From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: Re: RSVP-TE and PW Date: Fri, 01 Oct 2004 07:55:56 +0100 Lines: 12 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Fri Oct 01 09:13:12 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Sasha Vainshtein In-Reply-To: X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Sasha Vainshtein wrote: >IMHO,if you want to push forward RSVP-TE as one of the PW signaling >protocols, you should first define the problem that this method addresses >and which is not natively addressed by the existing LDP-based protocol. > > This is the key issue here. - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: Re: Scaling RSVP-TE end-to-end (was: RSVP-TE and PW) Date: Fri, 01 Oct 2004 08:10:09 +0100 Lines: 17 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, chmetz@cisco.com X-From: pwe3-bounces@ietf.org Fri Oct 01 09:50:20 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: richard.spencer@bt.com In-Reply-To: X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org richard.spencer@bt.com wrote: >However, there is ongoing work on hierarchical RSVP-TE, which sounds like it may have the potential to scale RSVP-TE PE-PE using a 2+ layer hierarchy. Using RSVP-TE PE-PE would have several advantages, e.g. end-to-end FRR across the provider network, PE level CAC, and P2P/P2MP OAM and performance monitoring (i.e. no MP2P OAM issues where the source is lost). If we get to this stage then it would make sense to use RSVP-TE for PW signalling as well. > >IMO using LDP PW signalling makes sense today, but if hierarchical RSVP-TE delivers then RSVP-TE PW signalling would make sense in the future for some deployments/providers. For this reason I would like to see the RSVP-TE PW signalling approach remain on the table and not be rejected at this time, at least until the capability to scale RSVP-TE PE-PE using hierarchy is proved/disproved. > > > So, hierarchical RSVP-TE is the enabling technology, for the use of RSVP-TE as a PW signalling protocol, but we do not yet know whether it works. That would suggest that the WG should put RSVP-TE PW setup on the back burner until we resolve the RSVP-TE performance concerns. - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Nurit Sprecher" Subject: RE: RSVP-TE and PW Date: Fri, 1 Oct 2004 11:32:38 +0200 Lines: 74 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Oct 01 17:31:16 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSmJeV84g8ZrFfQRh6GNdfp1NPXygBclh2g To: X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Thanks Eric for your response. Please see my comments/questions in-line. Nurit. -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Wednesday, September 29, 2004 15:13 To: Nurit Sprecher Cc: pwe3@ietf.org Subject: Re: [PWE3] RSVP-TE and PW=20 Nurit> I can list some benefits in using RSVP-TE for signaling PWs even = in Nurit> intra domain. For example: Nurit> 1. For TE environment, TE tunnels could be considered as = point-to-point Nurit> TE links and IGP-TE could distribute the actual load of them and = CSPF Nurit> could be used to select (automatically) the most appropriate TE = tunnel Nurit> to transmit the PW's TE traffic. Today this should be manually = defined Nurit> via the MPLS PW MIB). This seems to be confusing the PSN tunnels through which PWs travel with = the PWs themselves. Sending the PW data through an RSVP-TE tunnel, = even a dynamically chosen RSVP-TE tunnel, does not require using RSVP-TE to = set up and maintain the PWs. Nurit: Right, but this would probably not work in inter domain (when = tunnel-switching).=20 Nurit> 2. There is no way to identify at the Egress side on which = specific TE Nurit> Tunnel the traffic from the MPLS network is coming. Such = information Nurit> could be useful in the switches to support enhanced modes of QoS = (to Nurit> know the amount of BW expected to come from each port). Since the = Egress Nurit> has no idea from which tunnel the PW's traffic would come, the = Egress hs Nurit> no idea from which port the PW's traffic would come (it = potentially may Nurit> come from each port). If RSVP-TE is used to signal the PWs, the = Egress Nurit> node could identify from which specific ports to expect the = traffic. Again, binding a PW to a particular tunnel does not require that = the PW setup and maintenance protocol be the same protocol as the tunnel setup = and maintenance protocol. Nurit: Agree.=20 If we were sending TCP connections through a TE tunnel, you wouldn't = propose to replace TCP with RSVP-TE, would you? Nurit: It could be. I guess that you mean to open a TCP session between = two PE peers for each tunnel between them. And how does it work with a = 1:1 FRR protected tunnel (especially when using the path specific = mechanism)? Should we multiplex the TCP session at each detour? And = still we should have a mechanism at the Egress to sense from which = instance of the tunnel the traffic is actually coming from. What is the benefit of the TCP over the RSVP-TE? Why is the reason for = the strong objection for using RSVP-TE for PWs? From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Nurit Sprecher" Subject: RE: RSVP-TE and PW Date: Fri, 1 Oct 2004 11:41:25 +0200 Lines: 63 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3 , "Stewart Bryant X-From: pwe3-bounces@ietf.org Fri Oct 01 17:49:00 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSmK5wq1+VIdDpZREOO+yq58YfwhwBbkKVg To: , "Diego Caviglia" X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Eric, I absolutely agree with you that QoS relates to the AC. But when the PW = transmits across multiple tunnels (muin ltiple domains), the QOS = information is required in order to select the end-to-end best route and = to 'allocate resources' within the tunnel. As I said in my previous = mail, if the tunnels are considered as point-to point links and their TE = attributes and their actual load are distributed via the IGP-TE = protocol, maybe using the PCE mechanism, the best end-to end route for = the PW's traffic can be selected.=20 Nurit. -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of = Eric Rosen Sent: Wednesday, September 29, 2004 15:27 To: Diego Caviglia Cc: pwe3; Stewart Bryant given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS) The "some advantage" is not relevant in this context.=20 The network layer tunnels through which the PWs flow may have QoS. = The attachment circuits which are connected to each other via a PW may have = QoS. But I don't think there is any notion of QoS which is specific to = the PW itself, rather than to the network layer or the attachment circuits. Therefore, any QoS parameter carried in the PW setup protocol would = really be just an opaque object to that protocol. A PW endpoint might want to = pass this object to the network layer, saying in effect "put this PW = through a tunnel that has this QoS". A PW endpoint might want to pass this = object to the NSP layer, saying in effect "set up the attachment circuit = according to these QoS parameters". But the PW setup protocol doesn't actually = do anything itself with the QoS parameter, other than to carry it around = and pass it off. The only QoS requirement for the PW signaling protocol is = that it be able to carry an opaque QoS object from one endpoint to = another. RSVP-TE has no advantage over LDP with respect to the carrying of = objects from one endpoint to another. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Nurit Sprecher" Subject: RE: RSVP-TE and PW Date: Fri, 1 Oct 2004 11:48:40 +0200 Lines: 89 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Oct 01 18:05:17 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSmJeV84g8ZrFfQRh6GNdfp1NPXygBclh2gAADD/SA= To: "Nurit Sprecher" , X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org In addition to the below, also when using a TCP session within a tunnel, = then if the tunnel fails and recovers later, the TCP session should be = re-established, and all PW's information should be re-signaled. If the = TCP session is established in the IGP network, then the route of the = session and the route of the tunnel probably differ (when talking about = TE tunnel with TE constraints). Also only one TCP session should be = established between a pair of PE peers. -----Original Message----- From: Nurit Sprecher=20 Sent: Friday, October 01, 2004 11:33 To: 'erosen@cisco.com' Cc: pwe3@ietf.org Subject: RE: [PWE3] RSVP-TE and PW=20 Thanks Eric for your response. Please see my comments/questions in-line. Nurit. -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Wednesday, September 29, 2004 15:13 To: Nurit Sprecher Cc: pwe3@ietf.org Subject: Re: [PWE3] RSVP-TE and PW Nurit> I can list some benefits in using RSVP-TE for signaling PWs even = in Nurit> intra domain. For example: Nurit> 1. For TE environment, TE tunnels could be considered as = point-to-point Nurit> TE links and IGP-TE could distribute the actual load of them and = CSPF Nurit> could be used to select (automatically) the most appropriate TE = tunnel Nurit> to transmit the PW's TE traffic. Today this should be manually = defined Nurit> via the MPLS PW MIB). This seems to be confusing the PSN tunnels through which PWs travel with = the PWs themselves. Sending the PW data through an RSVP-TE tunnel, = even a dynamically chosen RSVP-TE tunnel, does not require using RSVP-TE to = set up and maintain the PWs. Nurit: Right, but this would probably not work in inter domain (when = tunnel-switching). Nurit> 2. There is no way to identify at the Egress side on which = specific TE Nurit> Tunnel the traffic from the MPLS network is coming. Such = information Nurit> could be useful in the switches to support enhanced modes of QoS = (to Nurit> know the amount of BW expected to come from each port). Since the = Egress Nurit> has no idea from which tunnel the PW's traffic would come, the = Egress hs Nurit> no idea from which port the PW's traffic would come (it = potentially may Nurit> come from each port). If RSVP-TE is used to signal the PWs, the = Egress Nurit> node could identify from which specific ports to expect the = traffic. Again, binding a PW to a particular tunnel does not require that = the PW setup and maintenance protocol be the same protocol as the tunnel setup = and maintenance protocol. Nurit: Agree. If we were sending TCP connections through a TE tunnel, you wouldn't = propose to replace TCP with RSVP-TE, would you? Nurit: It could be. I guess that you mean to open a TCP session between = two PE peers for each tunnel between them. And how does it work with a = 1:1 FRR protected tunnel (especially when using the path specific = mechanism)? Should we multiplex the TCP session at each detour? And = still we should have a mechanism at the Egress to sense from which = instance of the tunnel the traffic is actually coming from. What is the benefit of the TCP over the RSVP-TE? Why is the reason for = the strong objection for using RSVP-TE for PWs? From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Fri, 1 Oct 2004 10:46:20 -0400 Lines: 56 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: erosen@cisco.com, pwe3@ietf.org, "'richard.spencer@bt.com'" X-From: pwe3-bounces@ietf.org Fri Oct 01 19:16:43 2004 Return-path: To: "'Stewart Bryant'" , Sasha Vainshtein X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org To answer the question: what problem would RSVP-TE solve: In the current PWE3 architecture, PEs multiplex multiple PWs onto a PSN tunnel that extends from the ingress PE to the egress PE. With growing MPLS deployment, it is conceivable that there is not always an end-to-end PSN tunnel between two PEs and that there is a need to "re-multiplex": take PWs out of one tunnel and map them onto another. In fact, I think it is more than conceivable. It is very likely. Service Providers grow through mergers and acquisitions and will have to interconnect independent MPLS islands. And within one network, MPLS will extend further and further to the edge of the network. The notion of re-multiplexing PWs is not new. E.g. section 3.5 of draft-ietf-l2vpn-signaling-02.txt shows an achitecture in which it occurs. However, the section leaves big questions about the appropriate control infrastructure to manage this architecture. The text under the figure in 3.5 suggests extensive use of maual provisioning or the use of some undefined discovery protocol. Similarly, another draft that addresses this issue (draft-martini-pwe3-pw-switching-00.txt), strongly suggests that intermediate switching nodes are manually provisioned. The problem with manual provisioning is that it impacts resiliency. If one intermediate node goes down, it would be good if PWs could be rapidly established via a different route. Also, there are cases in which PW set up needs to be fully automatic. E.g. there are cases in which signaling messages in the client layer (e.g. PNNI messages in the case of ATM) trigger PW setup and the end-to-end connection setup needs to happen without operator interference. These considerations suggest that it would be helpful to have a PW setup mechanism that allows the ingress node to select a path through one or more intermediate PW Switching nodes to the egress PE and use a single-sided signaling mechanism to establish the PW along that path. One solution would be to use a signaling protocol that carries some kind of Explicit Route Object. In earlier emails, it was observed that certain application require the PW setup protocol to carry QoS objects. This brings us to the rationale for RSVP-TE. If you need a protocol that carries an ERO and QoS objects, RSVP-TE is the obvious choice. Is it absolutely clear that we need RSVP-TE? No. We are at the very beginning of the deployment of PWE. We have little idea how MPLS networks will be deployed five years from now. With regards to PW Switching, one of the big questions we are struggling with is whether PW Switching is only required at the edge of Autonomous Systems. If that would be the case, RSVP-TE may have little benefit and a combination of BGP and LDP would probably be a better solutions. However, if PW Switching nodes would be required within ASs, RSVP-TE seems to offer a straightforward solution. Considering this uncertainty, I would echo Richard's request: "I would like to see the RSVP-TE PW signalling approach remain on the table and not be rejected at this time." One last note: I am somewhat surprised by references to RSVP performance problems. I don't think the problem is RSVP. By definition, there are scaleability concerns about PW Switching. PWE introduces large numbers of fine-grained "connections". Any PW Switching solution would have to deal with that. Whether you use LDP or RSVP should not matter. (I assume that the people who decided that CR-LDP should be retired in favor of RSVP-TE were convinced that the two solutions scaled equally well to large numbers of connections.) Peter > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, October 01, 2004 2:56 AM > To: Sasha Vainshtein > Cc: erosen@cisco.com; pwe3@ietf.org; 'richard.spencer@bt.com' > Subject: Re: [PWE3] RSVP-TE and PW > > > Sasha Vainshtein wrote: > > > > >IMHO,if you want to push forward RSVP-TE as one of the PW signaling > >protocols, you should first define the problem that this > method addresses > >and which is not natively addressed by the existing > LDP-based protocol. > > > > > This is the key issue here. > > - Stewart > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: RSVP-TE and PW Date: Fri, 1 Oct 2004 21:31:53 +0200 Lines: 144 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'erosen@cisco.com '" , "'pwe3@ietf.org '" , "''richard.spencer@bt.com' '" X-From: pwe3-bounces@ietf.org Fri Oct 01 22:06:52 2004 Return-path: To: "'Busschbach, Peter B (Peter) '" , "''Stewart Bryant' '" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, Thank you for a prompt and highly informative response. Please see some comments inline. Regards, Sasha -----Original Message----- From: Busschbach, Peter B (Peter) To: 'Stewart Bryant'; Sasha Vainshtein Cc: erosen@cisco.com; pwe3@ietf.org; 'richard.spencer@bt.com' Sent: 10/1/2004 4:46 PM Subject: RE: [PWE3] RSVP-TE and PW To answer the question: what problem would RSVP-TE solve: In the current PWE3 architecture, PEs multiplex multiple PWs onto a PSN tunnel that extends from the ingress PE to the egress PE. With growing MPLS deployment, it is conceivable that there is not always an end-to-end PSN tunnel between two PEs [Sasha] I agree that non-existence of an end-to-end PSN tunnel between [Sasha] a pair of PEs is the problem PW switching tries to address. [Sasha] At the same time, if you PE-to-PE tunnels with the desired [Sasha] properties exist (as the current architecture assumes), there is [Sasha] no need for PW switching. I also think that this is what makes PW [Sasha] switching special to MPLS (as opposed to IP) PSN. and that there is a need to "re-multiplex": take PWs out of one tunnel and map them onto another. In fact, I think it is more than conceivable. It is very likely. Service Providers grow through mergers and acquisitions and will have to interconnect independent MPLS islands. And within one network, MPLS will extend further and further to the edge of the network. [Sasha] I think that this already happens with2547-based L3 VPNs, [Sasha] even if I do not know the details. The notion of re-multiplexing PWs is not new. E.g. section 3.5 of draft-ietf-l2vpn-signaling-02.txt shows an achitecture in which it occurs. However, the section leaves big questions about the appropriate control infrastructure to manage this architecture. The text under the figure in 3.5 suggests extensive use of maual provisioning or the use of some undefined discovery protocol. Similarly, another draft that addresses this issue (draft-martini-pwe3-pw-switching-00.txt), strongly suggests that intermediate switching nodes are manually provisioned. The problem with manual provisioning is that it impacts resiliency. If one intermediate node goes down, it would be good if PWs could be rapidly established via a different route. [Sasha] Again, I agree, However,I am not sure RSVP-TE really provides [Sasha] this kind of resilience. Please see below. Also, there are cases in which PW set up needs to be fully automatic. E.g. there are cases in which signaling messages in the client layer (e.g. PNNI messages in the case of ATM) trigger PW setup and the end-to-end connection setup needs to happen without operator interference. These considerations suggest that it would be helpful to have a PW setup mechanism that allows the ingress node to select a path through one or more intermediate PW Switching nodes to the egress PE and use a single-sided signaling mechanism to establish the PW along that path. One solution would be to use a signaling protocol that carries some kind of Explicit Route Object. [Sasha] But does it not require pre-knowledge about the potential [Sasha] PW switching nodes? And is learning these nodes provided via [Sasha] RSVP-TE per se? In earlier emails, it was observed that certain application require the PW setup protocol to carry QoS objects. This brings us to the rationale for RSVP-TE. If you need a protocol that carries an ERO and QoS objects, RSVP-TE is the obvious choice. Is it absolutely clear that we need RSVP-TE? No. We are at the very beginning of the deployment of PWE. We have little idea how MPLS networks will be deployed five years from now. With regards to PW Switching, one of the big questions we are struggling with is whether PW Switching is only required at the edge of Autonomous Systems. If that would be the case, RSVP-TE may have little benefit and a combination of BGP and LDP would probably be a better solutions. However, if PW Switching nodes would be required within ASs, RSVP-TE seems to offer a straightforward solution. [Sasha] I think that this is a very good question. The need for intra-AS [Sasha] PW switching, if it exists, would assume that intra-AS PE-to-PE [Sasha] tunnels with the desired properties cannot be created. [Sasha] I do not see at this moment, why this should be the case, [Sasha] and, IMHO, this point clearly deserves clarification. Considering this uncertainty, I would echo Richard's request: "I would like to see the RSVP-TE PW signalling approach remain on the table and not be rejected at this time." [Sasha] I would be glad if we could say more, e.g., complie a list of [Sasha] issues (starting with the need for intra-AS PW switching) that [Sasha] should be resolved in order to answer the question of [Sasha] applicability of the RSVP-TE PW signaling approach. One last note: I am somewhat surprised by references to RSVP performance problems. I don't think the problem is RSVP. By definition, there are scaleability concerns about PW Switching. PWE introduces large numbers of fine-grained "connections". Any PW Switching solution would have to deal with that. Whether you use LDP or RSVP should not matter. (I assume that the people who decided that CR-LDP should be retired in favor of RSVP-TE were convinced that the two solutions scaled equally well to large numbers of connections.) Peter > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, October 01, 2004 2:56 AM > To: Sasha Vainshtein > Cc: erosen@cisco.com; pwe3@ietf.org; 'richard.spencer@bt.com' > Subject: Re: [PWE3] RSVP-TE and PW > > > Sasha Vainshtein wrote: > > > > >IMHO,if you want to push forward RSVP-TE as one of the PW signaling > >protocols, you should first define the problem that this > method addresses > >and which is not natively addressed by the existing > LDP-based protocol. > > > > > This is the key issue here. > > - Stewart > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Tony Li Subject: Re: RSVP-TE and PW Date: Fri, 1 Oct 2004 12:56:07 -0700 Lines: 137 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, pwe3@ietf.org, "'richard.spencer@bt.com'" , Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Fri Oct 01 23:54:11 2004 Return-path: In-Reply-To: To: "Busschbach, Peter B (Peter)" X-Mailer: Apple Mail (2.619) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Peter, Following this logic, there are many other LSPs in the network other than just PW's. For example, one might have a number of TE LSPs also containing best effort traffic, or a number of VPN LSPs. In the scale of network that you describe, it seems likely that these might well be encapsulated in trunk LSPs. As you note, these trunk LSPs may well need to be re-multiplexed, which seems quite reasonable to me, as I've already seen this done. In such an environment, there is necessarily a considerable amount of TE going on, just because of the mismatch between the physical plant and the demand matrix. For the scalability of management, wouldn't it be better to allow the TE layer of the network to perform its functions and not try to meld that functionality into the PW layer? After all, without the global knowledge of the traffic matrix, PW is not likely to achieve an optimal (or even acceptable) solution, and it would effectively combat the TE layer. Regards, Tony On Oct 1, 2004, at 7:46 AM, Busschbach, Peter B (Peter) wrote: > To answer the question: what problem would RSVP-TE solve: > > In the current PWE3 architecture, PEs multiplex multiple PWs onto a > PSN tunnel that extends from the ingress PE to the egress PE. > > With growing MPLS deployment, it is conceivable that there is not > always an end-to-end PSN tunnel between two PEs and that there is a > need to "re-multiplex": take PWs out of one tunnel and map them onto > another. In fact, I think it is more than conceivable. It is very > likely. Service Providers grow through mergers and acquisitions and > will have to interconnect independent MPLS islands. And within one > network, MPLS will extend further and further to the edge of the > network. > > The notion of re-multiplexing PWs is not new. E.g. section 3.5 of > draft-ietf-l2vpn-signaling-02.txt shows an achitecture in which it > occurs. However, the section leaves big questions about the > appropriate control infrastructure to manage this architecture. The > text under the figure in 3.5 suggests extensive use of maual > provisioning or the use of some undefined discovery protocol. > Similarly, another draft that addresses this issue > (draft-martini-pwe3-pw-switching-00.txt), strongly suggests that > intermediate switching nodes are manually provisioned. > > The problem with manual provisioning is that it impacts resiliency. If > one intermediate node goes down, it would be good if PWs could be > rapidly established via a different route. Also, there are cases in > which PW set up needs to be fully automatic. E.g. there are cases in > which signaling messages in the client layer (e.g. PNNI messages in > the case of ATM) trigger PW setup and the end-to-end connection setup > needs to happen without operator interference. > > These considerations suggest that it would be helpful to have a PW > setup mechanism that allows the ingress node to select a path through > one or more intermediate PW Switching nodes to the egress PE and use a > single-sided signaling mechanism to establish the PW along that path. > One solution would be to use a signaling protocol that carries some > kind of Explicit Route Object. > > In earlier emails, it was observed that certain application require > the PW setup protocol to carry QoS objects. > > This brings us to the rationale for RSVP-TE. If you need a protocol > that carries an ERO and QoS objects, RSVP-TE is the obvious choice. > > Is it absolutely clear that we need RSVP-TE? No. We are at the very > beginning of the deployment of PWE. We have little idea how MPLS > networks will be deployed five years from now. > > With regards to PW Switching, one of the big questions we are > struggling with is whether PW Switching is only required at the edge > of Autonomous Systems. If that would be the case, RSVP-TE may have > little benefit and a combination of BGP and LDP would probably be a > better solutions. However, if PW Switching nodes would be required > within ASs, RSVP-TE seems to offer a straightforward solution. > > Considering this uncertainty, I would echo Richard's request: "I would > like to see the RSVP-TE PW signalling approach remain on the table and > not be rejected at this time." > > > One last note: I am somewhat surprised by references to RSVP > performance problems. I don't think the problem is RSVP. By > definition, there are scaleability concerns about PW Switching. PWE > introduces large numbers of fine-grained "connections". Any PW > Switching solution would have to deal with that. Whether you use LDP > or RSVP should not matter. (I assume that the people who decided that > CR-LDP should be retired in favor of RSVP-TE were convinced that the > two solutions scaled equally well to large numbers of connections.) > > Peter > >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Friday, October 01, 2004 2:56 AM >> To: Sasha Vainshtein >> Cc: erosen@cisco.com; pwe3@ietf.org; 'richard.spencer@bt.com' >> Subject: Re: [PWE3] RSVP-TE and PW >> >> >> Sasha Vainshtein wrote: >> >> >> >>> IMHO,if you want to push forward RSVP-TE as one of the PW signaling >>> protocols, you should first define the problem that this >> method addresses >>> and which is not natively addressed by the existing >> LDP-based protocol. >>> >>> >> This is the key issue here. >> >> - Stewart >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: rfc-editor@rfc-editor.org Subject: RFC 3916 on Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) Date: Fri, 01 Oct 2004 13:14:34 -0700 Lines: 112 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org X-From: pwe3-bounces@ietf.org Sat Oct 02 00:27:22 2004 Return-path: To: ietf-announce@ietf.org X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3916 Title: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) Author(s): X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed. Status: Informational Date: September 2004 Mailbox: xxiao@riverstonenet.com, danny@arbor.net, prayson.pate@overturenetworks.com Pages: 19 Characters: 43856 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-requirements-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3916.txt 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. This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Diego Caviglia" Subject: Re: RSVP-TE and PW Date: Mon, 4 Oct 2004 17:25:29 +0200 Lines: 14 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Mon Oct 04 17:38:40 2004 Return-path: To: pwe3@ietf.org X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 04/10/2004 16:25:24 X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org May be this question is out of 3d anyway, how can I cope with multicast traffic? There is an ID about multicast extension for RSVP-TE that allows the creation of p2mp tunnel but AFAIK there is no way (using LDP) to provision p2mp PW. So I have a tunnel protocol with the possibility to set-up p2mp but i haven't the possibility to signal p2mp pw. Best Regards Diego From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: Re: RSVP-TE and PW Date: Mon, 04 Oct 2004 17:50:10 +0100 Lines: 9 Sender: pwe3-bounces@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-bounces@ietf.org Mon Oct 04 19:13:53 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Diego Caviglia In-Reply-To: X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Diego Caviglia wrote: > May be this question is out of 3d anyway, how can I cope with multicast > traffic? What sort of multicast traffic? - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: RSVP-TE and PW Date: Mon, 04 Oct 2004 13:40:42 -0400 Lines: 50 Sender: pwe3-bounces@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org, "'richard.spencer@bt.com'" , Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Mon Oct 04 19:57:29 2004 Return-path: X-BrightmailFiltered: true To: "Busschbach, Peter B (Peter)" In-reply-to: Your message of Fri, 01 Oct 2004 10:46:20 -0400. 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) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter> If one intermediate node goes down, it would be good if PWs could be Peter> rapidly established via a different route. Also, there are cases in Peter> which PW set up needs to be fully automatic. E.g. there are cases in Peter> which signaling messages in the client layer (e.g. PNNI messages in Peter> the case of ATM) trigger PW setup and the end-to-end connection setup Peter> needs to happen without operator interference. So far, so good. Peter> These considerations suggest that it would be helpful to have a PW Peter> setup mechanism that allows the ingress node to select a path through Peter> one or more intermediate PW Switching nodes to the egress PE and use Peter> a single-sided signaling mechanism to establish the PW along that Peter> path These considerations suggest that a PW switching point should be able to dynamically determine the next PW switching point. I don't see how you've drawn any conclusion about the need for carrying an explicit path from the ingress. In general, if you want routing to failed paths repaired automatically, you want something which will route around the failure, rather than something which requires the ingress to recompute (based on what?) an explicit route. If the PW egress is to stay the same, while the set of tunnels through which the PW passes is to change, then what you are asking for is a routing protocol that runs over the tunnel overlay, and which gives you the "next hop" in that overlay for the IP address of the egress. Note that the overlay consists not of the PWs, but of the tunnels. > if PW Switching nodes would be required within ASs, RSVP-TE seems to offer > a straightforward solution. I would like to understand better what the antecedent of this statement is true. However, I certainly don't agree with the conclusion, as RSVP-TE does not provide the routing capability that appears to be required in this case. As I said, I'd like to understand better the need for routing over the tunnel overlay. If that model turns out to be necessary, we can then discuss whether its needs can or cannot be met with the existing protocols. The claim that RSVP-TE is preferable whenever we need to send parameters which we call "QoS" or "explicit route" is not a claim which I can take very seriously. Generally, if you have a protocol that does something, and you find that you need to add a new parameter, you just add the new parameter; you don't go looking for another protocol that already has a parameter of the same name! You first need to understand which is the tail and which is the dog. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Thomas D. Nadeau" Subject: Re: RSVP-TE and PW Date: Mon, 4 Oct 2004 13:55:49 -0400 Lines: 96 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, pwe3 , "Stewart Bryant X-From: pwe3-bounces@ietf.org Mon Oct 04 20:15:22 2004 Return-path: X-BrightmailFiltered: true In-Reply-To: To: Benny Ammitzboll X-Mailer: Apple Mail (2.619) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org There seems little logical relevance as to whether you should use one protocol or the other because you have already implemented one or the other. The fact is that if you are building an LSR (or enhancing an existing one), you should be building in both RSVP-TE and LDP anyway (or have both there already). To me, the most germane point is what Eric said earlier -- LDP signaling for PWs already is well understood, deployed in real code and solves what seems to be the same problems solved by an RSVP-TE-based approach. Call me cynical, but it seems that this argument really boils down to is the old RSVP-TE vs. CR-LDP argument (again) -- both protocols solve the same problems, with the majority implementing/deploying one approach, while the other approach is pushed by a small number of vendors or vendor who seem to be motivated solely by their marketing departments to hold out for their 'alternate' approach based on purported technical superiority. --Tom > May I add that if you already have RSVP-TE to set up your TE tunnels > there > seems to be little advantage in implementing yet another protocol to > carry > the same kind of objects from one endpoint to another. > > Therefore I find the question raised by Diego relevant - although it is > probably too late. > > /Benny > > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of > Eric Rosen > Sent: 29. september 2004 15:27 > To: Diego Caviglia > Cc: pwe3; Stewart Bryant Subject: Re: [PWE3] RSVP-TE and PW > > > >> given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS) > > The "some advantage" is not relevant in this context. > > The network layer tunnels through which the PWs flow may have > QoS. The > attachment circuits which are connected to each other via a PW may > have QoS. > But I don't think there is any notion of QoS which is specific to > the PW > itself, rather than to the network layer or the attachment circuits. > > Therefore, any QoS parameter carried in the PW setup protocol would > really > be just an opaque object to that protocol. A PW endpoint might want > to pass > this object to the network layer, saying in effect "put this PW > through a > tunnel that has this QoS". A PW endpoint might want to pass this > object to > the NSP layer, saying in effect "set up the attachment circuit > according to > these QoS parameters". But the PW setup protocol doesn't > actually do > anything itself with the QoS parameter, other than to carry it > around and > pass it off. The only QoS requirement for the PW signaling protocol > is that > it be able to carry an opaque QoS object from one endpoint to > another. > RSVP-TE has no advantage over LDP with respect to the carrying of > objects > from one endpoint to another. > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "David Allan" Subject: RE: RSVP-TE and PW Date: Mon, 4 Oct 2004 14:37:48 -0400 Lines: 125 Sender: pwe3-bounces@ietf.org Cc: erosen@cisco.com, pwe3 , "Stewart Bryant X-From: pwe3-bounces@ietf.org Mon Oct 04 20:53:38 2004 Return-path: To: "'Thomas D. Nadeau'" , Benny Ammitzboll X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org There's somthing to be learned from the way victors write history.... ;-) cheers Dave > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Thomas D. Nadeau > Sent: Monday, October 04, 2004 1:56 PM > To: Benny Ammitzboll > Cc: erosen@cisco.com; pwe3; Stewart Bryant Subject: Re: [PWE3] RSVP-TE and PW > > > > There seems little logical relevance as to whether > you should use one protocol or the other because you have > already implemented one or the other. The fact is that if you > are building an LSR (or enhancing an existing one), you > should be building in both RSVP-TE and LDP anyway > (or have both there already). To me, the most > germane point is what Eric said earlier -- LDP signaling > for PWs already is well understood, deployed in real > code and solves what seems to be the same problems solved by > an RSVP-TE-based approach. Call me cynical, but it seems > that this argument really boils down to is the old RSVP-TE > vs. CR-LDP argument (again) -- both protocols solve the > same problems, with the majority implementing/deploying > one approach, while the other approach is pushed by a small > number of vendors or vendor who seem to be motivated solely > by their marketing departments to hold out for their > 'alternate' approach based on purported technical superiority. > > --Tom > > > > > May I add that if you already have RSVP-TE to set up your TE tunnels > > there > > seems to be little advantage in implementing yet another > protocol to > > carry > > the same kind of objects from one endpoint to another. > > > > Therefore I find the question raised by Diego relevant - > although it > > is probably too late. > > > > /Benny > > > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org > [mailto:pwe3-bounces@ietf.org]On Behalf Of > > Eric Rosen > > Sent: 29. september 2004 15:27 > > To: Diego Caviglia > > Cc: pwe3; Stewart Bryant > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > >> given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS) > > > > The "some advantage" is not relevant in this context. > > > > The network layer tunnels through which the PWs flow may have > > QoS. The > > attachment circuits which are connected to each other via a PW may > > have QoS. > > But I don't think there is any notion of QoS which is > specific to > > the PW > > itself, rather than to the network layer or the attachment circuits. > > > > Therefore, any QoS parameter carried in the PW setup > protocol would > > really > > be just an opaque object to that protocol. A PW endpoint > might want > > to pass > > this object to the network layer, saying in effect "put this PW > > through a > > tunnel that has this QoS". A PW endpoint might want to pass this > > object to > > the NSP layer, saying in effect "set up the attachment circuit > > according to > > these QoS parameters". But the PW setup protocol doesn't > > actually do > > anything itself with the QoS parameter, other than to carry it > > around and > > pass it off. The only QoS requirement for the PW signaling > protocol > > is that > > it be able to carry an opaque QoS object from one endpoint to > > another. > > RSVP-TE has no advantage over LDP with respect to the > carrying of > > objects > > from one endpoint to another. > > > > > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Mon, 4 Oct 2004 18:19:38 -0400 Lines: 134 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: erosen@cisco.com, pwe3 , "Stewart Bryant X-From: pwe3-bounces@ietf.org Tue Oct 05 00:23:10 2004 Return-path: To: "'Thomas D. Nadeau'" , Benny Ammitzboll X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Tom, I currently have problems with email access and lack of time to answer email. Therefore, I am not yet able to respond to other emails on this topict. However, I can't let this one go unchallenged. I am not having the CR-LDP vs RSVP-TE debate again. It has been decided. The answer is RSVP-TE. Did you see me propose CR-LDP?? Just to be clear: I personally don't see any reason why you would use RSVP-TE for the existing PW architecture that consists of single-hop PWs over end-to-end PSN tunnels between PEs. My previous email was based on the premise that perhaps, at some point in the future, we may find that the current PW architecture does not scale well and that enhanced solutions are needed. Going back in time: RIP was a protocol "well understood, deployed in real code". According to your logic, we should never have developed OSPF and IS-IS. Peter > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, October 04, 2004 1:56 PM > To: Benny Ammitzboll > Cc: erosen@cisco.com; pwe3; Stewart Bryant Subject: Re: [PWE3] RSVP-TE and PW > > > > There seems little logical relevance as to whether > you should use one protocol or the other because you have > already implemented one or the other. The fact is > that if you are building an LSR (or enhancing an > existing one), you should be building in both RSVP-TE and LDP anyway > (or have both there already). To me, the most > germane point is what Eric said earlier -- LDP signaling > for PWs already is well understood, deployed in real > code and solves what seems to be the same problems solved by > an RSVP-TE-based approach. Call me cynical, but it seems > that this argument really boils down to is the old RSVP-TE > vs. CR-LDP argument (again) -- both protocols solve the > same problems, with the majority implementing/deploying > one approach, while the other approach is pushed by a small > number of vendors or vendor who seem to be motivated solely by > their marketing departments to hold out for their > 'alternate' approach based on purported technical > superiority. > > --Tom > > > > > May I add that if you already have RSVP-TE to set up your > TE tunnels > > there > > seems to be little advantage in implementing yet another > protocol to > > carry > > the same kind of objects from one endpoint to another. > > > > Therefore I find the question raised by Diego relevant - > although it is > > probably too late. > > > > /Benny > > > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org > [mailto:pwe3-bounces@ietf.org]On Behalf Of > > Eric Rosen > > Sent: 29. september 2004 15:27 > > To: Diego Caviglia > > Cc: pwe3; Stewart Bryant > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > >> given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS) > > > > The "some advantage" is not relevant in this context. > > > > The network layer tunnels through which the PWs flow may have > > QoS. The > > attachment circuits which are connected to each other via a PW may > > have QoS. > > But I don't think there is any notion of QoS which is > specific to > > the PW > > itself, rather than to the network layer or the attachment circuits. > > > > Therefore, any QoS parameter carried in the PW setup > protocol would > > really > > be just an opaque object to that protocol. A PW endpoint > might want > > to pass > > this object to the network layer, saying in effect "put this PW > > through a > > tunnel that has this QoS". A PW endpoint might want to pass this > > object to > > the NSP layer, saying in effect "set up the attachment circuit > > according to > > these QoS parameters". But the PW setup protocol doesn't > > actually do > > anything itself with the QoS parameter, other than to carry it > > around and > > pass it off. The only QoS requirement for the PW signaling > protocol > > is that > > it be able to carry an opaque QoS object from one endpoint to > > another. > > RSVP-TE has no advantage over LDP with respect to the > carrying of > > objects > > from one endpoint to another. > > > > > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: [Fwd: Re: RSVP-TE and PW] Date: Tue, 05 Oct 2004 09:36:00 +0100 Lines: 62 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Tue Oct 05 10:42:47 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: pwe3 X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org -------- Original Message -------- Subject: Re: [PWE3] RSVP-TE and PW Date: Tue, 05 Oct 2004 09:31:57 +0100 From: Stewart Bryant To: Diego Caviglia CC: tnadeau@cisco.com, "Benny Ammitzboll , ", "pwe3\" \"" <"pwe3\" \""@smtpoutuk02.marconi.com> References: Diego Caviglia wrote: > Hi Thomas, > actually it seems to me that what we are > discussing here is if both the protocol solve the same problems and the > result is that: > > LDP doesn't provide QoS > LDP doesn't have TE features > LDP doesn't have mp2p That is as maybe, but as far as the PWE3 WG is concerned LDP is only being used for PE parameter negotiaton. If QoS or TE is needed the PEs ask the PSN to provide them. As for mp2p, the charter says: "Any multicast service not native to the emulated medium. Thus, Ethernet transmission to a "multicast" IEEE-48 address is in scope, while multicast services like MARS that are implemented on top of the medium are out of scope." The only service that we are have defined so far that might have used m/c is Ethernet. Now if there is a new service that we need to define please explicitly propose it. > > Now may be that feature are useless but may be not. Moreover as some > carrier said having two protocol instead only one is not good from an OPEX > point of view. If the proposal had been made when we started this WG it would have been considered. It was not made. Any new control protocol now needs to be justified on the basis that it solves some problem not reasonably addressed by the protocol that we are using today. I suggest that the place to start is a draft describing the problem being addressed, the reason why LDP is not suitable and a comparison with the alternatives. - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 10:36:33 +0100 Lines: 178 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: erosen@cisco.com, pwe3@ietf.org, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Tue Oct 05 11:44:18 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSqPlVWuUlDZ6bWRCG8cTntfDBNnQAdjkQA To: , X-OriginalArrivalTime: 05 Oct 2004 09:36:38.0421 (UTC) FILETIME=[D00C9450:01C4AABE] X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Tom...point taken. But if you also re-read Eric's last mail (04 October 2004 18:41) he is also reinforcing the point we in BT have been making from the outset here, ie PW switching will create a new layer network (though Eric is not explicitly expressing it like this)....so all the functions any layer network requires (which vary dependent on the mode considered) will require to be developed yet again. But for what compelling reason? Now, without labouring the point too heavily (yet again) the cl-ps mode is functionally not the same as the co-ps mode and neither is functionally the same as the co-cs mode. So if you really want to point the finger at where the root problem lies it is here. Once folks grok that the so-called peer-model notion of 'functionally crunching' all the modes from IP to optics is a broken idea the rest follows.=20 It is also interesting to observe that some folks want RSVP-TE as *the* prescriptive signalling protocol for the co-cs mode (eg SDH/OTN), and note also it has to work OOB wrt to the traffic data-plane as this is forced requirement of the co-cs mode......well, that may be so, but it is not a logically forced choice for the signalling component once folks grok the peer-model coulping idea is a broken idea. A signalling protocol is a signalling protocol is a signalling protocol....some are better functionally specified than others, ie there are only so many ways to do this function (just like OAM if you also recall that 'discussion' ;-)). Of course, the message set is a little different for the co-ps mode and the co-cs mode (largely due to the fact that the link-connection IDs are abstract in the co-ps mode and real/physical in the co-cs mode).....but things like taking the signalling (and management-plane) protocols logically OOB wrt to the traffic ought to be a key requirement for both modes (simply from the enhanced security and stability considerations of a best-of breed solution here). However, this is not perhaps something that obviously springs to mind for folks used to only dealing with the cl-ps mode. The targeted spin of LDP signalling is more like a session protocol IMO, ie it only conveys parameters between 2 fixed end-points and does not flex connectivity between those 2 end-points. So whilst this remains 'the problem being addressed' this is fine. This is also very closely related to another point I have made many times in the past regarding the nature of the PW entity itself, ie its an adaptation function between 2 layer networks....with the additional spin that XoverIP is somehow the same as XoverMPLS. This is clearly not true of course, but it seems to keep some folks happy ;-)=20 But if one now wants to flex connectivity you need the full range of functions to make the PW entity a layer network, ie addressing, discovery/route-calculation, signalling, OAM, etc. So I think the gripe of those arguing for RSVP-TE here is that targeted LDP does not flex connectivity....as its not a proper signalling protocol. However, our gripe is that: - we don't need yet another 'PW' layer network being created....please just fix MPLS - and please try and grok functional architecture and how this applies to the 3 modes better so that errors-of-judgement like this don't keep being made. regards, Neil > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Thomas D. Nadeau > Sent: 04 October 2004 18:56 > To: Benny Ammitzboll > Cc: erosen@cisco.com; pwe3; Stewart Bryant Subject: Re: [PWE3] RSVP-TE and PW=20 >=20 >=20 >=20 > There seems little logical relevance as to whether > you should use one protocol or the other because you have=20 > already implemented one or the other. The fact is that if you=20 > are building an LSR (or enhancing an existing one), you=20 > should be building in both RSVP-TE and LDP anyway=20 > (or have both there already). To me, the most > germane point is what Eric said earlier -- LDP signaling > for PWs already is well understood, deployed in real > code and solves what seems to be the same problems solved by > an RSVP-TE-based approach. Call me cynical, but it seems > that this argument really boils down to is the old RSVP-TE > vs. CR-LDP argument (again) -- both protocols solve the > same problems, with the majority implementing/deploying > one approach, while the other approach is pushed by a small=20 > number of vendors or vendor who seem to be motivated solely=20 > by their marketing departments to hold out for their=20 > 'alternate' approach based on purported technical superiority. >=20 > --Tom >=20 >=20 >=20 > > May I add that if you already have RSVP-TE to set up your TE tunnels > > there > > seems to be little advantage in implementing yet another=20 > protocol to=20 > > carry > > the same kind of objects from one endpoint to another. > > > > Therefore I find the question raised by Diego relevant -=20 > although it=20 > > is probably too late. > > > > /Benny > > > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org=20 > [mailto:pwe3-bounces@ietf.org]On Behalf Of=20 > > Eric Rosen > > Sent: 29. september 2004 15:27 > > To: Diego Caviglia > > Cc: pwe3; Stewart Bryant > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > >> given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS) > > > > The "some advantage" is not relevant in this context. > > > > The network layer tunnels through which the PWs flow may have > > QoS. The > > attachment circuits which are connected to each other via a PW may=20 > > have QoS. > > But I don't think there is any notion of QoS which is=20 > specific to=20 > > the PW > > itself, rather than to the network layer or the attachment circuits. > > > > Therefore, any QoS parameter carried in the PW setup=20 > protocol would > > really > > be just an opaque object to that protocol. A PW endpoint=20 > might want=20 > > to pass > > this object to the network layer, saying in effect "put this PW=20 > > through a > > tunnel that has this QoS". A PW endpoint might want to pass this=20 > > object to > > the NSP layer, saying in effect "set up the attachment circuit=20 > > according to > > these QoS parameters". But the PW setup protocol doesn't=20 > > actually do > > anything itself with the QoS parameter, other than to carry it=20 > > around and > > pass it off. The only QoS requirement for the PW signaling=20 > protocol=20 > > is that > > it be able to carry an opaque QoS object from one endpoint to=20 > > another. > > RSVP-TE has no advantage over LDP with respect to the =20 > carrying of=20 > > objects > > from one endpoint to another. > > > > > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Kjeld Borch Egevang Subject: C-bit negotiation in draft-ietf-pwe3-control-protocol-10.txt Date: Tue, 05 Oct 2004 11:41:00 +0200 Lines: 19 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Tue Oct 05 11:49:20 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: en-us, en To: pwe3@ietf.org, lmartini@cisco.com X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org In "6.2. PW types for which the control word is NOT mandatory". Why is this complicated behaviour introduced? Why not do almost the same as in 6.1, i.e: -iii. If the received Label Mapping message has c=1, and the PW is locally configured such that the use of the control word is not preferred or the control word is not supported, then send a Label Release message with the "Wrong c-bit" status code. and receive behaviour: -iii. A Label Release with a "Wrong c-bit" status code and the Label Mapping message that was sent has c=1. In this case, send a Label Mapping message that has c=0. The control word is not used. /Kjeld From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Diego Caviglia" Subject: Re: RSVP-TE and PW Date: Tue, 5 Oct 2004 12:13:37 +0200 Lines: 131 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Tue Oct 05 12:20:06 2004 Return-path: To: pwe3@ietf.org X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 05/10/2004 11:13:31 X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Thomas, actually it seems to me that what we are discussing here is if both the protocol solve the same problems and the result is that: LDP doesn't provide QoS LDP doesn't have TE features LDP doesn't have mp2p Now may be that feature are useless but may be not. Moreover as some carrier said having two protocol instead only one is not good from an OPEX point of view. I'm not pushing one approach because "...who seem to be motivated solely by their marketing departments to hold out for their 'alternate' approach based on purported technical superiority." I'm just trying to understand well this stuff. Best Regards Diego "Thomas D. Nadeau" on 04/10/2004 19.55.49 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 13:20:51 +0200 Lines: 51 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'erosen@cisco.com '" , "'pwe3@ietf.org '" , "'stbryant@cisco.com '" X-From: pwe3-bounces@ietf.org Tue Oct 05 13:30:11 2004 Return-path: To: "'neil.2.harrison@bt.com '" , "'tnadeau@cisco.com '" , "'Benny.Ammitzboell@tpack.net '" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Neil and all, Please see a brief comment inline below (marked [Sasha]). I have snipped the parts of the message that, IMO, do not deal directly with this issue. Regards, Sasha. -----Original Message----- From: neil.2.harrison@bt.com To: tnadeau@cisco.com; Benny.Ammitzboell@tpack.net Cc: erosen@cisco.com; pwe3@ietf.org; stbryant@cisco.com Sent: 10/5/2004 11:36 AM Subject: RE: [PWE3] RSVP-TE and PW ... snipped ... A signalling protocol is a signalling protocol is a signalling protocol....some are better functionally specified than others, ie there are only so many ways to do this function (just like OAM if you also recall that 'discussion' ;-)). Of course, the message set is a little different for the co-ps mode and the co-cs mode (largely due to the fact that the link-connection IDs are abstract in the co-ps mode and real/physical in the co-cs mode).....but things like taking the signalling (and management-plane) protocols logically OOB wrt to the traffic ought to be a key requirement for both modes (simply from the enhanced security and stability considerations of a best-of breed solution here). However, this is not perhaps something that obviously springs to mind for folks used to only dealing with the cl-ps mode. [Sasha] One point that seems to me to be missing is the implicit [Sasha] assumption that co-ps networks work all by themselves. This may be [Sasha] correct for some of them (e.g., FR) but, IMO, this is de-facto [Sasha] incorrect for MPLS (even if you treat it as a co-ps network), [Sasha] since it (again, de-facto) exists side-by-side with IP and hence [Sasha] uses IP (and only IP!) in all its signaling protocols. [Sasha] To be more specific, most devices I'm aware of can treat MPLS [Sasha] as an add-on capability on their IP interfaces. [Sasha] One can argue that this is good or bad architecturally, [Sasha] but this is more or less the reality, and trying to change [Sasha] it (if you believe it is bad) would be very expensive. [Sasha] And it will become even more expensive as various IP-based [Sasha] things (like LSP ping) become deployed... [Sasha] At the same time, IMHO, as long as this situation goes on, there [Sasha] is no real justification for OOB (or, to be more specific, [Sasha] OOB-only). [Sasha] My 2c. [Sasha] signaling for MPLS. ... snipped to the end ... From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Thomas D. Nadeau" Subject: Re: RSVP-TE and PW Date: Tue, 5 Oct 2004 07:39:19 -0400 Lines: 159 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, pwe3 , Benny Ammitzboll , "Stewart Bryant X-From: pwe3-bounces@ietf.org Tue Oct 05 13:44:05 2004 Return-path: In-Reply-To: To: "Busschbach, Peter B (Peter)" X-Mailer: Apple Mail (2.619) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Oct 4, 2004, at 6:19 PM, Busschbach, Peter B (Peter) wrote: > Tom, > > I currently have problems with email access and lack of time to answer > email. Therefore, I am not yet able to respond to other emails on this > topict. However, I can't let this one go unchallenged. > > I am not having the CR-LDP vs RSVP-TE debate again. It has been > decided. The answer is RSVP-TE. Did you see me propose CR-LDP?? I didn't mean literally; rather, the flavor of the arguments are the same as were provided before during the old debates. > Just to be clear: I personally don't see any reason why you would use > RSVP-TE for the existing PW architecture that consists of single-hop > PWs over end-to-end PSN tunnels between PEs. > > My previous email was based on the premise that perhaps, at some point > in the future, we may find that the current PW architecture does not > scale well and that enhanced solutions are needed. > > Going back in time: RIP was a protocol "well understood, deployed in > real code". According to your logic, we should never have developed > OSPF and IS-IS. Not exactly. In that case there are clear advantages over RIP in OSPF or IS-IS. In this case, it is not clear what if any advantages there are for using RSVP-TE over LDP for signaling PWs. --Tom > > Peter > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: Monday, October 04, 2004 1:56 PM >> To: Benny Ammitzboll >> Cc: erosen@cisco.com; pwe3; Stewart Bryant > Subject: Re: [PWE3] RSVP-TE and PW >> >> >> >> There seems little logical relevance as to whether >> you should use one protocol or the other because you have >> already implemented one or the other. The fact is >> that if you are building an LSR (or enhancing an >> existing one), you should be building in both RSVP-TE and LDP anyway >> (or have both there already). To me, the most >> germane point is what Eric said earlier -- LDP signaling >> for PWs already is well understood, deployed in real >> code and solves what seems to be the same problems solved by >> an RSVP-TE-based approach. Call me cynical, but it seems >> that this argument really boils down to is the old RSVP-TE >> vs. CR-LDP argument (again) -- both protocols solve the >> same problems, with the majority implementing/deploying >> one approach, while the other approach is pushed by a small >> number of vendors or vendor who seem to be motivated solely by >> their marketing departments to hold out for their >> 'alternate' approach based on purported technical >> superiority. >> >> --Tom >> >> >> >>> May I add that if you already have RSVP-TE to set up your >> TE tunnels >>> there >>> seems to be little advantage in implementing yet another >> protocol to >>> carry >>> the same kind of objects from one endpoint to another. >>> >>> Therefore I find the question raised by Diego relevant - >> although it is >>> probably too late. >>> >>> /Benny >>> >>> >>> -----Original Message----- >>> From: pwe3-bounces@ietf.org >> [mailto:pwe3-bounces@ietf.org]On Behalf Of >>> Eric Rosen >>> Sent: 29. september 2004 15:27 >>> To: Diego Caviglia >>> Cc: pwe3; Stewart Bryant >> Subject: Re: [PWE3] RSVP-TE and PW >>> >>> >>> >>>> given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS) >>> >>> The "some advantage" is not relevant in this context. >>> >>> The network layer tunnels through which the PWs flow may have >>> QoS. The >>> attachment circuits which are connected to each other via a PW may >>> have QoS. >>> But I don't think there is any notion of QoS which is >> specific to >>> the PW >>> itself, rather than to the network layer or the attachment circuits. >>> >>> Therefore, any QoS parameter carried in the PW setup >> protocol would >>> really >>> be just an opaque object to that protocol. A PW endpoint >> might want >>> to pass >>> this object to the network layer, saying in effect "put this PW >>> through a >>> tunnel that has this QoS". A PW endpoint might want to pass this >>> object to >>> the NSP layer, saying in effect "set up the attachment circuit >>> according to >>> these QoS parameters". But the PW setup protocol doesn't >>> actually do >>> anything itself with the QoS parameter, other than to carry it >>> around and >>> pass it off. The only QoS requirement for the PW signaling >> protocol >>> is that >>> it be able to carry an opaque QoS object from one endpoint to >>> another. >>> RSVP-TE has no advantage over LDP with respect to the >> carrying of >>> objects >>> from one endpoint to another. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 13:40:32 +0100 Lines: 67 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: quoted-printable Cc: neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Tue Oct 05 14:43:12 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSqzwFXjjUKHCISQOq+ADtdI5m0KgAB4nOw To: X-OriginalArrivalTime: 05 Oct 2004 12:40:32.0450 (UTC) FILETIME=[80D7CA20:01C4AAD8] X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Sasha et al, Please see below... > A signalling protocol is a signalling protocol is a signalling > protocol....some are better functionally specified than=20 > others, ie there > are only so many ways to do this function (just like OAM if you also > recall that 'discussion' ;-)). Of course, the message set is a little > different for the co-ps mode and the co-cs mode (largely due=20 > to the fact > that the link-connection IDs are abstract in the co-ps mode and > real/physical in the co-cs mode).....but things like taking the > signalling (and management-plane) protocols logically OOB wrt to the > traffic ought to be a key requirement for both modes (simply from the > enhanced security and stability considerations of a best-of breed > solution here). However, this is not perhaps something that obviously > springs to mind for folks used to only dealing with the cl-ps mode. >=20 > [Sasha] One point that seems to me to be missing is the implicit=20 > [Sasha] assumption that co-ps networks work all by=20 > themselves. This may be > [Sasha] correct for some of them (e.g., FR) but, IMO, this is=20 > de-facto=20 > [Sasha] incorrect for MPLS (even if you treat it as a co-ps network),=20 > [Sasha] since it (again, de-facto) exists side-by-side with=20 > IP and hence > [Sasha] uses IP (and only IP!) in all its signaling protocols. > [Sasha] To be more specific, most devices I'm aware of can treat MPLS > [Sasha] as an add-on capability on their IP interfaces. > [Sasha] One can argue that this is good or bad architecturally, > [Sasha] but this is more or less the reality, and trying to change > [Sasha] it (if you believe it is bad) would be very expensive. > [Sasha] And it will become even more expensive as various IP-based > [Sasha] things (like LSP ping) become deployed... > [Sasha] At the same time, IMHO, as long as this situation=20 > goes on, there > [Sasha] is no real justification for OOB (or, to be more specific,=20 > [Sasha] OOB-only). > [Sasha] My 2c. > [Sasha] signaling for MPLS. I agree that IP and MPLS share an incestuous relationship. However just = because IP & MPLS exist side-by-side does not mean that OOB control is = not required/justified. For example in a standalone MPLS 2547 VPN = deployment (i.e. where a provider has built a MPLS network that is used = solely to provide 2547 VPNs and nothing else) the IP network is = basically just used to control the MPLS network then there is no reason = to mandate that the control plane layer network (i.e. IP) has to be = inband with the data plane layer network (i.e. MPLS). IMO the incestuous relationship between IP & MPLS is irrelevant, the = reason that it is/would be expensive at the present time to take the = control plane OOB is because of the implicit assumption that the control = plane is always carried inband (and the amount of kludges/protocols that = rely on this assumption). What we need to start doing is recognising = that service providers see a need for OOB control and start moving = towards that goal, rather than just carrying on as in the past because = it is the path of least resistance. One final point - the GMPLS folks seem to have managed to get IP (as a = control plane) and GMPLS (as a data plane) decoupled. Given the = similarity between MPLS & GMPLS it would not appear to me to be a = insurmountable task to get an OOB control plane for MPLS (or any co-ps = layer network). Ben From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 15:02:30 +0200 Lines: 97 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'neil.2.harrison@bt.com '" X-From: pwe3-bounces@ietf.org Tue Oct 05 15:15:10 2004 Return-path: To: "'benjamin.niven-jenkins@bt.com '" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Ben, Thank you for a prompot response. I respectfully disagree with your position on MPLS-IP relationship as "irrelevant" (leaving aside such qualifiers as "incestous"). IMHO, it is exactly this relationship that makes MPLS a suitable convergence technology. Leaving empotions aside, may I ask how do you envision an MPLS-only (without IP) network for 2547 services? E.g., how would it provide PE-to-PE full mesh connectivity? I also am not sure (but I may be wrong, of course) to what exactly do you refer as the "GMPLS data plane". E.g., if GMPLS is used to set up SONET/SDH trails? Regards, Sasha -----Original Message----- From: benjamin.niven-jenkins@bt.com To: pwe3@ietf.org Cc: neil.2.harrison@bt.com Sent: 10/5/2004 2:40 PM Subject: RE: [PWE3] RSVP-TE and PW Sasha et al, Please see below... > A signalling protocol is a signalling protocol is a signalling > protocol....some are better functionally specified than > others, ie there > are only so many ways to do this function (just like OAM if you also > recall that 'discussion' ;-)). Of course, the message set is a little > different for the co-ps mode and the co-cs mode (largely due > to the fact > that the link-connection IDs are abstract in the co-ps mode and > real/physical in the co-cs mode).....but things like taking the > signalling (and management-plane) protocols logically OOB wrt to the > traffic ought to be a key requirement for both modes (simply from the > enhanced security and stability considerations of a best-of breed > solution here). However, this is not perhaps something that obviously > springs to mind for folks used to only dealing with the cl-ps mode. > > [Sasha] One point that seems to me to be missing is the implicit > [Sasha] assumption that co-ps networks work all by > themselves. This may be > [Sasha] correct for some of them (e.g., FR) but, IMO, this is > de-facto > [Sasha] incorrect for MPLS (even if you treat it as a co-ps network), > [Sasha] since it (again, de-facto) exists side-by-side with > IP and hence > [Sasha] uses IP (and only IP!) in all its signaling protocols. > [Sasha] To be more specific, most devices I'm aware of can treat MPLS > [Sasha] as an add-on capability on their IP interfaces. > [Sasha] One can argue that this is good or bad architecturally, > [Sasha] but this is more or less the reality, and trying to change > [Sasha] it (if you believe it is bad) would be very expensive. > [Sasha] And it will become even more expensive as various IP-based > [Sasha] things (like LSP ping) become deployed... > [Sasha] At the same time, IMHO, as long as this situation > goes on, there > [Sasha] is no real justification for OOB (or, to be more specific, > [Sasha] OOB-only). > [Sasha] My 2c. > [Sasha] signaling for MPLS. I agree that IP and MPLS share an incestuous relationship. However just because IP & MPLS exist side-by-side does not mean that OOB control is not required/justified. For example in a standalone MPLS 2547 VPN deployment (i.e. where a provider has built a MPLS network that is used solely to provide 2547 VPNs and nothing else) the IP network is basically just used to control the MPLS network then there is no reason to mandate that the control plane layer network (i.e. IP) has to be inband with the data plane layer network (i.e. MPLS). IMO the incestuous relationship between IP & MPLS is irrelevant, the reason that it is/would be expensive at the present time to take the control plane OOB is because of the implicit assumption that the control plane is always carried inband (and the amount of kludges/protocols that rely on this assumption). What we need to start doing is recognising that service providers see a need for OOB control and start moving towards that goal, rather than just carrying on as in the past because it is the path of least resistance. One final point - the GMPLS folks seem to have managed to get IP (as a control plane) and GMPLS (as a data plane) decoupled. Given the similarity between MPLS & GMPLS it would not appear to me to be a insurmountable task to get an OOB control plane for MPLS (or any co-ps layer network). Ben _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 14:29:25 +0100 Lines: 33 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: quoted-printable Cc: neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Tue Oct 05 15:34:59 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSq3GHbqD+77fY5TnqBGOOuWoC1LgAAX6dg To: , X-OriginalArrivalTime: 05 Oct 2004 13:29:25.0409 (UTC) FILETIME=[5505D110:01C4AADF] X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Sasha, > Leaving empotions aside, may I ask how do you envision an MPLS-only=20 > (without IP) network for 2547 services? E.g., how would it=20 > provide PE-to-PE > full mesh connectivity?=20 I think you misunderstand my point (or I did not explain it well = enough). In a MPLS-only 2547 network then MPLS is used purely for = forwarding customer packets (i.e. MPLS is the data plane) and IP is used = purely for carrying control/management traffic for the provider (i.e. IP = is the control plane). AFAIK this is how MPLS 2547 works, it's just = that the distinction is not explicitly stated anywhere. Taking the = control plane OOB does not mean that IP is no longer required, just that = the IP layer network does not have to operate in band with respect to = the MPLS layer network. Similarly in GMPLS you have the control plane = OOB wrt the data plane but IP is still required. =20 The difference is that the OOB IP control plane is forced upon you in = GMPLS because of the nature of transparent optical networks, what I am = saying is that I don't any major difference in this respect betwen MPLS = & GMPLS except in GMPLS you are forced to support OOB and in MPLS you = have the choice of OOB or inband. > I also am not sure (but I may be wrong, of course) to what exactly do > you refer as the "GMPLS data plane". E.g., if GMPLS is used to > set up SONET/SDH trails?=20 The GMPLS data plane consists of the end-end trails set up by the GMPLS = control plane that are used to transport bits end-end (i.e. they are the = SONET/SDH trails for TSC, Lambdas for LSC etc.). Ben From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 16:01:10 +0200 Lines: 59 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'neil.2.harrison@bt.com '" X-From: pwe3-bounces@ietf.org Tue Oct 05 16:18:02 2004 Return-path: To: "'benjamin.niven-jenkins@bt.com '" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Ben, Sorry to say, I still do not understand. If you have and MPLS network that does not run inband IP, how do you provide connectivity between the PEs? By running something like GMPLS and associated CSPF-TE in the OOB control network? Would you also deploy dedicated BGP-MP RRs in this OOB control network for making BGP-based label distribution scalable? What else? And all this for just removing IP as the control plane from the network that carries (private) IP in the data plane? If anything, this approach looks to me like the direct opposite of the network convergence paradigm. Regards, Sasha -----Original Message----- From: benjamin.niven-jenkins@bt.com To: Sasha Vainshtein; pwe3@ietf.org Cc: neil.2.harrison@bt.com Sent: 10/5/2004 3:29 PM Subject: RE: [PWE3] RSVP-TE and PW Sasha, > Leaving empotions aside, may I ask how do you envision an MPLS-only > (without IP) network for 2547 services? E.g., how would it > provide PE-to-PE > full mesh connectivity? I think you misunderstand my point (or I did not explain it well enough). In a MPLS-only 2547 network then MPLS is used purely for forwarding customer packets (i.e. MPLS is the data plane) and IP is used purely for carrying control/management traffic for the provider (i.e. IP is the control plane). AFAIK this is how MPLS 2547 works, it's just that the distinction is not explicitly stated anywhere. Taking the control plane OOB does not mean that IP is no longer required, just that the IP layer network does not have to operate in band with respect to the MPLS layer network. Similarly in GMPLS you have the control plane OOB wrt the data plane but IP is still required. The difference is that the OOB IP control plane is forced upon you in GMPLS because of the nature of transparent optical networks, what I am saying is that I don't any major difference in this respect betwen MPLS & GMPLS except in GMPLS you are forced to support OOB and in MPLS you have the choice of OOB or inband. > I also am not sure (but I may be wrong, of course) to what exactly do > you refer as the "GMPLS data plane". E.g., if GMPLS is used to > set up SONET/SDH trails? The GMPLS data plane consists of the end-end trails set up by the GMPLS control plane that are used to transport bits end-end (i.e. they are the SONET/SDH trails for TSC, Lambdas for LSC etc.). Ben From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 15:19:38 +0100 Lines: 94 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: quoted-printable Cc: neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Tue Oct 05 16:27:04 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSq5JOqimwJpoP8Qiu1+seD5TA0hAAAE5Vw To: , X-OriginalArrivalTime: 05 Oct 2004 14:19:39.0317 (UTC) FILETIME=[5973AE50:01C4AAE6] X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Sasha, I'm not sure how else to explain it. I was only trying to use MPLS 2547 = as *an example* to demonstrate that a service provider could/may want to = deploy an MPLS based service where IP is only used for = control/management but I obviously managed to make the situation less = clear. =20 In my example I assume that we are talking about a MPLS layer that is = co-ps and therefore the PE-PE LSPs would be signalled using a co-ps = signalling protocol (i.e. RSVP-TE). Forget about specific applications/services - the point I am trying (and = failing) to emphasise is that just because MPLS requires IP for its = control plane does not automatically lead to a justification for the IP = control plane to be carried inband wrt the MPLS data plane. Ben > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: 05 October 2004 15:01 > To: Niven-jenkins,B,Ben,XGH5 R; 'pwe3@ietf.org ' > Cc: Harrison,N,Neil,IKR2 R > Subject: RE: [PWE3] RSVP-TE and PW=20 >=20 >=20 > Ben, > Sorry to say, I still do not understand. > If you have and MPLS network that does not run inband IP, > how do you provide connectivity between the PEs?=20 > By running something like GMPLS and associated CSPF-TE in=20 > the OOB control network?=20 >=20 > Would you also deploy dedicated BGP-MP RRs in this OOB > control network for making BGP-based label distribution scalable? > What else? >=20 > And all this for just removing IP as the control plane from the > network that carries (private) IP in the data plane? >=20 > If anything, this approach looks to me like the direct opposite of the > network convergence paradigm. >=20 > Regards, > Sasha > -----Original Message----- > From: benjamin.niven-jenkins@bt.com > To: Sasha Vainshtein; pwe3@ietf.org > Cc: neil.2.harrison@bt.com > Sent: 10/5/2004 3:29 PM > Subject: RE: [PWE3] RSVP-TE and PW=20 >=20 > Sasha, >=20 > > Leaving empotions aside, may I ask how do you envision an MPLS-only=20 > > (without IP) network for 2547 services? E.g., how would it=20 > > provide PE-to-PE > > full mesh connectivity?=20 >=20 > I think you misunderstand my point (or I did not explain it well > enough). In a MPLS-only 2547 network then MPLS is used purely for > forwarding customer packets (i.e. MPLS is the data plane) and=20 > IP is used > purely for carrying control/management traffic for the=20 > provider (i.e. IP > is the control plane). AFAIK this is how MPLS 2547 works, it's just > that the distinction is not explicitly stated anywhere. Taking the > control plane OOB does not mean that IP is no longer=20 > required, just that > the IP layer network does not have to operate in band with respect to > the MPLS layer network. Similarly in GMPLS you have the control plane > OOB wrt the data plane but IP is still required. =20 >=20 > The difference is that the OOB IP control plane is forced upon you in > GMPLS because of the nature of transparent optical networks, what I am > saying is that I don't any major difference in this respect=20 > betwen MPLS > & GMPLS except in GMPLS you are forced to support OOB and in MPLS you > have the choice of OOB or inband. >=20 > > I also am not sure (but I may be wrong, of course) to what=20 > exactly do > > you refer as the "GMPLS data plane". E.g., if GMPLS is used to > > set up SONET/SDH trails?=20 >=20 > The GMPLS data plane consists of the end-end trails set up by=20 > the GMPLS > control plane that are used to transport bits end-end (i.e.=20 > they are the > SONET/SDH trails for TSC, Lambdas for LSC etc.). >=20 > Ben >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 15:37:21 +0100 Lines: 23 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Tue Oct 05 16:48:05 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSq5JWCDrylB60mQIKqUhU7m0ERKgAAafDA To: , , X-OriginalArrivalTime: 05 Oct 2004 14:37:25.0537 (UTC) FILETIME=[D4F7F110:01C4AAE8] X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Sasha, we do fully understand the points you have made......but you may have to trust me on that one. =20 > If anything, this approach looks to me like the direct > opposite of the network convergence paradigm. NH=3D> That maybe because you have not seen further than what is here = and now.....there are alternative ways of doing things that do have convergence (but not maybe as you think of it) as a central theme. However, it is not appropriate, nor am I at liberty, to fully discuss these topics here. However, as a hint, the really big problem facing operators is all about the fundamental economics of networking, ie the large build/run costs of networks vs the small costs of usage. Having the right network arch is an enabler to this bigger commercial problem. Have a look at this paper which describes the problem (but not the solutions): "Pricing and architecture of the Internet: Historical perspectives from telecommunications and transportation", A. M. Odlyzko. A copy can be found at http://www.dtc.umn.edu/~odlyzko/doc/networks.html regards, Neil=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 16:34:11 +0200 Lines: 35 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-bounces@ietf.org Tue Oct 05 16:49:49 2004 Return-path: To: "'neil.2.harrison@bt.com '" , "'benjamin.niven-jenkins@bt.com '" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Neil, Thank you for a prompt response and an interesting reference. I'll look it up. Regards, Sasha -----Original Message----- From: neil.2.harrison@bt.com To: Sasha Vainshtein; benjamin.niven-jenkins@bt.com; pwe3@ietf.org Sent: 10/5/2004 4:37 PM Subject: RE: [PWE3] RSVP-TE and PW Hi Sasha, we do fully understand the points you have made......but you may have to trust me on that one. > If anything, this approach looks to me like the direct > opposite of the network convergence paradigm. NH=> That maybe because you have not seen further than what is here and now.....there are alternative ways of doing things that do have convergence (but not maybe as you think of it) as a central theme. However, it is not appropriate, nor am I at liberty, to fully discuss these topics here. However, as a hint, the really big problem facing operators is all about the fundamental economics of networking, ie the large build/run costs of networks vs the small costs of usage. Having the right network arch is an enabler to this bigger commercial problem. Have a look at this paper which describes the problem (but not the solutions): "Pricing and architecture of the Internet: Historical perspectives from telecommunications and transportation", A. M. Odlyzko. A copy can be found at http://www.dtc.umn.edu/~odlyzko/doc/networks.html regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: RSVP-TE and PW Date: Tue, 05 Oct 2004 10:46:19 -0400 Lines: 11 Sender: pwe3-bounces@ietf.org References: <0536FC9B908BEC4597EE721BE6A353890A9F12A8@i2km07-ukbr.domain1.systemhost.net> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: tnadeau@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Tue Oct 05 16:59:08 2004 Return-path: X-BrightmailFiltered: true To: neil.2.harrison@bt.com In-reply-to: Your message of Tue, 05 Oct 2004 10:36:33 +0100. <0536FC9B908BEC4597EE721BE6A353890A9F12A8@i2km07-ukbr.domain1.systemhost.net> 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) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > if you also re-read Eric's last mail (04 October 2004 18:41) he is also > reinforcing the point we in BT have been making from the outset here, ie > PW switching will create a new layer network No, I was saying that Peter's message seemed to presuppose that model, but a. I didn't see the justification for it, and b. I don't see explicit routing as either necessary or sufficient to support that model. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Chris Chase Subject: Re: RSVP-TE and PW Date: Tue, 05 Oct 2004 10:49:14 -0400 Lines: 244 Sender: pwe3-bounces@ietf.org References: <31E5653D-16C3-11D9-9F92-000D93AD480A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3 X-From: pwe3-bounces@ietf.org Tue Oct 05 16:59:58 2004 Return-path: User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en To: "Thomas D. Nadeau" In-Reply-To: <31E5653D-16C3-11D9-9F92-000D93AD480A@cisco.com> X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Tom, I know that this has probably been dicussed before, but I don't keep up with the list. Is there a concern about how many simultaneous LDP sessions can run on a PE? I know of TCP/IP stacks and vendors that have problems with getting more than one or two thousand BGP sessions running on their routers and it often has to do with limits in their TCP/IP stacks (e.g., file descriptor length limits, inefficient poll or select). With LDP for PW signaling we can be adding on the order of 500 sessions easily. Looking at a very large FR/ATM network I know and giving you rough numbers: there are almost 500 remote terminating nodes for some switches. In fact, there are hundreds of switches that have several hundred remote node terminations (over a hundred have more than 400 remote node terminations). Is not this one area where RSVP for PW signaling has an advantage? Chris Chase On 10/5/2004 7:39 AM, Thomas D. Nadeau wrote: >On Oct 4, 2004, at 6:19 PM, Busschbach, Peter B (Peter) wrote: > > > >>Tom, >> >>I currently have problems with email access and lack of time to answer >>email. Therefore, I am not yet able to respond to other emails on this >>topict. However, I can't let this one go unchallenged. >> >>I am not having the CR-LDP vs RSVP-TE debate again. It has been >>decided. The answer is RSVP-TE. Did you see me propose CR-LDP?? >> >> > > I didn't mean literally; rather, the flavor of the arguments >are the same as were provided before during the old debates. > > > >>Just to be clear: I personally don't see any reason why you would use >>RSVP-TE for the existing PW architecture that consists of single-hop >>PWs over end-to-end PSN tunnels between PEs. >> >>My previous email was based on the premise that perhaps, at some point >>in the future, we may find that the current PW architecture does not >>scale well and that enhanced solutions are needed. >> >>Going back in time: RIP was a protocol "well understood, deployed in >>real code". According to your logic, we should never have developed >>OSPF and IS-IS. >> >> > > Not exactly. In that case there are clear advantages >over RIP in OSPF or IS-IS. In this case, it is not clear >what if any advantages there are for using RSVP-TE over >LDP for signaling PWs. > > --Tom > > > > >>Peter >> >> >> >>>-----Original Message----- >>>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>Sent: Monday, October 04, 2004 1:56 PM >>>To: Benny Ammitzboll >>>Cc: erosen@cisco.com; pwe3; Stewart Bryant >>Subject: Re: [PWE3] RSVP-TE and PW >>> >>> >>> >>> There seems little logical relevance as to whether >>>you should use one protocol or the other because you have >>>already implemented one or the other. The fact is >>>that if you are building an LSR (or enhancing an >>>existing one), you should be building in both RSVP-TE and LDP anyway >>>(or have both there already). To me, the most >>>germane point is what Eric said earlier -- LDP signaling >>>for PWs already is well understood, deployed in real >>>code and solves what seems to be the same problems solved by >>>an RSVP-TE-based approach. Call me cynical, but it seems >>>that this argument really boils down to is the old RSVP-TE >>>vs. CR-LDP argument (again) -- both protocols solve the >>>same problems, with the majority implementing/deploying >>>one approach, while the other approach is pushed by a small >>>number of vendors or vendor who seem to be motivated solely by >>>their marketing departments to hold out for their >>>'alternate' approach based on purported technical >>>superiority. >>> >>> --Tom >>> >>> >>> >>> >>> >>>>May I add that if you already have RSVP-TE to set up your >>>> >>>> >>>TE tunnels >>> >>> >>>>there >>>>seems to be little advantage in implementing yet another >>>> >>>> >>>protocol to >>> >>> >>>>carry >>>>the same kind of objects from one endpoint to another. >>>> >>>>Therefore I find the question raised by Diego relevant - >>>> >>>> >>>although it is >>> >>> >>>>probably too late. >>>> >>>>/Benny >>>> >>>> >>>>-----Original Message----- >>>>From: pwe3-bounces@ietf.org >>>> >>>> >>>[mailto:pwe3-bounces@ietf.org]On Behalf Of >>> >>> >>>>Eric Rosen >>>>Sent: 29. september 2004 15:27 >>>>To: Diego Caviglia >>>>Cc: pwe3; Stewart Bryant >>>Subject: Re: [PWE3] RSVP-TE and PW >>>> >>>> >>>> >>>> >>>> >>>>>given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS) >>>>> >>>>> >>>>The "some advantage" is not relevant in this context. >>>> >>>>The network layer tunnels through which the PWs flow may have >>>>QoS. The >>>>attachment circuits which are connected to each other via a PW may >>>>have QoS. >>>>But I don't think there is any notion of QoS which is >>>> >>>> >>>specific to >>> >>> >>>>the PW >>>>itself, rather than to the network layer or the attachment circuits. >>>> >>>>Therefore, any QoS parameter carried in the PW setup >>>> >>>> >>>protocol would >>> >>> >>>>really >>>>be just an opaque object to that protocol. A PW endpoint >>>> >>>> >>>might want >>> >>> >>>>to pass >>>>this object to the network layer, saying in effect "put this PW >>>>through a >>>>tunnel that has this QoS". A PW endpoint might want to pass this >>>>object to >>>>the NSP layer, saying in effect "set up the attachment circuit >>>>according to >>>>these QoS parameters". But the PW setup protocol doesn't >>>>actually do >>>>anything itself with the QoS parameter, other than to carry it >>>>around and >>>>pass it off. The only QoS requirement for the PW signaling >>>> >>>> >>>protocol >>> >>> >>>>is that >>>>it be able to carry an opaque QoS object from one endpoint to >>>>another. >>>>RSVP-TE has no advantage over LDP with respect to the >>>> >>>> >>>carrying of >>> >>> >>>>objects >>>>from one endpoint to another. >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>pwe3 mailing list >>>>pwe3@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>> >>>> >>>> >>>>_______________________________________________ >>>>pwe3 mailing list >>>>pwe3@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/pwe3 >>>> >>>> >>>> >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: RSVP-TE and PW Date: Tue, 05 Oct 2004 10:50:25 -0400 Lines: 20 Sender: pwe3-bounces@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Oct 05 17:03:00 2004 Return-path: X-BrightmailFiltered: true To: "Diego Caviglia" In-reply-to: Your message of Tue, 05 Oct 2004 08:54:34 +0200. 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) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This thread is getting a bit repetitive, I'll try to avoid repeating my opinions on issues that I've already tried to address. Diego raises a new issue though: > LDP doesn't have mp2p Did you mean p2mp? In either case, it's far from clear what a multipoint PW would be, we haven't actually defined any such concept. (The PWs we've defined are bidirectional.) The closest thing to a p2mp PW that we have is the VPLS service, which already has two non-interoperable signaling protocols and probably doesn't need a third. Without more discussion of just what a multipoint PW is, it's hard to say whether we need to have such things, or just what the signaling protocol for it should be. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Diego Caviglia" Subject: Re: RSVP-TE and PW Date: Tue, 5 Oct 2004 18:03:53 +0200 Lines: 58 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3 X-From: pwe3-bounces@ietf.org Tue Oct 05 18:24:28 2004 Return-path: To: erosen@cisco.com X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 05/10/2004 17:03:46 X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Eric, first of all let me say thanks to you and to all the other guys involved in thuis thread, as I said in my first e-mail I'm pretty new to this stuff. Other stuff in-line. Diego Eric Rosen on 05/10/2004 16.50.25 Please respond to erosen@cisco.com From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Monique Morrow \(mmorrow\)" Subject: "Inter-Provider Service Quality on the Internet": IEEE Comm. Mag. CFP Date: Tue, 5 Oct 2004 20:39:24 +0200 Lines: 512 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1038191194==" Cc: Loa Andersson , "Tom Nadeau \(tnadeau\)" , Vishal Sharma X-From: pwe3-bounces@ietf.org Tue Oct 05 20:55:37 2004 Return-path: X-BrightmailFiltered: true X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Thread-Topic: "Inter-Provider Service Quality on the Internet": IEEE Comm. Mag. CFP Thread-Index: AcSrCqMKIa4HgXr3Txe66pghaFvF2A== To: X-OriginalArrivalTime: 05 Oct 2004 18:39:25.0456 (UTC) FILETIME=[A383C100:01C4AB0A] X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1038191194== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AB0A.A33BD982" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4AB0A.A33BD982 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Folks, The IEEE Communications Magazine has just approved the publication of a Feature Topic issue on "Challenges in Enabling Inter-Provider Service Quality on the Internet." The CFP is attached below. We invite those working in this area to consider sending in their contributions. If you intend to submit a paper for this special issue, please do drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your participation! Regards, Monique =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "Challenges in Enabling Inter-Provider Service Quality on the Internet" ************************************************************************ ******************************************** As carriers and service providers build multi-services networks based on IP/MPLS-enabled infrastructures that are able to meet evermore stringent service level agreements (SLAs) and quality-of-service (QoS) requirements, it becomes a key issue to extend the ability to deliver these services across carrier and service provider domain boundaries, while at the same time preserving the same SLAs and QoS assurances as those provided within a given provider's network. The advent of new end-user applications, as well as new services based on MPLS technology, such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs), also means the emergence of added service quality requirements from operators deploying and interoperating these networks and the end-users themselves. As a result, providers and vendors require efficient means to enable inter-provider service quality, which comprises of several key elements including quality of service, class of service, security, OAM, and restoration and repair. This will is lead to the emergence of improved or novel tools and techniques to address these aspects, with the goal of guaranteeing service quality end-to-end,improving security and billing/accounting, and reducing operating costs. Standards organizations such as the IETF and the ITU are taking on significant work in this area, and various aspects of this subject are also being investigated by bodies such as the OIF, the MSF, the MPLS/Frame Relay Alliance, the IEEE, and the Metro Ethernet Forum, and are the themes for numerous upcoming conferences. This feature topic issue of the IEEE Communications Magazine has a multi-pronged focus on the delivery of inter-provider service quality: * Highlight operator and end-user concerns and requirements. * Feature current and/or planned deployment experiences. * Survey modern research and engineering developments. * Spotlight contemporary standards activity. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but certainly not limited to) the following topics: * Carrier requirements for efficient inter-provider service quality: Current operational needs, bottlenecks, future demands * Deployment experience with inter-provider service quality on IP/MPLS- based networks: comparative analysis, case studies * QoS management in an inter-provider environment: interconnection architectures using MPLS, Diffserv, QoS performance, path characterization, routing policies * Service assurance in inter-provider infrastructures: End-to-end SLA management, service billing/reporting, admission control * Failure and restoration requirements/challenges in inter-provider contexts * Interoperability and inter-working of diverse equipment types and technologies (ATM, FR, Ethernet) * Current engineering and research developments: E.g. Passive and active performance measurement and monitoring, TE, modelling and simulation * Standards activities and initiatives: new services and network architectures On-line CFP with submission instructions can be found at: http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.htm =20 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 there is consent of the Guest Editor;more than three equations require permission from the Editor-in-Chief).=20 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 30 October 2004.** Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due: 30 October 2004 Acceptance Notification: 15 January 2004 Final Manuscript Due: 28 February 2005 Publication Date: June 2005 Guest Editors Monique J. Morrow, Cisco Systems, (mmorrow@cisco.com) Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Thomas D.Nadeau, Cisco Systems (tnadeau@cisco.com) Loa Andersson, Acreo (loa@pi.se) =20 =20 =20 ------_=_NextPart_001_01C4AB0A.A33BD982 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
Folks,

The IEEE Communications Magazine has just = approved=20 the publication of

a Feature Topic issue on "Challenges in = Enabling=20 Inter-Provider Service Quality = on the=20 Internet." The CFP is attached=20 below.

We invite those working in this = area to=20 consider sending in = their contributions. If you intend to submit a = paper for=20 this

special issue, please do drop one = of the Guest=20 Editors a note, so that we can plan the issue.

We look forward to your = participation!

Regards, = Monique

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

CALL FOR PAPERS

IEEE Communications Magazine

Feature Topic on=20 "Challenges in Enabling = Inter-Provider Service Quality on the Internet"

****************************************************************= ****************************************************

As carriers and service providers build=20 multi-services networks based on

IP/MPLS-enabled=20 infrastructures that are able to meet evermore stringent = service

level=20 agreements (SLAs) and=20 quality-of-service (QoS) requirements, it becomes a

key=20 issue to extend the = ability to=20 deliver these services across carrier and

service=20 provider domain = boundaries, while=20 at the same time preserving the same SLAs

and=20 QoS assurances as those = provided=20 within a given provider's network.

The advent of new end-user = applications, as=20 well as new services based on=20 MPLS technology, such = as Layer 2=20 Virtual Private LAN Services (VPLS) and

Layer 3 Virtual Private Networks = (L3VPNs), also=20 means the emergence of = added service quality

requirements from operators = deploying and=20 interoperating these networks and = the end-users=20 themselves. As a result, providers and vendors require = efficient

means to=20 enable inter-provider service quality, which comprises of several = key elements including=20 quality of service, class of service, security, OAM, and

restoration and=20 repair.

This will is lead to the emergence = of improved=20 or novel tools and techniques=20 to address these = aspects, with the=20 goal of guaranteeing service quality

end-to-end,improving=20 security and billing/accounting, and reducing operating = costs.

Standards=20 organizations such as the IETF and the ITU are taking on = significant work=20 in this

area, and various aspects of this = subject are=20 also being investigated by=20 bodies such

as the OIF, the MSF, the MPLS/Frame = Relay=20 Alliance, the IEEE, and the Metro=20 Ethernet Forum, and are = the themes=20 for numerous upcoming conferences.

This feature topic issue of the = IEEE=20 Communications Magazine has a=20 multi-pronged

focus on the delivery of inter-provider = service=20 quality:

* Highlight operator and end-user = concerns and=20 requirements.

* Feature current and/or planned = deployment=20 experiences.

* Survey modern research and engineering=20 developments.

* Spotlight contemporary standards=20 activity.

Thus, focused tutorial and survey = contributions=20 as well as research papers=20 are

solicited on (but certainly not limited = to) the=20 following topics:

* Carrier requirements for efficient = inter-provider=20 service quality: Current

operational needs, bottlenecks, future=20 demands

* Deployment experience with = inter-provider service=20 quality on IP/MPLS-

based networks: comparative analysis, = case=20 studies

* QoS management in an inter-provider = environment:=20 interconnection

architectures using MPLS, Diffserv, QoS = performance,=20 path

characterization, routing = policies

* Service assurance in inter-provider=20 infrastructures: End-to-end SLA

management, service billing/reporting, = admission=20 control

* Failure and restoration = requirements/challenges in=20 inter-provider contexts

* Interoperability and inter-working of = diverse=20 equipment types and

technologies (ATM, FR, = Ethernet)

* Current engineering and research = developments: E.g.=20 Passive and active

performance measurement and monitoring, = TE, modelling=20 and simulation

* Standards activities and initiatives: = new services=20 and network

architectures

On-line CFP with submission instructions = can be found=20 at:

http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.htm=

Submission

Articles should be tutorial in nature and = should be=20 written in a style

comprehensible

to readers outside the specialty of the = article.=20 Articles may be edited for

clarity and grammatical accuracy, and = will be=20 copyedited according to the

Magazine's style.

Mathematical equations should not = be used (in=20 justified cases up to three=20 simple

equations could be allowed, provided = there is consent=20 of the Guest Editor;more = than

three equations require permission from = the=20 Editor-in-Chief).

Articles should have no=20 more than 4,500 words, no more than 6 tables/figures, and = no more=20 than 15

references. Guidelines for prospective = authors can be=20 found on-line at

http://www.comsoc.org/pubs/commag/sub_guidelines.html= .

** Please submit no later than 30 October = 2004.**

Accepted papers will also be included in=20 Communications

Interactive (CI), the online version of=20 Communications Magazine.

Manuscript Due: 30 October = 2004

Acceptance Notification: 15 January = 2004

Final Manuscript Due: 28 February = 2005

Publication Date: June 2005

Guest Editors

Monique J. Morrow, Cisco Systems,=20 (mmorrow@cisco.com)

Vishal Sharma, Metanoia, Inc.=20 (v.sharma@ieee.org)

Thomas D.Nadeau, Cisco Systems=20 (tnadeau@cisco.com)

Loa Andersson, Acreo = (loa@pi.se)

 

 
 
------_=_NextPart_001_01C4AB0A.A33BD982-- --===============1038191194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1038191194==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Tue, 5 Oct 2004 18:11:05 -0400 Lines: 100 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3 X-From: pwe3-bounces@ietf.org Wed Oct 06 00:23:12 2004 Return-path: To: "'Diego Caviglia'" , erosen@cisco.com X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Diego, Eric, Regarding p2mp PWs: There are concerns that in VPLS or HVPLS solutions, the number of MAC entries in the (N-)PE could become excessively large. Therefore, it could make sense to move to a DVPLS model (as described in draft-ietf-l2vpn-signaling-02.txt, section 3.5). In this model, the link between U-PE and N-PE carries all PWs that originate in the U-PE. Therefore, multicast or broadcast packets would be replicated multiple times on the same link. However, since the link may have limited bandwidth, this replication of identical packets might cause concerns. Hence, it could make sense to have some form of p2mp PWs, where the N-PE splits the traffic coming from the U-PE onto multiple branches. Note that the GVPLS solution (draft-radoaca-ppvpn-gvpls-02.txt (I couldn't find a newer draft)) supports such a broadcast/multicast feature. This is not a true example of p2mp PWs, but it illustrates the idea. Peter > -----Original Message----- > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > Sent: Tuesday, October 05, 2004 12:04 PM > To: erosen@cisco.com > Cc: pwe3 > Subject: Re: [PWE3] RSVP-TE and PW > > > > Hi Eric, > first of all let me say thanks to you and to all the > other guys involved in thuis thread, as I said in my first e-mail I'm > pretty new to this stuff. > > Other stuff in-line. > > Diego > > > > Eric Rosen on 05/10/2004 16.50.25 > > Please respond to erosen@cisco.com > > To: "Diego Caviglia" > cc: pwe3@ietf.org > > Subject: Re: [PWE3] RSVP-TE and PW > > > > This thread is getting a bit repetitive, I'll try to > avoid repeating > my > opinions on issues that I've already tried to address. > Diego raises a > new > issue though: > > > LDP doesn't have mp2p > > Did you mean p2mp? > [dc] Yes it was a typo. > > In either case, it's far from clear what a multipoint PW > would be, > we > haven't actually defined any such concept. (The PWs > we've defined > are > bidirectional.) > [dc] Ok so you think that p2mp (and unidirectional PW) could > be something > that will be addressed by PWE3 WG in the future? > > > The closest thing to a p2mp PW that we have is the VPLS service, > which > already has two non-interoperable signaling protocols and probably > doesn't > need a third. > [dc] Yes but in VPLS you have to split traffic at the PE that > may be is not > the best place to do that. > > Without more discussion of just what a multipoint PW is, > it's hard to > say > whether we need to have such things, or just what the > signaling protocol > for > it should be. > [dc] I agree I was trying to understand if it something > interested in p2mp > PW. > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Rahul Aggarwal Subject: RE: p2mp PWs (was RSVP-TE and PW) Date: Tue, 5 Oct 2004 15:34:50 -0700 (PDT) Lines: 120 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: erosen@cisco.com, pwe3 X-From: pwe3-bounces@ietf.org Wed Oct 06 00:48:13 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: "Busschbach, Peter B (Peter)" In-Reply-To: X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Peter, On Tue, 5 Oct 2004, Busschbach, Peter B (Peter) wrote: > Diego, Eric, > > Regarding p2mp PWs: > > There are concerns that in VPLS or HVPLS solutions, the number of MAC entries in the (N-)PE could become excessively large. Therefore, it could make sense to move to a DVPLS model (as described in draft-ietf-l2vpn-signaling-02.txt, section 3.5). > > In this model, the link between U-PE and N-PE carries all PWs that originate in the U-PE. Therefore, multicast or broadcast packets would be replicated multiple times on the same link. However, since the link may have limited bandwidth, this replication of identical packets might cause concerns. Hence, it could make sense to have some form of p2mp PWs, where the N-PE splits the traffic coming from the U-PE onto multiple branches. > > Note that the GVPLS solution (draft-radoaca-ppvpn-gvpls-02.txt (I couldn't find a newer draft)) supports such a broadcast/multicast feature. This is not a true example of p2mp PWs, but it illustrates the idea. > Also see the VPLS multicast solution in the following draft. In principle the solution builds P2MP PWs for VPLS. http://www.ietf.org/internet-drafts/draft-raggarwa-l3vpn-mvpn-vpls-mcast-00.txt rahul > Peter > > > -----Original Message----- > > From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com] > > Sent: Tuesday, October 05, 2004 12:04 PM > > To: erosen@cisco.com > > Cc: pwe3 > > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > > Hi Eric, > > first of all let me say thanks to you and to all the > > other guys involved in thuis thread, as I said in my first e-mail I'm > > pretty new to this stuff. > > > > Other stuff in-line. > > > > Diego > > > > > > > > Eric Rosen on 05/10/2004 16.50.25 > > > > Please respond to erosen@cisco.com > > > > To: "Diego Caviglia" > > cc: pwe3@ietf.org > > > > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > > This thread is getting a bit repetitive, I'll try to > > avoid repeating > > my > > opinions on issues that I've already tried to address. > > Diego raises a > > new > > issue though: > > > > > LDP doesn't have mp2p > > > > Did you mean p2mp? > > [dc] Yes it was a typo. > > > > In either case, it's far from clear what a multipoint PW > > would be, > > we > > haven't actually defined any such concept. (The PWs > > we've defined > > are > > bidirectional.) > > [dc] Ok so you think that p2mp (and unidirectional PW) could > > be something > > that will be addressed by PWE3 WG in the future? > > > > > > The closest thing to a p2mp PW that we have is the VPLS service, > > which > > already has two non-interoperable signaling protocols and probably > > doesn't > > need a third. > > [dc] Yes but in VPLS you have to split traffic at the PE that > > may be is not > > the best place to do that. > > > > Without more discussion of just what a multipoint PW is, > > it's hard to > > say > > whether we need to have such things, or just what the > > signaling protocol > > for > > it should be. > > [dc] I agree I was trying to understand if it something > > interested in p2mp > > PW. > > > > > > > > > > > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Adrian Farrel" Subject: Re: RSVP-TE and PW Date: Wed, 6 Oct 2004 00:34:33 +0100 Lines: 47 Sender: pwe3-bounces@ietf.org References: <449B2580D802A443A923DABF3EAB82AF07D9AA21@OCCLUST04EVS1.ugd.att.com> Reply-To: Adrian Farrel Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Wed Oct 06 01:57:35 2004 Return-path: To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi all, PMFJI. I try to whenever I see the G-word used. RSVP-TE is a control plane signaling technology used to install MPLS LSPs in packet switching networks. The "GMPLS data plane" is not a very useful term IMHO because GMPLS-RSVP-TE signaling can be used to install LSPs in a variety of network technologies. Popularly, this is considered to be limited to optical networks (lambda switching and TDM) but this is not the case. GMPLS signaling is fully applicable to a wide range (or hierarchy) of switching technology from (at the coarsest granularity) port switching, down through waveband and lambda switching, passed TDM and layer 2 switching, to MPLS packet switching (at the finest granularity). This last point is very important since it says that GMPLS signaling technology can be used to install LSPs in packet switched networks. Yet, GMPLS signaling (which is built upon RSVP-TE) includes some of the mechanisms described as necessary and missing. Not least among these is the ability to signal in control plane channels that are both logically and physically diverse from the data plane channels. But don't think that GMPLS signaling is some radical new signaling technique. It isn't. It is just a logical (some would say evolutionary) development of RSVP-TE. Thus, there is no need to talk about getting MPLS to do the same 'decoupling' as GMPLS has achieved. GMPLS *is* the decoupling that you want. GMPLS is worked on by the CCAMP working group who would, I'm sure, be happy to discuss your requirements and to suggest ways that GMPLS signaling could provide the functional support needed by PWE3. Cheers, Adrian Sasha... > I also am not sure (but I may be wrong, of course) to what exactly > do you refer as the "GMPLS data plane". E.g., if GMPLS is used to > set up SONET/SDH trails? Ben... > One final point - the GMPLS folks seem to have managed to get > IP (as a control plane) and GMPLS (as a data plane) decoupled. > Given the similarity between MPLS & GMPLS it would not appear > to me to be a insurmountable task to get an OOB control plane for > MPLS (or any co-ps layer network). From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: p2mp PWs (was RSVP-TE and PW) Date: Tue, 05 Oct 2004 21:55:49 -0400 Lines: 23 Sender: pwe3-bounces@ietf.org References: <20041005152629.A91072@sapphire.juniper.net> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "Busschbach, Peter B \(Peter\)" , pwe3 X-From: pwe3-bounces@ietf.org Wed Oct 06 03:59:02 2004 Return-path: X-BrightmailFiltered: true To: Rahul Aggarwal In-reply-to: Your message of Tue, 05 Oct 2004 15:34:50 -0700. <20041005152629.A91072@sapphire.juniper.net> 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) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > Also see the VPLS multicast solution in the following draft. In principle > the solution builds P2MP PWs for VPLS. And it does it without requiring the use of RSVP-TE ;-) Actually, all that it does is provide a way to use multicast distribution trees to carry IP multicast packets. The receiving PEs then process the packets as if the packets had arrived on the unicast PW from the transmitting PE. I don't think that's quite the same as a multipoint PW. (If you try to model the multicast distribution tree as a PW itself, you end up with a pair of ethernet switches connected by two different (pseudo)wires, with both of them unblocked -- I don't think there's any such entity.) The closest thing we have to a multipoint PW is the VPLS service itself, which is designed to produce the properties of a multipoint-to-multipoint wire. Is there actually a layer 2 service which provides unidirectional point-to-multipoint transmission? If we knew what we needed to do in order to emulate such a service, we'd know what the signaling requirements are for p2mp PWs. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: RSVP-TE and PW Date: Wed, 6 Oct 2004 08:33:27 +0100 Lines: 121 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Wed Oct 06 09:36:10 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSrN0sLYJiC8kjXRmGsPYC9+OzAgAAOQbvw To: , X-OriginalArrivalTime: 06 Oct 2004 07:33:28.0690 (UTC) FILETIME=[C5D6DD20:01C4AB76] X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Adrian....rather glad you 'PMFJI'd' on this topic.....some additional remarks below. > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Adrian Farrel > Sent: 06 October 2004 00:35 > To: pwe3@ietf.org > Subject: Re: [PWE3] RSVP-TE and PW=20 >=20 >=20 > Hi all, >=20 > PMFJI. I try to whenever I see the G-word used. >=20 > RSVP-TE is a control plane signaling technology used to=20 > install MPLS LSPs in packet switching networks. >=20 > The "GMPLS data plane" is not a very useful term IMHO because=20 > GMPLS-RSVP-TE signaling can be used to install LSPs in a=20 > variety of network technologies. NH=3D> I think it is actually rather important to be clear about the data-plane aspects......as there are some important diffences between the 3 modes. However, a key observation is that with co-cs mode technologies (like SDH and OTNs) the control and management protocols are forced to reside in their own co-cs network partition that is disjoint to the traffic's co-cs data-plane network. Now this has very significant implications across all the functional components of *each* data-plane.....and in particular the control/management protocols are likely to be using a cl-ps mode of operation in their network partition, but they act to set-up/take-down/manage co-cs trails in the traffic data-plane, ie there are 2 fundamentally different network designs operating in the same 'technology'. > Popularly, this is=20 > considered to be limited to optical networks (lambda=20 > switching and TDM) but this is not the case. GMPLS signaling=20 > is fully applicable to a wide range (or hierarchy) of=20 > switching technology from (at the coarsest granularity) port=20 > switching, down through waveband and lambda switching, passed=20 > TDM and layer 2 switching, to MPLS packet switching (at the=20 > finest granularity). >=20 > This last point is very important since it says that GMPLS=20 > signaling technology can be used to install LSPs in packet=20 > switched networks. NH=3D> I agree. I tried to make this same point in an earlier posting, = ie a similar control/management-plane design philosophy can be applied to the co-ps mode as the co-cs mode....and there are indeed some important benefits from doing so. There are, however, some key differences between the 2 modes in the traffic data-plane, eg the link-connection IDs are abstract in the co-ps mode but they must take on a time/space/freq semantic in the co-cs mode, there are no QoS classes in the co-cs mode (this is a *very* significant simplification), the defects are different (and so the OAM required is a little different), etc......however, I do agree with you that one can apply a very similar OOB design philosophy for the control/management-plane in the co-ps mode as one can (and is indeed forced to do) for the co-cs mode. >=20 > Yet, GMPLS signaling (which is built upon RSVP-TE) includes=20 > some of the mechanisms described as necessary and missing.=20 > Not least among these is the ability to signal in control=20 > plane channels that are both logically and physically diverse=20 > from the data plane channels. NH=3D> Its not just the control-plane protocol but also the management-plane protocols. This is an important observation (eg for security) and is something we are very keen to see adopted as a general principle in core co-cs and co-ps networks. >=20 > But don't think that GMPLS signaling is some radical new=20 > signaling technique. It isn't. It is just a logical (some=20 > would say evolutionary) development of RSVP-TE. NH=3D> Agreed. But the co-cs mode does force things like OOB. >=20 > Thus, there is no need to talk about getting MPLS to do the=20 > same 'decoupling' as GMPLS has achieved. GMPLS *is* the=20 > decoupling that you want. NH=3D> I can but agree....nice to hear someone else saying this! >=20 > GMPLS is worked on by the CCAMP working group who would, I'm=20 > sure, be happy to discuss your requirements and to suggest=20 > ways that GMPLS signaling could provide the functional=20 > support needed by PWE3. NH=3D> Yes please Adrian......but please note that the stuff I have been harping on about since as long as I can remember must also be considered, eg like the OAM is different in the 3 modes, like the client/server adaptation functions are not the same for all modal combinations, like there are no QoS/traffic classes in the co-cs modes, etc. Further, its not for fun that we are very strong advocates of functional modelling (ie the G.805/809 stuff for the data-plane and G.8080 for the control-plane), and it would be great if folks could try and understand/use this stuff more. regards, Neil >=20 > Cheers, > Adrian >=20 > Sasha... > > I also am not sure (but I may be wrong, of course) to what=20 > exactly do=20 > > you refer as the "GMPLS data plane". E.g., if GMPLS is used=20 > to set up=20 > > SONET/SDH trails? >=20 > Ben... > > One final point - the GMPLS folks seem to have managed to=20 > get IP (as a=20 > > control plane) and GMPLS (as a data plane) decoupled. Given the=20 > > similarity between MPLS & GMPLS it would not appear to me to be a=20 > > insurmountable task to get an OOB control plane for MPLS=20 > (or any co-ps=20 > > layer network). >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Rahul Aggarwal Subject: Re: p2mp PWs (was RSVP-TE and PW) Date: Wed, 6 Oct 2004 00:38:16 -0700 (PDT) Lines: 57 Sender: pwe3-bounces@ietf.org References: <200410060155.i961tnED009980@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Busschbach, Peter B \(Peter\)" , pwe3 X-From: pwe3-bounces@ietf.org Wed Oct 06 09:41:37 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: Eric Rosen In-Reply-To: <200410060155.i961tnED009980@rtp-core-2.cisco.com> X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Eric, On Tue, 5 Oct 2004, Eric Rosen wrote: > > > Also see the VPLS multicast solution in the following draft. In principle > > the solution builds P2MP PWs for VPLS. > > And it does it without requiring the use of RSVP-TE ;-) > > Actually, all that it does is provide a way to use multicast distribution > trees to carry IP multicast packets. And the same SP tree can carry IP multicast packets belonging to multiple VPLS instances. This is analogous to the same transport tunnel carrying packets for multiple L2 circuits. > The receiving PEs then process the > packets as if the packets had arrived on the unicast PW from the > transmitting PE. Not quite. The IP multicast packet carries an upstream label which is a different label from the one used by the unicast PW. The upstream label is in the context of the sender PE and assigned by the sender PE, while the unicast PW label is assigned by the receiver PE. > I don't think that's quite the same as a multipoint PW. Maybe its a matter of terminology. The above draft allows one multicast distribution tree to be used for carrying IP multicast packet from multiple VPLS instances. And I thought part of the discussion on this thread had to do with being able to achieve such a function. The term P2MP PW was used to describe such a function, though that may not be the best terminology. Thanks, rahul > (If you try to model the multicast distribution tree as a PW itself, you end > up with a pair of ethernet switches connected by two different > (pseudo)wires, with both of them unblocked -- I don't think there's any such > entity.) > > The closest thing we have to a multipoint PW is the VPLS service itself, > which is designed to produce the properties of a multipoint-to-multipoint > wire. > > Is there actually a layer 2 service which provides unidirectional > point-to-multipoint transmission? If we knew what we needed to do in order > to emulate such a service, we'd know what the signaling requirements are for > p2mp PWs. > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: RSVP-TE and PW Date: Wed, 6 Oct 2004 11:19:42 +0100 Lines: 17 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: neil.2.harrison@bt.com X-From: pwe3-bounces@ietf.org Wed Oct 06 12:27:25 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSrN0sLYJiC8kjXRmGsPYC9+OzAgAAOQbvwAAc4aKA= To: X-OriginalArrivalTime: 06 Oct 2004 10:19:42.0920 (UTC) FILETIME=[FEF19480:01C4AB8D] X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Folks, One last comment on this topic. > > Thus, there is no need to talk about getting MPLS to do the=20 > > same 'decoupling' as GMPLS has achieved. GMPLS *is* the=20 > > decoupling that you want. > NH=3D> I can but agree....nice to hear someone else saying this! Agreed. However the problem is IMO somewhat larger than just = MPLS/GMPLS. Folks need to start moving away from the 'IP-based mindset' = that leads to the assumption that control/management will be carried = inband (and therefore move away from producing fixes/features that rely = on that assumption). I would expect/hope all GMPLS folks understand = this, but I'm not so sure that all MPLS & PWE3 folks do. Ben From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: RSVP-TE and PW Date: Wed, 06 Oct 2004 09:46:10 -0600 Organization: Cisco Systems Lines: 257 Sender: pwe3-bounces@ietf.org References: <0536FC9B908BEC4597EE721BE6A353890A9F12A8@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: tnadeau@cisco.com, erosen@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Wed Oct 06 17:52:19 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F12A8@i2km07-ukbr.domain1.systemhost.net> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Neil, See inline. Also as a general comment I do not see this general thread going anywhere at this time , so I'm going to dedicate very little time to it. ( it's going round and round again and again ) Luca neil.2.harrison@bt.com wrote: >Tom...point taken. But if you also re-read Eric's last mail (04 October >2004 18:41) he is also reinforcing the point we in BT have been making >from the outset here, ie PW switching will create a new layer network >(though Eric is not explicitly expressing it like this)....so all the >functions any layer network requires (which vary dependent on the mode >considered) will require to be developed yet again. But for what >compelling reason? > > > Neil, I think the problem is the definition of a network. PW switching just connects wires 1 to 1 in a static mode. I see it as a wire extension. Now if you develop autoprovisioning for the switching points , with some other protocol, take BGP as an example, then you create an new layer network. This work maybe valid and useful but it needs to be added to the autodiscovery/autoprovisioning work in L2VPN. I do not see anything in the pw-switching draft that impedes this extension work from happening. >Now, without labouring the point too heavily (yet again) the cl-ps mode >is functionally not the same as the co-ps mode and neither is >functionally the same as the co-cs mode. So if you really want to point >the finger at where the root problem lies it is here. Once folks grok >that the so-called peer-model notion of 'functionally crunching' all the >modes from IP to optics is a broken idea the rest follows. > >It is also interesting to observe that some folks want RSVP-TE as *the* >prescriptive signalling protocol for the co-cs mode (eg SDH/OTN), and >note also it has to work OOB wrt to the traffic data-plane as this is >forced requirement of the co-cs mode......well, that may be so, but it >is not a logically forced choice for the signalling component once folks >grok the peer-model coulping idea is a broken idea. > >A signalling protocol is a signalling protocol is a signalling >protocol....some are better functionally specified than others, ie there >are only so many ways to do this function (just like OAM if you also >recall that 'discussion' ;-)). Of course, the message set is a little >different for the co-ps mode and the co-cs mode (largely due to the fact >that the link-connection IDs are abstract in the co-ps mode and >real/physical in the co-cs mode).....but things like taking the >signalling (and management-plane) protocols logically OOB wrt to the >traffic ought to be a key requirement for both modes (simply from the >enhanced security and stability considerations of a best-of breed >solution here). However, this is not perhaps something that obviously >springs to mind for folks used to only dealing with the cl-ps mode. > >The targeted spin of LDP signalling is more like a session protocol IMO, >ie it only conveys parameters between 2 fixed end-points and does not >flex connectivity between those 2 end-points. So whilst this remains >'the problem being addressed' this is fine. This is also very closely > > I agree. as I said above we need to solve the problem using what we have built so far. This is not something that PWE3 is chartered to solve , and most likely LDP is not the autodiscovery/provisioning protocol across administrative domains. >related to another point I have made many times in the past regarding >the nature of the PW entity itself, ie its an adaptation function >between 2 layer networks....with the additional spin that XoverIP is >somehow the same as XoverMPLS. This is clearly not true of course, but >it seems to keep some folks happy ;-) > >But if one now wants to flex connectivity you need the full range of >functions to make the PW entity a layer network, ie addressing, >discovery/route-calculation, signalling, OAM, etc. So I think the gripe >of those arguing for RSVP-TE here is that targeted LDP does not flex >connectivity....as its not a proper signalling protocol. However, our >gripe is that: >- we don't need yet another 'PW' layer network being >created....please just fix MPLS >- and please try and grok functional architecture and how this >applies to the 3 modes better so that errors-of-judgement like this >don't keep being made. > >regards, Neil > > > >>-----Original Message----- >>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >>Behalf Of Thomas D. Nadeau >>Sent: 04 October 2004 18:56 >>To: Benny Ammitzboll >>Cc: erosen@cisco.com; pwe3; Stewart Bryant >Subject: Re: [PWE3] RSVP-TE and PW >> >> >> >> There seems little logical relevance as to whether >>you should use one protocol or the other because you have >>already implemented one or the other. The fact is that if you >>are building an LSR (or enhancing an existing one), you >>should be building in both RSVP-TE and LDP anyway >>(or have both there already). To me, the most >>germane point is what Eric said earlier -- LDP signaling >>for PWs already is well understood, deployed in real >>code and solves what seems to be the same problems solved by >>an RSVP-TE-based approach. Call me cynical, but it seems >>that this argument really boils down to is the old RSVP-TE >>vs. CR-LDP argument (again) -- both protocols solve the >>same problems, with the majority implementing/deploying >>one approach, while the other approach is pushed by a small >>number of vendors or vendor who seem to be motivated solely >>by their marketing departments to hold out for their >>'alternate' approach based on purported technical superiority. >> >> --Tom >> >> >> >> >> >>>May I add that if you already have RSVP-TE to set up your TE tunnels >>>there >>>seems to be little advantage in implementing yet another >>> >>> >>protocol to >> >> >>>carry >>>the same kind of objects from one endpoint to another. >>> >>>Therefore I find the question raised by Diego relevant - >>> >>> >>although it >> >> >>>is probably too late. >>> >>>/Benny >>> >>> >>>-----Original Message----- >>>From: pwe3-bounces@ietf.org >>> >>> >>[mailto:pwe3-bounces@ietf.org]On Behalf Of >> >> >>>Eric Rosen >>>Sent: 29. september 2004 15:27 >>>To: Diego Caviglia >>>Cc: pwe3; Stewart Bryant >>Subject: Re: [PWE3] RSVP-TE and PW >>> >>> >>> >>> >>> >>>>given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS) >>>> >>>> >>>The "some advantage" is not relevant in this context. >>> >>>The network layer tunnels through which the PWs flow may have >>>QoS. The >>>attachment circuits which are connected to each other via a PW may >>>have QoS. >>>But I don't think there is any notion of QoS which is >>> >>> >>specific to >> >> >>>the PW >>>itself, rather than to the network layer or the attachment circuits. >>> >>>Therefore, any QoS parameter carried in the PW setup >>> >>> >>protocol would >> >> >>>really >>>be just an opaque object to that protocol. A PW endpoint >>> >>> >>might want >> >> >>>to pass >>>this object to the network layer, saying in effect "put this PW >>>through a >>>tunnel that has this QoS". A PW endpoint might want to pass this >>>object to >>>the NSP layer, saying in effect "set up the attachment circuit >>>according to >>>these QoS parameters". But the PW setup protocol doesn't >>>actually do >>>anything itself with the QoS parameter, other than to carry it >>>around and >>>pass it off. The only QoS requirement for the PW signaling >>> >>> >>protocol >> >> >>>is that >>>it be able to carry an opaque QoS object from one endpoint to >>>another. >>>RSVP-TE has no advantage over LDP with respect to the >>> >>> >>carrying of >> >> >>>objects >>>from one endpoint to another. >>> >>> >>> >>> >>> >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: RSVP-TE and PW Date: Wed, 06 Oct 2004 09:48:18 -0600 Organization: Cisco Systems Lines: 160 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Oct 06 17:58:54 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: Diego Caviglia In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Diego, None of these are features or requirements specific to the PW itself. So there is no need to have the PW signaling protocol provide them. Luca Diego Caviglia wrote: >Hi Thomas, > actually it seems to me that what we are >discussing here is if both the protocol solve the same problems and the >result is that: > >LDP doesn't provide QoS >LDP doesn't have TE features >LDP doesn't have mp2p > >Now may be that feature are useless but may be not. Moreover as some >carrier said having two protocol instead only one is not good from an OPEX >point of view. > >I'm not pushing one approach because "...who seem to be motivated solely by >their marketing departments to hold out for their >'alternate' approach based on purported technical superiority." I'm just >trying to understand well this stuff. > >Best Regards > >Diego > > > > >"Thomas D. Nadeau" on 04/10/2004 19.55.49 > >To: Benny Ammitzboll >cc: , "Stewart Bryant , > pwe3 , "Diego Caviglia" > >Subject: Re: [PWE3] RSVP-TE and PW > > > > There seems little logical relevance as to whether >you should use one protocol or the other because you have >already implemented one or the other. The fact is >that if you are building an LSR (or enhancing an >existing one), you should be building in both RSVP-TE and LDP anyway >(or have both there already). To me, the most >germane point is what Eric said earlier -- LDP signaling >for PWs already is well understood, deployed in real >code and solves what seems to be the same problems solved by >an RSVP-TE-based approach. Call me cynical, but it seems >that this argument really boils down to is the old RSVP-TE >vs. CR-LDP argument (again) -- both protocols solve the >same problems, with the majority implementing/deploying >one approach, while the other approach is pushed by a small >number of vendors or vendor who seem to be motivated solely by >their marketing departments to hold out for their >'alternate' approach based on purported technical >superiority. > > --Tom > > > > > >>May I add that if you already have RSVP-TE to set up your TE tunnels >>there >>seems to be little advantage in implementing yet another protocol to >>carry >>the same kind of objects from one endpoint to another. >> >>Therefore I find the question raised by Diego relevant - although it is >>probably too late. >> >>/Benny >> >> >>-----Original Message----- >>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of >>Eric Rosen >>Sent: 29. september 2004 15:27 >>To: Diego Caviglia >>Cc: pwe3; Stewart Bryant >Subject: Re: [PWE3] RSVP-TE and PW >> >> >> >> >> >>>given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS) >>> >>> >>The "some advantage" is not relevant in this context. >> >>The network layer tunnels through which the PWs flow may have >>QoS. The >>attachment circuits which are connected to each other via a PW may >>have QoS. >>But I don't think there is any notion of QoS which is specific to >>the PW >>itself, rather than to the network layer or the attachment circuits. >> >>Therefore, any QoS parameter carried in the PW setup protocol would >>really >>be just an opaque object to that protocol. A PW endpoint might want >>to pass >>this object to the network layer, saying in effect "put this PW >>through a >>tunnel that has this QoS". A PW endpoint might want to pass this >>object to >>the NSP layer, saying in effect "set up the attachment circuit >>according to >>these QoS parameters". But the PW setup protocol doesn't >>actually do >>anything itself with the QoS parameter, other than to carry it >>around and >>pass it off. The only QoS requirement for the PW signaling protocol >>is that >>it be able to carry an opaque QoS object from one endpoint to >>another. >>RSVP-TE has no advantage over LDP with respect to the carrying of >>objects >>from one endpoint to another. >> >> >> >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> > > > > > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: p2mp PWs (was RSVP-TE and PW) Date: Wed, 06 Oct 2004 12:32:14 -0400 Lines: 29 Sender: pwe3-bounces@ietf.org References: <20041006001509.T44001@sapphire.juniper.net> 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 X-From: pwe3-bounces@ietf.org Wed Oct 06 18:38:08 2004 Return-path: X-BrightmailFiltered: true To: Rahul Aggarwal In-reply-to: Your message of Wed, 06 Oct 2004 00:38:16 -0700. <20041006001509.T44001@sapphire.juniper.net> 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) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Eric> The receiving PEs then process the packets as if the packets had Eric> arrived on the unicast PW from the transmitting PE. Rahul> Not quite. The IP multicast packet carries an upstream label which Rahul> is a different label from the one used by the unicast PW. The Rahul> upstream label is in the context of the sender PE and assigned by the Rahul> sender PE, while the unicast PW label is assigned by the receiver Rahul> PE. The "processing" I was referring to was the processing of the packet by the "ethernet switch" after the packet is decapsulated. What you're referring to above is the "MPLS decapsulate and dispatch" function. What you say is correct, but I think not in conflict with what I said (or meant to have said :-)). If the multicast distribution tree were to be treated as an independent PW, then we'd end up with two PWs between a pair of bridges. Would we need to send the BPDUs on both of them? Should one of the PWs be in blocking state if the other is active? When we do MAC learning, do we associate the MAC SAs learned from multicast packets with the multicast tree, rather than with the unicast PW? In your proposal, I think you really don't want the ethernet bridge function to know whether a received packet came from the unicast PW or from the multicast distribution tree, though of course the MPLS decapsulation and dispatch function needs to know this. That's why I don't really regard your proposal as creating a multicast PW. That's just meant as an observation about your proposal, not as a criticism of it. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Adrian Farrel" Subject: Re: RSVP-TE and PW Date: Wed, 6 Oct 2004 19:45:20 +0100 Lines: 128 Sender: pwe3-bounces@ietf.org References: <0536FC9B908BEC4597EE721BE6A353890A9F12BC@i2km07-ukbr.domain1.systemhost.net> Reply-To: Adrian Farrel Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Oct 06 21:00:34 2004 Return-path: To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Neil, > rather glad you 'PMFJI'd' on this topic Well, it's my pleasure :-) > some additional remarks below. > > The "GMPLS data plane" is not a very useful term IMHO > > because GMPLS-RSVP-TE signaling can be used to install > >LSPs in a variety of network technologies. >NH=> I think it is actually rather important to be clear about > the data-plane aspects......as there are some important diffences > between the 3 modes. However, a key observation is that with > co-cs mode technologies (like SDH and OTNs) the control and > management protocols are forced to reside in their own co-cs > network partition that is disjoint to the traffic's co-cs data-plane > network. 'Disjoint' is a word we have to use carefully. Consider the fact that one could squeeze singaling into overhead bytes (bleah!), dedicate timeslot or lambda, run a parallel 10/100 wire, etc., etc. Thus it is useful to distinguish out-of-band and out-of-fiber. I think that what you are saying is that non-packet technologies necessarily require that the control plane is out-of-band. > Now this has very > significant implications across all the functional components > of *each* data-plane.....and in particular the control/management > protocols are likely to be using a cl-ps mode of operation in their > network partition, but they act to set-up/take-down/manage co-cs > trails in the traffic data-plane, ie there are 2 fundamentally different > network designs operating in the same 'technology'. OK. No argument with that. And we can follow this model even if the data plane happens to use the same technology as the control plane. > > Popularly, this is > > considered to be limited to optical networks (lambda > > switching and TDM) but this is not the case. GMPLS signaling > > is fully applicable to a wide range (or hierarchy) of > > switching technology from (at the coarsest granularity) port > > switching, down through waveband and lambda switching, passed > > TDM and layer 2 switching, to MPLS packet switching (at the > > finest granularity). > > > > This last point is very important since it says that GMPLS > > signaling technology can be used to install LSPs in packet > > switched networks. > NH=> I agree. I tried to make this same point in an earlier posting, ie > a similar control/management-plane design philosophy can be applied to > the co-ps mode as the co-cs mode....and there are indeed some important > benefits from doing so. There are, however, some key differences > between the 2 modes in the traffic data-plane, eg the link-connection > IDs are abstract in the co-ps mode but they must take on a > time/space/freq semantic in the co-cs mode, there are no QoS classes in > the co-cs mode (this is a *very* significant simplification), the > defects are different (and so the OAM required is a little different), > etc......however, I do agree with you that one can apply a very similar > OOB design philosophy for the control/management-plane in the co-ps > mode as one can (and is indeed forced to do) for the co-cs mode. OK. Sounds like moderately violent agreement. > > Yet, GMPLS signaling (which is built upon RSVP-TE) includes > > some of the mechanisms described as necessary and missing. > > Not least among these is the ability to signal in control > > plane channels that are both logically and physically diverse > > from the data plane channels. > NH=> Its not just the control-plane protocol but also the > management-plane protocols. This is an important observation > (eg for security) and is something we are very keen to see > adopted as a general principle in core co-cs and co-ps networks. > > > But don't think that GMPLS signaling is some radical new > > signaling technique. It isn't. It is just a logical (some > > would say evolutionary) development of RSVP-TE. > NH=> Agreed. But the co-cs mode does force things like OOB. Absolutely. As I say, however, OOB is not necessarily out-of-fiber. Maybe the point (in packet networks) is to notice that GMPLS operates on TE links. The topology of TE links does not need to follow the IP topology at all. Thus, although it is possible (maybe even current practice) to exactly overlay the data and control networks in a packet environment, it is in no way compulsory and it is a network management choice. > > Thus, there is no need to talk about getting MPLS to do the > > same 'decoupling' as GMPLS has achieved. GMPLS *is* the > > decoupling that you want. > NH=> I can but agree....nice to hear someone else saying this! Hoorah! May I sell you some of this apple pie I made earlier? > > GMPLS is worked on by the CCAMP working group who > > would, I'm sure, be happy to discuss your requirements and to > > suggest ways that GMPLS signaling could provide the functional > > support needed by PWE3. > > NH=> Yes please Adrian. OK. looking forward to seeing the emails. >.....but please note that the stuff I have been > harping on about since as long as I can remember must also be > considered, eg like the OAM is different in the 3 modes, > like the client/server adaptation functions are not the same for > all modal combinations, like there are no QoS/traffic classes in > the co-cs modes, etc. Agreed that all of these things need further investigation and clarification. > Further, its not for fun that we are very strong advocates of > functional modelling (ie the G.805/809 stuff for the data-plane and > G.8080 for the control-plane), and it would be great if folks could > try and understand/use this stuff more. Followers of CCAMP will know that a fair amount of effort has been put into understanding exactly how G.8080 and G.7713/5 relate to GMPLS. Cheers, Adrian From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Paul Doolan" Subject: PW to PSN mapping (again) Date: Wed, 6 Oct 2004 16:44:58 -0400 Lines: 250 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1132349106==" X-From: pwe3-bounces@ietf.org Thu Oct 07 09:58:00 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: PW to PSN mapping (again) Thread-Index: AcSr5Vg7dAdGsgcKRRiKPVYk28/RAA== To: X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 X-Mailman-Approved-At: Thu, 07 Oct 2004 03:53:55 -0400 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1132349106== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4ABE5.583836B5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4ABE5.583836B5 Content-Type: text/plain; charset="utf-8" X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Content-Transfer-Encoding: quoted-printable Hello, =20 It's been a while since I've been active in this area but the fascinating= RSVP-TE thread makes it seem like I never left. Didn't we see the RSVP v= s LDP movie already? Still it's nice to see that some of the original com= batants are around to clarify the record. Today however I have no questio= ns about RSVP. =20 I would be grateful if any of you can shed some light on a thing that's b= een puzzling me for a little while. Back in August there was a little thr= ead "[PWE3] PW to PSN tunnel mapping" started by Benny L=C3=B8nstrup Ammi= tzb=C3=B8ll. He asked how a PE might know to which PSN tunnel a PW belong= s. Before that thread morphed into the QoS one there was an uchallenged c= ontribution that said it was a matter of local policy at the PE which dec= ided this mapping.=20 =20 Matters of local policy tend to create interoperability problems. In part= icular this one (if true) might be better stated as "it's a matter of loc= al policy at the ingress (to which PSN tunnel a PW is mapped)". And the c= orollary is surely that the egress is SOL in the 'local policy' departmen= t. Perhaps more accurately the egress's policy options are binary. It can= take pseudowire traffic as and from whence it arrives or it can drop it. Is it really the case that I can open up multiple tunnels to an egress PE= and fire off pseudowire traffic down whichever of them I choose and ever= ything will work fine? Or does this depend not only on the local policy o= f the ingress but also on the vendor implementation at the egress?=20 =20 =20 Paul =20 =20 This message contains information intended only for the individual named.= If you are not the named addressee you should not disseminate, distribut= e or copy this email. Please notify the sender immediately if you receive= d this message by mistake and delete this e-mail from your system. The se= nder does not accept liability for any errors or omissions in the content= s of this message, which arise as a result of e-mail transmission. If ver= ification is required please request a hard-copy version. Mangrove System= s, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com= =0A ------_=_NextPart_001_01C4ABE5.583836B5 Content-Type: text/HTML; charset="utf-8" X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Content-Transfer-Encoding: quoted-printable

Hello,

 

It’s been a while since I’ve been active i= n this area but the fascinating RSVP-TE thread makes it seem like I never left. = Didn’t we see the RSVP vs LDP movie already? Still it’s nice to see that s= ome of the original combatants are around to clarify the record. Today however I= have no questions about RSVP.

 

I would be grateful if any of you can shed some light = on a thing that’s been puzzling me for a little while. Back in August there wa= s a little thread “[PWE3] PW to PSN tunnel mapping” started by Be= nny L=C3=B8nstrup Ammitzb=C3=B8ll. He asked how a PE might know to which PSN tunnel a PW be= longs. Before that thread morphed into the QoS one there was an uchallenged contributio= n that said it was a matter of local policy at the PE which decided this mapping= =2E

 

Matters of local policy tend to create interoperabilit= y problems. In particular this one (if= true) might be better stated as “it’s a matter of local policy at the ing= ress (to which PSN tunnel a PW is mapped)”. And the corollary is surely = that the egress is SOL in the ‘local policy’ department. Perhaps more accurately the egress’s policy options are binary. It can take pseu= dowire traffic as and from whence it arrives or it can drop it.

Is it really the case that I can open up multiple tunn= els to an egress PE and fire off pseudowire traffic down whichever of them I cho= ose and everything will work fine? Or does this depend not only on the local = policy of the ingress but also on the vendor implementation at the egress?

 

 

Paul

 

 

This message contains information intended only for the individual named.= If you are not the named addressee you should not disseminate, distribut= e or copy this email. Please notify the sender immediately if you receive= d this message by mistake and delete this e-mail from your system. The se= nder does not accept liability for any errors or omissions in the content= s of this message, which arise as a result of e-mail transmission. If ver= ification is required please request a hard-copy version. Mangrove System= s, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com=
=0A

------_=_NextPart_001_01C4ABE5.583836B5-- --===============1132349106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1132349106==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Shah, Himanshu" Subject: RE: PW to PSN mapping (again) Date: Thu, 7 Oct 2004 09:07:41 -0400 Lines: 342 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1068489729==" X-From: pwe3-bounces@ietf.org Thu Oct 07 15:14:18 2004 Return-path: To: "'Paul Doolan'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1068489729== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AC6E.A0AA4570" 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_01C4AC6E.A0AA4570 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The service guarentees sold on ACs pretty much dictates what kind of transport tunnels the PW will ride on. You can then,=20 1) either build TE tunnels accordingly and do CAC as you map PWs (of same characteristics) over it. You can apply thresholds = that would dictate up or downsizing of tunnel b/w dynamically 2) do BE tunnels 3) manually map PWs over preconfigured suitable transport tunnels. =20 One of the thing an ingress PE may want to take into consideration is = AC characteristics of Egress PE when selecting a transport tunnel from ingress to egress = and for applying appropriate traffic policing/shaping at ingress (to avoid = packet drops at egress).=20 For this you may want to look at = draft-shah-PWE3-pw-qos-signalling-00.txt. (peddling my draft..:-) =20 /himanshu =20 =20 =20 -----Original Message----- From: Paul Doolan [mailto:pdoolan@mangrovesystems.com] Sent: Wednesday, October 06, 2004 4:45 PM To: pwe3@ietf.org Subject: [PWE3] PW to PSN mapping (again) Hello, =20 It=E2=80=99s been a while since I=E2=80=99ve been active in this area = but the fascinating RSVP-TE thread makes it seem like I never left. = Didn=E2=80=99t we see the RSVP vs LDP movie already? Still it=E2=80=99s = nice to see that some of the original combatants are around to clarify = the record. Today however I have no questions about RSVP. =20 I would be grateful if any of you can shed some light on a thing = that=E2=80=99s been puzzling me for a little while. Back in August = there was a little thread =E2=80=9C[PWE3] PW to PSN tunnel = mapping=E2=80=9D started by Benny L=C3=B8nstrup Ammitzb=C3=B8ll. He = asked how a PE might know to which PSN tunnel a PW belongs. Before that = thread morphed into the QoS one there was an uchallenged contribution = that said it was a matter of local policy at the PE which decided this = mapping.=20 =20 Matters of local policy tend to create interoperability problems. In = particular this one (if true) might be better stated as = =E2=80=9Cit=E2=80=99s a matter of local policy at the ingress (to which = PSN tunnel a PW is mapped)=E2=80=9D. And the corollary is surely that = the egress is SOL in the =E2=80=98local policy=E2=80=99 department. = Perhaps more accurately the egress=E2=80=99s policy options are binary. = It can take pseudowire traffic as and from whence it arrives or it can = drop it. Is it really the case that I can open up multiple tunnels to an egress = PE and fire off pseudowire traffic down whichever of them I choose and = everything will work fine? Or does this depend not only on the local = policy of the ingress but also on the vendor implementation at the = egress?=20 =20 =20 Paul =20 =20 _____ =20 This message contains information intended only for the individual = named. If you are not the named addressee you should not disseminate, = distribute or copy this email. Please notify the sender immediately if = you received this message by mistake and delete this e-mail from your = system. The sender does not accept liability for any errors or = omissions in the contents of this message, which arise as a result of = e-mail transmission. If verification is required please request a = hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd, = Wallingford, CT 06492. www.mangrovesystems.com ------_=_NextPart_001_01C4AC6E.A0AA4570 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA13599
The=20 service guarentees sold on ACs pretty much dictates what kind=20 of
transport tunnels the PW will ride on. You can then,
1)=20 either build TE tunnels accordingly and do CAC as you=20 map
      PWs (of same characteristics)&nbs= p;over=20 it.  You can apply thresholds that
      would dictate up or downsizing of= tunnel=20 b/w dynamically
2)=20 do BE tunnels
3)=20 manually map PWs over preconfigured suitable transport=20 tunnels.
 
One=20 of the thing an ingress PE may want to take into consideration is AC=20 characteristics
of=20 Egress PE when selecting a transport tunnel from ingress to egress and=20 for
applying appropriate traffic policing/shaping at ingress (to avo= id packet=20 drops at egress). 
 For this you may want to look = at=20 draft-shah-PWE3-pw-qos-signalling-00.txt. (peddling my=20 draft..:-)
 
/himanshu
 
 
 
-----Original Message-----
From: Paul Doolan=20 [mailto:pdoolan@mangrovesystems.com]
Sent: Wednesday, October= 06,=20 2004 4:45 PM
To: pwe3@ietf.org
Subject: [PWE3] PW t= o PSN=20 mapping (again)

Hello,

 

It=E2=80=99s been a while= since I=E2=80=99ve been=20 active in this area but the fascinating RSVP-TE thread makes it seem li= ke I=20 never left. Didn=E2=80=99t we see the RSVP vs LDP movie already? Still = it=E2=80=99s nice to=20 see that some of the original combatants are around to clarify the reco= rd.=20 Today however I have no questions about RSVP.

 

I would be grateful if an= y of you=20 can shed some light on a thing that=E2=80=99s been puzzling me for a li= ttle while.=20 Back in August there was a little thread =E2=80=9C[PWE3] PW to PSN tunn= el mapping=E2=80=9D=20 started by Benny L=C3=B8nstrup Ammitzb=C3=B8ll. He asked how a PE might= know to which=20 PSN tunnel a PW belongs. Before that thread morphed into the QoS one th= ere was=20 an uchallenged contribution that said it was a matter of local policy a= t the=20 PE which decided this mapping.

 

Matters of local policy t= end to=20 create interoperability probl= ems. In parti= cular this=20 one (if true) might be better stated as =E2=80=9Cit=E2=80=99s a matter = of local policy at the=20 ingress (to which PSN tunnel a PW is mapped)=E2=80=9D. And the corollar= y is surely=20 that the egress is SOL in the =E2=80=98local policy=E2=80=99 department= . Perhaps more=20 accurately the egress=E2=80=99s policy options are binary. It can take = pseudowire=20 traffic as and from whence it arrives or it can drop it.<= /P>

Is it really the case tha= t I can=20 open up multiple tunnels to an egress PE and fire off pseudowire traffi= c down=20 whichever of them I choose and everything will work fine? Or does this = depend=20 not only on the local policy of the ingress but also on the vendor=20 implementation at the egress?

 

 

Paul

 

 

This message contains information intended only for the individual name= d. If=20 you are not the named addressee you should not disseminate, distribute = or copy=20 this email. Please notify the sender immediately if you received this m= essage=20 by mistake and delete this e-mail from your system. The sender does not= accept=20 liability for any errors or omissions in the contents of this message, = which=20 arise as a result of e-mail transmission. If verification is required p= lease=20 request a hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd,=20 Wallingford, CT 06492. www.mangrovesystems.com

------_=_NextPart_001_01C4AC6E.A0AA4570-- --===============1068489729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1068489729==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Paul Doolan" Subject: RE: PW to PSN mapping (again) Date: Thu, 7 Oct 2004 10:42:14 -0400 Lines: 677 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1586289784==" X-From: pwe3-bounces@ietf.org Thu Oct 07 17:01:07 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] PW to PSN mapping (again) Thread-Index: AcSsbqNh/CIlZj25TPCTQSo9kzJOHQACmE4Q To: "Shah, Himanshu" , X-Scan-Signature: 8136d1e28e0aab8a4e130297ed2e1fc4 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1586289784== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AC7B.D630A4F8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4AC7B.D630A4F8 Content-Type: text/plain; charset="utf-8" X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Content-Transfer-Encoding: quoted-printable Himanshu, =20 1,2 and 3 though are operations that occur at the ingress. I'm still puzz= led as to how the egress knows (given any of these tunnel setup methods) = over which tunnel a particular pseudowire's datastream is going to appear= =2E My concern is unambiguously identifying such a, newly appearing, stre= am. I can believe that this is possible if the label value signaled (by t= he egress in this case) is unique for the platform. What I'm not aware of= is any statement that _requires_ this to be true. In draft-ietf-pwe3-con= trol-protocol-10.txt the label is signaled as a "Generic Label". Does any= one know if there are semantics associated with that type of label or its= use that require it to be unique?=20 =20 And I'll take a look at your draft.... thanks Pd=20 =20 -----Original Message----- From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Thursday, October 07, 2004 9:08 AM To: Paul Doolan; pwe3@ietf.org Subject: RE: [PWE3] PW to PSN mapping (again) =20 The service guarentees sold on ACs pretty much dictates what kind of transport tunnels the PW will ride on. You can then,=20 1) either build TE tunnels accordingly and do CAC as you map PWs (of same characteristics) over it. You can apply thresholds th= at would dictate up or downsizing of tunnel b/w dynamically 2) do BE tunnels 3) manually map PWs over preconfigured suitable transport tunnels. =20 One of the thing an ingress PE may want to take into consideration is AC = characteristics of Egress PE when selecting a transport tunnel from ingress to egress and= for applying appropriate traffic policing/shaping at ingress (to avoid packet= drops at egress).=20 For this you may want to look at draft-shah-PWE3-pw-qos-signalling-00.tx= t. (peddling my draft..:-) =20 /himanshu =20 =20 =20 =09-----Original Message----- =09From: Paul Doolan [mailto:pdoolan@mangrovesystems.com] =09Sent: Wednesday, October 06, 2004 4:45 PM =09To: pwe3@ietf.org =09Subject: [PWE3] PW to PSN mapping (again) =09Hello, =09=20 =09It's been a while since I've been active in this area but the fascinat= ing RSVP-TE thread makes it seem like I never left. Didn't we see the RSV= P vs LDP movie already? Still it's nice to see that some of the original = combatants are around to clarify the record. Today however I have no ques= tions about RSVP. =09=20 =09I would be grateful if any of you can shed some light on a thing that'= s been puzzling me for a little while. Back in August there was a little = thread "[PWE3] PW to PSN tunnel mapping" started by Benny L=C3=B8nstrup A= mmitzb=C3=B8ll. He asked how a PE might know to which PSN tunnel a PW bel= ongs. Before that thread morphed into the QoS one there was an uchallenge= d contribution that said it was a matter of local policy at the PE which = decided this mapping.=20 =09=20 =09Matters of local policy tend to create interoperability problems. In p= articular this one (if true) might be better stated as "it's a matter of = local policy at the ingress (to which PSN tunnel a PW is mapped)". And th= e corollary is surely that the egress is SOL in the 'local policy' depart= ment. Perhaps more accurately the egress's policy options are binary. It = can take pseudowire traffic as and from whence it arrives or it can drop = it. =09Is it really the case that I can open up multiple tunnels to an egress= PE and fire off pseudowire traffic down whichever of them I choose and e= verything will work fine? Or does this depend not only on the local polic= y of the ingress but also on the vendor implementation at the egress?=20 =09=20 =09=20 =09Paul =09=20 =09=20 =09 _____ =20 =09This message contains information intended only for the individual nam= ed. If you are not the named addressee you should not disseminate, distri= bute or copy this email. Please notify the sender immediately if you rece= ived this message by mistake and delete this e-mail from your system. The= sender does not accept liability for any errors or omissions in the cont= ents of this message, which arise as a result of e-mail transmission. If = verification is required please request a hard-copy version. Mangrove Sys= tems, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.= com This message contains information intended only for the individual named.= If you are not the named addressee you should not disseminate, distribut= e or copy this email. Please notify the sender immediately if you receive= d this message by mistake and delete this e-mail from your system. The se= nder does not accept liability for any errors or omissions in the content= s of this message, which arise as a result of e-mail transmission. If ver= ification is required please request a hard-copy version. Mangrove System= s, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com= =0A ------_=_NextPart_001_01C4AC7B.D630A4F8 Content-Type: text/HTML; charset="utf-8" X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Content-Transfer-Encoding: quoted-printable

Himanshu,

 

1,2 and 3 though are operations that= occur at the ingress. I’m still puzzled as to how the egress knows (given= any of these tunnel setup methods) over which tunnel a particular pseudowire’s d= atastream is going to appear. My concern is unambiguously identifying such a, newly appearing, stream. I can believe that this is possible if the label value= signaled (by the egress in this case) is unique for the platform. What I’m n= ot aware of is any statement that _requires_ this to be true. In draft-ietf-pwe3-control-protocol-10.txt the label is = signaled as a “Generic Label”. Does anyone know if there are semantics= associated with that type of label or its use that require it to be unique?

 

And I’ll take a look at your d= raft….

thanks

Pd

 

-----Original Message-----<= br> From: Shah, Himanshu [mailto:hshah@ciena.com]
Sent: Thursday, October 07, 2004 9:08 AM
To: Paul Doolan; pwe3@ietf= =2Eorg
Subject: RE: [PWE3] PW to = PSN mapping (again)

 

The service guarentees sold on ACs pretty much dictates what kind of

transport tunnels the PW will ride on. You can then,

1) either build TE tunnels accordingly and do CAC as you map

      PWs (of same characteristics) over it.  You can apply threshold= s that

      would dictate up or downsizing of tunnel b/w dynamically

2) do BE tunnels

3) manually map PWs over preconfigured suitable transport tunnels.

 

One of the thing an ingress PE may want to take into consideration is AC characteristics

of Egress PE when selecting= a transport tunnel from ingress to egress and for

applying appropriate traffic policing/shaping at ingress (to avoid packet drops at egress). 

 For this you may want to look at draft-shah-PWE3-pw-qos-signalling-00.txt. (peddling my draft..:-)

 

/himanshu

 

 

 

-----Original Message-----
From: Paul Doolan [mailto:pdoolan@mangrovesystems.com]
Sent: Wednesday, October 06, 2004 4:45 PM
To: pwe3@ietf.org
Subject: [PWE3] PW to PSN = mapping (again)

Hello,

 

It’s been a while sinc= e I’ve been active in this area but the fascinating RSVP-TE thread makes it seem like= I never left. Didn’t we see the RSVP vs LDP movie already? Still it&#= 8217;s nice to see that some of the original combatants are around to clarify the record. To= day however I have no questions about RSVP.

 

I would be grateful if any o= f you can shed some light on a thing that’s been puzzling me for a little= while. Back in August there was a little thread “[PWE3] PW to PSN tunnel mappin= g” started by Benny L=C3=B8nstrup Ammitzb=C3=B8ll. He asked how a PE might know to w= hich PSN tunnel a PW belongs. Before that thread morphed into the QoS one there was an uchallenged contribution that said it was a matter of local policy at the= PE which decided this mapping.

 

Matters of local policy tend= to create interoperability problems. In particular this one (if true) might = be better stated as “it’s a matter of local policy at the ingres= s (to which PSN tunnel a PW is mapped)”. And the corollary is surely that the egres= s is SOL in the ‘local policy’ department. Perhaps more accurately the eg= ress’s policy options are binary. It can take pseudowire traffic as and from whence it arrives = or it can drop it.

Is it really the case that I= can open up multiple tunnels to an egress PE and fire off pseudowire traffic = down whichever of them I choose and everything will work fine? Or does this de= pend not only on the local policy of the ingress but also on the vendor implementation at the egress?

 

 

Paul

 

 

This message contains information intended onl= y for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately if you received this message by mistake and delete this e-mai= l from your system. The sender does not accept liability for any errors or omiss= ions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy vers= ion. Mangrove Systems, Inc. 10 Fairfield Blvd, Wallingford, CT 0= 6492. www.mangrovesystems.com

This message contains information intended only for the individual named.= If you are not the named addressee you should not disseminate, distribut= e or copy this email. Please notify the sender immediately if you receive= d this message by mistake and delete this e-mail from your system. The se= nder does not accept liability for any errors or omissions in the content= s of this message, which arise as a result of e-mail transmission. If ver= ification is required please request a hard-copy version. Mangrove System= s, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com=
=0A

------_=_NextPart_001_01C4AC7B.D630A4F8-- --===============1586289784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1586289784==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Shah, Himanshu" Subject: RE: PW to PSN mapping (again) Date: Thu, 7 Oct 2004 10:59:09 -0400 Lines: 677 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1139848755==" X-From: pwe3-bounces@ietf.org Thu Oct 07 17:15:51 2004 Return-path: To: "'Paul Doolan'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 8136d1e28e0aab8a4e130297ed2e1fc4 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1139848755== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AC7E.32EFF560" 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_01C4AC7E.32EFF560 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In most common cases for PWs, PHP is used (and hence per-platform label = for PW). In which case, association to an incoming tunnel is lost. This is good = in the sense that FRR or any other mechanism is not constrained to what incoming = interface an egress PE will get the PW traffic. =20 May I ask why do you think it is necessary for egress PE to know on = which tunnel a particular PW traffic would arrive? The PW label carries all the = semantics to=20 forward the traffic out to egress AC (i.e. tunnel label is not used for = this)... =20 /himanshu -----Original Message----- From: Paul Doolan [mailto:pdoolan@mangrovesystems.com] Sent: Thursday, October 07, 2004 10:42 AM To: Shah, Himanshu; pwe3@ietf.org Subject: RE: [PWE3] PW to PSN mapping (again) Himanshu, =20 1,2 and 3 though are operations that occur at the ingress. I=E2=80=99m = still puzzled as to how the egress knows (given any of these tunnel = setup methods) over which tunnel a particular pseudowire=E2=80=99s = datastream is going to appear. My concern is unambiguously identifying = such a, newly appearing, stream. I can believe that this is possible if = the label value signaled (by the egress in this case) is unique for the = platform. What I=E2=80=99m not aware of is any statement that = _requires_ this to be true. In draft-ietf-pwe3-control-protocol-10.txt = the label is signaled as a =E2=80=9CGeneric Label=E2=80=9D. Does anyone = know if there are semantics associated with that type of label or its = use that require it to be unique?=20 =20 And I=E2=80=99ll take a look at your draft=E2=80=A6. thanks Pd=20 =20 -----Original Message----- From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Thursday, October 07, 2004 9:08 AM To: Paul Doolan; pwe3@ietf.org Subject: RE: [PWE3] PW to PSN mapping (again) =20 The service guarentees sold on ACs pretty much dictates what kind of transport tunnels the PW will ride on. You can then,=20 1) either build TE tunnels accordingly and do CAC as you map PWs (of same characteristics) over it. You can apply thresholds = that would dictate up or downsizing of tunnel b/w dynamically 2) do BE tunnels 3) manually map PWs over preconfigured suitable transport tunnels. =20 One of the thing an ingress PE may want to take into consideration is = AC characteristics of Egress PE when selecting a transport tunnel from ingress to egress = and for applying appropriate traffic policing/shaping at ingress (to avoid = packet drops at egress).=20 For this you may want to look at = draft-shah-PWE3-pw-qos-signalling-00.txt. (peddling my draft..:-) =20 /himanshu =20 =20 =20 -----Original Message----- From: Paul Doolan [mailto:pdoolan@mangrovesystems.com] Sent: Wednesday, October 06, 2004 4:45 PM To: pwe3@ietf.org Subject: [PWE3] PW to PSN mapping (again) Hello, =20 It=E2=80=99s been a while since I=E2=80=99ve been active in this area = but the fascinating RSVP-TE thread makes it seem like I never left. = Didn=E2=80=99t we see the RSVP vs LDP movie already? Still it=E2=80=99s = nice to see that some of the original combatants are around to clarify = the record. Today however I have no questions about RSVP. =20 I would be grateful if any of you can shed some light on a thing = that=E2=80=99s been puzzling me for a little while. Back in August = there was a little thread =E2=80=9C[PWE3] PW to PSN tunnel = mapping=E2=80=9D started by Benny L=C3=B8nstrup Ammitzb=C3=B8ll. He = asked how a PE might know to which PSN tunnel a PW belongs. Before that = thread morphed into the QoS one there was an uchallenged contribution = that said it was a matter of local policy at the PE which decided this = mapping.=20 =20 Matters of local policy tend to create interoperability problems. In = particular this one (if true) might be better stated as = =E2=80=9Cit=E2=80=99s a matter of local policy at the ingress (to which = PSN tunnel a PW is mapped)=E2=80=9D. And the corollary is surely that = the egress is SOL in the =E2=80=98local policy=E2=80=99 department. = Perhaps more accurately the egress=E2=80=99s policy options are binary. = It can take pseudowire traffic as and from whence it arrives or it can = drop it. Is it really the case that I can open up multiple tunnels to an egress = PE and fire off pseudowire traffic down whichever of them I choose and = everything will work fine? Or does this depend not only on the local = policy of the ingress but also on the vendor implementation at the = egress?=20 =20 =20 Paul =20 =20 _____ =20 This message contains information intended only for the individual = named. If you are not the named addressee you should not disseminate, = distribute or copy this email. Please notify the sender immediately if = you received this message by mistake and delete this e-mail from your = system. The sender does not accept liability for any errors or = omissions in the contents of this message, which arise as a result of = e-mail transmission. If verification is required please request a = hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd, = Wallingford, CT 06492. www.mangrovesystems.com _____ =20 This message contains information intended only for the individual = named. If you are not the named addressee you should not disseminate, = distribute or copy this email. Please notify the sender immediately if = you received this message by mistake and delete this e-mail from your = system. The sender does not accept liability for any errors or = omissions in the contents of this message, which arise as a result of = e-mail transmission. If verification is required please request a = hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd, = Wallingford, CT 06492. www.mangrovesystems.com ------_=_NextPart_001_01C4AC7E.32EFF560 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
In=20 most common cases for PWs, PHP is used (and hence per-platform label = for=20 PW).
In=20 which case, association to an incoming tunnel is lost. This is good in = the=20 sense
that=20 FRR or any other mechanism is not constrained to what incoming=20 interface
an egress PE will get the PW traffic.
 
May=20 I ask why do you think it is necessary for egress PE to know on which=20 tunnel
a=20 particular PW traffic would arrive? The PW label carries all the semantics to
forward the traffic out to egress AC (i.e. tunnel label is not = used for=20 this)...
 
/himanshu
-----Original Message-----
From: Paul Doolan=20 [mailto:pdoolan@mangrovesystems.com]
Sent: Thursday, = October 07,=20 2004 10:42 AM
To: Shah, Himanshu; = pwe3@ietf.org
Subject:=20 RE: [PWE3] PW to PSN mapping (again)

Himanshu,

 

1,2 and 3 = though are=20 operations that occur at the ingress. I=E2=80=99m still puzzled as to = how the egress=20 knows (given any of these tunnel setup methods) over which tunnel a = particular=20 pseudowire=E2=80=99s datastream is going to appear. My concern is = unambiguously=20 identifying such a, newly appearing, stream. I can believe that this = is=20 possible if the label value signaled (by the egress in this case) is = unique=20 for the platform. What I=E2=80=99m not aware of is any statement that = _requires_ this to be true. In = draft-ietf-pwe3-control-protocol-10.txt the label is signaled as a = =E2=80=9CGeneric=20 Label=E2=80=9D. Does anyone know if there are semantics associated = with that type of=20 label or its use that require it to be unique?

 

And = I=E2=80=99ll take a look=20 at your draft=E2=80=A6.

thanks

Pd=20

 

-----Original=20 Message-----
From: = Shah,=20 Himanshu [mailto:hshah@ciena.com]
Sent: Thursday, October=20 07, 2004 9:08=20 AM
To: Paul Doolan;=20 pwe3@ietf.org
Subject: RE:=20 [PWE3] PW to PSN mapping (again)

 

The=20 service guarentees sold on ACs pretty much dictates what kind=20 of

transport tunnels=20 the PW will ride on. You can then,

1)=20 either build TE tunnels accordingly and do CAC as you=20 map

     =20 PWs (of same characteristics) over it.  You can apply = thresholds=20 that

     =20 would dictate up or downsizing of tunnel b/w=20 dynamically

2) do=20 BE tunnels

3)=20 manually map PWs over preconfigured suitable transport=20 tunnels.

 

One of=20 the thing an ingress PE may want to take into consideration is AC=20 characteristics

of=20 Egress=20 PE when = selecting a=20 transport tunnel from ingress to egress and = for

applying = appropriate traffic policing/shaping at ingress (to avoid packet = drops at=20 egress). 

 For this you=20 may want to look at draft-shah-PWE3-pw-qos-signalling-00.txt. = (peddling my=20 draft..:-)

 

/himanshu

 

 

 

-----Original=20 Message-----
From: Paul=20 Doolan [mailto:pdoolan@mangrovesystems.com]
Sent: Wednesday, October=20 06, 2004 4:45=20 PM
To: = pwe3@ietf.org
Subject: [PWE3] PW to PSN = mapping=20 (again)

Hello,

 

It=E2=80=99s been a = while since I=E2=80=99ve=20 been active in this area but the fascinating RSVP-TE thread makes = it seem=20 like I never left. Didn=E2=80=99t we see the RSVP vs LDP movie = already? Still it=E2=80=99s=20 nice to see that some of the original combatants are around to = clarify the=20 record. Today however I have no questions about = RSVP.

 

I would be grateful = if any of=20 you can shed some light on a thing that=E2=80=99s been puzzling me = for a little=20 while. Back in August there was a little thread =E2=80=9C[PWE3] PW = to PSN tunnel=20 mapping=E2=80=9D started by Benny L=C3=B8nstrup Ammitzb=C3=B8ll. He = asked how a PE might know=20 to which PSN tunnel a PW belongs. Before that thread morphed into = the QoS=20 one there was an uchallenged contribution that said it was a matter = of local=20 policy at the PE which decided this mapping.

 

Matters of local = policy tend to=20 create interoperability problems. In particular this one (if true) = might be=20 better stated as =E2=80=9Cit=E2=80=99s a matter of local policy at = the ingress (to which PSN=20 tunnel a PW is mapped)=E2=80=9D. And the corollary is surely that = the egress is SOL=20 in the =E2=80=98local policy=E2=80=99 department. Perhaps more = accurately the egress=E2=80=99s=20 policy options are binary. It can take pseudowire traffic as and = from whence=20 it arrives or it can drop it.

Is it really the case = that I can=20 open up multiple tunnels to an egress PE and fire off pseudowire = traffic=20 down whichever of them I choose and everything will work fine? Or = does this=20 depend not only on the local policy of the ingress but also on the = vendor=20 implementation at the egress?

 

 

Paul

 

 

This message contains = information=20 intended only for the individual named. If you are not the named = addressee=20 you should not disseminate, distribute or copy this email. Please = notify the=20 sender immediately if you received this message by mistake and = delete this=20 e-mail from your system. The sender does not accept liability for = any errors=20 or omissions in the contents of this message, which arise as a = result of=20 e-mail transmission. If verification is required please request a = hard-copy=20 version. Mangrove Systems, Inc. 10 Fairfield Blvd,=20 Wallingford, CT 06492. = www.mangrovesystems.com

This message contains information intended only for the individual = named. If=20 you are not the named addressee you should not disseminate, = distribute or copy=20 this email. Please notify the sender immediately if you received this = message=20 by mistake and delete this e-mail from your system. The sender does = not accept=20 liability for any errors or omissions in the contents of this = message, which=20 arise as a result of e-mail transmission. If verification is required = please=20 request a hard-copy version. Mangrove Systems, Inc. 10 Fairfield = Blvd,=20 Wallingford, CT 06492. www.mangrovesystems.com

------_=_NextPart_001_01C4AC7E.32EFF560-- --===============1139848755== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1139848755==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: PW to PSN mapping (again) Date: Thu, 7 Oct 2004 17:13:35 +0200 Lines: 191 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Thu Oct 07 17:41:39 2004 Return-path: To: "'Paul Doolan '" , "'Shah, Himanshu '" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Paul, I quote the following text from Section 3 "The Pseudowire Label" of draft-ietf-pwe3-control-protocol-10.txt: Note that the PW label must always be at the bottom of the packet's label stack and labels MUST be allocated from the per-platform label space. IMHO this specifically answers your concerns and explains why egress PE does not require the knowledge of the actual transport LSP over which the specific PW instance is delivered to it. Regards, Sasha -----Original Message----- From: Paul Doolan To: Shah, Himanshu; pwe3@ietf.org Sent: 10/7/2004 4:42 PM Subject: RE: [PWE3] PW to PSN mapping (again) Himanshu, =20 1,2 and 3 though are operations that occur at the ingress. I=E2=80=99m = still puzzled as to how the egress knows (given any of these tunnel setup methods) over which tunnel a particular pseudowire=E2=80=99s datastream = is going to appear. My concern is unambiguously identifying such a, newly appearing, stream. I can believe that this is possible if the label value signaled (by the egress in this case) is unique for the platform. What I=E2=80=99m not aware of is any statement that _requires_ this to = be true. In draft-ietf-pwe3-control-protocol-10.txt the label is signaled as a =E2=80=9CGeneric Label=E2=80=9D. Does anyone know if there are = semantics associated with that type of label or its use that require it to be unique?=20 =20 And I=E2=80=99ll take a look at your draft=E2=80=A6. thanks Pd=20 =20 -----Original Message----- From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Thursday, October 07, 2004 9:08 AM To: Paul Doolan; pwe3@ietf.org Subject: RE: [PWE3] PW to PSN mapping (again) =20 The service guarentees sold on ACs pretty much dictates what kind of transport tunnels the PW will ride on. You can then,=20 1) either build TE tunnels accordingly and do CAC as you map PWs (of same characteristics) over it. You can apply thresholds that would dictate up or downsizing of tunnel b/w dynamically 2) do BE tunnels 3) manually map PWs over preconfigured suitable transport tunnels. =20 One of the thing an ingress PE may want to take into consideration is = AC characteristics of Egress PE when selecting a transport tunnel from ingress to egress and for applying appropriate traffic policing/shaping at ingress (to avoid packet drops at egress).=20 For this you may want to look at draft-shah-PWE3-pw-qos-signalling-00.txt. (peddling my draft..:-) =20 /himanshu =20 =20 =20 -----Original Message----- From: Paul Doolan [mailto:pdoolan@mangrovesystems.com] Sent: Wednesday, October 06, 2004 4:45 PM To: pwe3@ietf.org Subject: [PWE3] PW to PSN mapping (again) Hello, =20 It=E2=80=99s been a while since I=E2=80=99ve been active in this area = but the fascinating RSVP-TE thread makes it seem like I never left. = Didn=E2=80=99t we see the RSVP vs LDP movie already? Still it=E2=80=99s nice to see that = some of the original combatants are around to clarify the record. Today however I have no questions about RSVP. =20 I would be grateful if any of you can shed some light on a thing = that=E2=80=99s been puzzling me for a little while. Back in August there was a little thread =E2=80=9C[PWE3] PW to PSN tunnel mapping=E2=80=9D started by = Benny L=C3=B8nstrup Ammitzb=C3=B8ll. He asked how a PE might know to which PSN tunnel a PW belongs. Before that thread morphed into the QoS one there was an uchallenged contribution that said it was a matter of local policy at the PE which decided this mapping.=20 =20 Matters of local policy tend to create interoperability problems. In particular this one (if true) might be better stated as = =E2=80=9Cit=E2=80=99s a matter of local policy at the ingress (to which PSN tunnel a PW is = mapped)=E2=80=9D. And the corollary is surely that the egress is SOL in the = =E2=80=98local policy=E2=80=99 department. Perhaps more accurately the egress=E2=80=99s policy options = are binary. It can take pseudowire traffic as and from whence it arrives or it can drop it. Is it really the case that I can open up multiple tunnels to an egress PE and fire off pseudowire traffic down whichever of them I choose and everything will work fine? Or does this depend not only on the local policy of the ingress but also on the vendor implementation at the egress?=20 =20 =20 Paul =20 =20 _____ =20 This message contains information intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately if you received this message by mistake and delete this e-mail from your system. The sender does not accept liability for any errors or = omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com _____ =20 This message contains information intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately if you received this message by mistake and delete this e-mail from your system. The sender does not accept liability for any errors or = omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com <>=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Paul Doolan" Subject: RE: PW to PSN mapping (again) Date: Thu, 7 Oct 2004 11:45:14 -0400 Lines: 33 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Thu Oct 07 18:22:53 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] PW to PSN mapping (again) Thread-Index: AcSsgOKvhRfWUYKJRgCj2l6pTvPZKwAAjG1w To: "Sasha Vainshtein" , "Shah, Himanshu " , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Sasha, > > Note that the PW label must always be at the bottom of the packet's > label stack and labels MUST be allocated from the per-platform label > space. > > >IMHO this specifically answers your concerns and explains why >egress PE does not require the knowledge of the actual transport >LSP over which the specific PW instance is delivered to it. > >Regards, > Sasha =20 This certainly answers one question. The mechanism exists and I apologise for not noticing that. The question as to what implementations actually do still remains though.. Thanks Pd This message contains information intended only for the individual named.= If you are not the named addressee you should not disseminate, distribut= e or copy this email. Please notify the sender immediately if you receive= d this message by mistake and delete this e-mail from your system. The se= nder does not accept liability for any errors or omissions in the content= s of this message, which arise as a result of e-mail transmission. If ver= ification is required please request a hard-copy version. Mangrove System= s, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com= =0A From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Peter Willis Subject: Re: RSVP-TE and PW Date: Thu, 07 Oct 2004 17:16:46 +0100 Lines: 16 Sender: pwe3-bounces@ietf.org References: <41641342.4000609@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tnadeau@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, neil.2.harrison@bt.com, erosen@cisco.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 07 18:34:21 2004 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: Luca Martini In-reply-to: Your message of "Wed, 06 Oct 2004 09:46:10 MDT." <41641342.4000609@cisco.com> X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > > > Neil, I think the problem is the definition of a network. PW switching > just connects wires 1 to 1 in a static mode. I see it as a wire > extension. The early phone network just connected wires to wires in a provisioned mode i.e. call the operator and they connected 2 wires together. And that was not a network?! And if by "static mode" you mean we enter static configuration to stitch together millions of wires in hundreds of boxes then that would be a massive step backwards for service providers. Peter Willis, Office of the BT Group CTO. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Paul Doolan" Subject: RE: PW to PSN mapping (again) Date: Thu, 7 Oct 2004 12:38:16 -0400 Lines: 304 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1748935991==" X-From: pwe3-bounces@ietf.org Thu Oct 07 18:54:55 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] PW to PSN mapping (again) Thread-Index: AcSsfjVIYj+I/odmRPiUYJ63PNIskgACtsvg To: "Shah, Himanshu" , X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1748935991== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AC8C.0BCBC9A8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4AC8C.0BCBC9A8 Content-Type: text/plain; charset="us-ascii" X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Content-Transfer-Encoding: quoted-printable Himanshu, =20 >In most common cases for PWs, PHP is used (and hence per-platform label for PW). >In which case, association to an incoming tunnel is lost. This is good in the sense >that FRR or any other mechanism is not constrained to what incoming interface >an egress PE will get the PW traffic. =20 I can see how that might be useful. =20 >May I ask why do you think it is necessary for egress PE to know on which tunnel >a particular PW traffic would arrive? The PW label carries all the semantics to=20 >forward the traffic out to egress AC (i.e. tunnel label is not used for this)... =20 I don't actually think it is necessary....... if (somewhere) there was a specification that said that in that case where multiple tunnels from the an ingress PE terminate on the (same) egress PE then that PE can make no assumptions about the tunnel on which traffic from a particular PW can arrive. Absent that we rely on policy and implementation choice. Given the unique nature of the label as pointed out by Sasha and the PHP behavior, maybe the point is moot but I still have a nagging feeling that expected behavior in this scenario is underspecified. =20 =20 BTW: Apologies to all for the boilerplate verbiage at the bottom of this. I'm working on getting it removed.=20 =20 pd =20 =20 =20 This message contains information intended only for the individual named.= If you are not the named addressee you should not disseminate, distribut= e or copy this email. Please notify the sender immediately if you receive= d this message by mistake and delete this e-mail from your system. The se= nder does not accept liability for any errors or omissions in the content= s of this message, which arise as a result of e-mail transmission. If ver= ification is required please request a hard-copy version. Mangrove System= s, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com= =0A ------_=_NextPart_001_01C4AC8C.0BCBC9A8 Content-Type: text/HTML; charset="us-ascii" X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Content-Transfer-Encoding: quoted-printable

Himanshu,

 

>In most common cases for PWs, PH= P is used (and hence per-platform label for PW).

>In which case, association to an incoming tunnel is lost. This is good in the sense

>that FRR or any other mechanism = is not constrained to what incoming interface

>an egress PE will get the PW tra= ffic.

 

I can see how that might be useful.<= /span>

 

>May I ask why do you think it is necessary for egress PE to know on which tunnel

>a particular PW traffic would ar= rive? The PW label carries all the semantics to

>forward the traffic out to egres= s AC (i.e. tunnel label is not used for this)...

 

I don’t actually think it is n= ecessary……. if (somewhere) there was a specification that said that in that case where multiple tunnels from the an ingress PE terminate on the (same) egress PE= then that PE can make no assumptions about the tunnel on which traffic from a particular PW can arrive. Absent that we rely on policy and implementatio= n choice. Given the unique nature of the label as pointed out by Sasha and = the PHP behavior, maybe the point is moot but I still have a nagging feeling that= expected behavior in this scenario is underspecified.  

 

BTW: Apologies to all for the boiler= plate verbiage at the bottom of this.

I’m working on getting it remo= ved.

 

pd

 

 

 

This message contains information intended only for the individual named.= If you are not the named addressee you should not disseminate, distribut= e or copy this email. Please notify the sender immediately if you receive= d this message by mistake and delete this e-mail from your system. The se= nder does not accept liability for any errors or omissions in the content= s of this message, which arise as a result of e-mail transmission. If ver= ification is required please request a hard-copy version. Mangrove System= s, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com=
=0A

------_=_NextPart_001_01C4AC8C.0BCBC9A8-- --===============1748935991== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1748935991==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Thomas D. Nadeau" Subject: Re: RSVP-TE and PW Date: Thu, 7 Oct 2004 13:41:37 -0400 Lines: 37 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, Benny.Ammitzboell@tpack.net, neil.2.harrison@bt.com, erosen@cisco.com, Luca Martini , stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 07 20:39:41 2004 Return-path: X-BrightmailFiltered: true In-Reply-To: To: Peter Willis X-Mailer: Apple Mail (2.619) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, I don't think that is the point he was making, at least not as I understood it. I don't see stitching PWs together as anything different than bridging/patching two enet segments together. This seems to fit well within the PWE3 charter of p2p pwe3s. HOWEVER, if we start talking about automatically patching these together, then this requires more intelligence such as the form of some routing protocol. This is the purview of the L2VPN WG, which I do agree constitutes another 'layer'. --Tom > >>> >> Neil, I think the problem is the definition of a network. PW switching >> just connects wires 1 to 1 in a static mode. I see it as a wire >> extension. > > The early phone network just connected wires to wires in a provisioned > mode > i.e. call the operator and they connected 2 wires together. And that > was not a > network?! > > And if by "static mode" you mean we enter static configuration to > stitch > together millions of wires in hundreds of boxes then that would be a > massive > step backwards for service providers. > > Peter Willis, > Office of the BT Group CTO. > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-07.txt Date: Thu, 07 Oct 2004 15:34:51 -0400 Lines: 99 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Oct 07 22:38:11 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) Author(s) : L. Martini, M. Townsley Filename : draft-ietf-pwe3-iana-allocation-07.txt Pages : 6 Date : 2004-10-7 The Control and maintenance protocol for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [2]. This document pre-allocates the fixed Pseudo-wire identifier , and other fixed protocol values that are to be assigned by IANA using the 'IETF Consensus' policy defined in RFC2434 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-iana-allocation-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-iana-allocation-07.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-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-control-protocol-11.txt Date: Thu, 07 Oct 2004 15:35:00 -0400 Lines: 102 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Oct 07 22:44:44 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --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, et al. Filename : draft-ietf-pwe3-control-protocol-11.txt Pages : 41 Date : 2004-10-7 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 low-rate TDM and 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-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-control-protocol-11.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-11.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-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: C-bit negotiation in draft-ietf-pwe3-control-protocol-10.txt Date: Thu, 07 Oct 2004 18:17:37 -0600 Organization: Cisco Systems Lines: 36 Sender: pwe3-bounces@ietf.org References: <41626C2C.90000@mail4us.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Oct 08 02:34:48 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: Kjeld Borch Egevang In-Reply-To: <41626C2C.90000@mail4us.dk> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Kjeld Borch Egevang wrote: > In "6.2. PW types for which the control word is NOT mandatory". Why is > this complicated behaviour introduced? Why not do almost the same as > in 6.1, i.e: > I'm not completely clear on what your point is , but the C-bit negotiation has been implemented, deployed and works well. The advantage is to be able to inter-operate with some platforms that might not implement the CW , while still use it if possible. Luca > -iii. If the received Label Mapping message has c=1, and the PW is > locally configured such that the use of the control word is > not preferred or the control word is not supported, then > send a Label Release message with the "Wrong c-bit" status > code. > > and receive behaviour: > > -iii. A Label Release with a "Wrong c-bit" status code and the > Label Mapping message that was sent has c=1. In this case, > send a Label Mapping message that has c=0. The control word > is not used. > > /Kjeld > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: RSVP-TE and PW Date: Thu, 07 Oct 2004 22:45:10 -0600 Organization: Cisco Systems Lines: 58 Sender: pwe3-bounces@ietf.org References: <23CAEC12-1888-11D9-A26E-000D93AD480A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, Benny.Ammitzboell@tpack.net, Peter Willis , neil.2.harrison@bt.com, erosen@cisco.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Fri Oct 08 06:50:21 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: "Thomas D. Nadeau" In-Reply-To: <23CAEC12-1888-11D9-A26E-000D93AD480A@cisco.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, I just want to add to Tom's comment , that I believe this is just a starting point. Like PW where used to build VPLS, or MPLS to build GMPLS. There should be nothing in the pw-switching draft preventing anyone from creating a new network layer if they wish. PW switching connects wires with only only going to one fixed destination, which does not change. That would make a pretty boring phone network wouldn't it ? :-) Anyway I believe that the PW switching draft should be targeted as an informational RFC, as it does not really even create a new protocol. Whether it is useful or not is a matter of personal opinion. Luca Thomas D. Nadeau wrote: > > Peter, I don't think that is the point he was > making, at least not as I understood it. > I don't see stitching PWs together as anything > different than bridging/patching two enet segments > together. This seems to fit well within the PWE3 > charter of p2p pwe3s. HOWEVER, if we start talking about > automatically patching these together, then this requires > more intelligence such as the form of some > routing protocol. This is the purview > of the L2VPN WG, which I do agree constitutes > another 'layer'. > > --Tom > > >> >>>> >>> Neil, I think the problem is the definition of a network. PW switching >>> just connects wires 1 to 1 in a static mode. I see it as a wire >>> extension. >> >> >> The early phone network just connected wires to wires in a >> provisioned mode >> i.e. call the operator and they connected 2 wires together. And that >> was not a >> network?! >> >> And if by "static mode" you mean we enter static configuration to stitch >> together millions of wires in hundreds of boxes then that would be a >> massive >> step backwards for service providers. >> >> Peter Willis, >> Office of the BT Group CTO. >> > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Kjeld Borch Egevang Subject: Re: C-bit negotiation in draft-ietf-pwe3-control-protocol-10.txt Date: Fri, 08 Oct 2004 09:15:37 +0200 Lines: 19 Sender: pwe3-bounces@ietf.org References: <41626C2C.90000@mail4us.dk> <4165DCA1.3000500@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Oct 08 09:24:28 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040817 X-Accept-Language: en-us, en To: Luca Martini In-Reply-To: <4165DCA1.3000500@cisco.com> X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca Martini wrote: > > > Kjeld Borch Egevang wrote: > >> In "6.2. PW types for which the control word is NOT mandatory". Why >> is this complicated behaviour introduced? Why not do almost the same >> as in 6.1, i.e: >> > I'm not completely clear on what your point is , but the C-bit > negotiation has been implemented, deployed and works well. > The advantage is to be able to inter-operate with some platforms that > might not implement the CW , while still use it if possible. But the document has not been accepted as a standard yet, right? Isn't it reasonable to change the draft if something can be simplified? /Kjeld From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Choudhary, Aseem (Aseem)" Subject: RE: PW to PSN mapping (again) Date: Fri, 8 Oct 2004 12:55:34 +0530 Lines: 294 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1063514433==" X-From: pwe3-bounces@ietf.org Fri Oct 08 09:32:26 2004 Return-path: To: pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1063514433== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AD08.0018D00A" 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_01C4AD08.0018D00A Content-Type: text/plain I have a question: If PW can take any PSN tunnel reachable to egress PE(assuming multiple PSN Tunnels from ingress PE to egress PE are available), then which PSN tunnel should be configured ( data plane) at egress PE to receive a particular PW label.One obvious option is static configuration where we bind PW label (inner label) to the PSN tunnel(outer label). The other option could be PW signalling should support which PSN tunnel it would take. Aseem -----Original Message----- From: Paul Doolan [mailto:pdoolan@mangrovesystems.com] Sent: Thursday, October 07, 2004 10:08 PM To: Shah, Himanshu; pwe3@ietf.org Subject: RE: [PWE3] PW to PSN mapping (again) Himanshu, >In most common cases for PWs, PHP is used (and hence per-platform label for PW). >In which case, association to an incoming tunnel is lost. This is good in the sense >that FRR or any other mechanism is not constrained to what incoming interface >an egress PE will get the PW traffic. I can see how that might be useful. >May I ask why do you think it is necessary for egress PE to know on which tunnel >a particular PW traffic would arrive? The PW label carries all the semantics to >forward the traffic out to egress AC (i.e. tunnel label is not used for this)... I don't actually think it is necessary....... if (somewhere) there was a specification that said that in that case where multiple tunnels from the an ingress PE terminate on the (same) egress PE then that PE can make no assumptions about the tunnel on which traffic from a particular PW can arrive. Absent that we rely on policy and implementation choice. Given the unique nature of the label as pointed out by Sasha and the PHP behavior, maybe the point is moot but I still have a nagging feeling that expected behavior in this scenario is underspecified. BTW: Apologies to all for the boilerplate verbiage at the bottom of this. I'm working on getting it removed. pd _____ This message contains information intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately if you received this message by mistake and delete this e-mail from your system. The sender does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com ------_=_NextPart_001_01C4AD08.0018D00A Content-Type: text/html
 
I have a question:
 
 If PW can take any PSN tunnel reachable to egress PE(assuming multiple PSN Tunnels from ingress PE to egress PE are available), then which PSN tunnel should be configured ( data plane) at egress PE to receive a particular PW label.One obvious option is static configuration where we bind PW label (inner label) to the PSN tunnel(outer label). The other option could be PW signalling should support which PSN tunnel it would take.
 
Aseem
 
 -----Original Message-----
From: Paul Doolan [mailto:pdoolan@mangrovesystems.com]
Sent: Thursday, October 07, 2004 10:08 PM
To: Shah, Himanshu; pwe3@ietf.org
Subject: RE: [PWE3] PW to PSN mapping (again)

Himanshu,

 

>In most common cases for PWs, PHP is used (and hence per-platform label for PW).

>In which case, association to an incoming tunnel is lost. This is good in the sense

>that FRR or any other mechanism is not constrained to what incoming interface

>an egress PE will get the PW traffic.

 

I can see how that might be useful.

 

>May I ask why do you think it is necessary for egress PE to know on which tunnel

>a particular PW traffic would arrive? The PW label carries all the semantics to

>forward the traffic out to egress AC (i.e. tunnel label is not used for this)...

 

I don’t actually think it is necessary……. if (somewhere) there was a specification that said that in that case where multiple tunnels from the an ingress PE terminate on the (same) egress PE then that PE can make no assumptions about the tunnel on which traffic from a particular PW can arrive. Absent that we rely on policy and implementation choice. Given the unique nature of the label as pointed out by Sasha and the PHP behavior, maybe the point is moot but I still have a nagging feeling that expected behavior in this scenario is underspecified.  

 

BTW: Apologies to all for the boilerplate verbiage at the bottom of this.

I’m working on getting it removed.

 

pd

 

 

 

This message contains information intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately if you received this message by mistake and delete this e-mail from your system. The sender does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com

------_=_NextPart_001_01C4AD08.0018D00A-- --===============1063514433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1063514433==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Peter Willis Subject: Re: RSVP-TE and PW Date: Fri, 08 Oct 2004 09:05:54 +0100 Lines: 71 Sender: pwe3-bounces@ietf.org References: <41661B56.7060305@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Thomas D. Nadeau" , pwe3@ietf.org, Benny.Ammitzboell@tpack.net, Peter Willis , neil.2.harrison@bt.com, erosen@cisco.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Fri Oct 08 10:14:29 2004 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: Luca Martini In-reply-to: Your message of "Thu, 07 Oct 2004 22:45:10 MDT." <41661B56.7060305@cisco.com> X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org So in other words are we saying that to do anything useful with PW stitching i.e. create a network, we need to go to the L2VPN WG? Is anything happening in the L2VPN WG to address PW stitching? Peter. > Peter, > > I just want to add to Tom's comment , that I believe this is just a > starting point. Like PW where used to build VPLS, or MPLS to build GMPLS. > There should be nothing in the pw-switching draft preventing anyone from > creating a new network layer if they wish. > PW switching connects wires with only only going to one fixed > destination, which does not change. That would make a pretty boring > phone network wouldn't it ? > :-) > Anyway I believe that the PW switching draft should be targeted as an > informational RFC, as it does not really even create a new protocol. > Whether it is useful or not is a matter of personal opinion. > > Luca > > > Thomas D. Nadeau wrote: > > > > > Peter, I don't think that is the point he was > > making, at least not as I understood it. > > I don't see stitching PWs together as anything > > different than bridging/patching two enet segments > > together. This seems to fit well within the PWE3 > > charter of p2p pwe3s. HOWEVER, if we start talking about > > automatically patching these together, then this requires > > more intelligence such as the form of some > > routing protocol. This is the purview > > of the L2VPN WG, which I do agree constitutes > > another 'layer'. > > > > --Tom > > > > > >> > >>>> > >>> Neil, I think the problem is the definition of a network. PW switching > >>> just connects wires 1 to 1 in a static mode. I see it as a wire > >>> extension. > >> > >> > >> The early phone network just connected wires to wires in a > >> provisioned mode > >> i.e. call the operator and they connected 2 wires together. And that > >> was not a > >> network?! > >> > >> And if by "static mode" you mean we enter static configuration to stitch > >> together millions of wires in hundreds of boxes then that would be a > >> massive > >> step backwards for service providers. > >> > >> Peter Willis, > >> Office of the BT Group CTO. > >> > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: richard.spencer@bt.com Subject: RE: RSVP-TE and PW Date: Fri, 8 Oct 2004 09:47:41 +0100 Lines: 36 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, Benny.Ammitzboell@tpack.net, neil.2.harrison@bt.com, erosen@cisco.com, lmartini@cisco.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Fri Oct 08 10:53:36 2004 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSsnS08QPZW38/NS0mcaiMUP7zqpQAZRzkw To: , X-OriginalArrivalTime: 08 Oct 2004 08:47:42.0679 (UTC) FILETIME=[79732670:01C4AD13] X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Tom, > I don't see stitching PWs together as anything > different than bridging/patching two enet segments > together. I must admit I am quite shocked by this response. I fail to see how you = can consider PW stitching to be analogous to bridging/patching two = Ethernet segments together. - (Transparent) bridging occurs in the data plane using MAC addresses = and allows connectionless flows to be transmitted between different = Ethernet segments. No configuration or control plane functions are = required at the Ethernet layer other than spanning tree to protect = against loops and the actual physical connection (also requires VLAN = configuration if employed). - PW stitching requires control/management plane functions to establish = a P2P connection and allows MPLS packets to be transmitted between the = connections source/sink termination points. Before any packets can be = forwarded MPLS labels must be signalled or manually configured and = before that a route/path between the source/sink PW termination points = must be calculated/selected if alternative switching points between the = source and sink exist. Considering the fact that: Control/management plane configuration/maintenance =3D operational cost please can you clarify why it is that you consider the differences = between the two to be insignificant, and also explain what the = similarities are (beyond the fact that two network partions are being = connected). Thanks, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: =?us-ascii?Q?Benny_Ammitzboll?= Subject: RE: PW to PSN mapping (again) Date: Fri, 8 Oct 2004 11:06:23 +0200 Lines: 84 Sender: pwe3-bounces@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D20F7FAA57@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Fri Oct 08 11:09:11 2004 Return-path: To: "Choudhary, Aseem \(Aseem\)" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D20F7FAA57@ii0015exch002u.iprc.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The answer is: None, because the egress PE does not need to know (in fact, in some systems it does not know) on which PSN tunnel the packet with a PW label was received. The PW label uniquely identifies the PW in the egress PE. Note that this also allows the ingress PE to select another PSN tunnel without any signaling from the ingress to the egress PE. Regards, Benny Ammitzboll -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of Choudhary, Aseem (Aseem) Sent: 8. oktober 2004 09:26 To: pwe3@ietf.org Subject: RE: [PWE3] PW to PSN mapping (again) I have a question: If PW can take any PSN tunnel reachable to egress PE(assuming multiple PSN Tunnels from ingress PE to egress PE are available), then which PSN tunnel should be configured ( data plane) at egress PE to receive a particular PW label.One obvious option is static configuration where we bind PW label (inner label) to the PSN tunnel(outer label). The other option could be PW signalling should support which PSN tunnel it would take. Aseem -----Original Message----- From: Paul Doolan [mailto:pdoolan@mangrovesystems.com] Sent: Thursday, October 07, 2004 10:08 PM To: Shah, Himanshu; pwe3@ietf.org Subject: RE: [PWE3] PW to PSN mapping (again) Himanshu, >In most common cases for PWs, PHP is used (and hence per-platform label for PW). >In which case, association to an incoming tunnel is lost. This is good in the sense >that FRR or any other mechanism is not constrained to what incoming interface >an egress PE will get the PW traffic. I can see how that might be useful. >May I ask why do you think it is necessary for egress PE to know on which tunnel >a particular PW traffic would arrive? The PW label carries all the semantics to >forward the traffic out to egress AC (i.e. tunnel label is not used for this)... I don't actually think it is necessary... if (somewhere) there was a specification that said that in that case where multiple tunnels from the an ingress PE terminate on the (same) egress PE then that PE can make no assumptions about the tunnel on which traffic from a particular PW can arrive. Absent that we rely on policy and implementation choice. Given the unique nature of the label as pointed out by Sasha and the PHP behavior, maybe the point is moot but I still have a nagging feeling that expected behavior in this scenario is underspecified. BTW: Apologies to all for the boilerplate verbiage at the bottom of this. I'm working on getting it removed. pd This message contains information intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately if you received this message by mistake and delete this e-mail from your system. The sender does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: richard.spencer@bt.com Subject: RE: RSVP-TE and PW Date: Fri, 8 Oct 2004 10:50:22 +0100 Lines: 60 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, Benny.Ammitzboell@tpack.net, pjw@ip-engineering.bt.com, neil.2.harrison@bt.com, erosen@cisco.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Fri Oct 08 11:55:00 2004 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSs8rJK6XfkeKSvTPmyvBNPGJq96QAF0dvg To: , X-OriginalArrivalTime: 08 Oct 2004 09:50:23.0033 (UTC) FILETIME=[3ACBA290:01C4AD1C] X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca, > There should be nothing in the pw-switching draft preventing=20 > anyone from creating a new network layer if they wish. If a provider uses PW-switching they are creating a new network layer = whether they wish to or not. Please consider the following simple examples that illustrate server = layer topologies/trails (i.e. tunnel LSPs), which may be used for = carrying switched PWs: (i) [U-PE1]----[S-PE1]-----U-PE2] (ii) [U-PE1]----[S-PE1]-----U-PE2]=20 \ / \-----[S-PE2]-----/ To establish a MH-PW in (i), because there is only one switching node, = only one path/route exists (i.e. there is no need for route/path = selection) but the route/path must still be determined either by using = dynamic protocols, manual methods or OSS, i.e. the PW switching node = must be identified before the two separate PWs can be 'stitched' = together. To establish a MH-PW in (ii), two alternate route/paths exist and = therefore the best route must be calculated and selected before = establishing the two separate PWs and stitching them together.=20 Anyway, whether you consider PW switching to create a new layer or not, = PW switching introduces new requirements that do not apply to single hop = PWs. From a technical perspective PW switching requires: o Switching node discovery o Route calculation and selection if alternative switching nodes exist o Stitching separate PWs together o Interworking at switching points, including: - Data plane interworking (e.g. L2TP to MPLS) - Control plane interworking (e.g. L2TP to LDP) - OAM message interworking >From a business perspective, each of these new functions that are = required adds operational cost, especially if an operator needs to = develop their own OSS to provision/maintain switched PWs. I'm not saying that there isn't a need for PW switching. On the = contrary, if providers decide to push MPLS out to the edge aggregation = layer resulting in a network with tens of thousands of PEs, then PW = switching offers one potential solution to scale end-to-end PWs in the = control plane (whilst keeping access aggregation device costs at a = feasible level).=20 I'm just saying that whether you believe PW switching creates a new = layer or not, it introduces a number of new requirements that must be = addressed for PW switching to become a viable solution. Hopefully these = will be identified in the PW switching requirements draft that is = currently being worked on. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: richard.spencer@bt.com Subject: RE: RSVP-TE and PW Date: Fri, 8 Oct 2004 10:56:48 +0100 Lines: 28 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, Benny.Ammitzboell@tpack.net, pjw@ip-engineering.bt.com, neil.2.harrison@bt.com, erosen@cisco.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Fri Oct 08 11:57:58 2004 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSs8rJK6XfkeKSvTPmyvBNPGJq96QAJZLpQ To: , X-OriginalArrivalTime: 08 Oct 2004 09:56:49.0239 (UTC) FILETIME=[20FDFE70:01C4AD1D] X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca, > PW switching connects wires with only only going to one fixed=20 > destination, which does not change. That would make a pretty boring=20 > phone network wouldn't it ? :-) I don't think this analogy makes sense, you are comparing connection = hold times to network functionality, i.e. you are comparing apples to = pears. The above could be re-written "Voice switching connects wires only going = to one fixed destination, which does not change." With the 'does not = change' referring to the duration of the call. - Prior to call setup, a user selects which number they want to call, = once the call is made and the connection established, the connection to = the fixed destination exists until the call is taken down. - Prior to PW establishment, an operator selects which U-PEs they need = to connect, once the PW is established, the connection to the fixed = destination exists until the PW is taken down. The connection hold times may be different, but the network = functionality (i.e. the ability to establish a connection between = source/sink termination points) is the same. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Nick Weeds Subject: Group IDs in draft-pwe3-control-protocol-11.txt Date: Fri, 8 Oct 2004 14:11:00 +0100 Lines: 27 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "pwe3@ietf.org \(E-mail\)" X-From: pwe3-bounces@ietf.org Fri Oct 08 15:24:33 2004 Return-path: To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca, A question on draft-ietf-pwe3-control-protocol-11.txt: Suppose we have PWs with the same group id but a mix of PWid and Generalized ID FECs - for example the PWid PWs have group id 1 and the Generalised ID PWs have PW Grouping id 1. Are these PWs considered to belong to the same group or to two distinct groups? Would a wildcard Label Withdraw with PWid FEC and group id 1 withdraw all these PWs (including Generalized ID ones) or just the PWid PWs? - Sections 5.1 and 5.2.2 describe the PWid group id and the PW Grouping ID as essentially the same, but use different terms, so it is unclear whether they refer to the same group or distinct groups. - Page 22 paragraph 1 (in section 5.3.2) might suggest that they are the same group, and a single Notification message applies to both PWid and Generalized ID FECs, but that might be reading too much into it. - Section 6.3 can be read either way. Clarification of this would certainly help implementation and probably inter-operability too. Nick. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: Group IDs in draft-pwe3-control-protocol-11.txt Date: Fri, 08 Oct 2004 09:58:01 -0600 Organization: Cisco Systems Lines: 73 Sender: pwe3-bounces@ietf.org References: <16E71652255A3E4796A7AF3A9E5068F90304B9@blakey.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org \(E-mail\)" X-From: pwe3-bounces@ietf.org Fri Oct 08 18:00:08 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: Nick Weeds In-Reply-To: <16E71652255A3E4796A7AF3A9E5068F90304B9@blakey.datcon.co.uk> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Nick Weeds wrote: >Luca, > >A question on draft-ietf-pwe3-control-protocol-11.txt: > >Suppose we have PWs with the same group id but a mix of PWid and Generalized >ID FECs - for example the PWid PWs have group id 1 and the Generalised ID >PWs have PW Grouping id 1. > >Are these PWs considered to belong to the same group or to two distinct >groups? > > Two distinct groups as it's 2 distinct FEC types. >Would a wildcard Label Withdraw with PWid FEC and group id 1 withdraw all >these PWs (including Generalized ID ones) or just the PWid PWs? > > > Since you have to send a FEC type , I would say that it withdraws only the PW for the FEC you sent. >- Sections 5.1 and 5.2.2 describe the PWid group id and the PW Grouping ID >as essentially the same, but use different terms, so it is unclear whether >they refer to the same group or distinct groups. > > > Since one is a TLV , and the other one is embedded with the FEC I take them to be different. ( even the name is different ;-) ) >- Page 22 paragraph 1 (in section 5.3.2) might suggest that they are the >same group, and a single Notification message applies to both PWid and >Generalized ID FECs, but that might be reading too much into it. > > > ok, I found an unwanted reference to appendix B, which was removed ... I also found the following text : " As mentioned above the Group ID field of the PWid FEC element, or the PW Grouping ID TLV used with the Generalized ID FEC element, can be used to send a status notification for all arbitrary sets of PWs." This does NOT mean that the Group ID and the Grouping ID are the same space. ( they refer 2 two different FECs ). I meant to say that they have similar functionality for their respective applications ( FECs ). >- Section 6.3 can be read either way. > >Clarification of this would certainly help implementation and probably >inter-operability too. > > > Yes I see, another bug in the text. I'll fix the grammar to be more clear. Thanks. Luca > Nick. > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: PW to PSN mapping (again) Date: Fri, 8 Oct 2004 19:58:35 +0200 Lines: 115 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-bounces@ietf.org Fri Oct 08 20:27:07 2004 Return-path: To: "'Choudhary, Aseem (Aseem) '" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Aseem, I have a counter-question: Why do you think the egress PE should require any binding between the PSN tunnel and the PW label? IMHO, no such binding is required (and hence no method to achieve it is provided:-). Instead, the PW labels are allocated from the per-platform space. And, as Himanshu has just explained, in certain cases such a binding would be definitely harmful. Regards, Sasha -----Original Message----- From: Choudhary, Aseem (Aseem) To: pwe3@ietf.org Sent: 10/8/2004 9:25 AM Subject: RE: [PWE3] PW to PSN mapping (again) I have a question: If PW can take any PSN tunnel reachable to egress PE(assuming multiple PSN Tunnels from ingress PE to egress PE are available), then which PSN tunnel should be configured ( data plane) at egress PE to receive a particular PW label.One obvious option is static configuration where we bind PW label (inner label) to the PSN tunnel(outer label). The other option could be PW signalling should support which PSN tunnel it would take. Aseem -----Original Message----- From: Paul Doolan [mailto:pdoolan@mangrovesystems.com] Sent: Thursday, October 07, 2004 10:08 PM To: Shah, Himanshu; pwe3@ietf.org Subject: RE: [PWE3] PW to PSN mapping (again) Himanshu, >In most common cases for PWs, PHP is used (and hence per-platform label for PW). >In which case, association to an incoming tunnel is lost. This is good in the sense >that FRR or any other mechanism is not constrained to what incoming interface >an egress PE will get the PW traffic. I can see how that might be useful. >May I ask why do you think it is necessary for egress PE to know on which tunnel >a particular PW traffic would arrive? The PW label carries all the semantics to >forward the traffic out to egress AC (i.e. tunnel label is not used for this)... I don't actually think it is necessary....... if (somewhere) there was a specification that said that in that case where multiple tunnels from the an ingress PE terminate on the (same) egress PE then that PE can make no assumptions about the tunnel on which traffic from a particular PW can arrive. Absent that we rely on policy and implementation choice. Given the unique nature of the label as pointed out by Sasha and the PHP behavior, maybe the point is moot but I still have a nagging feeling that expected behavior in this scenario is underspecified. BTW: Apologies to all for the boilerplate verbiage at the bottom of this. I'm working on getting it removed. pd _____ This message contains information intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately if you received this message by mistake and delete this e-mail from your system. The sender does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Mangrove Systems, Inc. 10 Fairfield Blvd, Wallingford, CT 06492. www.mangrovesystems.com <> From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: C-bit negotiation in draft-ietf-pwe3-control-protocol-10.txt Date: Fri, 08 Oct 2004 12:11:18 -0600 Organization: Cisco Systems Lines: 35 Sender: pwe3-bounces@ietf.org References: <41626C2C.90000@mail4us.dk> <4165DCA1.3000500@cisco.com> <41663E99.6040204@mail4us.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Fri Oct 08 20:29:16 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: Kjeld Borch Egevang In-Reply-To: <41663E99.6040204@mail4us.dk> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Actually the document has gone past last call , and is in the AD queue. All I can do at this point is fix english grammar , or spelling. Also the WG seems to have consensus of keeping this functionality in. Luca Kjeld Borch Egevang wrote: > Luca Martini wrote: > >> >> >> Kjeld Borch Egevang wrote: >> >>> In "6.2. PW types for which the control word is NOT mandatory". Why >>> is this complicated behaviour introduced? Why not do almost the same >>> as in 6.1, i.e: >>> >> I'm not completely clear on what your point is , but the C-bit >> negotiation has been implemented, deployed and works well. >> The advantage is to be able to inter-operate with some platforms that >> might not implement the CW , while still use it if possible. > > > But the document has not been accepted as a standard yet, right? Isn't > it reasonable to change the draft if something can be simplified? > > /Kjeld > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: RSVP-TE and PW Date: Fri, 08 Oct 2004 12:14:43 -0600 Organization: Cisco Systems Lines: 96 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , pwe3@ietf.org, Benny.Ammitzboell@tpack.net, neil.2.harrison@bt.com, erosen@cisco.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Fri Oct 08 20:32:15 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: Peter Willis In-Reply-To: X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter Willis wrote: >So in other words are we saying that to do anything useful with PW stitching >i.e. create a network, we need to go to the L2VPN WG? > > > yes. Luca >Is anything happening in the L2VPN WG to address PW stitching? > >Peter. > > >>Peter, >> >>I just want to add to Tom's comment , that I believe this is just a >>starting point. Like PW where used to build VPLS, or MPLS to build GMPLS. >>There should be nothing in the pw-switching draft preventing anyone from >>creating a new network layer if they wish. >>PW switching connects wires with only only going to one fixed >>destination, which does not change. That would make a pretty boring >>phone network wouldn't it ? >>:-) >>Anyway I believe that the PW switching draft should be targeted as an >>informational RFC, as it does not really even create a new protocol. >>Whether it is useful or not is a matter of personal opinion. >> >>Luca >> >> >>Thomas D. Nadeau wrote: >> >> >> >>> Peter, I don't think that is the point he was >>>making, at least not as I understood it. >>>I don't see stitching PWs together as anything >>>different than bridging/patching two enet segments >>>together. This seems to fit well within the PWE3 >>>charter of p2p pwe3s. HOWEVER, if we start talking about >>>automatically patching these together, then this requires >>>more intelligence such as the form of some >>>routing protocol. This is the purview >>>of the L2VPN WG, which I do agree constitutes >>>another 'layer'. >>> >>> --Tom >>> >>> >>> >>> >>>>>Neil, I think the problem is the definition of a network. PW switching >>>>>just connects wires 1 to 1 in a static mode. I see it as a wire >>>>>extension. >>>>> >>>>> >>>>The early phone network just connected wires to wires in a >>>>provisioned mode >>>>i.e. call the operator and they connected 2 wires together. And that >>>>was not a >>>>network?! >>>> >>>>And if by "static mode" you mean we enter static configuration to stitch >>>>together millions of wires in hundreds of boxes then that would be a >>>>massive >>>>step backwards for service providers. >>>> >>>>Peter Willis, >>>>Office of the BT Group CTO. >>>> >>>> >>>> >>> >>> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: RSVP-TE and PW Date: Fri, 8 Oct 2004 20:23:50 +0200 Lines: 53 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'pwe3@ietf.org '" , "'Benny.Ammitzboell@tpack.net '" , "'pjw@ip-engineering.bt.com '" , "'neil.2.harrison@bt.com '" , "'erosen@cisco.com '" , "'stbryant@cisco.com '" X-From: pwe3-bounces@ietf.org Fri Oct 08 20:48:49 2004 Return-path: To: "'richard.spencer@bt.com '" , "'lmartini@cisco.com '" , "'tnadeau@cisco.com '" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard and all, Please see a few comments inline below (marked [Sasha]). I've snipped some text to make the message readable. Regards, Sasha -----Original Message----- From: richard.spencer@bt.com To: lmartini@cisco.com; tnadeau@cisco.com Cc: pwe3@ietf.org; Benny.Ammitzboell@tpack.net; pjw@ip-engineering.bt.com; neil.2.harrison@bt.com; erosen@cisco.com; stbryant@cisco.com Sent: 10/8/2004 11:50 AM Subject: RE: [PWE3] RSVP-TE and PW ... snipped ... Anyway, whether you consider PW switching to create a new layer or not, PW switching introduces new requirements that do not apply to single hop PWs. From a technical perspective PW switching requires: o Switching node discovery o Route calculation and selection if alternative switching nodes exist o Stitching separate PWs together o Interworking at switching points, including: - Data plane interworking (e.g. L2TP to MPLS) - Control plane interworking (e.g. L2TP to LDP) - OAM message interworking [Sasha] I agree with these points and would even add a few, e.g.: [Sasha] o Detection of the switching node failure and appropriate [Sasha] correvtive actions to provide resilientce (note that PW segments [Sasha] presumably can rely on the PSN resilience mechanisms, but [Sasha] stitching node failures are different) [Sasha] o Per-segment OAM mechanisms as opposed to end-to-end [Sasha] PW OAM) [Sasha] There can be more... and, IMHO, just as these problems EXIST [Sasha] regardless of whether PW stitching is called a new network [Sasha] layer or not, neither is the SOLUTION provided [Sasha] by adopting this or that terminology. ... snipped ... I'm just saying that whether you believe PW switching creates a new layer or not, it introduces a number of new requirements that must be addressed for PW switching to become a viable solution. Hopefully these will be identified in the PW switching requirements draft that is currently being worked on. [Sasha] I would be happy to join you in this hope. But I have [Sasha] not seen much progress yet. ... snipped to the end ... From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Vach Kompella" Subject: RE: RSVP-TE and PW Date: Fri, 8 Oct 2004 11:41:04 -0700 Organization: Alcatel USA Lines: 123 Sender: pwe3-bounces@ietf.org References: <4166D913.1080706@cisco.com> Reply-To: vach.kompella@alcatel.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Fri Oct 08 20:59:46 2004 Return-path: To: "'Luca Martini'" , "'Peter Willis'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal In-Reply-To: <4166D913.1080706@cisco.com> X-OriginalArrivalTime: 08 Oct 2004 18:41:05.0482 (UTC) FILETIME=[5E5FC2A0:01C4AD66] X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I agree with Luca. This seems to be in keeping with the charters of both pwe3 and l2vpn. -Vach=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Luca Martini > Sent: Friday, October 08, 2004 11:15 AM > To: Peter Willis > Cc: Thomas D. Nadeau; pwe3@ietf.org;=20 > Benny.Ammitzboell@tpack.net; neil.2.harrison@bt.com;=20 > erosen@cisco.com; stbryant@cisco.com > Subject: Re: [PWE3] RSVP-TE and PW >=20 >=20 >=20 >=20 > Peter Willis wrote: >=20 > >So in other words are we saying that to do anything useful with PW=20 > >stitching > >i.e. create a network, we need to go to the L2VPN WG?=20 > > > > =20 > > > yes. >=20 > Luca >=20 > >Is anything happening in the L2VPN WG to address PW stitching? > > > >Peter. > > =20 > > > >>Peter, > >> > >>I just want to add to Tom's comment , that I believe this is just a > >>starting point. Like PW where used to build VPLS, or MPLS=20 > to build GMPLS. > >>There should be nothing in the pw-switching draft=20 > preventing anyone from=20 > >>creating a new network layer if they wish. > >>PW switching connects wires with only only going to one fixed=20 > >>destination, which does not change. That would make a pretty boring=20 > >>phone network wouldn't it ? > >>:-) > >>Anyway I believe that the PW switching draft should be=20 > targeted as an=20 > >>informational RFC, as it does not really even create a new protocol. > >>Whether it is useful or not is a matter of personal opinion. > >> > >>Luca > >> > >> > >>Thomas D. Nadeau wrote: > >> > >> =20 > >> > >>> Peter, I don't think that is the point he was > >>>making, at least not as I understood it. > >>>I don't see stitching PWs together as anything > >>>different than bridging/patching two enet segments > >>>together. This seems to fit well within the PWE3 > >>>charter of p2p pwe3s. HOWEVER, if we start talking about=20 > >>>automatically patching these together, then this requires more=20 > >>>intelligence such as the form of some routing protocol.=20 > This is the=20 > >>>purview of the L2VPN WG, which I do agree constitutes > >>>another 'layer'. > >>> > >>> --Tom > >>> > >>> > >>> =20 > >>> > >>>>>Neil, I think the problem is the definition of a network. PW=20 > >>>>>switching just connects wires 1 to 1 in a static mode. I=20 > see it as=20 > >>>>>a wire extension. > >>>>> =20 > >>>>> > >>>>The early phone network just connected wires to wires in a > >>>>provisioned mode > >>>>i.e. call the operator and they connected 2 wires=20 > together. And that=20 > >>>>was not a > >>>>network?! > >>>> > >>>>And if by "static mode" you mean we enter static configuration to=20 > >>>>stitch together millions of wires in hundreds of boxes then that=20 > >>>>would be a massive step backwards for service providers. > >>>> > >>>>Peter Willis, > >>>>Office of the BT Group CTO. > >>>> > >>>> =20 > >>>> > >>> =20 > >>> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> =20 > >> > > > > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > =20 > > >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: Re: RSVP-TE and PW Date: Mon, 11 Oct 2004 13:04:33 +0100 Lines: 111 Sender: pwe3-bounces@ietf.org References: <4166D913.1080706@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , pwe3@ietf.org, Benny.Ammitzboell@tpack.net, Peter Willis , neil.2.harrison@bt.com, erosen@cisco.com X-From: pwe3-bounces@ietf.org Tue Oct 12 06:58:11 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Luca Martini In-Reply-To: <4166D913.1080706@cisco.com> X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca Martini wrote: > > > Peter Willis wrote: > >> So in other words are we saying that to do anything useful with PW >> stitching i.e. create a network, we need to go to the L2VPN WG? >> >> > yes. > > Luca PWE3 is only concerned with the provision and operation of the wire emulation. The formation of a collection of wires into a network is the domain of L2VPN WG. - Stewart > >> Is anything happening in the L2VPN WG to address PW stitching? >> >> Peter. >> >> >>> Peter, >>> >>> I just want to add to Tom's comment , that I believe this is just a >>> starting point. Like PW where used to build VPLS, or MPLS to build >>> GMPLS. >>> There should be nothing in the pw-switching draft preventing anyone >>> from creating a new network layer if they wish. >>> PW switching connects wires with only only going to one fixed >>> destination, which does not change. That would make a pretty boring >>> phone network wouldn't it ? >>> :-) >>> Anyway I believe that the PW switching draft should be targeted as an >>> informational RFC, as it does not really even create a new protocol. >>> Whether it is useful or not is a matter of personal opinion. >>> >>> Luca >>> >>> >>> Thomas D. Nadeau wrote: >>> >>> >>> >>>> Peter, I don't think that is the point he was >>>> making, at least not as I understood it. >>>> I don't see stitching PWs together as anything >>>> different than bridging/patching two enet segments >>>> together. This seems to fit well within the PWE3 >>>> charter of p2p pwe3s. HOWEVER, if we start talking about >>>> automatically patching these together, then this requires >>>> more intelligence such as the form of some >>>> routing protocol. This is the purview >>>> of the L2VPN WG, which I do agree constitutes >>>> another 'layer'. >>>> >>>> --Tom >>>> >>>> >>>> >>>> >>>>>> Neil, I think the problem is the definition of a network. PW >>>>>> switching >>>>>> just connects wires 1 to 1 in a static mode. I see it as a wire >>>>>> extension. >>>>>> >>>>> >>>>> The early phone network just connected wires to wires in a >>>>> provisioned mode >>>>> i.e. call the operator and they connected 2 wires together. And >>>>> that was not a >>>>> network?! >>>>> >>>>> And if by "static mode" you mean we enter static configuration to >>>>> stitch >>>>> together millions of wires in hundreds of boxes then that would be >>>>> a massive >>>>> step backwards for service providers. >>>>> >>>>> Peter Willis, >>>>> Office of the BT Group CTO. >>>>> >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >>> >> >> >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: richard.spencer@bt.com Subject: RE: RSVP-TE and PW Date: Tue, 12 Oct 2004 10:44:40 +0100 Lines: 36 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: tnadeau@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, pjw@ip-engineering.bt.com, neil.2.harrison@bt.com, erosen@cisco.com X-From: pwe3-bounces@ietf.org Tue Oct 12 11:57:54 2004 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSwGK8jwEW74GlqQTyier2D6AY2BgAIMeEQ To: , X-OriginalArrivalTime: 12 Oct 2004 09:44:42.0289 (UTC) FILETIME=[19593A10:01C4B040] X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, > PWE3 is only concerned with the provision and operation of the > wire emulation. The formation of a collection of wires into a > network is the domain of L2VPN WG. Please can you tell me where (i.e. which charter/draft/RFC) this is = stated. Also, please can you confirm exactly what is in scope and what is out of = scope? Are you saying that: (i) PW switching is out of scope of PWE3 (ii) Signalling of individual PWs used to create switched multihop PWs = is in scope, but the routing, end-to-end signalling, and interworking = are out of scope? I assume its not (i), otherwise why was the PW switching draft allowed = to be submitted to PWE3, why was it agreed to start a PW switching = requirements draft, and why are we discussing it on this mailing list? If (ii) and consensus is reached that PW switching is a requirement, = then due to switched PW requirements for data/control plane = interworking, OAM message mapping, end-to-end signalling, etc. existing = PWE3 drafts will need expanding or completely new drafts covering the = same topics will need to be written in the L2VPN WG.=20 I personally think it would make more sense to make PW switching = requirements/solutions the superset and single hop PWs a subset of those = requirements/solutions and to do the work in the same WG. Regards, Richard =20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: =?iso-8859-1?Q?Benny_Ammitzb=F8ll?= Subject: Spoke pseudowire signaling Date: Tue, 12 Oct 2004 13:41:01 +0200 Lines: 135 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004E_01C4B061.1CC0CC10" X-From: pwe3-bounces@ietf.org Tue Oct 12 13:53:44 2004 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-MS-TNEF-Correlator: X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C4B061.1CC0CC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA10210 Folks, >From draft-ietf-l2vpn-vpls-ldp-05.txt, section 8.1.1 "Spoke connectivity = for bridging-capable devices": "For each VPLS service, a single spoke pseudowire is set up between th= e MTU-s=20 and the PE-rs based on [PWE3-CTRL]. Unlike traditional pseudowires=20 that terminate on a physical (or a VLAN-tagged logical) port at each=20 end, the spoke pseudowire terminates on a virtual bridge instance on=20 the MTU-s and the PE-rs devices. " >From draft-ietf-pwe3-control-protocol-11.txt, section 5.2.1 "Attachment Identifiers": "If the AGI is non-null, then the Source AI (SAI) consists of the AGI together with the SAII, and the Target AI (TAI) consists of the TAII together with the AGI. If the AGI is null, then the SAII and TAII are the SAI and TAI respectively." >From draft-ietf-l2vpn-vpls-ldp-05.txt, section 4.1.1 "Using the Generaliz= ed PWid FEC Element": "AGI, Length, Value: The unique name of this VPLS. The AGI=20 identifies a type of name, the length denotes the length of Value,=20 which is the name of the VPLS. We will use the term AGI=20 interchangeably with VPLS identifier.=20 =20 TAII, SAII: These are null because the mesh of PWs in a VPLS=20 terminate on MAC learning tables, rather than on individual=20 attachment circuits. " So how is a spoke pseudowire being signaled using Generalized PWid FEC? T= he TAII and SAII can not both be null in this case, because one of them must point out an attachment identifier (AI) in the MTU-s. Also, note that the= AI in the MTU-s *must* consist of the VPLS AGI and a local AII. So the MTU-s *must* support attachment identifiers where the AGI is non-null and equal= to the VPLS AGI. My proposal would be to allow the TAII or SAII to be non-null when signal= ing a connection between a VPLS forwarder and a PWE-3 (single point / physica= l interface) forwarder. This may also be the intention, but the text in draft-ietf-l2vpn-vpls-ldp-05.txt should clearly state this. Regards, Benny L=F8nstrup Ammitzb=F8ll, M.Sc.E.E. T|Pack A/S Lautrupbjerg 7-11 DK-2750 Ballerup, Denmark ------=_NextPart_000_004E_01C4B061.1CC0CC10 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgELAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHCgAMAA0AKQAAAAIAKQEB A5AGALgJAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAGwAAAFNwb2tlIHBzZXVkb3dpcmUgc2lnbmFsaW5nAAACAXEAAQAAABYAAAABxLBQWSf2b/kF os5JQp/J6rjrB8StAAACAR0MAQAAACEAAABTTVRQOkJFTk5ZLkFNTUlUWkJPRUxMQFRQQUNLLk5F VAAAAAALAAEOAAAAAEAABg4AbmNYULDEAQIBCg4BAAAAGAAAAAAAAABWzLkabGDXTIwujMCLtRRQ woAAAAsAHw4BAAAAAgEJEAEAAAB8BQAAeAUAAEcJAABMWkZ1DcLSeAMACgByY3BnMTI1FjIA+Atg bg4QMDMzTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0DGBOYwBQCwMLtSBGBvBr XHMsCqIKhAqARgNhIGhkcmEBgC0IkAAwLUBsMnZwbi0WEGwCcxXgZHAtMDUuEQzQdCwgESBjdGkh AiAgOC4xF/AgIkBTcG9rZSAFoG7GbhdyEiB0eSACEAXAEmIFEGRnC4BnLWO+YQqwAmAYkAEAEiBj B5DUIjoUNCAbwCIT0AXAgmUA0GggVlBMBfDtESByGvIXQGEXUBoRGqGKcxhjcBEgdWRvA/CdCXAg BAAXUQVAdXAZsEURMHcJ4SB0aBiQTbhUVS0EIRt2AHBkICPYUEUtERAZsGERICGAARexW1BXRTMt QwBUUkxdLiBVbtRsaRiBdBVQZBlAF6GvB0AeWSC5IDBhBUB0BJA+bQuAJkAYkBexHXBwaDZ5DdEk oSgFsR1wVkzIQU4tAZBnZyJxCQD7GgAnsSkeUAkRHWAFQBxD+xtnCfBkF0AgMh4PJncEIPcnExIg ACB1JKEZwx7xAID9AZBuGxAikiWZIFYhbBrV7SOAIhQ/FUlwH+AjEBixTyQQBvAzsANgdG8I4S2u MRgAFxsW8DIYEkECQOccUQeAAjAgSQEAAjAGkBMIkRs7SWYgI0FHSQUfAm4CIC1udWxsWyszIBRT CGEu8UE5QCj+UzswKYAYsQCQLrAtMTjH/yWYKSARMCBABcAD8CAwOnTtOzBJHVEhdVQKwD2hOyP+ VDuPP1I+sTz/Pgg5ISOA/zcwOMw57T6xIVNBiwrAI/ErPnRF5iAlUXAY82VsvHkuMf8VPxZPF1c0 F/R2VR2SICNHCfAEkAdAaR56InEi4BngE8BFQyC+RRqgNvIbSjkhF0BMCfC2ZyAwF0BWB0AKUDo/ cLUgQXUDAHEKUDmAYQeA/zxEHxEckkOhUaI5IhtnGeD3N2UwYSAgeUhwPEJSUis0/xqgUNIawTmQ LRJWWTxRUTP7F0AbZ3dS4BxhHxEgMlJY+xiQUyVXGJAD8DnwH3ARIP8gIyZyU80CMASQEOEPIBxA 3wJgGWA+ExyTVKdyI4AbZ/8gyEGCF0A+olGDW/FHAjnS/x+hGlBb5geBWBMi4AQgC4DPKCIcoiWY JopNQU8QGqD/CsADAE1yGoIUEEgwJkA90t8mIQOgF7EScRkhZC3iINjlNqhjHtBjdRlAMc46wPwg aB6wHwIdcR4eH7BNYv0AkGckkSJxW+BNYk3vTvH+P1GTQYIhU0WjGlADoFch/xmwNLAccB+wYmRk QVLTGlC/ESAXQGLGAiBaZkoQbVvg7wVAGGBdgSKQdSnRJyE2qL9fKCfgQEJy0yBVI4BBS2B+bxdA VyImFTjyOUEgGir9dPIqQHZaejkTIWIdcAkA3yeyPrEjgGvhek9zH4AppX92PzfBWVEEkEckOS0h U2WvUhAkoTTAe/suSSpNGWDrNJEYYHMkoXcIYEuQckL/g1EHQAkAB+BBRiKQBcBFo/+DUXJSgjaB EQOgbhRNYh1w3xi2F7EftmR1GYF3CxE94XN81CLhLTMn4B2VdUQv6ydYXYNmANBlKYCLpyOA/1Gg HxEAwBlgB0B4wIYjIEH/XYI3cQIgc5F1sVwkFyBkMt9KP0tNF1BsEIXyY2aCXlEfLrF5IwQAhEtJ JFJlZ6cLERQcCvMgQgnwbhlgoExcJ2Y4LqFyH4HkQW0moHR6DDCZ4TnywE0uU2MuRZuxSSQoVHxQ ANBrEWAvU81JJExi8JoyYmoEkE2ABjc1EUkkREstMjd6NRFQQoaRBJAfgBdARLMJ8ADAcmtJKhHh AKFgCwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAnagEAHgAJgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAA AQAAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAMgAggBgAA AAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAIKF AAABAAAACwA6gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADyACCAGAAAAAADAAAAAAAAA RgAAAAARhQAAAAAAAAMAPYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAACwBSgAggBgAAAAAA wAAAAAAAAEYAAAAABoUAAAAAAAADAFOACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAIB+A8B AAAAEAAAAFbMuRpsYNdMjC6MwIu1FFACAfoPAQAAABAAAABWzLkabGDXTIwujMCLtRRQAgH7DwEA AABYAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoA N9luAAAAXFxCbHVlXGJsYVxPdXRsb29rXG91dGxvb2sucHN0AAMA/g8FAAAAAwANNP03AAACAX8A AQAAADsAAAA8TkhFTUlNQ09OS0FNRENLUEhJREFLRU5DQ0ZBQS5CZW5ueS5BbW1pdHpib2VsbEB0 cGFjay5uZXQ+AAADAAYQOYwMZwMABxBlBgAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEZP TEtTLEZST01EUkFGVC1JRVRGLUwyVlBOLVZQTFMtTERQLTA1VFhULFNFQ1RJT044MTEiU1BPS0VD T05ORUNUSVZJVFlGT1JCUklER0lORy1DQVBBQkxFREVWSUNFUyI6IkYAAAAAgIM= ------=_NextPart_000_004E_01C4B061.1CC0CC10 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------=_NextPart_000_004E_01C4B061.1CC0CC10-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: RE: RSVP-TE and PW Date: Tue, 12 Oct 2004 15:24:18 +0200 Lines: 89 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: tnadeau@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, pjw@ip-engineering.bt.com, neil.2.harrison@bt.com, erosen@cisco.com, lmartini@cisco.com X-From: pwe3-bounces@ietf.org Tue Oct 12 16:00:22 2004 Return-path: To: "'richard.spencer@bt.com'" , stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard, Stewart and all, I would like to present a somewhat different point of view. IMHO a multi-hop PW is still a single PW even if it is composed of multiple segments. If we can agree on that, PROVISIONING - all the way through a known set of "switching nodes" - and OPERATION of multi-hop PWs would remain in the scope of the PWE3 WG. E.g., if we decide that, in addition to the current PE-to-PE VCCV mechanism, we need an OAM mechanism limited to a single segment of a multi-hop PW, I would expect that the definitions would be provided by the PWE3. At the same time, DISCOVERING the set of switching nodes that will be used by a given multi-hop PW would be out of scope of the PWE3. I am not sure that this falls within the scope of the L2VPN WG either, but this is a different issue. My 2 c. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: Tuesday, October 12, 2004 11:45 AM > To: stbryant@cisco.com; lmartini@cisco.com > Cc: tnadeau@cisco.com; pwe3@ietf.org; > Benny.Ammitzboell@tpack.net; pjw@ip-engineering.bt.com; > neil.2.harrison@bt.com; erosen@cisco.com > Subject: RE: [PWE3] RSVP-TE and PW > > > Stewart, > > > PWE3 is only concerned with the provision and operation of the > > wire emulation. The formation of a collection of wires into a > > network is the domain of L2VPN WG. > > Please can you tell me where (i.e. which charter/draft/RFC) > this is stated. > > Also, please can you confirm exactly what is in scope and > what is out of scope? Are you saying that: > > (i) PW switching is out of scope of PWE3 > (ii) Signalling of individual PWs used to create switched > multihop PWs is in scope, but the routing, end-to-end > signalling, and interworking are out of scope? > > I assume its not (i), otherwise why was the PW switching > draft allowed to be submitted to PWE3, why was it agreed to > start a PW switching requirements draft, and why are we > discussing it on this mailing list? > > If (ii) and consensus is reached that PW switching is a > requirement, then due to switched PW requirements for > data/control plane interworking, OAM message mapping, > end-to-end signalling, etc. existing PWE3 drafts will need > expanding or completely new drafts covering the same topics > will need to be written in the L2VPN WG. > > I personally think it would make more sense to make PW > switching requirements/solutions the superset and single hop > PWs a subset of those requirements/solutions and to do the > work in the same WG. > > Regards, > Richard > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Tue, 12 Oct 2004 09:38:45 -0400 Lines: 154 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "Thomas D. Nadeau" , pwe3@ietf.org, Benny.Ammitzboell@tpack.net, Peter Willis , neil.2.harrison@bt.com, erosen@cisco.com X-From: pwe3-bounces@ietf.org Tue Oct 12 16:07:11 2004 Return-path: To: "'Stewart Bryant'" , Luca Martini X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, October 11, 2004 8:05 AM > To: Luca Martini > Cc: Thomas D. Nadeau; pwe3@ietf.org; > Benny.Ammitzboell@tpack.net; Peter > Willis; neil.2.harrison@bt.com; erosen@cisco.com > Subject: Re: [PWE3] RSVP-TE and PW > > > > > Luca Martini wrote: > > > > > > > Peter Willis wrote: > > > >> So in other words are we saying that to do anything useful with PW > >> stitching i.e. create a network, we need to go to the L2VPN WG? > >> > >> > > yes. > > > > Luca > > PWE3 is only concerned with the provision and operation of the > wire emulation. The formation of a collection of wires into a > network is the domain of L2VPN WG. Stewart, In my view, a Multi-hop PW is a single wire, not a collection of wires. That is one reason why I think the work belongs in PWE3 and not in L2VPN. More importantly, however, the aspects of MH-PWs that require further standardization, have nothing to do with the emulated service. E.g. - L2VPN works on the discovery of PEs that participate in a L2 service. On the other hand, MH-PWs require a discovery/routing mechanism to determine intermidiate switching points, independent of the L2 service. - L2VPN works on the signaling of l2vpn related information. MH-PWs require a signaling solution to tie together multiple segments, independent of the L2 service. Peter Peter > > - Stewart > > > > >> Is anything happening in the L2VPN WG to address PW stitching? > >> > >> Peter. > >> > >> > >>> Peter, > >>> > >>> I just want to add to Tom's comment , that I believe this > is just a > >>> starting point. Like PW where used to build VPLS, or MPLS > to build > >>> GMPLS. > >>> There should be nothing in the pw-switching draft > preventing anyone > >>> from creating a new network layer if they wish. > >>> PW switching connects wires with only only going to one fixed > >>> destination, which does not change. That would make a > pretty boring > >>> phone network wouldn't it ? > >>> :-) > >>> Anyway I believe that the PW switching draft should be > targeted as an > >>> informational RFC, as it does not really even create a > new protocol. > >>> Whether it is useful or not is a matter of personal opinion. > >>> > >>> Luca > >>> > >>> > >>> Thomas D. Nadeau wrote: > >>> > >>> > >>> > >>>> Peter, I don't think that is the point he was > >>>> making, at least not as I understood it. > >>>> I don't see stitching PWs together as anything > >>>> different than bridging/patching two enet segments > >>>> together. This seems to fit well within the PWE3 > >>>> charter of p2p pwe3s. HOWEVER, if we start talking about > >>>> automatically patching these together, then this requires > >>>> more intelligence such as the form of some > >>>> routing protocol. This is the purview > >>>> of the L2VPN WG, which I do agree constitutes > >>>> another 'layer'. > >>>> > >>>> --Tom > >>>> > >>>> > >>>> > >>>> > >>>>>> Neil, I think the problem is the definition of a network. PW > >>>>>> switching > >>>>>> just connects wires 1 to 1 in a static mode. I see it as a wire > >>>>>> extension. > >>>>>> > >>>>> > >>>>> The early phone network just connected wires to wires in a > >>>>> provisioned mode > >>>>> i.e. call the operator and they connected 2 wires together. And > >>>>> that was not a > >>>>> network?! > >>>>> > >>>>> And if by "static mode" you mean we enter static > configuration to > >>>>> stitch > >>>>> together millions of wires in hundreds of boxes then > that would be > >>>>> a massive > >>>>> step backwards for service providers. > >>>>> > >>>>> Peter Willis, > >>>>> Office of the BT Group CTO. > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> pwe3 mailing list > >>> pwe3@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/pwe3 > >>> > >>> > >> > >> > >> > >> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> > >> > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: RSVP-TE and PW Date: Tue, 12 Oct 2004 14:58:33 +0100 Lines: 56 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: tnadeau@cisco.com, erosen@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, pjw@ip-engineering.bt.com X-From: pwe3-bounces@ietf.org Tue Oct 12 17:01:06 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSwYPGpumEMqhQ/TI+etiV/W/MwqgAAUPoQ To: , , X-OriginalArrivalTime: 12 Oct 2004 13:58:33.0870 (UTC) FILETIME=[90140AE0:01C4B063] X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Peter, >=20 > > Luca Martini wrote: > >=20 > > >=20 > > >=20 > > > Peter Willis wrote: > > >=20 > > >> So in other words are we saying that to do anything=20 > useful with PW > > >> stitching i.e. create a network, we need to go to the L2VPN WG? > > >> =20 > > >> > > > yes. > > >=20 > > > Luca > >=20 > > PWE3 is only concerned with the provision and operation of the wire=20 > > emulation. The formation of a collection of wires into a network is=20 > > the domain of L2VPN WG. >=20 > Stewart, >=20 > In my view, a Multi-hop PW is a single wire, not a collection=20 > of wires. That is one reason why I think the work belongs in=20 > PWE3 and not in L2VPN. More importantly, however, the aspects=20 > of MH-PWs that require further standardization, have nothing=20 > to do with the emulated service.=20 >=20 > E.g. >=20 > - L2VPN works on the discovery of PEs that participate in a=20 > L2 service. On the other hand, MH-PWs require a=20 > discovery/routing mechanism to determine intermidiate=20 > switching points, independent of the L2 service. >=20 > - L2VPN works on the signaling of l2vpn related information.=20 > MH-PWs require a signaling solution to tie together multiple=20 > segments, independent of the L2 service. >=20 > Peter NH=3D> You have nicely described the behaviour of a layer network here (that is also independent of it's client). If folks managed to get their head round what is going on here in func arch terms it is this: In the 'old' PW 1-hop world we had a (single) client X link-connection supported off a MPLS trail (or IP connectionless trail). In the proposed 'new' PW N-hop world we have a (single) client X link-connection supported off a PW trail, where *each* PW link-connection (there are N in the PW trail) is in turn now supported off a MPLS trail (or IP connectionless trail). regards, Neil =20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: Re: RSVP-TE and PW Date: Tue, 12 Oct 2004 18:14:28 +0100 Lines: 92 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: tnadeau@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, pjw@ip-engineering.bt.com, neil.2.harrison@bt.com, erosen@cisco.com, lmartini@cisco.com X-From: pwe3-bounces@ietf.org Tue Oct 12 19:33:12 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: richard.spencer@bt.com In-Reply-To: X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org richard.spencer@bt.com wrote: > Stewart, > > >>PWE3 is only concerned with the provision and operation of the >>wire emulation. The formation of a collection of wires into a >>network is the domain of L2VPN WG. > > > Please can you tell me where (i.e. which charter/draft/RFC) this is stated. From the PWE3 charter "The basic idea of this working group is to develop standards for the encapsulation and service emulation of pseudo wires: encapsulating service-specific PDUs arriving at an ingress logical port and carrying them across a tunnel, managing their timing, order or other aspects entering and leaving the tunnel, to emulate the behavior and characteristics of the service as well as possible." "From the customer perspective, the pseudo wire is perceived as an unshared link or circuit (or the appropriate unit) of the chosen service (although it will not be a perfect emulation of the service)." From the L2VPN charter "2. Virtual Private Wire Service (VPWS)--L2 service that provides L2 point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI, point-to-point Ethernet) across an IP and an MPLS-enabled IP network." "As a specific example, this WG will not define new encapsulation mechanism, but will use those defined in the PWE3 WG." When we only had single hop wires it was therefore quite clear PWE3 owned pt-pt wires, and L2VPN owned forming them into network. Now we are considering joining two wires end to end for various operational/administrative reasons. I think that so long as the object is basically a "repeater" it belongs in PWE3, but as soon as you want to automatically create it, then it belongs in L2VPN. > > Also, please can you confirm exactly what is in scope and what > is out of scope? Are you saying that: > > (i) PW switching is out of scope of PWE3 Yes - I think that belongs in L2VPN > (ii) Signalling of individual PWs used to create switched multihop > PWs is in scope, but the routing, end-to-end signalling, and > interworking are out of scope? Yes, although in the specific case of a "wire splice" I am not sure. Luca's draft is really just putting into place the things that you need to "splice" or "repeat" a wire under static configuration. As such I think it belongs in PWE3. > > I assume its not (i), otherwise why was the PW switching draft > allowed to be submitted to PWE3, why was it agreed to start a PW > switching requirements draft, and why are we discussing it on > this mailing list? You have to start somewhere. > > If (ii) and consensus is reached that PW switching is a requirement, > then due to switched PW requirements for data/control plane > interworking, OAM message mapping, end-to-end signalling, etc. > existing PWE3 drafts will need expanding or completely new drafts > covering the same topics will need to be written in the L2VPN WG. The Internet ADs and WG chairs need to figure out what work should be done in which WG. > > I personally think it would make more sense to make PW switching > requirements/solutions the superset and single hop PWs a subset > of those requirements/solutions and to do the work in the same WG. > There is a difference between the wires and the control plane that instructs their creating and interconnection, so that's not clear. - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: Re: RSVP-TE and PW Date: Tue, 12 Oct 2004 18:29:04 +0100 Lines: 32 Sender: pwe3-bounces@ietf.org References: <0536FC9B908BEC4597EE721BE6A353890A9F1307@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: tnadeau@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, pjw@ip-engineering.bt.com, busschbach@lucent.com, erosen@cisco.com, lmartini@cisco.com X-From: pwe3-bounces@ietf.org Tue Oct 12 19:47:09 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890A9F1307@i2km07-ukbr.domain1.systemhost.net> X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Neil > > NH=> You have nicely described the behaviour of a layer network here > (that is also independent of it's client). If folks managed to get > their head round what is going on here in func arch terms it is this: > > In the 'old' PW 1-hop world we had a (single) client X link-connection > supported off a MPLS trail (or IP connectionless trail). Correct > > In the proposed 'new' PW N-hop world we have a (single) client X > link-connection supported off a PW trail, where *each* PW > link-connection (there are N in the PW trail) is in turn now supported > off a MPLS trail (or IP connectionless trail). Correct if we do switching rather than splicing (splicing was Luca's original proposal). Most networks have splices without introducing a new full-blown network layer, although I do admit they mostly have OAM issues of various sorts. So how would structue the work if: a) We just do splicing/repeating and no more. b) We do PW switching (which as far as I can see is not chartered anywhere in IETF). - Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Tue, 12 Oct 2004 13:29:39 -0400 Lines: 132 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, "'richard.spencer@bt.com'" , Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Tue Oct 12 19:48:28 2004 Return-path: To: "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Eric, It is a little late, but I had a few comments on your email from last week. Peter > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, October 04, 2004 1:41 PM > To: Busschbach, Peter B (Peter) > Cc: 'Stewart Bryant'; Sasha Vainshtein; pwe3@ietf.org; > 'richard.spencer@bt.com' > Subject: Re: [PWE3] RSVP-TE and PW > > > > Peter> If one intermediate node goes down, it would be good > if PWs could be > Peter> rapidly established via a different route. Also, > there are cases in > Peter> which PW set up needs to be fully automatic. E.g. > there are cases in > Peter> which signaling messages in the client layer (e.g. > PNNI messages in > Peter> the case of ATM) trigger PW setup and the end-to-end > connection setup > Peter> needs to happen without operator interference. > > So far, so good. > > Peter> These considerations suggest that it would be > helpful to have a PW > Peter> setup mechanism that allows the ingress node to select > a path through > Peter> one or more intermediate PW Switching nodes to the > egress PE and use > Peter> a single-sided signaling mechanism to establish the > PW along that > Peter> path > > These considerations suggest that a PW switching point > should be able to > dynamically determine the next PW switching point. I don't > see how you've > drawn any conclusion about the need for carrying an > explicit path from the > ingress. I am afraid that my formulation has given the wrong impression. I did not mean to suggest that the ingress PE should identify the entire end-to-end path. In my view, two things are necessary: a) The signaling message must identify the egress PE (which would require an ERO, even if it would only contain the end point of the path). b) The ingress PE must be able to select autonomously the first PW switching point to which it forwards the signaling message. It is possible that a signaling message identifies more than one PW switching point, but I think it would be more likely that the first PW switching point uses the node id of the egress PE to determine the next PW switching point, and so on. >In general, if you want routing to failed > paths repaired > automatically, you want something which will route > around the failure, > rather than something which requires the ingress to > recompute (based on > what?) an explicit route. > > If the PW egress is to stay the same, while the set of > tunnels through which > the PW passes is to change, then what you are asking > for is a routing > protocol that runs over the tunnel overlay, and which gives > you the "next > hop" in that overlay for the IP address of the egress. > > Note that the overlay consists not of the PWs, but of the tunnels. > > > if PW Switching nodes would be required within ASs, RSVP-TE > seems to offer > > a straightforward solution. > > I would like to understand better what the antecedent of > this statement is > true. However, I certainly don't agree with the conclusion, > as RSVP-TE does > not provide the routing capability that appears to be > required in this > case. Perhaps my use of the word "solution" was inappropriate. However, if you read my entire email instead of the single line that you quote, it must be clear that my point was that RSVP-TE as a *signaling* protocol has properties that could make it suitable for MH-PW setup within a Service Provider network. I did not claim in any way that it is a sufficient solution to the entire problem. Obviously, the routing aspects of MH-PW setup are not met by RSVP-TE. > > As I said, I'd like to understand better the need for > routing over the > tunnel overlay. If that model turns out to be > necessary, we can then > discuss whether its needs can or cannot be met with the > existing protocols. > > The claim that RSVP-TE is preferable whenever we need to > send parameters > which we call "QoS" or "explicit route" is not a claim which > I can take very > seriously. Generally, if you have a protocol that does > something, and you > find that you need to add a new parameter, you just add the > new parameter; > you don't go looking for another protocol that already has > a parameter of > the same name! You first need to understand which is the > tail and which is > the dog. I agree that we need to get a better understanding of the problem to be solved before we evaluate solutions. Just to put things into context: I wrote my email in response to an email thread in which one of the overriding arguments seemed to be that it would make sense to use RSVP-TE for today's single-hop PWs because of RSVP-TE's role in the setup of PSN tunnels. I don't agree with that argument and I thought it would be helpful to give other reasons why RSVP-TE might be considered in the future. So, how about the claim that RSVP-TE is preferable? If you only look at PEs, I agree with your statement. Current implementations are based on LDP and it does not make much sense to introduce a different protocol just because there is a need to carry QoS- and/or ERO-related objects. However, if you add QoS- and ERO-related objects to LDP, it becomes CR-LDP. That may not matter much for PE implementations, but it seems to me that it does have impact on IP/MPLS networks in general. PW switching points perform label switching based on PW labels. Therefore, they treat MH-PWs as they do any regular LSP. (There are minor differences: label merging and PHP is not allowed on MH-PWs, and for scaleability reasons it is preferable to tunnel MH-PWs through larger PSN tunnels). Do we really want to end up in a situation in which LSRs support RSVP-TE to set up regular LSPs and CR-LDP if they act as PW switching points? >From an implementation perspective, it might not be a big deal. Many switches may support CR-LDP already as a left-over from the days when the RSVP-TE - CR-LDP controversy was still undecided. But going forward, do we really want to require support for both protocols? As mentioned before, the requirements for MH-PWs are not clear yet. However, to summarily dismiss concerns about the re-introduction of CR-LDP seems short-sighted. > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: richard.spencer@bt.com Subject: RE: RSVP-TE and PW Date: Tue, 12 Oct 2004 21:28:09 +0100 Lines: 41 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: tnadeau@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, pjw@ip-engineering.bt.com, busschbach@lucent.com, erosen@cisco.com, lmartini@cisco.com X-From: pwe3-bounces@ietf.org Tue Oct 12 23:34:21 2004 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSwg7lOZNdQihQcSDa9RZV0XLXCGAADWTLA To: , X-OriginalArrivalTime: 12 Oct 2004 20:28:10.0400 (UTC) FILETIME=[FD937200:01C4B099] X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Stewart, > Correct if we do switching rather than splicing (splicing > was Luca's original proposal).=20 I haven't read Luca's original proposal for PW splicing, can you tell me = how it differs from his PW switching draft? > Most networks have splices without introducing a new=20 > full-blown network layer, although I do admit they mostly=20 > have OAM issues of various sorts. >=20 > So how would structue the work if: >=20 > a) We just do splicing/repeating and no more. >=20 > b) We do PW switching (which as far as I can see is not chartered > anywhere in IETF). Again, what is the difference between splicing/repeating and switching? = Surely in both cases a splicing/switching node must perform a label = lookup on ingress to determine the egress? If so, whether a packet is = repeated or switched a switching/splicing node must still be configured = with or dynamically learn what the next hop/egress interface is for an = incoming packet. This brings us back to the question over the routing/discovery = functions. An operator must perform these functions in order to = establish a multi-hop PW, the only question is over how the functions = are performed, the options being via manual configuration, OSS, or = dynamic protocols. So is it the case that option a) above means that routing/discovery for = multi-hop PWs is out of scope, and therefore must be performed using = manual configuration, OSS or dynamic protocols defined in another WG? If = so, what about other PW splicing requirements such as interworking (i.e. = MPLS<->L2TP), resilience (e.g. to protect against splicing node = failure), and OAM? Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Tue, 12 Oct 2004 16:38:55 -0400 Lines: 188 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: erosen@cisco.com, pwe3@ietf.org, Sasha Vainshtein , "'richard.spencer@bt.com'" , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Tue Oct 12 23:48:51 2004 Return-path: To: "'Tony Li'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Tony, Sorry for the late response. I agree with your general observation, but do have some questions regarding the details. In my earlier emails, I have implicitly made the assumption that a Multi-hop PW is essentially an LSP in its own right. It exists between two PEs and it is aggregated in Tunnel LSPs. Since the Tunnel LSPs may not extend end-to-end, there is a need for intermediate nodes that do PW switching (i.e. label switching based on the PW Label). If I understand you correctly, you propose to stick with Single-Hop PWs and to solve the scaleability problems related to Tunnel LSPs. With an increasing number of PEs, and thus with an increasing number of Tunel LSPs, it could make sense to aggregate multiple Tunnel LSPs into higher-order LSPs. If my understanding is correct, then the two solutions look practically the same. The difference is that the PW switching solution requires a two-label stack (PW Label and Tunnel LSP Label), whereas yours requires a three-label stack (ditto plus higher-order LSP label) Is my understanding correct and if so, why do you think that it is a better approach? Why would the PW layer combat the TE layer? I wasn't aware of any restrictions in the PWE3 architecture that would prevent the merging of PW traffic and non-PW traffic on the same Tunnel LSPs. Therefore, I didn't think there would be any conflict between allocating bandwidth to MH-PWs and to other non-PW LSPs. Peter > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li] > Sent: Friday, October 01, 2004 3:56 PM > To: Busschbach, Peter B (Peter) > Cc: erosen@cisco.com; pwe3@ietf.org; 'richard.spencer@bt.com'; Sasha > Vainshtein; 'Stewart Bryant' > Subject: Re: [PWE3] RSVP-TE and PW > > > > Hi Peter, > > Following this logic, there are many other LSPs in the network other > than just PW's. For example, one might have > a number of TE LSPs also containing best effort traffic, or a > number of > VPN LSPs. In the scale of network that > you describe, it seems likely that these might well be > encapsulated in > trunk LSPs. As you note, these trunk > LSPs may well need to be re-multiplexed, which seems quite reasonable > to me, as I've already seen this done. > > In such an environment, there is necessarily a considerable amount of > TE going on, just because of the mismatch > between the physical plant and the demand matrix. For the > scalability > of management, wouldn't it be better to > allow the TE layer of the network to perform its functions > and not try > to meld that functionality into the > PW layer? After all, without the global knowledge of the traffic > matrix, PW is not likely to achieve an > optimal (or even acceptable) solution, and it would > effectively combat > the TE layer. > > Regards, > Tony > > > > On Oct 1, 2004, at 7:46 AM, Busschbach, Peter B (Peter) wrote: > > > To answer the question: what problem would RSVP-TE solve: > > > > In the current PWE3 architecture, PEs multiplex multiple PWs onto a > > PSN tunnel that extends from the ingress PE to the egress PE. > > > > With growing MPLS deployment, it is conceivable that there is not > > always an end-to-end PSN tunnel between two PEs and that there is a > > need to "re-multiplex": take PWs out of one tunnel and map > them onto > > another. In fact, I think it is more than conceivable. It is very > > likely. Service Providers grow through mergers and acquisitions and > > will have to interconnect independent MPLS islands. And within one > > network, MPLS will extend further and further to the edge of the > > network. > > > > The notion of re-multiplexing PWs is not new. E.g. section 3.5 of > > draft-ietf-l2vpn-signaling-02.txt shows an achitecture in which it > > occurs. However, the section leaves big questions about the > > appropriate control infrastructure to manage this architecture. The > > text under the figure in 3.5 suggests extensive use of maual > > provisioning or the use of some undefined discovery protocol. > > Similarly, another draft that addresses this issue > > (draft-martini-pwe3-pw-switching-00.txt), strongly suggests that > > intermediate switching nodes are manually provisioned. > > > > The problem with manual provisioning is that it impacts > resiliency. If > > one intermediate node goes down, it would be good if PWs could be > > rapidly established via a different route. Also, there are cases in > > which PW set up needs to be fully automatic. E.g. there are > cases in > > which signaling messages in the client layer (e.g. PNNI messages in > > the case of ATM) trigger PW setup and the end-to-end > connection setup > > needs to happen without operator interference. > > > > These considerations suggest that it would be helpful to have a PW > > setup mechanism that allows the ingress node to select a > path through > > one or more intermediate PW Switching nodes to the egress > PE and use a > > single-sided signaling mechanism to establish the PW along > that path. > > One solution would be to use a signaling protocol that carries some > > kind of Explicit Route Object. > > > > In earlier emails, it was observed that certain application require > > the PW setup protocol to carry QoS objects. > > > > This brings us to the rationale for RSVP-TE. If you need a protocol > > that carries an ERO and QoS objects, RSVP-TE is the obvious choice. > > > > Is it absolutely clear that we need RSVP-TE? No. We are at the very > > beginning of the deployment of PWE. We have little idea how MPLS > > networks will be deployed five years from now. > > > > With regards to PW Switching, one of the big questions we are > > struggling with is whether PW Switching is only required at > the edge > > of Autonomous Systems. If that would be the case, RSVP-TE may have > > little benefit and a combination of BGP and LDP would probably be a > > better solutions. However, if PW Switching nodes would be required > > within ASs, RSVP-TE seems to offer a straightforward solution. > > > > Considering this uncertainty, I would echo Richard's > request: "I would > > like to see the RSVP-TE PW signalling approach remain on > the table and > > not be rejected at this time." > > > > > > One last note: I am somewhat surprised by references to RSVP > > performance problems. I don't think the problem is RSVP. By > > definition, there are scaleability concerns about PW Switching. PWE > > introduces large numbers of fine-grained "connections". Any PW > > Switching solution would have to deal with that. Whether > you use LDP > > or RSVP should not matter. (I assume that the people who > decided that > > CR-LDP should be retired in favor of RSVP-TE were convinced > that the > > two solutions scaled equally well to large numbers of connections.) > > > > Peter > > > >> -----Original Message----- > >> From: Stewart Bryant [mailto:stbryant@cisco.com] > >> Sent: Friday, October 01, 2004 2:56 AM > >> To: Sasha Vainshtein > >> Cc: erosen@cisco.com; pwe3@ietf.org; 'richard.spencer@bt.com' > >> Subject: Re: [PWE3] RSVP-TE and PW > >> > >> > >> Sasha Vainshtein wrote: > >> > >> > >> > >>> IMHO,if you want to push forward RSVP-TE as one of the PW > signaling > >>> protocols, you should first define the problem that this > >> method addresses > >>> and which is not natively addressed by the existing > >> LDP-based protocol. > >>> > >>> > >> This is the key issue here. > >> > >> - Stewart > >> > >> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pwe3 > >> > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Tony Li Subject: Re: RSVP-TE and PW Date: Tue, 12 Oct 2004 14:51:27 -0700 Lines: 22 Sender: pwe3-bounces@ietf.org References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, pwe3@ietf.org, Sasha Vainshtein , "'richard.spencer@bt.com'" , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 00:09:33 2004 Return-path: In-Reply-To: To: "Busschbach, Peter B (Peter)" X-Mailer: Apple Mail (2.619) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > > Is my understanding correct and if so, why do you think that it is a > better approach? Why would the PW layer combat the TE layer? I wasn't > aware of any restrictions in the PWE3 architecture that would prevent > the merging of PW traffic and non-PW traffic on the same Tunnel LSPs. > Therefore, I didn't think there would be any conflict between > allocating bandwidth to MH-PWs and to other non-PW LSPs. > Perhaps I'm misunderstanding then. If you agree with the heirarchical model, then what is the purpose of using RSVP for signalling? All of the functionality that RSVP provides would be handled by lower layers (as they should be, IMHO ;-) and PW can continue to operate in a manner oblivious to such details as path selection. Put more generally, I'm trying to suggest the obverse to the end-to-end principle: if the middle of the network has to do something to make things work, then the end systems shouldn't participate. Tony From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Tue, 12 Oct 2004 18:33:37 -0400 Lines: 46 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: erosen@cisco.com, pwe3@ietf.org, Sasha Vainshtein , "'richard.spencer@bt.com'" , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 00:37:25 2004 Return-path: To: "'Tony Li'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Tony, I am afraid we are talking past each other. Unfortunately, I don't see how to clarify my point without writing a long, long email. Let's drop this issue for now. I will keep your "obverse end-to-end principle" in mind in future discussions on Multi-hop Pseudo Wires. Peter > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li] > Sent: Tuesday, October 12, 2004 5:51 PM > To: Busschbach, Peter B (Peter) > Cc: erosen@cisco.com; pwe3@ietf.org; 'richard.spencer@bt.com'; Sasha > Vainshtein; 'Stewart Bryant' > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > Is my understanding correct and if so, why do you think > that it is a > > better approach? Why would the PW layer combat the TE > layer? I wasn't > > aware of any restrictions in the PWE3 architecture that > would prevent > > the merging of PW traffic and non-PW traffic on the same > Tunnel LSPs. > > Therefore, I didn't think there would be any conflict between > > allocating bandwidth to MH-PWs and to other non-PW LSPs. > > > > Perhaps I'm misunderstanding then. If you agree with the > heirarchical > model, then what is the purpose of using RSVP for > signalling? All of the functionality that RSVP provides would be > handled by lower layers (as they should be, IMHO ;-) and > PW can continue to operate in a manner oblivious to such details as > path selection. > > Put more generally, I'm trying to suggest the obverse to the > end-to-end > principle: if the middle of the network has to > do something to make things work, then the end systems shouldn't > participate. > > Tony > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 09:16:09 +0100 Lines: 71 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: tnadeau@cisco.com, pwe3@ietf.org, Benny.Ammitzboell@tpack.net, pjw@ip-engineering.bt.com, busschbach@lucent.com, erosen@cisco.com, lmartini@cisco.com X-From: pwe3-bounces@ietf.org Wed Oct 13 10:20:45 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSwg7lOZNdQihQcSDa9RZV0XLXCGAADWTLAABfF5NA= To: , X-OriginalArrivalTime: 13 Oct 2004 08:16:10.0084 (UTC) FILETIME=[E570D240:01C4B0FC] X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard/Stewart, Spencer,R,Richard,XGH5 R wrote 12 October 2004 21:28 > Stewart, >=20 > > Correct if we do switching rather than splicing (splicing > > was Luca's original proposal). >=20 > I haven't read Luca's original proposal for PW splicing, can=20 > you tell me how it differs from his PW switching draft? >=20 > > Most networks have splices without introducing a new > > full-blown network layer, although I do admit they mostly=20 > > have OAM issues of various sorts. > >=20 > > So how would structue the work if: > >=20 > > a) We just do splicing/repeating and no more. > >=20 > > b) We do PW switching (which as far as I can see is not chartered=20 > > anywhere in IETF). >=20 > Again, what is the difference between splicing/repeating and=20 > switching? NH=3D> Functionally the answer is 'none'.....at least in the context of this issue (a 'repeater' in the context of ethernet is different). Do you remember the point Peter (Willis) made about the fact that once upon a time we used a human (an 'operator') to 'splice' PSTN link-connections together.....well, that person was the routing/signalling/cross-connect function. Later Almon Strowger automated this process as he thought he was losing business to his rivals (if folks don't know the story have a look at http://www.wordiq.com/definition/Almon_Strowger for example). > Surely in both cases a splicing/switching node=20 > must perform a label lookup on ingress to determine the=20 > egress? If so, whether a packet is repeated or switched a=20 > switching/splicing node must still be configured with or=20 > dynamically learn what the next hop/egress interface is for=20 > an incoming packet. >=20 > This brings us back to the question over the=20 > routing/discovery functions. An operator must perform these=20 > functions in order to establish a multi-hop PW, the only=20 > question is over how the functions are performed, the options=20 > being via manual configuration, OSS, or dynamic protocols. NH=3D> I suppose we could find gainful employment for a bunch of 'operators' again ;-) >=20 > So is it the case that option a) above means that=20 > routing/discovery for multi-hop PWs is out of scope, and=20 > therefore must be performed using manual configuration, OSS=20 > or dynamic protocols defined in another WG? If so, what about=20 > other PW splicing requirements such as interworking (i.e.=20 > MPLS<->L2TP), resilience (e.g. to protect against splicing=20 > node failure), and OAM? NH=3D> This is a slippery slope. The fact of the matter is that a new layer network will be created.....you can't get away from that no matter how folks try and dress it up (though to be fair I am not sure all folks will readily grasp this point as many don't have any functional arch background). That said, then all the functions one needs for a layer network (and BTW its a co-ps mode network if anyone was wondering) will need to be developed *if* one thinks its going to be successful. One can, of course, plan for failure from the outset and not do a proper design at t=3D0. regards, Neil >=20 > Regards, > Richard >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 09:16:12 +0100 Lines: 55 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: erosen@cisco.com, pwe3@ietf.org, richard.spencer@bt.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Wed Oct 13 10:24:35 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSwqHiIX6PNsOucQG+OYiVyYwCy4wAUMWcA To: , X-OriginalArrivalTime: 13 Oct 2004 08:16:12.0775 (UTC) FILETIME=[E70B6F70:01C4B0FC] X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Tony/Peter, Tony Li wrote 12 October 2004 22:51 > > Is my understanding correct and if so, why do you think that it is a > > better approach? Why would the PW layer combat the TE=20 > layer? I wasn't=20 > > aware of any restrictions in the PWE3 architecture that=20 > would prevent=20 > > the merging of PW traffic and non-PW traffic on the same=20 > Tunnel LSPs.=20 > > Therefore, I didn't think there would be any conflict between=20 > > allocating bandwidth to MH-PWs and to other non-PW LSPs. > > >=20 > Perhaps I'm misunderstanding then. If you agree with the=20 > heirarchical=20 > model, then what is the purpose of using RSVP for > signalling? All of the functionality that RSVP provides would be=20 > handled by lower layers (as they should be, IMHO ;-) and > PW can continue to operate in a manner oblivious to such details as=20 > path selection. >=20 > Put more generally, I'm trying to suggest the obverse to the=20 > end-to-end=20 > principle: if the middle of the network has to > do something to make things work, then the end systems shouldn't=20 > participate. >=20 > Tony NH=3D> If we assume the core technology is going to be MPLS then PW switching is a complete nonsense IMO. That is, one is simply using MPLS as the switching technology. So I agree with Tony on this point....and AFAI can tell Peter was saying something rather similar in the snipped bit of his mail (viz "In my earlier emails, I have implicitly made the assumption that a Multi-hop PW is essentially an LSP in its own right."). However, if one wants to carry on the pretence that = IP=3D=3DMPLS with the misguided egalitarian objective that 'whatever we do for MPLS we must also do for IP' then PW switching (or at least peer-partition PW interworking) will rear its head. I also think there maybe some 'non-technical' reasons at play here. For example, I could postulate that some folks have 'done' an LDP-based solution and LDP is not really a good signalling protocol. So what to do? Can't go back and resurrect CR-LDP can we (?)....ergo the fudging of 'PW st/witching' etc. If there are scaling concerns, then perhaps folks ought to look hard at why there are scaling concerns, eg are the signalling protocols at our disposal really right for the job being asked? (But don't confuse this with the need for hierarchy) regards, Neil From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: =?us-ascii?Q?Benny_Ammitzboll?= Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 11:31:56 +0200 Lines: 75 Sender: pwe3-bounces@ietf.org References: <0536FC9B908BEC4597EE721BE6A353890B2CFE45@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Wed Oct 13 11:43:34 2004 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <0536FC9B908BEC4597EE721BE6A353890B2CFE45@i2km07-ukbr.domain1.systemhost.net> X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Neil, Well said, I fully agree. /Benny -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of neil.2.harrison@bt.com Sent: 13. oktober 2004 10:16 To: tony.li@tony.li; busschbach@lucent.com Cc: erosen@cisco.com; pwe3@ietf.org; richard.spencer@bt.com; Sasha@AXERRA.com; stbryant@cisco.com Subject: RE: [PWE3] RSVP-TE and PW Tony/Peter, Tony Li wrote 12 October 2004 22:51 > > Is my understanding correct and if so, why do you think that it is a > > better approach? Why would the PW layer combat the TE > layer? I wasn't > > aware of any restrictions in the PWE3 architecture that > would prevent > > the merging of PW traffic and non-PW traffic on the same > Tunnel LSPs. > > Therefore, I didn't think there would be any conflict between > > allocating bandwidth to MH-PWs and to other non-PW LSPs. > > > > Perhaps I'm misunderstanding then. If you agree with the > heirarchical > model, then what is the purpose of using RSVP for > signalling? All of the functionality that RSVP provides would be > handled by lower layers (as they should be, IMHO ;-) and > PW can continue to operate in a manner oblivious to such details as > path selection. > > Put more generally, I'm trying to suggest the obverse to the > end-to-end > principle: if the middle of the network has to > do something to make things work, then the end systems shouldn't > participate. > > Tony NH=> If we assume the core technology is going to be MPLS then PW switching is a complete nonsense IMO. That is, one is simply using MPLS as the switching technology. So I agree with Tony on this point....and AFAI can tell Peter was saying something rather similar in the snipped bit of his mail (viz "In my earlier emails, I have implicitly made the assumption that a Multi-hop PW is essentially an LSP in its own right."). However, if one wants to carry on the pretence that IP==MPLS with the misguided egalitarian objective that 'whatever we do for MPLS we must also do for IP' then PW switching (or at least peer-partition PW interworking) will rear its head. I also think there maybe some 'non-technical' reasons at play here. For example, I could postulate that some folks have 'done' an LDP-based solution and LDP is not really a good signalling protocol. So what to do? Can't go back and resurrect CR-LDP can we (?)....ergo the fudging of 'PW st/witching' etc. If there are scaling concerns, then perhaps folks ought to look hard at why there are scaling concerns, eg are the signalling protocols at our disposal really right for the job being asked? (But don't confuse this with the need for hierarchy) regards, Neil _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: RSVP-TE and PW Date: Wed, 13 Oct 2004 10:09:00 -0400 Lines: 61 Sender: pwe3-bounces@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org, "'richard.spencer@bt.com'" , Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 16:21:27 2004 Return-path: X-BrightmailFiltered: true To: "Busschbach, Peter B (Peter)" In-reply-to: Your message of Tue, 12 Oct 2004 13:29:39 -0400. 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) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > It is a little late, but I had a few comments on your email from last > week. It's never too late to try to address the substantive technical issues; this would be a much shorter thread if we eliminated all the useless pontificating about grand architectural issues (not to mention the various attempts on all sides to question the motives of others), and focused on the detailed technical issues. (Peter, this complaint is not directed at you.) > The signaling message must identify the egress PE (which would require an > ERO, even if it would only contain the end point of the path). If we merely need to identify the ultimate endpoint of the path, we do not need anything like an ERO, nor would we choose one signaling protocol over another simply because it provides an ERO object. After all, it is the rare protocol that does not provide an endpoint identifier of some sort. > It is possible that a signaling message identifies more than one PW > switching point, but I think it would be more likely that the first PW > switching point uses the node id of the egress PE to determine the next PW > switching point, and so on. This seems reasonable, it's the typical routing model, and does not require an ERO. > if you add QoS- and ERO-related objects to LDP, it becomes CR-LDP People keep saying that, but that just isn't true. RSVP-TE was preferred to CR-LDP because RSVP was already used for applying network layer QoS characteristics to paths through the network. Unless one is proposing to use LDP for this purpose, one is not proposing CR-LDP. If the only enhancements to LDP are the introduction of an opaque QoS object and the introduction of an endpoint identifier (wait, LDP already has that!), then I don't think we have to worry about CR-LDP returning from the dead. > Do we really want to end up in a situation in which LSRs support RSVP-TE > to set up regular LSPs and CR-LDP if they act as PW switching points? I object to the formulation of this question, as I think the "CR-LDP" stuff is a red herring. But of course, one could equally well ask: "do we really want to end up in a situation in which LSRs support LDP to set up regular LSPs and RSVP-TE if they support traffic engineering?" Whoops, that question has already been answered ;-) So how about the question: "do we really want to end up in a situation in which LSRs support LDP to set up regular PWs and RSVP-TE to set up switched PWs?" or "do we really want to end up in a situation in which LSRs support LDP to set up regular LSPs and RSVP-TE to set up switched PWs?" I don't think that this path will lead to any conclusion, which is why I've been trying to focus on whether RSVP-TE actually lets you do something easily which could not be easily done with the existing PWE3 control protocol. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 11:14:02 -0400 Lines: 9 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, "'richard.spencer@bt.com'" , Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 17:21:07 2004 Return-path: To: "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Eric> If the only enhancements to LDP are the introduction of an Eric> opaque QoS object and the introduction of an endpoint Eric> identifier (wait, LDP already has that!), then I Eric> don't think we have to worry about CR-LDP returning from the dead. > End-point identifier: are you referring to the FEC, or is there another LDP object that can be used to identify an endpoint? Opaque QoS: It is not opaque!! In the case of MH-PWs with associate QoS characteristics, the PW switching nodes must allocate resources to each PW. I still believe that: *if* there is a need for MH-PWs within a Service Provider network and *if* there is a need to associate QoS characteristics with PWs, then such a MH-PW looks exactly like any other traffic-engineered LSP. If RSVP-TE is the appropriate protocol to set up such LSPs, it should be the appropriate tool to set up MH-PWs with QoS characteristics. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: RSVP-TE and PW Date: Wed, 13 Oct 2004 12:48:18 -0400 Lines: 13 Sender: pwe3-bounces@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org, "'richard.spencer@bt.com'" , Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 19:04:58 2004 Return-path: X-BrightmailFiltered: true To: "Busschbach, Peter B (Peter)" In-reply-to: Your message of Wed, 13 Oct 2004 11:14:02 -0400. 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) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > End-point identifier: are you referring to the FEC, or is there another > LDP object that can be used to identify an endpoint? The FEC identifies the endpoint. If the currently defined FECs are insufficient for this purpose when PW switching is done, we can discuss how to augment them. > In the case of MH-PWs with associate QoS characteristics, the PW switching > nodes must allocate resources to each PW. Could you be specific about what these resources are and how their allocation is to be affected by the QoS parameter? From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 13:02:25 -0400 Lines: 39 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, "'richard.spencer@bt.com'" , Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 19:18:32 2004 Return-path: To: "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, October 13, 2004 12:48 PM > To: Busschbach, Peter B (Peter) > Cc: 'Stewart Bryant'; Sasha Vainshtein; pwe3@ietf.org; > 'richard.spencer@bt.com' > Subject: Re: [PWE3] RSVP-TE and PW > > > > > End-point identifier: are you referring to the FEC, or > is there another > > LDP object that can be used to identify an endpoint? > > The FEC identifies the endpoint. If the currently > defined FECs are > insufficient for this purpose when PW switching is done, we > can discuss how > to augment them. Fair enough. > > > In the case of MH-PWs with associate QoS characteristics, > the PW switching > > nodes must allocate resources to each PW. > > Could you be specific about what these resources are > and how their > allocation is to be affected by the QoS parameter? I meant that a PW Switching node must make sure that the bandwidth, packet loss and delay characteristics of the PW are met. In other words: if the PW switching node can switch a certain amount of bandwidth, it must allocate some of this bandwidth to the PW. > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Shah, Himanshu" Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 14:12:06 -0400 Lines: 57 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, Sasha Vainshtein , "'richard.spencer@bt.com'" , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 20:27:38 2004 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Peter, I believe that by using a target-PE TLV in optional field of PWE3 control signaling, one can achieve what you are looking for. This additional target-PE TLV will contain the IP address of target-PE and some other stuff, if needed. This along with QOS TLV as defined in shah-pwe3-pw-qos-signaling draft would enable each intermediate PE to find the next hop and a suitable transport tunnel to the next hop, all the way to the destination PE. In short, starting from source, based on the destination, each PE hop forwards the pwe3 control signal to the next hop and responds to the previous hop with the pw label, and programs the FIB for PW label switching. Do you think this meets the requirements? /himanshu > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Wednesday, October 13, 2004 11:14 AM > To: 'erosen@cisco.com' > Cc: pwe3@ietf.org; 'richard.spencer@bt.com'; Sasha > Vainshtein; 'Stewart > Bryant' > Subject: RE: [PWE3] RSVP-TE and PW > > > > Eric> If the only enhancements to LDP are the introduction of an > Eric> opaque QoS object and the introduction of an endpoint > Eric> identifier (wait, LDP already has that!), then I > Eric> don't think we have to worry about CR-LDP returning > from the dead. > > > End-point identifier: are you referring to the FEC, or is > there another LDP object that can be used to identify an endpoint? > > Opaque QoS: It is not opaque!! In the case of MH-PWs with > associate QoS characteristics, the PW switching nodes must > allocate resources to each PW. I still believe that: *if* > there is a need for MH-PWs within a Service Provider network > and *if* there is a need to associate QoS characteristics > with PWs, then such a MH-PW looks exactly like any other > traffic-engineered LSP. If RSVP-TE is the appropriate > protocol to set up such LSPs, it should be the appropriate > tool to set up MH-PWs with QoS characteristics. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: RSVP-TE and PW Date: Wed, 13 Oct 2004 14:51:00 -0400 Lines: 18 Sender: pwe3-bounces@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org, "'richard.spencer@bt.com'" , Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 21:09:11 2004 Return-path: X-BrightmailFiltered: true To: "Busschbach, Peter B (Peter)" In-reply-to: Your message of Wed, 13 Oct 2004 13:02:25 -0400. 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) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > I meant that a PW Switching node must make sure that the bandwidth, packet > loss and delay characteristics of the PW are met. In other words: if the > PW switching node can switch a certain amount of bandwidth, it must > allocate some of this bandwidth to the PW. I don't think so. The switching node just assigns the PW to an LSP tunnel with appropriate QoS characteristics. The data plane model is that packets move from one tunnel to the next by dint of ordinary MPLS switching. Thus the relevant QoS characteristics are characteristics of the LSP tunnels. There are no resources or queuing strategies that are under the control of the PW control plane. I think it is appropriate to say that the QoS object is "opaque" to the PW control protocol, because the PW control protocol does not need to understand the queuing or other resource allocation strategies needed to provide the QoS. Providing the necessary QoS is the function of the LSP tunnels. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 14:55:44 -0400 Lines: 81 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, Sasha Vainshtein , "'richard.spencer@bt.com'" , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 21:15:20 2004 Return-path: To: "'Shah, Himanshu'" , "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Wednesday, October 13, 2004 2:12 PM > To: 'Busschbach, Peter B (Peter)'; 'erosen@cisco.com' > Cc: pwe3@ietf.org; 'richard.spencer@bt.com'; Sasha > Vainshtein; 'Stewart > Bryant' > Subject: RE: [PWE3] RSVP-TE and PW > > > Peter, > > I believe that by using a target-PE TLV in optional field > of PWE3 control signaling, one can achieve what you are > looking for. This additional target-PE TLV will contain the > IP address of target-PE and some other stuff, if needed. > > This along with QOS TLV as defined in shah-pwe3-pw-qos-signaling > draft would enable each intermediate PE to find the next hop > and a suitable transport tunnel to the next hop, all the way to > the destination PE. In short, starting from source, based on > the destination, each PE hop forwards the pwe3 control signal to > the next hop and responds to the previous hop with the pw label, > and programs the FIB for PW label switching. > > Do you think this meets the requirements? Hi Himanchu, We still don't have a clear formulation of the requirements. Therefore, I can't answer the last question. Would your proposal meet the hypothetical requirements that we have been discussing? Of course. But that is not the point. I don't have any doubt that you can enhance LDP to make it do what we want to do. The question is, once all is set and done, haven't we recreated a signaling protocol that does the same as RSVP-TE? And if so, is that acceptable? Peter > > /himanshu > > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: Wednesday, October 13, 2004 11:14 AM > > To: 'erosen@cisco.com' > > Cc: pwe3@ietf.org; 'richard.spencer@bt.com'; Sasha > > Vainshtein; 'Stewart > > Bryant' > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > Eric> If the only enhancements to LDP are the > introduction of an > > Eric> opaque QoS object and the introduction of an endpoint > > Eric> identifier (wait, LDP already has that!), then I > > Eric> don't think we have to worry about CR-LDP returning > > from the dead. > > > > > End-point identifier: are you referring to the FEC, or is > > there another LDP object that can be used to identify an endpoint? > > > > Opaque QoS: It is not opaque!! In the case of MH-PWs with > > associate QoS characteristics, the PW switching nodes must > > allocate resources to each PW. I still believe that: *if* > > there is a need for MH-PWs within a Service Provider network > > and *if* there is a need to associate QoS characteristics > > with PWs, then such a MH-PW looks exactly like any other > > traffic-engineered LSP. If RSVP-TE is the appropriate > > protocol to set up such LSPs, it should be the appropriate > > tool to set up MH-PWs with QoS characteristics. > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Shah, Himanshu" Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 15:05:01 -0400 Lines: 108 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, Sasha Vainshtein , "'richard.spencer@bt.com'" , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 21:25:21 2004 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org It is one thing to marginally extend the pwe3 control signaling and other thing to replace with new signaling protocol (that is still evolving - as per discussions in this thread it seems scalability of hierarchical RSPV-TE signagling is still not fully understood) There are pros and cons for both. /himanshu > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Wednesday, October 13, 2004 2:56 PM > To: Shah, Himanshu; 'erosen@cisco.com' > Cc: pwe3@ietf.org; 'richard.spencer@bt.com'; Sasha > Vainshtein; 'Stewart > Bryant' > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > -----Original Message----- > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > Sent: Wednesday, October 13, 2004 2:12 PM > > To: 'Busschbach, Peter B (Peter)'; 'erosen@cisco.com' > > Cc: pwe3@ietf.org; 'richard.spencer@bt.com'; Sasha > > Vainshtein; 'Stewart > > Bryant' > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > Peter, > > > > I believe that by using a target-PE TLV in optional field > > of PWE3 control signaling, one can achieve what you are > > looking for. This additional target-PE TLV will contain the > > IP address of target-PE and some other stuff, if needed. > > > > This along with QOS TLV as defined in shah-pwe3-pw-qos-signaling > > draft would enable each intermediate PE to find the next hop > > and a suitable transport tunnel to the next hop, all the way to > > the destination PE. In short, starting from source, based on > > the destination, each PE hop forwards the pwe3 control signal to > > the next hop and responds to the previous hop with the pw label, > > and programs the FIB for PW label switching. > > > > Do you think this meets the requirements? > > Hi Himanchu, > > We still don't have a clear formulation of the requirements. > Therefore, I can't answer the last question. > > Would your proposal meet the hypothetical requirements that > we have been discussing? Of course. But that is not the > point. I don't have any doubt that you can enhance LDP to > make it do what we want to do. The question is, once all is > set and done, haven't we recreated a signaling protocol that > does the same as RSVP-TE? And if so, is that acceptable? > > Peter > > > > > > /himanshu > > > > > > > -----Original Message----- > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > Sent: Wednesday, October 13, 2004 11:14 AM > > > To: 'erosen@cisco.com' > > > Cc: pwe3@ietf.org; 'richard.spencer@bt.com'; Sasha > > > Vainshtein; 'Stewart > > > Bryant' > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > Eric> If the only enhancements to LDP are the > > introduction of an > > > Eric> opaque QoS object and the introduction of an endpoint > > > Eric> identifier (wait, LDP already has that!), then I > > > Eric> don't think we have to worry about CR-LDP returning > > > from the dead. > > > > > > > End-point identifier: are you referring to the FEC, or is > > > there another LDP object that can be used to identify an endpoint? > > > > > > Opaque QoS: It is not opaque!! In the case of MH-PWs with > > > associate QoS characteristics, the PW switching nodes must > > > allocate resources to each PW. I still believe that: *if* > > > there is a need for MH-PWs within a Service Provider network > > > and *if* there is a need to associate QoS characteristics > > > with PWs, then such a MH-PW looks exactly like any other > > > traffic-engineered LSP. If RSVP-TE is the appropriate > > > protocol to set up such LSPs, it should be the appropriate > > > tool to set up MH-PWs with QoS characteristics. > > > > > > > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 15:09:10 -0400 Lines: 28 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, "'richard.spencer@bt.com'" , Sasha Vainshtein , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 21:26:50 2004 Return-path: To: "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > > > I meant that a PW Switching node must make sure that the > bandwidth, packet > > loss and delay characteristics of the PW are met. In > other words: if the > > PW switching node can switch a certain amount of > bandwidth, it must > > allocate some of this bandwidth to the PW. > > I don't think so. The switching node just assigns the PW > to an LSP tunnel > with appropriate QoS characteristics. The data plane model > is that packets > move from one tunnel to the next by dint of ordinary MPLS > switching. Thus > the relevant QoS characteristics are characteristics of > the LSP tunnels. > There are no resources or queuing strategies that are under > the control of > the PW control plane. > Just to make sure that we talk about the same model: a PW Switching node terminates one Tunnel LSP, switches based on the PW label and forwards the traffic over another Tunnel LSP. In that model, the Tunnel LSPs have the same function as any other physical or logical interface. The determination of which PWs are forwarded over which LSP Tunnels is determined by the QoS characteristics of each PW. Therefore, I do believe that there are resources and queuing strategies under the control of the PW control plane. Note: a PW Switching node would need hierarchical scheduling, since the Tunnel LSPs themselves need the appropriate resources. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Wed, 13 Oct 2004 15:13:31 -0400 Lines: 54 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'pwe3@ietf.org'" , "'richard.spencer@bt.com'" , 'Sasha Vainshtein' , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Wed Oct 13 21:52:19 2004 Return-path: To: "'erosen@cisco.com'" X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > Note: a PW Switching node would need hierarchical scheduling, > since the Tunnel LSPs themselves need the appropriate resources. I take this back. It is not necessarily true. > -----Original Message----- > From: Busschbach, Peter B (Peter) > Sent: Wednesday, October 13, 2004 3:09 PM > To: 'erosen@cisco.com' > Cc: 'Stewart Bryant'; Sasha Vainshtein; pwe3@ietf.org; > 'richard.spencer@bt.com' > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > I meant that a PW Switching node must make sure that the > > bandwidth, packet > > > loss and delay characteristics of the PW are met. In > > other words: if the > > > PW switching node can switch a certain amount of > > bandwidth, it must > > > allocate some of this bandwidth to the PW. > > > > I don't think so. The switching node just assigns the PW > > to an LSP tunnel > > with appropriate QoS characteristics. The data plane model > > is that packets > > move from one tunnel to the next by dint of ordinary MPLS > > switching. Thus > > the relevant QoS characteristics are characteristics of > > the LSP tunnels. > > There are no resources or queuing strategies that are under > > the control of > > the PW control plane. > > > > Just to make sure that we talk about the same model: a PW > Switching node terminates one Tunnel LSP, switches based on > the PW label and forwards the traffic over another Tunnel LSP. > > In that model, the Tunnel LSPs have the same function as any > other physical or logical interface. The determination of > which PWs are forwarded over which LSP Tunnels is determined > by the QoS characteristics of each PW. Therefore, I do > believe that there are resources and queuing strategies under > the control of the PW control plane. > > Note: a PW Switching node would need hierarchical scheduling, > since the Tunnel LSPs themselves need the appropriate resources. > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Chris Metz Subject: Re: RSVP-TE and PW Date: Wed, 13 Oct 2004 15:22:50 -0700 Lines: 20 Sender: pwe3-bounces@ietf.org References: <200410131851.i9DIp0YX019163@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Busschbach, Peter B \(Peter\)" , pwe3@ietf.org, Sasha Vainshtein , "'richard.spencer@bt.com'" , 'Stewart Bryant' X-From: pwe3-bounces@ietf.org Thu Oct 14 00:39:40 2004 Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: erosen@cisco.com In-Reply-To: <200410131851.i9DIp0YX019163@rtp-core-1.cisco.com> References: X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org At 02:51 PM 10/13/2004 -0400, Eric Rosen wrote: > > I meant that a PW Switching node must make sure that the bandwidth, packet > > loss and delay characteristics of the PW are met. In other words: if the > > PW switching node can switch a certain amount of bandwidth, it must > > allocate some of this bandwidth to the PW. > >I don't think so. The switching node just assigns the PW to an LSP tunnel >with appropriate QoS characteristics. The data plane model is that packets >move from one tunnel to the next by dint of ordinary MPLS switching. Thus >the relevant QoS characteristics are characteristics of the LSP tunnels. >There are no resources or queuing strategies that are under the control of >the PW control plane. I think I agree ... but is this true even if you PHP the LSP tunnel label of the preceding PW segment and the packet arrives at the switching PE with just a PW label? From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: richard.spencer@bt.com Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 01:21:19 +0100 Lines: 56 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 02:42:55 2004 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RSVP-TE and PW Thread-Index: AcSxVbub/98lKQdpSq+gfMqwhGVfdgAAE6XQ To: , X-OriginalArrivalTime: 14 Oct 2004 00:21:20.0014 (UTC) FILETIME=[BA72E2E0:01C4B183] X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Eric, > I don't think so. The switching node just assigns the PW =20 > to an LSP tunnel with appropriate QoS characteristics. =20 > The data plane model is that packets move from one tunnel =20 > to the next by dint of ordinary MPLS switching. Thus the =20 > relevant QoS characteristics are characteristics of the =20 > LSP tunnels. There are no resources or queuing strategies=20 > that are under the control of the PW control plane.=20 >=20 > I think it is appropriate to say that the QoS object is=20 > "opaque" to the PW control protocol, because the PW =20 > control protocol does not need to understand the=20 > queuing or other resource allocation strategies needed to > provide the QoS. Providing the necessary QoS is the=20 > function of the LSP tunnels. I think the definition of whether a QoS object is opaque to the PW = signalling protocol or not is dependant on the what functions are being = performed on the QoS object, and what mechanisms are performing those = functions. For example, in a network that uses single hop PWs, CAC may be performed = (for leased line/CBR type services) based on the bandwidth required by = the attachment circuit as part of the provisioning process to ensure = that an egress (PE-PE) TE tunnel has enough bandwidth available before = signalling a PW. In a (hypothetical) network that uses PW switching with TE tunnels = between switching nodes, to ensure bandwidth is available for any given = PW end-to-end across multiple TE tunnels, CAC would need to be performed = at each switching node as part of the provisioning process. As switching = nodes are not directly attached to attachment circuits, they would need = to receive the PW bandwidth information through the PW signalling = protocol. With single hop PWs, CAC is performed prior to PW signalling and = therefore it can be performed by a separate mechanism (i.e. not the = signalling protocol), but what about the switched PW case? For switched = PWs CAC would need to be performed at switching nodes during the = signalling process. So either the signalling protocol would need to = perform the CAC function, or the signalling protocol would need to send = the bandwidth information to a separate CAC mechanism and wait for a = response before continuing.=20 If the PW signalling protocol performs the CAC function then obviously = the bandwidth information could not be considered to be opaque, if on = the other hand the CAC function was performed by a separate mechanism, = then the bandwidth information could be considered to be opaque. Saying = that, the two methods perform exactly the same functionality, I think = its more of an implementation/standards specification issue as to = whether the CAC function is considered to be part of the signalling = mechanism or separate. Regards, Richard From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Diego Caviglia" Subject: Re: RSVP-TE and PW Date: Thu, 14 Oct 2004 08:53:14 +0200 Lines: 73 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: erosen@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 08:58:13 2004 Return-path: To: pwe3@ietf.org X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 14/10/2004 07:53:22 X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Eric, I've a question, what is the difference between having a PW signalled with LDP in a MPLS Tunnel signalled with RSVP-TE and having two nested LSP signalled with RSVP-TE? Or having an LSP acting as PW and a tunnel (e.g. VC4) signalled both with G.RSVP-TE? I mean from the service I'm offering to the final customer. One more question: if I use the PWE3 encapsulation IDs to encapsulate traffic but I set up both the PW and the Tunnel with e.g. G.RSVP-TE can I say that I'm offering a VPLS service? Regards Diego Eric Rosen @ietf.org on 13/10/2004 20.51.00 Please respond to erosen@cisco.com Sent by: pwe3-bounces@ietf.org From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Matthew.Bocci@alcatel.co.uk Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 11:40:10 +0100 Lines: 99 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, busschbach@lucent.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 13:15:33 2004 Return-path: To: richard.spencer@bt.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/14/2004 12:04:31 X-Alcanet-MTA-scanned-and-authorized: yes X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Richard, I agree with what you are saying in general, but I think that we can achieve this with relatively simple extensions to T-LDP. We already have a proposal for a way to signal traffic parameters in draft-shah, and I think it would be simple to enable T-LDP to signal the ultimate target PE (either usings one of the existing FECs, or a new one). If a PE can maintain a binding of ingress and egress T-LDP sessions, then we can also effectively crankback PW setup attempts that fail or block at an intermediate switching node. Best regards, Matthew |---------+---------------------------> | | richard.spencer@| | | bt.com | | | Sent by: | | | pwe3-bounces@iet| | | f.org | | | | | | | | | 14/10/2004 01:21| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | To: , | | cc: pwe3@ietf.org, Sasha@AXERRA.com, stbryant@cisco.com | | Subject: RE: [PWE3] RSVP-TE and PW | >-------------------------------------------------------------------------------------------------------------------------------| Eric, > I don't think so. The switching node just assigns the PW > to an LSP tunnel with appropriate QoS characteristics. > The data plane model is that packets move from one tunnel > to the next by dint of ordinary MPLS switching. Thus the > relevant QoS characteristics are characteristics of the > LSP tunnels. There are no resources or queuing strategies > that are under the control of the PW control plane. > > I think it is appropriate to say that the QoS object is > "opaque" to the PW control protocol, because the PW > control protocol does not need to understand the > queuing or other resource allocation strategies needed to > provide the QoS. Providing the necessary QoS is the > function of the LSP tunnels. I think the definition of whether a QoS object is opaque to the PW signalling protocol or not is dependant on the what functions are being performed on the QoS object, and what mechanisms are performing those functions. For example, in a network that uses single hop PWs, CAC may be performed (for leased line/CBR type services) based on the bandwidth required by the attachment circuit as part of the provisioning process to ensure that an egress (PE-PE) TE tunnel has enough bandwidth available before signalling a PW. In a (hypothetical) network that uses PW switching with TE tunnels between switching nodes, to ensure bandwidth is available for any given PW end-to-end across multiple TE tunnels, CAC would need to be performed at each switching node as part of the provisioning process. As switching nodes are not directly attached to attachment circuits, they would need to receive the PW bandwidth information through the PW signalling protocol. With single hop PWs, CAC is performed prior to PW signalling and therefore it can be performed by a separate mechanism (i.e. not the signalling protocol), but what about the switched PW case? For switched PWs CAC would need to be performed at switching nodes during the signalling process. So either the signalling protocol would need to perform the CAC function, or the signalling protocol would need to send the bandwidth information to a separate CAC mechanism and wait for a response before continuing. If the PW signalling protocol performs the CAC function then obviously the bandwidth information could not be considered to be opaque, if on the other hand the CAC function was performed by a separate mechanism, then the bandwidth information could be considered to be opaque. Saying that, the two methods perform exactly the same functionality, I think its more of an implementation/standards specification issue as to whether the CAC function is considered to be part of the signalling mechanism or separate. Regards, Richard _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Matthew.Bocci@alcatel.co.uk Subject: PW switching and OAM Date: Thu, 14 Oct 2004 12:45:55 +0100 Lines: 32 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-bounces@ietf.org Thu Oct 14 14:01:17 2004 Return-path: To: pwe3@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11 |July 24, 2002) at 10/14/2004 12:47:12 X-Alcanet-MTA-scanned-and-authorized: yes X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The impact of PW switching on OAM does not seem to have been discussed in much depth yet, but I think that given where we are with the OAM message mapping draft, it is worth looking at how this applies in the multi-hop case. If by PW switching/stitching we are creating a layer network, then I think the OAM model should not be any different from a layer network today. That is, we have clear definitions of segment and and to end OAM on the PW. However, the OAM tools for PWs e.g. VCCV, assume a single-hop (as noted by Sasha in a previous email) i.e. effectively a single OAM segment. What are the implications of extending these to a multi-hop PW network? The other question that I have is how to deal with fault alarm propagation between concatenated single hop PWs. At the moment, we can use either in-band or out of band fault notification mechanisms, depending on the PW type or encapsulation used. draft-martini-pwe3-pw-switching-00.txt says that one motivation for stitching PWs is to enable ultimate PEs with different signaling and encapsulation protocols to be connected. While I agree that this is a good motivation in principle, I think it raises some questions about how to propagate fault notifications across the stitching node. For example, take the case of an ATM PW being transported end to end across two PW domains. In one domain, only static PWs with ATM cell mode encapsulation are supported. In the other domain, ATM SDU mode is supported with PW status signalling. Getting fault notifications across the switching node implies that the node will have to understand ATM AIS/RDI, and translate this to PW status signalling. This is an extreme example, but I think it illustrates that there need to be some pragmatic constraints on the PW types that we stitch e.g. the same OAM mechanisms in each domain. Best regards, Matthew From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: dimitri papadimitriou Subject: Re: RSVP-TE and PW Date: Thu, 14 Oct 2004 14:05:10 +0200 Lines: 136 Sender: pwe3-bounces@ietf.org References: Reply-To: dpapadimitriou@psg.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com, busschbach@lucent.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 14:12:47 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en To: Matthew.Bocci@alcatel.co.uk In-Reply-To: X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org matthew, as of today, i don't see why/how T-LDP QoS extensions can be qualified as "relatively simple" or "marginal extensions" (as i have seen this argument used many times on this list) without any real proposal on the table for this purpose (i don't speak about the point-to-point exchange of QoS AC parameters as in draft-shah where only ultimate PEs are involved) ? this said, what is the QoS model and AC model that is associated to LDP signaling on ultimate and intermediate switching PEs ? so, as you are a bit evasive on how you would "transform" a point-to-point non-QoS capable protocol into an end-to-end QoS capable protocol, would you please clarify ? the next question is how end-to-end and/or partial re-routing of such switched PW entities will be achieved in case of switching PE node failure ? much thanks for your clarifications, - dimitri. Matthew.Bocci@alcatel.co.uk wrote: > Richard, > > I agree with what you are saying in general, but I think that we can > achieve this with relatively simple extensions to T-LDP. > > We already have a proposal for a way to signal traffic parameters in > draft-shah, and I think it would be simple to enable T-LDP to signal the > ultimate target PE (either usings one of the existing FECs, or a new one). > If a PE can maintain a binding of ingress and egress T-LDP sessions, then > we can also effectively crankback PW setup attempts that fail or block at > an intermediate switching node. > > > Best regards, > > Matthew > > > > |---------+---------------------------> > | | richard.spencer@| > | | bt.com | > | | Sent by: | > | | pwe3-bounces@iet| > | | f.org | > | | | > | | | > | | 14/10/2004 01:21| > | | | > |---------+---------------------------> > >-------------------------------------------------------------------------------------------------------------------------------| > | | > | To: , | > | cc: pwe3@ietf.org, Sasha@AXERRA.com, stbryant@cisco.com | > | Subject: RE: [PWE3] RSVP-TE and PW | > >-------------------------------------------------------------------------------------------------------------------------------| > > > > > Eric, > > >>I don't think so. The switching node just assigns the PW >>to an LSP tunnel with appropriate QoS characteristics. >>The data plane model is that packets move from one tunnel >>to the next by dint of ordinary MPLS switching. Thus the >>relevant QoS characteristics are characteristics of the >>LSP tunnels. There are no resources or queuing strategies >>that are under the control of the PW control plane. >> >>I think it is appropriate to say that the QoS object is >>"opaque" to the PW control protocol, because the PW >>control protocol does not need to understand the >>queuing or other resource allocation strategies needed to >>provide the QoS. Providing the necessary QoS is the >>function of the LSP tunnels. > > > I think the definition of whether a QoS object is opaque to the PW > signalling protocol or not is dependant on the what functions are being > performed on the QoS object, and what mechanisms are performing those > functions. > > For example, in a network that uses single hop PWs, CAC may be performed > (for leased line/CBR type services) based on the bandwidth required by the > attachment circuit as part of the provisioning process to ensure that an > egress (PE-PE) TE tunnel has enough bandwidth available before signalling a > PW. > > In a (hypothetical) network that uses PW switching with TE tunnels between > switching nodes, to ensure bandwidth is available for any given PW > end-to-end across multiple TE tunnels, CAC would need to be performed at > each switching node as part of the provisioning process. As switching nodes > are not directly attached to attachment circuits, they would need to > receive the PW bandwidth information through the PW signalling protocol. > > With single hop PWs, CAC is performed prior to PW signalling and therefore > it can be performed by a separate mechanism (i.e. not the signalling > protocol), but what about the switched PW case? For switched PWs CAC would > need to be performed at switching nodes during the signalling process. So > either the signalling protocol would need to perform the CAC function, or > the signalling protocol would need to send the bandwidth information to a > separate CAC mechanism and wait for a response before continuing. > > If the PW signalling protocol performs the CAC function then obviously the > bandwidth information could not be considered to be opaque, if on the other > hand the CAC function was performed by a separate mechanism, then the > bandwidth information could be considered to be opaque. Saying that, the > two methods perform exactly the same functionality, I think its more of an > implementation/standards specification issue as to whether the CAC function > is considered to be part of the signalling mechanism or separate. > > Regards, > Richard > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > . > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Shah, Himanshu" Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 08:39:04 -0400 Lines: 215 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com, busschbach@lucent.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 14:45:07 2004 Return-path: To: "'dpapadimitriou@psg.com'" , Matthew.Bocci@alcatel.co.uk X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org As you suggest and I agree that it is fruitless to engage in detailed discussions without a proposal on the table. Although, a couple of question that you have posted can be clarified. As Eric has pointed out many times with clarifications, I don't see why "qos model" and "AC model" is necessary for the underlying LDP signaling protocol. The (opaque) QOS TLV that is singalled to/through each PE hop is used to select the suitable underlying transport tunnel (TE-LSP or other) between PE hops, to perform the CAC and/or to apply appropriate traffic shaping and policing for traffic between PW switch points. As for partial or end-to-end rerouting - we need to wait for the requirements to be hammered out. /himanshu > -----Original Message----- > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > Sent: Thursday, October 14, 2004 8:05 AM > To: Matthew.Bocci@alcatel.co.uk > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > stbryant@cisco.com > Subject: Re: [PWE3] RSVP-TE and PW > > > matthew, > > as of today, i don't see why/how T-LDP QoS extensions can be > qualified > as "relatively simple" or "marginal extensions" (as i have seen this > argument used many times on this list) without any real > proposal on the > table for this purpose (i don't speak about the > point-to-point exchange > of QoS AC parameters as in draft-shah where only ultimate PEs are > involved) ? > > this said, what is the QoS model and AC model that is > associated to LDP > signaling on ultimate and intermediate switching PEs ? so, as > you are a > bit evasive on how you would "transform" a point-to-point non-QoS > capable protocol into an end-to-end QoS capable protocol, would you > please clarify ? > > the next question is how end-to-end and/or partial re-routing of such > switched PW entities will be achieved in case of switching PE > node failure ? > > much thanks for your clarifications, > - dimitri. > > Matthew.Bocci@alcatel.co.uk wrote: > > > Richard, > > > > I agree with what you are saying in general, but I think that we can > > achieve this with relatively simple extensions to T-LDP. > > > > We already have a proposal for a way to signal traffic parameters in > > draft-shah, and I think it would be simple to enable T-LDP > to signal the > > ultimate target PE (either usings one of the existing FECs, > or a new one). > > If a PE can maintain a binding of ingress and egress T-LDP > sessions, then > > we can also effectively crankback PW setup attempts that > fail or block at > > an intermediate switching node. > > > > > > Best regards, > > > > Matthew > > > > > > > > |---------+---------------------------> > > | | richard.spencer@| > > | | bt.com | > > | | Sent by: | > > | | pwe3-bounces@iet| > > | | f.org | > > | | | > > | | | > > | | 14/10/2004 01:21| > > | | | > > |---------+---------------------------> > > > >------------------------------------------------------------- > ------------------------------------------------------------------| > > | > > | > > | To: , > > | > > | cc: pwe3@ietf.org, Sasha@AXERRA.com, > stbryant@cisco.com > | > > | Subject: RE: [PWE3] RSVP-TE and PW > > | > > > >------------------------------------------------------------- > ------------------------------------------------------------------| > > > > > > > > > > Eric, > > > > > >>I don't think so. The switching node just assigns the PW > >>to an LSP tunnel with appropriate QoS characteristics. > >>The data plane model is that packets move from one tunnel > >>to the next by dint of ordinary MPLS switching. Thus the > >>relevant QoS characteristics are characteristics of the > >>LSP tunnels. There are no resources or queuing strategies > >>that are under the control of the PW control plane. > >> > >>I think it is appropriate to say that the QoS object is > >>"opaque" to the PW control protocol, because the PW > >>control protocol does not need to understand the > >>queuing or other resource allocation strategies needed to > >>provide the QoS. Providing the necessary QoS is the > >>function of the LSP tunnels. > > > > > > I think the definition of whether a QoS object is opaque to the PW > > signalling protocol or not is dependant on the what > functions are being > > performed on the QoS object, and what mechanisms are > performing those > > functions. > > > > For example, in a network that uses single hop PWs, CAC may > be performed > > (for leased line/CBR type services) based on the bandwidth > required by the > > attachment circuit as part of the provisioning process to > ensure that an > > egress (PE-PE) TE tunnel has enough bandwidth available > before signalling a > > PW. > > > > In a (hypothetical) network that uses PW switching with TE > tunnels between > > switching nodes, to ensure bandwidth is available for any given PW > > end-to-end across multiple TE tunnels, CAC would need to be > performed at > > each switching node as part of the provisioning process. As > switching nodes > > are not directly attached to attachment circuits, they would need to > > receive the PW bandwidth information through the PW > signalling protocol. > > > > With single hop PWs, CAC is performed prior to PW > signalling and therefore > > it can be performed by a separate mechanism (i.e. not the signalling > > protocol), but what about the switched PW case? For > switched PWs CAC would > > need to be performed at switching nodes during the > signalling process. So > > either the signalling protocol would need to perform the > CAC function, or > > the signalling protocol would need to send the bandwidth > information to a > > separate CAC mechanism and wait for a response before continuing. > > > > If the PW signalling protocol performs the CAC function > then obviously the > > bandwidth information could not be considered to be opaque, > if on the other > > hand the CAC function was performed by a separate > mechanism, then the > > bandwidth information could be considered to be opaque. > Saying that, the > > two methods perform exactly the same functionality, I think > its more of an > > implementation/standards specification issue as to whether > the CAC function > > is considered to be part of the signalling mechanism or separate. > > > > Regards, > > Richard > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > . > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 09:28:17 -0400 Lines: 245 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 15:33:45 2004 Return-path: To: "'Shah, Himanshu'" , "'dpapadimitriou@psg.com'" , Matthew.Bocci@alcatel.co.uk X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Thursday, October 14, 2004 8:39 AM > To: 'dpapadimitriou@psg.com'; Matthew.Bocci@alcatel.co.uk > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > stbryant@cisco.com > Subject: RE: [PWE3] RSVP-TE and PW > > > As you suggest and I agree that it is fruitless to engage > in detailed discussions without a proposal on the table. > > Although, a couple of question that you have posted can > be clarified. As Eric has pointed out many times with > clarifications, I don't see why "qos model" and "AC model" > is necessary for the underlying LDP signaling protocol. > > The (opaque) QOS TLV that is singalled to/through each PE hop is used > to select the suitable underlying transport tunnel (TE-LSP > or other) between PE hops, to perform the CAC and/or to apply > appropriate traffic shaping and policing for traffic between PW switch > points. How can an object be both opaque AND be used for CAC and tunnel selection? I suggest you read Richard's email again. His analysis is right on. > > As for partial or end-to-end rerouting - we need to wait for > the requirements to be hammered out. > > > /himanshu > > > -----Original Message----- > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > Sent: Thursday, October 14, 2004 8:05 AM > > To: Matthew.Bocci@alcatel.co.uk > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > stbryant@cisco.com > > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > matthew, > > > > as of today, i don't see why/how T-LDP QoS extensions can be > > qualified > > as "relatively simple" or "marginal extensions" (as i have > seen this > > argument used many times on this list) without any real > > proposal on the > > table for this purpose (i don't speak about the > > point-to-point exchange > > of QoS AC parameters as in draft-shah where only ultimate PEs are > > involved) ? > > > > this said, what is the QoS model and AC model that is > > associated to LDP > > signaling on ultimate and intermediate switching PEs ? so, as > > you are a > > bit evasive on how you would "transform" a point-to-point non-QoS > > capable protocol into an end-to-end QoS capable protocol, would you > > please clarify ? > > > > the next question is how end-to-end and/or partial > re-routing of such > > switched PW entities will be achieved in case of switching PE > > node failure ? > > > > much thanks for your clarifications, > > - dimitri. > > > > Matthew.Bocci@alcatel.co.uk wrote: > > > > > Richard, > > > > > > I agree with what you are saying in general, but I think > that we can > > > achieve this with relatively simple extensions to T-LDP. > > > > > > We already have a proposal for a way to signal traffic > parameters in > > > draft-shah, and I think it would be simple to enable T-LDP > > to signal the > > > ultimate target PE (either usings one of the existing FECs, > > or a new one). > > > If a PE can maintain a binding of ingress and egress T-LDP > > sessions, then > > > we can also effectively crankback PW setup attempts that > > fail or block at > > > an intermediate switching node. > > > > > > > > > Best regards, > > > > > > Matthew > > > > > > > > > > > > |---------+---------------------------> > > > | | richard.spencer@| > > > | | bt.com | > > > | | Sent by: | > > > | | pwe3-bounces@iet| > > > | | f.org | > > > | | | > > > | | | > > > | | 14/10/2004 01:21| > > > | | | > > > |---------+---------------------------> > > > > > >------------------------------------------------------------- > > ------------------------------------------------------------------| > > > | > > > > | > > > | To: , > > > > | > > > | cc: pwe3@ietf.org, Sasha@AXERRA.com, > > stbryant@cisco.com > > | > > > | Subject: RE: [PWE3] RSVP-TE and PW > > > > | > > > > > >------------------------------------------------------------- > > ------------------------------------------------------------------| > > > > > > > > > > > > > > > Eric, > > > > > > > > >>I don't think so. The switching node just assigns the PW > > >>to an LSP tunnel with appropriate QoS characteristics. > > >>The data plane model is that packets move from one tunnel > > >>to the next by dint of ordinary MPLS switching. Thus the > > >>relevant QoS characteristics are characteristics of the > > >>LSP tunnels. There are no resources or queuing strategies > > >>that are under the control of the PW control plane. > > >> > > >>I think it is appropriate to say that the QoS object is > > >>"opaque" to the PW control protocol, because the PW > > >>control protocol does not need to understand the > > >>queuing or other resource allocation strategies needed to > > >>provide the QoS. Providing the necessary QoS is the > > >>function of the LSP tunnels. > > > > > > > > > I think the definition of whether a QoS object is opaque to the PW > > > signalling protocol or not is dependant on the what > > functions are being > > > performed on the QoS object, and what mechanisms are > > performing those > > > functions. > > > > > > For example, in a network that uses single hop PWs, CAC may > > be performed > > > (for leased line/CBR type services) based on the bandwidth > > required by the > > > attachment circuit as part of the provisioning process to > > ensure that an > > > egress (PE-PE) TE tunnel has enough bandwidth available > > before signalling a > > > PW. > > > > > > In a (hypothetical) network that uses PW switching with TE > > tunnels between > > > switching nodes, to ensure bandwidth is available for any given PW > > > end-to-end across multiple TE tunnels, CAC would need to be > > performed at > > > each switching node as part of the provisioning process. As > > switching nodes > > > are not directly attached to attachment circuits, they > would need to > > > receive the PW bandwidth information through the PW > > signalling protocol. > > > > > > With single hop PWs, CAC is performed prior to PW > > signalling and therefore > > > it can be performed by a separate mechanism (i.e. not the > signalling > > > protocol), but what about the switched PW case? For > > switched PWs CAC would > > > need to be performed at switching nodes during the > > signalling process. So > > > either the signalling protocol would need to perform the > > CAC function, or > > > the signalling protocol would need to send the bandwidth > > information to a > > > separate CAC mechanism and wait for a response before continuing. > > > > > > If the PW signalling protocol performs the CAC function > > then obviously the > > > bandwidth information could not be considered to be opaque, > > if on the other > > > hand the CAC function was performed by a separate > > mechanism, then the > > > bandwidth information could be considered to be opaque. > > Saying that, the > > > two methods perform exactly the same functionality, I think > > its more of an > > > implementation/standards specification issue as to whether > > the CAC function > > > is considered to be part of the signalling mechanism or separate. > > > > > > Regards, > > > Richard > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > . > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Shah, Himanshu" Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 09:45:36 -0400 Lines: 281 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 15:48:13 2004 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'dpapadimitriou@psg.com'" , Matthew.Bocci@alcatel.co.uk X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org It is NOT opaque for intermediate PE nodes. As I had indicated in the earlier email, PWE3 control signal is terminated, processed and re-signaled at each intermediate PE hop, all the way to the destination PE. The word 'opaque' was used in the context of LDP, CR_LDP, and use of RSVP-TE to build transport lsp as well as multi-hop PW. Hope this clears up the confusion. /himanshu > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Thursday, October 14, 2004 9:28 AM > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > Matthew.Bocci@alcatel.co.uk > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > -----Original Message----- > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > Sent: Thursday, October 14, 2004 8:39 AM > > To: 'dpapadimitriou@psg.com'; Matthew.Bocci@alcatel.co.uk > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > stbryant@cisco.com > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > As you suggest and I agree that it is fruitless to engage > > in detailed discussions without a proposal on the table. > > > > Although, a couple of question that you have posted can > > be clarified. As Eric has pointed out many times with > > clarifications, I don't see why "qos model" and "AC model" > > is necessary for the underlying LDP signaling protocol. > > > > The (opaque) QOS TLV that is singalled to/through each PE > hop is used > > to select the suitable underlying transport tunnel (TE-LSP > > or other) between PE hops, to perform the CAC and/or to apply > > appropriate traffic shaping and policing for traffic > between PW switch > > points. > > > How can an object be both opaque AND be used for CAC and > tunnel selection? > > I suggest you read Richard's email again. His analysis is right on. > > > > > > > > > > As for partial or end-to-end rerouting - we need to wait for > > the requirements to be hammered out. > > > > > > /himanshu > > > > > -----Original Message----- > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > Sent: Thursday, October 14, 2004 8:05 AM > > > To: Matthew.Bocci@alcatel.co.uk > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > stbryant@cisco.com > > > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > > > matthew, > > > > > > as of today, i don't see why/how T-LDP QoS extensions can be > > > qualified > > > as "relatively simple" or "marginal extensions" (as i have > > seen this > > > argument used many times on this list) without any real > > > proposal on the > > > table for this purpose (i don't speak about the > > > point-to-point exchange > > > of QoS AC parameters as in draft-shah where only ultimate PEs are > > > involved) ? > > > > > > this said, what is the QoS model and AC model that is > > > associated to LDP > > > signaling on ultimate and intermediate switching PEs ? so, as > > > you are a > > > bit evasive on how you would "transform" a point-to-point non-QoS > > > capable protocol into an end-to-end QoS capable protocol, > would you > > > please clarify ? > > > > > > the next question is how end-to-end and/or partial > > re-routing of such > > > switched PW entities will be achieved in case of switching PE > > > node failure ? > > > > > > much thanks for your clarifications, > > > - dimitri. > > > > > > Matthew.Bocci@alcatel.co.uk wrote: > > > > > > > Richard, > > > > > > > > I agree with what you are saying in general, but I think > > that we can > > > > achieve this with relatively simple extensions to T-LDP. > > > > > > > > We already have a proposal for a way to signal traffic > > parameters in > > > > draft-shah, and I think it would be simple to enable T-LDP > > > to signal the > > > > ultimate target PE (either usings one of the existing FECs, > > > or a new one). > > > > If a PE can maintain a binding of ingress and egress T-LDP > > > sessions, then > > > > we can also effectively crankback PW setup attempts that > > > fail or block at > > > > an intermediate switching node. > > > > > > > > > > > > Best regards, > > > > > > > > Matthew > > > > > > > > > > > > > > > > |---------+---------------------------> > > > > | | richard.spencer@| > > > > | | bt.com | > > > > | | Sent by: | > > > > | | pwe3-bounces@iet| > > > > | | f.org | > > > > | | | > > > > | | | > > > > | | 14/10/2004 01:21| > > > > | | | > > > > |---------+---------------------------> > > > > > > > >------------------------------------------------------------- > > > > ------------------------------------------------------------------| > > > > | > > > > > > | > > > > | To: , > > > > > > | > > > > | cc: pwe3@ietf.org, Sasha@AXERRA.com, > > > stbryant@cisco.com > > > | > > > > | Subject: RE: [PWE3] RSVP-TE and PW > > > > > > | > > > > > > > >------------------------------------------------------------- > > > > ------------------------------------------------------------------| > > > > > > > > > > > > > > > > > > > > Eric, > > > > > > > > > > > >>I don't think so. The switching node just assigns the PW > > > >>to an LSP tunnel with appropriate QoS characteristics. > > > >>The data plane model is that packets move from one tunnel > > > >>to the next by dint of ordinary MPLS switching. Thus the > > > >>relevant QoS characteristics are characteristics of the > > > >>LSP tunnels. There are no resources or queuing strategies > > > >>that are under the control of the PW control plane. > > > >> > > > >>I think it is appropriate to say that the QoS object is > > > >>"opaque" to the PW control protocol, because the PW > > > >>control protocol does not need to understand the > > > >>queuing or other resource allocation strategies needed to > > > >>provide the QoS. Providing the necessary QoS is the > > > >>function of the LSP tunnels. > > > > > > > > > > > > I think the definition of whether a QoS object is > opaque to the PW > > > > signalling protocol or not is dependant on the what > > > functions are being > > > > performed on the QoS object, and what mechanisms are > > > performing those > > > > functions. > > > > > > > > For example, in a network that uses single hop PWs, CAC may > > > be performed > > > > (for leased line/CBR type services) based on the bandwidth > > > required by the > > > > attachment circuit as part of the provisioning process to > > > ensure that an > > > > egress (PE-PE) TE tunnel has enough bandwidth available > > > before signalling a > > > > PW. > > > > > > > > In a (hypothetical) network that uses PW switching with TE > > > tunnels between > > > > switching nodes, to ensure bandwidth is available for > any given PW > > > > end-to-end across multiple TE tunnels, CAC would need to be > > > performed at > > > > each switching node as part of the provisioning process. As > > > switching nodes > > > > are not directly attached to attachment circuits, they > > would need to > > > > receive the PW bandwidth information through the PW > > > signalling protocol. > > > > > > > > With single hop PWs, CAC is performed prior to PW > > > signalling and therefore > > > > it can be performed by a separate mechanism (i.e. not the > > signalling > > > > protocol), but what about the switched PW case? For > > > switched PWs CAC would > > > > need to be performed at switching nodes during the > > > signalling process. So > > > > either the signalling protocol would need to perform the > > > CAC function, or > > > > the signalling protocol would need to send the bandwidth > > > information to a > > > > separate CAC mechanism and wait for a response before > continuing. > > > > > > > > If the PW signalling protocol performs the CAC function > > > then obviously the > > > > bandwidth information could not be considered to be opaque, > > > if on the other > > > > hand the CAC function was performed by a separate > > > mechanism, then the > > > > bandwidth information could be considered to be opaque. > > > Saying that, the > > > > two methods perform exactly the same functionality, I think > > > its more of an > > > > implementation/standards specification issue as to whether > > > the CAC function > > > > is considered to be part of the signalling mechanism or > separate. > > > > > > > > Regards, > > > > Richard > > > > > > > > _______________________________________________ > > > > pwe3 mailing list > > > > pwe3@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > pwe3 mailing list > > > > pwe3@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > . > > > > > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 09:51:27 -0400 Lines: 303 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 15:55:14 2004 Return-path: To: "'Shah, Himanshu'" , "'dpapadimitriou@psg.com'" , Matthew.Bocci@alcatel.co.uk X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Himanchu, I am afraid your last email has left me even more confused than the first. Are you saying that the QoS object is opaque if you use CR-LDP or RSVP-TE to establish a MH-PW, but not if you terminate control signaling at intermediate nodes? What difference do you see between "terminating and resignaling" versus the regular RSVP-TE procedure of processing and forwarding of signaling messages? Peter > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Thursday, October 14, 2004 9:46 AM > To: 'Busschbach, Peter B (Peter)'; 'dpapadimitriou@psg.com'; > Matthew.Bocci@alcatel.co.uk > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > Subject: RE: [PWE3] RSVP-TE and PW > > > It is NOT opaque for intermediate PE nodes. > > As I had indicated in the earlier email, > PWE3 control signal is terminated, processed and > re-signaled at each intermediate PE hop, all > the way to the destination PE. > > The word 'opaque' was used in the context of > LDP, CR_LDP, and use of RSVP-TE to build transport > lsp as well as multi-hop PW. > > Hope this clears up the confusion. > > /himanshu > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: Thursday, October 14, 2004 9:28 AM > > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > > Matthew.Bocci@alcatel.co.uk > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > -----Original Message----- > > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > > Sent: Thursday, October 14, 2004 8:39 AM > > > To: 'dpapadimitriou@psg.com'; Matthew.Bocci@alcatel.co.uk > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > stbryant@cisco.com > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > As you suggest and I agree that it is fruitless to engage > > > in detailed discussions without a proposal on the table. > > > > > > Although, a couple of question that you have posted can > > > be clarified. As Eric has pointed out many times with > > > clarifications, I don't see why "qos model" and "AC model" > > > is necessary for the underlying LDP signaling protocol. > > > > > > The (opaque) QOS TLV that is singalled to/through each PE > > hop is used > > > to select the suitable underlying transport tunnel (TE-LSP > > > or other) between PE hops, to perform the CAC and/or to apply > > > appropriate traffic shaping and policing for traffic > > between PW switch > > > points. > > > > > > How can an object be both opaque AND be used for CAC and > > tunnel selection? > > > > I suggest you read Richard's email again. His analysis is right on. > > > > > > > > > > > > > > > > > > As for partial or end-to-end rerouting - we need to wait for > > > the requirements to be hammered out. > > > > > > > > > /himanshu > > > > > > > -----Original Message----- > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > Sent: Thursday, October 14, 2004 8:05 AM > > > > To: Matthew.Bocci@alcatel.co.uk > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > richard.spencer@bt.com; > > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > > stbryant@cisco.com > > > > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > > > > > > matthew, > > > > > > > > as of today, i don't see why/how T-LDP QoS extensions can be > > > > qualified > > > > as "relatively simple" or "marginal extensions" (as i have > > > seen this > > > > argument used many times on this list) without any real > > > > proposal on the > > > > table for this purpose (i don't speak about the > > > > point-to-point exchange > > > > of QoS AC parameters as in draft-shah where only > ultimate PEs are > > > > involved) ? > > > > > > > > this said, what is the QoS model and AC model that is > > > > associated to LDP > > > > signaling on ultimate and intermediate switching PEs ? so, as > > > > you are a > > > > bit evasive on how you would "transform" a > point-to-point non-QoS > > > > capable protocol into an end-to-end QoS capable protocol, > > would you > > > > please clarify ? > > > > > > > > the next question is how end-to-end and/or partial > > > re-routing of such > > > > switched PW entities will be achieved in case of switching PE > > > > node failure ? > > > > > > > > much thanks for your clarifications, > > > > - dimitri. > > > > > > > > Matthew.Bocci@alcatel.co.uk wrote: > > > > > > > > > Richard, > > > > > > > > > > I agree with what you are saying in general, but I think > > > that we can > > > > > achieve this with relatively simple extensions to T-LDP. > > > > > > > > > > We already have a proposal for a way to signal traffic > > > parameters in > > > > > draft-shah, and I think it would be simple to enable T-LDP > > > > to signal the > > > > > ultimate target PE (either usings one of the existing FECs, > > > > or a new one). > > > > > If a PE can maintain a binding of ingress and egress T-LDP > > > > sessions, then > > > > > we can also effectively crankback PW setup attempts that > > > > fail or block at > > > > > an intermediate switching node. > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > Matthew > > > > > > > > > > > > > > > > > > > > |---------+---------------------------> > > > > > | | richard.spencer@| > > > > > | | bt.com | > > > > > | | Sent by: | > > > > > | | pwe3-bounces@iet| > > > > > | | f.org | > > > > > | | | > > > > > | | | > > > > > | | 14/10/2004 01:21| > > > > > | | | > > > > > |---------+---------------------------> > > > > > > > > > >------------------------------------------------------------- > > > > > > ------------------------------------------------------------------| > > > > > | > > > > > > > > | > > > > > | To: , > > > > > > > > | > > > > > | cc: pwe3@ietf.org, Sasha@AXERRA.com, > > > > stbryant@cisco.com > > > > | > > > > > | Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > | > > > > > > > > > >------------------------------------------------------------- > > > > > > ------------------------------------------------------------------| > > > > > > > > > > > > > > > > > > > > > > > > > Eric, > > > > > > > > > > > > > > >>I don't think so. The switching node just assigns the PW > > > > >>to an LSP tunnel with appropriate QoS characteristics. > > > > >>The data plane model is that packets move from one tunnel > > > > >>to the next by dint of ordinary MPLS switching. Thus the > > > > >>relevant QoS characteristics are characteristics of the > > > > >>LSP tunnels. There are no resources or queuing strategies > > > > >>that are under the control of the PW control plane. > > > > >> > > > > >>I think it is appropriate to say that the QoS object is > > > > >>"opaque" to the PW control protocol, because the PW > > > > >>control protocol does not need to understand the > > > > >>queuing or other resource allocation strategies needed to > > > > >>provide the QoS. Providing the necessary QoS is the > > > > >>function of the LSP tunnels. > > > > > > > > > > > > > > > I think the definition of whether a QoS object is > > opaque to the PW > > > > > signalling protocol or not is dependant on the what > > > > functions are being > > > > > performed on the QoS object, and what mechanisms are > > > > performing those > > > > > functions. > > > > > > > > > > For example, in a network that uses single hop PWs, CAC may > > > > be performed > > > > > (for leased line/CBR type services) based on the bandwidth > > > > required by the > > > > > attachment circuit as part of the provisioning process to > > > > ensure that an > > > > > egress (PE-PE) TE tunnel has enough bandwidth available > > > > before signalling a > > > > > PW. > > > > > > > > > > In a (hypothetical) network that uses PW switching with TE > > > > tunnels between > > > > > switching nodes, to ensure bandwidth is available for > > any given PW > > > > > end-to-end across multiple TE tunnels, CAC would need to be > > > > performed at > > > > > each switching node as part of the provisioning process. As > > > > switching nodes > > > > > are not directly attached to attachment circuits, they > > > would need to > > > > > receive the PW bandwidth information through the PW > > > > signalling protocol. > > > > > > > > > > With single hop PWs, CAC is performed prior to PW > > > > signalling and therefore > > > > > it can be performed by a separate mechanism (i.e. not the > > > signalling > > > > > protocol), but what about the switched PW case? For > > > > switched PWs CAC would > > > > > need to be performed at switching nodes during the > > > > signalling process. So > > > > > either the signalling protocol would need to perform the > > > > CAC function, or > > > > > the signalling protocol would need to send the bandwidth > > > > information to a > > > > > separate CAC mechanism and wait for a response before > > continuing. > > > > > > > > > > If the PW signalling protocol performs the CAC function > > > > then obviously the > > > > > bandwidth information could not be considered to be opaque, > > > > if on the other > > > > > hand the CAC function was performed by a separate > > > > mechanism, then the > > > > > bandwidth information could be considered to be opaque. > > > > Saying that, the > > > > > two methods perform exactly the same functionality, I think > > > > its more of an > > > > > implementation/standards specification issue as to whether > > > > the CAC function > > > > > is considered to be part of the signalling mechanism or > > separate. > > > > > > > > > > Regards, > > > > > Richard > > > > > > > > > > _______________________________________________ > > > > > pwe3 mailing list > > > > > pwe3@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > pwe3 mailing list > > > > > pwe3@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > . > > > > > > > > > > > > > _______________________________________________ > > > > pwe3 mailing list > > > > pwe3@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: PW switching and OAM Date: Thu, 14 Oct 2004 15:07:49 +0100 Lines: 105 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Thu Oct 14 16:15:37 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PW switching and OAM Thread-Index: AcSx5awTJrTQhPvSQZqbuwuSDYzN3gABcQ3w To: , X-OriginalArrivalTime: 14 Oct 2004 14:07:49.0493 (UTC) FILETIME=[3014E250:01C4B1F7] X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Matthew...... Matthew.Bocci@alcatel.co.uk wrote 14 October 2004 12:46 =20 >=20 > The impact of PW switching on OAM does not seem to have been discussed > in much depth yet, but I think that given where we are with the OAM=20 > message mapping draft, it is worth looking at how this applies in the=20 > multi-hop case. > If by PW switching/stitching we are creating a layer network, then I=20 > think the OAM model should not be any different from a layer network=20 > today. That is, we have clear definitions of segment and and to end=20 > OAM on the PW. However, the OAM tools for PWs e.g. VCCV, assume a=20 > single-hop (as noted by Sasha in a previous email) i.e. effectively a=20 > single OAM segment. > What are the implications of extending these to a multi-hop=20 > PW network? NH=3D> I could see this issue coming up right from the outset. And the 1st thing you need to be clear on is the mnode you are dealing with as the defects (and OAM required) are different in each case, viz: - cl-ps: breaks only - co-cs: breaks and swaps between *exactly* alike entities - co-ps: breaks, swaps between any entities, and various mismerging cases The differences arise because of the nature of the traffic unit on link-connections. That is: - in cl-ps mode each/every traffic unit naturally carries a CV function (ie DA) - in the co-cs mode the link-connectioons are physical/real (time or space or freq metric) and the trail BW is quantised/fixed, - and in the co-ps mode the link-connection ID are abstract and the trail BW is variable. For the co-ps and co-cs modes we must therefore add the missing CV function. This is done correctly in SDH (trail-trace field), it's not done completely correctly in ATM (but close, ie CC is missing source address) and its not done right at all in FR. It is done correctly and the most sparsely in Y.1711 (BTW this spec should apply to any co-ps technology). BFD is starting to look a bit like Y.1711 (it has to, the required CV function forces this) but its still not right. Why?.... Because to correctly deal with p2mp constructs and to make sure the required consequent actions are taken at the right place (ie trail sink) the OAM must be unidirectional and it it must be done in the data-plane......this applies to both the co-cs and co-ps modes (it does not however apply to the cl-ps mode). Note also this is a forced behaviour in the co-cs mode as the control/management plane is forced to be OOB wrt the traffic data-plane. SDH is a great of example of doing this right, and ATM gets some of this right.....and interestingly enough folks rely on this fact whether they realise it or not, ie its largely taken for granted IMO. >=20 >=20 > The other question that I have is how to deal with fault alarm=20 > propagation between concatenated single hop PWs. At the moment, we can > use either in-band or out of band fault notification mechanisms, NH=3D> OOB is wrong for CV and FDI functions. FDI must be sent in the data-plane in the syntax of the client(s) affected and from the server trail term point....and this is a recursive requirement over all affected client layer networks (ie the clients of the initially affected clients if you follow me). The BDI function can go OOB as this not a direct fault-handling function, but merely there to allow single-ended monitoring of the defect behaviour of both directions. > depending on the PW type or > encapsulation used. draft-martini-pwe3-pw-switching-00.txt=20 > says that one motivation for stitching PWs is to enable=20 > ultimate PEs with different signaling and encapsulation=20 > protocols to be connected. While I agree that this is a good=20 > motivation in principle, I think it raises some questions=20 > about how to propagate fault notifications across the=20 > stitching node. For example, take the case of an ATM PW being=20 > transported end to end across two PW domains. In one domain,=20 > only static PWs with ATM cell mode encapsulation are=20 > supported. In the other domain, ATM SDU mode is supported=20 > with PW status signalling. Getting fault notifications across=20 > the switching node implies that the node will have to=20 > understand ATM AIS/RDI, and translate this to PW status=20 > signalling. This is an extreme example, but I think it=20 > illustrates that there need to be some pragmatic constraints=20 > on the PW types that we stitch e.g. the same OAM mechanisms=20 > in each domain. NH=3D> All these issues are arising because folks are not understanding the differences between the modal behaviours....you simply can't apply the same approach in all cases. I'll send you something off-list that explains this more completely. regards, Neil >=20 > Best regards, >=20 > Matthew >=20 >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Eric Rosen Subject: Re: RSVP-TE and PW Date: Thu, 14 Oct 2004 10:39:39 -0400 Lines: 31 Sender: pwe3-bounces@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: busschbach@lucent.com, pwe3@ietf.org, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 16:52:23 2004 Return-path: X-BrightmailFiltered: true To: richard.spencer@bt.com In-reply-to: Your message of Thu, 14 Oct 2004 01:21:19 +0100. 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) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > either the signalling protocol would need to perform the CAC function, or > the signalling protocol would need to send the bandwidth information to a > separate CAC mechanism and wait for a response before continuing. > if on the other hand the CAC function was performed by a separate > mechanism, then the bandwidth information could be considered to be > opaque. Saying that, the two methods perform exactly the same > functionality, I think its more of an implementation/standards > specification issue as to whether the CAC function is considered to be > part of the signalling mechanism or separate. I agree with this analysis, but I think there are pretty strong reasons to keep CAC and related functions part of the tunnel setup and maintenance protocol, rather than part of the PW setup and maintenance protocol. - There are many applications whose data packets may travel through a TE tunnel. Pseudowires is just one such application. If CAC is handled at the PW layer, then presumably every application which can send data through a TE tunnel would have to have its own CAC function. Somehow all these independent CAC functions would have to work together to share the tunnel. - Many of the data packets traveling through a TE tunnel will belong to applications that do not have control points at the tunnel endpoints. So the tunnel mechanism itself has to be able to handle the CAC functionality. - If CAC or other QoS functionality is really thought of as part of the PW layer, then it would seem to be a major mistake to bind it tightly to the QoS capabilities of any particular PSN. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: neil.2.harrison@bt.com Subject: RE: PW switching and OAM Date: Thu, 14 Oct 2004 15:44:36 +0100 Lines: 138 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-bounces@ietf.org Thu Oct 14 16:54:38 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PW switching and OAM Thread-Index: AcSx5awTJrTQhPvSQZqbuwuSDYzN3gABcQ3wAAQzxqA= To: , X-OriginalArrivalTime: 14 Oct 2004 14:44:36.0927 (UTC) FILETIME=[53D094F0:01C4B1FC] X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Folks....just noticed a typo....where it says: > - in cl-ps mode each/every traffic unit naturally carries a CV > function (ie DA) ^^ This should obviously be SA. Apologies....regards, Neil > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of neil.2.harrison@bt.com > Sent: 14 October 2004 15:08 > To: Matthew.Bocci@alcatel.co.uk; pwe3@ietf.org > Subject: RE: [PWE3] PW switching and OAM >=20 >=20 > Matthew...... >=20 > Matthew.Bocci@alcatel.co.uk wrote 14 October 2004 12:46 > =20 > >=20 > > The impact of PW switching on OAM does not seem to have=20 > been discussed >=20 > > in much depth yet, but I think that given where we are with the OAM > > message mapping draft, it is worth looking at how this=20 > applies in the=20 > > multi-hop case. >=20 > > If by PW switching/stitching we are creating a layer network, then I > > think the OAM model should not be any different from a=20 > layer network=20 > > today. That is, we have clear definitions of segment and and to end=20 > > OAM on the PW. However, the OAM tools for PWs e.g. VCCV, assume a=20 > > single-hop (as noted by Sasha in a previous email) i.e.=20 > effectively a=20 > > single OAM segment. > > What are the implications of extending these to a multi-hop=20 > > PW network? > NH=3D> I could see this issue coming up right from the outset. =20 > And the 1st thing you need to be clear on is the mnode you=20 > are dealing with as the defects (and OAM required) are=20 > different in each case, viz: > - cl-ps: breaks only > - co-cs: breaks and swaps between *exactly* alike entities > - co-ps: breaks, swaps between any entities, and various > mismerging cases >=20 > The differences arise because of the nature of the traffic=20 > unit on link-connections. That is: > - in cl-ps mode each/every traffic unit naturally carries a CV > function (ie DA) > - in the co-cs mode the link-connectioons are physical/real (time > or space or freq metric) and the trail BW is quantised/fixed, > - and in the co-ps mode the link-connection ID are abstract and > the trail BW is variable. >=20 > For the co-ps and co-cs modes we must therefore add the=20 > missing CV function. This is done correctly in SDH=20 > (trail-trace field), it's not done completely correctly in=20 > ATM (but close, ie CC is missing source > address) and its not done right at all in FR. It is done=20 > correctly and the most sparsely in Y.1711 (BTW this spec=20 > should apply to any co-ps technology). BFD is starting to=20 > look a bit like Y.1711 (it has to, the required CV function=20 > forces this) but its still not right. Why?.... >=20 > Because to correctly deal with p2mp constructs and to make=20 > sure the required consequent actions are taken at the right=20 > place (ie trail sink) the OAM must be unidirectional and it=20 > it must be done in the data-plane......this applies to both=20 > the co-cs and co-ps modes (it does not however apply to the=20 > cl-ps mode). Note also this is a forced behaviour in the=20 > co-cs mode as the control/management plane is forced to be=20 > OOB wrt the traffic data-plane. SDH is a great of example of=20 > doing this right, and ATM gets some of this right.....and=20 > interestingly enough folks rely on this fact whether they=20 > realise it or not, ie its largely taken for granted IMO. > >=20 > >=20 > > The other question that I have is how to deal with fault alarm > > propagation between concatenated single hop PWs. At the=20 > moment, we can >=20 > > use either in-band or out of band fault notification mechanisms, > NH=3D> OOB is wrong for CV and FDI functions. FDI must be sent=20 > in the data-plane in the syntax of the client(s) affected and=20 > from the server trail term point....and this is a recursive=20 > requirement over all affected client layer networks (ie the=20 > clients of the initially affected clients if you follow me). =20 > The BDI function can go OOB as this not a direct=20 > fault-handling function, but merely there to allow=20 > single-ended monitoring of the defect behaviour of both directions. >=20 > > depending on the PW type or > > encapsulation used. draft-martini-pwe3-pw-switching-00.txt > > says that one motivation for stitching PWs is to enable=20 > > ultimate PEs with different signaling and encapsulation=20 > > protocols to be connected. While I agree that this is a good=20 > > motivation in principle, I think it raises some questions=20 > > about how to propagate fault notifications across the=20 > > stitching node. For example, take the case of an ATM PW being=20 > > transported end to end across two PW domains. In one domain,=20 > > only static PWs with ATM cell mode encapsulation are=20 > > supported. In the other domain, ATM SDU mode is supported=20 > > with PW status signalling. Getting fault notifications across=20 > > the switching node implies that the node will have to=20 > > understand ATM AIS/RDI, and translate this to PW status=20 > > signalling. This is an extreme example, but I think it=20 > > illustrates that there need to be some pragmatic constraints=20 > > on the PW types that we stitch e.g. the same OAM mechanisms=20 > > in each domain. > NH=3D> All these issues are arising because folks are not=20 > understanding the differences between the modal=20 > behaviours....you simply can't apply the same approach in all=20 > cases. I'll send you something off-list that explains this=20 > more completely. >=20 > regards, Neil > >=20 > > Best regards, > >=20 > > Matthew > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Shah, Himanshu" Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 10:45:15 -0400 Lines: 356 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 16:55:25 2004 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'dpapadimitriou@psg.com'" , Matthew.Bocci@alcatel.co.uk X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org If the word opaque is confusing you - then drop it. It is not relevent in this discussion or what I was suggesting on how one can use PWE3-control (ie targeted LDP) also to signal MH PW along with QOS information. The main difference between terminating+resignaling and processing+forwarding, the way I see it is this. Lets take a simple example of only one switching hop. When switching PE1 receives PWE3-control msg from source PE, he can respond back with his PW label (but PW status down). He then would signal to target PE using the information received from source PE plus PE1's own label. When the response comes back from target PE (and since he is target he would send PW status up), PE1 would, 1) program the FIB for PW label switching 2) send PW status to source PE if both tunnels are up and target PE indicated that PW status is up May be the difference is subtle. Lets not hung up on that. The objectives are, 1) static configuration of intermediate PEs is not required 2) QOS information is taken into consideration 3) And most importantly we are still using established PWE3- control signaling. if you need to discuss more, we can do that offline. /himanshu (not himanchu...:) > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Thursday, October 14, 2004 9:51 AM > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > Matthew.Bocci@alcatel.co.uk > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > Subject: RE: [PWE3] RSVP-TE and PW > > > Himanchu, > > I am afraid your last email has left me even more confused > than the first. > > Are you saying that the QoS object is opaque if you use > CR-LDP or RSVP-TE to establish a MH-PW, but not if you > terminate control signaling at intermediate nodes? What > difference do you see between "terminating and resignaling" > versus the regular RSVP-TE procedure of processing and > forwarding of signaling messages? > > Peter > > > -----Original Message----- > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > Sent: Thursday, October 14, 2004 9:46 AM > > To: 'Busschbach, Peter B (Peter)'; 'dpapadimitriou@psg.com'; > > Matthew.Bocci@alcatel.co.uk > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > It is NOT opaque for intermediate PE nodes. > > > > As I had indicated in the earlier email, > > PWE3 control signal is terminated, processed and > > re-signaled at each intermediate PE hop, all > > the way to the destination PE. > > > > The word 'opaque' was used in the context of > > LDP, CR_LDP, and use of RSVP-TE to build transport > > lsp as well as multi-hop PW. > > > > Hope this clears up the confusion. > > > > /himanshu > > > > > -----Original Message----- > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > Sent: Thursday, October 14, 2004 9:28 AM > > > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > > > Matthew.Bocci@alcatel.co.uk > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > > > Sent: Thursday, October 14, 2004 8:39 AM > > > > To: 'dpapadimitriou@psg.com'; Matthew.Bocci@alcatel.co.uk > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > richard.spencer@bt.com; > > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > > stbryant@cisco.com > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > As you suggest and I agree that it is fruitless to engage > > > > in detailed discussions without a proposal on the table. > > > > > > > > Although, a couple of question that you have posted can > > > > be clarified. As Eric has pointed out many times with > > > > clarifications, I don't see why "qos model" and "AC model" > > > > is necessary for the underlying LDP signaling protocol. > > > > > > > > The (opaque) QOS TLV that is singalled to/through each PE > > > hop is used > > > > to select the suitable underlying transport tunnel (TE-LSP > > > > or other) between PE hops, to perform the CAC and/or to apply > > > > appropriate traffic shaping and policing for traffic > > > between PW switch > > > > points. > > > > > > > > > How can an object be both opaque AND be used for CAC and > > > tunnel selection? > > > > > > I suggest you read Richard's email again. His analysis is > right on. > > > > > > > > > > > > > > > > > > > > > > > > > > As for partial or end-to-end rerouting - we need to wait for > > > > the requirements to be hammered out. > > > > > > > > > > > > /himanshu > > > > > > > > > -----Original Message----- > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > Sent: Thursday, October 14, 2004 8:05 AM > > > > > To: Matthew.Bocci@alcatel.co.uk > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > richard.spencer@bt.com; > > > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > > > stbryant@cisco.com > > > > > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > matthew, > > > > > > > > > > as of today, i don't see why/how T-LDP QoS extensions can be > > > > > qualified > > > > > as "relatively simple" or "marginal extensions" (as i have > > > > seen this > > > > > argument used many times on this list) without any real > > > > > proposal on the > > > > > table for this purpose (i don't speak about the > > > > > point-to-point exchange > > > > > of QoS AC parameters as in draft-shah where only > > ultimate PEs are > > > > > involved) ? > > > > > > > > > > this said, what is the QoS model and AC model that is > > > > > associated to LDP > > > > > signaling on ultimate and intermediate switching PEs ? so, as > > > > > you are a > > > > > bit evasive on how you would "transform" a > > point-to-point non-QoS > > > > > capable protocol into an end-to-end QoS capable protocol, > > > would you > > > > > please clarify ? > > > > > > > > > > the next question is how end-to-end and/or partial > > > > re-routing of such > > > > > switched PW entities will be achieved in case of switching PE > > > > > node failure ? > > > > > > > > > > much thanks for your clarifications, > > > > > - dimitri. > > > > > > > > > > Matthew.Bocci@alcatel.co.uk wrote: > > > > > > > > > > > Richard, > > > > > > > > > > > > I agree with what you are saying in general, but I think > > > > that we can > > > > > > achieve this with relatively simple extensions to T-LDP. > > > > > > > > > > > > We already have a proposal for a way to signal traffic > > > > parameters in > > > > > > draft-shah, and I think it would be simple to enable T-LDP > > > > > to signal the > > > > > > ultimate target PE (either usings one of the existing FECs, > > > > > or a new one). > > > > > > If a PE can maintain a binding of ingress and egress T-LDP > > > > > sessions, then > > > > > > we can also effectively crankback PW setup attempts that > > > > > fail or block at > > > > > > an intermediate switching node. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Matthew > > > > > > > > > > > > > > > > > > > > > > > > |---------+---------------------------> > > > > > > | | richard.spencer@| > > > > > > | | bt.com | > > > > > > | | Sent by: | > > > > > > | | pwe3-bounces@iet| > > > > > > | | f.org | > > > > > > | | | > > > > > > | | | > > > > > > | | 14/10/2004 01:21| > > > > > > | | | > > > > > > |---------+---------------------------> > > > > > > > > > > > >------------------------------------------------------------- > > > > > > > > > ------------------------------------------------------------------| > > > > > > | > > > > > > > > > > | > > > > > > | To: , > > > > > > > > > > | > > > > > > | cc: pwe3@ietf.org, Sasha@AXERRA.com, > > > > > stbryant@cisco.com > > > > > | > > > > > > | Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > | > > > > > > > > > > > >------------------------------------------------------------- > > > > > > > > > ------------------------------------------------------------------| > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Eric, > > > > > > > > > > > > > > > > > >>I don't think so. The switching node just assigns the PW > > > > > >>to an LSP tunnel with appropriate QoS characteristics. > > > > > >>The data plane model is that packets move from one tunnel > > > > > >>to the next by dint of ordinary MPLS switching. Thus the > > > > > >>relevant QoS characteristics are characteristics of the > > > > > >>LSP tunnels. There are no resources or queuing strategies > > > > > >>that are under the control of the PW control plane. > > > > > >> > > > > > >>I think it is appropriate to say that the QoS object is > > > > > >>"opaque" to the PW control protocol, because the PW > > > > > >>control protocol does not need to understand the > > > > > >>queuing or other resource allocation strategies needed to > > > > > >>provide the QoS. Providing the necessary QoS is the > > > > > >>function of the LSP tunnels. > > > > > > > > > > > > > > > > > > I think the definition of whether a QoS object is > > > opaque to the PW > > > > > > signalling protocol or not is dependant on the what > > > > > functions are being > > > > > > performed on the QoS object, and what mechanisms are > > > > > performing those > > > > > > functions. > > > > > > > > > > > > For example, in a network that uses single hop PWs, CAC may > > > > > be performed > > > > > > (for leased line/CBR type services) based on the bandwidth > > > > > required by the > > > > > > attachment circuit as part of the provisioning process to > > > > > ensure that an > > > > > > egress (PE-PE) TE tunnel has enough bandwidth available > > > > > before signalling a > > > > > > PW. > > > > > > > > > > > > In a (hypothetical) network that uses PW switching with TE > > > > > tunnels between > > > > > > switching nodes, to ensure bandwidth is available for > > > any given PW > > > > > > end-to-end across multiple TE tunnels, CAC would need to be > > > > > performed at > > > > > > each switching node as part of the provisioning process. As > > > > > switching nodes > > > > > > are not directly attached to attachment circuits, they > > > > would need to > > > > > > receive the PW bandwidth information through the PW > > > > > signalling protocol. > > > > > > > > > > > > With single hop PWs, CAC is performed prior to PW > > > > > signalling and therefore > > > > > > it can be performed by a separate mechanism (i.e. not the > > > > signalling > > > > > > protocol), but what about the switched PW case? For > > > > > switched PWs CAC would > > > > > > need to be performed at switching nodes during the > > > > > signalling process. So > > > > > > either the signalling protocol would need to perform the > > > > > CAC function, or > > > > > > the signalling protocol would need to send the bandwidth > > > > > information to a > > > > > > separate CAC mechanism and wait for a response before > > > continuing. > > > > > > > > > > > > If the PW signalling protocol performs the CAC function > > > > > then obviously the > > > > > > bandwidth information could not be considered to be opaque, > > > > > if on the other > > > > > > hand the CAC function was performed by a separate > > > > > mechanism, then the > > > > > > bandwidth information could be considered to be opaque. > > > > > Saying that, the > > > > > > two methods perform exactly the same functionality, I think > > > > > its more of an > > > > > > implementation/standards specification issue as to whether > > > > > the CAC function > > > > > > is considered to be part of the signalling mechanism or > > > separate. > > > > > > > > > > > > Regards, > > > > > > Richard > > > > > > > > > > > > _______________________________________________ > > > > > > pwe3 mailing list > > > > > > pwe3@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > pwe3 mailing list > > > > > > pwe3@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > . > > > > > > > > > > > > > > > > _______________________________________________ > > > > > pwe3 mailing list > > > > > pwe3@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 11:47:02 -0400 Lines: 403 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 18:03:07 2004 Return-path: To: "'Shah, Himanshu'" , "'dpapadimitriou@psg.com'" , Matthew.Bocci@alcatel.co.uk X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Himanshu, Sorry for repeatedly mispelling your first name. (It must be the abundance of 'ch's in my own name that lead my fingers to the wrong keys.) Thanks for your offer to continue this discussion off-line. However, I think it is important to discuss this on the list. The point is: the mechanism that you propose is wrong. An intermediate PE should not respond to the initiator of the PW before forwarding a setup message to the destination PE. The reason is that there are interface parameters that need to be exchanged between the two end points and must be passed unchanged across PW switching points. See section 6 of draft-martini-pwe3-pw-switching-00.txt for a correct description of the procedure. This may be a minor oversight, but to me it is an example of the lack of rigor that appears frequently in the MH-PW discussions on this mailing list. When people talk about a MH-PW as a collection of wires that are patched together, they seem to underestimate what it takes to create a robust set of standards. Peter > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Thursday, October 14, 2004 10:45 AM > To: 'Busschbach, Peter B (Peter)'; 'dpapadimitriou@psg.com'; > Matthew.Bocci@alcatel.co.uk > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > Subject: RE: [PWE3] RSVP-TE and PW > > > If the word opaque is confusing you - then drop it. > It is not relevent in this discussion or what I > was suggesting on how one can use PWE3-control (ie targeted LDP) > also to signal MH PW along with QOS information. > > The main difference between terminating+resignaling and > processing+forwarding, the way I see it is this. > > Lets take a simple example of only one switching hop. > When switching PE1 receives PWE3-control msg from > source PE, he can respond back with his PW label (but > PW status down). He then would signal to target PE > using the information received from source PE plus > PE1's own label. When the response comes back from > target PE (and since he is target he would send PW status up), > PE1 would, > 1) program the FIB for PW label switching > 2) send PW status to source PE if both tunnels are up and > target PE indicated that PW status is up > > > May be the difference is subtle. Lets not hung up on that. > The objectives are, > 1) static configuration of intermediate PEs is not required > 2) QOS information is taken into consideration > 3) And most importantly we are still using established PWE3- > control signaling. > > if you need to discuss more, we can do that offline. > > /himanshu (not himanchu...:) > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: Thursday, October 14, 2004 9:51 AM > > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > > Matthew.Bocci@alcatel.co.uk > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > Himanchu, > > > > I am afraid your last email has left me even more confused > > than the first. > > > > Are you saying that the QoS object is opaque if you use > > CR-LDP or RSVP-TE to establish a MH-PW, but not if you > > terminate control signaling at intermediate nodes? What > > difference do you see between "terminating and resignaling" > > versus the regular RSVP-TE procedure of processing and > > forwarding of signaling messages? > > > > Peter > > > > > -----Original Message----- > > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > > Sent: Thursday, October 14, 2004 9:46 AM > > > To: 'Busschbach, Peter B (Peter)'; 'dpapadimitriou@psg.com'; > > > Matthew.Bocci@alcatel.co.uk > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > It is NOT opaque for intermediate PE nodes. > > > > > > As I had indicated in the earlier email, > > > PWE3 control signal is terminated, processed and > > > re-signaled at each intermediate PE hop, all > > > the way to the destination PE. > > > > > > The word 'opaque' was used in the context of > > > LDP, CR_LDP, and use of RSVP-TE to build transport > > > lsp as well as multi-hop PW. > > > > > > Hope this clears up the confusion. > > > > > > /himanshu > > > > > > > -----Original Message----- > > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > > Sent: Thursday, October 14, 2004 9:28 AM > > > > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > > > > Matthew.Bocci@alcatel.co.uk > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > richard.spencer@bt.com; > > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > > > > Sent: Thursday, October 14, 2004 8:39 AM > > > > > To: 'dpapadimitriou@psg.com'; Matthew.Bocci@alcatel.co.uk > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > richard.spencer@bt.com; > > > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > > > stbryant@cisco.com > > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > As you suggest and I agree that it is fruitless to engage > > > > > in detailed discussions without a proposal on the table. > > > > > > > > > > Although, a couple of question that you have posted can > > > > > be clarified. As Eric has pointed out many times with > > > > > clarifications, I don't see why "qos model" and "AC model" > > > > > is necessary for the underlying LDP signaling protocol. > > > > > > > > > > The (opaque) QOS TLV that is singalled to/through each PE > > > > hop is used > > > > > to select the suitable underlying transport tunnel (TE-LSP > > > > > or other) between PE hops, to perform the CAC and/or to apply > > > > > appropriate traffic shaping and policing for traffic > > > > between PW switch > > > > > points. > > > > > > > > > > > > How can an object be both opaque AND be used for CAC and > > > > tunnel selection? > > > > > > > > I suggest you read Richard's email again. His analysis is > > right on. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for partial or end-to-end rerouting - we need to wait for > > > > > the requirements to be hammered out. > > > > > > > > > > > > > > > /himanshu > > > > > > > > > > > -----Original Message----- > > > > > > From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] > > > > > > Sent: Thursday, October 14, 2004 8:05 AM > > > > > > To: Matthew.Bocci@alcatel.co.uk > > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > > richard.spencer@bt.com; > > > > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > > > > stbryant@cisco.com > > > > > > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > matthew, > > > > > > > > > > > > as of today, i don't see why/how T-LDP QoS > extensions can be > > > > > > qualified > > > > > > as "relatively simple" or "marginal extensions" (as i have > > > > > seen this > > > > > > argument used many times on this list) without any real > > > > > > proposal on the > > > > > > table for this purpose (i don't speak about the > > > > > > point-to-point exchange > > > > > > of QoS AC parameters as in draft-shah where only > > > ultimate PEs are > > > > > > involved) ? > > > > > > > > > > > > this said, what is the QoS model and AC model that is > > > > > > associated to LDP > > > > > > signaling on ultimate and intermediate switching > PEs ? so, as > > > > > > you are a > > > > > > bit evasive on how you would "transform" a > > > point-to-point non-QoS > > > > > > capable protocol into an end-to-end QoS capable protocol, > > > > would you > > > > > > please clarify ? > > > > > > > > > > > > the next question is how end-to-end and/or partial > > > > > re-routing of such > > > > > > switched PW entities will be achieved in case of > switching PE > > > > > > node failure ? > > > > > > > > > > > > much thanks for your clarifications, > > > > > > - dimitri. > > > > > > > > > > > > Matthew.Bocci@alcatel.co.uk wrote: > > > > > > > > > > > > > Richard, > > > > > > > > > > > > > > I agree with what you are saying in general, but I think > > > > > that we can > > > > > > > achieve this with relatively simple extensions to T-LDP. > > > > > > > > > > > > > > We already have a proposal for a way to signal traffic > > > > > parameters in > > > > > > > draft-shah, and I think it would be simple to > enable T-LDP > > > > > > to signal the > > > > > > > ultimate target PE (either usings one of the > existing FECs, > > > > > > or a new one). > > > > > > > If a PE can maintain a binding of ingress and > egress T-LDP > > > > > > sessions, then > > > > > > > we can also effectively crankback PW setup attempts that > > > > > > fail or block at > > > > > > > an intermediate switching node. > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Matthew > > > > > > > > > > > > > > > > > > > > > > > > > > > > |---------+---------------------------> > > > > > > > | | richard.spencer@| > > > > > > > | | bt.com | > > > > > > > | | Sent by: | > > > > > > > | | pwe3-bounces@iet| > > > > > > > | | f.org | > > > > > > > | | | > > > > > > > | | | > > > > > > > | | 14/10/2004 01:21| > > > > > > > | | | > > > > > > > |---------+---------------------------> > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > > > > > > > > > ------------------------------------------------------------------| > > > > > > > | > > > > > > > > > > > > > > | > > > > > > > | To: , > > > > > > > > > > > > > | > > > > > > > | cc: pwe3@ietf.org, Sasha@AXERRA.com, > > > > > > stbryant@cisco.com > > > > > > > | > > > > > > > | Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > | > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > > > > > > > > > ------------------------------------------------------------------| > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Eric, > > > > > > > > > > > > > > > > > > > > >>I don't think so. The switching node just assigns the PW > > > > > > >>to an LSP tunnel with appropriate QoS characteristics. > > > > > > >>The data plane model is that packets move from one tunnel > > > > > > >>to the next by dint of ordinary MPLS switching. Thus the > > > > > > >>relevant QoS characteristics are characteristics of the > > > > > > >>LSP tunnels. There are no resources or queuing strategies > > > > > > >>that are under the control of the PW control plane. > > > > > > >> > > > > > > >>I think it is appropriate to say that the QoS object is > > > > > > >>"opaque" to the PW control protocol, because the PW > > > > > > >>control protocol does not need to understand the > > > > > > >>queuing or other resource allocation strategies > needed to > > > > > > >>provide the QoS. Providing the necessary QoS is the > > > > > > >>function of the LSP tunnels. > > > > > > > > > > > > > > > > > > > > > I think the definition of whether a QoS object is > > > > opaque to the PW > > > > > > > signalling protocol or not is dependant on the what > > > > > > functions are being > > > > > > > performed on the QoS object, and what mechanisms are > > > > > > performing those > > > > > > > functions. > > > > > > > > > > > > > > For example, in a network that uses single hop > PWs, CAC may > > > > > > be performed > > > > > > > (for leased line/CBR type services) based on the > bandwidth > > > > > > required by the > > > > > > > attachment circuit as part of the provisioning process to > > > > > > ensure that an > > > > > > > egress (PE-PE) TE tunnel has enough bandwidth available > > > > > > before signalling a > > > > > > > PW. > > > > > > > > > > > > > > In a (hypothetical) network that uses PW > switching with TE > > > > > > tunnels between > > > > > > > switching nodes, to ensure bandwidth is available for > > > > any given PW > > > > > > > end-to-end across multiple TE tunnels, CAC would > need to be > > > > > > performed at > > > > > > > each switching node as part of the provisioning > process. As > > > > > > switching nodes > > > > > > > are not directly attached to attachment circuits, they > > > > > would need to > > > > > > > receive the PW bandwidth information through the PW > > > > > > signalling protocol. > > > > > > > > > > > > > > With single hop PWs, CAC is performed prior to PW > > > > > > signalling and therefore > > > > > > > it can be performed by a separate mechanism (i.e. not the > > > > > signalling > > > > > > > protocol), but what about the switched PW case? For > > > > > > switched PWs CAC would > > > > > > > need to be performed at switching nodes during the > > > > > > signalling process. So > > > > > > > either the signalling protocol would need to perform the > > > > > > CAC function, or > > > > > > > the signalling protocol would need to send the bandwidth > > > > > > information to a > > > > > > > separate CAC mechanism and wait for a response before > > > > continuing. > > > > > > > > > > > > > > If the PW signalling protocol performs the CAC function > > > > > > then obviously the > > > > > > > bandwidth information could not be considered to > be opaque, > > > > > > if on the other > > > > > > > hand the CAC function was performed by a separate > > > > > > mechanism, then the > > > > > > > bandwidth information could be considered to be opaque. > > > > > > Saying that, the > > > > > > > two methods perform exactly the same > functionality, I think > > > > > > its more of an > > > > > > > implementation/standards specification issue as > to whether > > > > > > the CAC function > > > > > > > is considered to be part of the signalling mechanism or > > > > separate. > > > > > > > > > > > > > > Regards, > > > > > > > Richard > > > > > > > > > > > > > > _______________________________________________ > > > > > > > pwe3 mailing list > > > > > > > pwe3@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > pwe3 mailing list > > > > > > > pwe3@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > pwe3 mailing list > > > > > > pwe3@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Shah, Himanshu" Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 12:13:25 -0400 Lines: 467 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 18:32:43 2004 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'dpapadimitriou@psg.com'" , Matthew.Bocci@alcatel.co.uk X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org It is fruitless to continue discussing further until there is a proposal that you can shoot holes in it. So you will have to wait. Since you have not fully understood the proposal (partly because there is no written proposal), it would be a mistake to call it a 'wrong mechanism'. It is possible that you have put more thought into this and you see your proposal to be the only right way to solve this problem. However, it would be a mistake to declare that rest of the WG lack 'rigor' to create a robust set of standards. Now, it is possible that when everything is said and done, hierarchical RSVP signaling is a better way to go. That is fine. However, what is not OK is to refuse to look at other alternatives. /himanshu > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Thursday, October 14, 2004 11:47 AM > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > Matthew.Bocci@alcatel.co.uk > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > Subject: RE: [PWE3] RSVP-TE and PW > > > Hi Himanshu, > > Sorry for repeatedly mispelling your first name. (It must be > the abundance of 'ch's in my own name that lead my fingers to > the wrong keys.) > > Thanks for your offer to continue this discussion off-line. > However, I think it is important to discuss this on the list. > > The point is: the mechanism that you propose is wrong. An > intermediate PE should not respond to the initiator of the PW > before forwarding a setup message to the destination PE. The > reason is that there are interface parameters that need to be > exchanged between the two end points and must be passed > unchanged across PW switching points. See section 6 of > draft-martini-pwe3-pw-switching-00.txt for a correct > description of the procedure. > > This may be a minor oversight, but to me it is an example of > the lack of rigor that appears frequently in the MH-PW > discussions on this mailing list. When people talk about a > MH-PW as a collection of wires that are patched together, > they seem to underestimate what it takes to create a robust > set of standards. > > Peter > > > -----Original Message----- > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > Sent: Thursday, October 14, 2004 10:45 AM > > To: 'Busschbach, Peter B (Peter)'; 'dpapadimitriou@psg.com'; > > Matthew.Bocci@alcatel.co.uk > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > If the word opaque is confusing you - then drop it. > > It is not relevent in this discussion or what I > > was suggesting on how one can use PWE3-control (ie targeted LDP) > > also to signal MH PW along with QOS information. > > > > The main difference between terminating+resignaling and > > processing+forwarding, the way I see it is this. > > > > Lets take a simple example of only one switching hop. > > When switching PE1 receives PWE3-control msg from > > source PE, he can respond back with his PW label (but > > PW status down). He then would signal to target PE > > using the information received from source PE plus > > PE1's own label. When the response comes back from > > target PE (and since he is target he would send PW status up), > > PE1 would, > > 1) program the FIB for PW label switching > > 2) send PW status to source PE if both tunnels are up and > > target PE indicated that PW status is up > > > > > > May be the difference is subtle. Lets not hung up on that. > > The objectives are, > > 1) static configuration of intermediate PEs is not required > > 2) QOS information is taken into consideration > > 3) And most importantly we are still using established PWE3- > > control signaling. > > > > if you need to discuss more, we can do that offline. > > > > /himanshu (not himanchu...:) > > > > > -----Original Message----- > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > Sent: Thursday, October 14, 2004 9:51 AM > > > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > > > Matthew.Bocci@alcatel.co.uk > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > Himanchu, > > > > > > I am afraid your last email has left me even more confused > > > than the first. > > > > > > Are you saying that the QoS object is opaque if you use > > > CR-LDP or RSVP-TE to establish a MH-PW, but not if you > > > terminate control signaling at intermediate nodes? What > > > difference do you see between "terminating and resignaling" > > > versus the regular RSVP-TE procedure of processing and > > > forwarding of signaling messages? > > > > > > Peter > > > > > > > -----Original Message----- > > > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > > > Sent: Thursday, October 14, 2004 9:46 AM > > > > To: 'Busschbach, Peter B (Peter)'; 'dpapadimitriou@psg.com'; > > > > Matthew.Bocci@alcatel.co.uk > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > richard.spencer@bt.com; > > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > It is NOT opaque for intermediate PE nodes. > > > > > > > > As I had indicated in the earlier email, > > > > PWE3 control signal is terminated, processed and > > > > re-signaled at each intermediate PE hop, all > > > > the way to the destination PE. > > > > > > > > The word 'opaque' was used in the context of > > > > LDP, CR_LDP, and use of RSVP-TE to build transport > > > > lsp as well as multi-hop PW. > > > > > > > > Hope this clears up the confusion. > > > > > > > > /himanshu > > > > > > > > > -----Original Message----- > > > > > From: Busschbach, Peter B (Peter) > [mailto:busschbach@lucent.com] > > > > > Sent: Thursday, October 14, 2004 9:28 AM > > > > > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > > > > > Matthew.Bocci@alcatel.co.uk > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > richard.spencer@bt.com; > > > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > > > > > Sent: Thursday, October 14, 2004 8:39 AM > > > > > > To: 'dpapadimitriou@psg.com'; Matthew.Bocci@alcatel.co.uk > > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > > richard.spencer@bt.com; > > > > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > > > > stbryant@cisco.com > > > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > As you suggest and I agree that it is fruitless to engage > > > > > > in detailed discussions without a proposal on the table. > > > > > > > > > > > > Although, a couple of question that you have posted can > > > > > > be clarified. As Eric has pointed out many times with > > > > > > clarifications, I don't see why "qos model" and "AC model" > > > > > > is necessary for the underlying LDP signaling protocol. > > > > > > > > > > > > The (opaque) QOS TLV that is singalled to/through each PE > > > > > hop is used > > > > > > to select the suitable underlying transport tunnel (TE-LSP > > > > > > or other) between PE hops, to perform the CAC > and/or to apply > > > > > > appropriate traffic shaping and policing for traffic > > > > > between PW switch > > > > > > points. > > > > > > > > > > > > > > > How can an object be both opaque AND be used for CAC and > > > > > tunnel selection? > > > > > > > > > > I suggest you read Richard's email again. His analysis is > > > right on. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for partial or end-to-end rerouting - we need to > wait for > > > > > > the requirements to be hammered out. > > > > > > > > > > > > > > > > > > /himanshu > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: dimitri papadimitriou > [mailto:dpapadimitriou@psg.com] > > > > > > > Sent: Thursday, October 14, 2004 8:05 AM > > > > > > > To: Matthew.Bocci@alcatel.co.uk > > > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > > > richard.spencer@bt.com; > > > > > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > > > > > stbryant@cisco.com > > > > > > > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > > > > matthew, > > > > > > > > > > > > > > as of today, i don't see why/how T-LDP QoS > > extensions can be > > > > > > > qualified > > > > > > > as "relatively simple" or "marginal extensions" > (as i have > > > > > > seen this > > > > > > > argument used many times on this list) without any real > > > > > > > proposal on the > > > > > > > table for this purpose (i don't speak about the > > > > > > > point-to-point exchange > > > > > > > of QoS AC parameters as in draft-shah where only > > > > ultimate PEs are > > > > > > > involved) ? > > > > > > > > > > > > > > this said, what is the QoS model and AC model that is > > > > > > > associated to LDP > > > > > > > signaling on ultimate and intermediate switching > > PEs ? so, as > > > > > > > you are a > > > > > > > bit evasive on how you would "transform" a > > > > point-to-point non-QoS > > > > > > > capable protocol into an end-to-end QoS capable protocol, > > > > > would you > > > > > > > please clarify ? > > > > > > > > > > > > > > the next question is how end-to-end and/or partial > > > > > > re-routing of such > > > > > > > switched PW entities will be achieved in case of > > switching PE > > > > > > > node failure ? > > > > > > > > > > > > > > much thanks for your clarifications, > > > > > > > - dimitri. > > > > > > > > > > > > > > Matthew.Bocci@alcatel.co.uk wrote: > > > > > > > > > > > > > > > Richard, > > > > > > > > > > > > > > > > I agree with what you are saying in general, > but I think > > > > > > that we can > > > > > > > > achieve this with relatively simple extensions to T-LDP. > > > > > > > > > > > > > > > > We already have a proposal for a way to signal traffic > > > > > > parameters in > > > > > > > > draft-shah, and I think it would be simple to > > enable T-LDP > > > > > > > to signal the > > > > > > > > ultimate target PE (either usings one of the > > existing FECs, > > > > > > > or a new one). > > > > > > > > If a PE can maintain a binding of ingress and > > egress T-LDP > > > > > > > sessions, then > > > > > > > > we can also effectively crankback PW setup > attempts that > > > > > > > fail or block at > > > > > > > > an intermediate switching node. > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > Matthew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |---------+---------------------------> > > > > > > > > | | richard.spencer@| > > > > > > > > | | bt.com | > > > > > > > > | | Sent by: | > > > > > > > > | | pwe3-bounces@iet| > > > > > > > > | | f.org | > > > > > > > > | | | > > > > > > > > | | | > > > > > > > > | | 14/10/2004 01:21| > > > > > > > > | | | > > > > > > > > |---------+---------------------------> > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > > > > > > > > > > > > > ------------------------------------------------------------------| > > > > > > > > | > > > > > > > > > > > > > > > > > > | > > > > > > > > | To: , > > > > > > > > > > > > > > > > | > > > > > > > > | cc: pwe3@ietf.org, Sasha@AXERRA.com, > > > > > > > stbryant@cisco.com > > > > > > > > > | > > > > > > > > | Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > > > > > > > > > > > > > ------------------------------------------------------------------| > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Eric, > > > > > > > > > > > > > > > > > > > > > > > >>I don't think so. The switching node just > assigns the PW > > > > > > > >>to an LSP tunnel with appropriate QoS characteristics. > > > > > > > >>The data plane model is that packets move from > one tunnel > > > > > > > >>to the next by dint of ordinary MPLS switching. Thus the > > > > > > > >>relevant QoS characteristics are > characteristics of the > > > > > > > >>LSP tunnels. There are no resources or queuing > strategies > > > > > > > >>that are under the control of the PW control plane. > > > > > > > >> > > > > > > > >>I think it is appropriate to say that the QoS > object is > > > > > > > >>"opaque" to the PW control protocol, because the PW > > > > > > > >>control protocol does not need to understand the > > > > > > > >>queuing or other resource allocation strategies > > needed to > > > > > > > >>provide the QoS. Providing the necessary QoS is the > > > > > > > >>function of the LSP tunnels. > > > > > > > > > > > > > > > > > > > > > > > > I think the definition of whether a QoS object is > > > > > opaque to the PW > > > > > > > > signalling protocol or not is dependant on the what > > > > > > > functions are being > > > > > > > > performed on the QoS object, and what mechanisms are > > > > > > > performing those > > > > > > > > functions. > > > > > > > > > > > > > > > > For example, in a network that uses single hop > > PWs, CAC may > > > > > > > be performed > > > > > > > > (for leased line/CBR type services) based on the > > bandwidth > > > > > > > required by the > > > > > > > > attachment circuit as part of the provisioning > process to > > > > > > > ensure that an > > > > > > > > egress (PE-PE) TE tunnel has enough bandwidth available > > > > > > > before signalling a > > > > > > > > PW. > > > > > > > > > > > > > > > > In a (hypothetical) network that uses PW > > switching with TE > > > > > > > tunnels between > > > > > > > > switching nodes, to ensure bandwidth is available for > > > > > any given PW > > > > > > > > end-to-end across multiple TE tunnels, CAC would > > need to be > > > > > > > performed at > > > > > > > > each switching node as part of the provisioning > > process. As > > > > > > > switching nodes > > > > > > > > are not directly attached to attachment circuits, they > > > > > > would need to > > > > > > > > receive the PW bandwidth information through the PW > > > > > > > signalling protocol. > > > > > > > > > > > > > > > > With single hop PWs, CAC is performed prior to PW > > > > > > > signalling and therefore > > > > > > > > it can be performed by a separate mechanism > (i.e. not the > > > > > > signalling > > > > > > > > protocol), but what about the switched PW case? For > > > > > > > switched PWs CAC would > > > > > > > > need to be performed at switching nodes during the > > > > > > > signalling process. So > > > > > > > > either the signalling protocol would need to > perform the > > > > > > > CAC function, or > > > > > > > > the signalling protocol would need to send the > bandwidth > > > > > > > information to a > > > > > > > > separate CAC mechanism and wait for a response before > > > > > continuing. > > > > > > > > > > > > > > > > If the PW signalling protocol performs the CAC function > > > > > > > then obviously the > > > > > > > > bandwidth information could not be considered to > > be opaque, > > > > > > > if on the other > > > > > > > > hand the CAC function was performed by a separate > > > > > > > mechanism, then the > > > > > > > > bandwidth information could be considered to be opaque. > > > > > > > Saying that, the > > > > > > > > two methods perform exactly the same > > functionality, I think > > > > > > > its more of an > > > > > > > > implementation/standards specification issue as > > to whether > > > > > > > the CAC function > > > > > > > > is considered to be part of the signalling mechanism or > > > > > separate. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Richard > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > pwe3 mailing list > > > > > > > > pwe3@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > pwe3 mailing list > > > > > > > > pwe3@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > pwe3 mailing list > > > > > > > pwe3@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RSVP-TE and PW Date: Thu, 14 Oct 2004 12:43:08 -0400 Lines: 497 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3-bounces@ietf.org, pwe3@ietf.org, richard.spencer@bt.com, erosen@cisco.com, Sasha@AXERRA.com, stbryant@cisco.com X-From: pwe3-bounces@ietf.org Thu Oct 14 19:00:40 2004 Return-path: To: "'Shah, Himanshu'" , "'dpapadimitriou@psg.com'" , Matthew.Bocci@alcatel.co.uk X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org > However, what is not OK is to refuse to look at other alternatives. I thought that my reference to draft-martini-pwe3-pw-switching-00.txt was clear evidence that I am willing to look at other alternatives. > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Thursday, October 14, 2004 12:13 PM > To: 'Busschbach, Peter B (Peter)'; 'dpapadimitriou@psg.com'; > Matthew.Bocci@alcatel.co.uk > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > Subject: RE: [PWE3] RSVP-TE and PW > > > It is fruitless to continue discussing further until there > is a proposal that you can shoot holes in it. So you will > have to wait. > > Since you have not fully understood the proposal (partly > because there is no written proposal), it would be a mistake > to call it a 'wrong mechanism'. > > It is possible that you have put more thought into this and > you see your proposal to be the only right way to solve this > problem. However, it would be a mistake to declare that rest > of the WG lack 'rigor' to create a robust set of standards. > > Now, it is possible that when everything is said and done, > hierarchical RSVP signaling is a better way to go. That is fine. > However, what is not OK is to refuse to look at other alternatives. > > /himanshu > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: Thursday, October 14, 2004 11:47 AM > > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > > Matthew.Bocci@alcatel.co.uk > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > Hi Himanshu, > > > > Sorry for repeatedly mispelling your first name. (It must be > > the abundance of 'ch's in my own name that lead my fingers to > > the wrong keys.) > > > > Thanks for your offer to continue this discussion off-line. > > However, I think it is important to discuss this on the list. > > > > The point is: the mechanism that you propose is wrong. An > > intermediate PE should not respond to the initiator of the PW > > before forwarding a setup message to the destination PE. The > > reason is that there are interface parameters that need to be > > exchanged between the two end points and must be passed > > unchanged across PW switching points. See section 6 of > > draft-martini-pwe3-pw-switching-00.txt for a correct > > description of the procedure. > > > > This may be a minor oversight, but to me it is an example of > > the lack of rigor that appears frequently in the MH-PW > > discussions on this mailing list. When people talk about a > > MH-PW as a collection of wires that are patched together, > > they seem to underestimate what it takes to create a robust > > set of standards. > > > > Peter > > > > > -----Original Message----- > > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > > Sent: Thursday, October 14, 2004 10:45 AM > > > To: 'Busschbach, Peter B (Peter)'; 'dpapadimitriou@psg.com'; > > > Matthew.Bocci@alcatel.co.uk > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; richard.spencer@bt.com; > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > If the word opaque is confusing you - then drop it. > > > It is not relevent in this discussion or what I > > > was suggesting on how one can use PWE3-control (ie targeted LDP) > > > also to signal MH PW along with QOS information. > > > > > > The main difference between terminating+resignaling and > > > processing+forwarding, the way I see it is this. > > > > > > Lets take a simple example of only one switching hop. > > > When switching PE1 receives PWE3-control msg from > > > source PE, he can respond back with his PW label (but > > > PW status down). He then would signal to target PE > > > using the information received from source PE plus > > > PE1's own label. When the response comes back from > > > target PE (and since he is target he would send PW status up), > > > PE1 would, > > > 1) program the FIB for PW label switching > > > 2) send PW status to source PE if both tunnels are up and > > > target PE indicated that PW status is up > > > > > > > > > May be the difference is subtle. Lets not hung up on that. > > > The objectives are, > > > 1) static configuration of intermediate PEs is not required > > > 2) QOS information is taken into consideration > > > 3) And most importantly we are still using established PWE3- > > > control signaling. > > > > > > if you need to discuss more, we can do that offline. > > > > > > /himanshu (not himanchu...:) > > > > > > > -----Original Message----- > > > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > > Sent: Thursday, October 14, 2004 9:51 AM > > > > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > > > > Matthew.Bocci@alcatel.co.uk > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > richard.spencer@bt.com; > > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > Himanchu, > > > > > > > > I am afraid your last email has left me even more confused > > > > than the first. > > > > > > > > Are you saying that the QoS object is opaque if you use > > > > CR-LDP or RSVP-TE to establish a MH-PW, but not if you > > > > terminate control signaling at intermediate nodes? What > > > > difference do you see between "terminating and resignaling" > > > > versus the regular RSVP-TE procedure of processing and > > > > forwarding of signaling messages? > > > > > > > > Peter > > > > > > > > > -----Original Message----- > > > > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > > > > Sent: Thursday, October 14, 2004 9:46 AM > > > > > To: 'Busschbach, Peter B (Peter)'; 'dpapadimitriou@psg.com'; > > > > > Matthew.Bocci@alcatel.co.uk > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > richard.spencer@bt.com; > > > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > It is NOT opaque for intermediate PE nodes. > > > > > > > > > > As I had indicated in the earlier email, > > > > > PWE3 control signal is terminated, processed and > > > > > re-signaled at each intermediate PE hop, all > > > > > the way to the destination PE. > > > > > > > > > > The word 'opaque' was used in the context of > > > > > LDP, CR_LDP, and use of RSVP-TE to build transport > > > > > lsp as well as multi-hop PW. > > > > > > > > > > Hope this clears up the confusion. > > > > > > > > > > /himanshu > > > > > > > > > > > -----Original Message----- > > > > > > From: Busschbach, Peter B (Peter) > > [mailto:busschbach@lucent.com] > > > > > > Sent: Thursday, October 14, 2004 9:28 AM > > > > > > To: Shah, Himanshu; 'dpapadimitriou@psg.com'; > > > > > > Matthew.Bocci@alcatel.co.uk > > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > > richard.spencer@bt.com; > > > > > > erosen@cisco.com; Sasha@AXERRA.com; stbryant@cisco.com > > > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > > > > > > Sent: Thursday, October 14, 2004 8:39 AM > > > > > > > To: 'dpapadimitriou@psg.com'; Matthew.Bocci@alcatel.co.uk > > > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > > > richard.spencer@bt.com; > > > > > > > busschbach@lucent.com; erosen@cisco.com; Sasha@AXERRA.com; > > > > > > > stbryant@cisco.com > > > > > > > Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > > > > As you suggest and I agree that it is fruitless to engage > > > > > > > in detailed discussions without a proposal on the table. > > > > > > > > > > > > > > Although, a couple of question that you have posted can > > > > > > > be clarified. As Eric has pointed out many times with > > > > > > > clarifications, I don't see why "qos model" and > "AC model" > > > > > > > is necessary for the underlying LDP signaling protocol. > > > > > > > > > > > > > > The (opaque) QOS TLV that is singalled to/through each PE > > > > > > hop is used > > > > > > > to select the suitable underlying transport tunnel (TE-LSP > > > > > > > or other) between PE hops, to perform the CAC > > and/or to apply > > > > > > > appropriate traffic shaping and policing for traffic > > > > > > between PW switch > > > > > > > points. > > > > > > > > > > > > > > > > > > How can an object be both opaque AND be used for CAC and > > > > > > tunnel selection? > > > > > > > > > > > > I suggest you read Richard's email again. His analysis is > > > > right on. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As for partial or end-to-end rerouting - we need to > > wait for > > > > > > > the requirements to be hammered out. > > > > > > > > > > > > > > > > > > > > > /himanshu > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: dimitri papadimitriou > > [mailto:dpapadimitriou@psg.com] > > > > > > > > Sent: Thursday, October 14, 2004 8:05 AM > > > > > > > > To: Matthew.Bocci@alcatel.co.uk > > > > > > > > Cc: pwe3-bounces@ietf.org; pwe3@ietf.org; > > > > > richard.spencer@bt.com; > > > > > > > > busschbach@lucent.com; erosen@cisco.com; > Sasha@AXERRA.com; > > > > > > > > stbryant@cisco.com > > > > > > > > Subject: Re: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > > > > > > > matthew, > > > > > > > > > > > > > > > > as of today, i don't see why/how T-LDP QoS > > > extensions can be > > > > > > > > qualified > > > > > > > > as "relatively simple" or "marginal extensions" > > (as i have > > > > > > > seen this > > > > > > > > argument used many times on this list) without any real > > > > > > > > proposal on the > > > > > > > > table for this purpose (i don't speak about the > > > > > > > > point-to-point exchange > > > > > > > > of QoS AC parameters as in draft-shah where only > > > > > ultimate PEs are > > > > > > > > involved) ? > > > > > > > > > > > > > > > > this said, what is the QoS model and AC model that is > > > > > > > > associated to LDP > > > > > > > > signaling on ultimate and intermediate switching > > > PEs ? so, as > > > > > > > > you are a > > > > > > > > bit evasive on how you would "transform" a > > > > > point-to-point non-QoS > > > > > > > > capable protocol into an end-to-end QoS capable > protocol, > > > > > > would you > > > > > > > > please clarify ? > > > > > > > > > > > > > > > > the next question is how end-to-end and/or partial > > > > > > > re-routing of such > > > > > > > > switched PW entities will be achieved in case of > > > switching PE > > > > > > > > node failure ? > > > > > > > > > > > > > > > > much thanks for your clarifications, > > > > > > > > - dimitri. > > > > > > > > > > > > > > > > Matthew.Bocci@alcatel.co.uk wrote: > > > > > > > > > > > > > > > > > Richard, > > > > > > > > > > > > > > > > > > I agree with what you are saying in general, > > but I think > > > > > > > that we can > > > > > > > > > achieve this with relatively simple > extensions to T-LDP. > > > > > > > > > > > > > > > > > > We already have a proposal for a way to > signal traffic > > > > > > > parameters in > > > > > > > > > draft-shah, and I think it would be simple to > > > enable T-LDP > > > > > > > > to signal the > > > > > > > > > ultimate target PE (either usings one of the > > > existing FECs, > > > > > > > > or a new one). > > > > > > > > > If a PE can maintain a binding of ingress and > > > egress T-LDP > > > > > > > > sessions, then > > > > > > > > > we can also effectively crankback PW setup > > attempts that > > > > > > > > fail or block at > > > > > > > > > an intermediate switching node. > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > Matthew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |---------+---------------------------> > > > > > > > > > | | richard.spencer@| > > > > > > > > > | | bt.com | > > > > > > > > > | | Sent by: | > > > > > > > > > | | pwe3-bounces@iet| > > > > > > > > > | | f.org | > > > > > > > > > | | | > > > > > > > > > | | | > > > > > > > > > | | 14/10/2004 01:21| > > > > > > > > > | | | > > > > > > > > > |---------+---------------------------> > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------| > > > > > > > > > | > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > | To: , > > > > > > > > > > > > > > > > > > > | > > > > > > > > > | cc: pwe3@ietf.org, Sasha@AXERRA.com, > > > > > > > > stbryant@cisco.com > > > > > > > > > > > | > > > > > > > > > | Subject: RE: [PWE3] RSVP-TE and PW > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------| > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Eric, > > > > > > > > > > > > > > > > > > > > > > > > > > >>I don't think so. The switching node just > > assigns the PW > > > > > > > > >>to an LSP tunnel with appropriate QoS characteristics. > > > > > > > > >>The data plane model is that packets move from > > one tunnel > > > > > > > > >>to the next by dint of ordinary MPLS > switching. Thus the > > > > > > > > >>relevant QoS characteristics are > > characteristics of the > > > > > > > > >>LSP tunnels. There are no resources or queuing > > strategies > > > > > > > > >>that are under the control of the PW control plane. > > > > > > > > >> > > > > > > > > >>I think it is appropriate to say that the QoS > > object is > > > > > > > > >>"opaque" to the PW control protocol, > because the PW > > > > > > > > >>control protocol does not need to understand the > > > > > > > > >>queuing or other resource allocation strategies > > > needed to > > > > > > > > >>provide the QoS. Providing the necessary > QoS is the > > > > > > > > >>function of the LSP tunnels. > > > > > > > > > > > > > > > > > > > > > > > > > > > I think the definition of whether a QoS object is > > > > > > opaque to the PW > > > > > > > > > signalling protocol or not is dependant on the what > > > > > > > > functions are being > > > > > > > > > performed on the QoS object, and what mechanisms are > > > > > > > > performing those > > > > > > > > > functions. > > > > > > > > > > > > > > > > > > For example, in a network that uses single hop > > > PWs, CAC may > > > > > > > > be performed > > > > > > > > > (for leased line/CBR type services) based on the > > > bandwidth > > > > > > > > required by the > > > > > > > > > attachment circuit as part of the provisioning > > process to > > > > > > > > ensure that an > > > > > > > > > egress (PE-PE) TE tunnel has enough bandwidth > available > > > > > > > > before signalling a > > > > > > > > > PW. > > > > > > > > > > > > > > > > > > In a (hypothetical) network that uses PW > > > switching with TE > > > > > > > > tunnels between > > > > > > > > > switching nodes, to ensure bandwidth is available for > > > > > > any given PW > > > > > > > > > end-to-end across multiple TE tunnels, CAC would > > > need to be > > > > > > > > performed at > > > > > > > > > each switching node as part of the provisioning > > > process. As > > > > > > > > switching nodes > > > > > > > > > are not directly attached to attachment > circuits, they > > > > > > > would need to > > > > > > > > > receive the PW bandwidth information through the PW > > > > > > > > signalling protocol. > > > > > > > > > > > > > > > > > > With single hop PWs, CAC is performed prior to PW > > > > > > > > signalling and therefore > > > > > > > > > it can be performed by a separate mechanism > > (i.e. not the > > > > > > > signalling > > > > > > > > > protocol), but what about the switched PW case? For > > > > > > > > switched PWs CAC would > > > > > > > > > need to be performed at switching nodes during the > > > > > > > > signalling process. So > > > > > > > > > either the signalling protocol would need to > > perform the > > > > > > > > CAC function, or > > > > > > > > > the signalling protocol would need to send the > > bandwidth > > > > > > > > information to a > > > > > > > > > separate CAC mechanism and wait for a response before > > > > > > continuing. > > > > > > > > > > > > > > > > > > If the PW signalling protocol performs the > CAC function > > > > > > > > then obviously the > > > > > > > > > bandwidth information could not be considered to > > > be opaque, > > > > > > > > if on the other > > > > > > > > > hand the CAC function was performed by a separate > > > > > > > > mechanism, then the > > > > > > > > > bandwidth information could be considered to > be opaque. > > > > > > > > Saying that, the > > > > > > > > > two methods perform exactly the same > > > functionality, I think > > > > > > > > its more of an > > > > > > > > > implementation/standards specification issue as > > > to whether > > > > > > > > the CAC function > > > > > > > > > is considered to be part of the signalling > mechanism or > > > > > > separate. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Richard > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > pwe3 mailing list > > > > > > > > > pwe3@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > pwe3 mailing list > > > > > > > > > pwe3@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > pwe3 mailing list > > > > > > > > pwe3@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: LDP Status Codes in draft-ietf-pwe3-control-protocol-11: section 7.2 vs. section 7.6 AND a possibly missing code Date: Mon, 18 Oct 2004 10:46:22 +0200 Lines: 55 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: "PWE3 WG \(E-mail\)" X-From: pwe3-bounces@ietf.org Mon Oct 18 10:57:45 2004 Return-path: To: "Luca Martini (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca and all, Please take a look at the two sections mentioned in the subject: 7.2. LDP status messages This document uses several new LDP status codes, IANA already maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC3036. The following values are suggested for assignment: 0x00000024 "Illegal C-Bit" 0x00000025 "Wrong C-Bit" 0x00000026 "Incompatible bit-rate" 0x00000027 "CEP/TDM mis-configuration" 0x00000028 "PW status" 0x00000029 "Invalid TAI" ... snipped ... 7.6. Status codes RFC 3036 has a range of Status Code values which are assigned by IANA on a First Come, First Served basis. These additional status codes, and assigned Values are specified in "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)" [IANA]. Since RFC 3036 is the LDP Spec, I cannot but assume that the Status Codes mentioned in Section 7.6 are LDP Statuc Codes mentioned in Section 7.2, i.e. both sections refer to the same IANA registry. However, Section 7.2 lists the required new values while Section 7.6 only contains a reference to draft-ietf-pwe3-iana-allocation-07.txt which, BTW, does not mention any LDP status codes (it did mention them in the -06 version). On a separate albeit related issue: Which LDP Status Code should be used if attempt to set up a FR Port Mode PW has been rejected due to difference in the DLCI Length at two end points? None of the values listed in Section 7.2 looks like suitable, while draft-ietf-pwe3-frame-relay-03.txt explicitly states that FR Port Mode PWs can be only set up if both end points use the same DLCI Length. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Ramasamy, Rajendran" Subject: Change in Order of F & B bit in Flag Bits of PW header. Date: Mon, 18 Oct 2004 05:21:10 -0700 Lines: 251 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0757375437==" X-From: pwe3-bounces@ietf.org Mon Oct 18 14:34:42 2004 Return-path: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Change in Order of F & B bit in Flag Bits of PW header. Thread-Index: AcS1DPNdqqdjePV2TPqkqCktqzaenQ== To: X-OriginalArrivalTime: 18 Oct 2004 12:21:28.0765 (UTC) FILETIME=[FE860ED0:01C4B50C] X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0757375437== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B50C.FAEC7F1A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B50C.FAEC7F1A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I have a question related to the difference between drafts 'draft-martini-l2circuit-encap-mpls-08' and 'draft-martini-l2circuit-encap-mpls-07'. In the diff I could see that only the FLAG bits (F & B bit) related to Pseudo-Wire header of Frame-Relay is changed. But I couldn't find the reason for doing so . Please clarify whether it is intentional or a typo ?=20 Diff of 'draft-martini-l2circuit-encap-mpls-08' and 'draft-martini-l2circuit-encap-mpls-07' are attached. draft-martini-l2circuit-encap-mpls-08.txt=20 vs draft-martini-l2circuit-encap-mpls-07.txt 0a1,5 >=20 >=20 >=20 >=20 >=20 3c8 < Expiration Date: March 2005 Nasser El-Aawar --- > Expiration Date: December 2004 Nasser El-Aawar 24c29 < September 2004 --- > June 2004 30c35 < draft-martini-l2circuit-encap-mpls-08.txt --- > Internet Draft draft-martini-l2circuit-encap-mpls-07.txt June 2004 363c368 < | Rsvd |F|B|D|C| Length | Sequence Number | <<<<<<<<<<<<<<< Difference in flag bits --- > | Rsvd |B|F|D|C| Length | Sequence Number | <<<<<<<<<<<<<<< =20 390c395 < Internet Draft draft-martini-l2circuit-encap-mpls-08.txt September 2004 --- > Internet Draft draft-martini-l2circuit-encap-mpls-07.txt June 2004 446c451 < Internet Draft draft-martini-l2circuit-encap-mpls-08.txt September 2004 --- <<<< snipped Since only file name difference is listed as the previous line >>>> Thanks in advance, Rajendran ------_=_NextPart_001_01C4B50C.FAEC7F1A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Change in Order of F & B bit in Flag Bits of PW = header.

Hi,
        I have a question related to the difference between = drafts 'draft-martini-l2circuit-encap-mpls-08' and = 'draft-martini-l2circuit-encap-mpls-07'.

In the diff I could see that only the = FLAG bits (F & B bit)  related to Pseudo-Wire header of = Frame-Relay is changed. But I couldn't find the reason for doing so . = Please clarify whether it is intentional or a typo ?

Diff of = 'draft-martini-l2circuit-encap-mpls-08' and = 'draft-martini-l2circuit-encap-mpls-07' are attached.

draft-martini-l2circuit-encap-mpls-08.txt
vs
draft-martini-l2circuit-encap-mpls-07.txt

0a1,5
>
>
>
>
>
3c8
< Expiration Date: March = 2005           &nb= sp;           &nbs= p;      Nasser El-Aawar
---
> Expiration Date: December = 2004           &nb= sp;           &nbs= p;   Nasser El-Aawar
24c29
<         =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; September 2004
---
>         =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      June 2004
30c35
<         =        = draft-martini-l2circuit-encap-mpls-08.txt
---
> Internet Draft = draft-martini-l2circuit-encap-mpls-07.txt     &n= bsp; June 2004
363c368
<    | Rsvd  = |F|B|D|C|    Length     = |        Sequence = Number        = |            =   = <<<<<<<<<<<<<<<  = Difference in flag bits

---
>    | Rsvd  = |B|F|D|C|    Length     = |        Sequence = Number        = |            =    = <<<<<<<<<<<<<<<   =
390c395
< Internet Draft = draft-martini-l2circuit-encap-mpls-08.txt  September 2004
---
> Internet Draft = draft-martini-l2circuit-encap-mpls-07.txt     &n= bsp; June 2004
446c451
< Internet Draft = draft-martini-l2circuit-encap-mpls-08.txt  September 2004
---
<<<< snipped Since only = file name difference is listed as the previous line = >>>>


Thanks in advance,
Rajendran

------_=_NextPart_001_01C4B50C.FAEC7F1A-- --===============0757375437== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0757375437==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Andrew G. Malis" Subject: Re: Change in Order of F & B bit in Flag Bits of PW header. Date: Tue, 19 Oct 2004 10:52:37 -0400 Lines: 31 Sender: pwe3-bounces@ietf.org References: <485C8799EA83DF4DAF2C1E78F8198D730FAB71@BNGEXMB01.corp.netgen.local> <485C8799EA83DF4DAF2C1E78F8198D730FAB71@BNGEXMB01.corp.netg en.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Wed Oct 20 04:07:42 2004 Return-path: X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 To: "Ramasamy, Rajendran" In-Reply-To: <485C8799EA83DF4DAF2C1E78F8198D730FAB71@BNGEXMB01.corp.netg en.local> References: <485C8799EA83DF4DAF2C1E78F8198D730FAB71@BNGEXMB01.corp.netgen.local> X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Rajendran, This was recently discussed at length on the PWE3 list. See http://www1.ietf.org/mail-archive/web/pwe3/current/msg06217.html and the follow-up messages in the same thread. Cheers, Andy --------- At 10/18/2004 05:21 AM -0700, Ramasamy, Rajendran wrote: >Hi, > I have a question related to the difference between drafts > 'draft-martini-l2circuit-encap-mpls-08' and > 'draft-martini-l2circuit-encap-mpls-07'. > >In the diff I could see that only the FLAG bits (F & B bit) related to >Pseudo-Wire header of Frame-Relay is changed. But I couldn't find the >reason for doing so . Please clarify whether it is intentional or a typo ? > >Diff of 'draft-martini-l2circuit-encap-mpls-08' and >'draft-martini-l2circuit-encap-mpls-07' are attached. > >draft-martini-l2circuit-encap-mpls-08.txt >vs >draft-martini-l2circuit-encap-mpls-07.txt > >Thanks in advance, >Rajendran From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Ramalingam, Swaminathan (Swaminathan)" Subject: Interworking PW Date: Wed, 20 Oct 2004 12:19:12 +0530 Lines: 15 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-bounces@ietf.org Wed Oct 20 11:42:53 2004 Return-path: To: pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi- PWE3 Architechture assumes the endpoints of a PW always "like" endpoints (as per RFC 3916) and it clearly specifies "service interworking" is out of scope of PWE3 WG. But, is there any guidelines and/or constraints of such "Service Interworking" for a PWE3 ckt?. I guess there should be some document under "informational" category, to guide/constraint if an implementation wants to do that. I like to know, is there any interest on such document on PWE3 WG?. Thanks, Swami From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Thomas D. Nadeau" Subject: Re: Interworking PW Date: Wed, 20 Oct 2004 08:01:15 -0400 Lines: 43 Sender: pwe3-bounces@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D20FF676EE@ii0015exch002u.iprc.lucent.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: "pwe3 \(IETF\)" X-From: pwe3-bounces@ietf.org Wed Oct 20 15:38:55 2004 Return-path: X-BrightmailFiltered: true In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D20FF676EE@ii0015exch002u.iprc.lucent.com> To: "Ramalingam, Swaminathan (Swaminathan)" X-Mailer: Apple Mail (2.619) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Take a look at the following drafts. The first is targeted at the L2VPN WG, and the other is a PWE3 WG document: draft-aissaoui-l2vpn-vpws-iw-oam-01.txt draft-ietf-pwe3-oam-msg-map-00.txt --Tom > Hi- > > PWE3 Architechture assumes the endpoints of a PW always "like" > endpoints (as > per RFC 3916) and it clearly specifies "service interworking" is out of > scope of PWE3 WG. > > But, is there any guidelines and/or constraints of such "Service > Interworking" for a PWE3 ckt?. I guess there should be some document > under > "informational" category, to guide/constraint if an implementation > wants to > do that. > > I like to know, is there any interest on such document on PWE3 WG?. > > Thanks, > Swami > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-cw-00.txt Date: Wed, 20 Oct 2004 10:50:53 -0400 Lines: 97 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Oct 21 04:23:11 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Control Word for use over an MPLS PSN Author(s) : S. Bryant, et al. Filename : draft-ietf-pwe3-cw-00.txt Pages : 8 Date : 2004-10-19 This document describes the preferred designs of the PWE3 Control Word, and the PW Associated Channel Header. The design of these fields is chosen so that an MPLS LSR performing deep packet inspection will not confuse a PWE3 payload with an IP payload. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cw-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-cw-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-cw-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-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: IETF61 slot requests Date: Thu, 21 Oct 2004 09:14:32 +0100 Lines: 31 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Thu Oct 21 14:52:40 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: pwe3 X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Second reminder: If there are any slot or topic requests for PWE3 at IETF 61, please send the request to me. - Stewart -------- Original Message -------- Subject: PWE3 @ IETF-61 Date: Fri, 17 Sep 2004 15:42:21 +0100 From: Stewart Bryant To: pwe3@ietf.org Some key dates for IETF-61: October 11, Monday - WG Chair approval for initial document (Version -00) submission due by 09:00 ET October 18, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET October 25, Monday - Working Group and BOF scheduling closes at 17:00 ET November 7-12, 2004 - 61st IETF Meeting in Washington, DC, USA It's my turn to run the agenda, so slot requests to me please, with a two sentence abstract. Please can I have slides by the 1st November. Thanks Stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: =?iso-8859-1?Q?Benny_Ammitzb=F8ll?= Subject: PW-DRAFT05-MIB question Date: Thu, 21 Oct 2004 11:00:39 +0200 Lines: 80 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_010B_01C4B75D.33670E90" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Oct 21 14:56:27 2004 Return-path: To: "David Zelig" , "Tnadeau@Cisco. Com" , "Dave_Danenberg@Yahoo. Com" , "Sharon. Mantin@Axonlink. Com" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-MS-TNEF-Correlator: X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_010B_01C4B75D.33670E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA22386 For 'pwVcOwner' equal 'manual' - how is the local attachment identified? For 'pwVcOwner' equal 'pwIdFecSignaling' the local attachment is identifi= ed by 'pwVcType' and 'pwVcID'. For 'pwVcOwner' equal 'genFecSignaling' the local attachment is identifie= d by 'pwVcType', 'pwVcGroupAttachmentID' and 'pwVcLocalAttachmentID'. Benny L=F8nstrup Ammitzb=F8ll, M.Sc.E.E. T|Pack A/S Lautrupbjerg 7-11 DK-2750 Ballerup, Denmark Phone: (+45) 44732100 Direct: (+45) 44732140 mailto:bla@tpack.net - www.tpack.net ------=_NextPart_000_010B_01C4B75D.33670E90 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IicJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHCgAVAAsAAAAAAAQACQEB A5AGAAAGAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAGAAAAFBXLURSQUZUMDUtTUlCIHF1ZXN0aW9uAAIBcQABAAAAFgAAAAHEt0xvvHJB0xUZxk7E iDluM56s1zYAAAIBHQwBAAAAIQAAAFNNVFA6QkVOTlkuQU1NSVRaQk9FTExAVFBBQ0suTkVUAAAA AAsAAQ4AAAAAQAAGDgAoTFhMt8QBAgEKDgEAAAAYAAAAAAAAAFbMuRpsYNdMjC6MwIu1FFDCgAAA CwAfDgEAAAACAQkQAQAAAMUBAADBAQAAwQIAAExaRnX8BVuRAwAKAHJjcGcxMjUWMgD4C2BuDhAw MzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgZJ2CJB3awuAZDQMYE5jAFALAwu1IEYFsSeAcHdW Y093bgSQ4CcgZXF1B0AUAAOBwxTxFLAtIGhvB+AEAKAgdGhlIAkAYxUB9mECQADQaAeAAjAWEAEA 5wIwBpAIkGQ/CqIKhAqEjmQTzxTVGcBJZEYFkLBTaWduB0ALgGcUsI8WXxdjBCAXqCBieRmk8FR5 cGUUsABwGVAZs3BJRCcuGFoZfxTkZ18J8BsvHD8dTx5ZLCDUR3EDYHVwQRcHH6EfCEyvI3Im6x/b GRRCCfBuHkAgTFwnZjgAgHRygybAEWBtbWl0egwwCSshbGwmIE0uU2OMLkUs8SmEVHxQANASaxFg L1MphExhdQkrcmJqBJBnIDctBjES4wqAREstMjfqNRFQQgdAbASQJsAmIKZECfAAwHJrKYRQFeAB FIA6ICgrNDUpwCA0NDczMg9AAUClL8RpCXBjdDJcNDNFIwDAAxB0bzoCYGFAdnQKsC3gLhSABUAV wHe9NuAuNicYuSmEEeEAOQAAAAALAAGACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAA4AI IAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAACdq AQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAAHgAKgAggBgAAAAAAwAAA AAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAA AQAAAAAAAAAeAAyACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwANgAggBgAA AAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMA PIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUA AAAAAAALAFKACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAU4AIIAYAAAAAAMAAAAAAAABG AAAAAAGFAAAAAAAAAgH4DwEAAAAQAAAAVsy5Gmxg10yMLozAi7UUUAIB+g8BAAAAEAAAAFbMuRps YNdMjC6MwIu1FFACAfsPAQAAAFgAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAA AAAAAAAATklUQfm/uAEAqgA32W4AAABcXEJsdWVcYmxhXE91dGxvb2tcb3V0bG9vay5wc3QAAwD+ DwUAAAADAA00/TcAAAIBfwABAAAAOwAAADxOSEVNSU1DT05LQU1EQ0tQSElEQUlFUEJDRkFBLkJl bm55LkFtbWl0emJvZWxsQHRwYWNrLm5ldD4AAAMABhChfdkQAwAHEJQBAAADABAQAAAAAAMAERAA AAAAHgAIEAEAAABlAAAARk9SUFdWQ09XTkVSRVFVQUxNQU5VQUwtSE9XSVNUSEVMT0NBTEFUVEFD SE1FTlRJREVOVElGSUVEP0ZPUlBXVkNPV05FUkVRVUFMUFdJREZFQ1NJR05BTElOR1RIRUxPQ0FM QQAAAADFOw== ------=_NextPart_000_010B_01C4B75D.33670E90 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------=_NextPart_000_010B_01C4B75D.33670E90-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Benny Ammitzb?ll" Subject: RE: PW-DRAFT05-MIB question Date: Thu, 21 Oct 2004 17:21:55 +0200 Lines: 120 Sender: pwe3-bounces@ietf.org References: <45A67426326F814AAC27DBEC3FC7EEC20A8B33@tlvmail1.corrigent.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_011C_01C4B792.76862EB0" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Oct 21 17:36:04 2004 Return-path: To: "David Zelig" , "Tnadeau@Cisco. Com" , "Dave_Danenberg@Yahoo. Com" , "Sharon. Mantin@Axonlink. Com" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-MS-TNEF-Correlator: In-Reply-To: <45A67426326F814AAC27DBEC3FC7EEC20A8B33@tlvmail1.corrigent.com> X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_011C_01C4B792.76862EB0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Ok, thanks. I think the description text should mention this, because it leaves you with the impression that all objects that could point out the attachment should be set to 0 when the 'pwVcOwner' does not equal 'pwIdFecSignaling' or 'genFecSignaling'. /Benny > -----Original Message----- > From: David Zelig [mailto:Davidz@corrigent.com] > Sent: 21. oktober 2004 17:09 > To: Benny Ammitzb?ll; Tnadeau@Cisco. Com; Dave_Danenberg@Yahoo. Com; > Sharon. Mantin@Axonlink. Com > Cc: pwe3@ietf.org > Subject: RE: PW-DRAFT05-MIB question > > Benny, > For manual configuration there is no signaling so there is no use for > logical identifiers from the protocol point of view. For management > consistency you may decide to use any of the attachment identifiers. > > David > > > > -----Original Message----- > > From: Benny.Ammitzboell@tpack.net > > [mailto:Benny.Ammitzboell@tpack.net] > > Sent: Thursday, October 21, 2004 11:01 AM > > To: David Zelig; Tnadeau@Cisco. Com; Dave_Danenberg@Yahoo. > > Com; Sharon. Mantin@Axonlink. Com > > Cc: pwe3@ietf.org > > Subject: PW-DRAFT05-MIB question > > > > For 'pwVcOwner' equal 'manual' - how is the local attachment > > identified? > > > > For 'pwVcOwner' equal 'pwIdFecSignaling' the local attachment > > is identified by 'pwVcType' and 'pwVcID'. > > > > For 'pwVcOwner' equal 'genFecSignaling' the local attachment > > is identified by 'pwVcType', 'pwVcGroupAttachmentID' and > > 'pwVcLocalAttachmentID'. > > > > Benny L?nstrup Ammitzb?ll, M.Sc.E.E. > > T|Pack A/S > ------=_NextPart_000_011C_01C4B792.76862EB0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjcPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANQHCgAVABEAFQAAAAQAJAEB A5AGAFAJAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAYAAAAUFctRFJBRlQwNS1NSUIgcXVlc3Rpb24AAgFxAAEAAAAgAAAAAcS3TG+8 ckHTFRnGTsSIOW4znqzXNgAAwh/gAAxs+9ACAR0MAQAAACEAAABTTVRQOkJFTk5ZLkFNTUlUWkJP RUxMQFRQQUNLLk5FVAAAAAALAAEOAAAAAEAABg4AVuuRgbfEAQIBCg4BAAAAGAAAAAAAAABWzLka bGDXTIwujMCLtRRQwoAAAAsAHw4BAAAAAgEJEAEAAAC8BAAAuAQAAKIJAABMWkZ14Y07yuEABWZi aWQEAABkAHKAY3BnMTI1MgD4xQtgbg6AMDMzAfcCpBMD4wIAY2gKwHNldDwwIAcTAoMNQRDlcHLG cQ7AEUhUYWgDcQKDRxNREr8RkTE3OBQHfbMKgAjIIDsJbw6gNQKAJQqBdgiQd2sLgGQ0jQxgYwBQ CwNsdHIKsQcI0A0yC8QgT2ssIAJ0EWBua3MuIEnLHAELgGscAWUgAQAE9KZpAiAcAGV4BUBzFDDw dWxkIAeAAjAd0xzASnMb8GIFkGF1EZAgQmkFQGxlYXYHkXn9CGAgA/AcEB0DB3ATIAeQOwCQHyNh BUAHQAMgb2J6agWQdAQgIlMFoB6ScP5vC4AFQAhgBUAdEiJwAZB/EVAe0h5WH7AeUBGgHABvOiAR wHcdIB8yHTAncEB3VmNPd24EkCclHUBvB5FubwVAZXFGdQdAJ1JJZEYFkFPYaWduB0ALgGcoAAWx 7CdnCfApay4KogqECoDkL0IJ8G55K5oaSyng/DM2AUAbEAFAEyAogCMReQvSNCADMA90L4ASZDGo NiAtMOJPBRBnC4D1KOFNIeFhKoAw4yuWLvQPLsELEy71GqVmaS0xjDQ0AUAp4DE4MAFAowzQNPNi IEYDYToDMDUMkmIRwEQggA2AIFriZSngZyBbAMADECaAcjo3I3pABaExQR7hLrkFoG1dAzEOwAAg bBFQfyuVDDAAQRqhEVAGUQIwOsk2pjIxHHBvayaAH7AbBcAB0DAvkBYwOjA5PzpWFAA4QDamLGMR 0G1t0SAwemI/IrA7FAApwPMBAB/gQEMEAAWgHHAIUGZtP+A3IWVfNyAn0G6xPMFnQFkUIUDGUxFh GwIgHHBNAHAdwG5AQXZ4AiAp4WtA0znPOthDxmM7tydwZTNACJAAMNouBbBnRL862XUi8zu3BFJF NoBQVy1EUgBBRlQwNS1NSfxCICjAB5AdwkfuMp8zr38uNzrxD4UCsjsTG3QsYyy9K5RGBbEDgSjS BaBuNMD+ZwhwInAfFASQIBEoUh5Q/ymmHlAmkFPaH/ICEAXACQD/MWAf0AMgDYAe4jTABJAEIDcD Uh0DLuJvCOEkBmYg/xlyHHBSRTIBJVNS8QCQS/D9CfBjPyAg0gDAPyAFgVch/yZyH/IAcD8gWWEk vVcpK4vfNyMsvgqBLqIvYz4vrzC//zHPTY8z7zT/NgJh8DZMLGNOLj9FKDAisEB0CrBj/0RQJ9AF QSujYfA35mmvarhPOa86umHwO3tUaAhwc7ZkW/Ab8E8jIDy0MRvw1T0EMT1wMRHQTW4/b0r/Pjk3 KT/vQP9CCGtmQq9Dv/9zH29ZRm9Hf3wvb+FJrUrf/0vvK7NvWUxPZW9Oz1AfG3Q/aKEqQid5KLVS hCgALSD/FDAH4FQxHRIJAFbiJPlrZvlXJ2Q/a2ZrZomPKM8p1X+MD40bBCCN2B+gPyAnY1R4eXBl KAAAcB6wJ2NJ/kQrdo7vif4qjpIPkx+ULxeVNBvwJ2NHA2B1cEHfJQeWMZWTa2YnY0yaQp47g5Zv PuRMXCdmOACAPxqwnhA/NqLCIrAb8E0uMFNjLkWkoWtmVHxmUGrhEdAvUyuaFvEAAacQHgBCEAEA AABAAAAAPDQ1QTY3NDI2MzI2RjgxNEFBQzI3REJFQzNGQzdFRUMyMEE4QjMzQHRsdm1haWwxLmNv cnJpZ2VudC5jb20+AAsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwADgAggBgAAAAAA wAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAABShQAAJ2oBAB4ACYAI IAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAAeAAqACCAGAAAAAADAAAAAAAAARgAA AAA2hQAAAQAAAAEAAAAAAAAAHgALgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAA AB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAA2ACCAGAAAAAADAAAAA AAAARgAAAACChQAAAQAAAAsAOoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwA8gAggBgAA AAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAD2ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsA UoAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwBTgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUA AAAAAAACAfgPAQAAABAAAABWzLkabGDXTIwujMCLtRRQAgH6DwEAAAAQAAAAVsy5Gmxg10yMLozA i7UUUAIB+w8BAAAAWAAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABO SVRB+b+4AQCqADfZbgAAAFxcQmx1ZVxibGFcT3V0bG9va1xvdXRsb29rLnBzdAADAP4PBQAAAAMA DTT9NwAAAgF/AAEAAAA7AAAAPE5IRU1JTUNPTktBTURDS1BISURBQ0VQRUNGQUEuQmVubnkuQW1t aXR6Ym9lbGxAdHBhY2submV0PgAAAwAGEANk7MYDAAcQgQQAAAMAEBAAAAAAAwAREAEAAAAeAAgQ AQAAAGUAAABPSyxUSEFOS1NJVEhJTktUSEVERVNDUklQVElPTlRFWFRTSE9VTERNRU5USU9OVEhJ UyxCRUNBVVNFSVRMRUFWRVNZT1VXSVRIVEhFSU1QUkVTU0lPTlRIQVRBTExPQkpFQ1RTAAAAAHti ------=_NextPart_000_011C_01C4B792.76862EB0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------=_NextPart_000_011C_01C4B792.76862EB0-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "David Zelig" Subject: RE: PW-DRAFT05-MIB question Date: Thu, 21 Oct 2004 17:09:00 +0200 Lines: 191 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0848797594==" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Oct 21 17:46:06 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Thread-Topic: PW-DRAFT05-MIB question Thread-Index: AcS3TG+8ckHTFRnGTsSIOW4znqzXNgAAwh/g To: "Benny Ammitzb?ll" , "Tnadeau@Cisco. Com" , "Dave_Danenberg@Yahoo. Com" , "Sharon. Mantin@Axonlink. Com" X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0848797594== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B77F.E53AB118" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B77F.E53AB118 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Benny, For manual configuration there is no signaling so there is no use for = logical identifiers from the protocol point of view. For management = consistency you may decide to use any of the attachment identifiers. David > -----Original Message----- > From: Benny.Ammitzboell@tpack.net=20 > [mailto:Benny.Ammitzboell@tpack.net]=20 > Sent: Thursday, October 21, 2004 11:01 AM > To: David Zelig; Tnadeau@Cisco. Com; Dave_Danenberg@Yahoo.=20 > Com; Sharon. Mantin@Axonlink. Com > Cc: pwe3@ietf.org > Subject: PW-DRAFT05-MIB question >=20 > For 'pwVcOwner' equal 'manual' - how is the local attachment=20 > identified? >=20 > For 'pwVcOwner' equal 'pwIdFecSignaling' the local attachment=20 > is identified by 'pwVcType' and 'pwVcID'. >=20 > For 'pwVcOwner' equal 'genFecSignaling' the local attachment=20 > is identified by 'pwVcType', 'pwVcGroupAttachmentID' and=20 > 'pwVcLocalAttachmentID'. >=20 > Benny L?nstrup Ammitzb?ll, M.Sc.E.E. > T|Pack A/S > Lautrupbjerg 7-11 > DK-2750 Ballerup, Denmark > Phone: (+45) 44732100 > Direct: (+45) 44732140 > mailto:bla@tpack.net - www.tpack.net >=20 ------_=_NextPart_001_01C4B77F.E53AB118 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: PW-DRAFT05-MIB question

Benny,

For manual = configuration there is no signaling so there is no use for logical = identifiers from the protocol point of view. For management consistency = you may decide to use any of the attachment identifiers.

David


>  -----Original Message-----

> = From:         Benny.Ammitzboell@tpack.net

> = [mailto:Benny.Ammitzboell@tpac= k.net]

> = Sent: Thursday, October 21, = 2004 11:01 AM

> = To:   David Zelig; = Tnadeau@Cisco. Com; Dave_Danenberg@Yahoo.

> = Com; Sharon. Mantin@Axonlink. Com

> = Cc:   pwe3@ietf.org

> = Subject:      PW-DRAFT05-MIB question

>

> For 'pwVcOwner' equal 'manual' - how is the = local attachment

> = identified?

> =

> For = 'pwVcOwner' equal 'pwIdFecSignaling' the local attachment =

> is = identified by 'pwVcType' and 'pwVcID'.

> =

> For = 'pwVcOwner' equal 'genFecSignaling' the local attachment =

> is = identified by 'pwVcType', 'pwVcGroupAttachmentID' and

> = 'pwVcLocalAttachmentID'.

> =

> = Benny Lønstrup Ammitzbøll, M.Sc.E.E.

> = T|Pack A/S

> = Lautrupbjerg 7-11

> = DK-2750 Ballerup, Denmark

> = Phone: (+45) 44732100

> = Direct: (+45) 44732140

> mailto:bla@tpack.net - = www.tpack.net

> =

------_=_NextPart_001_01C4B77F.E53AB118-- --===============0848797594== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0848797594==-- From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: [Fwd: Re: draft-ietf-pwe3-arch-07.txt editorials] Date: Fri, 22 Oct 2004 10:26:01 +0100 Lines: 193 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Fri Oct 22 11:30:23 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: pwe3 X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I propose that we send the following editorial requests to the RFC editor. Note that the first change removes an important gate because now the only gate is L2TPv3 which is in the RFC-editor's queue with no gate. - Stewart Stewart Bryant wrote: > > The following editorial changes need to be made to > > > Note that the first change removes a reference that is > gating the draft and hence requires a change to the > status in the RFC editors queue. > > -------------------------------------------------- > > 1)The reference [FRAG] should be deleted from > the Normative References > > REASON > > [FRAG] was a normative reference in section 5.4.3. > "PW over MPLS Generic Control Word" in the -06 > version of the draft. This section was removed > and placed in a new draft. There was no other > reference to [FRAG] in the text and so this > reference should have also been removed. > > --------------------------------------------------- > > 2) In the following text "the associated PWs" should > be replaced by "the PW" > > "7.3.1. Pseudo-wire Up/Down Notification > > If a native service REQUIRES bi-directional connectivity, the > corresponding emulated service can only be signaled as being up when > the associated PWs, and PSN tunnels if any, are functional in both > directions. " > > Also REQUIRES should be lower case. > > The text should then read > > "7.3.1. Pseudo-wire Up/Down Notification > > If a native service requires bi-directional connectivity, the > corresponding emulated service can only be signaled as being up when > the PW, and PSN tunnels if any, are functional in both > directions. " > > > REASON > ------ > > PWs are bi-directional and therefore, there is only one PW > that must be up. > > Note that the equivalent text in the requirements draft: > > "5.1. Setup and Teardown of Pseudo-Wires > > If a native circuit is bi-directional, the corresponding emulated > circuit can be signaled "Up" only when the associated PW and PSN > tunnels in both directions are functional." > > is correct and the change makes the two drafts > consistent. > > ----------------------------------------------------- > 3) At the end of 5.4.3. PW-IP Packet Discrimination > > there is a spurious ".sp" which needs to be deleted > > ----------------------------------------------------- > > 4) In "1.4 Terminology" the following text should > be removed: > > PWE3 Payload Type A identifier used to distinguish between > Identifier an MPLS IP payload and a CW that is not > (PWE3-PID) ECMP safe. > > REASON > ------ > This term is no longer used by PWE3. > > ----------------------------------------------------- > > 5) In "5.4.3. PW-IP Packet Discrimination" delete the > line > > The use of this field for PWs is work in progress. > > REASON > ------ > This work has progressed since -07 was sent to the IESG. > Text is cleaner without the line and no value is lost. > > > ------------------------------------------------------ > 6) From the "Normative References" section the > following references should be removed as they are > not used: > > [RFC791] > [RFC1883] > [RFC1902] > [RFC2119] > [RFC3031] > > REASON > ------ > Not referenced by the text > > ------------------------------------------------------ > > 7) All references to RFC2558 should be replaced by > references to RFC3592 > > This occur in Fig 16 and in the Normative references > which should now include the following definition > for RFC3592: > > [RFC3592] K. Tesink, "Definitions of Managed Objects for the > Synchronous Optical Network/Synchronous Digital Hierarchy > (SONET/SDH) Interface Type", RFC3592, September 2003. > > REASON > ------ > RFC2558 has been obsoleted by RFC3592 > > ------------------------------------------------------- > > 8) All references to [LDPMIB] should be replaced by > [RFC3815] > > In the informative references the reference should be > > [RFC3815] Cucchiara, J., Sjostrand, H., and Luciani, J., > "Definitions of Managed Objects for the Multiprotocol > Label Switching, Label Distribution Protocol (LDP)", > RFC-3815, June 2004 > > REASON > ------ > This Internet-Draft was published as a Proposed Standard, RFC 3815 > (http://www.ietf.org/rfc/rfc3815.txt), on 2004-6-22. > > The name of the internet-draft was draft-ietf-mpls-ldp-mib-14.txt > > -------------------------------------------------------- > > 9) All references to [LSRMIB} should be changed to [RFC3813] > > In the informative references the reference should be > > [RFC3813] Srinivasan, C., Viswanathan, A., Nadeau, T. > "Multiprotocol Label Switching (MPLS) Label > Switching Router (LSR) Management Information > Base (MIB)", RFC-3813, June 2004 > > REASON > ------ > This Internet-Draft was published as a Proposed Standard, RFC 3813 > (http://www.ietf.org/rfc/rfc3813.txt), on 2004-6-22. > > The name of the internet-draft was draft-ietf-mpls-lsr-mib-14.txt > > ------------------------------------------------------- > > 10) All references to [TEMIB] should be changed to [RFC3812] > > In the informative references the reference should be > > [RFC3812] Srinivasan, C., Viswanathan, A., Nadeau, T. > "Multiprotocol Label Switching (MPLS) Traffic > Engineering (TE) Management Information Base (MIB)", > RFC-3812, June 2004. > > REASON > ------- > This Internet-Draft was published as a Proposed Standard, RFC 3812 > (http://www.ietf.org/rfc/rfc3812.txt), on 2004-6-22. > > The name of the internet-draft was draft-ietf-mpls-te-mib-14.txt > > From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-control-protocol-12.txt Date: Mon, 25 Oct 2004 16:06:11 -0400 Lines: 102 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Oct 26 01:01:40 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --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, et al. Filename : draft-ietf-pwe3-control-protocol-12.txt Pages : 41 Date : 2004-10-25 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 low-rate TDM and 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-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-control-protocol-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-control-protocol-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Singh, Hardeep (Hardeep)" Subject: RE: I-D ACTION:draft-ietf-pwe3-control-protocol-12.txt Date: Mon, 25 Oct 2004 20:19:27 -0400 Lines: 74 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Tue Oct 26 02:24:08 2004 Return-path: To: "'Internet-Drafts@ietf.org'" , i-d-announce@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Is there an easy way to see the revision history for the draft (For eg. the nature of changes made - a short synopsis on areas touched, etc) Thanks Hardeep -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 25, 2004 4:06 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-control-protocol-12.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, et al. Filename : draft-ietf-pwe3-control-protocol-12.txt Pages : 41 Date : 2004-10-25 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 low-rate TDM and 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-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-control-protocol-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-control-protocol-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Sasha Vainshtein Subject: Minor comments regarding draft-ietf-pwe3-control-protocol-12.txt Date: Tue, 26 Oct 2004 10:15:47 +0200 Lines: 170 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: "PWE3 WG \(E-mail\)" X-From: pwe3-bounces@ietf.org Tue Oct 26 10:33:04 2004 Return-path: To: "Luca Martini (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Luca and all, I am now reading draft-ietf-pwe3-control-protocol-12.txt and it looks really good. However, I have some minor comments that I would like to present for your consideration. Hopefully you will find some of them useful. 1. The last para on Page 5 says: The following two figures describe the reference models which are derived from [ARCH] to support the Ethernet PW emulated services. However, Figures 1 and 2 (to which this text presumably refers) do not mention Ethernet (or any specific Layer 2) at all. Indeed, even the reference to "Layer 2 services" in Fig.2 seems over-restrictive, as it creates an, IMHO, wrong impression that the protocol stack it describes does not apply to TDM and/or SONET PWs. 2. The text on page 7 says: So when PE1 sends a layer 2 PDU to PE2, it first pushes a PW label on its label stack, thereby creating an MPLS packet. It then (if PE1 is not adjacent to PE2) encapsulates that MPLS packet in a PSN tunnel header. (If the PSN tunnel is an LSP, this is just a matter of pushing on a second label.) The PW label is not visible again until the MPLS packet reaches PE2. PE2's disposition of the packet is based on the PW label. IMHO the text, as written, may create a wrong impression that pushing a stack of several labels representing the PSN tunnel is not considered. 3. The next para on the same page says: Note that the PW label must always be at the bottom of the packet's label stack and labels MUST be allocated from the per-platform label space. The following questions arise: a) The text uses IETF capitalized "MUST" when requesting allocation of the PW from the per-platform label space and non-capitalized "must" when requesting the PW label at the bottom of the label stack. This may create an impression that the bottom-of-stack clause is not a requirement of this protocol which is probably wrong. b) Please note taht if the "bottom-of-stack" clause were made a requirement, (by using IETF capitalized "MUST") it would preclude using Y.1711 as the PW OAM method. While I do not have any problems with such a limitation, I believe that an explicit clarification would be beneficial. c) Per-platform allocation of PW labels has been questioned too many times by too many people on this list to justify a few more words explaining why this requirement is necessary (or why the alternative does not make sense). In fact, most of these words are already there, but IMHO it would be nice to dot all i's and cross all t's. 4. Section 4.1 "Frame Relay" a) Reference [ITUQ] points to ITU-T Recommendation Q.933. Hence explicit mentioning Q.933 in the text ... particular DLCI, as defined in [ITUQ] Q.933 Annex A.5 sited in IA FRF1.1, ... looks unncesssary. Please note also that FRF1.1 is mentioned but is not a reference. b) FR LMI can report both failure and deletion of a specific DLCI (as two different condistions), but the text does not specify any difference in the processing, leaving open the following question (that, to the best of my memory, has been discussed on the list): should the PE that has been notified about deletion of a DLCI withdraw the associated PW label? c) This section does not mention FR Port Mode PWs defined in [FRAME]. 5. The text describing PW ID on page 14 does not contain an explicit specification of the PW ID scope. This issue has been raised on this list, and, to the best of my recollections, the consensus was that PW ID value MUST be unique per PW Type per given pair of PEs. IMHO it is worth explicitly saying that in the spec. 6. Section 5.2 "The Generalized PW ID FEC Element" Please note that the following text: The "Generalized ID FEC Element" is FEC type 129 (provisionally, subject to assignment by IANA). does not match any wording used when describing FEC type 128. Please note also that both descriptions refer to [note1] that states: [note1] FEC element type 128,129 is pending IANA approval. Hence, IMHO, specifically mentioning that FEC type 129 is used provsionally is unncessary. 7. On page 17, the fielsd AGI, SAII and TAII in the (unnamed) diagram actually refer to single-octet AGI, SAII and TAII type identifiers. IMHO it would be useful to update the diagram accordingly. Please note also that the number "129" appears directly in the diagram describing the Generlized PW ID FEC, while the matching field in the diagram describing the PW ID FEC is marked as "PW tlv". And it would be helpful to cintinue numbering of the diagrams through the entire document (it stops at Figure 2, and the remaining diagrams are nameless:-) 8. The following two text fragments seem to be in contradiction to me: 5.2.1. Attachment Identifiers ... snipped ... The association of two unidirectional LSPs into a single bidirectional pseudowire depends on the SAI and the TAI. Each application and/or provisioning model which uses the Generalized ID FEC element must specify the rules for performing this association. vs. 5.2.3. Signaling Procedures ... snipped ... If PE2 decides to accept the Label Mapping message, then it has to make sure that an LSP is set up in the opposite (PE1-->PE2) direction. If it has already signaled for the corresponding LSP in that direction, nothing more need be done. Otherwise, it must initiate such signaling by sending a Label Mapping message to PE1. This is very similar to the Label Mapping message PE2 received, but with the SAI and TAI reversed. Thus a bidirectional PW consists of two LSPs, where the FEC of one is the "reverse" of the FEC of the other. The text in Quote 2 looks to me like an explicit specification of an (application-independent) pairing rule which, according to Quote 1, is left for specific applications using the Generalized PW ID FEC. 9. [ITUG] is listed as one of informative references but never used. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: "Vishal Sharma" Subject: Deadline extended: "Inter-Provider Service Quality..." IEEE Comm. Mag. CFP Date: Tue, 26 Oct 2004 07:37:22 -0700 Lines: 146 Sender: pwe3-bounces@ietf.org Reply-To: v.sharma@ieee.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Loa Andersson , Thomas Nadeau , "Monique J. Morrow" X-From: pwe3-bounces@ietf.org Tue Oct 26 16:46:13 2004 Return-path: To: "MPLS" , "CCAMP" , "L2PPVPN" , "L3PPVPN" , "PWE3" 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.1409 X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Folks, Due to responses from several quarters for this CFP, and the authors requesting for more time to submit, we are happy to let you know that the deadline for submission for this Feature Topic issue has been extended up to: **26 November 2004**. So, we invite those working in this area who are considering sending in their contributions, but were held back by the deadline to rush to do so! If you intend to submit a paper for this special issue, please do drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your continued participation! Thanks, -Vishal ========================================================================= CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "Challenges in Enabling Inter-Provider Service Quality on the Internet" ************************************************************************* ** Submission deadline extended to 26 November 2004.** As carriers and service providers build multi-services networks based on IP/MPLS- enabled infrastructures that are able to meet evermore stringent service level agreements (SLAs) and quality-of-service (QoS) requirements, it becomes a key issue to extend the ability to deliver these services across carrier and service provider domain boundaries, while at the same time preserving the same SLAs and QoS assurances as those provided within a given provider's network. The advent of new end-user applications, as well as new services based on MPLS technology, such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs), also means the emergence of added service quality requirements from operators deploying and interoperating these networks and the end-users themselves. As a result, providers and vendors require efficient means to enable inter-provider service quality, which comprises of several key elements including quality of service, class of service, security, OAM, and restoration and repair. This will is lead to the emergence of improved or novel tools and techniques to address these aspects, with the goal of guaranteeing service quality end-to-end, improving security and billing/accounting, and reducing operating costs. Standards organizations such as the IETF and the ITU are taking on significant work in this area, and various aspects of this subject are also being investigated by bodies such as the OIF, the MSF, the MPLS/Frame Relay Alliance, the IEEE, and the Metro Ethernet Forum, and are the themes for numerous upcoming conferences. This feature topic issue of the IEEE Communications Magazine has a multi-pronged focus on the delivery of inter-provider service quality: * Highlight operator and end-user concerns and requirements. * Feature current and/or planned deployment experiences. * Survey modern research and engineering developments. * Spotlight contemporary standards activity. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but certainly not limited to) the following topics: * Carrier requirements for efficient inter-provider service quality: Current operational needs, bottlenecks, future demands * Deployment experience with inter-provider service quality on IP/MPLS- based networks: comparative analysis, case studies * QoS management in an inter-provider environment: interconnection architectures using MPLS, Diffserv, QoS performance, path characterization, routing policies * Service assurance in inter-provider infrastructures: End-to-end SLA management, service billing/reporting, admission control * Failure and restoration requirements/challenges in inter-provider contexts * Interoperability and inter-working of diverse equipment types and technologies (ATM, FR, Ethernet) * Current engineering and research developments: E.g. Passive and active performance measurement and monitoring, TE, modelling and simulation * Standards activities and initiatives: new services and network architectures On-line CFP with submission instructions can be found at: http://www.metanoia-inc.com/IEEECommMag_InterProviderQoS_CFP.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 there is 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 26 November 2004.** Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Manuscript Due: **26 November 2004** Acceptance Notification: 15 January 2004 Final Manuscript Due: 28 February 2005 Publication Date: June 2005 (Deadline extended from 30th October 2004 to 26th November 2004.) Guest Editors Monique J. Morrow, Cisco Systems, (mmorrow@cisco.com) Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Thomas D.Nadeau, Cisco Systems (tnadeau@cisco.com) Loa Andersson, Acreo (loa@pi.se) **************************************************************** Vishal Sharma, Ph.D. Metanoia, Inc. (Critical Systems Thinking) 888 Villa Street, Suite 200, Mountain View, CA 94041-1261 Phone: +1 650-641-0082. Fax: +1 650-641-0086 Email: v.sharma@ieee.org. http://www.metanoia-inc.com **************************************************************** From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-oam-msg-map-01.txt Date: Thu, 28 Oct 2004 11:05:27 -0400 Lines: 96 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-bounces@ietf.org Thu Oct 28 20:28:36 2004 Return-path: To: i-d-announce@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --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) OAM Message Mapping Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-oam-msg-map-01.txt Pages : 26 Date : 2004-10-27 This document enumerates the OAM defect state mapping from pseudo wire emulated edge-to-edge services over MPLS and IP transport networks to their native attached services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-oam-msg-map-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-oam-msg-map-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-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Danny McPherson Subject: IETF 61/DC Slot Requests Date: Fri, 29 Oct 2004 08:16:38 -0600 Lines: 6 Sender: pwe3-bounces@ietf.org Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-bounces@ietf.org Fri Oct 29 16:43:12 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.619) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org If you'd like a slot in DC please let me know ASAP. We've only received a couple of requests thus far. -danny/stewart From pwe3-bounces@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: I-D ACTION:draft-ietf-pwe3-control-protocol-12.txt Date: Fri, 29 Oct 2004 17:33:45 -0600 Organization: Cisco Systems Lines: 159 Sender: pwe3-bounces@ietf.org References: <4F9DBE266768DC46A1F17E875D37164108569FF9@ma8117exch002u.inse.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "PWE3 WG \(E-mail\)" X-From: pwe3-bounces@ietf.org Sat Oct 30 01:47:41 2004 Return-path: X-BrightmailFiltered: true User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20040620 X-Accept-Language: en-us, en, fr, it To: "Singh, Hardeep (Hardeep)" In-Reply-To: <4F9DBE266768DC46A1F17E875D37164108569FF9@ma8117exch002u.inse.lucent.com> X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.224.186] X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Here is the diff. Basically : - added generic misconfiguration error ( per sasha ) - Clarification on pSN tunnel text. - removed redundant status tlv secion - fixed grouping tlv note That's it. Luca ------- control.nroff ------- 1c1 < .\" %A% %D% %T% %R%.%S% --- > .\" @(#) control.nroff 12.3@(#) 04/10/22 18:38:00 12.0 6c6 < .Id 11 "ietf-pwe3-control-protocol" --- > .Id 12 "ietf-pwe3-control-protocol" 9c9 < .Dd 2004 10 05 --- > .Dd 2004 10 22 196,202c196,202 < pseudowire to the other are MPLS packets. Unless the pseudowire endpoints < are immediately adjacent, these MPLS packets must be transmitted through a < PSN tunnel. Any sort of PSN tunnel can be used, as long as it is possible to < transmit MPLS packets through it. The PSN tunnel can itself be an LSP, or < any other sort of tunnel which can carry MPLS packets. Procedures for < setting up and maintaining the PSN tunnels are outside the scope of this < document. --- > pseudowire to the other are MPLS packets must be transmitted through a PSN > tunnel, however if the pseudowire endpoints are immediately adjacent, the > PSN tunnel may not be necessary. Any sort of PSN tunnel can be used, as long > as it is possible to transmit MPLS packets through it. The PSN tunnel can > itself be an LSP, or any other sort of tunnel which can carry MPLS packets. > Procedures for setting up and maintaining the PSN tunnels are outside the > scope of this document. 923c923 < A more detailed diagram is shown in Appendix B. --- > .\A more detailed diagram is shown in Appendix B. 1200c1200,1202 < accept such withdrawn message, but are not required to send it. --- > accept such withdrawn message, but are not required to send it. Note that > the PW Grouping ID TLV only applies to PW using the Generalized ID FEC > element, while the Group ID only applies to PWid FEC element. 1204,1205c1206,1207 < include only the group ID. A Label Release message initiated from the < imposition router must always include the PW ID. --- > include only the group ID, or Grouping ID TLV. A Label Release message > initiated from the imposition router must always include the PW ID. 1269a1272,1273 > 0x0000002A "Generic Misconfiguration Error" > 1318,1323d1321 < .Pb "Status codes" < RFC 3036 has a range of Status Code values which are assigned by IANA on a < First Come, First Served basis. These additional status codes, and assigned < Values are specified in "IANA Allocations for pseudo Wire Edge to Edge < Emulation (PWE3)" [IANA]. < Singh, Hardeep (Hardeep) wrote: >Is there an easy way to see the revision history for the draft (For eg. >the nature of changes made - a short synopsis on areas touched, etc) > >Thanks > >Hardeep > >-----Original Message----- >From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of >Internet-Drafts@ietf.org >Sent: Monday, October 25, 2004 4:06 PM >To: i-d-announce@ietf.org >Cc: pwe3@ietf.org >Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-control-protocol-12.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, et al. > Filename : draft-ietf-pwe3-control-protocol-12.txt > Pages : 41 > Date : 2004-10-25 > >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 low-rate TDM and 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-12.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-pwe3-control-protocol-12.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-pwe3-control-protocol-12.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > >