From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 09:21:09 +0300 Lines: 72 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , "Andrew G. Malis" , X-From: pwe3-admin@ietf.org Thu May 01 08:31:15 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcMPFWDhuVY9udXWSe6xhlXikNuGOgAkgZrA To: "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h416SI826524 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, > Just for the reference: Axerra develops, produces and sells > an edge device that handles multiple PW types. Some of the supported PWs use RTP and > some don't. And, so far, we have not experienced any problem due to > different encapsulations. Yes, I know that you have such capabilities. However, the fact that a problem CAN be addressed using a certain set of constraints, doesn't mean that these constraints are useful. For example, as we all know CESoPSN uses a completely different control word from the "standard" one used in atm-encap, fr-encap, etc. Now, assuming that your device really handles multiple PWE encap types (and not, for instance, simply transporting frame relay inside a TDM timeslot which really isn't handling multiple PWE types) then you have to first "know" which PWE type the incoming packet is, before handing it off to the appropriate encap handler. This knowledge is apparently in the configuration based on the label or IP destination address, or some other non-PWE layer. So although your device may handle multiple PWE types, your use of different CWs forces you to handle them separately, needlessly duplicating hardware and software. > I do not see why supporting multiple encapsulations in a "PWE3 chip" > would be different in any way. Granted, I am not an ASIC expert. > But Ron and Tim are. Once again, this is not the point. Given an engineering constraint I am sure that Ron and Tim can come up with a solution. But we are trying to do architecture DESIGN here, not live with arbitrary constraints. In pure terms, a "PWE chip" should be able to receive a packet containing any PWE type (or at least any type it was designed to handle) and be able to process it. By processing I mean, at very leaast to be able to strip and check the CW, performing sequencing, timing, errorr detection, etc. as relevant. It would then send the payload to wherever. By using multiple CW types, multiple placements for the CWs, and not using consistent PIS, we make the clean design of such a "PWE chip" impossible. We now need an ATM-encap chip, a fr-encap chip, a tdm-encap chip, and a controller chip which uses info in other layers to relegate the processing to the appropriate chip. Of course, these chips could be forced onto a single substrate, but they are still logically distinct. > IMO, an attempt to insert a (possibly suppressed) > RTP header between the CW and the payload would > make such a chip really complicated. Quite the contrary. Some PWs need RTP, others don't. We need to first uniquely determine that the packet is a PWE packet (that should determined by the "type" in the previous layer, i.e. MPLS PID, IP type, etc). Then this packet would be passed to the "PWE chip". This chip must first determine which PWE type we have and handle all common PWE functionality. Only then, if the PWE type supports RTP, and RTP is determined to be in use, should the RTP information be extracted and used. Any other order is not only more complex, it is a clear layer violation (more on that in another email). Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 1 May 2003 10:57:30 +0300 Lines: 98 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , X-From: pwe3-admin@ietf.org Thu May 01 10:06:08 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcMPG8R/tqEBYWh8SPuc4wuhg+CsTgAjhz7w To: "Andrew G. Malis" , "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41843800370 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy, Yes, I know that RTP has been that way all along, and as you have probably noticed, I have been going along with it. In all the anavi drafts I have also put the RTP between the PSN layers and the control word. I guess I should claim temporary insanity, but the real reason is that I never saw RTP to be needed, and thus never really thought too much about it. However, I was awakened by the thought of having this anomaly sanctioned in a document called the PWE ARCHITECTURE draft. >From a purely architectural point of view the order is clearly wrong. Let me explain, using the OSI layering model (in G.805 layer network terms it is even worse, but I think that the OSI terminology is more familiar to most of readers of this list). * Each layer performs a service for the layer directly above it. * Working inwards on a packet we reach higher layers. After we have finished processing the layer's header (i.e. that layer's service has been performed), we strip the header and proceed to process the next higher layer. * A layer should carry its protocol identifier, protocol version number, and whatever other information is needed to process the control information of that layer. Now starting from the bottom, we have MPLS or IP which are identifiable and carry in their headers all the information they need for their functionality (addresses, service classes, TTLs, etc). Next we look at the IP type or MPLS PID and discover that we have a PW (yes, I know that we haven't yet defined a IP-type for PW, and MPLS PIDs are not yet defined, but I am talking about what we want to have). At this point the IP or MPLS header has been stripped since the PSN layer has performed its service, and we should process the PW information (as admirably described in the architecture doc) based on the contents of the PWE CW. This service having been performed, the PW-type should now tell us what encap we have, and the CW should be stripped. In particular, the CW may indicate that RTP is being used, and after the CW is stripped this could be processed. Of course, the RTP-type would refer to whatever payload is above it. Now, we COULD perform a short-cut, whereby we decide that there is no such thing as a purely generic PW, rather there are atm-PWs, ethernet-PWs, fr-PWs, sonet-PWs, and TDM-PWs. In that case we need to define 5 MPLS-PIDs or IP-types; but we would still put the CW next (although we could now allow different CW formats). If instead, we decide to have the IP-type or MPLS PID refer to RTP, and have the RTP-type equal PW, then we have completely divorced those PWs using RTP from the mainstream of PWE. In particular, those PWs for which RTP is optional now have two completely separate instantiations. BOTTOM LINE By placing the RTP info first, we are implying that it is a lower layer which services the PW, rather than being a higher layer option. Since RTP comes first, it will perform its sequencing, timing and whatever functions, before we even know we are talking about a PW. The PW has lost control over this functionality. By placing the RTP after the PSN layers, the processing of those PWs which use it becomes divorced from that of all other PW types. We thus need to start talking about two types of entities, PWs, and RTP-PWs, with completely different network processing. The previous point shows that sequencing and timing are performed at different layers, we now see that all super-PSN layer processing is different. Do we really want to add this complexity for RTP which is only used by two drafts, and even there optional? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 10:15:41 +0200 Lines: 131 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 10:49:38 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, Please see some comments inline. Hopefully they will clarify the situation. 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: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, May 01, 2003 8:21 AM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > Sasha, > > > Just for the reference: Axerra develops, produces and sells > > an edge device that handles multiple PW types. Some of the > supported PWs use RTP and > > some don't. And, so far, we have not experienced any problem due to > > different encapsulations. > > Yes, I know that you have such capabilities. > However, the fact that a problem CAN be addressed using a certain > set of constraints, doesn't mean that these constraints are useful. > I agree and I am happy to see that you accept this principle. E.g., the fact that TDM traffic CAN be carried across a PSN a an AAL1 cell stream does not mean that the AAL1-imposed constrains (like inability to work with packetoization delay that is a multiple of 125 mirocseconds etc.) are useful. IMO, they are not, > > For example, as we all know CESoPSN uses a completely > different control word from the "standard" one used in > atm-encap, fr-encap, etc. > > > Now, assuming that your device really handles multiple PWE > encap types > (and not, for instance, simply transporting frame relay > inside a TDM timeslot > which really isn't handling multiple PWE types) > I can assure you that the Axerra device really carries FR, HDLC and Ethernet frames in the corresponding PWs. > > then you have to first "know" which PWE type the incoming packet is, > before handing it off to the appropriate encap handler. > > This knowledge is apparently in the configuration based on the label > or IP destination address, or some other non-PWE layer. > This is exactly the function of the demultilexing layer in the PWE protocol stack. That is what the VC label/L2TPv3 Session ID etc. exist. Please note that this function is required regardless of multiple PW types/encpaulations (sorry for having to state an obvious fact). As the result, each incoming packet is forwarded to its specific IWF instance for further processing (Sequencing, Synchronization, playout etc.) > > So although your device may handle multiple PWE types, > your use of different CWs forces you to handle them separately, > needlessly duplicating hardware and software. > I think that different services require different IWF logic. In particular, I do not think that you need jitter buffer and clock recovery for FR or HDLC, while these blocks are necessary for TDM PWs. > ... snipped ... > > In pure terms, a "PWE chip" should be able to receive > a packet containing any PWE type (or at least any type it > was designed to handle) and be able to process it. > By processing I mean, at very least to be able to > strip and check the CW, performing sequencing, timing, > error detection, etc. as relevant. It would then send the > payload to wherever. > Since requirements for these functions are quite different, pushing their implementation in one monolothic block looks like a very bad design decision indeed. > ... snipped ... > > > IMO, an attempt to insert a (possibly suppressed) > > RTP header between the CW and the payload would > > make such a chip really complicated. > > Quite the contrary. > > Some PWs need RTP, others don't. > We need to first uniquely determine that the packet is > a PWE packet (that should determined by the "type" in the > previous layer, > i.e. MPLS PID, IP type, etc). Then this packet would be passed > I am not sure I understand what "IP Type" you refer to. And, IMHO you have lost completely the meaning of MPLS PID. It is NOT used by the PEs - only by the core routers to distinguish between IPv4/IPv6 and non-IP packets. That is why the PEs MAY be configured to omit it if the core routers are known not to use ECMP. Once the packet has reached the PE, it is switched to the appropriate upper layers according to one of several demultiplexing mechanisms: o In case of an MPLS demultiplexing layer - according to the VC label o In case of IP/L2TPv3 (as defined by the Protocol Type in the IPv4 header) - - according to the Session ID value o In case of IP/UDP - according to the UDP destination port ec. > > to the "PWE chip". This chip must first determine which PWE type > we have and handle all common PWE functionality. > > Only then, if the PWE type supports RTP, and RTP is determined > to be in use, should the RTP information be extracted and used. > > Any other order is not only more complex, > it is a clear layer violation (more on that in another email). > I do not see any layer violation here. But I promise to read your next mail. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 11:47:47 +0300 Lines: 27 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , "Andrew G. Malis" , X-From: pwe3-admin@ietf.org Thu May 01 10:54:26 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) Thread-Index: AcMPse+BkWmDSB9VSr27PS9/du5nVwACmH3Q To: "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h418qC803692 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I do not see any layer violation here. But I promise to read > your next mail. There are many problems. For example, take a look at Ron's ASCII art diagram. Of the three sublayers of the encapsulation layer, you can clearly see that the middle one (timing) has been farmed out to a lower layer. This means that the timing performs a service for the sequencing, and is performed before this sequencing. But the sequencing MUST be checked before timing recovery is attempted, since packets may be mssing or mis-ordered. Additionally, between the PW demux layer and the encapsulation layer, we now have a new layer. As my previous email discussed, it is not allowed to have direct connection between layers N and N+2, and thus the RTP sunders the PW mechanisms. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 1 May 2003 11:14:11 +0200 Lines: 97 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , pwe3@ietf.org, "Andrew G. Malis" X-From: pwe3-admin@ietf.org Thu May 01 11:46:46 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, As promised, I have read this mail also. Please see some comments inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, May 01, 2003 9:58 AM > To: Andrew G. Malis; Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > Andy, > ... snipped... > > From a purely architectural point of view the order is clearly wrong. > ... snipped ... > > * Each layer performs a service for the layer directly above it. > > * Working inwards on a packet we reach higher layers. > After we have finished processing the layer's header > (i.e. that layer's service has been performed), > we strip the header and proceed to process the next higher layer. > > * A layer should carry its protocol identifier, protocol > version number, > and whatever other information is needed to process the control > information of that layer. > AFAIK, MPLS does not have version numbers and protocol identifiers in its data plane. Nor does it carry any global addresses. > > Now starting from the bottom, we have MPLS or IP > which are identifiable and carry in their headers > all the information they need for their functionality > (addresses, service classes, TTLs, etc). > > Next we look at the IP type or MPLS PID > and discover that we have a PW > (yes, I know that we haven't yet defined a IP-type > for PW, and MPLS PIDs are not yet defined, > but I am talking about what we want to have). > No, we most definitely do NOT want it. MPLS PID is a NOT processed by the PEs terminating the PW, and we do NOT define a new Protocol Type for PWs in IP. And, in any case, the MPLS PID is below the VC label which uniquely defines the egress PW IWF instance, so all your fine theory is broken completely at this point. > > At this point the IP or MPLS header has been stripped > Once more: an MPLS label stack includes both the PSN and the PW demultiplexing function (the latter is implemented via the VC label). > > since the PSN layer has performed its service, > and we should process the PW information > (as admirably described in the architecture doc) > based on the contents of the PWE CW. > This service having been performed, > the PW-type should now tell us what > encap we have, and the CW should be stripped. > You may have missed the fact that all the PE encapsulations do not carry any service type indicators in their data plane. And the architecture documnet is well-alighed with this fact. Draft-anavi is the only exception to that rule, but then it violates other PWE3 architectural principles as well. > ... snipped ... > > Now, we COULD perform a short-cut, > whereby we decide that there is no such thing as > a purely generic PW, > Indeed, there is no such thing - definitely not in the architecture draft. And I think it is the correct approach. Instead, the architecture drfat refers to generic functions and generic payload types. IMO, your "explanation" demonstrates that your private "PWE3 architecture" does not have much in common with the WG-adopted one. > ... snipped to the end ... From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 1 May 2003 13:24:35 +0300 Lines: 76 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , X-From: pwe3-admin@ietf.org Thu May 01 12:30:31 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcMPyDBOnooplC/3TFKjZiyOB685EwAAb2yA To: "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41AU6809456 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > AFAIK, MPLS does not have version numbers and protocol identifiers > in its data plane. Nor does it carry any global addresses. The addresses are only global in connectionless networks, they are local in CO networks. The use of protocol identifiers and version numbers are part of the OSI layer model (see X.200). I am aware that MPLS is not YET using an identifier. > No, we most definitely do NOT want it. > MPLS PID is a NOT processed by the PEs terminating > the PW, and we do NOT define a new Protocol Type for > PWs in IP. And, in any case, the MPLS PID is below the VC label > which uniquely defines the egress PW IWF instance, so all > your fine theory is broken completely at this point. The present term is PW label (or interworking label in ITU-speak). This label is used to enable the use of multiple PWs in a tunnel, and so is in the correct place. > > > > At this point the IP or MPLS header has been stripped > > > Once more: an MPLS label stack includes both the PSN > and the PW demultiplexing function (the latter is implemented > via the VC label). The outer/tunnel/transport labels are stripped when the PSN service is completed, leaving the inner/PW/interworking label. > You may have missed the fact that all the PE encapsulations > do not carry any service type indicators in their data plane. And > the architecture documnet is well-alighed with this fact. I have complained about this omission in the past. > Draft-anavi is the only exception to that rule, but then it > violates other PWE3 architectural principles as well. 1) I am not aware of any PWE document where ii is stated that the use of an indicator is an architecture violation. 2) What other "violations" ? > ... snipped ... > > > > Now, we COULD perform a short-cut, > > whereby we decide that there is no such thing as > > a purely generic PW, > > > Indeed, there is no such thing - definitely not in > the architecture draft. And I think it is the correct approach. > Instead, the architecture drfat refers to generic functions and > generic payload types. > IMO, your "explanation" demonstrates that your private > "PWE3 architecture" does not have much in common with > the WG-adopted one. The IETF is not always a stickler for pure architectural principles, and our WG is no exception. However, I have never heard it stated that good architectural design is not allowed in the IETF. Our WG has already designed another new layer (in addition to the already added "layer 2.5" of the MPLS) and we have to realize that this layer needs to properly placed and interfaced with the other layers. My "private architecture" is simply an attempt to add some coherence to the new layers we are adding. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 13:27:42 +0300 Lines: 76 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , "Andrew G. Malis" , X-From: pwe3-admin@ietf.org Thu May 01 12:35:26 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) Thread-Index: AcMPy7bxCn5QswmXSiKryLwHpyYqJAAAEY/w To: "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41AWK809523 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I agree that it CAN provide sequencing, but the CW has a sequence number as well, which is the standard PWE method of sequencing. The use of RTP adds an additional NON-PWE sequence number, and various suggestions have been given on how to align the two numbers (e.g. use the LSBs, etc). Unfortunately, the two are NOT alignable because of the standard PWE sequence number processes (skipping zero) so the problem remains. Y(J)S > -----Original Message----- > From: Alexander Vainshtein > Sent: Thursday, May 01, 2003 2:20 PM > To: Yaakov Stein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > Yaakov and all, > Please note that RTP provides BOTH sequencing and > synchronization services. This is why there is no layer > violation in Ron's diagram. > > 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: Yaakov Stein [mailto:yaakov_s@rad.com] > > Sent: Thursday, May 01, 2003 10:48 AM > > To: Sasha Vainshtein > > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > > G. Malis; pwe3@ietf.org > > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > > > > > > I do not see any layer violation here. But I promise to read > > > your next mail. > > > > > > There are many problems. > > > > For example, take a look at Ron's ASCII art diagram. > > > > Of the three sublayers of the encapsulation layer, > > you can clearly see that the middle one (timing) > > has been farmed out to a lower layer. > > This means that the timing performs a service > > for the sequencing, and is performed before > > this sequencing. > > > > But the sequencing MUST be checked before > > timing recovery is attempted, since packets may > > be mssing or mis-ordered. > > > > Additionally, between the PW demux layer and the > > encapsulation layer, we now have a new layer. > > As my previous email discussed, > > it is not allowed to have direct connection between layers > N and N+2, > > and thus the RTP sunders the PW mechanisms. > > > > Y(J)S > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 13:20:24 +0200 Lines: 51 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 14:12:10 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, Please note that RTP provides BOTH sequencing and synchronization services. This is why there is no layer violation in Ron's diagram. 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: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, May 01, 2003 10:48 AM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > > I do not see any layer violation here. But I promise to read > > your next mail. > > > There are many problems. > > For example, take a look at Ron's ASCII art diagram. > > Of the three sublayers of the encapsulation layer, > you can clearly see that the middle one (timing) > has been farmed out to a lower layer. > This means that the timing performs a service > for the sequencing, and is performed before > this sequencing. > > But the sequencing MUST be checked before > timing recovery is attempted, since packets may > be mssing or mis-ordered. > > Additionally, between the PW demux layer and the > encapsulation layer, we now have a new layer. > As my previous email discussed, > it is not allowed to have direct connection between layers N and N+2, > and thus the RTP sunders the PW mechanisms. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 1 May 2003 14:27:35 +0200 Lines: 83 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 14:36:36 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, Please see some responses inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, May 01, 2003 12:25 PM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > > AFAIK, MPLS does not have version numbers and protocol identifiers > > in its data plane. Nor does it carry any global addresses. > > The addresses are only global in connectionless networks, > they are local in CO networks. > > The use of protocol identifiers and version numbers > are part of the OSI layer model (see X.200). > I am aware that MPLS is not YET using an identifier. > AFAIK, nobody is going to retrofit the Internet and to use it for IP traffic. AND nobody is going to use it with PWs that utilize the generic PWE3 CW. AND there is no protocol version in the MPLS stack either. I suggest to take further discussioin of the differences between the OSI layering model and IP or MPLS off this list (if you are interested). > > > No, we most definitely do NOT want it. > > MPLS PID is a NOT processed by the PEs terminating > > the PW, and we do NOT define a new Protocol Type for > > PWs in IP. And, in any case, the MPLS PID is below the VC label > > which uniquely defines the egress PW IWF instance, so all > > your fine theory is broken completely at this point. > > The present term is PW label (or interworking label in ITU-speak). > This label is used to enable the use of multiple PWs > in a tunnel, and so is in the correct place. > I do not know what exactly the "interworking label" means, and hence I do not want to discuss whether this term is appropriate. However, the archutecture draft defines that the PW (a.k.a. VC) label is the MPLS-specific PW demultiplexer, i.e. the data plane method of of IDENTIFYING the PW by the terminating PE. And if you take a look at the current proposals for distributing this label (in ietf-pwe3-control-protocol-02.txt) you will find out that it is bound to a FEC that includes the type of the emulated service. (BTW, the same holds for L2TPv3) and is allocated from the global device label pool. > ... snipped ... > > > You may have missed the fact that all the PE encapsulations > > do not carry any service type indicators in their data plane. And > > the architecture documnet is well-alighed with this fact. > > I have complained about this omission in the past. > Correct. However, IMO, your complaint has been either ignored or rejected by the WG. > ... snipped ... > > The IETF is not always a stickler for pure architectural principles, > and our WG is no exception. > Please take a look at RFC 1925, especially at item 2 (1). IMO, this is a great architectural principle consistently pursued by the IETF, and this WG is no exception. I also recommend for your attention item 2 (10) as highlly relevant for this discussion. > ... snipped to the end ... From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 16:49:56 +0300 Lines: 40 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , "Andrew G. Malis" , X-From: pwe3-admin@ietf.org Thu May 01 15:56:34 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) Thread-Index: AcMP51m+Xo5TKge/Q5OzZdnGQxSVFwAAA0ag To: "Akiva Sadovski" , "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41DuP800895 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Akiva, > AFAIK skipping zero in sequence number processing isn't mentioned in > framework/architecture drafts. Correct, but that is the way the non-RTP drafts handle it. I have no problem with changing that, but as the situation stands we have an incompatibility. > Support for sequencing depends on the payload type, and may be > omitted if not needed. For example, Frame Relay always > requires the preservation of packet order. However, where the Frame > Relay service is only being used to carry IP, it may be desirable to relax that > constraint in return for reduced per-packet processing cost. > > [RTP] or encapsulation-specific sequence numbers may be used for > sequencing. That's great news, but unfortunately the FR draft does not use RTP, so there is no way of using RTP sequence numbers either. I guess this misunderstanding has something to do with Axerra's private architecture for PWE (universal RTP) which has little in common with the WG-adopted one. (Akiva - please forgive the jab - I couldn't resist). > Have i missed smth ? No, I think that the IETF has missed something. Had the MPLS WG ensured ordered delivery (as would be logical from a purely architecural point of view) we wouldn't be in such a fix, and wouldn't now be putting together such strange structures. The way it stands we HAVE to have a consistent sequencing method. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 09:53:35 -0400 Lines: 68 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 16:01:42 2003 Return-path: To: "'Sasha Vainshtein'" , "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > Yaakov and all, > Please note that RTP provides BOTH sequencing and > synchronization services. This is why there is no layer > violation in Ron's diagram. > > 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: Yaakov Stein [mailto:yaakov_s@rad.com] > > > I do not see any layer violation here. But I promise to read > > > your next mail. > > > > > > There are many problems. > > > > For example, take a look at Ron's ASCII art diagram. > > > > Of the three sublayers of the encapsulation layer, > > you can clearly see that the middle one (timing) > > has been farmed out to a lower layer. > > This means that the timing performs a service > > for the sequencing, and is performed before > > this sequencing. > > > > But the sequencing MUST be checked before > > timing recovery is attempted, since packets may > > be mssing or mis-ordered. > > It seems to me that the truth lies in the middle. Some elements of the Control Word (the first nibble, fragmentation bits and sequence numbers) clearly belong to the PW layer and should immediately follow the PW Label. Other elements (protocol specific flags and pointers) clearly belong to the payload and should immediately preceed the payload. In case RTP is used, it should sit in between. Lets call 'first nibble + fragmentation bits + sequence numbers': CW-PW, and 'flags + pointers': CW-PL, and let's assume that RTP sits in between. Since RTP provides sequencing, the sequence numbers in CW-PW could be eliminated, which reduces CW-PW to the first nibble plus fragmentation bits. However, this would mean that CW-PW is practically identical to the MPLS PID. Conclusion: The order MPLS PID - RTP Header - CW doesn't seem like a severe layer violation. That said, I do think that the current drafts would benefit from a more narrow specification of the use of sequence numbers (i.e. I think that an encapsulation with two sequence numbers should be avoided) and fragmentation (it is still not clear to me whether it could be supported, as the architecture draft says, or not) Peter > > Additionally, between the PW demux layer and the > > encapsulation layer, we now have a new layer. > > As my previous email discussed, > > it is not allowed to have direct connection between layers > N and N+2, > > and thus the RTP sunders the PW mechanisms. > > > > Y(J)S > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: TTL value of VC Label? Date: Thu, 01 May 2003 14:56:04 +0100 Organization: Cisco Systems, Inc. Lines: 36 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 16:06:22 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Yaron Nachman Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O We changed it to the value 2 This is large enough that it will always get delivered even in a PHP system, small enough that it goes the minimum distance if accidentally released as a top label, and requires no special checking. Stewart Yaron Nachman wrote: > Hi, > > I have just noticed that in the yesterday-updated > draft-martini-l2circuit-encap-mpls-05.txt, the TTL value to be placed by an > Ingress LER on the VC Label is 2. > I have noticed in the past that it was changed to 255. > > So, is it 2 or 255? or even some other value?? > > Thanks, > > Yaron Nachman > > SEABRIDGE Ltd. > Tel: 972-9-7751359 > Fax: 972-9-7751212 > E-mail: yaron.nachman@SeabridgeNetworks.com > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 1 May 2003 17:11:48 +0300 Lines: 86 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , X-From: pwe3-admin@ietf.org Thu May 01 16:17:10 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Arch sections 5.4.3 and 5.4.4 Thread-Index: AcMP1SCMJPbp3IzcTM+xx9yme7CH8wAE+IgQ To: "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41EGU807033 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > AFAIK, nobody is going to retrofit the Internet and to use it for IP traffic. I'm not quite sure I understand this statement. > AND nobody is going to use it with PWs that utilize the > generic PWE3 CW. Why not? As a matter of fact a lot of people are just waiting to try this stuff our on IP networks. And it they aren't why is the IETF working on this? > AND there is no protocol version in the MPLS stack either. > I suggest to take further discussioin of the differences between the > OSI layering model and IP or MPLS off this list (if you are interested). Sorry if I have offended anyone by talking about architectural design. > I do not know what exactly the "interworking label" means, See, e.g. ITU-T recommendation Y.1411 > and hence I do not want to discuss whether this term is appropriate. > However, the archutecture draft defines that the PW (a.k.a. VC) VC label was the old (ATM-speak) label. Luca has promised to erradicate it from all the drafts over which he has control; I suggest the rest of us do as well. > label is the MPLS-specific PW demultiplexer, i.e. the data plane > method of of IDENTIFYING the PW by the terminating PE. > And if you take a look at the current proposals for distributing > this label (in ietf-pwe3-control-protocol-02.txt) you will > find out that it is bound to a FEC that includes the type of the emulated service. Precisely my point. The fact that this is the ONLY place where the encap type is mentioned is problematic (see my previous email about the problems with making a "PWE chip"). Of course the encap type needs to be mentioned during set-up, making it available to the forwardin layer, since the LSP may need to be tailored for the service requirements. However, it should also be available to the PW layer, both for architectural and practical reasons. However, as you will recall, I was willing to compromise on this in the past, for example, allowing the set-up to dictate the major type (atm, fr, tdm, etc) and the FORMID determine the minor type (1:1vs N:1, AAL1 vs AAL2, etc). > (BTW, the same holds for L2TPv3) and is allocated from the > global device label pool. Good point. Where do you suggest putting the RTP for the L2TP case? > > > You may have missed the fact that all the PE encapsulations > > > do not carry any service type indicators in their data plane. And > > > the architecture documnet is well-alighed with this fact. > > > > I have complained about this omission in the past. > > > Correct. However, IMO, your complaint has been either ignored sigh. > or rejected by the WG. I haven't heard rejection, so I guess the former is the case. But then again, my whole CW crusade was ignored for a year, but then came to life. So I haven't lost hope. > Please take a look at RFC 1925, especially at item 2 (1). > IMO, this is a great architectural principle consistently pursued > by the IETF, and this WG is no exception. > I also recommend for your attention item 2 (10) as highlly relevant > for this discussion. I re-read this RFC precisely one month ago (on April fools day), and think that the more relevant principle is 2(6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 01 May 2003 15:27:52 +0100 Organization: Cisco Systems, Inc. Lines: 153 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Yaakov Stein'" , Sasha Vainshtein , Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 16:39:50 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Akiva Sadovski Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O From Section 5.4.3: Sequence number (Bit 16 to 31): If the sequence number is not used, it is set to zero by the sender and ignored by the receiver. Otherwise it specifies the sequence number of a packet. A circular list of sequence numbers is used. A sequence number takes a value from 1 to 65535 (2**16-1). Akiva Sadovski wrote: > Hi, Yaakov and all, > > AFAIK skipping zero in sequence number processing isn't mentioned in > framework/architecture drafts. > > Framework: > > 3.5.2.2. Sequencing > > Support for sequencing depends on the payload type, and may be > omitted if not needed. For example, Frame Relay always requires the > preservation of packet order. However, where the Frame Relay service > is only being used to carry IP, it may be desirable to relax that > constraint in return for reduced per-packet processing cost. > > [RTP] or encapsulation-specific sequence numbers may be used for > sequencing. > > > > Architecture: > > > 5.2.1. Sequencing > > The sequencing function provides three services: frame ordering, > frame duplication detection and frame loss detection. These services > allow the emulation of the invariant properties of a physical wire. > Support for sequencing depends on the payload type, and MAY be > omitted if not needed. > > The size of the sequence-number space depends on the speed of the > emulated service, and the maximum time of the transient conditions in > the PSN. A sequence number space greater than 2^16 may therefore be > needed to prevent the sequence number space wrapping during the > transient. > > > Have i missed smth ? > > thanks, > Akiva Sadovski > > >>-----Original Message----- >>From: Yaakov Stein [mailto:yaakov_s@rad.com] >>Sent: Thursday, May 01, 2003 12:28 PM >>To: Sasha Vainshtein >>Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew >>G. Malis; pwe3@ietf.org >>Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) >> >> >>I agree that it CAN provide sequencing, >>but the CW has a sequence number as well, >>which is the standard PWE method of sequencing. >> >>The use of RTP adds an additional NON-PWE sequence number, >>and various suggestions have been given on how to align >>the two numbers (e.g. use the LSBs, etc). Unfortunately, >>the two are NOT alignable because of the standard PWE >>sequence number processes (skipping zero) >>so the problem remains. >> >>Y(J)S >> >> >> >>>-----Original Message----- >>>From: Alexander Vainshtein >>>Sent: Thursday, May 01, 2003 2:20 PM >>>To: Yaakov Stein >>>Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew >>>G. Malis; pwe3@ietf.org >>>Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) >>> >>> >>>Yaakov and all, >>>Please note that RTP provides BOTH sequencing and >>>synchronization services. This is why there is no layer >>>violation in Ron's diagram. >>> >>>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: Yaakov Stein [mailto:yaakov_s@rad.com] >>>>Sent: Thursday, May 01, 2003 10:48 AM >>>>To: Sasha Vainshtein >>>>Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew >>>>G. Malis; pwe3@ietf.org >>>>Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) >>>> >>>> >>>> >>>> >>>>>I do not see any layer violation here. But I promise to read >>>>>your next mail. >>>> >>>> >>>>There are many problems. >>>> >>>>For example, take a look at Ron's ASCII art diagram. >>>> >>>>Of the three sublayers of the encapsulation layer, >>>>you can clearly see that the middle one (timing) >>>>has been farmed out to a lower layer. >>>>This means that the timing performs a service >>>>for the sequencing, and is performed before >>>>this sequencing. >>>> >>>>But the sequencing MUST be checked before >>>>timing recovery is attempted, since packets may >>>>be mssing or mis-ordered. >>>> >>>>Additionally, between the PW demux layer and the >>>>encapsulation layer, we now have a new layer. >>>>As my previous email discussed, >>>>it is not allowed to have direct connection between layers >>> >>>N and N+2, >>> >>>>and thus the RTP sunders the PW mechanisms. >>>> >>>>Y(J)S >>>> >>> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 17:34:15 +0300 Lines: 48 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , "Andrew G. Malis" , X-From: pwe3-admin@ietf.org Thu May 01 16:45:14 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) Thread-Index: AcMP6RNtdvHqB9pOQRqgVpKrABLAcgABMWLg To: "Busschbach, Peter B (Peter)" , "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41Eco812400 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, > It seems to me that the truth lies in the middle. > Some elements of the Control Word (the first nibble, > fragmentation bits and sequence numbers) clearly belong to > the PW layer and should immediately follow the PW Label. > Other elements (protocol specific flags and pointers) clearly > belong to the payload and should immediately preceed the > payload. In case RTP is used, it should sit in between. > > Lets call 'first nibble + fragmentation bits + sequence > numbers': CW-PW, and 'flags + pointers': CW-PL, > and let's assume that RTP sits in between. > Since RTP provides sequencing, the sequence > numbers in CW-PW could be eliminated, I would agree with this, were it not for the fact that most of the drafts do NOT use RTP. So it makes more sense to eliminate the RTP sequence number. > which reduces CW-PW to > the first nibble plus fragmentation bits. However, this would > mean that CW-PW is practically identical to the MPLS PID. My conclusion exactly. > Conclusion: The order MPLS PID - RTP Header - CW doesn't seem > like a severe layer violation. But what if the sequence number IS there, since we want to use a unified PWE mechanism for which we build a single unifed "PWE chip" ? > > That said, I do think that the current drafts would benefit > from a more narrow specification of the use of sequence > numbers (i.e. I think that an encapsulation with two sequence > numbers should be avoided) Conclusion: RTP is impractical for PWs ? > and fragmentation (it is still not > clear to me whether it could be supported, as the > architecture draft says, or not) Probably not, and that's probably a good thing too. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 1 May 2003 07:23:28 -0700 Lines: 151 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 16:57:33 2003 Return-path: To: "'Yaakov Stein'" , "Andrew G. Malis" , Alexander Vainshtein X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I tend to agree with Yaakov. Since the multiplexing layer (aka PW label) carries the context information for the PW payload (i.e, CW+ TDM payload) such as type of PW traffic T1, SONET, etc, it seems that in Ron's suggested layering (RTP preceding CW), a client layer (ie. multiplexing layer) is controlling 2 layers below it (ie, the TDM PW). While usually a client layer should control only its immediate server layer, which in this case would be RTP. While, if the RTP is placed after the CW, then the PW label would correctly control its payload which is the TDM PW. So what are the implications: By placing RTP before the CW, in effect we are decoupling the PW from the service that it carries. In other words now all services (like SONET, T1, E1, T3, E3, etc) that use RTP could be effectively transported across the same PW. Because RTP would be doing the job of the service multiplexing not PW label. This is clearly not in line with Arch draft that says: " From the perspective of a Customer Edge Equipment (CE), the PW is characterized as an unshared link or circuit of the chosen service" The above discussion was architectural issues. There is also implementation complexity associated with placing RTP before CW. By doing so, a PE would need to parse and process each PW packet differently. In other words for some PW packets the MPLS engine needs to forward the packet to PW engine and for some other PW types the MPLS engine needs to forward the packet to RTP engine and then from RTP engine to PW engine: RTP > RTP ^ v / | | | / v MPLS --> PW or MPLS --> CW This has 2 problems: 1) The parser now needs to be dynamic in order to find the CW. 1) In the latter case a kind of internal switching (to RTP or CW) needs to be required which would require context lookup. So my vote is to have RTP after the CW and have a consistent PW format and architecture for all PW types. -Shahram >-----Original Message----- >From: Yaakov Stein [mailto:yaakov_s@rad.com] >Sent: Thursday, May 01, 2003 3:58 AM >To: Andrew G. Malis; Alexander Vainshtein >Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); pwe3@ietf.org >Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > >Andy, > >Yes, I know that RTP has been that way all along, >and as you have probably noticed, I have been going along with it. > >In all the anavi drafts I have also put the RTP >between the PSN layers and the control word. >I guess I should claim temporary insanity, >but the real reason is that I never saw RTP to be needed, >and thus never really thought too much about it. > >However, I was awakened by the thought of having >this anomaly sanctioned in a document called >the PWE ARCHITECTURE draft. > >From a purely architectural point of view the order is clearly wrong. > >Let me explain, using the OSI layering model >(in G.805 layer network terms it is even worse, >but I think that the OSI terminology is more >familiar to most of readers of this list). > >* Each layer performs a service for the layer directly above it. > >* Working inwards on a packet we reach higher layers. >After we have finished processing the layer's header >(i.e. that layer's service has been performed), >we strip the header and proceed to process the next higher layer. > >* A layer should carry its protocol identifier, protocol >version number, >and whatever other information is needed to process the control >information of that layer. > >Now starting from the bottom, we have MPLS or IP >which are identifiable and carry in their headers >all the information they need for their functionality >(addresses, service classes, TTLs, etc). > >Next we look at the IP type or MPLS PID >and discover that we have a PW >(yes, I know that we haven't yet defined a IP-type >for PW, and MPLS PIDs are not yet defined, >but I am talking about what we want to have). > >At this point the IP or MPLS header has been stripped >since the PSN layer has performed its service, >and we should process the PW information >(as admirably described in the architecture doc) >based on the contents of the PWE CW. >This service having been performed, >the PW-type should now tell us what >encap we have, and the CW should be stripped. > >In particular, the CW may indicate that RTP is being used, >and after the CW is stripped this could be processed. >Of course, the RTP-type would refer to whatever >payload is above it. > >Now, we COULD perform a short-cut, >whereby we decide that there is no such thing as >a purely generic PW, rather there are atm-PWs, >ethernet-PWs, fr-PWs, sonet-PWs, and TDM-PWs. >In that case we need to define 5 MPLS-PIDs or IP-types; >but we would still put the CW next >(although we could now allow different CW formats). > >If instead, we decide to have the IP-type or MPLS PID >refer to RTP, and have the RTP-type equal PW, >then we have completely divorced those PWs using RTP >from the mainstream of PWE. In particular, >those PWs for which RTP is optional >now have two completely separate instantiations. > >BOTTOM LINE > >By placing the RTP info first, we are implying >that it is a lower layer which services the PW, >rather than being a higher layer option. >Since RTP comes first, it will perform its sequencing, >timing and whatever functions, before we even know >we are talking about a PW. >The PW has lost control over this functionality. > >By placing the RTP after the PSN layers, >the processing of those PWs which use it >becomes divorced from that of all other PW types. >We thus need to start talking about two types >of entities, PWs, and RTP-PWs, >with completely different network processing. >The previous point shows that sequencing and >timing are performed at different layers, >we now see that all super-PSN layer processing is different. > >Do we really want to add this complexity for >RTP which is only used by two drafts, >and even there optional? > >Y(J)S > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 07:38:01 -0700 Lines: 24 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 17:02:44 2003 Return-path: To: "'Sasha Vainshtein'" , "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >I am not sure I understand what "IP Type" you refer to. >And, IMHO you have lost completely the meaning of MPLS PID. >It is NOT used by the PEs - only by the core routers to distinguish >between IPv4/IPv6 and non-IP packets. That is why the PEs MAY >be configured >to omit it if the core routers are known not to use ECMP. >Once the packet has reached the PE, it is switched to the appropriate >upper layers according to one of several demultiplexing mechanisms: >o In case of an MPLS demultiplexing layer - according to the VC label >o In case of IP/L2TPv3 (as defined by the Protocol Type in the >IPv4 header) Sasha, I think it is you who has completely misunderstood the meaning of MPLS PID word that should precede the CW. The proposed MPLS PID, carries the Payload ID of the PW not just identifying it as being IP or not. If it was only meant for intermediate routers, then we would have set the last bytes of the MPLS PID word to Reserved not to PPP-PID or Ethertype or anything else. But it seems that people want to define a proper MPLS PID that would be used by PEs. In fact only the first nibble of MPLS PID word is used by intermediate routers, which effectively does not carry any PID info. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 07:54:08 -0700 Lines: 21 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 17:11:19 2003 Return-path: To: "'Sasha Vainshtein'" , "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Sasha, I think it is you who has completely misunderstood the >> meaning of >> MPLS PID word that should precede the CW. The proposed MPLS >> PID, carries the >> Payload ID of the PW not just identifying it as being IP or not. >> >Would it be so, the MPLS PID would be mandatory for all the PWs. >Since it is not, your reasoning looks faulty. >> MPLS PID being mandatory or optional does not change the fact the the actual protocol identifier of MPLS PID is used by PEs and not intermediate routers. So I am not sure what is faulty here? Besides I think it should be made mandatory for PWE3 (i.e, non IP payload), because you never know for sure whether a PW may cross an ECMP network or not. -Shahram -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Akiva Sadovski Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 16:38:08 +0200 Lines: 133 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 17:12:21 2003 Return-path: To: "'Yaakov Stein'" , Sasha Vainshtein X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, Yaakov and all, AFAIK skipping zero in sequence number processing isn't mentioned in framework/architecture drafts. Framework: 3.5.2.2. Sequencing Support for sequencing depends on the payload type, and may be omitted if not needed. For example, Frame Relay always requires the preservation of packet order. However, where the Frame Relay service is only being used to carry IP, it may be desirable to relax that constraint in return for reduced per-packet processing cost. [RTP] or encapsulation-specific sequence numbers may be used for sequencing. Architecture: 5.2.1. Sequencing The sequencing function provides three services: frame ordering, frame duplication detection and frame loss detection. These services allow the emulation of the invariant properties of a physical wire. Support for sequencing depends on the payload type, and MAY be omitted if not needed. The size of the sequence-number space depends on the speed of the emulated service, and the maximum time of the transient conditions in the PSN. A sequence number space greater than 2^16 may therefore be needed to prevent the sequence number space wrapping during the transient. Have i missed smth ? thanks, Akiva Sadovski > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, May 01, 2003 12:28 PM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > I agree that it CAN provide sequencing, > but the CW has a sequence number as well, > which is the standard PWE method of sequencing. > > The use of RTP adds an additional NON-PWE sequence number, > and various suggestions have been given on how to align > the two numbers (e.g. use the LSBs, etc). Unfortunately, > the two are NOT alignable because of the standard PWE > sequence number processes (skipping zero) > so the problem remains. > > Y(J)S > > > > -----Original Message----- > > From: Alexander Vainshtein > > Sent: Thursday, May 01, 2003 2:20 PM > > To: Yaakov Stein > > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > > G. Malis; pwe3@ietf.org > > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > > > Yaakov and all, > > Please note that RTP provides BOTH sequencing and > > synchronization services. This is why there is no layer > > violation in Ron's diagram. > > > > 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: Yaakov Stein [mailto:yaakov_s@rad.com] > > > Sent: Thursday, May 01, 2003 10:48 AM > > > To: Sasha Vainshtein > > > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > > > G. Malis; pwe3@ietf.org > > > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > > > > > > > > > > I do not see any layer violation here. But I promise to read > > > > your next mail. > > > > > > > > > There are many problems. > > > > > > For example, take a look at Ron's ASCII art diagram. > > > > > > Of the three sublayers of the encapsulation layer, > > > you can clearly see that the middle one (timing) > > > has been farmed out to a lower layer. > > > This means that the timing performs a service > > > for the sequencing, and is performed before > > > this sequencing. > > > > > > But the sequencing MUST be checked before > > > timing recovery is attempted, since packets may > > > be mssing or mis-ordered. > > > > > > Additionally, between the PW demux layer and the > > > encapsulation layer, we now have a new layer. > > > As my previous email discussed, > > > it is not allowed to have direct connection between layers > > N and N+2, > > > and thus the RTP sunders the PW mechanisms. > > > > > > Y(J)S > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Akiva Sadovski Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 17:26:28 +0200 Lines: 78 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 17:21:53 2003 Return-path: To: "'Yaakov Stein'" , Sasha Vainshtein X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, Sasha and all, short comments inline... Best, Akiva > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, May 01, 2003 3:50 PM > To: Akiva Sadovski; Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > Akiva, > > > AFAIK skipping zero in sequence number processing isn't > mentioned in > > framework/architecture drafts. > > Correct, but that is the way the non-RTP drafts handle it. > I have no problem with changing that, > but as the situation stands we have an incompatibility. > > > Support for sequencing depends on the payload type, and may be > > omitted if not needed. For example, Frame Relay always > > requires the preservation of packet order. However, > where the Frame > > Relay service is only being used to carry IP, it may be > desirable to relax that > > constraint in return for reduced per-packet processing cost. > > > > [RTP] or encapsulation-specific sequence numbers may be used for > > sequencing. > > That's great news, but unfortunately the FR draft does not use RTP, > so there is no way of using RTP sequence numbers either. I agree with you. So: those who don't use RTP (FR, ATM, HDLC, Ethernet) may use any suitable sequence number processing (f.ex. zero skipping) those who use RTP have no problem with RTP and CW sequence numbers synchronisation; therefore RTP can be considered as a valid Sequencing layer (for those who use RTP, sure) > > I guess this misunderstanding has something to do with > Axerra's private architecture for PWE (universal RTP) As far as i'm familar with Axerra's implementation there's no universal RTP there. Frame Relay is RTP-free and we have no problems with it. > which has little in common with the WG-adopted one. > (Akiva - please forgive the jab - I couldn't resist). > > > > > Have i missed smth ? > > No, I think that the IETF has missed something. > > Had the MPLS WG ensured ordered delivery > (as would be logical from a purely architecural point of view) > we wouldn't be in such a fix, and wouldn't now be putting together > such strange structures. > > The way it stands we HAVE to have a consistent sequencing method. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: TTL value of VC Label? Date: Thu, 01 May 2003 10:55:42 -0400 Lines: 15 Sender: pwe3-admin@ietf.org References: <3EB12774.5060301@cisco.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 17:21:55 2003 Return-path: To: stbryant@cisco.com In-reply-to: Your message of Thu, 01 May 2003 14:56:04 +0100. <3EB12774.5060301@cisco.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart> We changed it to the value 2 I don't think this is a good idea. Suppose one of the two attachment circuits bound together by a pw is itself a pw. Now you'd like ordinary MPLS switching to be able to move the packet from one pw to the other, but the TTL of 2 will prevent this from happening. The "Distributed VPLS" model also gives rise to a number of cases in which one wants to splice together two pws. I don't think there should be any requirement on the setting of the TTL value. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Alik Shimelmits Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 17:34:37 +0200 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 18:03:15 2003 Return-path: To: Yaakov Stein , Akiva Sadovski , Sasha Vainshtein X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O ...snipped > I guess this misunderstanding has something to do with > Axerra's private architecture for PWE (universal RTP) > which has little in common with the WG-adopted one. > (Akiva - please forgive the jab - I couldn't resist). Yaakov, first, I have to say that you are NOT familiar with the Axerra architecture. (that what I would expect because you do NOT work in Axerra.) Just for the reference - Axerra does not use and never used RTP to carry frame relay (as well as ATM and ethernet). second, it is amazing that, being a strong pusher for universal RTP suppression, you invest so much effort into discussion of placement of the RTP header. (forgive the jab ...) Alik > Have i missed smth ? No, I think that the IETF has missed something. Had the MPLS WG ensured ordered delivery (as would be logical from a purely architecural point of view) we wouldn't be in such a fix, and wouldn't now be putting together such strange structures. The way it stands we HAVE to have a consistent sequencing method. Y(J)S _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Akiva Sadovski Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 1 May 2003 17:42:31 +0200 Lines: 109 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 18:16:32 2003 Return-path: To: Sasha Vainshtein , "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and Sasha, short question inline... thanks, Akiva > -----Original Message----- > From: Sasha Vainshtein > Sent: Thursday, May 01, 2003 2:28 PM > To: 'Yaakov Stein' > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > Yaakov and all, > Please see some responses inline. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > Sent: Thursday, May 01, 2003 12:25 PM > > To: Sasha Vainshtein > > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); pwe3@ietf.org > > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > > > > > > AFAIK, MPLS does not have version numbers and protocol identifiers > > > in its data plane. Nor does it carry any global addresses. > > > > The addresses are only global in connectionless networks, > > they are local in CO networks. > > > > The use of protocol identifiers and version numbers > > are part of the OSI layer model (see X.200). > > I am aware that MPLS is not YET using an identifier. > > > AFAIK, nobody is going to retrofit the Internet and to use it for IP > traffic. > AND nobody is going to use it with PWs that utilize the > generic PWE3 CW. > AND there is no protocol version in the MPLS stack either. > I suggest to take further discussioin of the differences between the > OSI layering model and IP or MPLS off this list (if you are > interested). > > > > > No, we most definitely do NOT want it. > > > MPLS PID is a NOT processed by the PEs terminating > > > the PW, and we do NOT define a new Protocol Type for > > > PWs in IP. And, in any case, the MPLS PID is below the VC label > > > which uniquely defines the egress PW IWF instance, so all > > > your fine theory is broken completely at this point. > > > > The present term is PW label (or interworking label in ITU-speak). > > This label is used to enable the use of multiple PWs > > in a tunnel, and so is in the correct place. > > > I do not know what exactly the "interworking label" means, and > hence I do not want to discuss whether this term is appropriate. > However, the archutecture draft defines that the PW (a.k.a. VC) > label is the MPLS-specific PW demultiplexer, i.e. the data plane > method of of IDENTIFYING the PW by the terminating PE. > And if you take a look at the current proposals for distributing > this label (in ietf-pwe3-control-protocol-02.txt) you will > find out that > it is bound to a FEC that includes the type of the emulated service. > (BTW, the same holds for L2TPv3) and is allocated from the > global device label pool. Does a PHP system "see" (and process) VC label ? > > > ... snipped ... > > > > > You may have missed the fact that all the PE encapsulations > > > do not carry any service type indicators in their data plane. And > > > the architecture documnet is well-alighed with this fact. > > > > I have complained about this omission in the past. > > > Correct. However, IMO, your complaint has been either ignored > or rejected > by the WG. > > > ... snipped ... > > > > The IETF is not always a stickler for pure architectural principles, > > and our WG is no exception. > > > Please take a look at RFC 1925, especially at item 2 (1). > IMO, this is a great architectural principle consistently pursued > by the IETF, and this WG is no exception. > I also recommend for your attention item 2 (10) as highlly relevant > for this discussion. > > > ... snipped to the end ... > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 17:43:02 +0200 Lines: 44 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 18:24:36 2003 Return-path: To: "'Shahram Davari'" , "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sharham, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, May 01, 2003 4:38 PM > To: Sasha Vainshtein; 'Yaakov Stein' > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > >I am not sure I understand what "IP Type" you refer to. > >And, IMHO you have lost completely the meaning of MPLS PID. > >It is NOT used by the PEs - only by the core routers to distinguish > >between IPv4/IPv6 and non-IP packets. That is why the PEs MAY > >be configured > >to omit it if the core routers are known not to use ECMP. > >Once the packet has reached the PE, it is switched to the appropriate > >upper layers according to one of several demultiplexing mechanisms: > >o In case of an MPLS demultiplexing layer - according to the VC label > >o In case of IP/L2TPv3 (as defined by the Protocol Type in the > >IPv4 header) > > Sasha, I think it is you who has completely misunderstood the > meaning of > MPLS PID word that should precede the CW. The proposed MPLS > PID, carries the > Payload ID of the PW not just identifying it as being IP or not. > Would it be so, the MPLS PID would be mandatory for all the PWs. Since it is not, your reasoning looks faulty. > ... skipped to the end ... From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 18:17:12 +0200 Lines: 41 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org, "'Yaakov Stein'" X-From: pwe3-admin@ietf.org Thu May 01 18:27:42 2003 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, Please see inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, May 01, 2003 4:54 PM > To: Sasha Vainshtein; 'Yaakov Stein' > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > Sasha, I think it is you who has completely misunderstood the > >> meaning of > >> MPLS PID word that should precede the CW. The proposed MPLS > >> PID, carries the > >> Payload ID of the PW not just identifying it as being IP or not. > >> > >Would it be so, the MPLS PID would be mandatory for all the PWs. > >Since it is not, your reasoning looks faulty. > >> > > MPLS PID being mandatory or optional does not change the fact the > the actual protocol identifier of MPLS PID is used by PEs and not > intermediate routers. So I am not sure what is faulty here? > I have been taught that, when facts contradict a theory, the facts win, and the theory is faulty. Since the MPLS PID issue in PWs is about 1 month old, and MPLS PWs are already implemented and deployed, I conclude that PEs neither need nor use the PID information. > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 19:19:33 +0300 Lines: 15 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , "Andrew G. Malis" , X-From: pwe3-admin@ietf.org Thu May 01 18:41:07 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) Thread-Index: AcMP/MPJEV2MHCUsQCu/YaVnzDeoSQAAGlzA To: "Alexander Vainshtein" , "Shahram Davari" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41GX1807847 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I have been taught that, when facts contradict a theory, the > facts win, and the theory is faulty. > Since the MPLS PID issue in PWs is about 1 month old, and > MPLS PWs are already implemented and deployed, I conclude that PEs neither > need nor use the PID information. I have been taught that many schemes seem to work at first, but then get bogged down. I teach that it is better to think things through first, rather than build a new system that will become burdened with problems within a few years. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 19:17:04 +0300 Lines: 24 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Ron Cohen" , "Tim Frost (E-mail)" , "Andrew G. Malis" , X-From: pwe3-admin@ietf.org Thu May 01 18:47:39 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) Thread-Index: AcMP/MCchg6KSIAPQ0qBOEFW+z5Y6AAAAaBw To: "Alik Shimelmits" , "Akiva Sadovski" , "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h41Gct809278 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > I guess this misunderstanding has something to do with > > Axerra's private architecture for PWE (universal RTP) > > which has little in common with the WG-adopted one. > > (Akiva - please forgive the jab - I couldn't resist). > > Yaakov, > first, I have to say that you are NOT familiar with the > Axerra architecture. Never claimed to be. I just assumed that, based on vehement past support of RTP. > (that what I would expect because you do NOT work in Axerra.) > Just for the reference - Axerra does not use and never used > RTP to carry frame relay (as well as ATM and ethernet). > second, it is amazing that, being a strong pusher for universal > RTP suppression, you invest so much effort into discussion of > placement of the RTP header. > (forgive the jab ...) touche Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Thu, 1 May 2003 19:32:27 +0200 Lines: 103 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 18:52:15 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, A few comments inlune. 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: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, May 01, 2003 4:12 PM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); pwe3@ietf.org > Subject: RE: [PWE3] Arch sections 5.4.3 and 5.4.4 > > > > AFAIK, nobody is going to retrofit the Internet and to use > it for IP traffic. > > I'm not quite sure I understand this statement. > In this particular case it means that nobody will change thousands of deployed LSRs that carry IP traffic without any MPLS PID even if this is required by X.200. > > > AND nobody is going to use it with PWs that utilize the > > generic PWE3 CW. > > Why not? As a matter of fact a lot of people are just waiting > to try this stuff our on IP networks. And it they aren't > why is the IETF working on this? > FYI, people are already running PWs over IP and MPLS networks, including MPLS networks that implement ECMP. And they do it without using MPLS PID. > ... skipped ... > > > And if you take a look at the current proposals for distributing > > this label (in ietf-pwe3-control-protocol-02.txt) you will > > find out that it is bound to a FEC that includes the type > of the emulated service. > > Precisely my point. > The fact that this is the ONLY place where the encap type is > mentioned is problematic (see my previous email about the problems > with making a "PWE chip"). > Somehow no vendor that has implemented multiple PW types has noticed these problems. These icnlude Cisco, Juniper, Laurel, Vivace etc. So I think this discussion becomes too theoretic for my taste. > > Of course the encap type needs to be mentioned during set-up, > making it available to the forwardin layer, > since the LSP may need to be tailored for the service requirements. > Please read draft-ietf-pwe3-contol-protocol-02.txt. > > However, it should also be available to the PW layer, > both for architectural and practical reasons. > However, as you will recall, I was willing to compromise > on this in the past, for example, allowing the set-up to dictate > the major type (atm, fr, tdm, etc) and the FORMID > determine the minor type (1:1vs N:1, AAL1 vs AAL2, etc). > A PW connects to PW end services of the same type. AFAIK, there is no major and minor types in the PWE3 architecture. Presumably because no one needs them. > > > (BTW, the same holds for L2TPv3) and is allocated from the > > global device label pool. > > Good point. Where do you suggest putting the RTP for the L2TP case? > Immediately after the L2TP (v3) header. > ... snipped ... > > > Please take a look at RFC 1925, especially at item 2 (1). > > IMO, this is a great architectural principle consistently pursued > > by the IETF, and this WG is no exception. > > I also recommend for your attention item 2 (10) as highlly relevant > > for this discussion. > > I re-read this RFC precisely one month ago (on April fools day), > and think that the more relevant principle is 2(6) > > It is easier to move a problem around (for example, by moving > the problem to a different part of the overall network > architecture) > than it is to solve it. > I suggest we hold a side discussion on comparative importance and relevance of principles from RFC 1925 off the list. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Alik Shimelmits Subject: RE: TTL value of VC Label? Date: Thu, 1 May 2003 19:47:06 +0200 Lines: 30 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 18:55:19 2003 Return-path: To: erosen@cisco.com, stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I agree with Eric Alik -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Thursday, May 01, 2003 4:56 PM To: stbryant@cisco.com Cc: Yaron Nachman; 'pwe3@ietf.org'; Eli Angel; Ilya Vershkov Subject: Re: [PWE3] TTL value of VC Label? Stewart> We changed it to the value 2 I don't think this is a good idea. Suppose one of the two attachment circuits bound together by a pw is itself a pw. Now you'd like ordinary MPLS switching to be able to move the packet from one pw to the other, but the TTL of 2 will prevent this from happening. The "Distributed VPLS" model also gives rise to a number of cases in which one wants to splice together two pws. I don't think there should be any requirement on the setting of the TTL value. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: Arch sections 5.4.3 and 5.4.4 Date: Thu, 01 May 2003 18:57:01 +0100 Organization: Cisco Systems, Inc. Lines: 11 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Sasha Vainshtein , "'Yaakov Stein'" , Ron Cohen , "Tim Frost (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 01 20:03:52 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Akiva Sadovski Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > > Does a PHP system "see" (and process) VC label ? > > Yes, it may see it as the top (only) label. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Wei Luo Subject: Re: TTL value of VC Label? Date: Thu, 01 May 2003 11:08:02 -0700 Lines: 50 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 20:14:05 2003 Return-path: X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN To: Alik Shimelmits Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O In the PW splicing scenario, it's not really the same as normal MPLS switching. Typically, one PW is terminated at the splicing PE and another (different PW) is initiated. This means packets arrived from one PW will remove its current PW encapsulation, e.g. tunnel and vc labels, and then add a new PW encapsulation. In this way, it allows the data path to have a unified packet processing behavior regardless what PW encapsulation is used in each leg. For example, MPLS PW - MPLS PW, MPLS PW - L2TP PW, L2TP PW - MPLS PW, L2TP PW - L2TP PW can all have the same data plane implementation, instead of one flavor for a different combination. I am speaking of what's more suitable from implementation point of view. In the PW splicing case, the TTL of 2 would work. Of course, simply specifying it anything larger than 2 would work too. ---Wei Alik Shimelmits wrote: > > I agree with Eric > Alik > > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Thursday, May 01, 2003 4:56 PM > To: stbryant@cisco.com > Cc: Yaron Nachman; 'pwe3@ietf.org'; Eli Angel; Ilya Vershkov > Subject: Re: [PWE3] TTL value of VC Label? > > Stewart> We changed it to the value 2 > > I don't think this is a good idea. > > Suppose one of the two attachment circuits bound together by a pw is itself > a pw. Now you'd like ordinary MPLS switching to be able to move the packet > from one pw to the other, but the TTL of 2 will prevent this from > happening. > > The "Distributed VPLS" model also gives rise to a number of cases in which > one wants to splice together two pws. > > I don't think there should be any requirement on the setting of the TTL > value. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Vach Kompella" Subject: RE: TTL value of VC Label? Date: Thu, 1 May 2003 11:29:52 -0700 Lines: 76 Sender: pwe3-admin@ietf.org References: <3EB16282.C9BA713B@cisco.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , , "Yaron Nachman" , , "Eli Angel" , "Ilya Vershkov" X-From: pwe3-admin@ietf.org Thu May 01 20:37:36 2003 Return-path: To: "Wei Luo" , "Alik Shimelmits" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <3EB16282.C9BA713B@cisco.com> X-OriginalArrivalTime: 01 May 2003 18:29:43.0376 (UTC) FILETIME=[A2862500:01C3100F] Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I too would like to see the value not specified as 2. Splicing PWs as a L2 service and still having a TTL is a secondary security against loops for a service that extends beyond the scope of the tunnel. It also provides nice "traceroute" capabilities, with L2 service aware nodes handling TTL expiration. -Vach > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Wei > Luo > Sent: Thursday, May 01, 2003 11:08 AM > To: Alik Shimelmits > Cc: erosen@cisco.com; stbryant@cisco.com; Yaron Nachman; > 'pwe3@ietf.org'; Eli Angel; Ilya Vershkov > Subject: Re: [PWE3] TTL value of VC Label? > > > In the PW splicing scenario, it's not really the same as normal MPLS > switching. > Typically, one PW is terminated at the splicing PE and another > (different PW) is > initiated. This means packets arrived from one PW will remove its current PW > encapsulation, e.g. tunnel and vc labels, and then add a new PW > encapsulation. > In this way, it allows the data path to have a unified packet processing > behavior regardless what PW encapsulation is used in each leg. For example, > MPLS PW - MPLS PW, MPLS PW - L2TP PW, L2TP PW - MPLS PW, L2TP PW - L2TP PW can > all have the same data plane implementation, instead of one flavor for a > different combination. I am speaking of what's more suitable from > implementation point of view. > > In the PW splicing case, the TTL of 2 would work. Of course, simply > specifying > it anything larger than 2 would work too. > > ---Wei > > Alik Shimelmits wrote: > > > > I agree with Eric > > Alik > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Thursday, May 01, 2003 4:56 PM > > To: stbryant@cisco.com > > Cc: Yaron Nachman; 'pwe3@ietf.org'; Eli Angel; Ilya Vershkov > > Subject: Re: [PWE3] TTL value of VC Label? > > > > Stewart> We changed it to the value 2 > > > > I don't think this is a good idea. > > > > Suppose one of the two attachment circuits bound together by a pw is itself > > a pw. Now you'd like ordinary MPLS switching to be able to move the packet > > from one pw to the other, but the TTL of 2 will prevent this from > > happening. > > > > The "Distributed VPLS" model also gives rise to a number of cases in which > > one wants to splice together two pws. > > > > I don't think there should be any requirement on the setting of the TTL > > value. > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: TTL value of VC Label? Date: Thu, 01 May 2003 14:52:19 -0400 Lines: 14 Sender: pwe3-admin@ietf.org References: <3EB16282.C9BA713B@cisco.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Alik Shimelmits , stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 20:58:18 2003 Return-path: To: Wei Luo In-reply-to: Your message of Thu, 01 May 2003 11:08:02 -0700. <3EB16282.C9BA713B@cisco.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Wei> packets arrived from one PW will remove its current PW encapsulation, Wei> e.g. tunnel and vc labels, and then add a new PW encapsulation. In Wei> this way, it allows the data path to have a unified packet processing Wei> behavior regardless what PW encapsulation is used in each leg. I guess I don't agree. If you're splicing together two MPLS pseudowires, you should be able to use existing MPLS forwarding hardware, and just do ordinary MPLS label replacement with ordinary MPLS TTL processing. In fact, even in the case where you are moving from one encapsulation to another I think you want to make sure that the outgoing TTL is one less than the incoming TTL, in order to maintain the usual loop detection functionality of TTL. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Skip Booth Subject: Re: TTL value of VC Label? Date: Thu, 1 May 2003 15:07:20 -0400 (Eastern Daylight Time) Lines: 42 Sender: pwe3-admin@ietf.org References: <200305011852.h41IqJWS008325@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Wei Luo , Alik Shimelmits , stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 21:13:17 2003 Return-path: To: Eric Rosen In-Reply-To: <200305011852.h41IqJWS008325@rtp-core-1.cisco.com> X-Warning: UNAuthenticated Sender Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O On Thu, 1 May 2003, Eric Rosen wrote: > > Wei> packets arrived from one PW will remove its current PW encapsulation, > Wei> e.g. tunnel and vc labels, and then add a new PW encapsulation. In > Wei> this way, it allows the data path to have a unified packet processing > Wei> behavior regardless what PW encapsulation is used in each leg. > > I guess I don't agree. If you're splicing together two MPLS pseudowires, > you should be able to use existing MPLS forwarding hardware, and just do > ordinary MPLS label replacement with ordinary MPLS TTL processing. Not quite true as you would want to go through the control word processing including any sequence number options. This isn't straight MPLS forwarding IMO. There's probably a degenerate case where you could handle this like straight MPLS forwarding though, but that shouldn't be the base assumption. > > In fact, even in the case where you are moving from one encapsulation to > another I think you want to make sure that the outgoing TTL is one less than > the incoming TTL, in order to maintain the usual loop detection > functionality of TTL. I tend to agree here. I guess the question is whether the TTL's meaning is really end to end, i.e AC to AC, or per PW hop. It probably has more value meaning end to end so that a service provider could limit the number of PW splices that occur for the end to end service. However, it's more difficult to map the VC label TTL into the IP header TTL for AToM to L2TP tunnel splicing. They certainly aren't treated exactly the same way by the intermediate P routers. -Skip > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: TTL value of VC Label? Date: Thu, 01 May 2003 15:14:52 -0400 Lines: 10 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Wei Luo , Alik Shimelmits , stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 21:19:16 2003 Return-path: To: Skip Booth In-reply-to: Your message of Thu, 01 May 2003 15:07: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) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eric> If you're splicing together two MPLS pseudowires, you should be able Eric> to use existing MPLS forwarding hardware, and just do ordinary MPLS Eric> label replacement with ordinary MPLS TTL processing. Skip> Not quite true as you would want to go through the control word Skip> processing including any sequence number options. I don't think so, the control word processing should only be done at the ultimate endpoint, there's no point to doing it multiple times. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Skip Booth Subject: Re: TTL value of VC Label? Date: Thu, 1 May 2003 15:23:04 -0400 (Eastern Daylight Time) Lines: 30 Sender: pwe3-admin@ietf.org References: <200305011914.h41JErWS015315@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Wei Luo , Alik Shimelmits , stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 21:41:58 2003 Return-path: To: Eric Rosen In-Reply-To: <200305011914.h41JErWS015315@rtp-core-1.cisco.com> X-Warning: UNAuthenticated Sender Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O On Thu, 1 May 2003, Eric Rosen wrote: > > Eric> If you're splicing together two MPLS pseudowires, you should be able > Eric> to use existing MPLS forwarding hardware, and just do ordinary MPLS > Eric> label replacement with ordinary MPLS TTL processing. > > Skip> Not quite true as you would want to go through the control word > Skip> processing including any sequence number options. > > I don't think so, the control word processing should only be done at the > ultimate endpoint, there's no point to doing it multiple times. That may be true for end to end AToM, like to like cases. However, that wouldn't be true for AToM to L2TP tunnel splicing. Nor would it be true for AToM any2any processing if the tunnel splicing box was the a2a enforcement point. Also, even for the like2like case, it may be important to do the sequencing checks at the tunnel-splicer just to provide the diagnostic information needed to determine where the sequencing errors are occurring. This could translate into a billing issue if there was packet loss as a result of sequence errors. It's certainly a service issue which needs to be diagnosed in the appropriate part of the network. -Skip > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: TTL value of VC Label? Date: Thu, 01 May 2003 15:43:18 -0400 Lines: 18 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Wei Luo , Alik Shimelmits , stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 21:47:44 2003 Return-path: To: Skip Booth In-reply-to: Your message of Thu, 01 May 2003 15:23:04 -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) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Skip> it may be important to do the sequencing checks at the tunnel-splicer Skip> just to provide the diagnostic information needed to determine where Skip> the sequencing errors are occurring. I don't think so, the scalability problems that arise from doing pseudowire-specific processing at intermediate nodes far outweigh any possible diagnostic value of this technique. In a multi-provider environment, each provider will probably want to be able to gather the data it needs to blame the other, but gathering this data in the forwarding plane of the border routers does not seem like a good idea to me. Skip> This could translate into a billing issue if there was packet loss as Skip> a result of sequence errors. Billing based on the number of packets per pseudowire that arrive at various points in the network over some period of time seems a bit far-fetched to me. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Skip Booth Subject: Re: TTL value of VC Label? Date: Thu, 1 May 2003 16:07:17 -0400 (Eastern Daylight Time) Lines: 33 Sender: pwe3-admin@ietf.org References: <200305011943.h41JhJWS023799@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Wei Luo , Alik Shimelmits , stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 22:14:28 2003 Return-path: To: Eric Rosen In-Reply-To: <200305011943.h41JhJWS023799@rtp-core-1.cisco.com> X-Warning: UNAuthenticated Sender Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O On Thu, 1 May 2003, Eric Rosen wrote: > > Skip> it may be important to do the sequencing checks at the tunnel-splicer > Skip> just to provide the diagnostic information needed to determine where > Skip> the sequencing errors are occurring. > > I don't think so, the scalability problems that arise from doing > pseudowire-specific processing at intermediate nodes far outweigh any > possible diagnostic value of this technique. In a multi-provider > environment, each provider will probably want to be able to gather the data > it needs to blame the other, but gathering this data in the forwarding plane > of the border routers does not seem like a good idea to me. I don't think either of us are really wrong. I imagine different SPs would give you different answers. The forwarding path will most likely have to support both, if for no other reason than the interworking and AToM to L2TP cases I mentioned earlier. In my experience with L2TP tunnel splicing, the per PW features and accounting information was something that SPs wanted. Time will tell whether that's the case for AToM. -Skip > > Skip> This could translate into a billing issue if there was packet loss as > Skip> a result of sequence errors. > > Billing based on the number of packets per pseudowire that arrive at various > points in the network over some period of time seems a bit far-fetched to > me. > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Thu, 1 May 2003 14:06:26 -0700 Lines: 17 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org, "'Yaakov Stein'" X-From: pwe3-admin@ietf.org Thu May 01 23:15:15 2003 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >> MPLS PID being mandatory or optional does not change the fact the >> the actual protocol identifier of MPLS PID is used by PEs and not >> intermediate routers. So I am not sure what is faulty here? >> >I have been taught that, when facts contradict a theory, the facts win, >and the theory is faulty. >Since the MPLS PID issue in PWs is about 1 month old, and MPLS PWs are >already implemented and deployed, I conclude that PEs neither >need nor use >the PID information. Sasha, You are missing the point. The point is that if MPLS PID exists, then PEs identify the payload by PID in the MPLS PID word. If not then they have to rely on the signaled PID. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Chris Metz Subject: Re: TTL value of VC Label? Date: Thu, 01 May 2003 14:10:13 -0700 Lines: 34 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Skip Booth , Wei Luo , Alik Shimelmits , stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 01 23:20:57 2003 Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: erosen@cisco.com In-Reply-To: <200305011943.h41JhJWS023799@rtp-core-1.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 03:43 PM 5/1/2003 -0400, Eric Rosen wrote: >Skip> it may be important to do the sequencing checks at the tunnel-splicer >Skip> just to provide the diagnostic information needed to determine where >Skip> the sequencing errors are occurring. > >I don't think so, the scalability problems that arise from doing >pseudowire-specific processing at intermediate nodes far outweigh any >possible diagnostic value of this technique. In a multi-provider >environment, each provider will probably want to be able to gather the data >it needs to blame the other, but gathering this data in the forwarding plane >of the border routers does not seem like a good idea to me. > >Skip> This could translate into a billing issue if there was packet loss as >Skip> a result of sequence errors. > >Billing based on the number of packets per pseudowire that arrive at various >points in the network over some period of time seems a bit far-fetched to >me. Two providers sharing an inter-AS link (independent of whether these are PW or IP packets) at an exchange point may establish a paid peering relationship based on the amount of traffic exchanged. So counting PW packets that cross AS boundaries may be a requirement. Cheers ... >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Wei Luo Subject: Re: TTL value of VC Label? Date: Thu, 01 May 2003 15:23:57 -0700 Lines: 26 Sender: pwe3-admin@ietf.org References: <200305011852.h41IqJWS008325@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alik Shimelmits , stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Fri May 02 00:34:57 2003 Return-path: X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN To: Skip Booth , Eric Rosen Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > In fact, even in the case where you are moving from one encapsulation to > > another I think you want to make sure that the outgoing TTL is one less than > > the incoming TTL, in order to maintain the usual loop detection > > functionality of TTL. > > I tend to agree here. I guess the question is whether the TTL's meaning is > really end to end, i.e AC to AC, or per PW hop. It probably has more value > meaning end to end so that a service provider could limit the number of PW > splices that occur for the end to end service. However, it's more difficult to > map the VC label TTL into the IP header TTL for AToM to L2TP tunnel splicing. > They certainly aren't treated exactly the same way by the intermediate P > routers. It's a "surprise" how quickly we switched topic on the thread :-). At any rate, having an end-to-end TTL is more valuable than per-PW segement TTL. Therefore, a fixed TTL value should not be imposed on the VC label if we expect to have features like "traceroute" or "loop prevention". I would agree not to specify a fixed value for the VC label TTL. As for mapping TTL from MPLS to L2TP, it's definitely not a good idea to map the VC labe TTL to the IP header TTL, as the IP header TTL has a semantics of Layer-3 IP hops. Instead, it should be mapped to a TTL field in L2TP header, either the session header or the L2-specific sublayer, none of which has such a field currently. ---Wei From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Chris Metz Subject: Re: TTL value of VC Label? Date: Thu, 01 May 2003 12:06:11 -0700 Lines: 28 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stbryant@cisco.com, Yaron Nachman , "'pwe3@ietf.org'" , Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Fri May 02 01:20:57 2003 Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: erosen@cisco.com In-Reply-To: <200305011455.h41EthWS007477@rtp-core-1.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 10:55 AM 5/1/2003 -0400, Eric Rosen wrote: >Stewart> We changed it to the value 2 > >I don't think this is a good idea. > >Suppose one of the two attachment circuits bound together by a pw is itself >a pw. Now you'd like ordinary MPLS switching to be able to move the packet >from one pw to the other, but the TTL of 2 will prevent this from >happening. Yes, this case could arise. Conceivably per-AS PWs could be spliced together at ASBR-PEs forming an inter-AS PW. It looks like the PW packet could never move beyond the first PW (due to ttl=0). Cheers ... >The "Distributed VPLS" model also gives rise to a number of cases in which >one wants to splice together two pws. > >I don't think there should be any requirement on the setting of the TTL >value. >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Olen Stokes Subject: RE: TTL value of VC Label? Date: Thu, 1 May 2003 17:16:18 -0700 Lines: 116 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: erosen@cisco.com, stbryant@cisco.com, Yaron Nachman , pwe3@ietf.org, Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Fri May 02 02:25:36 2003 Return-path: To: "'vkompella@timetra.com'" , Wei Luo , Alik Shimelmits X-Mailer: Internet Mail Service (5.5.2655.55) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O As Vach says, being able to set the TTL to something other than 2 is very important to being able to provide a "traceroute" capability (in addition to protection against loops). Cheers, Olen > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetra.com] > Sent: Thursday, May 01, 2003 2:30 PM > To: Wei Luo; Alik Shimelmits > Cc: erosen@cisco.com; stbryant@cisco.com; Yaron Nachman; > pwe3@ietf.org; > Eli Angel; Ilya Vershkov > Subject: RE: [PWE3] TTL value of VC Label? > > > I too would like to see the value not specified as 2. > Splicing PWs as a L2 > service and still having a TTL is a secondary security > against loops for a > service that extends beyond the scope of the tunnel. It also > provides nice > "traceroute" capabilities, with L2 service aware nodes > handling TTL expiration. > > -Vach > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On > Behalf Of Wei > > Luo > > Sent: Thursday, May 01, 2003 11:08 AM > > To: Alik Shimelmits > > Cc: erosen@cisco.com; stbryant@cisco.com; Yaron Nachman; > > 'pwe3@ietf.org'; Eli Angel; Ilya Vershkov > > Subject: Re: [PWE3] TTL value of VC Label? > > > > > > In the PW splicing scenario, it's not really the same as normal MPLS > > switching. > > Typically, one PW is terminated at the splicing PE and another > > (different PW) is > > initiated. This means packets arrived from one PW will > remove its current PW > > encapsulation, e.g. tunnel and vc labels, and then add a new PW > > encapsulation. > > In this way, it allows the data path to have a unified > packet processing > > behavior regardless what PW encapsulation is used in each > leg. For example, > > MPLS PW - MPLS PW, MPLS PW - L2TP PW, L2TP PW - MPLS PW, > L2TP PW - L2TP PW can > > all have the same data plane implementation, instead of one > flavor for a > > different combination. I am speaking of what's more suitable from > > implementation point of view. > > > > In the PW splicing case, the TTL of 2 would work. Of course, simply > > specifying > > it anything larger than 2 would work too. > > > > ---Wei > > > > Alik Shimelmits wrote: > > > > > > I agree with Eric > > > Alik > > > > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: Thursday, May 01, 2003 4:56 PM > > > To: stbryant@cisco.com > > > Cc: Yaron Nachman; 'pwe3@ietf.org'; Eli Angel; Ilya Vershkov > > > Subject: Re: [PWE3] TTL value of VC Label? > > > > > > Stewart> We changed it to the value 2 > > > > > > I don't think this is a good idea. > > > > > > Suppose one of the two attachment circuits bound > together by a pw is itself > > > a pw. Now you'd like ordinary MPLS switching to be able > to move the packet > > > from one pw to the other, but the TTL of 2 will > prevent this from > > > happening. > > > > > > The "Distributed VPLS" model also gives rise to a number > of cases in which > > > one wants to splice together two pws. > > > > > > I don't think there should be any requirement on the > setting of the TTL > > > value. > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: TTL value of VC Label? Date: Fri, 02 May 2003 09:00:15 +0100 Organization: Cisco Systems, Inc. Lines: 15 Sender: pwe3-admin@ietf.org References: <82F679A6A377F84B8F665D8F90D12B8DD8F2AA@sc-msexch-05.extremenetworks.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'vkompella@timetra.com'" , Wei Luo , Alik Shimelmits , erosen@cisco.com, Yaron Nachman , pwe3@ietf.org, Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Fri May 02 10:12:31 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Olen Stokes Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I could delete the TTL = 2 completely, but there was some discussion on the list that caused me to add it in the first place, so how about either something of the form: "Ideally the TTL should be a small value to prevent the looping of PW packets in misconfigured or malfunctioning MPLS networks. In choosing a suitable TTL value, the user should give consideration to any PHP systems and concatonated PWs." If it needs to be any more complex than this, I will just delete the sentence. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Brian Hassink" Subject: RE: TTL value of VC Label? Date: Fri, 2 May 2003 06:44:47 -0400 Lines: 40 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Cc: , "Wei Luo" , "Alik Shimelmits" , , "Yaron Nachman" , , "Eli Angel" , "Ilya Vershkov" X-From: pwe3-admin@ietf.org Fri May 02 12:52:26 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] TTL value of VC Label? Thread-Index: AcMQgv3HAxCmAcZYTdq3ZNt0JWpfcgAE3hPt To: , "Olen Stokes" X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h42Aq4810678 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shouldn't the usage of TTL with respect to VC labels be specified in one of the architectural or functional drafts so that the scenarios and their issues can be fully explored, and best common practices can be specified (some of which has been done in this thread)? The MIB should take its queue from this specification, not do it itself. If there's ambiguity in the MIB, then something hasn't been properly specified in the architectural or functional drafts. Cheers, Brian -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Fri 5/2/2003 4:00 AM To: Olen Stokes Cc: 'vkompella@timetra.com'; Wei Luo; Alik Shimelmits; erosen@cisco.com; Yaron Nachman; pwe3@ietf.org; Eli Angel; Ilya Vershkov Subject: Re: [PWE3] TTL value of VC Label? I could delete the TTL = 2 completely, but there was some discussion on the list that caused me to add it in the first place, so how about either something of the form: "Ideally the TTL should be a small value to prevent the looping of PW packets in misconfigured or malfunctioning MPLS networks. In choosing a suitable TTL value, the user should give consideration to any PHP systems and concatonated PWs." If it needs to be any more complex than this, I will just delete the sentence. Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Olen Stokes Subject: RE: TTL value of VC Label? Date: Fri, 2 May 2003 05:44:24 -0700 Lines: 74 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Cc: vkompella@timetra.com, Wei Luo , Alik Shimelmits , erosen@cisco.com, Yaron Nachman , pwe3@ietf.org, Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Fri May 02 14:54:49 2003 Return-path: To: "'Brian Hassink'" , stbryant@cisco.com, Olen Stokes X-Mailer: Internet Mail Service (5.5.2655.55) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I would be happy with a statement that says when used in a point-to-point PW environment, the TTL should be set to 2. This could be combined with a statement that says when used in other environments, such as concatenated PWs, the setting shall be as specified in the standards defining those environments. For example, in draft "draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt," we defined a method for setting the TTL and also how the TTL is to be handled as it passes between the concatenated PWs. Cheers, Olen > -----Original Message----- > From: Brian Hassink [mailto:BHassink@HatterasNetworks.com] > Sent: Friday, May 02, 2003 6:45 AM > To: stbryant@cisco.com; Olen Stokes > Cc: vkompella@timetra.com; Wei Luo; Alik Shimelmits; erosen@cisco.com; > Yaron Nachman; pwe3@ietf.org; Eli Angel; Ilya Vershkov > Subject: RE: [PWE3] TTL value of VC Label? > > > Shouldn't the usage of TTL with respect to VC labels be > specified in one of the architectural or functional drafts so > that the scenarios and their issues can be fully explored, > and best common practices can be specified (some of which has > been done in this thread)? > > The MIB should take its queue from this specification, not do > it itself. If there's ambiguity in the MIB, then something > hasn't been properly specified in the architectural or > functional drafts. > > Cheers, > Brian > > > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Fri 5/2/2003 4:00 AM > To: Olen Stokes > Cc: 'vkompella@timetra.com'; Wei Luo; Alik Shimelmits; > erosen@cisco.com; Yaron Nachman; pwe3@ietf.org; Eli Angel; > Ilya Vershkov > Subject: Re: [PWE3] TTL value of VC Label? > > > > I could delete the TTL = 2 completely, but there was > some discussion on the list that caused me to add it > in the first place, so how about either something of > the form: > > "Ideally the TTL should be a small value to prevent the > looping of PW packets in misconfigured or malfunctioning > MPLS networks. In choosing a suitable TTL value, the > user should give consideration to any PHP systems and > concatonated PWs." > > If it needs to be any more complex than this, I will > just delete the sentence. > > Stewart > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: TTL value of VC Label? Date: Fri, 02 May 2003 09:06:22 -0400 Lines: 9 Sender: pwe3-admin@ietf.org References: <3EB2258F.8070304@cisco.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Olen Stokes , "'vkompella@timetra.com'" , Wei Luo , Alik Shimelmits , Yaron Nachman , pwe3@ietf.org, Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Fri May 02 15:10:55 2003 Return-path: To: stbryant@cisco.com In-reply-to: Your message of Fri, 02 May 2003 09:00:15 +0100. <3EB2258F.8070304@cisco.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart> I could delete the TTL = 2 completely That would be my preference. Olen> I would be happy with a statement that says when used in a Olen> point-to-point PW environment, the TTL should be set to 2. I would not be happy with this. If your environment gets modified, you shouldn't have to go reconfigure the TTL at all the endpoints. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: David Watkinson Subject: Re: TTL value of VC Label? Date: Fri, 02 May 2003 09:46:54 -0400 Organization: Alcatel Canada Lines: 13 Sender: pwe3-admin@ietf.org References: <82F679A6A377F84B8F665D8F90D12B8DD8F2AA@sc-msexch-05.extremenetworks.com> <3EB2258F.8070304@cisco.com> Reply-To: david.watkinson@alcatel.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Olen Stokes , "'vkompella@timetra.com'" , Wei Luo , Alik Shimelmits , erosen@cisco.com, Yaron Nachman , pwe3@ietf.org, Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Fri May 02 15:51:56 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: stbryant@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Setting the TTL is application dependant. The originating PE will know if the PSN tunnel reaches the destination node for the PW. If it does, a TTL of 2 is sufficient. If it does not, the TTL should probably be set to the configurable default IP TTL to allow for PW stitching. In other cases, for example, DTLS, a TTL of 4 may be needed due to the two additional hops taken between the L2PE and PE at each end. I would suggest the following text to ensure that the various applications using PW's think about this issue:: "Setting the TTL is application dependent." Dave. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: TTL value of VC Label? Date: Fri, 02 May 2003 09:49:06 -0400 Lines: 12 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20030501134606.019e9510@mail1.cisco.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Skip Booth , Wei Luo , "'pwe3@ietf.org'" X-From: pwe3-admin@ietf.org Fri May 02 16:02:09 2003 Return-path: To: Chris Metz In-reply-to: Your message of Thu, 01 May 2003 14:10:13 -0700. <4.3.2.7.2.20030501134606.019e9510@mail1.cisco.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Chris> Two providers sharing an inter-AS link (independent of whether these Chris> are PW or IP packets) at an exchange point may establish a paid Chris> peering relationship based on the amount of traffic exchanged. So Chris> counting PW packets that cross AS boundaries may be a requirement. Yes, but that's not the issue. The issue is the following: if provider A sends 100 packets to provider B, but 50 of them are out of sequence, do they count against the amount of traffic exchanged? Do you think one provider would tell another "I'm not paying for that packet because it is out of sequence?" Maybe the answer depends on whether the cost of doing that check eats up all the savings ;-) From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: Arch sections 5.4.3 and 5.4.4 Date: Fri, 2 May 2003 15:06:32 +0100 Lines: 24 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, ronc@lyciumnetworks.com, Tim.Frost@zarlink.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 02 16:12:19 2003 Return-path: To: Sasha@axerra.com, yaakov_s@rad.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha Vainshtein wrote 01 May 2003 18:32 > > > AND nobody is going to use it with PWs that utilize the > > > generic PWE3 CW. > > > > Why not? As a matter of fact a lot of people are just waiting > > to try this stuff our on IP networks. And it they aren't > > why is the IETF working on this? > > > FYI, people are already running PWs over IP and MPLS networks, > including MPLS networks that implement ECMP. And they do it > without using MPLS PID. NH=> Can you be precise as to which MPLS network type you mean here please? There are several disjoint types of MPLS network, characterised by the fact they don't have consistent (or even conciously recognised) addressed data-plane access points. Being more obvious however, you don't really need ECMP with p2p RSVP-TE LSPs. However, a key observation here is that load-spreading only makes sense *within* a single layer network.....not across them. Think client/server IP to Optics and also in different commercial ownership cases (ie where the client and server layers belong to different organisations) if this helps understand this as a general arch principle, ie load-spreading should be restricted to a single layer network. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Danny McPherson Subject: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 02 May 2003 15:55:57 -0600 Lines: 17 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Sat May 03 00:07:33 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Given that many folks have been quite vocal regarding this, and that this discussion has been trolling on for quite a while now, I think we've reached _rough consensus on how to proceed. On my count the majority of views expressed here support this layering model: MPLS->PW label->MPLS PID->RTP->PW CW->PW Payload We need to move forward with this (as we'd like to have WG LC on the Arch again [again] within a week or two), and although there are arguments both ways, there are no show-stoppers either way. As such, given my perception of consensus on the list, we'll move forward with the the model depicted above, and RTP will immediately precede the CW. An updated version should be posted soon for another round of WG LC. -danny From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Alex Zinin Subject: IMPORTANT: Strategy for VPN work in IETF Date: Sun, 4 May 2003 00:11:52 -0700 Lines: 67 Reply-To: Alex Zinin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Sun May 04 09:13:41 2003 Return-path: X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) To: ppvpn@nortelnetworks.com X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] Status: O Folks, Since San Francisco IETF meeting the IESG has been considering the situation in the SUB-IP area and in the PPVPN Working Group in particular. Such close attention to this WG was triggered by numerous concerns that the IESG members received from the WG participants about limited and slow progress within the WG despite the efforts of the WG chairs and its members. The IESG also used this opportunity to consider the IETF area that the PPVPN work would fit best. After much deliberation, the involved ADs (Bert, Thomas, and I) are considering the following organizational changes in order to improve WG focus and productivity and ensure faster progress of the VPN-related work: 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. The L2 and L3 VPN work spaces are each big enough to warrant a separate WG. While concentration of all VPN-related work in a single forum was the right thing to do to ensure coordination of efforts when the PPVPN WG was created and L2 VPN work came in, such concentration is causing scaling problems within the WG at this moment. Migration of work into two separate WGs for L2 and L3 VPN technologies with more specific WG charters will help to focus discussions, prevent staff and meeting time overloading, and will aid faster progress of corresponding technologies. 2. Migration of the VPN-related work to the Internet area. As previously discussed, VPN-related work could be argued to belong to more than one area. Tunneling mechanisms are the property that gravitates this work to the Internet area, which is where we believe the VPN work should go. As part of this move, we are also considering moving PWE3 into INT, so that L2TPEXT, PWE3, and thew new VPN WGs are operating in the same area. Based on the above considerations, we are considering the following steps: 1. Two new WGs--L2VPN and L3VPN--will be created in the Internet area. The mailing lists will be established and the discussion of the proposed charters of the new WGs will be initiated shortly. 2. Once the charters of the new WGs are agreed upon and approved by the IESG, creation of the L2VPN and L3VPN WGs and shutdown of the PPVPN WG will be performed simultaneously. PPVPN WG documents will be migrated to the corresponding new WGs. It is our intention to complete this process by the Vienna IETF meeting. Also, these changes are being made for management reasons and are not intended to be a "reset" on WG activities or to halt or interrupt progress on current ongoing WG activities. We'd like to hear from the WG members if they see any fatal flaws with the proposed approach. Please send us your feedback by May 11th. Regards, -- Alex Zinin IETF SUB-IP Area Co-Director From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Akiva Sadovski Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Sun, 4 May 2003 14:06:51 +0200 Lines: 53 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org, "'Yaakov Stein'" X-From: pwe3-admin@ietf.org Sun May 04 13:25:07 2003 Return-path: To: "'Shahram Davari'" , Sasha Vainshtein X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, Shahram, a short naive question inside... thanks, Akiva > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, May 01, 2003 11:06 PM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org; 'Yaakov Stein' > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > >> MPLS PID being mandatory or optional does not change the fact the > >> the actual protocol identifier of MPLS PID is used by PEs and not > >> intermediate routers. So I am not sure what is faulty here? > >> > >I have been taught that, when facts contradict a theory, the > facts win, > >and the theory is faulty. > >Since the MPLS PID issue in PWs is about 1 month old, and > MPLS PWs are > >already implemented and deployed, I conclude that PEs neither > >need nor use > >the PID information. > > Sasha, You are missing the point. The point is that if MPLS > PID exists, then PEs > identify the payload by PID in the MPLS PID word. Why do we need to identify the payload ? Are we going to support multiple types of payloads per PW (f.ex. mix of Ethernet, ATM and TDM) ? As draft-ietf-pwe3-arch states: "An inner MPLS label is used to provide the PW demultiplexing function". So the inner label identifies PW, do we need additional identifier for the Payload-IN-PW ? If not then > they have to rely on > the signaled PID. > > -Shahram > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Waldemar Augustyn Subject: Re: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 05 May 2003 00:33:21 -0400 Lines: 46 References: <2032066549.20030504001152@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon May 05 06:33:13 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en To: Alex Zinin In-Reply-To: <2032066549.20030504001152@psg.com> X-SMTP-HELO: smtp01.mrf.mail.rcn.net X-SMTP-MAIL-FROM: waldemar@nxp.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp01.mrf.mail.rcn.net [207.172.4.60] Status: O Well, as the co-originator, with Tissa, of the L2 VPN work within PPVPN, I would like to say I am glad to see this effort finally recognized as significant. But the two year delay does not impress me. What is being proposed should have been done at that time, two years ago. At the very least, the charter of ppvpn should have been adjusted as it was promised but never done. The good thing is, we were able to progress and we will continue to progress regardless of what IESG does or does not do. It appears, what we're talking about is playing catch up. The issue is really the charter which makes no sense, but I do not see the point of splitting the WG after these years. But, if all we're being asked to do is change a few header lines on our documents, then that's fine. We're easy, glad to make somebody happy. Waldemar Alex Zinin wrote: >Folks, > >Since San Francisco IETF meeting the IESG has been considering the >situation in the SUB-IP area and in the PPVPN Working Group in particular. > [snip] >We'd like to hear from the WG members if they see any fatal flaws with >the proposed approach. Please send us your feedback by May 11th. > >Regards, > >-- >Alex Zinin >IETF SUB-IP Area Co-Director > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Mon, 5 May 2003 11:10:50 +0100 Lines: 47 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, ronc@lyciumnetworks.com, Tim.Frost@zarlink.com, Andy.Malis@vivacenetworks.com, pwe3@ietf.org, yaakov_s@rad.com X-From: pwe3-admin@ietf.org Mon May 05 12:24:49 2003 Return-path: To: akiva@axerra.com, Shahram_Davari@pmc-sierra.com, Sasha@axerra.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Akiva Sadovski wrote 04 May 2003 13:07 > Hi, Shahram, > > a short naive question inside... > > Sasha, You are missing the point. The point is that if MPLS > > PID exists, then PEs > > identify the payload by PID in the MPLS PID word. > > Why do we need to identify the payload ? Are we going to > support multiple > types of payloads per PW (f.ex. mix of Ethernet, ATM and TDM) ? > As draft-ietf-pwe3-arch states: "An inner MPLS label is used > to provide > the PW demultiplexing function". So the inner label > identifies PW, do we > need > additional identifier for the Payload-IN-PW ? Akiva....It's not a naive question since it has importnat architectural consequences. Let me try and answer you. There is a fundamantal requirement to distinguish an OAM pkt from a traffic pkt. But this should be done *within* the specification of the layer network technology in question and not using a PID. In a properly specified technology this requirement is sorted up-front and is part of the general data-plane pkt overhead. So a PID is only really required when (as you say) we are muxing different *client* layer signals into a common *server* layer trail. Note that the OAM of the server layer trail is *constant/consistent* for any clinet layer carried (inc the muxed case) and is a function of, and only of, the server layer.....each of the clients should have their own independent OAM. PWs are *not* layer networks, though this is effectively what PWE3 are unneccessarily creating ....and something we don't want to see. So, to repeat, I am *not* advocating the use of PID for OAM/traffic differentiation in the PW.....though I suspect some will be. Finally, the client/server cases of X/MPLS or X/IP are *not* the same cases architecturally. This architecturally incorrect 'assumption' that they are the same case is partially responsible for why we are seeing functions appearing in the PW 'in-between' layer that are strictly not required....the other reason is poor specification of either the client or server layers per se. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Akiva Sadovski Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Mon, 5 May 2003 16:27:34 +0200 Lines: 79 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, ronc@lyciumnetworks.com, Tim.Frost@zarlink.com, Andy.Malis@vivacenetworks.com, pwe3@ietf.org, yaakov_s@rad.com X-From: pwe3-admin@ietf.org Mon May 05 15:53:25 2003 Return-path: To: "'neil.2.harrison@bt.com'" , Shahram_Davari@pmc-sierra.com, Sasha Vainshtein X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, thanks for your thorough explanation; so, you suppose, the only use of PID in PWs will be to differentiate the PWs OAM from traffic ? thanks, Akiva > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Monday, May 05, 2003 12:11 PM > To: Akiva Sadovski; Shahram_Davari@pmc-sierra.com; Sasha Vainshtein > Cc: stbryant@cisco.com; ronc@lyciumnetworks.com; > Tim.Frost@zarlink.com; Andy.Malis@vivacenetworks.com; > pwe3@ietf.org; yaakov_s@rad.com > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > Akiva Sadovski wrote 04 May 2003 13:07 > > Hi, Shahram, > > > > a short naive question inside... > > > > Sasha, You are missing the point. The point is that if MPLS > > > PID exists, then PEs > > > identify the payload by PID in the MPLS PID word. > > > > Why do we need to identify the payload ? Are we going to > > support multiple > > types of payloads per PW (f.ex. mix of Ethernet, ATM and TDM) ? > > As draft-ietf-pwe3-arch states: "An inner MPLS label is used > > to provide > > the PW demultiplexing function". So the inner label > > identifies PW, do we > > need > > additional identifier for the Payload-IN-PW ? > > Akiva....It's not a naive question since it has importnat > architectural > consequences. Let me try and answer you. > > There is a fundamantal requirement to distinguish an OAM pkt > from a traffic > pkt. But this should be done *within* the specification of the layer > network technology in question and not using a PID. > > In a properly specified technology this requirement is sorted > up-front and > is part of the general data-plane pkt overhead. So a PID is > only really > required when (as you say) we are muxing different *client* > layer signals > into a common *server* layer trail. Note that the OAM of the > server layer > trail is *constant/consistent* for any clinet layer carried > (inc the muxed > case) and is a function of, and only of, the server > layer.....each of the > clients should have their own independent OAM. > > PWs are *not* layer networks, though this is effectively what PWE3 are > unneccessarily creating ....and something we don't want to > see. So, to > repeat, I am *not* advocating the use of PID for OAM/traffic > differentiation > in the PW.....though I suspect some will be. > > Finally, the client/server cases of X/MPLS or X/IP are *not* > the same cases > architecturally. This architecturally incorrect 'assumption' > that they are > the same case is partially responsible for why we are seeing functions > appearing in the PW 'in-between' layer that are strictly not > required....the > other reason is poor specification of either the client or > server layers per > se. > > regards, Neil > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Mon, 5 May 2003 06:54:47 -0700 Lines: 78 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org, "'Yaakov Stein'" X-From: pwe3-admin@ietf.org Mon May 05 16:17:22 2003 Return-path: To: "'Akiva Sadovski'" , Sasha Vainshtein X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Akiva, Have a look at: http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt The short answer is yes, we might want to multiplex multiple protocols in the same PW. These protocols may include ICMP PING, GTTP, Y.1711, LSP-PING, etc. (not ATM, TDM, FR, ...). -Shahram >-----Original Message----- >From: Akiva Sadovski [mailto:akiva@AXERRA.com] >Sent: Sunday, May 04, 2003 8:07 AM >To: Shahram Davari; Sasha Vainshtein >Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew G. Malis; >pwe3@ietf.org; 'Yaakov Stein' >Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > >Hi, Shahram, > > a short naive question inside... > > >thanks, > Akiva > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: Thursday, May 01, 2003 11:06 PM >> To: Sasha Vainshtein >> Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew >> G. Malis; pwe3@ietf.org; 'Yaakov Stein' >> Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) >> >> >> >> >> MPLS PID being mandatory or optional does not change the fact the >> >> the actual protocol identifier of MPLS PID is used by PEs and not >> >> intermediate routers. So I am not sure what is faulty here? >> >> >> >I have been taught that, when facts contradict a theory, the >> facts win, >> >and the theory is faulty. >> >Since the MPLS PID issue in PWs is about 1 month old, and >> MPLS PWs are >> >already implemented and deployed, I conclude that PEs neither >> >need nor use >> >the PID information. >> >> Sasha, You are missing the point. The point is that if MPLS >> PID exists, then PEs >> identify the payload by PID in the MPLS PID word. > > Why do we need to identify the payload ? Are we going to >support multiple >types of payloads per PW (f.ex. mix of Ethernet, ATM and TDM) ? >As draft-ietf-pwe3-arch states: "An inner MPLS label is used >to provide >the PW demultiplexing function". So the inner label identifies >PW, do we >need >additional identifier for the Payload-IN-PW ? > > >If not then >> they have to rely on >> the signaled PID. >> >> -Shahram >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 05 May 2003 10:43:56 -0400 Lines: 26 Sender: pwe3-admin@ietf.org References: <2032066549.20030504001152@psg.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: pwe3-admin@ietf.org Mon May 05 16:55:39 2003 Return-path: To: Alex Zinin In-reply-to: Your message of Sun, 04 May 2003 00:11:52 -0700. <2032066549.20030504001152@psg.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Alex> these changes are being made for management reasons and are not Alex> intended to be a "reset" on WG activities or to halt or interrupt Alex> progress on current ongoing WG activities. That being the case, I think the proposed changes make sense, at least from the 50,000 foot level. (One could hardly say that things are fine the way they are!) I do have the following concerns: 1. Before being comfortable with a reorganization, I'd like to see what the new charters will be. I'd particularly like to be sure that the L3VPN charter is not constructed so as to cause a reset. Same with the PWE3 charter; we don't want to have to refight old wars. 2. From ground level, the most important aspect of a particular WG being in a particular area is the attitude of that area's ADs towards the work that the WG is doing. This is an unknown to us. Given that at least one IESG member (though not one involved in this reorg) has been quoted in the trade tabloids as saying that this work is all a scam which will destroy the network, you can see why we might react cautiously to any proposed change. Despite these concerns, I do think that L2VPN and L3VPN are separate pieces of work which need separate focus, and I don't think that there should be a "sub-ip" area into which one throws anything that might possibly have anything to do with MPLS. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Nagarajan, Ananth [CC]" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 10:05:22 -0500 Lines: 176 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31317.C006A79C" Cc: , "Wijnen, Bert (Bert)" , "Thomas Narten" , "Peterson, Jon" , "Allison Mankin" X-From: pwe3-admin@ietf.org Mon May 05 17:33:10 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: IMPORTANT: Strategy for VPN work in IETF Thread-Index: AcMSDTfFE+/T1tyLQqSRuBsUCtrwywBCgyqi To: "Alex Zinin" , X-OriginalArrivalTime: 05 May 2003 15:05:22.0051 (UTC) FILETIME=[BFDB6D30:01C31317] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C31317.C006A79C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW55IGVmZm9ydCB0byBzcGVlZCB1cCB0aGUgd29yayBpbiB0aGUgV0cgaXMgd2VsY29tZS4gIFRo ZSBpZGVhIHNlZW1zIGxvZ2ljYWwsIGJ1dCBzaG91bGQgaGF2ZSBiZWVuIGRvbmUgYXMgc29vbiBh cyB0aGUgcHB2cG4gV0cgc3RhcnRlZCBhY2NlcHRpbmcgTDJWUE4gd2l0aGluIHRoZSBjaGFydGVy LiAgUmlnaHQgbm93LCBJIGFtIGFmcmFpZCBpdCB3b3VsZCBjcmVhdGUgYW5vdGhlciBhZG1pbmlz dHJhdGl2ZSBkZWxheSAgaW4gdGhlIHdvcmsgLSBiZWNhdXNlIHRoZSBMMyB3b3JrIGlzIG1vcmUg b3IgbGVzcyBkb25lLiAgKEkgYW0gYW50aWNpcGF0aW5nIHRoYXQgaW4gdGhlIG5leHQgZmV3IG1v bnRocywgdGhlIFdHIHdpbGwgY29uY2VudHJhdGUgZnVsbHkgb24gTDIgd29yaykuDQogDQpJZiwg aW4gZmFjdCwgdGhlIFdHIGRvZXMgc3BsaXQsIHRoZW4gd2UgYWxzbyBuZWVkIHRvIHRoaW5rIGFi b3V0IHdoYXQgdG8gZG8gd2l0aCBhIGZldyBkb2N1bWVudHMgc3VjaCBhcyB0aGUgZ2VuZXJpYyBy ZXF0cyBkcmFmdCwgdGhhdCB3aWxsIGJlIHJlYWR5IGZvciBJRVNHIGxhc3QgY2FsbCB0aGlzIHdl ZWssIHRoYXQgcmVhbGx5IGlzIGFuIHVtYnJlbGxhIGRvY3VtZW50IGZvciBib3RoIEwyIGFuZCBM MyBWUE5zLiAgU2ltaWxhcmx5LCBJIHRoaW5rIHdlIGhhdmUgdGhlIHRlcm1pbm9sb2d5IGRyYWZ0 IHRvbyB0aGF0IHdlIG5lZWQgdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8gd2l0aC4NCiANClRoYW5r cywNCkFuYW50aA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogQWxleCBa aW5pbiBbbWFpbHRvOnppbmluQHBzZy5jb21dIA0KCVNlbnQ6IFN1biA1LzQvMjAwMyAyOjExIEFN IA0KCVRvOiBwcHZwbkBub3J0ZWxuZXR3b3Jrcy5jb20gDQoJQ2M6IHB3ZTNAaWV0Zi5vcmc7IFdp am5lbiwgQmVydCAoQmVydCk7IFRob21hcyBOYXJ0ZW47IFBldGVyc29uLCBKb247IEFsbGlzb24g TWFua2luIA0KCVN1YmplY3Q6IElNUE9SVEFOVDogU3RyYXRlZ3kgZm9yIFZQTiB3b3JrIGluIElF VEYNCgkNCgkNCg0KCUZvbGtzLA0KCQ0KCVNpbmNlIFNhbiBGcmFuY2lzY28gSUVURiBtZWV0aW5n IHRoZSBJRVNHIGhhcyBiZWVuIGNvbnNpZGVyaW5nIHRoZQ0KCXNpdHVhdGlvbiBpbiB0aGUgU1VC LUlQIGFyZWEgYW5kIGluIHRoZSBQUFZQTiBXb3JraW5nIEdyb3VwIGluIHBhcnRpY3VsYXIuDQoJ DQoJU3VjaCBjbG9zZSBhdHRlbnRpb24gdG8gdGhpcyBXRyB3YXMgdHJpZ2dlcmVkIGJ5IG51bWVy b3VzIGNvbmNlcm5zIHRoYXQNCgl0aGUgSUVTRyBtZW1iZXJzIHJlY2VpdmVkIGZyb20gdGhlIFdH IHBhcnRpY2lwYW50cyBhYm91dCBsaW1pdGVkIGFuZA0KCXNsb3cgcHJvZ3Jlc3Mgd2l0aGluIHRo ZSBXRyBkZXNwaXRlIHRoZSBlZmZvcnRzIG9mIHRoZSBXRyBjaGFpcnMgYW5kIGl0cw0KCW1lbWJl cnMuIFRoZSBJRVNHIGFsc28gdXNlZCB0aGlzIG9wcG9ydHVuaXR5IHRvIGNvbnNpZGVyIHRoZSBJ RVRGIGFyZWENCgl0aGF0IHRoZSBQUFZQTiB3b3JrIHdvdWxkIGZpdCBiZXN0Lg0KCQ0KCUFmdGVy IG11Y2ggZGVsaWJlcmF0aW9uLCB0aGUgaW52b2x2ZWQgQURzIChCZXJ0LCBUaG9tYXMsIGFuZCBJ KSBhcmUNCgljb25zaWRlcmluZyB0aGUgZm9sbG93aW5nIG9yZ2FuaXphdGlvbmFsIGNoYW5nZXMg aW4gb3JkZXIgdG8gaW1wcm92ZSBXRw0KCWZvY3VzIGFuZCBwcm9kdWN0aXZpdHkgYW5kIGVuc3Vy ZSBmYXN0ZXIgcHJvZ3Jlc3Mgb2YgdGhlIFZQTi1yZWxhdGVkIHdvcms6DQoJDQoJIDEuIFNwbGl0 IG9mIExheWVyLTIgYW5kIExheWVyLTMgVlBOIHdvcmsgaW4gc2VwYXJhdGUgV29ya2luZyBHcm91 cHMuDQoJDQoJICAgIFRoZSBMMiBhbmQgTDMgVlBOIHdvcmsgc3BhY2VzIGFyZSBlYWNoIGJpZyBl bm91Z2ggdG8gd2FycmFudCBhIHNlcGFyYXRlDQoJICAgIFdHLiBXaGlsZSBjb25jZW50cmF0aW9u IG9mIGFsbCBWUE4tcmVsYXRlZCB3b3JrIGluIGEgc2luZ2xlIGZvcnVtIHdhcw0KCSAgICB0aGUg cmlnaHQgdGhpbmcgdG8gZG8gdG8gZW5zdXJlIGNvb3JkaW5hdGlvbiBvZiBlZmZvcnRzIHdoZW4g dGhlIFBQVlBODQoJICAgIFdHIHdhcyBjcmVhdGVkIGFuZCBMMiBWUE4gd29yayBjYW1lIGluLCBz dWNoIGNvbmNlbnRyYXRpb24gaXMgY2F1c2luZw0KCSAgICBzY2FsaW5nIHByb2JsZW1zIHdpdGhp biB0aGUgV0cgYXQgdGhpcyBtb21lbnQuDQoJDQoJICAgIE1pZ3JhdGlvbiBvZiB3b3JrIGludG8g dHdvIHNlcGFyYXRlIFdHcyBmb3IgTDIgYW5kIEwzIFZQTiB0ZWNobm9sb2dpZXMNCgkgICAgd2l0 aCBtb3JlIHNwZWNpZmljIFdHIGNoYXJ0ZXJzIHdpbGwgaGVscCB0byBmb2N1cyBkaXNjdXNzaW9u cywgcHJldmVudA0KCSAgICBzdGFmZiBhbmQgbWVldGluZyB0aW1lIG92ZXJsb2FkaW5nLCBhbmQg d2lsbCBhaWQgZmFzdGVyIHByb2dyZXNzIG9mDQoJICAgIGNvcnJlc3BvbmRpbmcgdGVjaG5vbG9n aWVzLg0KCQ0KCSAyLiBNaWdyYXRpb24gb2YgdGhlIFZQTi1yZWxhdGVkIHdvcmsgdG8gdGhlIElu dGVybmV0IGFyZWEuDQoJDQoJICAgIEFzIHByZXZpb3VzbHkgZGlzY3Vzc2VkLCBWUE4tcmVsYXRl ZCB3b3JrIGNvdWxkIGJlIGFyZ3VlZCB0byBiZWxvbmcNCgkgICAgdG8gbW9yZSB0aGFuIG9uZSBh cmVhLiBUdW5uZWxpbmcgbWVjaGFuaXNtcyBhcmUgdGhlIHByb3BlcnR5IHRoYXQNCgkgICAgZ3Jh dml0YXRlcyB0aGlzIHdvcmsgdG8gdGhlIEludGVybmV0IGFyZWEsIHdoaWNoIGlzIHdoZXJlIHdl IGJlbGlldmUNCgkgICAgdGhlIFZQTiB3b3JrIHNob3VsZCBnby4NCgkNCgkgICAgQXMgcGFydCBv ZiB0aGlzIG1vdmUsIHdlIGFyZSBhbHNvIGNvbnNpZGVyaW5nIG1vdmluZyBQV0UzIGludG8gSU5U LA0KCSAgICBzbyB0aGF0IEwyVFBFWFQsIFBXRTMsIGFuZCB0aGV3IG5ldyBWUE4gV0dzIGFyZSBv cGVyYXRpbmcgaW4gdGhlIHNhbWUNCgkgICAgYXJlYS4NCgkNCglCYXNlZCBvbiB0aGUgYWJvdmUg Y29uc2lkZXJhdGlvbnMsIHdlIGFyZSBjb25zaWRlcmluZyB0aGUgZm9sbG93aW5nIHN0ZXBzOg0K CQ0KCSAxLiBUd28gbmV3IFdHcy0tTDJWUE4gYW5kIEwzVlBOLS13aWxsIGJlIGNyZWF0ZWQgaW4g dGhlIEludGVybmV0IGFyZWEuDQoJICAgIFRoZSBtYWlsaW5nIGxpc3RzIHdpbGwgYmUgZXN0YWJs aXNoZWQgYW5kIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBwcm9wb3NlZA0KCSAgICBjaGFydGVycyBv ZiB0aGUgbmV3IFdHcyB3aWxsIGJlIGluaXRpYXRlZCBzaG9ydGx5Lg0KCQ0KCSAyLiBPbmNlIHRo ZSBjaGFydGVycyBvZiB0aGUgbmV3IFdHcyBhcmUgYWdyZWVkIHVwb24gYW5kIGFwcHJvdmVkIGJ5 IHRoZSBJRVNHLA0KCSAgICBjcmVhdGlvbiBvZiB0aGUgTDJWUE4gYW5kIEwzVlBOIFdHcyBhbmQg c2h1dGRvd24gb2YgdGhlIFBQVlBOIFdHIHdpbGwgYmUNCgkgICAgcGVyZm9ybWVkIHNpbXVsdGFu ZW91c2x5LiBQUFZQTiBXRyBkb2N1bWVudHMgd2lsbCBiZSBtaWdyYXRlZCB0byB0aGUNCgkgICAg Y29ycmVzcG9uZGluZyBuZXcgV0dzLg0KCQ0KCUl0IGlzIG91ciBpbnRlbnRpb24gdG8gY29tcGxl dGUgdGhpcyBwcm9jZXNzIGJ5IHRoZSBWaWVubmEgSUVURiBtZWV0aW5nLg0KCUFsc28sIHRoZXNl IGNoYW5nZXMgYXJlIGJlaW5nIG1hZGUgZm9yIG1hbmFnZW1lbnQgcmVhc29ucyBhbmQgYXJlIG5v dCBpbnRlbmRlZA0KCXRvIGJlIGEgInJlc2V0IiBvbiBXRyBhY3Rpdml0aWVzIG9yIHRvIGhhbHQg b3IgaW50ZXJydXB0IHByb2dyZXNzIG9uIGN1cnJlbnQNCglvbmdvaW5nIFdHIGFjdGl2aXRpZXMu DQoJDQoJV2UnZCBsaWtlIHRvIGhlYXIgZnJvbSB0aGUgV0cgbWVtYmVycyBpZiB0aGV5IHNlZSBh bnkgZmF0YWwgZmxhd3Mgd2l0aA0KCXRoZSBwcm9wb3NlZCBhcHByb2FjaC4gUGxlYXNlIHNlbmQg dXMgeW91ciBmZWVkYmFjayBieSBNYXkgMTF0aC4NCgkNCglSZWdhcmRzLA0KCQ0KCS0tDQoJQWxl eCBaaW5pbg0KCUlFVEYgU1VCLUlQIEFyZWEgQ28tRGlyZWN0b3INCgkNCgkNCgkNCgkNCg0K ------_=_NextPart_001_01C31317.C006A79C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8v RU4iPg0KPEhUTUw+DQo8SEVBRD4NCg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5UPSJN UyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA2LjAuNjM4OS4wIj4NCjxUSVRMRT5JTVBPUlRBTlQ6 IFN0cmF0ZWd5IGZvciBWUE4gd29yayBpbiBJRVRGPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZIGRp cj1sdHI+DQo8RElWPkFueSBlZmZvcnQgdG8gc3BlZWQgdXAgdGhlIHdvcmsgaW4gdGhlIFdHIGlz IHdlbGNvbWUuJm5ic3A7IFRoZSBpZGVhIHNlZW1zIA0KbG9naWNhbCwgYnV0IHNob3VsZCBoYXZl IGJlZW4gZG9uZSBhcyBzb29uIGFzIHRoZSBwcHZwbiBXRyBzdGFydGVkIGFjY2VwdGluZyANCkwy VlBOIHdpdGhpbiB0aGUgY2hhcnRlci4mbmJzcDsgUmlnaHQgbm93LCBJIGFtIGFmcmFpZCBpdCB3 b3VsZCBjcmVhdGUgYW5vdGhlciANCmFkbWluaXN0cmF0aXZlIGRlbGF5Jm5ic3A7IGluIHRoZSB3 b3JrIC0gYmVjYXVzZSB0aGUgTDMgd29yayBpcyBtb3JlIG9yIGxlc3MgDQpkb25lLiZuYnNwOyAo SSBhbSBhbnRpY2lwYXRpbmcgdGhhdCBpbiB0aGUgbmV4dCBmZXcgbW9udGhzLCB0aGUgV0cgd2ls bCANCmNvbmNlbnRyYXRlIGZ1bGx5IG9uIEwyIHdvcmspLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+SWYsIGluIGZhY3QsIHRoZSBXRyBkb2VzIHNwbGl0LCB0aGVuIHdlIGFsc28gbmVl ZCB0byB0aGluayBhYm91dCB3aGF0IHRvIGRvIA0Kd2l0aCBhIGZldyBkb2N1bWVudHMgc3VjaCBh cyB0aGUgZ2VuZXJpYyByZXF0cyBkcmFmdCwgdGhhdCB3aWxsIGJlIHJlYWR5IGZvciANCklFU0cg bGFzdCBjYWxsIHRoaXMgd2VlaywgdGhhdCByZWFsbHkgaXMgYW4gdW1icmVsbGEgZG9jdW1lbnQg Zm9yIGJvdGggTDIgYW5kIEwzIA0KVlBOcy4mbmJzcDsgU2ltaWxhcmx5LCBJIHRoaW5rIHdlIGhh dmUgdGhlIHRlcm1pbm9sb2d5IGRyYWZ0IHRvbyB0aGF0IHdlIG5lZWQgdG8gDQpkZXRlcm1pbmUg d2hhdCB0byBkbyB3aXRoLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzLDwv RElWPg0KPERJVj5BbmFudGg8L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJ Ti1SSUdIVDogMHB4Ij4NCiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gPEJSPjxCPkZyb206PC9CPiBBbGV4IFppbmluIA0KICBbbWFpbHRvOnppbmluQHBzZy5j b21dIDxCUj48Qj5TZW50OjwvQj4gU3VuIDUvNC8yMDAzIDI6MTEgQU0gPEJSPjxCPlRvOjwvQj4g DQogIHBwdnBuQG5vcnRlbG5ldHdvcmtzLmNvbSA8QlI+PEI+Q2M6PC9CPiBwd2UzQGlldGYub3Jn OyBXaWpuZW4sIEJlcnQgKEJlcnQpOyANCiAgVGhvbWFzIE5hcnRlbjsgUGV0ZXJzb24sIEpvbjsg QWxsaXNvbiBNYW5raW4gPEJSPjxCPlN1YmplY3Q6PC9CPiBJTVBPUlRBTlQ6IA0KICBTdHJhdGVn eSBmb3IgVlBOIHdvcmsgaW4gSUVURjxCUj48QlI+PC9GT05UPjwvRElWPg0KICA8UD48Rk9OVCBz aXplPTI+Rm9sa3MsPEJSPjxCUj5TaW5jZSBTYW4gRnJhbmNpc2NvIElFVEYgbWVldGluZyB0aGUg SUVTRyBoYXMgDQogIGJlZW4gY29uc2lkZXJpbmcgdGhlPEJSPnNpdHVhdGlvbiBpbiB0aGUgU1VC LUlQIGFyZWEgYW5kIGluIHRoZSBQUFZQTiBXb3JraW5nIA0KICBHcm91cCBpbiBwYXJ0aWN1bGFy LjxCUj48QlI+U3VjaCBjbG9zZSBhdHRlbnRpb24gdG8gdGhpcyBXRyB3YXMgdHJpZ2dlcmVkIGJ5 IA0KICBudW1lcm91cyBjb25jZXJucyB0aGF0PEJSPnRoZSBJRVNHIG1lbWJlcnMgcmVjZWl2ZWQg ZnJvbSB0aGUgV0cgcGFydGljaXBhbnRzIA0KICBhYm91dCBsaW1pdGVkIGFuZDxCUj5zbG93IHBy b2dyZXNzIHdpdGhpbiB0aGUgV0cgZGVzcGl0ZSB0aGUgZWZmb3J0cyBvZiB0aGUgV0cgDQogIGNo YWlycyBhbmQgaXRzPEJSPm1lbWJlcnMuIFRoZSBJRVNHIGFsc28gdXNlZCB0aGlzIG9wcG9ydHVu aXR5IHRvIGNvbnNpZGVyIHRoZSANCiAgSUVURiBhcmVhPEJSPnRoYXQgdGhlIFBQVlBOIHdvcmsg d291bGQgZml0IGJlc3QuPEJSPjxCUj5BZnRlciBtdWNoIA0KICBkZWxpYmVyYXRpb24sIHRoZSBp bnZvbHZlZCBBRHMgKEJlcnQsIFRob21hcywgYW5kIEkpIGFyZTxCUj5jb25zaWRlcmluZyB0aGUg DQogIGZvbGxvd2luZyBvcmdhbml6YXRpb25hbCBjaGFuZ2VzIGluIG9yZGVyIHRvIGltcHJvdmUg V0c8QlI+Zm9jdXMgYW5kIA0KICBwcm9kdWN0aXZpdHkgYW5kIGVuc3VyZSBmYXN0ZXIgcHJvZ3Jl c3Mgb2YgdGhlIFZQTi1yZWxhdGVkIA0KICB3b3JrOjxCUj48QlI+Jm5ic3A7MS4gU3BsaXQgb2Yg TGF5ZXItMiBhbmQgTGF5ZXItMyBWUE4gd29yayBpbiBzZXBhcmF0ZSANCiAgV29ya2luZyBHcm91 cHMuPEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgVGhlIEwyIGFuZCBMMyBWUE4gd29yayBzcGFj ZXMgYXJlIA0KICBlYWNoIGJpZyBlbm91Z2ggdG8gd2FycmFudCBhIHNlcGFyYXRlPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyBXRy4gV2hpbGUgDQogIGNvbmNlbnRyYXRpb24gb2YgYWxsIFZQTi1yZWxh dGVkIHdvcmsgaW4gYSBzaW5nbGUgZm9ydW0gDQogIHdhczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsg dGhlIHJpZ2h0IHRoaW5nIHRvIGRvIHRvIGVuc3VyZSBjb29yZGluYXRpb24gb2YgDQogIGVmZm9y dHMgd2hlbiB0aGUgUFBWUE48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdHIHdhcyBjcmVhdGVkIGFu ZCBMMiBWUE4gd29yayANCiAgY2FtZSBpbiwgc3VjaCBjb25jZW50cmF0aW9uIGlzIGNhdXNpbmc8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNjYWxpbmcgcHJvYmxlbXMgDQogIHdpdGhpbiB0aGUgV0cg YXQgdGhpcyBtb21lbnQuPEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgTWlncmF0aW9uIG9mIHdv cmsgaW50byANCiAgdHdvIHNlcGFyYXRlIFdHcyBmb3IgTDIgYW5kIEwzIFZQTiB0ZWNobm9sb2dp ZXM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGggDQogIG1vcmUgc3BlY2lmaWMgV0cgY2hhcnRl cnMgd2lsbCBoZWxwIHRvIGZvY3VzIGRpc2N1c3Npb25zLCANCiAgcHJldmVudDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsgc3RhZmYgYW5kIG1lZXRpbmcgdGltZSBvdmVybG9hZGluZywgYW5kIHdpbGwg YWlkIA0KICBmYXN0ZXIgcHJvZ3Jlc3Mgb2Y8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvcnJlc3Bv bmRpbmcgDQogIHRlY2hub2xvZ2llcy48QlI+PEJSPiZuYnNwOzIuIE1pZ3JhdGlvbiBvZiB0aGUg VlBOLXJlbGF0ZWQgd29yayB0byB0aGUgDQogIEludGVybmV0IGFyZWEuPEJSPjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsgQXMgcHJldmlvdXNseSBkaXNjdXNzZWQsIFZQTi1yZWxhdGVkIA0KICB3b3Jr IGNvdWxkIGJlIGFyZ3VlZCB0byBiZWxvbmc8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIG1vcmUg dGhhbiBvbmUgYXJlYS4gDQogIFR1bm5lbGluZyBtZWNoYW5pc21zIGFyZSB0aGUgcHJvcGVydHkg dGhhdDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgZ3Jhdml0YXRlcyANCiAgdGhpcyB3b3JrIHRvIHRo ZSBJbnRlcm5ldCBhcmVhLCB3aGljaCBpcyB3aGVyZSB3ZSANCiAgYmVsaWV2ZTxCUj4mbmJzcDsm bmJzcDsmbmJzcDsgdGhlIFZQTiB3b3JrIHNob3VsZCANCiAgZ28uPEJSPjxCUj4mbmJzcDsmbmJz cDsmbmJzcDsgQXMgcGFydCBvZiB0aGlzIG1vdmUsIHdlIGFyZSBhbHNvIGNvbnNpZGVyaW5nIA0K ICBtb3ZpbmcgUFdFMyBpbnRvIElOVCw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvIHRoYXQgTDJU UEVYVCwgUFdFMywgYW5kIHRoZXcgDQogIG5ldyBWUE4gV0dzIGFyZSBvcGVyYXRpbmcgaW4gdGhl IHNhbWU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZWEuPEJSPjxCUj5CYXNlZCANCiAgb24gdGhl IGFib3ZlIGNvbnNpZGVyYXRpb25zLCB3ZSBhcmUgY29uc2lkZXJpbmcgdGhlIGZvbGxvd2luZyAN CiAgc3RlcHM6PEJSPjxCUj4mbmJzcDsxLiBUd28gbmV3IFdHcy0tTDJWUE4gYW5kIEwzVlBOLS13 aWxsIGJlIGNyZWF0ZWQgaW4gdGhlIA0KICBJbnRlcm5ldCBhcmVhLjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsgVGhlIG1haWxpbmcgbGlzdHMgd2lsbCBiZSBlc3RhYmxpc2hlZCBhbmQgDQogIHRoZSBk aXNjdXNzaW9uIG9mIHRoZSBwcm9wb3NlZDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgY2hhcnRlcnMg b2YgdGhlIG5ldyBXR3MgDQogIHdpbGwgYmUgaW5pdGlhdGVkIHNob3J0bHkuPEJSPjxCUj4mbmJz cDsyLiBPbmNlIHRoZSBjaGFydGVycyBvZiB0aGUgbmV3IFdHcyANCiAgYXJlIGFncmVlZCB1cG9u IGFuZCBhcHByb3ZlZCBieSB0aGUgSUVTRyw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNyZWF0aW9u IG9mIA0KICB0aGUgTDJWUE4gYW5kIEwzVlBOIFdHcyBhbmQgc2h1dGRvd24gb2YgdGhlIFBQVlBO IFdHIHdpbGwgDQogIGJlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBwZXJmb3JtZWQgc2ltdWx0YW5l b3VzbHkuIFBQVlBOIFdHIGRvY3VtZW50cyB3aWxsIGJlIA0KICBtaWdyYXRlZCB0byB0aGU8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvcnJlc3BvbmRpbmcgbmV3IFdHcy48QlI+PEJSPkl0IGlzIG91 ciANCiAgaW50ZW50aW9uIHRvIGNvbXBsZXRlIHRoaXMgcHJvY2VzcyBieSB0aGUgVmllbm5hIElF VEYgbWVldGluZy48QlI+QWxzbywgdGhlc2UgDQogIGNoYW5nZXMgYXJlIGJlaW5nIG1hZGUgZm9y IG1hbmFnZW1lbnQgcmVhc29ucyBhbmQgYXJlIG5vdCBpbnRlbmRlZDxCUj50byBiZSBhIA0KICAi cmVzZXQiIG9uIFdHIGFjdGl2aXRpZXMgb3IgdG8gaGFsdCBvciBpbnRlcnJ1cHQgcHJvZ3Jlc3Mg b24gDQogIGN1cnJlbnQ8QlI+b25nb2luZyBXRyBhY3Rpdml0aWVzLjxCUj48QlI+V2UnZCBsaWtl IHRvIGhlYXIgZnJvbSB0aGUgV0cgbWVtYmVycyANCiAgaWYgdGhleSBzZWUgYW55IGZhdGFsIGZs YXdzIHdpdGg8QlI+dGhlIHByb3Bvc2VkIGFwcHJvYWNoLiBQbGVhc2Ugc2VuZCB1cyB5b3VyIA0K ICBmZWVkYmFjayBieSBNYXkgMTF0aC48QlI+PEJSPlJlZ2FyZHMsPEJSPjxCUj4tLTxCUj5BbGV4 IFppbmluPEJSPklFVEYgU1VCLUlQIA0KICBBcmVhIENvLURpcmVjdG9yPEJSPjxCUj48QlI+PEJS PjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C31317.C006A79C-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Mon, 5 May 2003 18:21:58 +0300 Lines: 14 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Mon May 05 17:39:43 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) Thread-Index: AcMTDfkpaiAB2Gk1QmyeDTyerx7I6gACp7bw To: "Shahram Davari" , "Akiva Sadovski" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h45FSe809783 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > The short answer is yes, we might want to multiplex multiple protocols > in the same PW. These protocols may include ICMP PING, GTTP, Y.1711, > LSP-PING, etc. (not ATM, TDM, FR, ...). We might also want to multiplex "sub-modes" on a single PW, e.g. changing from AAL1 to AAL2 submodes of TDM for congestion mitigation, or changing to single ATM VCC cell mode for ATM OAM cells. This is what I suggested in section 5 of http://www.ietf.org/internet-drafts/draft-stein-pwe3-controlword-00.txt Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 19:04:04 +0300 Lines: 44 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , "Wijnen, Bert (Bert)" , "Thomas Narten" , "Peterson, Jon" , "Allison Mankin" X-From: pwe3-admin@ietf.org Mon May 05 18:42:59 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] IMPORTANT: Strategy for VPN work in IETF Thread-Index: AcMSEBruRHMbZVYVRBmBcrGCBvanRABCkecg To: "Alex Zinin" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h45GBi813607 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > As part of this move, we are also considering moving PWE3 into INT, > so that L2TPEXT, PWE3, and the new VPN WGs are operating in the same > area. The PWE3 charter specifically states that PWE3 will coordinate with the following WGs: L2TPEXT, DIFFSERV, AVT, CCAMP, PPVPN, MPLS, TEWG, ROHC . Scrutinizing this list, four are in SUB-IP, three are in TSV, and one in INT. l2tpext (INT), diffserv (closed - was TSV), avt (TSV), ccamp (SUB-IP), ppvpn (SUB-IP), mpls (SUB-IP), tewg (SUB-IP), rohc (TSV) After the proposed change, and removing the (now closed) diffserv WG from the list, the new count will be three SUB-IP, three INT, and two TSV. l2tpext (INT), avt (TSV), ccamp (SUB-IP), l3vpn (INT), l2vpn(INT), mpls (SUB-IP), tewg (SUB-IP), rohc (TSV) In actuality, the interaction with avt and rohc has been tenuous (note how few PWE drafts mandate RTP!), so inter-area links would be palliated by moving PWE to either SUB-IP or INT. Since the SUB-IP area is defined as temporary and hence its augmentation not desirable, the suggested path with regards to PWE3 seems to be a logical one. My only concern is regarding network congestion issues. It has been stated that PWE was originally placed in the transport area due to that area being the proper place to handle congestion avoidance and mitigation. As the WG has only recently stated to seriously consider these issues, we should give some thought as to how to keep them in focus even after an area transplant. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Mon, 5 May 2003 19:59:12 +0200 Lines: 104 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org, "'Yaakov Stein'" , Akiva Sadovski X-From: pwe3-admin@ietf.org Mon May 05 19:23:22 2003 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, Can you please explain what would be the expecting result of sending ICMP echo/echo reply on a PW? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, May 05, 2003 3:55 PM > To: Akiva Sadovski; Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org; 'Yaakov Stein' > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > Akiva, > > Have a look at: > > http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt > > The short answer is yes, we might want to multiplex multiple protocols > in the same PW. These protocols may include ICMP PING, GTTP, Y.1711, > LSP-PING, etc. (not ATM, TDM, FR, ...). > > -Shahram > > >-----Original Message----- > >From: Akiva Sadovski [mailto:akiva@AXERRA.com] > >Sent: Sunday, May 04, 2003 8:07 AM > >To: Shahram Davari; Sasha Vainshtein > >Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); > Andrew G. Malis; > >pwe3@ietf.org; 'Yaakov Stein' > >Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > > >Hi, Shahram, > > > > a short naive question inside... > > > > > >thanks, > > Akiva > > > >> -----Original Message----- > >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> Sent: Thursday, May 01, 2003 11:06 PM > >> To: Sasha Vainshtein > >> Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > >> G. Malis; pwe3@ietf.org; 'Yaakov Stein' > >> Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > >> > >> > >> > >> >> MPLS PID being mandatory or optional does not change > the fact the > >> >> the actual protocol identifier of MPLS PID is used by > PEs and not > >> >> intermediate routers. So I am not sure what is faulty here? > >> >> > >> >I have been taught that, when facts contradict a theory, the > >> facts win, > >> >and the theory is faulty. > >> >Since the MPLS PID issue in PWs is about 1 month old, and > >> MPLS PWs are > >> >already implemented and deployed, I conclude that PEs neither > >> >need nor use > >> >the PID information. > >> > >> Sasha, You are missing the point. The point is that if MPLS > >> PID exists, then PEs > >> identify the payload by PID in the MPLS PID word. > > > > Why do we need to identify the payload ? Are we going to > >support multiple > >types of payloads per PW (f.ex. mix of Ethernet, ATM and TDM) ? > >As draft-ietf-pwe3-arch states: "An inner MPLS label is used > >to provide > >the PW demultiplexing function". So the inner label identifies > >PW, do we > >need > >additional identifier for the Payload-IN-PW ? > > > > > >If not then > >> they have to rely on > >> the signaled PID. > >> > >> -Shahram > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pwe3 > >> > > > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: "Hamid Ould-Brahim" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 13:24:29 -0400 Lines: 102 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3132B.2F6090C8" Cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon May 05 19:34:47 2003 Return-path: To: Alex Zinin , ppvpn@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2653.19) Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3132B.2F6090C8 Content-Type: text/plain; charset="iso-8859-1" Alex, > > Since San Francisco IETF meeting the IESG has been considering the > situation in the SUB-IP area and in the PPVPN Working Group > in particular. > > Such close attention to this WG was triggered by numerous > concerns that > the IESG members received from the WG participants about limited and > slow progress within the WG despite the efforts of the WG > chairs and its > members. [clipped...] Wouldn't be more appropriate to first discuss what these concerns are and if they are indeed justified concerns, and solicit feedback from the wg to discuss options or improvements on how to move the wg forward and get consensus on that. If I recall, similar open approach has been taken for sup-ip area in Atlanta meeting. Kind of hard to be *confident* that the proposed reorganization will actually address the raised concerns without actually knowing what these concerns are in the first place! After all, the amount of work after the split is exactly the same as before the split if not bigger (given that l3vpns work is almost done and the split will introduce additional administrative overhead). Hamid. ------_=_NextPart_001_01C3132B.2F6090C8 Content-Type: text/html; charset="iso-8859-1" RE: IMPORTANT: Strategy for VPN work in IETF

Alex,

>
> Since San Francisco IETF meeting the IESG has been considering the
> situation in the SUB-IP area and in the PPVPN Working Group
> in particular.
>
> Such close attention to this WG was triggered by numerous
> concerns that
> the IESG members received from the WG participants about limited and
> slow progress within the WG despite the efforts of the WG
> chairs and its
> members.

[clipped...]

Wouldn't be more appropriate to first discuss what these
concerns are and if they are indeed justified concerns, and
solicit feedback from the wg to discuss options or
improvements on how to move the wg forward and get consensus
on that. If I recall, similar open approach has been taken for
sup-ip area in Atlanta meeting.

Kind of hard to be *confident* that the proposed reorganization
will actually address the raised concerns without actually
knowing what these concerns are in the first place!

After all, the amount of work after the split is exactly
the same as before the split if not bigger (given that
l3vpns work is almost done and the split will
introduce additional administrative overhead).

Hamid.

------_=_NextPart_001_01C3132B.2F6090C8-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Mon, 5 May 2003 10:18:52 -0700 Lines: 143 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org, "'Yaakov Stein'" , Akiva Sadovski X-From: pwe3-admin@ietf.org Mon May 05 19:39:21 2003 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O You can find your answer in these 2 drafts: http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-vccv-00.txt draft-allan: "Originators of ICMP echo request messages use the any address in the non-routable 127./8 address range as a destination address. Originators of ICMP echo reply messages substitute their own PSN loopback address for the 127./8 when replying." draft-nadeau: " When ICMP packets are used, the source address should be set to the source address of the LDP session and the destination address to the destination of the LDP session. The Identifier and Sequence Number fields of the ICMP Echo Request / Echo Reply messages are used to track what VCs are being tested. These fields are only interpreted by the sending PE. Specific use of these fields is an implementation matter." -Shahram >-----Original Message----- >From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] >Sent: Monday, May 05, 2003 1:59 PM >To: Shahram Davari >Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew G. Malis; >pwe3@ietf.org; 'Yaakov Stein'; Akiva Sadovski >Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > >Shahram, >Can you please explain what would be the expecting result of >sending ICMP >echo/echo reply on a PW? > >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: Monday, May 05, 2003 3:55 PM >> To: Akiva Sadovski; Sasha Vainshtein >> Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew >> G. Malis; pwe3@ietf.org; 'Yaakov Stein' >> Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) >> >> >> Akiva, >> >> Have a look at: >> >> http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt >> >> The short answer is yes, we might want to multiplex multiple >protocols >> in the same PW. These protocols may include ICMP PING, GTTP, Y.1711, >> LSP-PING, etc. (not ATM, TDM, FR, ...). >> >> -Shahram >> >> >-----Original Message----- >> >From: Akiva Sadovski [mailto:akiva@AXERRA.com] >> >Sent: Sunday, May 04, 2003 8:07 AM >> >To: Shahram Davari; Sasha Vainshtein >> >Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); >> Andrew G. Malis; >> >pwe3@ietf.org; 'Yaakov Stein' >> >Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) >> > >> > >> >Hi, Shahram, >> > >> > a short naive question inside... >> > >> > >> >thanks, >> > Akiva >> > >> >> -----Original Message----- >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> >> Sent: Thursday, May 01, 2003 11:06 PM >> >> To: Sasha Vainshtein >> >> Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew >> >> G. Malis; pwe3@ietf.org; 'Yaakov Stein' >> >> Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) >> >> >> >> >> >> >> >> >> MPLS PID being mandatory or optional does not change >> the fact the >> >> >> the actual protocol identifier of MPLS PID is used by >> PEs and not >> >> >> intermediate routers. So I am not sure what is faulty here? >> >> >> >> >> >I have been taught that, when facts contradict a theory, the >> >> facts win, >> >> >and the theory is faulty. >> >> >Since the MPLS PID issue in PWs is about 1 month old, and >> >> MPLS PWs are >> >> >already implemented and deployed, I conclude that PEs neither >> >> >need nor use >> >> >the PID information. >> >> >> >> Sasha, You are missing the point. The point is that if MPLS >> >> PID exists, then PEs >> >> identify the payload by PID in the MPLS PID word. >> > >> > Why do we need to identify the payload ? Are we going to >> >support multiple >> >types of payloads per PW (f.ex. mix of Ethernet, ATM and TDM) ? >> >As draft-ietf-pwe3-arch states: "An inner MPLS label is used >> >to provide >> >the PW demultiplexing function". So the inner label identifies >> >PW, do we >> >need >> >additional identifier for the Payload-IN-PW ? >> > >> > >> >If not then >> >> they have to rely on >> >> the signaled PID. >> >> >> >> -Shahram >> >> _______________________________________________ >> >> pwe3 mailing list >> >> pwe3@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> > >> > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Mon, 5 May 2003 20:31:29 +0200 Lines: 180 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org, "'Yaakov Stein'" , Akiva Sadovski X-From: pwe3-admin@ietf.org Mon May 05 19:51:57 2003 Return-path: To: "'Shahram Davari'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, Thank you for a prompt response. Please see some feedback inline. In addition: AFAIK, Y.1711 does NOT require any MPLS PID as it uses a reserved OAM label at the bottom of the stack. Did I miss something? And why do we need two different methods for identifying maintenance packets on a PW? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, May 05, 2003 7:19 PM > To: Sasha Vainshtein > Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > G. Malis; pwe3@ietf.org; 'Yaakov Stein'; Akiva Sadovski > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > You can find your answer in these 2 drafts: > > http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt > > http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-vccv-00.txt > > draft-allan: > > "Originators of ICMP echo request > messages use the any address in the non-routable 127./8 address > range as a destination address. Originators of ICMP echo reply > messages substitute their own PSN loopback address for the 127./8 > when replying." > I seem to remember that this has been strongly objected when the draft was discussed. > > draft-nadeau: > > " When ICMP packets are used, the source address should be set > to the source address of the LDP session and the destination > address to the destination of the LDP session. The Identifier > and Sequence Number fields of the ICMP Echo Request / Echo > Reply messages are used to track what VCs are being tested. > These fields are only interpreted by the sending PE. Specific > use of these fields is an implementation matter." > AFAIK, draft-nadeau proposes its own method of identifying in-band Connectivity Verification messages. > > -Shahram > > > >-----Original Message----- > >From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > >Sent: Monday, May 05, 2003 1:59 PM > >To: Shahram Davari > >Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); > Andrew G. Malis; > >pwe3@ietf.org; 'Yaakov Stein'; Akiva Sadovski > >Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > > >Shahram, > >Can you please explain what would be the expecting result of > >sending ICMP > >echo/echo reply on a PW? > > > >With best regards, > > Sasha Vainshtein > >email: sasha@axerra.com > >tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > >> -----Original Message----- > >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> Sent: Monday, May 05, 2003 3:55 PM > >> To: Akiva Sadovski; Sasha Vainshtein > >> Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > >> G. Malis; pwe3@ietf.org; 'Yaakov Stein' > >> Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > >> > >> > >> Akiva, > >> > >> Have a look at: > >> > >> http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt > >> > >> The short answer is yes, we might want to multiplex multiple > >protocols > >> in the same PW. These protocols may include ICMP PING, > GTTP, Y.1711, > >> LSP-PING, etc. (not ATM, TDM, FR, ...). > >> > >> -Shahram > >> > >> >-----Original Message----- > >> >From: Akiva Sadovski [mailto:akiva@AXERRA.com] > >> >Sent: Sunday, May 04, 2003 8:07 AM > >> >To: Shahram Davari; Sasha Vainshtein > >> >Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); > >> Andrew G. Malis; > >> >pwe3@ietf.org; 'Yaakov Stein' > >> >Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > >> > > >> > > >> >Hi, Shahram, > >> > > >> > a short naive question inside... > >> > > >> > > >> >thanks, > >> > Akiva > >> > > >> >> -----Original Message----- > >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> >> Sent: Thursday, May 01, 2003 11:06 PM > >> >> To: Sasha Vainshtein > >> >> Cc: stbryant@cisco.com; Ron Cohen; Tim Frost (E-mail); Andrew > >> >> G. Malis; pwe3@ietf.org; 'Yaakov Stein' > >> >> Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 > and 5.4.4) > >> >> > >> >> > >> >> > >> >> >> MPLS PID being mandatory or optional does not change > >> the fact the > >> >> >> the actual protocol identifier of MPLS PID is used by > >> PEs and not > >> >> >> intermediate routers. So I am not sure what is faulty here? > >> >> >> > >> >> >I have been taught that, when facts contradict a theory, the > >> >> facts win, > >> >> >and the theory is faulty. > >> >> >Since the MPLS PID issue in PWs is about 1 month old, and > >> >> MPLS PWs are > >> >> >already implemented and deployed, I conclude that PEs neither > >> >> >need nor use > >> >> >the PID information. > >> >> > >> >> Sasha, You are missing the point. The point is that if MPLS > >> >> PID exists, then PEs > >> >> identify the payload by PID in the MPLS PID word. > >> > > >> > Why do we need to identify the payload ? Are we going to > >> >support multiple > >> >types of payloads per PW (f.ex. mix of Ethernet, ATM and TDM) ? > >> >As draft-ietf-pwe3-arch states: "An inner MPLS label is used > >> >to provide > >> >the PW demultiplexing function". So the inner label identifies > >> >PW, do we > >> >need > >> >additional identifier for the Payload-IN-PW ? > >> > > >> > > >> >If not then > >> >> they have to rely on > >> >> the signaled PID. > >> >> > >> >> -Shahram > >> >> _______________________________________________ > >> >> pwe3 mailing list > >> >> pwe3@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/pwe3 > >> >> > >> > > >> > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Mon, 5 May 2003 11:00:47 -0700 Lines: 24 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, Ron Cohen , "Tim Frost (E-mail)" , "Andrew G. Malis" , pwe3@ietf.org, "'Yaakov Stein'" , Akiva Sadovski X-From: pwe3-admin@ietf.org Mon May 05 20:13:38 2003 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, >In addition: AFAIK, Y.1711 does NOT require any MPLS PID as it uses a >reserved OAM label at the bottom of the stack. >Did I miss something? The proposal by David Allan is to amend Y.1711 with an option that uses MPLS PID. >And why do we need two different methods for >identifying maintenance packets on a PW? Because some ICMP implementations may hash the reserved label, and therefore cause the OAM packets to take a different path than user packets. >AFAIK, draft-nadeau proposes its own method of identifying in-band >Connectivity Verification >messages. Correct, but it only works for some PW types, i.e., those that have a reserved bit in their CW. For example it can't be used with SONET/SDH PW or even CESoPSN. Also it permits running only a single management protocol over the PW, i.e., either ICMP or LSP-ping, or ... -Shahram From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Yakov Rekhter Subject: Re: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 05 May 2003 13:12:46 -0700 Lines: 91 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: PPVPN , pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon May 05 22:11:46 2003 Return-path: To: Alex Zinin Content-ID: <95811.1052165566.1@juniper.net> X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] Status: O Alex, > Folks, > > > Since San Francisco IETF meeting the IESG has been considering the > situation in the SUB-IP area and in the PPVPN Working Group in particular. > > > Such close attention to this WG was triggered by numerous concerns that > the IESG members received from the WG participants about limited and > slow progress within the WG despite the efforts of the WG chairs and its > members. The IESG also used this opportunity to consider the IETF area > that the PPVPN work would fit best. > > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to improve WG > focus and productivity and ensure faster progress of the VPN-related work: > > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > > The L2 and L3 VPN work spaces are each big enough to warrant a separate > WG. While concentration of all VPN-related work in a single forum was > the right thing to do to ensure coordination of efforts when the PPVPN > WG was created and L2 VPN work came in, such concentration is causing > scaling problems within the WG at this moment. As was pointed by other folks, there is practically no L3 VPN related activities now. Practically all the discussion is about L2 VPN, or to be even more precise, above VPLS. Just count the number of messages posted to the list over the last 12 months related to L3 VPNs vs L2 VPNs. With this in mind please explain how moving L3 VPN into a separate WG would help to address the scaling problems that you mentioned above. > Migration of work into two separate WGs for L2 and L3 VPN technologies > with more specific WG charters will help to focus discussions, prevent > staff and meeting time overloading, and will aid faster progress of > corresponding technologies. As I mentioned above - there isn't any discussion on L3 VPN technologies. The WG focuses on L2 VPN, and mostly on VPLS. Are you suggesting that the WG need more discussion on L3 VPNs (e.g., 2547bis) ? > 2. Migration of the VPN-related work to the Internet area. > > As previously discussed, VPN-related work could be argued to belong > to more than one area. Tunneling mechanisms are the property that > gravitates this work to the Internet area, which is where we believe > the VPN work should go. > > As part of this move, we are also considering moving PWE3 into INT, > so that L2TPEXT, PWE3, and thew new VPN WGs are operating in the same > area. > > Based on the above considerations, we are considering the following steps: > > > 1. Two new WGs--L2VPN and L3VPN--will be created in the Internet area. > The mailing lists will be established and the discussion of the proposed > charters of the new WGs will be initiated shortly. > > 2. Once the charters of the new WGs are agreed upon and approved by the IESG, > creation of the L2VPN and L3VPN WGs and shutdown of the PPVPN WG will be > performed simultaneously. PPVPN WG documents will be migrated to the > corresponding new WGs. > > > It is our intention to complete this process by the Vienna IETF meeting. > Also, these changes are being made for management reasons and are not > intended to be a "reset" on WG activities or to halt or interrupt progress > on current ongoing WG activities. > > We'd like to hear from the WG members if they see any fatal flaws with > the proposed approach. Please send us your feedback by May 11th. I find the justifications for the steps you suggested above highly dubious (to say the least). The absence of solid justifications is one of the fatal flaws of the proposed approach. Yakov. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: TTL value of VC Label? Date: Mon, 05 May 2003 15:46:28 -0400 Lines: 14 Sender: pwe3-admin@ietf.org References: <82F679A6A377F84B8F665D8F90D12B8DD8F2AE@sc-msexch-05.extremenetworks.com> Cc: "'Brian Hassink'" , stbryant@cisco.com, vkompella@timetra.com, Wei Luo , Alik Shimelmits , erosen@cisco.com, Yaron Nachman , pwe3@ietf.org, Eli Angel , Ilya Vershkov , swallow@cisco.com X-From: pwe3-admin@ietf.org Mon May 05 22:12:49 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Olen Stokes In-reply-to: Your message of "Fri, 02 May 2003 05:44:24 PDT." <82F679A6A377F84B8F665D8F90D12B8DD8F2AE@sc-msexch-05.extremenetworks.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > For example, in draft "draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt," we > defined a method for setting the TTL and also how the TTL is to be handled > as it passes between the concatenated PWs. If you're doing a 802.1d bridging function between PWs, they are not concatenated PWs. What Eric Rosen was discussing is simply splicing based on the VC label. Not by looking at MAC addresses. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Robert Raszuk Subject: Re: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 05 May 2003 22:09:29 +0200 Organization: Signature: http://www.employees.org/~raszuk/sig/ Lines: 80 References: <2032066549.20030504001152@psg.com> Reply-To: raszuk@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon May 05 22:20:53 2003 Return-path: X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en To: Alex Zinin X-SMTP-HELO: sj-core-5.cisco.com X-SMTP-MAIL-FROM: raszuk@cisco.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: sj-core-5.cisco.com [171.71.177.238] Status: O Alex, I think that auto92679 is partially correct that it is just impossible to master every piece of technology for AD or IESG member... :) Well reg the split I have a mixed feelings, but I guess I will be fine either way provided that charters actually and explicitely allow for something productive to be done in the new groups. R. > Alex Zinin wrote: > > Folks, > > Since San Francisco IETF meeting the IESG has been considering the > situation in the SUB-IP area and in the PPVPN Working Group in particular. > > Such close attention to this WG was triggered by numerous concerns that > the IESG members received from the WG participants about limited and > slow progress within the WG despite the efforts of the WG chairs and its > members. The IESG also used this opportunity to consider the IETF area > that the PPVPN work would fit best. > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to improve WG > focus and productivity and ensure faster progress of the VPN-related work: > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > The L2 and L3 VPN work spaces are each big enough to warrant a separate > WG. While concentration of all VPN-related work in a single forum was > the right thing to do to ensure coordination of efforts when the PPVPN > WG was created and L2 VPN work came in, such concentration is causing > scaling problems within the WG at this moment. > > Migration of work into two separate WGs for L2 and L3 VPN technologies > with more specific WG charters will help to focus discussions, prevent > staff and meeting time overloading, and will aid faster progress of > corresponding technologies. > > 2. Migration of the VPN-related work to the Internet area. > > As previously discussed, VPN-related work could be argued to belong > to more than one area. Tunneling mechanisms are the property that > gravitates this work to the Internet area, which is where we believe > the VPN work should go. > > As part of this move, we are also considering moving PWE3 into INT, > so that L2TPEXT, PWE3, and thew new VPN WGs are operating in the same > area. > > Based on the above considerations, we are considering the following steps: > > 1. Two new WGs--L2VPN and L3VPN--will be created in the Internet area. > The mailing lists will be established and the discussion of the proposed > charters of the new WGs will be initiated shortly. > > 2. Once the charters of the new WGs are agreed upon and approved by the IESG, > creation of the L2VPN and L3VPN WGs and shutdown of the PPVPN WG will be > performed simultaneously. PPVPN WG documents will be migrated to the > corresponding new WGs. > > It is our intention to complete this process by the Vienna IETF meeting. > Also, these changes are being made for management reasons and are not intended > to be a "reset" on WG activities or to halt or interrupt progress on current > ongoing WG activities. > > We'd like to hear from the WG members if they see any fatal flaws with > the proposed approach. Please send us your feedback by May 11th. > > Regards, > > -- > Alex Zinin > IETF SUB-IP Area Co-Director From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 16:21:19 -0400 Organization: Cisco Systems, Inc. Lines: 146 References: <200305052012.h45KCku45738@merlot.juniper.net> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'PPVPN'" , , "'Wijnen, Bert \(Bert\)'" , "'Thomas Narten'" , "'Peterson, Jon'" , "'Allison Mankin'" X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon May 05 22:23:49 2003 Return-path: To: "'Yakov Rekhter'" , "'Alex Zinin'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200305052012.h45KCku45738@merlot.juniper.net> Importance: Normal X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: tnadeau@cisco.com X-SMTP-RCPT-TO: PPVPN@NORTELNETWORKS.COM X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] Status: O > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Monday, May 05, 2003 4:13 PM > To: Alex Zinin > Cc: PPVPN; pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten; > Peterson, Jon; Allison Mankin > Subject: Re: IMPORTANT: Strategy for VPN work in IETF > > > Alex, > > > Folks, > > > > > > Since San Francisco IETF meeting the IESG has been considering the > > situation in the SUB-IP area and in the PPVPN Working Group in > > particular. > > > > > > Such close attention to this WG was triggered by numerous concerns > > that the IESG members received from the WG participants > about limited > > and slow progress within the WG despite the efforts of the > WG chairs > > and its members. The IESG also used this opportunity to > consider the > > IETF area that the PPVPN work would fit best. > > > > > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > > considering the following organizational changes in order > to improve > > WG focus and productivity and ensure faster progress of the > > VPN-related work: > > > > > > 1. Split of Layer-2 and Layer-3 VPN work in separate > Working Groups. > > > > > > The L2 and L3 VPN work spaces are each big enough to > warrant a separate > > WG. While concentration of all VPN-related work in a > single forum was > > the right thing to do to ensure coordination of efforts > when the PPVPN > > WG was created and L2 VPN work came in, such > concentration is causing > > scaling problems within the WG at this moment. > > As was pointed by other folks, there is practically no L3 VPN > related activities now. Practically all the discussion is > about L2 VPN, or to be even more precise, above VPLS. Just > count the number of messages posted to the list over the last > 12 months related to L3 VPNs vs L2 VPNs. > > With this in mind please explain how moving L3 VPN into a > separate WG would help to address the scaling problems that > you mentioned above. This may be the case because a) all of the existing L3 VPN work is wrapped up and b) no new L3 VPN work has been added to the work queue due to lack of bandwidth in general, which I think Alex's proposal is trying to address. There was work proposed at the SF meeting that was discouraged to move forward due to the current list of things on the WG's plate. --Tom > > Migration of work into two separate WGs for L2 and L3 > VPN technologies > > with more specific WG charters will help to focus > discussions, prevent > > staff and meeting time overloading, and will aid faster > progress of > > corresponding technologies. > > As I mentioned above - there isn't any discussion on L3 VPN > technologies. The WG focuses on L2 VPN, and mostly on VPLS. > > Are you suggesting that the WG need more discussion on L3 VPNs (e.g., > 2547bis) ? > > 2. Migration of the VPN-related work to the Internet area. > > > > As previously discussed, VPN-related work could be > argued to belong > > to more than one area. Tunneling mechanisms are the > property that > > gravitates this work to the Internet area, which is > where we believe > > the VPN work should go. > > > > As part of this move, we are also considering moving > PWE3 into INT, > > so that L2TPEXT, PWE3, and thew new VPN WGs are > operating in the same > > area. > > > > Based on the above considerations, we are considering the following > > steps: > > > > > > 1. Two new WGs--L2VPN and L3VPN--will be created in the > Internet area. > > The mailing lists will be established and the > discussion of the proposed > > charters of the new WGs will be initiated shortly. > > > > 2. Once the charters of the new WGs are agreed upon and > approved by the IESG, > > creation of the L2VPN and L3VPN WGs and shutdown of the > PPVPN WG will be > > performed simultaneously. PPVPN WG documents will be > migrated to the > > corresponding new WGs. > > > > > > It is our intention to complete this process by the Vienna IETF > > meeting. Also, these changes are being made for management > reasons and > > are not intended to be a "reset" on WG activities or to halt or > > interrupt progress on current ongoing WG activities. > > > > We'd like to hear from the WG members if they see any fatal > flaws with > > the proposed approach. Please send us your feedback by May 11th. > > I find the justifications for the steps you suggested above > highly dubious > (to say the least). The absence of solid justifications is > one of the fatal flaws of the proposed approach. > > Yakov. > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: TTL value of VC Label? Date: Mon, 05 May 2003 16:21:55 -0400 Lines: 10 Sender: pwe3-admin@ietf.org References: <3EB276CE.40C29D34@alcatel.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: stbryant@cisco.com, Olen Stokes , "'vkompella@timetra.com'" , Wei Luo , Alik Shimelmits , Yaron Nachman , pwe3@ietf.org, Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Mon May 05 22:54:46 2003 Return-path: To: david.watkinson@alcatel.com In-reply-to: Your message of Fri, 02 May 2003 09:46:54 -0400. <3EB276CE.40C29D34@alcatel.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O David> Setting the TTL is application dependant. The originating PE will know David> if the PSN tunnel reaches the destination node for the PW. I don't think it will always know this. David> In other cases, for example, DTLS, a TTL of 4 may be needed due to David> the two additional hops taken between the L2PE and PE at each end. You could have an L2PE/PE hop at one end but not at the other. In general, you wouldn't know whether the other end has such a hop or not. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 05 May 2003 15:58:56 -0400 Lines: 25 Sender: pwe3-admin@ietf.org References: Cc: pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Mon May 05 23:07:18 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Danny McPherson In-reply-to: Your message of "Fri, 02 May 2003 15:55:57 MDT." Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Danny - > MPLS->PW label->MPLS PID->RTP->PW CW->PW Payload Just what is this MPLS PID that you're hanging you hat on? No standard or MPLS wg document exists. There is no item in the MPLS charter. I do not see the MPLS group doing a standards track 4 byte payload type ID. All I want MPLS to do is write an informational document citing the issues of ECMP and recomending the above use of the first nibble of a non-IP payload. So as far as I'm concerned what folks are calling the "MPLS PID" is merely a variant of the PW CW. And your diagram is: MPLS->PW label->PW CW->RTP->PW CW->PW Payload ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 05 May 2003 17:19:31 -0400 Lines: 14 References: <200305052012.h45KCku45738@merlot.juniper.net> Cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon May 05 23:20:50 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Alex Zinin , PPVPN In-reply-to: Your message of "Mon, 05 May 2003 13:12:46 PDT." <200305052012.h45KCku45738@merlot.juniper.net> X-SMTP-HELO: rtp-core-2.cisco.com X-SMTP-MAIL-FROM: swallow@cisco.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-2.cisco.com [64.102.124.13] Status: O I don't see the need for two work groups. Just encourage the chairs to get two meeting slots (until the level of activity settles down). ///George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: David Watkinson Subject: Re: TTL value of VC Label? Date: Mon, 05 May 2003 17:03:09 -0400 Organization: Alcatel Canada Lines: 25 Sender: pwe3-admin@ietf.org References: <200305052021.h45KLtWS009979@rtp-core-1.cisco.com> Reply-To: david.watkinson@alcatel.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, Olen Stokes , "'vkompella@timetra.com'" , Wei Luo , Alik Shimelmits , Yaron Nachman , pwe3@ietf.org, Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Mon May 05 23:22:15 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: erosen@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eric Rosen wrote: > David> Setting the TTL is application dependant. The originating PE will know > David> if the PSN tunnel reaches the destination node for the PW. > > I don't think it will always know this. For applications that do not know the number of hops will have to set the TTL to a larger value (e.g. the same TTL used for originated IP packets). Many applications will know that the far-end IP address of the tunnel is the same as the IP address of the termination point of the PW. For those cases, it could set the TTL to 2. > > > David> In other cases, for example, DTLS, a TTL of 4 may be needed due to > David> the two additional hops taken between the L2PE and PE at each end. > > You could have an L2PE/PE hop at one end but not at the other. In general, > you wouldn't know whether the other end has such a hop or not. Yes, that is true, however setting a TTL=4 is much safer than using a TTL=3. I still think that a statement such as "The setting of the TTL value in the PW label is application dependant" is a suitable replacement for the existing text. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Robert Raszuk Subject: Re: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 05 May 2003 22:54:04 +0200 Organization: Signature: http://www.employees.org/~raszuk/sig/ Lines: 21 Sender: pwe3-admin@ietf.org References: <200305052012.h45KCku45738@merlot.juniper.net> Reply-To: raszuk@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alex Zinin , PPVPN , pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: pwe3-admin@ietf.org Mon May 05 23:25:21 2003 Return-path: X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en To: Yakov Rekhter Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Yakov, > As was pointed by other folks, there is practically no L3 VPN > related activities now. Well I can't agree with this one submitting few new drafts within the last couple of months proposing some new improvements to L3VPNs ;). What may be the reason for not much work is the current charter's below quote: "Note that it is not a goal of this WG to develop new protocols or extend existing ones." So if the split allows to remove that one line I think it could be beneficial. Also it could very well get rid of all the framework/requirements and applicability statements ;). On the other hand there is work common to both L2VPN & L3VPNs - if we split ppvpn where such a work is going to end up ? In both :) ? R. From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Alex Zinin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 14:38:40 -0700 Lines: 27 References: <200305052119.RAA13282@bifocal.cisco.com> Reply-To: Alex Zinin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: PPVPN , pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , =?ISO-8859-15?B?UGV0ZXJzb24sDQogICAgSm9u?= , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon May 05 23:43:58 2003 Return-path: X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) To: George Swallow In-Reply-To: <200305052119.RAA13282@bifocal.cisco.com> X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] Status: O George, Interesting that you mention this... I actually believe that if a WG consistently needs more than one meeting slot, it is a good sign of it having more on its plate than can efficiently deal with or poor management of the meeting time. Cheers. -- Alex Monday, May 5, 2003, 2:19:31 PM, George Swallow wrote: > I don't see the need for two work groups. Just encourage the > chairs to get two meeting slots (until the level of activity settles > down). > ///George > ======================================================================== > George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 5 May 2003 14:25:16 -0700 Lines: 47 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 00:32:32 2003 Return-path: To: "'George Swallow'" , Danny McPherson X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O And what is your proposal for PW types that don't have their first nibble reserved (such as SONET/SDH PW)? -Shahram >-----Original Message----- >From: George Swallow [mailto:swallow@cisco.com] >Sent: Monday, May 05, 2003 3:59 PM >To: Danny McPherson >Cc: pwe3@ietf.org; swallow@cisco.com >Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > >Danny - > >> MPLS->PW label->MPLS PID->RTP->PW CW->PW Payload > >Just what is this MPLS PID that you're hanging you hat on? > >No standard or MPLS wg document exists. There is no item in the MPLS >charter. > >I do not see the MPLS group doing a standards track 4 byte payload >type ID. All I want MPLS to do is write an informational document >citing the issues of ECMP and recomending the above use of the first >nibble of a non-IP payload. > >So as far as I'm concerned what folks are calling the "MPLS PID" is >merely a variant of the PW CW. And your diagram is: > >MPLS->PW label->PW CW->RTP->PW CW->PW Payload > >...George > >=============================================================== >========= >George Swallow Cisco Systems >(978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 09:59:37 +0200 Lines: 126 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 09:09:33 2003 Return-path: To: "'Shahram Davari'" , "'George Swallow'" , Danny McPherson X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi all, I believe that George's comment has been very much in place. The "MPLS PID" story looks to me like following: 1. There was a recognized but, for some reasons, undeclared need to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts complied with this, and some did not; some others simply declared that the CW is optional. 2. At some (rather late) stage, the need has been declared, explained (which is always good!) and proposed as part of the standard (moving the architecture document int the Standards Track). 3. In order to minimize impact on some pre-standard implementations that have either utilized the 1st nibble of the CW or used RTP (or both), an optional opaque 32-bit word has between the PW label (at the bottom of the label stack) and a the CW/RTP header has been proposed as the simplest way out. The only requirement for this block of data has been to keep its 1st nibble zeroed. 4. After that, this patch has been somehow "promoted" to the title and associated status of of "MPLS PID". And this promotion has triggered a long discussion of its possible uses far beyond the original patchy fuctionality. 5. The proposals mentioned in is discussion are, IMO, paramount to an alternative PWE3 architecture (including allocation of a PWE3 protocol number in IP header etc.). They also include amendments to Y.1711 which is presumably out of scope of PWE3 (and IETF in general) etc. And somehow the fact that existing LSRs carry IP traffic over LSPs without any MPLS PID and will hardly be ever retrofitted has been happily ignored by some of the participants. IMHO the best way out of the confusion would be to demote "MPLS PID" to what it really is - a patch solving the ECMP problem for the following three cases (and just for these cases): o PW encapsulations that do not mandate a CW, so that payload immediately follows the PW label. In other words, make SOME CW mandatory. o PW encapsulations that mandate a CW but utilize its 1st nibble. They would prepend an opaque 32-bit word with the zeroed 1st nibble by default, reserving an option to drop it if ECMP is not used in the core network. o PW encapsulations that use RTP. They may follow the same rules as in the previous case, or may use weaker rules because the first nibble of an RTP header distinguishes it from IPv4/IPv6 headers and this is probably sufficient for ECMP. I think that building theories/architectures on patches is counter-productive. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, May 05, 2003 11:25 PM > To: 'George Swallow'; Danny McPherson > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > And what is your proposal for PW types that don't have their > first nibble > reserved (such as SONET/SDH PW)? > > -Shahram > > > >-----Original Message----- > >From: George Swallow [mailto:swallow@cisco.com] > >Sent: Monday, May 05, 2003 3:59 PM > >To: Danny McPherson > >Cc: pwe3@ietf.org; swallow@cisco.com > >Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > >Danny - > > > >> MPLS->PW label->MPLS PID->RTP->PW CW->PW Payload > > > >Just what is this MPLS PID that you're hanging you hat on? > > > >No standard or MPLS wg document exists. There is no item in the MPLS > >charter. > > > >I do not see the MPLS group doing a standards track 4 byte payload > >type ID. All I want MPLS to do is write an informational document > >citing the issues of ECMP and recomending the above use of the first > >nibble of a non-IP payload. > > > >So as far as I'm concerned what folks are calling the "MPLS PID" is > >merely a variant of the PW CW. And your diagram is: > > > >MPLS->PW label->PW CW->RTP->PW CW->PW Payload > > > >...George > > > >=============================================================== > >========= > >George Swallow Cisco Systems > >(978) 936-1398 > > 1414 Massachusetts Avenue > > Boxborough, MA 01719 > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Tue, 6 May 2003 09:22:33 +0100 Lines: 130 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: stbryant@cisco.com, ronc@lyciumnetworks.com, Tim.Frost@zarlink.com, Andy.Malis@vivacenetworks.com, pwe3@ietf.org, yaakov_s@rad.com X-From: pwe3-admin@ietf.org Tue May 06 10:31:58 2003 Return-path: To: akiva@AXERRA.com, Shahram_Davari@pmc-sierra.com, Sasha@AXERRA.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Akiva....Effectively yes, but to be absolutely clear what my point is: - in a client/server relationship between 2 layer network technologies X/Y, X and Y should be functionally independent, and the mapping of the client into the server payload should be simple adaptation, ie do not create (what are starting to look like) 'in-between' layer networks by defining functions which are part of the adaptation; - if the client is consistent over the life of the server trail than I agree with you there is no need for a server layer PID.......note carefully the words *server layer PID*, because that is where this function should reside (if it exists) and *not* in some 'in-between' layer. So a PW PID is a 'bad thing' per se IMO. - functions are starting to appear in the adaptation and creating an 'in-between' PW layer as a consequence of (i) not recognising/accepting that X/IP and X/MPLS are not the same architecturally, and (ii) trying to compensate for deficiencies in either the client or server layer functional specification. - The PID has emerged IMO to fix an MPLS problem (LDP and ECMP).....not an IP problem. Right answer is to fix the MPLS layer and not bodge the adaptation. - a related concern is that someone may use the PID to identify 'PW OAM'.....I have seen proposals for this. This reinforces my point about creating an in-between layer with unnecessary functional components.......and this is why I responded to you the way I did in the mail below. Hopefully you can piece all these observations together and understand why I have some serious architectural concerns about where all this stuff is heading. regards, Neil > -----Original Message----- > From: Akiva Sadovski [mailto:akiva@AXERRA.com] > Sent: 05 May 2003 15:28 > To: Harrison,N,Neil,IKL2 R; Shahram_Davari@pmc-sierra.com; Sasha > Vainshtein > Cc: stbryant@cisco.com; ronc@lyciumnetworks.com; > Tim.Frost@zarlink.com; > Andy.Malis@vivacenetworks.com; pwe3@ietf.org; yaakov_s@rad.com > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > Neil, > thanks for your thorough explanation; > so, you suppose, the only use of PID in PWs will be to > differentiate the PWs OAM from traffic ? > > thanks, > Akiva > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Monday, May 05, 2003 12:11 PM > > To: Akiva Sadovski; Shahram_Davari@pmc-sierra.com; Sasha Vainshtein > > Cc: stbryant@cisco.com; ronc@lyciumnetworks.com; > > Tim.Frost@zarlink.com; Andy.Malis@vivacenetworks.com; > > pwe3@ietf.org; yaakov_s@rad.com > > Subject: RE: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) > > > > > > Akiva Sadovski wrote 04 May 2003 13:07 > > > Hi, Shahram, > > > > > > a short naive question inside... > > > > > > Sasha, You are missing the point. The point is that if MPLS > > > > PID exists, then PEs > > > > identify the payload by PID in the MPLS PID word. > > > > > > Why do we need to identify the payload ? Are we going to > > > support multiple > > > types of payloads per PW (f.ex. mix of Ethernet, ATM and TDM) ? > > > As draft-ietf-pwe3-arch states: "An inner MPLS label is used > > > to provide > > > the PW demultiplexing function". So the inner label > > > identifies PW, do we > > > need > > > additional identifier for the Payload-IN-PW ? > > > > Akiva....It's not a naive question since it has importnat > > architectural > > consequences. Let me try and answer you. > > > > There is a fundamantal requirement to distinguish an OAM pkt > > from a traffic > > pkt. But this should be done *within* the specification of > the layer > > network technology in question and not using a PID. > > > > In a properly specified technology this requirement is sorted > > up-front and > > is part of the general data-plane pkt overhead. So a PID is > > only really > > required when (as you say) we are muxing different *client* > > layer signals > > into a common *server* layer trail. Note that the OAM of the > > server layer > > trail is *constant/consistent* for any clinet layer carried > > (inc the muxed > > case) and is a function of, and only of, the server > > layer.....each of the > > clients should have their own independent OAM. > > > > PWs are *not* layer networks, though this is effectively > what PWE3 are > > unneccessarily creating ....and something we don't want to > > see. So, to > > repeat, I am *not* advocating the use of PID for OAM/traffic > > differentiation > > in the PW.....though I suspect some will be. > > > > Finally, the client/server cases of X/MPLS or X/IP are *not* > > the same cases > > architecturally. This architecturally incorrect 'assumption' > > that they are > > the same case is partially responsible for why we are > seeing functions > > appearing in the PW 'in-between' layer that are strictly not > > required....the > > other reason is poor specification of either the client or > > server layers per > > se. > > > > regards, Neil > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 11:24:44 +0300 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Tue May 06 10:35:15 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) Thread-Index: AcMTn8twKecMJMfCT2O0YMcpirbagQACR26g To: "Alexander Vainshtein" , "Shahram Davari" , "George Swallow" , "Danny McPherson" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h468Wt831975 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, I think that you have summed up the situation admirably. The purpose of the first four bits was well known to most of us, but for some reason there was an agreement not to put it in writing. I am glad Stewart came out with it at last. As you said, the problem is that some of the PW types allow the CW to be optional, and some have a non-compliant CW. As you will recall, I brought precisely these issues up in IETF55, and was angrily attacked. The invention of a 4 byte MPLS PID in order to contain the 4 bits, is in my opinion, a ridiculous waste of bandwidth. You will no doubt recall the email discussions with Ron Cohen, who was strongly advocating this route. So although we agree on the problem definition, I can not agree with your conclusions. My suggestion is much simpler and cleaner: 1) Mandate a single CW format for all PW types. For those types that require a lengthy structure pointer, an extended format (8 byte CW) should be used (as suggested by Andy in one of his emails). Note that my IETF55 suggestion of precisely this was opposed on the grounds of being wasteful in BW, by precisely those who now promote a 4 byte MPLS PID! 2) If ECMP is used, then the CW can not be omitted. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Tue, 6 May 2003 12:45:53 +0300 Lines: 85 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: , , , , X-From: pwe3-admin@ietf.org Tue May 06 11:58:12 2003 Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE chips (was Arch sections 5.4.3 and 5.4.4) Thread-Index: AcMTqLKRkoQ84llHQbGJ3u0jrvr+KQACjS6g To: , "Akiva Sadovski" , , "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h469sJ805645 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, > - in a client/server relationship between 2 layer network technologies > X/Y, X and Y should be functionally independent, and the mapping of the > client into the server payload should be simple adaptation, > ie do not create (what are starting to look like) 'in-between' layer networks > by defining functions which are part of the adaptation; While I agree in principle, sometimes such functions are absolutely required, as for example, if the server is missing a facility that the client requires. Taking the TDM over MPLS case (and I am aware that you do not like such mode conversions), MPLS does not have timing transport capabilities, and so these must be added, just as ATM AAL1 adaptation was augmented by such mechanisms (and RTP was added to UDP/IP for that matter). > - if the client is consistent over the life of the server trail That is precisely the IF. For various reasons the client may desire or be forced to change its protocol mid-stream. Tear-down and new set-up procedures tend to be expensive, the addition of a PW PID control mechanism saves that overhead, without mangling the architecture to badly. Such mechanisms are very useful and becoming more prevalent. For example, the new (AMR) speech compression for GSM/3GPP cellular networks supports 8 bit rates, from 4.75 Kbps to 12.2 Kbps. The bit rate can be changed (e.g. when needed because of congestion) on a packet-by-packet basis because of a three-bit "coder PID". Would you advocate tearing down the users call, or blocking his service for the time needed to signal the change? I doubt it. > functions are starting to appear in the adaptation and creating an > 'in-between' PW layer as a consequence of (i) not recognising/accepting that > X/IP and X/MPLS are not the same architecturally, It is not a matter of not recognizing the differences between connectionless IP and connection-oriented MPLS. It is a matter of designing a layer that is functionally independent of the layer beneath it. That is NOT what PWE has BECOME, it was part of its charter from the beginning Quote : Tunnels for PWE3 encapsulations will use IP (both versions), L2TP, or MPLS. PWE3 will coordinate closely with the L2TP WG and its technologies. . PWE3 pseudo wires will have the same specification for all underlying PSNs (i.e. there will not be specific adaptation of a pseudo wire technology for MPLS that is distinct from what is used for IP and L2TP, or differences will be the minimum necessary and will be called out clearly). We all acknowledge that IP and MPLS are different, and that MPLS is the better medium for most of our work (note how much of PWE work has focused on MPLS, and how little on IP). However, there is a lot of IP out there, and a lot of people who want these mechanisms to work over vanilla IP. Will it work as well ? Frankly no. Obviously we can't give the QoS that we need, however, it is a matter of paying for QoS. Those who are willing to pay will get the SLA, those who aren't will have to put up with best-effort. > - The PID has emerged IMO to fix an MPLS problem (LDP and > ECMP).....not an IP problem. Right answer is to fix the MPLS > layer and not bodge the adaptation. I agree that the ideal answer would be to fix the MPLS (I would settle for MPLS promising not to mis-order packets ...) However, I doubt we can accomplish this. So the old adage about engineering being accomplishing what we need to accomplish with the tools at our disposal comes into play again. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 13:47:45 +0200 Lines: 53 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B3FB210@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Tue May 06 13:02:51 2003 Return-path: To: "'George Swallow'" , "'Danny McPherson'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <89D0584BBFBFE74F9057A389BA3F239B3FB210@gaya.lycium.net> Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O George, I'm not sure why the current MPLS WG charter changes any of the arguments that led to the rough consensus on the PW architecture and layering. If the name MPLS-PID is problematic, would naming it PW-MPLS-CNV (for MPLS Convergence layer in the PW architecture draft) be ok with you? That is: MPLS->PW label->PW MPLS CNV->RTP->PW CW->PW payload Ron > > MPLS->PW label->MPLS PID->RTP->PW CW->PW Payload > > Just what is this MPLS PID that you're hanging you hat on? > > No standard or MPLS wg document exists. There is no item in > the MPLS charter. > > I do not see the MPLS group doing a standards track 4 byte > payload type ID. All I want MPLS to do is write an > informational document citing the issues of ECMP and > recomending the above use of the first nibble of a non-IP payload. > > So as far as I'm concerned what folks are calling the "MPLS > PID" is merely a variant of the PW CW. And your diagram is: > > MPLS->PW label->PW CW->RTP->PW CW->PW Payload > > ...George > > ============================================================== > ========== > George Swallow Cisco Systems > (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: #@$!!!!!??????RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 14:02:16 +0200 Lines: 14 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B3FB22B@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Tue May 06 13:12:28 2003 Return-path: To: "'Yaakov Stein'" , "'Alexander Vainshtein'" , "'Shahram Davari'" , "'George Swallow'" , "'Danny McPherson'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <89D0584BBFBFE74F9057A389BA3F239B3FB22B@gaya.lycium.net> Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, > The purpose of the first four bits was well known to most of us, > but for some reason there was an agreement not to put it in > writing. !!!!!!!!! Please, it is important for me to know these things, which are known to 'most of us'. Can you send a list of these things? If there is agreement not to send it to the list, you can reply directly to me :-). Thanks Ron From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 06:59:20 -0700 Lines: 16 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 16:04:14 2003 Return-path: To: "'George Swallow'" , Danny McPherson X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >I do not see the MPLS group doing a standards track 4 byte payload >type ID. All I want MPLS to do is write an informational document >citing the issues of ECMP and recomending the above use of the first >nibble of a non-IP payload. Is this your personal opinion or the consensus of MPLS WG? > >So as far as I'm concerned what folks are calling the "MPLS PID" is >merely a variant of the PW CW. And your diagram is: > >MPLS->PW label->PW CW->RTP->PW CW->PW Payload Why are there 2x PW CW? -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 07:02:29 -0700 Lines: 12 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 16:09:33 2003 Return-path: To: "'Sasha Vainshtein'" , "'George Swallow'" , Danny McPherson X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Why do you think that IETF is in the business of standardizing patches to proprietary implementations and not in the business of building proper architecture? -Shahram > >I think that building theories/architectures on patches is >counter-productive. > >With best regards, > Sasha Vainshtein > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: Re: IMPORTANT: Strategy for VPN work in IETF Date: Tue, 06 May 2003 10:42:03 -0400 Lines: 18 Sender: pwe3-admin@ietf.org References: <10170473728.20030505143840@psg.com> Cc: George Swallow , PPVPN , pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , =?ISO-8859-15?B?UGV0ZXJzb24sDQogICAgSm9u?= , Allison Mankin , swallow@cisco.com X-From: pwe3-admin@ietf.org Tue May 06 16:45:19 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Alex Zinin In-reply-to: Your message of "Mon, 05 May 2003 14:38:40 PDT." <10170473728.20030505143840@psg.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Alex - > Interesting that you mention this... I actually believe that if a WG > consistently needs more than one meeting slot, it is a good sign of > it having more on its plate than can efficiently deal with or poor > management of the meeting time. I thought the IESG was concerned about the overall number of Workgroups. They are much easier to create than to shut down. So if meeting twice per IETF for a short while until the work settles down lets you have one less, seems like a good idea. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 06 May 2003 11:07:29 -0400 Lines: 17 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C91A@nt-exch-yow.pmc-sierra.bc.ca> Cc: "'George Swallow'" , Danny McPherson , pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue May 06 17:16:19 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari In-reply-to: Your message of "Tue, 06 May 2003 06:59:20 PDT." <4B6D09F3B826D411A67300D0B706EFDE0115C91A@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Is this your personal opinion or the consensus of MPLS WG? Clearly it is my opinion as there is absolutely no consensus in the MPLS WG. > >MPLS->PW label->PW CW->RTP->PW CW->PW Payload > > Why are there 2x PW CW? Exactly my point. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 16:15:54 +0100 Lines: 164 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 17:19:31 2003 Return-path: To: Sasha@axerra.com, Shahram_Davari@pmc-sierra.com, swallow@cisco.com, danny@tcb.net X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha....sounds bang-on to me. I'd like to see the real problem formally recognised as such: MPLS(sic) PID is a fix for using LDP mp2p in a co pkt-sw forwarding mode, and the consequential need to run (proprietary) ECMP algorithms to effect a sort-of TE function. Further, (though I suspect this problem won't get recognised) it is not valid IMO to run a load-sharing algorithm across multiple layered networks.....fine within a *single* layer network. It is for sure not an MPLS PID as it does not belong to the MPLS layer at all, but lives in the twilight world of PWs, as yet another unneccesary function (which heaven forbid will spawn more bolt-on PW functions like OAM) to fix architectural errors which emanate in a lower server layer. Just want to see fair identification of what the real problems are.....so one day we may even do the right thing and get rid of the real problems ;-) regards, Neil > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > Sent: 06 May 2003 09:00 > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Hi all, > > I believe that George's comment has been very much in place. > > The "MPLS PID" story looks to me like following: > > 1. There was a recognized but, for some reasons, undeclared need > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > complied with this, and some did not; some others simply > declared that the CW is optional. > > 2. At some (rather late) stage, the need has been declared, > explained (which is always good!) and proposed as part of > the standard (moving the architecture document int the > Standards Track). > > 3. In order to minimize impact on some pre-standard implementations > that have either utilized the 1st nibble of the CW or used RTP > (or both), an optional opaque 32-bit word has between the PW label > (at the bottom of the label stack) and a the CW/RTP header has been > proposed as the simplest way out. The only requirement for this > block of data has been to keep its 1st nibble zeroed. > > 4. After that, this patch has been somehow "promoted" to the title > and associated status of of "MPLS PID". And this promotion has > triggered a long discussion of its possible uses far beyond the > original patchy fuctionality. > > 5. The proposals mentioned in is discussion are, IMO, paramount > to an alternative PWE3 architecture (including allocation > of a PWE3 protocol number in IP header etc.). They also include > amendments to Y.1711 which is presumably out of scope of PWE3 > (and IETF in general) etc. > And somehow the fact that existing LSRs carry IP traffic over > LSPs without any MPLS PID and will hardly be ever retrofitted > has been happily ignored by some of the participants. > > IMHO the best way out of the confusion would be to demote > "MPLS PID" to what it really is - a patch solving the ECMP > problem for the following three cases (and just for these cases): > > o PW encapsulations that do not mandate a CW, so that payload > immediately > follows the PW label. In other words, make SOME CW mandatory. > o PW encapsulations that mandate a CW but utilize its 1st nibble. > They would prepend an opaque 32-bit word with the > zeroed 1st nibble > by default, reserving an option to drop it if ECMP is > not used in > the core network. > o PW encapsulations that use RTP. They may follow the > same rules as in > the previous case, or may use weaker rules because the > first nibble > of an RTP header distinguishes it from IPv4/IPv6 > headers and this > is probably sufficient for ECMP. > > I think that building theories/architectures on patches is > counter-productive. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, May 05, 2003 11:25 PM > > To: 'George Swallow'; Danny McPherson > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > And what is your proposal for PW types that don't have their > > first nibble > > reserved (such as SONET/SDH PW)? > > > > -Shahram > > > > > > >-----Original Message----- > > >From: George Swallow [mailto:swallow@cisco.com] > > >Sent: Monday, May 05, 2003 3:59 PM > > >To: Danny McPherson > > >Cc: pwe3@ietf.org; swallow@cisco.com > > >Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > >Danny - > > > > > >> MPLS->PW label->MPLS PID->RTP->PW CW->PW Payload > > > > > >Just what is this MPLS PID that you're hanging you hat on? > > > > > >No standard or MPLS wg document exists. There is no item > in the MPLS > > >charter. > > > > > >I do not see the MPLS group doing a standards track 4 byte payload > > >type ID. All I want MPLS to do is write an informational document > > >citing the issues of ECMP and recomending the above use of > the first > > >nibble of a non-IP payload. > > > > > >So as far as I'm concerned what folks are calling the "MPLS PID" is > > >merely a variant of the PW CW. And your diagram is: > > > > > >MPLS->PW label->PW CW->RTP->PW CW->PW Payload > > > > > >...George > > > > > >=============================================================== > > >========= > > >George Swallow Cisco Systems > > >(978) 936-1398 > > > 1414 Massachusetts Avenue > > > Boxborough, MA 01719 > > > > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 08:23:07 -0700 Lines: 80 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: Danny McPherson , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 17:29:05 2003 Return-path: To: "'George Swallow'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O George, But I recall that it was you who proposed the 4 byte MPLS PID in this archived email: "So this would be my proposal for doing so: For any PWE3 control header, define the first nibble of the first word as a format identifier with the following values: Value 0 = control word as defined in PWE Arch, data 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value 1 = control word as defined in PWE Arch, OAM 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The sequence number would either be unused or used to mark the position in the sequence, that is, carry the same value as the last data PDU sent. Value 2 = PPP PID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0| reserved | PPP DLL Protocol Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Values 3 - 15 = Reserved. New PPP DLL Protcol numbers would then be defined to indentify the further contents, such as the Sonet encaps. ...George" -Shahram >-----Original Message----- >From: George Swallow [mailto:swallow@cisco.com] >Sent: Tuesday, May 06, 2003 11:07 AM >To: Shahram Davari >Cc: 'George Swallow'; Danny McPherson; pwe3@ietf.org; swallow@cisco.com >Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > >> Is this your personal opinion or the consensus of MPLS WG? > >Clearly it is my opinion as there is absolutely no consensus in the >MPLS WG. > >> >MPLS->PW label->PW CW->RTP->PW CW->PW Payload >> >> Why are there 2x PW CW? > >Exactly my point. > >...George > >=============================================================== >========= >George Swallow Cisco Systems >(978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 06 May 2003 11:25:13 -0400 Lines: 9 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 17:30:50 2003 Return-path: To: Danny McPherson In-reply-to: Your message of Fri, 02 May 2003 15:55:57 -0600. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Now I'm confused. I thought this thread had something to do with TDM and/or RTP, and didn't pay much attention. Frankly, I don't care how the TDM and RTP stuff works out. As long as it doesn't affect the layer 2 service encapsulations. Has something been proposed that would change the layer 2 service encapsulations? If so, we need to make it clear that everyone understands that, so that we can kill it. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 16:15:56 +0100 Lines: 65 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 17:46:00 2003 Return-path: To: swallow@cisco.com, danny@tcb.net X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O George...The MPLS PID is not an *MPLS* PID at all....it is a *PW* PID. If it was an *MPLS* layer PID it would belong to the MPLS layer networks.....but it doesn't. It lives in the 'in-between-layer' world of PWs. So I have to agree with your conclusion (MPLS(sic) PID == PW CW), but I have my own reasons.....based on trying to get people to think a bit more architecturally about what is going on and why, rather than just creating ad hoc/expedient fixes to problems that actually reside in other layer networks (eg see my recent mail to Akiva). Maybe its too late now (at least for the current crop of PWE3 stuff)? But we should be striving for far more architectural rigour in IETF IMO....and this means recognising/accepting the world is not just cnls/IP, and that there are valid/important technologies that belong to co cct-sw and co pkt-sw modes whose required functional behaviour/specifications are quite different to the cnls mode. We operators need all all these modes. So we should stop trying to make them look like they are all the 'same'. We can, as an industry/community, do things much better IMO. I hope/pray others can also see the logic in this. regards, Neil > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: 05 May 2003 20:59 > To: Danny McPherson > Cc: pwe3@ietf.org; swallow@cisco.com > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Danny - > > > MPLS->PW label->MPLS PID->RTP->PW CW->PW Payload > > Just what is this MPLS PID that you're hanging you hat on? > > No standard or MPLS wg document exists. There is no item in the MPLS > charter. > > I do not see the MPLS group doing a standards track 4 byte payload > type ID. All I want MPLS to do is write an informational document > citing the issues of ECMP and recomending the above use of the first > nibble of a non-IP payload. > > So as far as I'm concerned what folks are calling the "MPLS PID" is > merely a variant of the PW CW. And your diagram is: > > MPLS->PW label->PW CW->RTP->PW CW->PW Payload > > ...George > > ============================================================== > ========== > George Swallow Cisco Systems > (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Peterson, Jon" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 5 May 2003 12:28:56 -0400 Lines: 24 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , Allison Mankin X-From: pwe3-admin@ietf.org Tue May 06 17:52:53 2003 Return-path: To: "'Yaakov Stein'" , Alex Zinin X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O [snip] > > My only concern is regarding network congestion issues. > It has been stated that PWE was originally placed in the > transport area due to that area being the proper place to handle > congestion avoidance and mitigation. > As the WG has only recently stated to seriously consider > these issues, we should give some thought as to how > to keep them in focus even after an area transplant. > After the proposed relocation of this group to the Internet Area, a Transport Area Advisor would be appointed to PWE3 to provide continuing guidance on transport issues, including congestion. Jon Peterson NeuStar, Inc. Transport Co-AD > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 06 May 2003 11:44:25 -0400 Lines: 12 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C91C@nt-exch-yow.pmc-sierra.bc.ca> Cc: "'George Swallow'" , Danny McPherson , pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue May 06 18:02:31 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari In-reply-to: Your message of "Tue, 06 May 2003 08:23:07 PDT." <4B6D09F3B826D411A67300D0B706EFDE0115C91C@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > But I recall that it was you who proposed the 4 byte MPLS PID in this > archived email: I didn't propose an "MPLS PID", I proposed alternate forms for the PW CW. It's one thing. Not two. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 09:01:35 -0700 Lines: 43 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: Danny McPherson , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 18:15:48 2003 Return-path: To: "'George Swallow'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > >I didn't propose an "MPLS PID", I proposed alternate forms for the PW >CW. It's one thing. Not two. > >...George > Let's forget about the term "MPLS PID". What I can't understand is how the following 2 formats could be the same thing? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value 2 = PPP PID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0| reserved | PPP DLL Protocol Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ New PPP DLL Protocol numbers would then be defined to identify the further contents, such as the Sonet encaps. Specially when you propose that SONET encap could follow the latter header. The SONET format has a pointer, bunch of flags, sequence # etc called CEP header (architecture draft calls it CW). Where should this go? If they follow your proposed header, then based on your proposal the format for SONET PW would be: MPLS->PW label->Your proposed header->RTP-> CEP header ->PW Payload right? If so then we have two things not one. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 06 May 2003 13:26:05 -0400 Lines: 31 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C91D@nt-exch-yow.pmc-sierra.bc.ca> Cc: "'George Swallow'" , Danny McPherson , pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue May 06 19:31:28 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari In-reply-to: Your message of "Tue, 06 May 2003 09:01:35 PDT." <4B6D09F3B826D411A67300D0B706EFDE0115C91D@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Let's forget about the term "MPLS PID". What I can't understand > is how the following 2 formats could be the same thing? When you set up a PW circuit you say what is going down it. All the second format gives you is an inband communication channel for that circuit. Similar to a DCC channel in SONET/SDH. > Specially when you propose that SONET encap could follow the latter header. I haven't proposed anything with regard to SONET encap. I've only commented on the diagram that Danny showed. As far as I'm concerned, the first thing after the PW label should be the PW CW. What you call things beyond that, or what order they go in is not my present concern. Just don't put in a second PW CW. ...George > The SONET format has a pointer, bunch of flags, sequence # etc called CEP > header (architecture draft calls it CW). Where should this go? > If they follow your proposed header, then based on your proposal > the format for SONET PW would be: > > MPLS->PW label->Your proposed header->RTP-> CEP header ->PW Payload > > right? If so then we have two things not one. ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 10:46:43 -0700 Lines: 34 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: Danny McPherson , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 19:54:05 2003 Return-path: To: "'George Swallow'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >I haven't proposed anything with regard to SONET encap. I meant in your email that I quoted from a few weeks ago. In that email you said: "New PPP DLL Protocol numbers would then be defined to identify the further contents, such as the Sonet encaps." My understanding of this sentence is that SONET Encap should follow your proposed header or whatever you like to call it. >I've only >commented on the diagram that Danny showed. As far as I'm concerned, >the first thing after the PW label should be the PW CW. The issue is What do you mean by PW CW? do you mean the 4-byte header that provides details such as seq#, length, flags, pointer, etc? If so then please explain to me what are you proposing here: " 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0| reserved | PPP DLL Protocol Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should this replace the SONET CW (i.e., CEP header), precede it or follow it? -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 06 May 2003 18:45:28 +0100 Organization: Cisco Systems, Inc. Lines: 17 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D67D4@i2km07-ukbr.domain1.systemhost.net> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 19:55:06 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: neil.2.harrison@bt.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O neil.2.harrison@bt.com wrote: > George...The MPLS PID is not an *MPLS* PID at all....it is a *PW* PID. If > it was an *MPLS* layer PID it would belong to the MPLS layer > networks.....but it doesn't. It lives in the 'in-between-layer' world of > PWs. > Can we mandate that the only payloads EVER to run over MPLS will be IP and PWE3? If yes, then the PID is a component of PW. If no, then the PID is a component of MPLS. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 06 May 2003 14:16:01 -0400 Lines: 19 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D67D4@i2km07-ukbr.domain1.systemhost.net> Cc: swallow@cisco.com, danny@tcb.net, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue May 06 20:18:27 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: neil.2.harrison@bt.com In-reply-to: Your message of "Tue, 06 May 2003 16:15:56 BST." <0536FC9B908BEC4597EE721BE6A35389025D67D4@i2km07-ukbr.domain1.systemhost.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil - > George...The MPLS PID is not an *MPLS* PID at all....it is a *PW* PID. If > it was an *MPLS* layer PID it would belong to the MPLS layer > networks.....but it doesn't. It lives in the 'in-between-layer' world of > PWs. > > So I have to agree with your conclusion (MPLS(sic) PID == PW CW), but I have > my own reasons.....based on trying to get people to think a bit more > architecturally... In this case, I don't think our reasons are all that different ;-). ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 14:20:51 -0400 Lines: 474 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313FC.3837415C" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 20:24:12 2003 Return-path: To: "'Sasha Vainshtein'" , "'Shahram Davari'" , "'George Swallow'" , Danny McPherson X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C313FC.3837415C Content-Type: text/plain; charset="iso-8859-8" We do have two separate problems.... 1) Is a means of identifying a generic payload. This would appear to potentially require additional services such as sequencing etc. stuff already dealt with in the exissting PWE control words. This would include ordering, and if this was preserved in the presence of proprietary ECMP so much the better. 2) A means of instrumenting PWs such that packets fate shares with PW forwarding. Tom has proposed VCCV which needs an available bit in the CW and control handshaking to agree on what the bit means. The PPP DLL approach (Georges proposal) or my proposal permits the instrumenting protocol to self identify and therefore IMHO is preferable. But I am skeptical that simply having a protocol identifier means a PW can carry anything. Its not designed with the requisite attributes for service bearing. If we want "carry anything" with ordering fragmentation etc. we have more to do. my 2 cents Dave > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > Sent: Tuesday, May 06, 2003 4:00 AM > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Hi all, > > I believe that George's comment has been very much in place. > > The "MPLS PID" story looks to me like following: > > 1. There was a recognized but, for some reasons, undeclared need > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > complied with this, and some did not; some others simply > declared that the CW is optional. > > 2. At some (rather late) stage, the need has been declared, > explained (which is always good!) and proposed as part of > the standard (moving the architecture document int the > Standards Track). > > 3. In order to minimize impact on some pre-standard implementations > that have either utilized the 1st nibble of the CW or used RTP > (or both), an optional opaque 32-bit word has between the PW label > (at the bottom of the label stack) and a the CW/RTP header has been > proposed as the simplest way out. The only requirement for this > block of data has been to keep its 1st nibble zeroed. > > 4. After that, this patch has been somehow "promoted" to the title > and associated status of of "MPLS PID". And this promotion has > triggered a long discussion of its possible uses far beyond the > original patchy fuctionality. > > 5. The proposals mentioned in is discussion are, IMO, paramount > to an alternative PWE3 architecture (including allocation > of a PWE3 protocol number in IP header etc.). They also include > amendments to Y.1711 which is presumably out of scope of PWE3 > (and IETF in general) etc. > And somehow the fact that existing LSRs carry IP traffic over > LSPs without any MPLS PID and will hardly be ever retrofitted > has been happily ignored by some of the participants. > > IMHO the best way out of the confusion would be to demote > "MPLS PID" to what it really is - a patch solving the ECMP > problem for the following three cases (and just for these cases): > > o PW encapsulations that do not mandate a CW, so that payload > immediately > follows the PW label. In other words, make SOME CW mandatory. > o PW encapsulations that mandate a CW but utilize its 1st nibble. > They would prepend an opaque 32-bit word with the > zeroed 1st nibble > by default, reserving an option to drop it if ECMP is > not used in > the core network. > o PW encapsulations that use RTP. They may follow the > same rules as in > the previous case, or may use weaker rules because the > first nibble > of an RTP header distinguishes it from IPv4/IPv6 > headers and this > is probably sufficient for ECMP. > > I think that building theories/architectures on patches is > counter-productive. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Monday, May 05, 2003 11:25 PM > > To: 'George Swallow'; Danny McPherson > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > And what is your proposal for PW types that don't have their > > first nibble > > reserved (such as SONET/SDH PW)? > > > > -Shahram > > > > > > >-----Original Message----- > > >From: George Swallow [mailto:swallow@cisco.com] > > >Sent: Monday, May 05, 2003 3:59 PM > > >To: Danny McPherson > > >Cc: pwe3@ietf.org; swallow@cisco.com > > >Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > >Danny - > > > > > >> MPLS->PW label->MPLS PID->RTP->PW CW->PW Payload > > > > > >Just what is this MPLS PID that you're hanging you hat on? > > > > > >No standard or MPLS wg document exists. There is no item > in the MPLS > > >charter. > > > > > >I do not see the MPLS group doing a standards track 4 byte payload > > >type ID. All I want MPLS to do is write an informational document > > >citing the issues of ECMP and recomending the above use of > the first > > >nibble of a non-IP payload. > > > > > >So as far as I'm concerned what folks are calling the > "MPLS PID" is > > >merely a variant of the PW CW. And your diagram is: > > > > > >MPLS->PW label->PW CW->RTP->PW CW->PW Payload > > > > > >...George > > > > > >=============================================================== > > >========= > > >George Swallow Cisco Systems > > >(978) 936-1398 > > > 1414 Massachusetts Avenue > > > Boxborough, MA 01719 > > > > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C313FC.3837415C Content-Type: text/html; charset="iso-8859-8" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) =

We do have two separate problems....

1) Is a means of identifying a generic payload. This = would appear to potentially require additional services such as = sequencing etc. stuff already dealt with in the exissting PWE control = words. This would include ordering, and if this was preserved in the = presence of proprietary ECMP so much the better.

2) A means of instrumenting PWs such that packets = fate shares with  PW forwarding. Tom has proposed VCCV which needs = an available bit in the CW and control handshaking to agree on what the = bit means. The PPP DLL approach (Georges proposal) or my proposal = permits the instrumenting protocol to self identify and therefore IMHO = is preferable.

But I am skeptical that simply having a protocol = identifier means a PW can carry anything. Its not designed with the = requisite attributes for service bearing. If we want "carry = anything" with ordering fragmentation etc. we have more to = do.

my 2 cents
Dave



> -----Original Message-----
> From: Sasha Vainshtein [mailto:Sasha@axerra.com]
> Sent: Tuesday, May 06, 2003 4:00 AM
> To: 'Shahram Davari'; 'George Swallow'; Danny = McPherson
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PWE3 Arch/CW & RTP = Order (Rough Consesus?)
>
>
> Hi all,
>
> I believe that George's comment has been very = much in place.
>
> The "MPLS PID" story looks to me like = following:
>
> 1. There was a recognized but, for some = reasons, undeclared need
>    to keep the 1st nibble of a = PW CW zeroed. Some PWE3 drafts
>    complied with this, and some = did not; some others simply
>    declared that the CW is = optional.
>
> 2. At some (rather late) stage, the need has = been declared,
>    explained (which is always = good!) and proposed as part of
>    the standard (moving the = architecture document int the
>    Standards Track).
>
> 3. In order to minimize impact on some = pre-standard implementations
>    that have either utilized the = 1st nibble of the CW or used RTP
>    (or both), an optional opaque = 32-bit word has between the PW label
>    (at the bottom of the label = stack) and a the CW/RTP header has been
>    proposed as the simplest way = out. The only requirement for this
>    block of data has been to = keep its 1st nibble zeroed.
>
> 4. After that, this patch has been somehow = "promoted" to the title
>    and associated status of of = "MPLS PID". And this promotion has
>    triggered a long discussion = of its possible uses far beyond the
>    original patchy = fuctionality.
>
> 5. The proposals mentioned in is discussion = are, IMO, paramount
>    to an alternative PWE3 = architecture (including allocation
>    of a PWE3 protocol number in = IP header etc.). They also include
>    amendments to Y.1711 which is = presumably out of scope of PWE3
>    (and IETF in general) = etc.
>    And somehow the fact that = existing LSRs carry IP traffic over
>    LSPs without any MPLS PID and = will hardly be ever retrofitted
>    has been happily ignored by = some of the participants.
>
> IMHO the best way out of the confusion would be = to demote
> "MPLS PID" to what it really is - a = patch solving the ECMP
> problem for the following three cases (and just = for these cases):
>
> o     PW encapsulations = that do not mandate a CW, so that payload
> immediately
>       follows the PW = label. In other words, make SOME CW mandatory.
> o     PW encapsulations = that mandate a CW but utilize its 1st nibble.
>       They would = prepend an opaque 32-bit word with the
> zeroed 1st nibble
>       by default, = reserving an option to drop it if ECMP is
> not used in
>       the core = network.
> o     PW encapsulations = that use RTP. They may follow the
> same rules as in
>       the previous = case, or may use weaker rules because the
> first nibble
>       of an RTP header = distinguishes it from IPv4/IPv6
> headers and this
>       is probably = sufficient for ECMP.
>
> I think that building theories/architectures on = patches is
> counter-productive.
>
> With best regards,
>          = ;            = ;            = ;  Sasha Vainshtein
> email:     sasha@axerra.com = <mailto:sasha@axerra.com> =
> tel:       = +972-3-7659993 (office)
>          = ;  +972-8-9254948 (res.)
>          = ;  +972-58-674833 (cell.)
> 
>
>
> > -----Original Message-----
> > From: Shahram Davari [mailto:Shahram_Davari@pmc-= sierra.com]
> > Sent: Monday, May 05, 2003 11:25 PM
> > To: 'George Swallow'; Danny = McPherson
> > Cc: pwe3@ietf.org
> > Subject: RE: [PWE3] PWE3 Arch/CW & RTP = Order (Rough Consesus?)
> >
> >
> > And what is your proposal for PW types = that don't have their
> > first nibble
> > reserved (such as SONET/SDH PW)?
> >
> > -Shahram
> >
> >
> > >-----Original Message-----
> > >From: George Swallow [mailto:swallow@cisco.com]
> > >Sent: Monday, May 05, 2003 3:59 = PM
> > >To: Danny McPherson
> > >Cc: pwe3@ietf.org; = swallow@cisco.com
> > >Subject: Re: [PWE3] PWE3 Arch/CW & = RTP Order (Rough Consesus?)
> > >
> > >
> > >Danny -
> > >
> > >> MPLS->PW label->MPLS = PID->RTP->PW CW->PW Payload
> > >
> > >Just what is this MPLS PID that you're = hanging you hat on?
> > >
> > >No standard or MPLS wg document = exists.  There is no item
> in the MPLS
> > >charter.
> > >
> > >I do not see the MPLS group doing a = standards track 4 byte payload
> > >type ID.  All I want MPLS to do = is write an informational document
> > >citing the issues of ECMP and = recomending the above use of
> the first
> > >nibble of a non-IP payload.
> > >
> > >So as far as I'm concerned what folks = are calling the
> "MPLS PID" is
> > >merely a variant of the PW CW.  = And your diagram is:
> > >
> > >MPLS->PW label->PW = CW->RTP->PW CW->PW Payload
> > >
> > >...George
> > >
> > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >George = Swallow           = ;  Cisco = Systems           = ;      
> > >(978) 936-1398
> > = >           &n= bsp;           &n= bsp;   1414 Massachusetts Avenue
> > = >           &n= bsp;           &n= bsp;   Boxborough, MA 01719
> > >
> > = >_______________________________________________
> > >pwe3 mailing list
> > >pwe3@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/pwe3=
> > >
> > = _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3=
> >
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C313FC.3837415C-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 22:04:20 +0200 Lines: 20 Sender: pwe3-admin@ietf.org References: <3EB7F4B8.30503@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , , X-From: pwe3-admin@ietf.org Tue May 06 21:07:34 2003 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3EB7F4B8.30503@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Exactly! This is why I believe MPLS-PID is a reasonable name for this layer. > Can we mandate that the only payloads EVER to run over MPLS > will be IP and PWE3? > > If yes, then the PID is a component of PW. > > If no, then the PID is a component of MPLS. > > Stewart > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 22:04:20 +0200 Lines: 74 Sender: pwe3-admin@ietf.org References: <200305061726.NAA28054@bifocal.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Danny McPherson'" , X-From: pwe3-admin@ietf.org Tue May 06 21:10:01 2003 Return-path: To: "'George Swallow'" , "'Shahram Davari'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200305061726.NAA28054@bifocal.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O George, > I haven't proposed anything with regard to SONET encap. I've > only commented on the diagram that Danny showed. As far as > I'm concerned, the first thing after the PW label should be > the PW CW. Why? Why not RTP, or foo? All you said up till now is that you don't want to define 4 bytes MPLS PID in the MPLS WG. What are your technical arguments? > What you call things beyond that, or what order > they go in is not my present concern. Just don't put in a > second PW CW. First you change the name of the first 4 bytes from MPLS-PID to PW CW, and then argue that it doesn't make sense to have two. Interesting. Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of George Swallow > Sent: Tuesday, May 06, 2003 7:26 PM > To: Shahram Davari > Cc: 'George Swallow'; Danny McPherson; pwe3@ietf.org; > swallow@cisco.com > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > Let's forget about the term "MPLS PID". What I can't understand > > is how the following 2 formats could be the same thing? > > When you set up a PW circuit you say what is going down it. > All the second format gives you is an inband communication > channel for that circuit. Similar to a DCC channel in SONET/SDH. > > > Specially when you propose that SONET encap could follow the latter > > header. > > I haven't proposed anything with regard to SONET encap. I've > only commented on the diagram that Danny showed. As far as > I'm concerned, the first thing after the PW label should be > the PW CW. What you call things beyond that, or what order > they go in is not my present concern. Just don't put in a > second PW CW. > > ...George > > > The SONET format has a pointer, bunch of flags, sequence # > etc called > > CEP header (architecture draft calls it CW). Where should > this go? If > > they follow your proposed header, then based on your proposal the > > format for SONET PW would be: > > > > MPLS->PW label->Your proposed header->RTP-> CEP header ->PW Payload > > > > right? If so then we have two things not one. > > > ============================================================== > ========== > George Swallow Cisco Systems > (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 06 May 2003 15:51:06 -0400 Lines: 17 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C920@nt-exch-yow.pmc-sierra.bc.ca> Cc: "'George Swallow'" , Danny McPherson , pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue May 06 21:53:40 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari In-reply-to: Your message of "Tue, 06 May 2003 10:46:43 PDT." <4B6D09F3B826D411A67300D0B706EFDE0115C920@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram - > "New PPP DLL Protocol numbers would then be defined to identify the > further contents, such as the Sonet encaps." I recant. Bad idea. If you stick a PID in there, then you're PW circuit is really some generalized LSP. So I would (now) stick with using LDP to signal the payload as SONET. If also signal that you have a PW CW you can then use the PID format as well, but only as a DCC. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 6 May 2003 21:14:25 +0100 Lines: 28 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 22:26:40 2003 Return-path: To: stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, > neil.2.harrison@bt.com wrote: > > George...The MPLS PID is not an *MPLS* PID at all....it is > a *PW* PID. If > > it was an *MPLS* layer PID it would belong to the MPLS layer > > networks.....but it doesn't. It lives in the > 'in-between-layer' world of > > PWs. > > > > Can we mandate that the only payloads EVER to run over MPLS will be IP > and PWE3? NH=> PWE3 is not a real layer network that I recognise, whereas IP (and MPLS) are. > > If yes, then the PID is a component of PW. NH=> But PWs are artifical/unnecessary....that is the whole point of my observations. > > If no, then the PID is a component of MPLS. NH=> Could be. But then why are they artifically attached to the PW layer? The only answer I have is (i) to try and make IP/X appear the same as X/MPLS (which is not arch sensible) and (ii) to cater for the (wrong) usage of ECMP across MPLS due to LDP (which again is not sensible....deprecate LDP mp2p is however sensible). MPLS originally assumed consistent client mappings to an LSP over its lifetime, so there was no need for a PID in the data-plane. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE chips (was Arch sections 5.4.3 and 5.4.4) Date: Tue, 6 May 2003 20:19:01 +0100 Lines: 104 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: stbryant@cisco.com, ronc@lyciumnetworks.com, Tim.Frost@zarlink.com, Andy.Malis@vivacenetworks.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 06 22:32:53 2003 Return-path: To: yaakov_s@rad.com, akiva@axerra.com, Shahram_Davari@pmc-sierra.com, sasha@axerra.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Yaakov.....please see below. regards, Neil > > > - in a client/server relationship between 2 layer network > technologies > > X/Y, X and Y should be functionally independent, and the > mapping of the > > client into the server payload should be simple adaptation, > > ie do not create (what are starting to look like) > 'in-between' layer networks > > by defining functions which are part of the adaptation; > > While I agree in principle, sometimes such functions are > absolutely required, > as for example, if the server is missing a facility that the > client requires. NH=> I think to be strictly accurate (in what follows) its the application's adaptation to the *immediately adjacent* layer network that requires the functionality (and not the server per se)....which is why one adapts a CBR application to an ATM layer network via AAL1. Hope you see the subtle point I am making here. So the adaptation: application=>AAL1=>MPLS would do the job fine. > Taking the TDM over MPLS case (and I am aware that you do not > like such mode conversions), NH=> Not strictly true for case given. The co cct-sw mode over a co pkt-sw mode is possible (eg ATM)....its the transport over a cnls mode that is the cause for concern. And which is why I say X/MPLS is not the same as X/IP.....I don't really understand why people are so afraid to acknowledge this. > MPLS does not have timing transport capabilities, and so > these must be added, > just as ATM AAL1 adaptation was augmented by such mechanisms > (and RTP was added to UDP/IP for that matter). NH=> Exactly my point above. So let's use AAL1 over any co pkt-sw mode....makes lots of sense to me.....even stops having to have gateways at the *application* interfacing level. > > functions are starting to appear in the adaptation and creating an > > 'in-between' PW layer as a consequence of (i) not > recognising/accepting that > > X/IP and X/MPLS are not the same architecturally, > > It is not a matter of not recognizing the differences between > connectionless IP and connection-oriented MPLS. > It is a matter of designing a layer that is functionally > independent of the layer beneath it. > That is NOT what PWE has BECOME, > it was part of its charter from the beginning > Quote : > Tunnels for PWE3 encapsulations will use IP (both versions), L2TP, > or MPLS. PWE3 will coordinate closely with the L2TP WG and its > technologies. . PWE3 pseudo wires will have the same specification > for all underlying PSNs (i.e. there will not be specific adaptation > of a pseudo wire technology for MPLS that is distinct from what is > used for IP and L2TP, or differences will be the minimum necessary > and will be called out clearly). > > We all acknowledge that IP and MPLS are different, > and that MPLS is the better medium for most of our work > (note how much of PWE work has focused on MPLS, > and how little on IP). > > However, there is a lot of IP out there, and a lot of people > who want these mechanisms to work over vanilla IP. > > Will it work as well ? Frankly no. > Obviously we can't give the QoS that we need, > however, it is a matter of paying for QoS. > > Those who are willing to pay will get the SLA, > those who aren't will have to put up with best-effort. NH=> I think you answered your own observation as to why a consistent 'in-between' layer cannot do what it is alledged to do.....so OK, it looks like it does as a sop (we are in the IETF right, so it must have a solution in IP too else its not palatable.....though no such qualms when dealing with a co cct-sw mode such as SDH in GMPLS is there?). My interpretation of this is: 'let's agree to delude ourselves in the case of MPLS'. > > > > - The PID has emerged IMO to fix an MPLS problem (LDP and > > ECMP).....not an IP problem. Right answer is to fix the MPLS > > layer and not bodge the adaptation. > > I agree that the ideal answer would be to fix the MPLS > (I would settle for MPLS promising not to mis-order packets ...) NH=> That would be a very good start....but, if this Seq No stuff lives-on, then we can't really leave the defect behaviour 'open-ended' as I have explained in previous mails.....at some stage consequent actions are required, so entry and exit criteria ought to be (consistently) specified. > However, I doubt we can accomplish this. NH=> It's not that hard.....its not really a question of 'adding' stuff, but taking stuff 'away' IMO. The only hard bit is letting the bad stuff go I guess. > > So the old adage about engineering being accomplishing > what we need to accomplish with the tools at our disposal > comes into play again. NH=> I know....sigh.....but one would think we really ought to learn as we go along. regards, Neil From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: "Hamid Ould-Brahim" Subject: RE: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF Date: Tue, 6 May 2003 17:01:31 -0400 Lines: 96 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31412.AB7B3A54" Cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Tue May 06 23:01:52 2003 Return-path: To: "Nagarajan, Ananth [CC]" , Alex Zinin , ppvpn@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2653.19) Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C31412.AB7B3A54 Content-Type: text/plain; charset="utf-8" Ananth, >If, in fact, the WG does split, then we also need to think about >what to do with a few documents such as the generic reqts draft, >that will be ready for IESG last call this week, that really is >an umbrella document for both L2 and L3 VPNs. Similarly, I think >we have the terminology draft too that we need to determine what to do with. The bgp auto-discovery draft covers as well both layer-3 and layer-2 vpns. But besides the "what to do with these common drafts question?", we need to ask ourselves why these drafts were created in the first place. For example isn't the generic requirement document covers common requirements for layer-2 and layer3 vpns. The simple existence of these drafts indicate that there is a belief within the wg that layer-2 and layer-3 vpns share something in common such as service attributes, topology, security, etc (documented in this draft). On that topic, if later on there are proposals that apply to both layer-2 and layer-3 vpns, where these proposals need to be captured, on what charter... One way or the other, the 'link', whatever that might be (protocols, service characteristics, etc), between layer-2 and layer-3 work needs to be taken into account and splitting the wg will somehow eliminate the need to explore this side of the vpn problem. Hamid. ------_=_NextPart_001_01C31412.AB7B3A54 Content-Type: text/html; charset="utf-8" RE: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF

Ananth,

>If, in fact, the WG does split, then we also need to think about
>what to do with a few documents such as the generic reqts draft,
>that will be ready for IESG last call this week, that really is
>an umbrella document for both L2 and L3 VPNs.  Similarly, I think
>we have the terminology draft too that we need to determine what to do with.

The bgp auto-discovery draft covers as well
both layer-3 and layer-2 vpns.

But besides the "what to do with these common drafts
question?", we need to ask ourselves why these drafts
were created in the first place. For example isn't
the generic requirement document covers common
requirements for layer-2 and layer3 vpns. The simple
existence of these drafts indicate that there is
a belief within the wg that layer-2 and layer-3 vpns
share something in common such as service attributes, topology,
security, etc (documented in this draft).

On that topic, if later on there are proposals that
apply to both layer-2 and layer-3 vpns, where these
proposals need to be captured, on what charter...
One way or the other, the 'link', whatever that might be
(protocols, service characteristics, etc), between layer-2
and layer-3 work needs to be taken into account and splitting
the wg will somehow eliminate the need to explore
this side of the vpn problem.

Hamid.

------_=_NextPart_001_01C31412.AB7B3A54-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Thomas Narten Subject: Re: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 07 May 2003 12:24:18 -0400 Lines: 124 Sender: pwe3-admin@ietf.org References: <3EB5E991.5040604@nxp.com> Cc: Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin X-From: pwe3-admin@ietf.org Wed May 07 18:42:53 2003 Return-path: To: Waldemar Augustyn In-Reply-To: Message from waldemar@nxp.com of "Mon, 05 May 2003 00:33:21 EDT." <3EB5E991.5040604@nxp.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Catching up a bit (and summarizing)... Waldemar Augustyn writes: > as the co-originator, with Tissa, of the L2 VPN work within PPVPN, I > would like to say I am glad to see this effort finally recognized as > significant. But the two year delay does not impress me. What is being > proposed should have been done at that time, two years ago. At the very > least, the charter of ppvpn should have been adjusted as it was promised > but never done. As the likely Area Advisor for these WGs, I think it is important to get the charters updated so that the WG and the ADs (and IESG) are in sync. Doing so sooner rather than later tends minimize (later) problems. (Note: this is true in general and if we end up moving these WGs to INT, doing this as part of the move seems logical, which is why I'm now following this all more closely.) > It appears, what we're talking about is playing catch up. The issue is > really the charter which makes no sense, but I do not see the point of > splitting the WG after these years. My understanding after having looked at the work as that there are something like 12-13 IDs on L3 VPNs in the pipeline. That's no small number and suggests that an L3 focused WG still has plenty on its plate. Eric Rosen writes: > 1. Before being comfortable with a reorganization, I'd like to see what the > new charters will be. I'd particularly like to be sure that the L3VPN > charter is not constructed so as to cause a reset. Same with the PWE3 > charter; we don't want to have to refight old wars. Fair enough. I don't think a PWE3 revised charter has even been drafted yet, but for the L2/L3 there are drafts (somewhere). Stay tuned. > 2. From ground level, the most important aspect of a particular WG being in > a particular area is the attitude of that area's ADs towards the work > that the WG is doing. This is an unknown to us. Given that at least one > IESG member (though not one involved in this reorg) has been quoted in > the trade tabloids as saying that this work is all a scam which will > destroy the network, you can see why we might react cautiously to any > proposed change. I don't know that I've been quoted on the press on this topic, so I'll assume the referal is to someone else. :-) Bottom line is that I'm fairly agnostic about the technology. I understand that there is a need for it, folks seem to want to do it, and there is a WG in place that is well on its way towards doing the work. I don't see a need to revisit such basic questions. But I am interested in seeing the WG complete work in a reasonable fashion in a way that when the documents make it to the IESG, there are no suprises and I can make the case that the work is baked/solid and there are no serious issues the WG neglected to consider. More on this over the next few weeks, I expect. As one example, on the topic of "one vs. multiple solutions", I know the IESG will ask, why are we standardizing 3 solutions to the same problem (if that is what the WG thinks it is going to do). The WG will have to be able to answer that sort of question with a credible response (and in some cases, a credible justification is that the solutions are very different and there are different applicabilities to the mechanisms -- but one needs to look at the details on this). If the answer simply is "because we want to and we'll let the market decide", the IESG may well come back and say fine, make them all experimental, none of them on standards track. Revisit when the market has decided. Would that be what the WG wants? Would that be in the best interests of the IETF and Internet community? I wonder. "Hamid Ould-Brahim" writes: > Wouldn't be more appropriate to first discuss what these concerns > are and if they are indeed justified concerns, and solicit feedback > from the wg to discuss options or improvements on how to move the wg > forward and get consensus on that. If I recall, similar open > approach has been taken for sup-ip area in Atlanta meeting. Sometimes, public discussions aren't the best way to deal with issues constructively. This is particularly true when it comes to management questions about WG operations. > After all, the amount of work after the split is exactly > the same as before the split if not bigger (given that > l3vpns work is almost done and the split will > introduce additional administrative overhead). But if there are two WGs, the management load is split across more chairs, so it takes less cycles (e.g., from each chair) to manage each WG. There is a basic tension in the IETF between having WGs that are too large (a similar discussion has been ongoing in places like MobileIP and IPv6 over the last year) and where splitting them up into smaller WGs can help focus them. Indeed, there have been numerious conversations about this on the problem-statement list (with one view being that smaller, focused WGs tending to do a better job of completing their work than larger ones). I tend to share that view (as a general observation), and given that there are some 13 documents in the L3 space alone, I see there being ample work for a standalone WG to take on. Will splitting up the WGs _guarantee_ this? Of course not. Does it solve all possible problems? Of course not. But it can help, and it seems reasonable in my mind to do so in this case. Yakov Rekhter writes: > As was pointed by other folks, there is practically no L3 VPN > related activities now. Practically all the discussion is about L2 > VPN, or to be even more precise, above VPLS. Just count the number > of messages posted to the list over the last 12 months related to > L3 VPNs vs L2 VPNs. The chairs themselves seem to agree that there are some 13 documents on L3 that are not through the system yet. I'm a bit concerned to hear that there has been minimal discussion on L3 topics over the last year, given the number of L3 work items that apparently need to get completed. The above could be read as indicating that the discussion/urgency of the L2 work is pushing out or drowning out discussion on L3 topics. If that is the case, a separate WG, mailing list, etc., may well help. I'm assuming the L3 work is important and should get completed. Thomas From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: "Paul Knight" Subject: RE: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 7 May 2003 12:56:24 -0400 Lines: 366 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C314B9.978C7218" Cc: pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Wed May 07 18:58:29 2003 Return-path: To: Alex Zinin , ppvpn@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2653.19) Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C314B9.978C7218 Content-Type: text/plain Hi Alex, The proposed split seems to put very little emphasis on the "PP" of PPVPN. The proposed focus on technologies for L2 and L3 is likely to seriously disrupt the focus on the "Provider Provisioned" concept, where much of the value comes from aiming for interoperation across all major VPN technologies. Of course, we could have PPL2VPN and PPL3VPN, but as has been pointed out, we then need to coordinate the "PP" parts across the two WGs. VPN customers want a bundle of VPN services, and don't really care whether it is L2 or L3 (or L1) or some mixture. VPN service providers want an interoperable toolkit which they can use to design services that they can differentiate in various ways to attract VPN customers. PPVPN is providing a forum to define the operation of the VPN tools. Regardless of L2 or L3 technologies, there is a need for simple and interoperable mechanisms for VPN membership and discovery, security considerations, SLA verification, and a host of management areas. These mechanisms are being defined, clarified, and debated in PPVPN mostly without regard to the specific L2 or L3 approaches. They should not be either dropped, or split across two WGs. Yes there is a lot of work in the group, but if it gets fragmented and things slip through the cracks, then we will be forcing the VPN service providers, vendors, and customers to do much more work and spend much more time in the long run. In terms of meeting logistics, we will find that many of the same people will be attending and developing drafts for the proposed L2 and L3 WGs, so we will have to make sure that they don't overlap... Just the same as if we plan extended meeting times for the current PPVPN when it is needed. Finally, I'm closely involved with two areas of work in L3 VPNs in PPVPN, and we are getting to the point where much of the basic work is stable, so the L3VPN may not justify a dedicated WG for much longer, although it does need a WG in which to operate. I would suggest planning for a longer meeting in Vienna (if the agenda justifies it) and bringing this proposal up for discussion there. Regards, Paul > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Sunday, May 04, 2003 3:12 AM > To: ppvpn@nortelnetworks.com > Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten; > Peterson, Jon; Allison Mankin > Subject: IMPORTANT: Strategy for VPN work in IETF > > > Folks, > > Since San Francisco IETF meeting the IESG has been > considering the situation in the SUB-IP area and in the PPVPN > Working Group in particular. > > Such close attention to this WG was triggered by numerous > concerns that the IESG members received from the WG > participants about limited and slow progress within the WG > despite the efforts of the WG chairs and its members. The > IESG also used this opportunity to consider the IETF area > that the PPVPN work would fit best. > > After much deliberation, the involved ADs (Bert, Thomas, and I) are > considering the following organizational changes in order to > improve WG > focus and productivity and ensure faster progress of the > VPN-related work: > > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups. > > The L2 and L3 VPN work spaces are each big enough to > warrant a separate > WG. While concentration of all VPN-related work in a > single forum was > the right thing to do to ensure coordination of efforts > when the PPVPN > WG was created and L2 VPN work came in, such > concentration is causing > scaling problems within the WG at this moment. > > Migration of work into two separate WGs for L2 and L3 VPN > technologies > with more specific WG charters will help to focus > discussions, prevent > staff and meeting time overloading, and will aid faster > progress of > corresponding technologies. > > 2. Migration of the VPN-related work to the Internet area. > > As previously discussed, VPN-related work could be argued > to belong > to more than one area. Tunneling mechanisms are the property that > gravitates this work to the Internet area, which is where > we believe > the VPN work should go. > > As part of this move, we are also considering moving PWE3 > into INT, > so that L2TPEXT, PWE3, and thew new VPN WGs are operating > in the same > area. > > Based on the above considerations, we are considering the > following steps: > > 1. Two new WGs--L2VPN and L3VPN--will be created in the > Internet area. > The mailing lists will be established and the discussion > of the proposed > charters of the new WGs will be initiated shortly. > > 2. Once the charters of the new WGs are agreed upon and > approved by the IESG, > creation of the L2VPN and L3VPN WGs and shutdown of the > PPVPN WG will be > performed simultaneously. PPVPN WG documents will be > migrated to the > corresponding new WGs. > > It is our intention to complete this process by the Vienna > IETF meeting. > Also, these changes are being made for management reasons and > are not intended > to be a "reset" on WG activities or to halt or interrupt > progress on current > ongoing WG activities. > > We'd like to hear from the WG members if they see any fatal > flaws with the proposed approach. Please send us your > feedback by May 11th. > > Regards, > > -- > Alex Zinin > IETF SUB-IP Area Co-Director > > > ------_=_NextPart_001_01C314B9.978C7218 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IMPORTANT: Strategy for VPN work in IETF

Hi Alex,

The proposed split seems to put very little emphasis = on the "PP" of PPVPN.

The proposed focus on technologies for L2 and L3 is = likely to seriously disrupt the focus on the "Provider = Provisioned" concept, where much of the value comes from aiming = for interoperation across all major VPN technologies.  Of course, = we could have PPL2VPN and PPL3VPN, but as has been pointed out, we then = need to coordinate the "PP" parts across the two WGs.  =

VPN customers want a bundle of VPN services, and = don't really care whether it is L2 or L3 (or L1) or some mixture.  = VPN service providers want an interoperable toolkit which they can use = to design services that they can differentiate in various ways to = attract VPN customers. PPVPN is providing a forum to define the = operation of the VPN tools.  Regardless of L2 or L3 technologies, = there is a need for simple and interoperable mechanisms for VPN = membership and discovery, security considerations, SLA verification, = and a host of management areas.  These mechanisms are being = defined, clarified, and debated in PPVPN mostly without regard to the = specific L2 or L3 approaches.  They should not be either dropped, = or split across two WGs.

Yes there is a lot of work in the group, but if it = gets fragmented and things slip through the cracks, then we will be = forcing the VPN service providers, vendors, and customers to do much = more work and spend much more time in the long run.

In terms of meeting logistics, we will find that many = of the same people will be attending and developing drafts for the = proposed L2 and L3 WGs, so we will have to make sure that they don't = overlap... Just the same as if we plan extended meeting times for the = current PPVPN when it is needed.

Finally, I'm closely involved with two areas of work = in L3 VPNs in PPVPN, and we are getting to the point where much of the = basic work is stable, so the L3VPN may not justify a dedicated WG for = much longer, although it does need a WG in which to operate.

I would suggest planning for a longer meeting in = Vienna (if the agenda justifies it) and bringing this proposal up for = discussion there.

Regards,
Paul

> -----Original Message-----
> From: Alex Zinin [mailto:zinin@psg.com]
> Sent: Sunday, May 04, 2003 3:12 AM
> To: ppvpn@nortelnetworks.com
> Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas = Narten;
> Peterson, Jon; Allison Mankin
> Subject: IMPORTANT: Strategy for VPN work in = IETF
>
>
> Folks,
>
> Since San Francisco IETF meeting the IESG has = been
> considering the situation in the SUB-IP area = and in the PPVPN
> Working Group in particular.
>
> Such close attention to this WG was triggered = by numerous
> concerns that the IESG members received from = the WG
> participants about limited and slow progress = within the WG
> despite the efforts of the WG chairs and its = members. The
> IESG also used this opportunity to consider the = IETF area
> that the PPVPN work would fit best.
>
> After much deliberation, the involved ADs = (Bert, Thomas, and I) are
> considering the following organizational = changes in order to
> improve WG
> focus and productivity and ensure faster = progress of the
> VPN-related work:
>
>  1. Split of Layer-2 and Layer-3 VPN work = in separate Working Groups.
>
>     The L2 and L3 VPN work = spaces are each big enough to
> warrant a separate
>     WG. While concentration = of all VPN-related work in a
> single forum was
>     the right thing to do = to ensure coordination of efforts
> when the PPVPN
>     WG was created and L2 = VPN work came in, such
> concentration is causing
>     scaling problems within = the WG at this moment.
>
>     Migration of work into = two separate WGs for L2 and L3 VPN
> technologies
>     with more specific WG = charters will help to focus
> discussions, prevent
>     staff and meeting time = overloading, and will aid faster
> progress of
>     corresponding = technologies.
>
>  2. Migration of the VPN-related work to = the Internet area.
>
>     As previously = discussed, VPN-related work could be argued
> to belong
>     to more than one area. = Tunneling mechanisms are the property that
>     gravitates this work to = the Internet area, which is where
> we believe
>     the VPN work should = go.
>
>     As part of this move, = we are also considering moving PWE3
> into INT,
>     so that L2TPEXT, PWE3, = and thew new VPN WGs are operating
> in the same
>     area.
>
> Based on the above considerations, we are = considering the
> following steps:
>
>  1. Two new WGs--L2VPN and L3VPN--will be = created in the
> Internet area.
>     The mailing lists will = be established and the discussion
> of the proposed
>     charters of the new WGs = will be initiated shortly.
>
>  2. Once the charters of the new WGs are = agreed upon and
> approved by the IESG,
>     creation of the L2VPN = and L3VPN WGs and shutdown of the
> PPVPN WG will be
>     performed = simultaneously. PPVPN WG documents will be
> migrated to the
>     corresponding new = WGs.
>
> It is our intention to complete this process by = the Vienna
> IETF meeting.
> Also, these changes are being made for = management reasons and
> are not intended
> to be a "reset" on WG activities or = to halt or interrupt
> progress on current
> ongoing WG activities.
>
> We'd like to hear from the WG members if they = see any fatal
> flaws with the proposed approach. Please send = us your
> feedback by May 11th.
>
> Regards,
>
> --
> Alex Zinin
> IETF SUB-IP Area Co-Director
>
>
>

------_=_NextPart_001_01C314B9.978C7218-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: Re: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 07 May 2003 12:59:03 -0400 Lines: 18 Sender: pwe3-admin@ietf.org References: <200305071624.h47GOI29002731@rotala.raleigh.ibm.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: Waldemar Augustyn , Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin X-From: pwe3-admin@ietf.org Wed May 07 19:15:43 2003 Return-path: To: Thomas Narten In-reply-to: Your message of Wed, 07 May 2003 12:24:18 -0400. <200305071624.h47GOI29002731@rotala.raleigh.ibm.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Thomas> I'm a bit concerned to hear that there has been minimal discussion Thomas> on L3 topics over the last year, given the number of L3 work items Thomas> that apparently need to get completed. Well, the issue here is that they were all completed a year ago, and have been held up by some mysterious process. However, I for one would welcome a smaller WG, focused only on L3VPN, which would not get distracted by L2VPN issues. (Though I seem to be the only WG participant to welcome this ;-)) I do anticipate some problems with the IESG (as Marco hints) on L3VPN, but I don't think that those problems will be any less if we keep the topics combined in one WG ;-) Thomas> The above could be read as indicating that the discussion/urgency of Thomas> the L2 work is pushing out or drowning out discussion on L3 topics. Yes, I do think so. From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Scott W Brim Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 7 May 2003 13:19:39 -0400 Lines: 19 References: <3EB5E991.5040604@nxp.com> <200305071624.h47GOI29002731@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Wed May 07 20:07:52 2003 Return-path: To: Thomas Narten Mail-Followup-To: Scott W Brim , Thomas Narten , ppvpn@nortelnetworks.com, pwe3@ietf.org Content-Disposition: inline In-Reply-To: <200305071624.h47GOI29002731@rotala.raleigh.ibm.com> User-Agent: Mutt/1.4i X-SMTP-HELO: rtp-core-1.cisco.com X-SMTP-MAIL-FROM: swb@employees.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: rtp-core-1.cisco.com [64.102.124.12] Status: O On Wed, May 07, 2003 12:24:18PM -0400, Thomas Narten allegedly wrote: > There is a basic tension in the IETF between having WGs that are > too large (a similar discussion has been ongoing in places like > MobileIP and IPv6 over the last year) and where splitting them up into > smaller WGs can help focus them. Indeed, there have been numerious > conversations about this on the problem-statement list (with one view > being that smaller, focused WGs tending to do a better job of > completing their work than larger ones). I tend to share that view (as > a general observation), and given that there are some 13 documents in > the L3 space alone, I see there being ample work for a standalone WG > to take on. Will splitting up the WGs _guarantee_ this? Of course > not. Does it solve all possible problems? Of course not. But it can > help, and it seems reasonable in my mind to do so in this case. Having related but small, focused WGs is fine as long as communication between them is mandated and kept flowing. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Thomas Narten Subject: Re: Re: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 07 May 2003 13:57:18 -0400 Lines: 11 Sender: pwe3-admin@ietf.org References: <20030507171939.GQ2136@sbrim-w2k> X-From: pwe3-admin@ietf.org Wed May 07 20:08:26 2003 Return-path: To: Scott W Brim , ppvpn@nortelnetworks.com, pwe3@ietf.org In-Reply-To: Message from swb@employees.org of "Wed, 07 May 2003 13:19:39 EDT." <20030507171939.GQ2136@sbrim-w2k> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Scott W Brim writes: > Having related but small, focused WGs is fine as long as communication > between them is mandated and kept flowing. Complete agreement, and keeping that communication going is something I will be watching for. That is also an argument for putting pwe3 and the ppvpn groups together (and also l2tpext) in the same area since they all do relate to varying degrees. Thomas From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Hamid Ould-Brahim" Subject: RE: Re: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 7 May 2003 14:08:52 -0400 Lines: 67 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C314C3.B7798FA2" Cc: Waldemar Augustyn , Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin X-From: pwe3-admin@ietf.org Wed May 07 20:15:55 2003 Return-path: To: erosen@cisco.com, Thomas Narten X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C314C3.B7798FA2 Content-Type: text/plain; charset="iso-8859-1" Thomas, Eric, > > Thomas> The above could be read as indicating that the > discussion/urgency of > Thomas> the L2 work is pushing out or drowning out discussion > on L3 topics. > > Yes, I do think so. To be more precise, the discussions were mostly on vpls service, and since l2vpn includes services other than vpls, this could be read as well that vpls discussion/urgency is pushing out or drowning out discussions on other l2vpn services. In that respect, creating a new l2vpn wg will not make the situation any better. Hamid. ------_=_NextPart_001_01C314C3.B7798FA2 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF

Thomas, Eric,

>
> Thomas> The above could be read as indicating that the
> discussion/urgency of
> Thomas> the L2 work is pushing out or drowning out discussion
> on L3 topics.
>
> Yes, I do think so.

To be more precise, the discussions were mostly on vpls service,
and since l2vpn includes services other than vpls, this could
be read as well that vpls discussion/urgency is pushing out or
drowning out discussions on other l2vpn services. In that
respect, creating a new l2vpn wg will not make the situation any
better.

Hamid.

------_=_NextPart_001_01C314C3.B7798FA2-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: Re: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 7 May 2003 22:13:36 +0100 Lines: 28 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: waldemar@nxp.com, zinin@psg.com, ppvpn@nortelnetworks.com, pwe3@ietf.org, bwijnen@lucent.com, jon.peterson@neustar.biz, mankin@psg.com X-From: pwe3-admin@ietf.org Wed May 07 23:27:33 2003 Return-path: To: hbrahim@nortelnetworks.com, erosen@cisco.com, narten@us.ibm.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hamid Ould-Brahim wrote 07 May 2003 19:09 Thomas, Eric, > > Thomas> The above could be read as indicating that the > discussion/urgency of > Thomas> the L2 work is pushing out or drowning out discussion > on L3 topics. > > Yes, I do think so. To be more precise, the discussions were mostly on vpls service, and since l2vpn includes services other than vpls, this could be read as well that vpls discussion/urgency is pushing out or drowning out discussions on other l2vpn services. In that respect, creating a new l2vpn wg will not make the situation any better. Hamid. NH=> Excellent observation Hamid. It would seem to me that a L2 VPN service should be nothing more than some form of co pkt-sw managed BW service. This could then be the common *default* VPN solution on which additional *client* layer VPN services (be they IP (rfc2547) or ethernet (VPLS)) can be considered (see my recent posting to Alex which suggested such a view). However, even though I can see logic in grouping together the common server layer aspects and then adding specific client layer aspects as needed, maybe this is not so attractive to some? regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Luca Martini Subject: Re: TTL value of VC Label? Date: Wed, 07 May 2003 15:49:51 -0600 Organization: Level3 Communications LLC. Lines: 52 Sender: pwe3-admin@ietf.org References: <200305052021.h45KLtWS009979@rtp-core-1.cisco.com> <3EB6D18D.8685531@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, stbryant@cisco.com, Olen Stokes , "'vkompella@timetra.com'" , Wei Luo , Alik Shimelmits , Yaron Nachman , pwe3@ietf.org, Eli Angel , Ilya Vershkov X-From: pwe3-admin@ietf.org Thu May 08 00:01:04 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- To: david.watkinson@alcatel.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Eric, I would like to point out that several of the vendors reading this list have experienced bugs in their MPLS routers that cause the MPLS LFIB to misprogrammed , and traffic to be sent to the wrong location. Initially we where attempting to mitigate such problems by making sure that a PW packet could not enter the SP network in this fashion. How about this ? "The setting of the TTL value in the PW label is application dependent, however in a strict point to point application the TTL should be appropriately set to 2" Luca David Watkinson wrote: > Eric Rosen wrote: > > >>David> Setting the TTL is application dependant. The originating PE will know >>David> if the PSN tunnel reaches the destination node for the PW. >> >>I don't think it will always know this. > > > For applications that do not know the number of hops will have to set the TTL to a > larger value (e.g. the same TTL used for originated IP packets). Many > applications will know that the far-end IP address of the tunnel is the same as > the IP address of the termination point of the PW. For those cases, it could set > the TTL to 2. > > >> >>David> In other cases, for example, DTLS, a TTL of 4 may be needed due to >>David> the two additional hops taken between the L2PE and PE at each end. >> >>You could have an L2PE/PE hop at one end but not at the other. In general, >>you wouldn't know whether the other end has such a hop or not. > > > Yes, that is true, however setting a TTL=4 is much safer than using a TTL=3. > > I still think that a statement such as "The setting of the TTL value in the PW > label is application dependant" is a suitable replacement for the existing text. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Wed, 07 May 2003 18:41:55 -0400 Organization: Alcatel Networks Corporaton Lines: 154 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , "'Shahram Davari'" , "'George Swallow'" , Danny McPherson , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 00:45:32 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: David Allan Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Dave and all, I agree with your assessment. Given that we want to progress the PWE3 work, I propose to address the issues raised in 2 phases: Phase 1: the current scope of the PWE3 working group is to provide for a PW between two endpoints of the same type (e.g., FR-MPLS-FR). In this environment, the native service OAM and link management achieves all what is needed and we do not need to define a specific PW OAM. At the PSN level, OAM can be achieved using either IP tools such as LSP-Ping, or Y.1711 tools. Any OAM specific issues with the PSN are clearly outside the scope of the PWE3. The only requirement is to address the IP aliasing issue. The most straighforward way to resolve it is to make sure that all CWs have the nibble following immediately the bottom label set to a value different of 4, 6, or 8 (zero seems to be the accepted value). This means that the SONET encapsulation would have to go with Option 3 in Andy's three proposals. Phase 2: the work of the PWE3 may expand to support endpoints of different types (e.g., FR-MPLS-Ethernet). In this scenario, if the native service is terminated locally at each PE, then clearly there is a need for the following: a. the ability to define a PW specific OAM and link management functions and inteoperate it with the native service OAM and link management. b. the ability to self-identify the protocol carried in a single PW. A PW can carry both user packets and OAM packets and we want them to share the same path in the presence of ECMP. A PW can also carry both a end-user bridged and a routed PDU (multiprotocol PW). This is where the MPLS/PW PID is useful but it should be addressed in a much wider scope than the current PWE3 issues. Let me know what you think. Mustapha. ------------ > David Allan wrote: > > We do have two separate problems.... > > 1) Is a means of identifying a generic payload. This would appear > to potentially require additional services such as sequencing etc. > stuff already dealt with in the exissting PWE control words. This > would include ordering, and if this was preserved in the presence > of proprietary ECMP so much the better. > > 2) A means of instrumenting PWs such that packets fate shares > with PW forwarding. Tom has proposed VCCV which needs an > available bit in the CW and control handshaking to agree on what > the bit means. The PPP DLL approach (Georges proposal) or my > proposal permits the instrumenting protocol to self identify and > therefore IMHO is preferable. > > But I am skeptical that simply having a protocol identifier means > a PW can carry anything. Its not designed with the requisite > attributes for service bearing. If we want "carry anything" with > ordering fragmentation etc. we have more to do. > > my 2 cents > Dave > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > Sent: Tuesday, May 06, 2003 4:00 AM > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > Hi all, > > > > I believe that George's comment has been very much in place. > > > > The "MPLS PID" story looks to me like following: > > > > 1. There was a recognized but, for some reasons, undeclared need > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > complied with this, and some did not; some others simply > > declared that the CW is optional. > > > > 2. At some (rather late) stage, the need has been declared, > > explained (which is always good!) and proposed as part of > > the standard (moving the architecture document int the > > Standards Track). > > > > 3. In order to minimize impact on some pre-standard > implementations > > that have either utilized the 1st nibble of the CW or used > RTP > > (or both), an optional opaque 32-bit word has between the PW > label > > (at the bottom of the label stack) and a the CW/RTP header > has been > > proposed as the simplest way out. The only requirement for > this > > block of data has been to keep its 1st nibble zeroed. > > > > 4. After that, this patch has been somehow "promoted" to the > title > > and associated status of of "MPLS PID". And this promotion > has > > triggered a long discussion of its possible uses far beyond > the > > original patchy fuctionality. > > > > 5. The proposals mentioned in is discussion are, IMO, paramount > > to an alternative PWE3 architecture (including allocation > > of a PWE3 protocol number in IP header etc.). They also > include > > amendments to Y.1711 which is presumably out of scope of PWE3 > > > (and IETF in general) etc. > > And somehow the fact that existing LSRs carry IP traffic over > > > LSPs without any MPLS PID and will hardly be ever retrofitted > > > has been happily ignored by some of the participants. > > > > IMHO the best way out of the confusion would be to demote > > "MPLS PID" to what it really is - a patch solving the ECMP > > problem for the following three cases (and just for these > cases): > > > > o PW encapsulations that do not mandate a CW, so that > payload > > immediately > > follows the PW label. In other words, make SOME CW > mandatory. > > o PW encapsulations that mandate a CW but utilize its 1st > nibble. > > They would prepend an opaque 32-bit word with the > > zeroed 1st nibble > > by default, reserving an option to drop it if ECMP is > > not used in > > the core network. > > o PW encapsulations that use RTP. They may follow the > > same rules as in > > the previous case, or may use weaker rules because the > > first nibble > > of an RTP header distinguishes it from IPv4/IPv6 > > headers and this > > is probably sufficient for ECMP. > > > > I think that building theories/architectures on patches is > > counter-productive. > > > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Alex Zinin Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Wed, 7 May 2003 16:40:54 -0700 Lines: 20 References: <200305061442.KAA23011@bifocal.cisco.com> Reply-To: Alex Zinin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: PPVPN , pwe3@ietf.org, =?ISO-8859-15?B?V2lqbmVuLA0KICAgIEJlcnQgKEJlcnQp?= , Thomas Narten , =?ISO-8859-15?B?UGV0ZXJzb24sDQogICAgSm9u?= , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Thu May 08 01:43:25 2003 Return-path: X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) To: George Swallow In-Reply-To: <200305061442.KAA23011@bifocal.cisco.com> X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: PPVPN@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] Status: O George, > I thought the IESG was concerned about the overall number of > Workgroups. They are much easier to create than to shut down. I think the overall number of the WGs is a lesser concern. > So if meeting twice per IETF for a short while until the work > settles down lets you have one less, seems like a good idea. Agreed, provided that this is not a consistent situation and that the agenda time is not used for slideware, but to discuss real issues the WG is facing, verify consensus on document modifications, etc., i.e., the real stuff. Alex From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Rahul Aggarwal Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Wed, 7 May 2003 18:37:19 -0700 (PDT) Lines: 22 Sender: pwe3-admin@ietf.org References: <3EB98BB3.B7682049@alcatel.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: David Allan , "'Sasha Vainshtein'" , "'Shahram Davari'" , "'George Swallow'" , Danny McPherson , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 03:39:40 2003 Return-path: X-Sender: rahul@malt To: Mustapha Aissaoui In-Reply-To: <3EB98BB3.B7682049@alcatel.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha, [clipped] > PWE3 work, I propose to address the issues raised in 2 phases: > > Phase 1: > the current scope of the PWE3 working group is to provide for a PW > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > environment, the native service OAM and link management achieves all > what is needed and we do not need to define a specific PW OAM. At In this environment there is still a need for a PW OAM. Please see section 3 of: draft-nadeau-pwe3-vccv-00.txt Regards, rahul From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 11:13:24 +0100 Lines: 230 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Sasha@axerra.com, Shahram_Davari@pmc-sierra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 12:16:20 2003 Return-path: To: mustapha.aissaoui@alcatel.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha, Please see in-line. regards, Neil Mustapha Aissaoui wrote 07 May 2003 23:42 > Phase 1: > the current scope of the PWE3 working group is to provide for a PW > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > environment, the native service OAM and link management achieves all > what is needed and we do not need to define a specific PW OAM. NH=> Absolutely correct.....when I want to interwork ATM/MPLS say there is not need whatsover for PW OAM, but further there is no need for PWs at all! > At > the PSN level, OAM can be achieved using either IP tools such as > LSP-Ping, or Y.1711 tools. Any OAM specific issues with the PSN are > clearly outside the scope of the PWE3. > The only requirement is to address the IP aliasing issue. The most > straighforward way to resolve it is to make sure that all CWs have > the nibble following immediately the bottom label set to a value > different of 4, 6, or 8 (zero seems to be the accepted value). This > means that the SONET encapsulation would have to go with Option 3 in > Andy's three proposals. > > Phase 2: > the work of the PWE3 may expand to support endpoints of different > types (e.g., FR-MPLS-Ethernet). NH=> I suggest some caution here. It is perfectly valid (and required) to have service-interworking between technologies that belong to the *same* network mode. It is not so valid to have service-interworking between technologies that don't belong to the same mode......here only client/server relationships make sense, and even then only certain ones between the 3 modes. One can of course ignore this, and no doubt this is going to happen.......but I advise caution. > In this scenario, if the native > service is terminated locally at each PE, then clearly there is a > need for the following: > a. the ability to define a PW specific OAM and link management > functions and inteoperate it with the native service OAM and link > management. NH=> Why? The scenario described (ie service-interworking) requires that the trails of each technology terminate at the IWF....if one drew out the G.805 diagrams this would be clear. This means their native OAM functions (if any) also terminate at the IWF. One therefore requires some higher/common 'networking entity' to be carried end-end across the concatenated server technologies. However, I don't see any difference between ATM/MPLS service interworking and ATM/MPLS/FR service interworking and ATM/MPLS/ethernet service interworking (other than the validity of having mode mismatch, and the functional specification differences of each of the technologies in question). > b. the ability to self-identify the protocol carried in a single PW. > A PW can carry both user packets NH=> of which layer network? > and OAM packets NH=> of which layer network? > and we want them to > share the same path in the presence of ECMP. A PW can also carry > both a end-user bridged and a routed PDU (multiprotocol PW). NH=> Whoa! You have just changed the service-interworking case into a (partial) client/server case....in the former the etherent component is simply a server layer access partition (terminates at the IWF) but now you are describing the case where the ethernet pkts have to be carried across all intervening networks....so, for example, it could be that ethernet is client to both MPLS and ATM partitions say, but the MPLS and ATM partitions are using service interworking. As I noted previously, if you draw out the G.805 relationships this would be much clearer. > This is > where the MPLS/PW PID is useful but it should be addressed in a much > wider scope than the current PWE3 issues. NH=> Please note this observation: A PID field is only required to identify the *clients* of a given layer network when these can change over the life of the (server) layer trail. In G.805 terms this is describing a multiplexing function that is related to the adaptation of the client signal into the payload of the server signal. Each layer network however, should have its own native OAM that is *independent* of any higher client layer. That is, the PID field and the layer network's native OAM are *not* in any way related (and the PID function sits above the OAM functionally).....putting this is very plain terms, the *client* PID field should not be used to identify OAM pkts. Finally, if MPLS is properly specified there is no need for any of this artifical PW stuff....we simply need to interwork MPLS and the other technologies natively. The PW stuff only 'lives' because: - of LDP and the issues/hacks of ECMP.....load-splitting only makes arch sense in a *single* layer network. - MPLS is 'allowed' to re-order pkts - someone thinks squeezing a bit of BW (wrt certain client layers) is useful - the erroneous belief that X/IP is somehow the same as X/MPLS An unneccessary networking layer (the PW) has thus been created, that is now starting to take on a life of its own as an 'in-between' layer network, when there is no need for it....esp when we have to manage the MPLS network anyway (so do it once, and do it right). Thanks, just something else to manage ;-) On a serious note however, I hope/pray there are some suppliers out there that can understand what I am saying here and will provide solutions without these unnecessary problems. I don't think its that hard (technically at least). > > Let me know what you think. > Mustapha. > ------------ > > David Allan wrote: > > > > We do have two separate problems.... > > > > 1) Is a means of identifying a generic payload. This would appear > > to potentially require additional services such as sequencing etc. > > stuff already dealt with in the exissting PWE control words. This > > would include ordering, and if this was preserved in the presence > > of proprietary ECMP so much the better. > > > > 2) A means of instrumenting PWs such that packets fate shares > > with PW forwarding. Tom has proposed VCCV which needs an > > available bit in the CW and control handshaking to agree on what > > the bit means. The PPP DLL approach (Georges proposal) or my > > proposal permits the instrumenting protocol to self identify and > > therefore IMHO is preferable. > > > > But I am skeptical that simply having a protocol identifier means > > a PW can carry anything. Its not designed with the requisite > > attributes for service bearing. If we want "carry anything" with > > ordering fragmentation etc. we have more to do. > > > > my 2 cents > > Dave > > > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > > Sent: Tuesday, May 06, 2003 4:00 AM > > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > Hi all, > > > > > > I believe that George's comment has been very much in place. > > > > > > The "MPLS PID" story looks to me like following: > > > > > > 1. There was a recognized but, for some reasons, undeclared need > > > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > > complied with this, and some did not; some others simply > > > declared that the CW is optional. > > > > > > 2. At some (rather late) stage, the need has been declared, > > > explained (which is always good!) and proposed as part of > > > the standard (moving the architecture document int the > > > Standards Track). > > > > > > 3. In order to minimize impact on some pre-standard > > implementations > > > that have either utilized the 1st nibble of the CW or used > > RTP > > > (or both), an optional opaque 32-bit word has between the PW > > label > > > (at the bottom of the label stack) and a the CW/RTP header > > has been > > > proposed as the simplest way out. The only requirement for > > this > > > block of data has been to keep its 1st nibble zeroed. > > > > > > 4. After that, this patch has been somehow "promoted" to the > > title > > > and associated status of of "MPLS PID". And this promotion > > has > > > triggered a long discussion of its possible uses far beyond > > the > > > original patchy fuctionality. > > > > > > 5. The proposals mentioned in is discussion are, IMO, paramount > > > to an alternative PWE3 architecture (including allocation > > > of a PWE3 protocol number in IP header etc.). They also > > include > > > amendments to Y.1711 which is presumably out of scope of PWE3 > > > > > (and IETF in general) etc. > > > And somehow the fact that existing LSRs carry IP traffic over > > > > > LSPs without any MPLS PID and will hardly be ever retrofitted > > > > > has been happily ignored by some of the participants. > > > > > > IMHO the best way out of the confusion would be to demote > > > "MPLS PID" to what it really is - a patch solving the ECMP > > > problem for the following three cases (and just for these > > cases): > > > > > > o PW encapsulations that do not mandate a CW, so that > > payload > > > immediately > > > follows the PW label. In other words, make SOME CW > > mandatory. > > > o PW encapsulations that mandate a CW but utilize its 1st > > nibble. > > > They would prepend an opaque 32-bit word with the > > > zeroed 1st nibble > > > by default, reserving an option to drop it if ECMP is > > > not used in > > > the core network. > > > o PW encapsulations that use RTP. They may follow the > > > same rules as in > > > the previous case, or may use weaker rules because the > > > first nibble > > > of an RTP header distinguishes it from IPv4/IPv6 > > > headers and this > > > is probably sufficient for ECMP. > > > > > > I think that building theories/architectures on patches is > > > counter-productive. > > > > > > With best regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > tel: +972-3-7659993 (office) > > > +972-8-9254948 (res.) > > > +972-58-674833 (cell.) > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 11:13:10 +0100 Lines: 26 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: dallan@nortelnetworks.com, Sasha@axerra.com, Shahram_Davari@pmc-sierra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 12:18:25 2003 Return-path: To: rahul@redback.com, mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Rahul, please see below, regards, Neil > Mustapha, > > [clipped] > > > > PWE3 work, I propose to address the issues raised in 2 phases: > > > > Phase 1: > > the current scope of the PWE3 working group is to provide for a PW > > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > > environment, the native service OAM and link management achieves all > > what is needed and we do not need to define a specific PW OAM. At > > In this environment there is still a need for a PW OAM. > Please see section > 3 of: > > draft-nadeau-pwe3-vccv-00.txt NH=> There is not a 'need' for PWs at all. The only 'need' arises due to reasons I pointed out in my response to Mustapha. Given we still have to manage the MPLS layer networks why not do it once and do it right? However, given it *is* possible to do things differently/simpler, then I think operators who want to have such solutions should be able to achieve them. And of course, those who want PWs as being defined can have them too. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 09:38:10 -0400 Organization: Cisco Systems, Inc. Lines: 242 Sender: pwe3-admin@ietf.org References: <3EB98BB3.B7682049@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , "'Shahram Davari'" , "'George Swallow'" , "'Danny McPherson'" , X-From: pwe3-admin@ietf.org Thu May 08 15:41:56 2003 Return-path: To: "'Mustapha Aissaoui'" , "'David Allan'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3EB98BB3.B7682049@alcatel.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mustapha Aissaoui > Sent: Wednesday, May 07, 2003 6:42 PM > To: David Allan > Cc: 'Sasha Vainshtein'; 'Shahram Davari'; 'George Swallow'; > Danny McPherson; pwe3@ietf.org > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Dave and all, > I agree with your assessment. Given that we want to progress > the PWE3 work, I propose to address the issues raised in 2 phases: > > Phase 1: > the current scope of the PWE3 working group is to provide for > a PW between two endpoints of the same type (e.g., > FR-MPLS-FR). In this environment, the native service OAM and > link management achieves all what is needed and we do not > need to define a specific PW OAM. At the PSN level, I suggest that you read the MPLS OAM requirements in draft-ietf-mpls-oam-requirements-00.txt, as well as the justifications for VCCV in draft-nadeau-pwe3-vccv-00.txt and then tell the 25 or so service providers that were polled for these requirements about how it is so clear that there is no need to have such a mechanism. > OAM can > be achieved using either IP tools such as LSP-Ping, or Y.1711 > tools. Any OAM specific issues with the PSN are clearly > outside the scope of the PWE3. Use of just LSP-ping for PWs is not going to cut the mustard for two reasons, which I will explain below. I believe that LSP ping/ICMP ping/native OAM and VCCV need to be used in conjunction to satisfy the requirements specified in the OAM requirements. 1) Use of VCCV allows you to get as close to the disposition point as possible; LSP or ICMP ping doesn't necessarily do this in all cases. 2) VCCV is a generic CV mechanism for IETF defined PWs regardless of the underlying PSN technology that allows CV traffic to flow on EXACTLY the same path as the data plane. This is important because tools designed to test/debug/verify PWs can be written more generally. This is also important because there are cases where using regular ICMP-ping will not follow the same data plane path over the IP tunnel. Also, pitching Y.1711 as a possible alternative is irresponsible. It is badly broken for LDP-based networks and has been shown to be quite difficult to implement besides, so lets not go there. Of course, its proponents are working feverishly to patch it up within the ITU so that they can ask service providers to replace all of their hardware (again) to support the ultimate OAM swiss army knife. I assert that it is certainly not ready and should not be considered as an acceptable approach. > The only requirement is to > address the IP aliasing issue. The most straighforward way to > resolve it is to make sure that all CWs have the nibble > following immediately the bottom label set to a value > different of 4, 6, or 8 (zero seems to be the accepted > value). This means that the SONET encapsulation would have to > go with Option 3 in Andy's three proposals. > > Phase 2: > the work of the PWE3 may expand to support endpoints of > different types (e.g., FR-MPLS-Ethernet). In this scenario, > if the native service is terminated locally at each PE, then > clearly there is a need for the following: a. the ability to > define a PW specific OAM and link management functions and > inteoperate it with the native service OAM and link > management. b. the ability to self-identify the protocol > carried in a single PW. > A PW can carry both user packets and > OAM packets and we want them to share the same path in the > presence of ECMP. Again, read the OAM requirements referenced above. OAM traffic MUST be carried on the same data path regardless of whether ECMP is active or not. Are you suggesting that we should ignore that 25 SPs have told us? --Tom > A PW can also carry both a end-user bridged > and a routed PDU (multiprotocol PW). This is where the > MPLS/PW PID is useful but it should be addressed in a much > wider scope than the current PWE3 issues. > > Let me know what you think. > Mustapha. > ------------ > > David Allan wrote: > > > > We do have two separate problems.... > > > > 1) Is a means of identifying a generic payload. This would > appear to > > potentially require additional services such as sequencing > etc. stuff > > already dealt with in the exissting PWE control words. This would > > include ordering, and if this was preserved in the presence of > > proprietary ECMP so much the better. > > > > 2) A means of instrumenting PWs such that packets fate > shares with PW > > forwarding. Tom has proposed VCCV which needs an available > bit in the > > CW and control handshaking to agree on what the bit means. > The PPP DLL > > approach (Georges proposal) or my proposal permits the > instrumenting > > protocol to self identify and therefore IMHO is preferable. > > > > But I am skeptical that simply having a protocol identifier > means a PW > > can carry anything. Its not designed with the requisite > attributes for > > service bearing. If we want "carry anything" with ordering > > fragmentation etc. we have more to do. > > > > my 2 cents > > Dave > > > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > > Sent: Tuesday, May 06, 2003 4:00 AM > > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > Hi all, > > > > > > I believe that George's comment has been very much in place. > > > > > > The "MPLS PID" story looks to me like following: > > > > > > 1. There was a recognized but, for some reasons, undeclared need > > > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > > complied with this, and some did not; some others simply > > > declared that the CW is optional. > > > > > > 2. At some (rather late) stage, the need has been declared, > > > explained (which is always good!) and proposed as part of > > > the standard (moving the architecture document int the > > > Standards Track). > > > > > > 3. In order to minimize impact on some pre-standard > > implementations > > > that have either utilized the 1st nibble of the CW or used > > RTP > > > (or both), an optional opaque 32-bit word has between the PW > > label > > > (at the bottom of the label stack) and a the CW/RTP header > > has been > > > proposed as the simplest way out. The only requirement for > > this > > > block of data has been to keep its 1st nibble zeroed. > > > > > > 4. After that, this patch has been somehow "promoted" to the > > title > > > and associated status of of "MPLS PID". And this promotion > > has > > > triggered a long discussion of its possible uses far beyond > > the > > > original patchy fuctionality. > > > > > > 5. The proposals mentioned in is discussion are, IMO, paramount > > > to an alternative PWE3 architecture (including allocation > > > of a PWE3 protocol number in IP header etc.). They also > > include > > > amendments to Y.1711 which is presumably out of scope of PWE3 > > > > > (and IETF in general) etc. > > > And somehow the fact that existing LSRs carry IP traffic over > > > > > LSPs without any MPLS PID and will hardly be ever retrofitted > > > > > has been happily ignored by some of the participants. > > > > > > IMHO the best way out of the confusion would be to demote > "MPLS PID" > > > to what it really is - a patch solving the ECMP problem for the > > > following three cases (and just for these > > cases): > > > > > > o PW encapsulations that do not mandate a CW, so that > > payload > > > immediately > > > follows the PW label. In other words, make SOME CW > > mandatory. > > > o PW encapsulations that mandate a CW but utilize its 1st > > nibble. > > > They would prepend an opaque 32-bit word with the > zeroed 1st > > > nibble > > > by default, reserving an option to drop it if ECMP > is not used > > > in > > > the core network. > > > o PW encapsulations that use RTP. They may follow the > > > same rules as in > > > the previous case, or may use weaker rules because > the first > > > nibble > > > of an RTP header distinguishes it from IPv4/IPv6 > headers and > > > this > > > is probably sufficient for ECMP. > > > > > > I think that building theories/architectures on patches is > > > counter-productive. > > > > > > With best regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > tel: +972-3-7659993 (office) > > > +972-8-9254948 (res.) > > > +972-58-674833 (cell.) > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: RE: IMPORTANT: Strategy for VPN work in IETF Date: Thu, 8 May 2003 09:54:30 -0400 Organization: Cisco Systems, Inc. Lines: 459 Sender: pwe3-admin@ietf.org References: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01C31547.D53AD5D0" Cc: , "'Wijnen, Bert \(Bert\)'" , "'Thomas Narten'" , "'Peterson, Jon'" , "'Allison Mankin'" X-From: pwe3-admin@ietf.org Thu May 08 15:57:53 2003 Return-path: To: "'Paul Knight'" , "'Alex Zinin'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------=_NextPart_000_00DD_01C31547.D53AD5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 You raise a good point. Is there going to be any discussion of actual provisioning of VPNs? =20 --Tom =20 -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Paul Knight Sent: Wednesday, May 07, 2003 12:56 PM To: Alex Zinin; ppvpn@nortelnetworks.com Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten; Peterson, Jon; Allison Mankin Subject: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF Hi Alex,=20 The proposed split seems to put very little emphasis on the "PP" of = PPVPN.=20 The proposed focus on technologies for L2 and L3 is likely to seriously disrupt the focus on the "Provider Provisioned" concept, where much of = the value comes from aiming for interoperation across all major VPN technologies. Of course, we could have PPL2VPN and PPL3VPN, but as has = been pointed out, we then need to coordinate the "PP" parts across the two = WGs. =20 VPN customers want a bundle of VPN services, and don't really care = whether it is L2 or L3 (or L1) or some mixture. VPN service providers want an interoperable toolkit which they can use to design services that they = can differentiate in various ways to attract VPN customers. PPVPN is = providing a forum to define the operation of the VPN tools. Regardless of L2 or L3 technologies, there is a need for simple and interoperable mechanisms = for VPN membership and discovery, security considerations, SLA verification, = and a host of management areas. These mechanisms are being defined, = clarified, and debated in PPVPN mostly without regard to the specific L2 or L3 approaches. They should not be either dropped, or split across two WGs. Yes there is a lot of work in the group, but if it gets fragmented and things slip through the cracks, then we will be forcing the VPN service providers, vendors, and customers to do much more work and spend much = more time in the long run. In terms of meeting logistics, we will find that many of the same people will be attending and developing drafts for the proposed L2 and L3 WGs, = so we will have to make sure that they don't overlap... Just the same as if = we plan extended meeting times for the current PPVPN when it is needed. Finally, I'm closely involved with two areas of work in L3 VPNs in = PPVPN, and we are getting to the point where much of the basic work is stable, = so the L3VPN may not justify a dedicated WG for much longer, although it = does need a WG in which to operate. I would suggest planning for a longer meeting in Vienna (if the agenda justifies it) and bringing this proposal up for discussion there. Regards,=20 Paul=20 > -----Original Message-----=20 > From: Alex Zinin [mailto:zinin@psg.com]=20 > Sent: Sunday, May 04, 2003 3:12 AM=20 > To: ppvpn@nortelnetworks.com=20 > Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten;=20 > Peterson, Jon; Allison Mankin=20 > Subject: IMPORTANT: Strategy for VPN work in IETF=20 >=20 >=20 > Folks,=20 >=20 > Since San Francisco IETF meeting the IESG has been=20 > considering the situation in the SUB-IP area and in the PPVPN=20 > Working Group in particular.=20 >=20 > Such close attention to this WG was triggered by numerous=20 > concerns that the IESG members received from the WG=20 > participants about limited and slow progress within the WG=20 > despite the efforts of the WG chairs and its members. The=20 > IESG also used this opportunity to consider the IETF area=20 > that the PPVPN work would fit best.=20 >=20 > After much deliberation, the involved ADs (Bert, Thomas, and I) are=20 > considering the following organizational changes in order to=20 > improve WG=20 > focus and productivity and ensure faster progress of the=20 > VPN-related work:=20 >=20 > 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups.=20 >=20 > The L2 and L3 VPN work spaces are each big enough to=20 > warrant a separate=20 > WG. While concentration of all VPN-related work in a=20 > single forum was=20 > the right thing to do to ensure coordination of efforts=20 > when the PPVPN=20 > WG was created and L2 VPN work came in, such=20 > concentration is causing=20 > scaling problems within the WG at this moment.=20 >=20 > Migration of work into two separate WGs for L2 and L3 VPN=20 > technologies=20 > with more specific WG charters will help to focus=20 > discussions, prevent=20 > staff and meeting time overloading, and will aid faster=20 > progress of=20 > corresponding technologies.=20 >=20 > 2. Migration of the VPN-related work to the Internet area.=20 >=20 > As previously discussed, VPN-related work could be argued=20 > to belong=20 > to more than one area. Tunneling mechanisms are the property that=20 > gravitates this work to the Internet area, which is where=20 > we believe=20 > the VPN work should go.=20 >=20 > As part of this move, we are also considering moving PWE3=20 > into INT,=20 > so that L2TPEXT, PWE3, and thew new VPN WGs are operating=20 > in the same=20 > area.=20 >=20 > Based on the above considerations, we are considering the=20 > following steps:=20 >=20 > 1. Two new WGs--L2VPN and L3VPN--will be created in the=20 > Internet area.=20 > The mailing lists will be established and the discussion=20 > of the proposed=20 > charters of the new WGs will be initiated shortly.=20 >=20 > 2. Once the charters of the new WGs are agreed upon and=20 > approved by the IESG,=20 > creation of the L2VPN and L3VPN WGs and shutdown of the=20 > PPVPN WG will be=20 > performed simultaneously. PPVPN WG documents will be=20 > migrated to the=20 > corresponding new WGs.=20 >=20 > It is our intention to complete this process by the Vienna=20 > IETF meeting.=20 > Also, these changes are being made for management reasons and=20 > are not intended=20 > to be a "reset" on WG activities or to halt or interrupt=20 > progress on current=20 > ongoing WG activities.=20 >=20 > We'd like to hear from the WG members if they see any fatal=20 > flaws with the proposed approach. Please send us your=20 > feedback by May 11th.=20 >=20 > Regards,=20 >=20 > --=20 > Alex Zinin=20 > IETF SUB-IP Area Co-Director=20 >=20 >=20 >=20 ------=_NextPart_000_00DD_01C31547.D53AD5D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
    You raise a good point. Is there going to be = any=20 discussion of
actual=20 provisioning of VPNs?
 
    --Tom
 
-----Original Message-----
From:=20 pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of = Paul=20 Knight
Sent: Wednesday, May 07, 2003 12:56 PM
To: = Alex=20 Zinin; ppvpn@nortelnetworks.com
Cc: pwe3@ietf.org; Wijnen, = Bert=20 (Bert); Thomas Narten; Peterson, Jon; Allison = Mankin
Subject: [PWE3]=20 RE: IMPORTANT: Strategy for VPN work in IETF

Hi Alex,

The proposed split seems to put very little emphasis = on the=20 "PP" of PPVPN.

The proposed focus on technologies for L2 and L3 is = likely to=20 seriously disrupt the focus on the "Provider Provisioned" concept, = where much=20 of the value comes from aiming for interoperation across all major VPN = technologies.  Of course, we could have PPL2VPN and PPL3VPN, but = as has=20 been pointed out, we then need to coordinate the "PP" parts across the = two=20 WGs. 

VPN customers want a bundle of VPN services, and = don't really=20 care whether it is L2 or L3 (or L1) or some mixture.  VPN service = providers want an interoperable toolkit which they can use to design = services=20 that they can differentiate in various ways to attract VPN customers. = PPVPN is=20 providing a forum to define the operation of the VPN tools.  = Regardless=20 of L2 or L3 technologies, there is a need for simple and interoperable = mechanisms for VPN membership and discovery, security considerations, = SLA=20 verification, and a host of management areas.  These mechanisms = are being=20 defined, clarified, and debated in PPVPN mostly without regard to the = specific=20 L2 or L3 approaches.  They should not be either dropped, or split = across=20 two WGs.

Yes there is a lot of work in the group, but if it = gets=20 fragmented and things slip through the cracks, then we will be forcing = the VPN=20 service providers, vendors, and customers to do much more work and = spend much=20 more time in the long run.

In terms of meeting logistics, we will find that = many of the=20 same people will be attending and developing drafts for the proposed = L2 and L3=20 WGs, so we will have to make sure that they don't overlap... Just the = same as=20 if we plan extended meeting times for the current PPVPN when it is=20 needed.

Finally, I'm closely involved with two areas of work = in L3=20 VPNs in PPVPN, and we are getting to the point where much of the basic = work is=20 stable, so the L3VPN may not justify a dedicated WG for much longer, = although=20 it does need a WG in which to operate.

I would suggest planning for a longer meeting in = Vienna (if=20 the agenda justifies it) and bringing this proposal up for discussion=20 there.

Regards,
Paul

> -----Original Message-----
>=20 From: Alex Zinin [mailto:zinin@psg.com]=20
> Sent: Sunday, May 04, 2003 3:12 = AM=20
> To: ppvpn@nortelnetworks.com
> Cc: pwe3@ietf.org; Wijnen, Bert (Bert); Thomas Narten;=20
> Peterson, Jon; Allison Mankin =
> Subject: IMPORTANT: Strategy for VPN work in IETF =
>
>
>=20 Folks,
>
> = Since San=20 Francisco IETF meeting the IESG has been
>=20 considering the situation in the SUB-IP area and in the PPVPN =
> Working Group in particular.
>=20
> Such close attention to this WG was = triggered by=20 numerous
> concerns that the IESG members = received=20 from the WG
> participants about limited = and slow=20 progress within the WG
> despite the = efforts of the=20 WG chairs and its members. The
> IESG = also used=20 this opportunity to consider the IETF area
> that=20 the PPVPN work would fit best.
> =
> After much deliberation, the involved ADs (Bert, Thomas, = and I)=20 are
> considering the following = organizational=20 changes in order to
> improve WG =
> focus and productivity and ensure faster progress of the =
> VPN-related work:
>=20
>  1. Split of Layer-2 and Layer-3 = VPN work in=20 separate Working Groups.
> =
>     The L2 and L3 VPN work spaces = are each big=20 enough to
> warrant a separate =
>     WG. While concentration of all = VPN-related=20 work in a
> single forum was =
>     the right thing to do to ensure=20 coordination of efforts
> when the PPVPN=20
>     WG was created = and L2 VPN=20 work came in, such
> concentration is=20 causing
>     scaling = problems=20 within the WG at this moment.
> =
>     Migration of work into two = separate WGs=20 for L2 and L3 VPN
> technologies =
>     with more specific WG charters = will help=20 to focus
> discussions, prevent =
>     staff and meeting time = overloading, and=20 will aid faster
> progress of =
>     corresponding = technologies.=20
>
>  2. = Migration of the=20 VPN-related work to the Internet area.
>=20
>     As previously = discussed,=20 VPN-related work could be argued
> to = belong=20
>     to more than one area. = Tunneling=20 mechanisms are the property that
>     gravitates this work to the = Internet area,=20 which is where
> we believe =
>     the VPN work should go. =
>
>     = As part of=20 this move, we are also considering moving PWE3
>=20 into INT,
>     so = that=20 L2TPEXT, PWE3, and thew new VPN WGs are operating
>=20 in the same
>     = area.=20
>
> Based on the = above=20 considerations, we are considering the
> = following=20 steps:
>
>  1. Two=20 new WGs--L2VPN and L3VPN--will be created in the
>=20 Internet area.
>     = The=20 mailing lists will be established and the discussion
> of the proposed
>     charters of the new WGs will be = initiated=20 shortly.
>
>  2.=20 Once the charters of the new WGs are agreed upon and
> approved by the IESG,
>     creation of the L2VPN and L3VPN = WGs and=20 shutdown of the
> PPVPN WG will be =
>     performed simultaneously. PPVPN = WG=20 documents will be
> migrated to the=20
>     corresponding = new=20 WGs.
>
> It = is our=20 intention to complete this process by the Vienna
>=20 IETF meeting.
> Also, these changes are = being made=20 for management reasons and
> are not = intended=20
> to be a "reset" on WG activities or to = halt or=20 interrupt
> progress on current =
> ongoing WG activities.
>=20
> We'd like to hear from the WG members = if they see=20 any fatal
> flaws with the proposed = approach.=20 Please send us your
> feedback by May = 11th.=20
>
> Regards, =
>
> --
> Alex=20 Zinin
> IETF SUB-IP Area = Co-Director=20
>
> =
>

------=_NextPart_000_00DD_01C31547.D53AD5D0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 06:57:57 -0700 Lines: 58 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 16:01:40 2003 Return-path: To: "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > 1) Use of VCCV allows you to get as close to the > disposition point as possible; LSP > or ICMP ping doesn't necessarily do > this in all cases. If you can test the PSN tunnel and if you can test the carried service using segment OAM then you can achieve the same result (i.e.,get as close to the disposition point as possible) For example in ATM/MPLS case, if you test the LSP tunnel between PEs using any method you like (LSP-ping, your hated Y.1711, etc.) then you are sure the PEs have connectivity. Now if you run an ATM segment OAM between PEs, you can test that the ATM connection is correctly mapped to the proper PW or not. So we won't need PW OAM. If your answer is that some technologies such as Ethernet don't have segment OAM, then the answer is go and fix them, which is what MEF and ITU are doing at this time. > > 2) VCCV is a generic CV mechanism for IETF defined > PWs regardless of the underlying PSN technology > that allows CV traffic to flow on EXACTLY the > same path as the data plane. It is not generic, it requires a CW and a reserved word in it. for example SONET/SDH PW doesn't have it. > Also, pitching Y.1711 as a possible alternative is >irresponsible. It is badly broken for LDP-based networks >and has been shown to be quite difficult to implement >besides, so lets not go there. Of course, its proponents >are working feverishly to patch it up within the ITU >so that they can ask service providers to replace all >of their hardware (again) to support the ultimate OAM >swiss army knife. I assert that it is certainly >not ready and should not be considered as an acceptable >approach. I can equally prove that LSP-ping is badly broken. LSP-ping is in effect a quick patch to the problem (like a band aid), not a proper OAM. But Let's not go there. > > Again, read the OAM requirements referenced above. >OAM traffic MUST be carried on the same data path regardless >of whether ECMP is active or not. Are you suggesting that >we should ignore that 25 SPs have told us? No we should not ignore them. But you are confusing the solution with the requirement. I am sure the 25 SPs didn't mandate VCCV ! All they need is a way to manage their PWs and as I said above there are better architectural alternatives to VCCV. > > --Tom -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 10:04:53 -0400 Organization: Cisco Systems, Inc. Lines: 57 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6805@i2km07-ukbr.domain1.systemhost.net> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , , , , , X-From: pwe3-admin@ietf.org Thu May 08 16:07:37 2003 Return-path: To: , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6805@i2km07-ukbr.domain1.systemhost.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of neil.2.harrison@bt.com > Sent: Thursday, May 08, 2003 6:13 AM > To: rahul@redback.com; mustapha.aissaoui@alcatel.com > Cc: dallan@nortelnetworks.com; Sasha@axerra.com; > Shahram_Davari@pmc-sierra.com; swallow@cisco.com; > danny@tcb.net; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Rahul, please see below, regards, Neil > > Mustapha, > > > > [clipped] > > > > > > > PWE3 work, I propose to address the issues raised in 2 phases: > > > > > > Phase 1: > > > the current scope of the PWE3 working group is to provide for a PW > > > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > > > environment, the native service OAM and link management > achieves all > > > what is needed and we do not need to define a specific PW OAM. At > > > > In this environment there is still a need for a PW OAM. > > Please see section > > 3 of: > > > > draft-nadeau-pwe3-vccv-00.txt > > NH=> There is not a 'need' for PWs at all. The only 'need' > arises due to reasons I pointed out in my response to > Mustapha. Your lack of need aside, the fact still remains that there are lots of deployments of PWs. Therefore, they do indeed need PW-level OAM. --Tom Given we still have to manage the MPLS layer > networks why not do it once and do it right? However, given > it *is* possible to do things differently/simpler, then I > think operators who want to have such solutions should be > able to achieve them. And of course, those who want PWs as > being defined can have them too. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 10:17:39 -0400 Lines: 271 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3156C.945D449C" Cc: "'Sasha Vainshtein'" , "'Shahram Davari'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 16:21:47 2003 Return-path: To: "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3156C.945D449C Content-Type: text/plain; charset="iso-8859-1" Tom: > > > OAM can > > be achieved using either IP tools such as LSP-Ping, or Y.1711 > > tools. Any OAM specific issues with the PSN are clearly > > outside the scope of the PWE3. > > Use of just LSP-ping for PWs is not going to cut > the mustard for two reasons, which I will explain > below. I believe that LSP ping/ICMP ping/native OAM > and VCCV need to be used in conjunction to satisfy > the requirements specified in the OAM requirements. I thought VCCV as described "was" LSP PING or ICMP just carried in a form hidden from existing proprietary ECMP implementations. Why do you draw such an artifical distinction? > > 1) Use of VCCV allows you to get as close to the > disposition point as possible; LSP > or ICMP ping doesn't necessarily do > this in all cases. > > 2) VCCV is a generic CV mechanism for IETF defined > PWs regardless of the underlying PSN technology > that allows CV traffic to flow on EXACTLY the > same path as the data plane. > > This is important because tools designed to > test/debug/verify PWs can be written more > generally. This is also important because > there are cases where using regular ICMP-ping > will not follow the same data plane path over > the IP tunnel. > > Also, pitching Y.1711 as a possible alternative is > irresponsible. It is badly broken for LDP-based networks and > has been shown to be quite difficult to implement besides, so > lets not go there. > Of course, its proponents > are working feverishly to patch it up within the ITU > so that they can ask service providers to replace all > of their hardware (again) to support the ultimate OAM > swiss army knife. I find your characterization rather hysterical....you may want to check the defintion of "irresponsible". > I assert that it is certainly > not ready and should not be considered as an acceptable approach. > > > The only requirement is to > > address the IP aliasing issue. The most straighforward way to > > resolve it is to make sure that all CWs have the nibble > > following immediately the bottom label set to a value > > different of 4, 6, or 8 (zero seems to be the accepted > > value). This means that the SONET encapsulation would have to > > go with Option 3 in Andy's three proposals. > > > > Phase 2: > > the work of the PWE3 may expand to support endpoints of > > different types (e.g., FR-MPLS-Ethernet). In this scenario, > > if the native service is terminated locally at each PE, then > > clearly there is a need for the following: a. the ability to > > define a PW specific OAM and link management functions and > > inteoperate it with the native service OAM and link > > management. b. the ability to self-identify the protocol > > carried in a single PW. > > > A PW can carry both user packets and > > OAM packets and we want them to share the same path in the > > presence of ECMP. > > Again, read the OAM requirements referenced above. > OAM traffic MUST be carried on the same data path regardless > of whether ECMP is active or not. Are you suggesting that > we should ignore that 25 SPs have told us? Looks to me that he stated accurately in the sentence above what those 25 SPs told you. Just described it in two phases. So what are you objecting to? Is there a real technical point in this diatrabe? cheers Dave ------_=_NextPart_001_01C3156C.945D449C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough = Consesus?)

Tom:

<snipped>
>
> > OAM can
> > be achieved using either IP tools such as = LSP-Ping, or Y.1711
> > tools. Any OAM specific issues with the = PSN are clearly
> > outside the scope of the PWE3.
>
>       Use of just = LSP-ping for PWs is not going to cut
> the mustard for two reasons, which I will = explain
> below. I believe that LSP ping/ICMP ping/native = OAM
> and VCCV need to be used in conjunction to = satisfy
> the requirements specified in the OAM = requirements.

I thought VCCV as described "was" LSP PING = or ICMP just carried in a form hidden from existing proprietary ECMP = implementations. Why do you draw such an artifical = distinction?

>
>       1) Use of VCCV = allows you to get as close to the
>       =         disposition point as = possible; LSP
>       =         or ICMP ping doesn't = necessarily do
>       =         this in all cases.
>
>       2) VCCV is a = generic CV mechanism for IETF defined
>       =         PWs regardless of the = underlying PSN technology
>       =         that allows CV traffic to = flow on EXACTLY the
>       =         same path as the data = plane.
>
>       =         This is important because = tools designed to
>       =         test/debug/verify PWs can be = written more
>       =         generally.  This is = also important because
>       =         there are cases where using = regular ICMP-ping
>       =         will not follow the same = data plane path over
>       =         the IP tunnel.
>
>       Also, pitching = Y.1711 as a possible alternative is
> irresponsible. It is badly broken for LDP-based = networks and
> has been shown to be quite difficult to = implement besides, so
> lets not go there.
> Of course, its proponents
> are working feverishly to patch it up within = the ITU
> so that they can ask service providers to = replace all
> of their hardware (again) to support the = ultimate OAM
> swiss army knife.

I find your characterization rather hysterical....you = may want to check the defintion of "irresponsible".

> I assert that it is certainly
> not ready and should not be considered as an = acceptable approach.
>
> > The only requirement is to
> > address the IP aliasing issue. The most = straighforward way to
> > resolve it is to make sure that all CWs = have the nibble
> > following immediately the bottom label set = to a value
> > different of 4, 6, or 8 (zero seems to be = the accepted
> > value). This means that the SONET = encapsulation would have to
> > go with Option 3 in Andy's three = proposals.
> >
> > Phase 2:
> > the work of the PWE3 may expand to support = endpoints of
> > different types (e.g., FR-MPLS-Ethernet). = In this scenario,
> > if the native service is terminated = locally at each PE, then
> > clearly there is a need for the following: = a. the ability to
> > define a PW specific OAM and link = management functions and
> > inteoperate it with the native service OAM = and link
> > management. b. the ability to = self-identify the protocol
> > carried in a single PW.
>
> > A PW can carry both user packets = and
> > OAM packets and we want them to share the = same path in the
> > presence of ECMP.
>
>       Again, read the = OAM requirements referenced above.
> OAM traffic MUST be carried on the same data = path regardless
> of whether ECMP is active or not.  Are you = suggesting that
> we should ignore that 25 SPs have told = us?

Looks to me that he stated accurately in the sentence = above what those 25 SPs told you. Just described it in two phases. So = what are you objecting to? Is there a real technical point in this = diatrabe?

cheers
Dave



------_=_NextPart_001_01C3156C.945D449C-- From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Juha Heinanen Subject: RE: [PWE3] RE: IMPORTANT: Strategy for VPN work in IETF Date: Thu, 8 May 2003 17:23:56 +0300 Lines: 17 References: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> <00dc01c31569$5c4c75d0$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Paul Knight" , "'Alex Zinin'" , , , "'Wijnen, Bert \(Bert\)'" , "'Thomas Narten'" , "'Peterson, Jon'" , "'Allison Mankin'" X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Thu May 08 16:24:17 2003 Return-path: To: In-Reply-To: <00dc01c31569$5c4c75d0$6401a8c0@amer.cisco.com> X-Mailer: VM 7.14 under Emacs 21.2.1 X-SMTP-HELO: harjus.eng.song.fi X-SMTP-MAIL-FROM: jh@lohi.eng.song.fi X-SMTP-RCPT-TO: paul.knight@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: harjus.eng.song.fi [195.10.149.20] Status: O Thomas D. Nadeau writes: > You raise a good point. Is there going to be any discussion of > actual provisioning of VPNs? provisioning is indeed an important issue. i have been told that commercial provisioning systems for bgp/mpls vpns are very expensive. may be that is because provisioning of them is difficult to do. a good solution is such for which writing automatic provisioning tools is very easy. this is true for radius based solutions, where the provisioning system needs little interaction with the actual pes. -- juha From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 10:35:52 -0400 Organization: Cisco Systems, Inc. Lines: 108 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C92E@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , X-From: pwe3-admin@ietf.org Thu May 08 16:41:48 2003 Return-path: To: "'Shahram Davari'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C92E@nt-exch-yow.pmc-sierra.bc.ca> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, May 08, 2003 9:58 AM > To: 'tnadeau@cisco.com'; 'Mustapha Aissaoui'; 'David Allan' > Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson'; > pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > 1) Use of VCCV allows you to get as close to the > > disposition point as possible; LSP > > or ICMP ping doesn't necessarily do > > this in all cases. > > If you can test the PSN tunnel and if you can test the > carried service using segment OAM then you can achieve the > same result (i.e.,get as close to the disposition point as > possible) For example in ATM/MPLS case, if you test the LSP > tunnel between PEs using any method you like (LSP-ping, your > hated Y.1711, etc.) then you are sure the PEs have > connectivity. Nope. If you have actually implemented this, you would understand my point. The code that intercepts the MPLS LSP ping code is different from that that does the disposition. It is close, but not as close as possible. Also, you are not considering what we should do if IP is the PSN. BTW, the same arguments apply. > Now if you run an ATM segment OAM between PEs, > you can test that the ATM connection is correctly mapped to > the proper PW or not. And what do you do if you find that it is not correctly mapped? What does ATM segment OAM tell you that helps you trouble-shoot the situation? > So we won't need PW OAM. If your answer > is that some technologies such as Ethernet don't have segment > OAM, then the answer is go and fix them, I think that even with segement OAM you still need PW OAM (VCCV). To further complicate things, consider what is needed for VPLS. > which is what MEF and ITU are doing at this time. I wouldn't call what the ITU is doing anything useable. I would call what the IEEE is doing for 801.11ab the right way, however. > > 2) VCCV is a generic CV mechanism for IETF defined > > PWs regardless of the underlying PSN technology > > that allows CV traffic to flow on EXACTLY the > > same path as the data plane. > > It is not generic, it requires a CW and a reserved word in > it. for example SONET/SDH PW doesn't have it. > > > Also, pitching Y.1711 as a possible alternative is > irresponsible. It > >is badly broken for LDP-based networks and has been shown to > be quite > >difficult to implement besides, so lets not go there. Of course, its > >proponents are working feverishly to patch it up within the ITU > >so that they can ask service providers to replace all > >of their hardware (again) to support the ultimate OAM > >swiss army knife. I assert that it is certainly > >not ready and should not be considered as an acceptable > >approach. > > I can equally prove that LSP-ping is badly broken. LSP-ping > is in effect a quick patch to the problem (like a band aid), > not a proper OAM. But Let's not go there. Well, we all have our opinions. I guess the market will tell us ultimately what will be used. > > Again, read the OAM requirements referenced above. > >OAM traffic MUST be carried on the same data path regardless > >of whether ECMP is active or not. Are you suggesting that > >we should ignore that 25 SPs have told us? > > No we should not ignore them. But you are confusing the > solution with the requirement. I am sure the 25 SPs didn't > mandate VCCV ! All they need is a way to manage their PWs and > as I said above there are better architectural alternatives to VCCV. You are right that most SPs don't care about the solution, just that it solves the problem, at least at a high level. However, there are many ways to skin a cat, and from the feedback I have been getting use of VCCV and LSP ping are the way my customers want to skin this cat (i.e.: they don't want to use y.1711's so-called 'architecturally correct' solution). --Tom > > > > --Tom > -Shahram > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 08:04:15 -0700 Lines: 85 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 17:07:55 2003 Return-path: To: "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Nope. If you have actually implemented this, you >would understand my point. The code that intercepts the >MPLS LSP ping code is different from that that does the >disposition. I did not argue against this point at all. In fact the segment OAM that I proposed is a recognition of this fact. >It is close, but not as close as possible. Correct, PSN tunnel test gives you PSN connectivity, not PW connectivity. That is why I proposed segment OAM as well. >Also, you are not considering what we should do if IP >is the PSN. Same thing, use IP-ping (like LSP-ping) for the IP connectivity test and then use segment OAM for the carried service. >BTW, the same arguments apply. > >> Now if you run an ATM segment OAM between PEs, >> you can test that the ATM connection is correctly mapped to >> the proper PW or not. > > And what do you do if you find that it is not >correctly mapped? What does ATM segment OAM tell you >that helps you trouble-shoot the situation? If the PSN tunnel test is OK then segment OAM tells you that the ATM VC is not mapped correctly to the proper PW. Then in the diagnostics phase you have to check the actual ATM VC mapping to the PW in both PE ends, and find why the mapping is not correct. > >> So we won't need PW OAM. If your answer >> is that some technologies such as Ethernet don't have segment >> OAM, then the answer is go and fix them, > > I think that even with segement OAM you still need >PW OAM (VCCV). To further complicate things, consider what >is needed for VPLS. No you don't need VCCV. In fact segment OAM gives you a much closer test to the desposition point than VCCV. The reason is simple. The layering is : PSN-PW-ATM. I proposed testing PSN and ATM, but you proposed testing PW. Which one goes higher in the protocol stack? Off course segment OAM goes higher than PW OAM, because ATM is higher in the stack that PW. > >> which is what MEF and ITU are doing at this time. > > I wouldn't call what the ITU is doing anything >useable. I would call what the IEEE is doing for >801.11ab the right way, however. What? 801.11ab !!!!!!!!! is this a new IEEE group? As far as I know IEEE is only doing link level OAM (802.3ah). > You are right that most SPs don't care about the >solution, just that it solves the problem, at least >at a high level. However, there are many ways to >skin a cat, and from the feedback I have been getting >use of VCCV and LSP ping are the way my customers >want to skin this cat (i.e.: they don't want to use >y.1711's so-called 'architecturally correct' solution). > > --Tom The PSN OAM method that you use is irrelevant to this discussion. So please don't bring that as a justification for VCCV. As you said your customers should not care how the PW management is solved, they just want a solution. It is the duty of IETF to find the best solution. If they want VCCV please tell them to explain why they think it is superior to other proposals (may be you have't given them any more options). So far I have seen only one provider (BT) that has spoken on the list and in fact not in favor of VCCV. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 11:07:01 -0400 Organization: Cisco Systems, Inc. Lines: 412 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0128_01C31551.F64C84D0" Cc: "'Sasha Vainshtein'" , "'Shahram Davari'" , "'George Swallow'" , "'Danny McPherson'" , X-From: pwe3-admin@ietf.org Thu May 08 17:12:33 2003 Return-path: To: "'David Allan'" , "'Mustapha Aissaoui'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0128_01C31551.F64C84D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com]=20 Sent: Thursday, May 08, 2003 10:18 AM To: 'tnadeau@cisco.com'; 'Mustapha Aissaoui' Cc: 'Sasha Vainshtein'; 'Shahram Davari'; 'George Swallow'; 'Danny McPherson'; pwe3@ietf.org Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) Tom:=20 =20 >=20 > > OAM can=20 > > be achieved using either IP tools such as LSP-Ping, or Y.1711=20 > > tools. Any OAM specific issues with the PSN are clearly=20 > > outside the scope of the PWE3.=20 >=20 > Use of just LSP-ping for PWs is not going to cut=20 > the mustard for two reasons, which I will explain=20 > below. I believe that LSP ping/ICMP ping/native OAM=20 > and VCCV need to be used in conjunction to satisfy=20 > the requirements specified in the OAM requirements.=20 I thought VCCV as described "was" LSP PING or ICMP just carried in a = form hidden from existing proprietary ECMP implementations. Why do you draw = such an artifical distinction?=20 It is not artificial. VCCV can be used as a generic "OAM container" = between two PW end-points regardless of the underlying PSN that carries this information over the same data plane path as normal traffic. =20 >=20 > 1) Use of VCCV allows you to get as close to the=20 > disposition point as possible; LSP=20 > or ICMP ping doesn't necessarily do=20 > this in all cases.=20 >=20 > 2) VCCV is a generic CV mechanism for IETF defined=20 > PWs regardless of the underlying PSN technology=20 > that allows CV traffic to flow on EXACTLY the=20 > same path as the data plane.=20 >=20 > This is important because tools designed to=20 > test/debug/verify PWs can be written more=20 > generally. This is also important because=20 > there are cases where using regular ICMP-ping=20 > will not follow the same data plane path over=20 > the IP tunnel.=20 >=20 > Also, pitching Y.1711 as a possible alternative is=20 > irresponsible. It is badly broken for LDP-based networks and=20 > has been shown to be quite difficult to implement besides, so=20 > lets not go there.=20 > Of course, its proponents=20 > are working feverishly to patch it up within the ITU=20 > so that they can ask service providers to replace all=20 > of their hardware (again) to support the ultimate OAM=20 > swiss army knife.=20 I find your characterization rather hysterical....you may want to check = the defintion of "irresponsible". =20 It is irresponsible to tout a mechanism that doesn't work while = claiming that it a) works, b) solves the worlds MPLS OAM problems, and c) does so = in a cost-effective and timely manner. Y.1711 did none of those things originally while claiming it did. It was and still is being positioned = as the "architecturally correct" visionary solution. At that time its proponents suggested that it was okay to replace all of a network's line cards to support this solution. Well, guess what, if we all had drunk = the Y.1711 Koolaid then, SPs would have to be spending OPEX and CAPEX = replacing line cards a second time because shortly after it was ratified at the = ITU, folks like myself showed it not to work for LDP-based networks. Yea, = sure the number of SPs I just mentioned includes a mere %95, but heck, we = should all obey architectural correctness because the Y.1711 folks said so the first time, so we should believe them this time too. So please stop = passing the FUD about Y.1711 being something that it is not because that is = indeed hysterical. --Tom =20 =20 =20 > I assert that it is certainly=20 > not ready and should not be considered as an acceptable approach.=20 >=20 > > The only requirement is to=20 > > address the IP aliasing issue. The most straighforward way to=20 > > resolve it is to make sure that all CWs have the nibble=20 > > following immediately the bottom label set to a value=20 > > different of 4, 6, or 8 (zero seems to be the accepted=20 > > value). This means that the SONET encapsulation would have to=20 > > go with Option 3 in Andy's three proposals.=20 > >=20 > > Phase 2:=20 > > the work of the PWE3 may expand to support endpoints of=20 > > different types (e.g., FR-MPLS-Ethernet). In this scenario,=20 > > if the native service is terminated locally at each PE, then=20 > > clearly there is a need for the following: a. the ability to=20 > > define a PW specific OAM and link management functions and=20 > > inteoperate it with the native service OAM and link=20 > > management. b. the ability to self-identify the protocol=20 > > carried in a single PW.=20 >=20 > > A PW can carry both user packets and=20 > > OAM packets and we want them to share the same path in the=20 > > presence of ECMP.=20 >=20 > Again, read the OAM requirements referenced above.=20 > OAM traffic MUST be carried on the same data path regardless=20 > of whether ECMP is active or not. Are you suggesting that=20 > we should ignore that 25 SPs have told us?=20 Looks to me that he stated accurately in the sentence above what those = 25 SPs told you. Just described it in two phases. So what are you objecting = to? Is there a real technical point in this diatrabe? cheers=20 Dave=20 ------=_NextPart_000_0128_01C31551.F64C84D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: = David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Thursday, May 08, = 2003=20 10:18 AM
To: 'tnadeau@cisco.com'; 'Mustapha = Aissaoui'
Cc:=20 'Sasha Vainshtein'; 'Shahram Davari'; 'George Swallow'; 'Danny = McPherson';=20 pwe3@ietf.org
Subject: RE: [PWE3] PWE3 Arch/CW & RTP = Order=20 (Rough Consesus?)

Tom:

<snipped>
> =
> > OAM can
> > be = achieved using=20 either IP tools such as LSP-Ping, or Y.1711
> >=20 tools. Any OAM specific issues with the PSN are clearly =
> > outside the scope of the PWE3.
>=20
>       Use of = just=20 LSP-ping for PWs is not going to cut
> = the mustard=20 for two reasons, which I will explain
> = below. I=20 believe that LSP ping/ICMP ping/native OAM
> and=20 VCCV need to be used in conjunction to satisfy
>=20 the requirements specified in the OAM requirements.

I thought VCCV as described "was" LSP PING or ICMP = just=20 carried in a form hidden from existing proprietary ECMP = implementations. Why=20 do you draw such an artifical distinction? 

It is not = artificial. VCCV can=20 be used as a generic "OAM container" between two PW end-points = regardless=20 of the = underlying=20 PSN that carries this information over the same data plane path as = normal=20 traffic.

 

>
>=20       1) Use of VCCV allows you to get as = close to=20 the
>      =20         disposition point as = possible; LSP=20
>      =20         or ICMP ping doesn't = necessarily do=20
>      =20         this in all cases. =
>
> =       2)=20 VCCV is a generic CV mechanism for IETF defined
>=20       =         PWs=20 regardless of the underlying PSN technology
>=20       =         that=20 allows CV traffic to flow on EXACTLY the
>=20       =         same=20 path as the data plane.
> =
>      =20         This is important because = tools=20 designed to
> =      =20         test/debug/verify PWs can = be=20 written more
> =      =20         generally.  This is = also=20 important because
> =      =20         there are cases where using = regular=20 ICMP-ping
> =      =20         will not follow the same = data plane=20 path over
> =      =20         the IP tunnel. =
>
> =       Also,=20 pitching Y.1711 as a possible alternative is
>=20 irresponsible. It is badly broken for LDP-based networks and =
> has been shown to be quite difficult to implement = besides, so=20
> lets not go there.
>=20 Of course, its proponents
> are working = feverishly=20 to patch it up within the ITU
> so that = they can=20 ask service providers to replace all
> of = their=20 hardware (again) to support the ultimate OAM
>=20 swiss army knife.

I find your characterization rather = hysterical....you may want=20 to check the defintion of "irresponsible".  

  It is irresponsible to tout a mechanism that doesn't work = while=20 claiming that it a) works, b) solves the worlds MPLS OAM problems, and = c) does=20 so in a cost-effective and timely manner.  Y.1711 did none of = those=20 things originally while claiming it did. It was and = still is=20 being positioned as the "architecturally correct" visionary = solution. At=20 that time its proponents suggested that it was okay to replace all of = a=20 network's line cards to support this solution. Well, guess what, if we = all had=20 drunk the Y.1711 Koolaid then, SPs would have to be spending OPEX and = CAPEX=20 replacing line cards a second time because shortly after it was = ratified at=20 the ITU, folks like myself showed it not to work for = LDP-based=20 networks. Yea, sure the number of SPs I just = mentioned includes a=20 mere %95, but heck, we should all obey architectural correctness = because the=20 Y.1711 folks said so the first time, so we should believe them this = time=20 too.  So please stop passing the FUD about Y.1711 being something = that it=20 is not because that is = indeed hysterical.

    --Tom

 

 

 

> I assert that it is certainly
> not ready and should not be considered as an acceptable=20 approach.
>
> > The=20 only requirement is to
> > address the = IP=20 aliasing issue. The most straighforward way to
>=20 > resolve it is to make sure that all CWs have the nibble =
> > following immediately the bottom label set to a = value=20
> > different of 4, 6, or 8 (zero = seems to be=20 the accepted
> > value). This means = that the=20 SONET encapsulation would have to
> > = go with=20 Option 3 in Andy's three proposals.
> = >=20
> > Phase 2:
> >=20 the work of the PWE3 may expand to support endpoints of =
> > different types (e.g., FR-MPLS-Ethernet). In this = scenario,=20
> > if the native service is = terminated locally=20 at each PE, then
> > clearly there is = a need for=20 the following: a. the ability to
> > = define a PW=20 specific OAM and link management functions and
>=20 > inteoperate it with the native service OAM and link =
> > management. b. the ability to self-identify the = protocol=20
> > carried in a single PW. =
>
> > A PW can carry both = user packets=20 and
> > OAM packets and we want them = to share=20 the same path in the
> > presence of = ECMP.=20
>
>=20       Again, read the OAM requirements = referenced=20 above.
> OAM traffic MUST be carried on = the same=20 data path regardless
> of whether ECMP is = active or=20 not.  Are you suggesting that
> we = should=20 ignore that 25 SPs have told us?

Looks to me that he stated accurately in the = sentence above=20 what those 25 SPs told you. Just described it in two phases. So what = are you=20 objecting to? Is there a real technical point in this = diatrabe?

cheers
Dave=20



------=_NextPart_000_0128_01C31551.F64C84D0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 08 May 2003 11:19:46 -0400 Organization: Alcatel Networks Corporaton Lines: 28 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 17:23:04 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Rahul Aggarwal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Rahul, Rahul Aggarwal wrote: > > Mustapha, > > [clipped] > > > PWE3 work, I propose to address the issues raised in 2 phases: > > > > Phase 1: > > the current scope of the PWE3 working group is to provide for a PW > > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > > environment, the native service OAM and link management achieves all > > what is needed and we do not need to define a specific PW OAM. At > > In this environment there is still a need for a PW OAM. Please see section > 3 of: > > draft-nadeau-pwe3-vccv-00.txt There is nothing in Section 3 which justifies the need for a PW OAM in the case of endpoints of the same type. You may want to double check it. > > Regards, > rahul From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: David Zelig Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 18:25:32 +0200 Lines: 20 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 17:36:50 2003 Return-path: To: "'Shahram Davari'" , "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > No you don't need VCCV. In fact segment OAM gives you a > much closer test to the desposition point than VCCV. The reason is > simple. The layering is : PSN-PW-ATM. I proposed testing PSN > and ATM, but you proposed testing PW. Which one goes higher in > the protocol stack? Off course segment OAM goes higher than > PW OAM, because ATM is higher in the stack that PW. > > Shahram, two major points are not solved with the suggestion to use segment OAM of the native signal: 1) What happened if the customer is using the segmented OAM over a span that include the PW? 2) A unified approach, applicable to all carried signal types, has operational benefits for the operators who wish to use PW for carrying of more than one signal type. David From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 11:29:02 -0400 Organization: Cisco Systems, Inc. Lines: 116 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C930@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , X-From: pwe3-admin@ietf.org Thu May 08 17:38:03 2003 Return-path: To: "'Shahram Davari'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C930@nt-exch-yow.pmc-sierra.bc.ca> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, May 08, 2003 11:04 AM > To: 'tnadeau@cisco.com'; 'Mustapha Aissaoui'; 'David Allan' > Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson'; > pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > Nope. If you have actually implemented this, you > >would understand my point. The code that intercepts the > >MPLS LSP ping code is different from that that does the disposition. > > I did not argue against this point at all. In fact the > segment OAM that I proposed is a recognition of this fact. > > >It is close, but not as close as possible. > > Correct, PSN tunnel test gives you PSN connectivity, not PW > connectivity. That is why I proposed segment OAM as well. > > >Also, you are not considering what we should do if IP > >is the PSN. > > Same thing, use IP-ping (like LSP-ping) for the IP > connectivity test and then use segment OAM for the carried service. If segment-OAM means VCCV then I agree. If it doesn't that I don't agree. There are load-share cares where if you ping the L2TPv3 control channel you might not take the same data plane path as the data. The forthcoming version of VCCV will include an option to send information for L2TPv3. > >BTW, the same arguments apply. > > > >> Now if you run an ATM segment OAM between PEs, > >> you can test that the ATM connection is correctly mapped to > >> the proper PW or not. > > > > And what do you do if you find that it is not > >correctly mapped? What does ATM segment OAM tell you > >that helps you trouble-shoot the situation? > > If the PSN tunnel test is OK then segment OAM > tells you that the ATM VC is not mapped correctly > to the proper PW. Then in the diagnostics phase you > have to check the actual ATM VC mapping to the PW in > both PE ends, and find why the mapping is not correct. What do you do in the VPLS case? The segment OAM in that case goes completely end-to-end. How do you know which segment is broken in that case? > >> So we won't need PW OAM. If your answer > >> is that some technologies such as Ethernet don't have segment > >> OAM, then the answer is go and fix them, > > > > I think that even with segement OAM you still need > >PW OAM (VCCV). To further complicate things, consider what > >is needed for VPLS. > > > No you don't need VCCV. In fact segment OAM gives you a > much closer test to the desposition point than VCCV. The > reason is simple. The layering is : PSN-PW-ATM. I proposed > testing PSN and ATM, but you proposed testing PW. Which one > goes higher in the protocol stack? Off course segment OAM > goes higher than PW OAM, because ATM is higher in the stack that PW. I propose using native OAM to go from end-to-end, if that fails, use VCCV for the PW and perhaps LSP ping/trace for the PSN. > >> which is what MEF and ITU are doing at this time. > > > > I wouldn't call what the ITU is doing anything > >useable. I would call what the IEEE is doing for > >801.11ab the right way, however. > > What? 801.11ab !!!!!!!!! is this a new IEEE group? > As far as I know IEEE is only doing link level OAM (802.3ah). 802.1ad. Stiky fingers. > > You are right that most SPs don't care about the > >solution, just that it solves the problem, at least > >at a high level. However, there are many ways to > >skin a cat, and from the feedback I have been getting > >use of VCCV and LSP ping are the way my customers > >want to skin this cat (i.e.: they don't want to use > >y.1711's so-called 'architecturally correct' solution). > > > > --Tom > > The PSN OAM method that you use is irrelevant to this > discussion. So please don't bring that as a justification for VCCV. It is indeed germain to this discussion for the reasons I have given. > As you said your customers should not care how the PW > management is solved, they just want a solution. It is the > duty of IETF to find the best solution. If they want VCCV > please tell them to > explain why they think it is superior to other proposals (may > be you have't given them any more options). So far I have > seen only one provider (BT) that has spoken on the list and > in fact not in favor of VCCV. Indeed more providers' operational departments need to speak on this issue. --Tom From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 08 May 2003 11:56:49 -0400 Organization: Alcatel Networks Corporaton Lines: 264 Sender: pwe3-admin@ietf.org References: <00c401c31567$147e9280$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 18:08:38 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: tnadeau@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, "Thomas D. Nadeau" wrote: > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Mustapha Aissaoui > > Sent: Wednesday, May 07, 2003 6:42 PM > > To: David Allan > > Cc: 'Sasha Vainshtein'; 'Shahram Davari'; 'George Swallow'; > > Danny McPherson; pwe3@ietf.org > > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > Dave and all, > > I agree with your assessment. Given that we want to progress > > the PWE3 work, I propose to address the issues raised in 2 phases: > > > > Phase 1: > > the current scope of the PWE3 working group is to provide for > > a PW between two endpoints of the same type (e.g., > > FR-MPLS-FR). In this environment, the native service OAM and > > link management achieves all what is needed and we do not > > need to define a specific PW OAM. At the PSN level, > > I suggest that you read the MPLS OAM > requirements in draft-ietf-mpls-oam-requirements-00.txt, > as well as the justifications for VCCV in > draft-nadeau-pwe3-vccv-00.txt and then tell the > 25 or so service providers that were polled for > these requirements about how it is so > clear that there is no need to have such a mechanism. I am really not saying anything different from what service providers are saying. I am just stating that in the case of endpoints of the same type we can troubleshoot the PSN using PSN specific OAM (out of scope of PWE3) and the PW using the native service OAM. Of course, one needs to correlate a defect indication from the PSN level to the native service level, but this is a local PE matter. > > OAM can > > be achieved using either IP tools such as LSP-Ping, or Y.1711 > > tools. Any OAM specific issues with the PSN are clearly > > outside the scope of the PWE3. > > Use of just LSP-ping for PWs is not going to cut > the mustard for two reasons, which I will explain > below. I believe that LSP ping/ICMP ping/native OAM > and VCCV need to be used in conjunction to satisfy > the requirements specified in the OAM requirements. > > 1) Use of VCCV allows you to get as close to the > disposition point as possible; LSP > or ICMP ping doesn't necessarily do > this in all cases. > > 2) VCCV is a generic CV mechanism for IETF defined > PWs regardless of the underlying PSN technology > that allows CV traffic to flow on EXACTLY the > same path as the data plane. > > This is important because tools designed to > test/debug/verify PWs can be written more > generally. This is also important because > there are cases where using regular ICMP-ping > will not follow the same data plane path over > the IP tunnel. Again, you are saying the same thing as I said. The only difference is that you believe that the PW level OAM requires a new mechanism while I am challenging you that it not required in the case of endpoints of the same type. > > Also, pitching Y.1711 as a possible alternative is > irresponsible. It is badly broken for LDP-based networks > and has been shown to be quite difficult to implement > besides, so lets not go there. Of course, its proponents > are working feverishly to patch it up within the ITU > so that they can ask service providers to replace all > of their hardware (again) to support the ultimate OAM > swiss army knife. I assert that it is certainly > not ready and should not be considered as an acceptable > approach. I am not pitching anything here. I think you are overreacting :-) > > The only requirement is to > > address the IP aliasing issue. The most straighforward way to > > resolve it is to make sure that all CWs have the nibble > > following immediately the bottom label set to a value > > different of 4, 6, or 8 (zero seems to be the accepted > > value). This means that the SONET encapsulation would have to > > go with Option 3 in Andy's three proposals. > > > > Phase 2: > > the work of the PWE3 may expand to support endpoints of > > different types (e.g., FR-MPLS-Ethernet). In this scenario, > > if the native service is terminated locally at each PE, then > > clearly there is a need for the following: a. the ability to > > define a PW specific OAM and link management functions and > > inteoperate it with the native service OAM and link > > management. b. the ability to self-identify the protocol > > carried in a single PW. > > > A PW can carry both user packets and > > OAM packets and we want them to share the same path in the > > presence of ECMP. > > Again, read the OAM requirements referenced above. > OAM traffic MUST be carried on the same data path regardless > of whether ECMP is active or not. Are you suggesting that > we should ignore that 25 SPs have told us? Tom, please read carefully before you reply. You just wrote exactly what I wrote. The good news is that we are in agreement here at least. > > --Tom > > > A PW can also carry both a end-user bridged > > and a routed PDU (multiprotocol PW). This is where the > > MPLS/PW PID is useful but it should be addressed in a much > > wider scope than the current PWE3 issues. > > > > Let me know what you think. > > Mustapha. > > ------------ > > > David Allan wrote: > > > > > > We do have two separate problems.... > > > > > > 1) Is a means of identifying a generic payload. This would > > appear to > > > potentially require additional services such as sequencing > > etc. stuff > > > already dealt with in the exissting PWE control words. This would > > > include ordering, and if this was preserved in the presence of > > > proprietary ECMP so much the better. > > > > > > 2) A means of instrumenting PWs such that packets fate > > shares with PW > > > forwarding. Tom has proposed VCCV which needs an available > > bit in the > > > CW and control handshaking to agree on what the bit means. > > The PPP DLL > > > approach (Georges proposal) or my proposal permits the > > instrumenting > > > protocol to self identify and therefore IMHO is preferable. > > > > > > But I am skeptical that simply having a protocol identifier > > means a PW > > > can carry anything. Its not designed with the requisite > > attributes for > > > service bearing. If we want "carry anything" with ordering > > > fragmentation etc. we have more to do. > > > > > > my 2 cents > > > Dave > > > > > > > -----Original Message----- > > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > > > Sent: Tuesday, May 06, 2003 4:00 AM > > > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > > > Cc: pwe3@ietf.org > > > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > > > > Hi all, > > > > > > > > I believe that George's comment has been very much in place. > > > > > > > > The "MPLS PID" story looks to me like following: > > > > > > > > 1. There was a recognized but, for some reasons, undeclared need > > > > > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > > > complied with this, and some did not; some others simply > > > > declared that the CW is optional. > > > > > > > > 2. At some (rather late) stage, the need has been declared, > > > > explained (which is always good!) and proposed as part of > > > > the standard (moving the architecture document int the > > > > Standards Track). > > > > > > > > 3. In order to minimize impact on some pre-standard > > > implementations > > > > that have either utilized the 1st nibble of the CW or used > > > RTP > > > > (or both), an optional opaque 32-bit word has between the PW > > > label > > > > (at the bottom of the label stack) and a the CW/RTP header > > > has been > > > > proposed as the simplest way out. The only requirement for > > > this > > > > block of data has been to keep its 1st nibble zeroed. > > > > > > > > 4. After that, this patch has been somehow "promoted" to the > > > title > > > > and associated status of of "MPLS PID". And this promotion > > > has > > > > triggered a long discussion of its possible uses far beyond > > > the > > > > original patchy fuctionality. > > > > > > > > 5. The proposals mentioned in is discussion are, IMO, paramount > > > > to an alternative PWE3 architecture (including allocation > > > > of a PWE3 protocol number in IP header etc.). They also > > > include > > > > amendments to Y.1711 which is presumably out of scope of PWE3 > > > > > > > (and IETF in general) etc. > > > > And somehow the fact that existing LSRs carry IP traffic over > > > > > > > LSPs without any MPLS PID and will hardly be ever retrofitted > > > > > > > has been happily ignored by some of the participants. > > > > > > > > IMHO the best way out of the confusion would be to demote > > "MPLS PID" > > > > to what it really is - a patch solving the ECMP problem for the > > > > following three cases (and just for these > > > cases): > > > > > > > > o PW encapsulations that do not mandate a CW, so that > > > payload > > > > immediately > > > > follows the PW label. In other words, make SOME CW > > > mandatory. > > > > o PW encapsulations that mandate a CW but utilize its 1st > > > nibble. > > > > They would prepend an opaque 32-bit word with the > > zeroed 1st > > > > nibble > > > > by default, reserving an option to drop it if ECMP > > is not used > > > > in > > > > the core network. > > > > o PW encapsulations that use RTP. They may follow the > > > > same rules as in > > > > the previous case, or may use weaker rules because > > the first > > > > nibble > > > > of an RTP header distinguishes it from IPv4/IPv6 > > headers and > > > > this > > > > is probably sufficient for ECMP. > > > > > > > > I think that building theories/architectures on patches is > > > > counter-productive. > > > > > > > > With best regards, > > > > Sasha Vainshtein > > > > email: sasha@axerra.com > > > > tel: +972-3-7659993 (office) > > > > +972-8-9254948 (res.) > > > > +972-58-674833 (cell.) > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 08 May 2003 12:13:30 -0400 Organization: Alcatel Networks Corporaton Lines: 35 Sender: pwe3-admin@ietf.org References: <8FA6CEF9A4E42B48A5F8DC038655B353010457A4@mxtlv1.corrigent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 18:16:50 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: David Zelig Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O David, David Zelig wrote: > > > > > No you don't need VCCV. In fact segment OAM gives you a > > much closer test to the desposition point than VCCV. The reason is > > simple. The layering is : PSN-PW-ATM. I proposed testing PSN > > and ATM, but you proposed testing PW. Which one goes higher in > > the protocol stack? Off course segment OAM goes higher than > > PW OAM, because ATM is higher in the stack that PW. > > > > > > Shahram, > two major points are not solved with the suggestion to use segment OAM of > the native signal: > 1) What happened if the customer is using the segmented OAM over a span that > include the PW? Since a PW always terminates on a L2 endpoint, your native segment OAM flow will terminate on that same endpoint. Thus a segment that spans a PW works the same way as any native service segement. > 2) A unified approach, applicable to all carried signal types, has > operational benefits for the operators who wish to use PW for carrying of > more than one signal type. I am being realistic about what can be done to progress the work in PWE3. The current scope of this working group is to work on endpoints of the same type. Therefore, one wants to reuse as much as possible the existing mechanisms. In phase 2, I agree that such a mechanism is required. > David From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 09:17:03 -0700 Lines: 65 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 18:22:14 2003 Return-path: To: "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >> Same thing, use IP-ping (like LSP-ping) for the IP >> connectivity test and then use segment OAM for the carried service. > > If segment-OAM means VCCV then I agree. If it >doesn't that I don't agree. Segment OAM is not VCCV. In fact it is superior to VCCV because it goes much further to the disposition point than VCCV. >There are load-share cares >where if you ping the L2TPv3 control channel you might >not take the same data plane path as the data. The >forthcoming version of VCCV will include an option >to send information for L2TPv3. I am not expert on L2TPV3, but if the management packets don't follow the data-plane, then that is L2TPs problem not PWE3. > What do you do in the VPLS case? The >segment OAM in that case goes completely end-to-end. >How do you know which segment is broken in that case? I assume you mean tandem VPLS. There are 2 cases: 1) If you only switch based on PW label (as Eric Rosen has suggested in another email thread) then to test each VPLS network you can use your normal MPLS OAM (LSP-ping or anything else). 2) If you actually terminate the PW label and start another PW then the segment OAMs will also be terminated and another one generated. So you can test all VPLS networks using their own separate segment OAM. > I propose using native OAM to go from end-to-end, >if that fails, use VCCV for the PW and perhaps LSP ping/trace >for the PSN. Since the end-to-end OAM belongs to customer, unfortunately the problem in that case is that it would be the customer who first discovers the problems and calls you to correct it. The delay in correcting the problem would be in the order of hours. >> The PSN OAM method that you use is irrelevant to this >> discussion. So please don't bring that as a justification for VCCV. > > It is indeed germain to this discussion for the >reasons I have given. I am sorry but if it is I don't get it. We are talking about PW testing, what has it got to do with how PSN is tested? > Indeed more providers' operational departments need >to speak on this issue. > > --Tom -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 09:24:59 -0700 Lines: 28 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 18:29:17 2003 Return-path: To: "'David Zelig'" , "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O David, > >Shahram, >two major points are not solved with the suggestion to use >segment OAM of >the native signal: >1) What happened if the customer is using the segmented OAM >over a span that >include the PW? You have a point, but I am not sure why customer wants to run segment OAM, rather than end-to-end OAM. >2) A unified approach, applicable to all carried signal types, has >operational benefits for the operators who wish to use PW for >carrying of >more than one signal type. Are you saying that operators prefer introducing a new protocol management layer with a new management protocol, rather than using the native OAM that is available for carried services? I think service providers need to speak on that. > >David > -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 12:27:57 -0400 Organization: Cisco Systems, Inc. Lines: 312 Sender: pwe3-admin@ietf.org References: <3EBA7E41.29A72E23@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Thu May 08 18:34:00 2003 Return-path: To: "'Mustapha Aissaoui'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3EBA7E41.29A72E23@alcatel.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Thursday, May 08, 2003 11:57 AM > To: tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Tom, > > "Thomas D. Nadeau" wrote: > > > > > -----Original Message----- > > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of > > > Mustapha Aissaoui > > > Sent: Wednesday, May 07, 2003 6:42 PM > > > To: David Allan > > > Cc: 'Sasha Vainshtein'; 'Shahram Davari'; 'George Swallow'; Danny > > > McPherson; pwe3@ietf.org > > > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > Dave and all, > > > I agree with your assessment. Given that we want to progress the > > > PWE3 work, I propose to address the issues raised in 2 phases: > > > > > > Phase 1: > > > the current scope of the PWE3 working group is to provide > for a PW > > > between two endpoints of the same type (e.g., > FR-MPLS-FR). In this > > > environment, the native service OAM and link management > achieves all > > > what is needed and we do not need to define a specific PW OAM. At > > > the PSN level, > > > > I suggest that you read the MPLS OAM > > requirements in draft-ietf-mpls-oam-requirements-00.txt, > > as well as the justifications for VCCV in > > draft-nadeau-pwe3-vccv-00.txt and then tell the 25 or so service > > providers that were polled for these requirements about how it is so > > clear that there is no need to have such a mechanism. > > I am really not saying anything different from what service > providers are saying. I am just stating that in the case of > endpoints of the same type we can troubleshoot the PSN using > PSN specific OAM (out of scope of PWE3) and the PW using the > native service OAM. Of course, one needs to correlate a > defect indication from the PSN level to the native service > level, but this is a local PE matter. I might have misinterpreted what you said earlier. It appears that we agree on the point that endpoint-OAM should be used to trouble-shoot/CV the service. What it looks like we don't agree on is whether VCCV is considered the PSN-specific OAM piece. Let me suggest that you look at it this way, consder VCCV to be part of the PSN-specific OAM. > > > OAM can > > > be achieved using either IP tools such as LSP-Ping, or > Y.1711 tools. > > > Any OAM specific issues with the PSN are clearly outside > the scope > > > of the PWE3. > > > > Use of just LSP-ping for PWs is not going to cut > > the mustard for two reasons, which I will explain > > below. I believe that LSP ping/ICMP ping/native OAM > > and VCCV need to be used in conjunction to satisfy > > the requirements specified in the OAM requirements. > > > > 1) Use of VCCV allows you to get as close to the > > disposition point as possible; LSP > > or ICMP ping doesn't necessarily do > > this in all cases. > > > > 2) VCCV is a generic CV mechanism for IETF defined > > PWs regardless of the underlying PSN technology > > that allows CV traffic to flow on EXACTLY the > > same path as the data plane. > > > > This is important because tools designed to > > test/debug/verify PWs can be written more > > generally. This is also important because > > there are cases where using regular ICMP-ping > > will not follow the same data plane path over > > the IP tunnel. > > Again, you are saying the same thing as I said. The only > difference is that you believe that the PW level OAM requires > a new mechanism while I am challenging you that it not > required in the case of endpoints of the same type. I am suggesting that the use of VCCV obviates the need to consider either case because it works for both, as well as VPLS. > > Also, pitching Y.1711 as a possible alternative is > > irresponsible. It is badly broken for LDP-based networks > and has been > > shown to be quite difficult to implement besides, so lets not go > > there. Of course, its proponents are working feverishly to > patch it up > > within the ITU so that they can ask service providers to replace all > > of their hardware (again) to support the ultimate OAM > > swiss army knife. I assert that it is certainly > > not ready and should not be considered as an acceptable > > approach. > > I am not pitching anything here. I think you are overreacting :-) Maybe. I have been known to in the past. *) --Tom > > > The only requirement is to > > > address the IP aliasing issue. The most straighforward way to > > > resolve it is to make sure that all CWs have the nibble following > > > immediately the bottom label set to a value different of > 4, 6, or 8 > > > (zero seems to be the accepted value). This means that the SONET > > > encapsulation would have to go with Option 3 in Andy's three > > > proposals. > > > > > > Phase 2: > > > the work of the PWE3 may expand to support endpoints of different > > > types (e.g., FR-MPLS-Ethernet). In this scenario, if the native > > > service is terminated locally at each PE, then clearly there is a > > > need for the following: a. the ability to define a PW > specific OAM > > > and link management functions and inteoperate it with the native > > > service OAM and link management. b. the ability to > self-identify the > > > protocol carried in a single PW. > > > > > A PW can carry both user packets and > > > OAM packets and we want them to share the same path in > the presence > > > of ECMP. > > > > Again, read the OAM requirements referenced above. > OAM traffic > > MUST be carried on the same data path regardless of whether ECMP is > > active or not. Are you suggesting that we should ignore > that 25 SPs > > have told us? > > Tom, please read carefully before you reply. You just wrote > exactly what I wrote. The good news is that we are in > agreement here at least. > > > > > --Tom > > > > > A PW can also carry both a end-user bridged > > > and a routed PDU (multiprotocol PW). This is where the > MPLS/PW PID > > > is useful but it should be addressed in a much wider > scope than the > > > current PWE3 issues. > > > > > > Let me know what you think. > > > Mustapha. > > > ------------ > > > > David Allan wrote: > > > > > > > > We do have two separate problems.... > > > > > > > > 1) Is a means of identifying a generic payload. This would > > > appear to > > > > potentially require additional services such as sequencing > > > etc. stuff > > > > already dealt with in the exissting PWE control words. > This would > > > > include ordering, and if this was preserved in the presence of > > > > proprietary ECMP so much the better. > > > > > > > > 2) A means of instrumenting PWs such that packets fate > > > shares with PW > > > > forwarding. Tom has proposed VCCV which needs an available > > > bit in the > > > > CW and control handshaking to agree on what the bit means. > > > The PPP DLL > > > > approach (Georges proposal) or my proposal permits the > > > instrumenting > > > > protocol to self identify and therefore IMHO is preferable. > > > > > > > > But I am skeptical that simply having a protocol identifier > > > means a PW > > > > can carry anything. Its not designed with the requisite > > > attributes for > > > > service bearing. If we want "carry anything" with ordering > > > > fragmentation etc. we have more to do. > > > > > > > > my 2 cents > > > > Dave > > > > > > > > > -----Original Message----- > > > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > > > > Sent: Tuesday, May 06, 2003 4:00 AM > > > > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > > > > Cc: pwe3@ietf.org > > > > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > I believe that George's comment has been very much in place. > > > > > > > > > > The "MPLS PID" story looks to me like following: > > > > > > > > > > 1. There was a recognized but, for some reasons, > undeclared need > > > > > > > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > > > > complied with this, and some did not; some others simply > > > > > declared that the CW is optional. > > > > > > > > > > 2. At some (rather late) stage, the need has been declared, > > > > > explained (which is always good!) and proposed as part of > > > > > the standard (moving the architecture document int the > > > > > Standards Track). > > > > > > > > > > 3. In order to minimize impact on some pre-standard > > > > implementations > > > > > that have either utilized the 1st nibble of the CW or used > > > > RTP > > > > > (or both), an optional opaque 32-bit word has > between the PW > > > > label > > > > > (at the bottom of the label stack) and a the CW/RTP header > > > > has been > > > > > proposed as the simplest way out. The only requirement for > > > > this > > > > > block of data has been to keep its 1st nibble zeroed. > > > > > > > > > > 4. After that, this patch has been somehow "promoted" to the > > > > title > > > > > and associated status of of "MPLS PID". And this promotion > > > > has > > > > > triggered a long discussion of its possible uses far beyond > > > > the > > > > > original patchy fuctionality. > > > > > > > > > > 5. The proposals mentioned in is discussion are, IMO, > paramount > > > > > to an alternative PWE3 architecture (including allocation > > > > > of a PWE3 protocol number in IP header etc.). They also > > > > include > > > > > amendments to Y.1711 which is presumably out of > scope of PWE3 > > > > > > > > > (and IETF in general) etc. > > > > > And somehow the fact that existing LSRs carry IP > traffic over > > > > > > > > > LSPs without any MPLS PID and will hardly be ever > retrofitted > > > > > > > > > has been happily ignored by some of the participants. > > > > > > > > > > IMHO the best way out of the confusion would be to demote > > > "MPLS PID" > > > > > to what it really is - a patch solving the ECMP > problem for the > > > > > following three cases (and just for these > > > > cases): > > > > > > > > > > o PW encapsulations that do not mandate a CW, so that > > > > payload > > > > > immediately > > > > > follows the PW label. In other words, make SOME CW > > > > mandatory. > > > > > o PW encapsulations that mandate a CW but utilize its 1st > > > > nibble. > > > > > They would prepend an opaque 32-bit word with the > > > zeroed 1st > > > > > nibble > > > > > by default, reserving an option to drop it if ECMP > > > is not used > > > > > in > > > > > the core network. > > > > > o PW encapsulations that use RTP. They may follow the > > > > > same rules as in > > > > > the previous case, or may use weaker rules because > > > the first > > > > > nibble > > > > > of an RTP header distinguishes it from IPv4/IPv6 > > > headers and > > > > > this > > > > > is probably sufficient for ECMP. > > > > > > > > > > I think that building theories/architectures on patches is > > > > > counter-productive. > > > > > > > > > > With best regards, > > > > > Sasha Vainshtein > > > > > email: sasha@axerra.com > > > > > tel: +972-3-7659993 (office) > > > > > +972-8-9254948 (res.) > > > > > +972-58-674833 (cell.) > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 12:32:58 -0400 Organization: Cisco Systems, Inc. Lines: 59 Sender: pwe3-admin@ietf.org References: <3EBA822A.AB9B89DC@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Thu May 08 18:45:05 2003 Return-path: To: "'Mustapha Aissaoui'" , "'David Zelig'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3EBA822A.AB9B89DC@alcatel.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mustapha Aissaoui > Sent: Thursday, May 08, 2003 12:14 PM > To: David Zelig > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > David, > > David Zelig wrote: > > > > > > > > No you don't need VCCV. In fact segment OAM gives you a > much closer > > > test to the desposition point than VCCV. The reason is > simple. The > > > layering is : PSN-PW-ATM. I proposed testing PSN and ATM, but you > > > proposed testing PW. Which one goes higher in the protocol stack? > > > Off course segment OAM goes higher than PW OAM, because ATM is > > > higher in the stack that PW. > > > > > > > > > > Shahram, > > two major points are not solved with the suggestion to use > segment OAM > > of the native signal: > > 1) What happened if the customer is using the segmented OAM over a > > span that include the PW? > > Since a PW always terminates on a L2 endpoint, your native > segment OAM flow will terminate on that same endpoint. Thus a > segment that spans a PW works the same way as any native > service segement. > > > 2) A unified approach, applicable to all carried signal types, has > > operational benefits for the operators who wish to use PW > for carrying > > of more than one signal type. > > I am being realistic about what can be done to progress the > work in PWE3. The current scope of this working group is to > work on endpoints of the same type. Therefore, one wants to > reuse as much as possible the existing mechanisms. In phase > 2, I agree that such a mechanism is required. Assuming that we are in agreement for the any-to-any case, why not define a generic mechanism that works for both any-to-any and like-to-like? If you don't, then the operator/operational software has to figure out which combination is in use, and then choose which mechanism to test rather than just mechanically trying the native service OAM, and then running VCCV? --Tom From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 08 May 2003 12:43:22 -0400 Organization: Alcatel Networks Corporaton Lines: 53 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C935@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'David Zelig'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 18:48:59 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Shahram Davari Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram and David, Shahram Davari wrote: > > David, > > > > >Shahram, > >two major points are not solved with the suggestion to use > >segment OAM of > >the native signal: > >1) What happened if the customer is using the segmented OAM > >over a span that > >include the PW? > > You have a point, but I am not sure why customer wants to run > segment OAM, rather than end-to-end OAM. We need to spearate customer testing from service provider testing. Assume that we have a simple 3-hop network scenario (CE-PE-PE-CE). Assume also we have a ATM-MPLS-ATM PW running over this network. The customer can test his/her connectivity using an end-to-end OAM flow. The service provider will pass these cells unaffected provided that: a. There was an agreement allowing the customer to inject OAM cells. b. The aggregate traffic on that connection des not violate the traffic contract when policing user traffic in the PE. The service provider can run a segment OAM flow between the ATM endpoints of the PW. These points are under his managment. Both the customer OAM testing and the service provider OAM testing can operate concurrently. > > >2) A unified approach, applicable to all carried signal types, has > >operational benefits for the operators who wish to use PW for > >carrying of > >more than one signal type. > > Are you saying that operators prefer introducing a new protocol management layer > with a new management protocol, rather than using the native OAM that is > available for carried services? I think service providers need to speak on that. > > > > >David > > > > -Shahram > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Rahul Aggarwal Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 10:36:10 -0700 (PDT) Lines: 44 Sender: pwe3-admin@ietf.org References: <3EBA7592.38B153B0@alcatel.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 19:39:25 2003 Return-path: X-Sender: rahul@u43 To: Mustapha Aissaoui In-Reply-To: <3EBA7592.38B153B0@alcatel.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha, On Thu, 8 May 2003, Mustapha Aissaoui wrote: > Rahul, > > Rahul Aggarwal wrote: > > > > Mustapha, > > > > [clipped] > > > > > PWE3 work, I propose to address the issues raised in 2 phases: > > > > > > Phase 1: > > > the current scope of the PWE3 working group is to provide for a PW > > > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > > > environment, the native service OAM and link management achieves all > > > what is needed and we do not need to define a specific PW OAM. At > > > > In this environment there is still a need for a PW OAM. Please see section > > 3 of: > > > > draft-nadeau-pwe3-vccv-00.txt > > There is nothing in Section 3 which justifies the need for a PW OAM > in the case of endpoints of the same type. You may want to double > check it. Its a matter of interpretation. VCCV provides a mechanism to validate the PW forwarding path on the egress PE i.e. the MPLS Label FIB->PW mapping. Even if endpoints are of the same type there may be a need to validate the egress PW forwarding path. Regards, rahul > > > > > Regards, > > rahul > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 14:02:22 -0400 Lines: 180 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'Shahram Davari'" , "'George Swallow'" , Danny McPherson , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 20:05:02 2003 Return-path: To: "'Mustapha Aissaoui'" , David Allan X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, May 07, 2003 6:42 PM > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Dave and all, > I agree with your assessment. Given that we want to progress the > PWE3 work, I propose to address the issues raised in 2 phases: > > Phase 1: > the current scope of the PWE3 working group is to provide for a PW > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > environment, the native service OAM and link management achieves all > what is needed and we do not need to define a specific PW OAM. At > the PSN level, OAM can be achieved using either IP tools such as > LSP-Ping, or Y.1711 tools. Any OAM specific issues with the PSN are > clearly outside the scope of the PWE3. > The only requirement is to address the IP aliasing issue. The most > straighforward way to resolve it is to make sure that all CWs have > the nibble following immediately the bottom label set to a value > different of 4, 6, or 8 (zero seems to be the accepted value). This > means that the SONET encapsulation would have to go with Option 3 in > Andy's three proposals. > > Phase 2: > the work of the PWE3 may expand to support endpoints of different > types (e.g., FR-MPLS-Ethernet). In this scenario, if the native > service is terminated locally at each PE, then clearly there is a > need for the following: > a. the ability to define a PW specific OAM and link management > functions and inteoperate it with the native service OAM and link > management. > b. the ability to self-identify the protocol carried in a single PW. > A PW can carry both user packets and OAM packets and we want them to > share the same path in the presence of ECMP. A PW can also carry > both a end-user bridged and a routed PDU (multiprotocol PW). This is > where the MPLS/PW PID is useful but it should be addressed in a much > wider scope than the current PWE3 issues. Mustapha, I don't think I agree with your rationale. In case of service interworking, e.g. Frame Relay to Ethernet, there is one point in the network where the two protocols meet. Let's call that point A. Further assume that CE1 is the Frame Relay endpoint and CE2 is the Ethernet endpoint. On the link between CE1 and A, Frame Relay OAM applies. On the link between A and CE2 ethernet OAM applies. Now assume that A coincides with a PE, say PE2. In that case, one segment of the link between CE1 and A is carried over a PW. I would argue that from a PW perspective this is an encapsulation of Frame Relay, nothing more, nothing less. Therefore: a)Frame Relay OAM can be used to validate the sanity of the PW segment b)There is no need to self-identify the protocol. As is the case for all PWs, the protocol carried over it is identified during PW set up. By the way, I agree with your observations on phase 1. Peter > > Let me know what you think. > Mustapha. > ------------ > > David Allan wrote: > > > > We do have two separate problems.... > > > > 1) Is a means of identifying a generic payload. This would appear > > to potentially require additional services such as sequencing etc. > > stuff already dealt with in the exissting PWE control words. This > > would include ordering, and if this was preserved in the presence > > of proprietary ECMP so much the better. > > > > 2) A means of instrumenting PWs such that packets fate shares > > with PW forwarding. Tom has proposed VCCV which needs an > > available bit in the CW and control handshaking to agree on what > > the bit means. The PPP DLL approach (Georges proposal) or my > > proposal permits the instrumenting protocol to self identify and > > therefore IMHO is preferable. > > > > But I am skeptical that simply having a protocol identifier means > > a PW can carry anything. Its not designed with the requisite > > attributes for service bearing. If we want "carry anything" with > > ordering fragmentation etc. we have more to do. > > > > my 2 cents > > Dave > > > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > > Sent: Tuesday, May 06, 2003 4:00 AM > > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > Hi all, > > > > > > I believe that George's comment has been very much in place. > > > > > > The "MPLS PID" story looks to me like following: > > > > > > 1. There was a recognized but, for some reasons, undeclared need > > > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > > complied with this, and some did not; some others simply > > > declared that the CW is optional. > > > > > > 2. At some (rather late) stage, the need has been declared, > > > explained (which is always good!) and proposed as part of > > > the standard (moving the architecture document int the > > > Standards Track). > > > > > > 3. In order to minimize impact on some pre-standard > > implementations > > > that have either utilized the 1st nibble of the CW or used > > RTP > > > (or both), an optional opaque 32-bit word has between the PW > > label > > > (at the bottom of the label stack) and a the CW/RTP header > > has been > > > proposed as the simplest way out. The only requirement for > > this > > > block of data has been to keep its 1st nibble zeroed. > > > > > > 4. After that, this patch has been somehow "promoted" to the > > title > > > and associated status of of "MPLS PID". And this promotion > > has > > > triggered a long discussion of its possible uses far beyond > > the > > > original patchy fuctionality. > > > > > > 5. The proposals mentioned in is discussion are, IMO, paramount > > > to an alternative PWE3 architecture (including allocation > > > of a PWE3 protocol number in IP header etc.). They also > > include > > > amendments to Y.1711 which is presumably out of scope of PWE3 > > > > > (and IETF in general) etc. > > > And somehow the fact that existing LSRs carry IP traffic over > > > > > LSPs without any MPLS PID and will hardly be ever retrofitted > > > > > has been happily ignored by some of the participants. > > > > > > IMHO the best way out of the confusion would be to demote > > > "MPLS PID" to what it really is - a patch solving the ECMP > > > problem for the following three cases (and just for these > > cases): > > > > > > o PW encapsulations that do not mandate a CW, so that > > payload > > > immediately > > > follows the PW label. In other words, make SOME CW > > mandatory. > > > o PW encapsulations that mandate a CW but utilize its 1st > > nibble. > > > They would prepend an opaque 32-bit word with the > > > zeroed 1st nibble > > > by default, reserving an option to drop it if ECMP is > > > not used in > > > the core network. > > > o PW encapsulations that use RTP. They may follow the > > > same rules as in > > > the previous case, or may use weaker rules because the > > > first nibble > > > of an RTP header distinguishes it from IPv4/IPv6 > > > headers and this > > > is probably sufficient for ECMP. > > > > > > I think that building theories/architectures on patches is > > > counter-productive. > > > > > > With best regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > tel: +972-3-7659993 (office) > > > +972-8-9254948 (res.) > > > +972-58-674833 (cell.) > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 08 May 2003 14:17:51 -0400 Organization: Alcatel Networks Corporaton Lines: 281 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6809@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 20:23:36 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: neil.2.harrison@bt.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, see some comments inline. Regards, Mustapha. ----------- neil.2.harrison@bt.com wrote: > > Mustapha, > > Please see in-line. regards, Neil > > Mustapha Aissaoui wrote 07 May 2003 23:42 > > Phase 1: > > the current scope of the PWE3 working group is to provide for a PW > > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > > environment, the native service OAM and link management achieves all > > what is needed and we do not need to define a specific PW OAM. > NH=> Absolutely correct.....when I want to interwork ATM/MPLS say there is > not need whatsover for PW OAM, but further there is no need for PWs at all! You raise an important question which I believe deserves much attention. Is a PW layer a regular MPLS layer or not. The currently defined mechanism for encpasulation and signaling are vague about that. The only thing I can think does not encourage removing this ambiguity is the fact that a PW does not exist in its own. It is always inside a tunnel of some sort and is a single hop as far as the tunneling network is concerned. > > > At > > the PSN level, OAM can be achieved using either IP tools such as > > LSP-Ping, or Y.1711 tools. Any OAM specific issues with the PSN are > > clearly outside the scope of the PWE3. > > The only requirement is to address the IP aliasing issue. The most > > straighforward way to resolve it is to make sure that all CWs have > > the nibble following immediately the bottom label set to a value > > different of 4, 6, or 8 (zero seems to be the accepted value). This > > means that the SONET encapsulation would have to go with Option 3 in > > Andy's three proposals. > > > > > Phase 2: > > the work of the PWE3 may expand to support endpoints of different > > types (e.g., FR-MPLS-Ethernet). > NH=> I suggest some caution here. It is perfectly valid (and required) to > have service-interworking between technologies that belong to the *same* > network mode. It is not so valid to have service-interworking between > technologies that don't belong to the same mode......here only client/server > relationships make sense, and even then only certain ones between the 3 > modes. One can of course ignore this, and no doubt this is going to > happen.......but I advise caution. > > > In this scenario, if the native > > service is terminated locally at each PE, then clearly there is a > > need for the following: > > a. the ability to define a PW specific OAM and link management > > functions and inteoperate it with the native service OAM and link > > management. > NH=> Why? The scenario described (ie service-interworking) requires that > the trails of each technology terminate at the IWF....if one drew out the > G.805 diagrams this would be clear. This means their native OAM functions > (if any) also terminate at the IWF. One therefore requires some > higher/common 'networking entity' to be carried end-end across the > concatenated server technologies. However, I don't see any difference > between ATM/MPLS service interworking and ATM/MPLS/FR service interworking > and ATM/MPLS/ethernet service interworking (other than the validity of > having mode mismatch, and the functional specification differences of each > of the technologies in question). Apart from the important question of whether a PW layer is a MPLS layer, the rest is not different from FR-ATM service interworking (FRF.8.1). In the latter case, you can carry a bridged or routed PDU across these 2 L2 networks. In fact you can carry a mix of protocols over the same VC. > > b. the ability to self-identify the protocol carried in a single PW. > > A PW can carry both user packets > NH=> of which layer network? I am talking about protocols used by the end-user equipment. The CPE may be routing IP, IPX, or any network layer protocol over a ATM VC. It could also bridge Ethernet, FDDI, or any other bridged media protocol over a ATM VC. > > and OAM packets > NH=> of which layer network? I am referring to segment OAM messages originating and terminating in the PW endpoints (or inner LSP endpoints). > > and we want them to > > share the same path in the presence of ECMP. A PW can also carry > > both a end-user bridged and a routed PDU (multiprotocol PW). > NH=> Whoa! You have just changed the service-interworking case into a > (partial) client/server case....in the former the etherent component is > simply a server layer access partition (terminates at the IWF) but now you > are describing the case where the ethernet pkts have to be carried across > all intervening networks....so, for example, it could be that ethernet is > client to both MPLS and ATM partitions say, but the MPLS and ATM partitions > are using service interworking. As I noted previously, if you draw out the > G.805 relationships this would be much clearer. I do not understand your point here. If I want to carry a higher layer protocol PDU over a Ethernet-(PE1)-MPLS-(PE2)-ATM network, I can do it in three different ways: a. Extend Ethernet over MPLS (network interworking) to the PE2 and then perform Ethernet-ATM service interworking there. b. Extend ATM over MPLS (network interworking) to PE1 and then perform Ethernet-ATM service interowrking there. c. Terminate ATM and Ethernet locally at each PE and perform 2 service interworking functions, one at PE1 (Ethernet-MPLS), the other at PE2 (ATM-MPLS). It is clear to me that in (a) and (b), OAM messages of either the Ethernet layer or the ATM layer need to be carried in the inner LSP. It is not the case in (c), since both ATM and Ethernet are terminated. Are we saying the same thing? > > This is > > where the MPLS/PW PID is useful but it should be addressed in a much > > wider scope than the current PWE3 issues. > NH=> Please note this observation: A PID field is only required to identify > the *clients* of a given layer network when these can change over the life > of the (server) layer trail. In G.805 terms this is describing a > multiplexing function that is related to the adaptation of the client signal > into the payload of the server signal. Each layer network however, should > have its own native OAM that is *independent* of any higher client layer. > That is, the PID field and the layer network's native OAM are *not* in any > way related (and the PID function sits above the OAM > functionally).....putting this is very plain terms, the *client* PID field > should not be used to identify OAM pkts. I agree with you on this point. The PID is in principle an identifier of the higher layer protocol, not of the OAM messages of the layer below it. > Finally, if MPLS is properly specified there is no need for any of this > artifical PW stuff....we simply need to interwork MPLS and the other > technologies natively. The PW stuff only 'lives' because: > - of LDP and the issues/hacks of ECMP.....load-splitting only makes > arch sense in a *single* layer network. > - MPLS is 'allowed' to re-order pkts > - someone thinks squeezing a bit of BW (wrt certain client layers) is > useful > - the erroneous belief that X/IP is somehow the same as X/MPLS > > An unneccessary networking layer (the PW) has thus been created, that is now > starting to take on a life of its own as an 'in-between' layer network, when > there is no need for it....esp when we have to manage the MPLS network > anyway (so do it once, and do it right). Thanks, just something else to > manage ;-) On a serious note however, I hope/pray there are some suppliers > out there that can understand what I am saying here and will provide > solutions without these unnecessary problems. I don't think its that hard > (technically at least). > > > > Let me know what you think. > > Mustapha. > > ------------ > > > David Allan wrote: > > > > > > We do have two separate problems.... > > > > > > 1) Is a means of identifying a generic payload. This would appear > > > to potentially require additional services such as sequencing etc. > > > stuff already dealt with in the exissting PWE control words. This > > > would include ordering, and if this was preserved in the presence > > > of proprietary ECMP so much the better. > > > > > > 2) A means of instrumenting PWs such that packets fate shares > > > with PW forwarding. Tom has proposed VCCV which needs an > > > available bit in the CW and control handshaking to agree on what > > > the bit means. The PPP DLL approach (Georges proposal) or my > > > proposal permits the instrumenting protocol to self identify and > > > therefore IMHO is preferable. > > > > > > But I am skeptical that simply having a protocol identifier means > > > a PW can carry anything. Its not designed with the requisite > > > attributes for service bearing. If we want "carry anything" with > > > ordering fragmentation etc. we have more to do. > > > > > > my 2 cents > > > Dave > > > > > > > -----Original Message----- > > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > > > Sent: Tuesday, May 06, 2003 4:00 AM > > > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > > > Cc: pwe3@ietf.org > > > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > > > > Hi all, > > > > > > > > I believe that George's comment has been very much in place. > > > > > > > > The "MPLS PID" story looks to me like following: > > > > > > > > 1. There was a recognized but, for some reasons, undeclared need > > > > > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > > > complied with this, and some did not; some others simply > > > > declared that the CW is optional. > > > > > > > > 2. At some (rather late) stage, the need has been declared, > > > > explained (which is always good!) and proposed as part of > > > > the standard (moving the architecture document int the > > > > Standards Track). > > > > > > > > 3. In order to minimize impact on some pre-standard > > > implementations > > > > that have either utilized the 1st nibble of the CW or used > > > RTP > > > > (or both), an optional opaque 32-bit word has between the PW > > > label > > > > (at the bottom of the label stack) and a the CW/RTP header > > > has been > > > > proposed as the simplest way out. The only requirement for > > > this > > > > block of data has been to keep its 1st nibble zeroed. > > > > > > > > 4. After that, this patch has been somehow "promoted" to the > > > title > > > > and associated status of of "MPLS PID". And this promotion > > > has > > > > triggered a long discussion of its possible uses far beyond > > > the > > > > original patchy fuctionality. > > > > > > > > 5. The proposals mentioned in is discussion are, IMO, paramount > > > > to an alternative PWE3 architecture (including allocation > > > > of a PWE3 protocol number in IP header etc.). They also > > > include > > > > amendments to Y.1711 which is presumably out of scope of PWE3 > > > > > > > (and IETF in general) etc. > > > > And somehow the fact that existing LSRs carry IP traffic over > > > > > > > LSPs without any MPLS PID and will hardly be ever retrofitted > > > > > > > has been happily ignored by some of the participants. > > > > > > > > IMHO the best way out of the confusion would be to demote > > > > "MPLS PID" to what it really is - a patch solving the ECMP > > > > problem for the following three cases (and just for these > > > cases): > > > > > > > > o PW encapsulations that do not mandate a CW, so that > > > payload > > > > immediately > > > > follows the PW label. In other words, make SOME CW > > > mandatory. > > > > o PW encapsulations that mandate a CW but utilize its 1st > > > nibble. > > > > They would prepend an opaque 32-bit word with the > > > > zeroed 1st nibble > > > > by default, reserving an option to drop it if ECMP is > > > > not used in > > > > the core network. > > > > o PW encapsulations that use RTP. They may follow the > > > > same rules as in > > > > the previous case, or may use weaker rules because the > > > > first nibble > > > > of an RTP header distinguishes it from IPv4/IPv6 > > > > headers and this > > > > is probably sufficient for ECMP. > > > > > > > > I think that building theories/architectures on patches is > > > > counter-productive. > > > > > > > > With best regards, > > > > Sasha Vainshtein > > > > email: sasha@axerra.com > > > > tel: +972-3-7659993 (office) > > > > +972-8-9254948 (res.) > > > > +972-58-674833 (cell.) > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 08 May 2003 14:31:52 -0400 Organization: Alcatel Networks Corporaton Lines: 199 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 20:34:07 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, thanks for the comments. See more below. Mustapha. ---------- "Busschbach, Peter B (Peter)" wrote: > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Wednesday, May 07, 2003 6:42 PM > > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > Dave and all, > > I agree with your assessment. Given that we want to progress the > > PWE3 work, I propose to address the issues raised in 2 phases: > > > > Phase 1: > > the current scope of the PWE3 working group is to provide for a PW > > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > > environment, the native service OAM and link management achieves all > > what is needed and we do not need to define a specific PW OAM. At > > the PSN level, OAM can be achieved using either IP tools such as > > LSP-Ping, or Y.1711 tools. Any OAM specific issues with the PSN are > > clearly outside the scope of the PWE3. > > The only requirement is to address the IP aliasing issue. The most > > straighforward way to resolve it is to make sure that all CWs have > > the nibble following immediately the bottom label set to a value > > different of 4, 6, or 8 (zero seems to be the accepted value). This > > means that the SONET encapsulation would have to go with Option 3 in > > Andy's three proposals. > > > > Phase 2: > > the work of the PWE3 may expand to support endpoints of different > > types (e.g., FR-MPLS-Ethernet). In this scenario, if the native > > service is terminated locally at each PE, then clearly there is a > > need for the following: > > a. the ability to define a PW specific OAM and link management > > functions and inteoperate it with the native service OAM and link > > management. > > b. the ability to self-identify the protocol carried in a single PW. > > A PW can carry both user packets and OAM packets and we want them to > > share the same path in the presence of ECMP. A PW can also carry > > both a end-user bridged and a routed PDU (multiprotocol PW). This is > > where the MPLS/PW PID is useful but it should be addressed in a much > > wider scope than the current PWE3 issues. > > Mustapha, > > I don't think I agree with your rationale. In case of service >interworking, e.g. Frame Relay to Ethernet, there is one point in the >network where the two protocols meet. Let's call that point A. Further >assume that CE1 is the Frame Relay endpoint and CE2 is the Ethernet >endpoint. On the link between CE1 and A, Frame Relay OAM applies. On the >link between A and CE2 ethernet OAM applies. > Now assume that A coincides with a PE, say PE2. In that case, one >segment of the link between CE1 and A is carried over a PW. I would >argue that from a PW perspective this is an encapsulation of Frame >Relay, nothing more, nothing less. Therefore: > > a)Frame Relay OAM can be used to validate the sanity of the PW segment > > b)There is no need to self-identify the protocol. As is the case for all PWs, the protocol carried over it is identified during PW set up. I guess your observation is correct if one extends FR to the remote PE. In my response to Neil, I mentioned three ways of performing Ethernet-(PE1)-MPLS-(PE2)-FR: a. Extend Ethernet over MPLS (network interworking) to PE2 and then perform Ethernet-FR service interworking there. b. Extend FR over MPLS (network interworking) to PE1 and then perform Ethernet-ATM service interowrking there. c. Terminate Ethernet and FR locally at each PE and perform 2 service interworking functions, one at PE1 (Ethernet-MPLS), the other at PE2 (FR-MPLS). Your observation applies to (a) and (b). In (c), a new mechanism for OAM is required since both FR and Ethernet are terminated locally. > By the way, I agree with your observations on phase 1. > > Peter > > > > Let me know what you think. > > Mustapha. > > ------------ > > > David Allan wrote: > > > > > > We do have two separate problems.... > > > > > > 1) Is a means of identifying a generic payload. This would appear > > > to potentially require additional services such as sequencing etc. > > > stuff already dealt with in the exissting PWE control words. This > > > would include ordering, and if this was preserved in the presence > > > of proprietary ECMP so much the better. > > > > > > 2) A means of instrumenting PWs such that packets fate shares > > > with PW forwarding. Tom has proposed VCCV which needs an > > > available bit in the CW and control handshaking to agree on what > > > the bit means. The PPP DLL approach (Georges proposal) or my > > > proposal permits the instrumenting protocol to self identify and > > > therefore IMHO is preferable. > > > > > > But I am skeptical that simply having a protocol identifier means > > > a PW can carry anything. Its not designed with the requisite > > > attributes for service bearing. If we want "carry anything" with > > > ordering fragmentation etc. we have more to do. > > > > > > my 2 cents > > > Dave > > > > > > > -----Original Message----- > > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > > > Sent: Tuesday, May 06, 2003 4:00 AM > > > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > > > Cc: pwe3@ietf.org > > > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > > > > Hi all, > > > > > > > > I believe that George's comment has been very much in place. > > > > > > > > The "MPLS PID" story looks to me like following: > > > > > > > > 1. There was a recognized but, for some reasons, undeclared need > > > > > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > > > complied with this, and some did not; some others simply > > > > declared that the CW is optional. > > > > > > > > 2. At some (rather late) stage, the need has been declared, > > > > explained (which is always good!) and proposed as part of > > > > the standard (moving the architecture document int the > > > > Standards Track). > > > > > > > > 3. In order to minimize impact on some pre-standard > > > implementations > > > > that have either utilized the 1st nibble of the CW or used > > > RTP > > > > (or both), an optional opaque 32-bit word has between the PW > > > label > > > > (at the bottom of the label stack) and a the CW/RTP header > > > has been > > > > proposed as the simplest way out. The only requirement for > > > this > > > > block of data has been to keep its 1st nibble zeroed. > > > > > > > > 4. After that, this patch has been somehow "promoted" to the > > > title > > > > and associated status of of "MPLS PID". And this promotion > > > has > > > > triggered a long discussion of its possible uses far beyond > > > the > > > > original patchy fuctionality. > > > > > > > > 5. The proposals mentioned in is discussion are, IMO, paramount > > > > to an alternative PWE3 architecture (including allocation > > > > of a PWE3 protocol number in IP header etc.). They also > > > include > > > > amendments to Y.1711 which is presumably out of scope of PWE3 > > > > > > > (and IETF in general) etc. > > > > And somehow the fact that existing LSRs carry IP traffic over > > > > > > > LSPs without any MPLS PID and will hardly be ever retrofitted > > > > > > > has been happily ignored by some of the participants. > > > > > > > > IMHO the best way out of the confusion would be to demote > > > > "MPLS PID" to what it really is - a patch solving the ECMP > > > > problem for the following three cases (and just for these > > > cases): > > > > > > > > o PW encapsulations that do not mandate a CW, so that > > > payload > > > > immediately > > > > follows the PW label. In other words, make SOME CW > > > mandatory. > > > > o PW encapsulations that mandate a CW but utilize its 1st > > > nibble. > > > > They would prepend an opaque 32-bit word with the > > > > zeroed 1st nibble > > > > by default, reserving an option to drop it if ECMP is > > > > not used in > > > > the core network. > > > > o PW encapsulations that use RTP. They may follow the > > > > same rules as in > > > > the previous case, or may use weaker rules because the > > > > first nibble > > > > of an RTP header distinguishes it from IPv4/IPv6 > > > > headers and this > > > > is probably sufficient for ECMP. > > > > > > > > I think that building theories/architectures on patches is > > > > counter-productive. > > > > > > > > With best regards, > > > > Sasha Vainshtein > > > > email: sasha@axerra.com > > > > tel: +972-3-7659993 (office) > > > > +972-8-9254948 (res.) > > > > +972-58-674833 (cell.) > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 14:32:17 -0400 Organization: Cisco Systems, Inc. Lines: 365 Sender: pwe3-admin@ietf.org References: <3EBA9F4F.AD5357C3@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu May 08 20:37:09 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3EBA9F4F.AD5357C3@alcatel.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O One point below. > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mustapha Aissaoui > Sent: Thursday, May 08, 2003 2:18 PM > To: neil.2.harrison@bt.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Neil, > see some comments inline. > > Regards, > Mustapha. > ----------- > neil.2.harrison@bt.com wrote: > > > > Mustapha, > > > > Please see in-line. regards, Neil > > > > Mustapha Aissaoui wrote 07 May 2003 23:42 > > > Phase 1: > > > the current scope of the PWE3 working group is to provide > for a PW > > > between two endpoints of the same type (e.g., > FR-MPLS-FR). In this > > > environment, the native service OAM and link management > achieves all > > > what is needed and we do not need to define a specific PW OAM. > > NH=> Absolutely correct.....when I want to interwork ATM/MPLS say > > there is not need whatsover for PW OAM, but further there > is no need > > for PWs at all! > > You raise an important question which I believe deserves much > attention. Is a PW layer a regular MPLS layer or not. The > currently defined mechanism for encpasulation and signaling > are vague about that. The only thing I can think does not > encourage removing this ambiguity is the fact that a PW does > not exist in its own. It is always inside a tunnel of some > sort and is a single hop as far as > the tunneling network is concerned. > > > > > > At > > > the PSN level, OAM can be achieved using either IP tools such as > > > LSP-Ping, or Y.1711 tools. Any OAM specific issues with > the PSN are > > > clearly outside the scope of the PWE3. The only requirement is to > > > address the IP aliasing issue. The most straighforward way to > > > resolve it is to make sure that all CWs have the nibble following > > > immediately the bottom label set to a value different of > 4, 6, or 8 > > > (zero seems to be the accepted value). This means that the SONET > > > encapsulation would have to go with Option 3 in Andy's three > > > proposals. > > > > > > > > Phase 2: > > > the work of the PWE3 may expand to support endpoints of different > > > types (e.g., FR-MPLS-Ethernet). > > NH=> I suggest some caution here. It is perfectly valid (and > > required) to have service-interworking between technologies that > > belong to the *same* network mode. It is not so valid to have > > service-interworking between technologies that don't belong to the > > same mode......here only client/server relationships make > sense, and > > even then only certain ones between the 3 modes. One can of course > > ignore this, and no doubt this is going to happen.......but > I advise > > caution. > > > > > In this scenario, if the native > > > service is terminated locally at each PE, then clearly there is a > > > need for the following: a. the ability to define a PW > specific OAM > > > and link management functions and inteoperate it with the native > > > service OAM and link management. > > NH=> Why? The scenario described (ie service-interworking) > requires > > that the trails of each technology terminate at the > IWF....if one drew > > out the G.805 diagrams this would be clear. This means > their native > > OAM functions (if any) also terminate at the IWF. One therefore > > requires some higher/common 'networking entity' to be > carried end-end > > across the concatenated server technologies. However, I > don't see any > > difference between ATM/MPLS service interworking and ATM/MPLS/FR > > service interworking and ATM/MPLS/ethernet service > interworking (other > > than the validity of having mode mismatch, and the functional > > specification differences of each of the technologies in question). > > Apart from the important question of whether a PW layer is a > MPLS layer, the rest is not different from FR-ATM service > interworking (FRF.8.1). In the latter case, you can carry a > bridged or routed PDU across these 2 L2 networks. In fact you > can carry a mix of protocols over the same VC. > > > > b. the ability to self-identify the protocol carried in a > single PW. > > > A PW can carry both user packets > > NH=> of which layer network? > > I am talking about protocols used by the end-user equipment. > The CPE may be routing IP, IPX, or any network layer protocol > over a ATM VC. It could also bridge Ethernet, FDDI, or any > other bridged media protocol over a ATM VC. > > > > and OAM packets > > NH=> of which layer network? > > I am referring to segment OAM messages originating and > terminating in the PW endpoints (or inner LSP endpoints). > > > > and we want them to > > > share the same path in the presence of ECMP. A PW can also carry > > > both a end-user bridged and a routed PDU (multiprotocol PW). > > NH=> Whoa! You have just changed the service-interworking > case into a > > (partial) client/server case....in the former the etherent > component > > is simply a server layer access partition (terminates at > the IWF) but > > now you are describing the case where the ethernet pkts have to be > > carried across all intervening networks....so, for example, > it could > > be that ethernet is client to both MPLS and ATM partitions say, but > > the MPLS and ATM partitions are using service interworking. As I > > noted previously, if you draw out the G.805 relationships > this would > > be much clearer. > > I do not understand your point here. If I want to carry a > higher layer protocol PDU over a > Ethernet-(PE1)-MPLS-(PE2)-ATM network, I can do it in three > different ways: a. Extend Ethernet over MPLS (network > interworking) to the PE2 and then perform Ethernet-ATM > service interworking there. b. Extend ATM over MPLS (network > interworking) to PE1 and then perform Ethernet-ATM service > interowrking there. c. Terminate ATM and Ethernet locally at > each PE and perform 2 service interworking functions, one at > PE1 (Ethernet-MPLS), the other at PE2 (ATM-MPLS). > > It is clear to me that in (a) and (b), OAM messages of either > the Ethernet layer or the ATM layer need to be carried in the > inner LSP. It is not the case in (c), since both ATM and > Ethernet are terminated. Are we saying the same thing? > > > > This is > > > where the MPLS/PW PID is useful but it should be > addressed in a much > > > wider scope than the current PWE3 issues. > > NH=> Please note this observation: A PID field is only required to > > identify the *clients* of a given layer network when these > can change > > over the life of the (server) layer trail. In G.805 terms this is > > describing a multiplexing function that is related to the > adaptation > > of the client signal into the payload of the server signal. Each > > layer network however, should have its own native OAM that is > > *independent* of any higher client layer. That is, the PID > field and > > the layer network's native OAM are *not* in any way related > (and the > > PID function sits above the OAM functionally).....putting > this is very > > plain terms, the *client* PID field should not be used to > identify OAM > > pkts. > > I agree with you on this point. The PID is in principle an > identifier of the higher layer protocol, not of the OAM > messages of the layer below it. The PID gives an indication of what type of PW VC is being carried, which includes the higher layer protocol; thus, it is reasonable to indicate PW OAM with this. --Tom > > Finally, if MPLS is properly specified there is no need for any of > > this artifical PW stuff....we simply need to interwork MPLS and the > > other technologies natively. The PW stuff only 'lives' because: > > - of LDP and the issues/hacks of > ECMP.....load-splitting only makes > > arch sense in a *single* layer network. > > - MPLS is 'allowed' to re-order pkts > > - someone thinks squeezing a bit of BW (wrt certain > client layers) is > > useful > > - the erroneous belief that X/IP is somehow the same as X/MPLS > > > > An unneccessary networking layer (the PW) has thus been > created, that > > is now starting to take on a life of its own as an > 'in-between' layer > > network, when there is no need for it....esp when we have to manage > > the MPLS network anyway (so do it once, and do it right). Thanks, > > just something else to manage ;-) On a serious note however, I > > hope/pray there are some suppliers out there that can > understand what > > I am saying here and will provide solutions without these > unnecessary > > problems. I don't think its that hard (technically at least). > > > > > > Let me know what you think. > > > Mustapha. > > > ------------ > > > > David Allan wrote: > > > > > > > > We do have two separate problems.... > > > > > > > > 1) Is a means of identifying a generic payload. This > would appear > > > > to potentially require additional services such as > sequencing etc. > > > > stuff already dealt with in the exissting PWE control > words. This > > > > would include ordering, and if this was preserved in > the presence > > > > of proprietary ECMP so much the better. > > > > > > > > 2) A means of instrumenting PWs such that packets fate > shares with > > > > PW forwarding. Tom has proposed VCCV which needs an > available bit > > > > in the CW and control handshaking to agree on what the > bit means. > > > > The PPP DLL approach (Georges proposal) or my proposal > permits the > > > > instrumenting protocol to self identify and therefore IMHO is > > > > preferable. > > > > > > > > But I am skeptical that simply having a protocol > identifier means > > > > a PW can carry anything. Its not designed with the requisite > > > > attributes for service bearing. If we want "carry > anything" with > > > > ordering fragmentation etc. we have more to do. > > > > > > > > my 2 cents > > > > Dave > > > > > > > > > -----Original Message----- > > > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > > > > Sent: Tuesday, May 06, 2003 4:00 AM > > > > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > > > > Cc: pwe3@ietf.org > > > > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > I believe that George's comment has been very much in place. > > > > > > > > > > The "MPLS PID" story looks to me like following: > > > > > > > > > > 1. There was a recognized but, for some reasons, > undeclared need > > > > > > > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > > > > complied with this, and some did not; some others simply > > > > > declared that the CW is optional. > > > > > > > > > > 2. At some (rather late) stage, the need has been declared, > > > > > explained (which is always good!) and proposed as part of > > > > > the standard (moving the architecture document int the > > > > > Standards Track). > > > > > > > > > > 3. In order to minimize impact on some pre-standard > > > > implementations > > > > > that have either utilized the 1st nibble of the CW or used > > > > RTP > > > > > (or both), an optional opaque 32-bit word has > between the PW > > > > label > > > > > (at the bottom of the label stack) and a the CW/RTP header > > > > has been > > > > > proposed as the simplest way out. The only requirement for > > > > this > > > > > block of data has been to keep its 1st nibble zeroed. > > > > > > > > > > 4. After that, this patch has been somehow "promoted" to the > > > > title > > > > > and associated status of of "MPLS PID". And this promotion > > > > has > > > > > triggered a long discussion of its possible uses far beyond > > > > the > > > > > original patchy fuctionality. > > > > > > > > > > 5. The proposals mentioned in is discussion are, IMO, > paramount > > > > > to an alternative PWE3 architecture (including allocation > > > > > of a PWE3 protocol number in IP header etc.). They also > > > > include > > > > > amendments to Y.1711 which is presumably out of > scope of PWE3 > > > > > > > > > (and IETF in general) etc. > > > > > And somehow the fact that existing LSRs carry IP > traffic over > > > > > > > > > LSPs without any MPLS PID and will hardly be ever > retrofitted > > > > > > > > > has been happily ignored by some of the participants. > > > > > > > > > > IMHO the best way out of the confusion would be to > demote "MPLS > > > > > PID" to what it really is - a patch solving the ECMP > problem for > > > > > the following three cases (and just for these > > > > cases): > > > > > > > > > > o PW encapsulations that do not mandate a CW, so that > > > > payload > > > > > immediately > > > > > follows the PW label. In other words, make SOME CW > > > > mandatory. > > > > > o PW encapsulations that mandate a CW but utilize its 1st > > > > nibble. > > > > > They would prepend an opaque 32-bit word with > the zeroed > > > > > 1st nibble > > > > > by default, reserving an option to drop it if > ECMP is not > > > > > used in > > > > > the core network. > > > > > o PW encapsulations that use RTP. They may follow the > > > > > same rules as in > > > > > the previous case, or may use weaker rules because the > > > > > first nibble > > > > > of an RTP header distinguishes it from > IPv4/IPv6 headers > > > > > and this > > > > > is probably sufficient for ECMP. > > > > > > > > > > I think that building theories/architectures on patches is > > > > > counter-productive. > > > > > > > > > > With best regards, > > > > > Sasha Vainshtein > > > > > email: sasha@axerra.com > > > > > tel: +972-3-7659993 (office) > > > > > +972-8-9254948 (res.) > > > > > +972-58-674833 (cell.) > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 14:49:34 -0400 Lines: 258 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 20:57:35 2003 Return-path: To: "'Mustapha Aissaoui'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Thursday, May 08, 2003 2:32 PM > To: Busschbach, Peter B (Peter) > Cc: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Peter, > thanks for the comments. See more below. > > Mustapha. > ---------- > "Busschbach, Peter B (Peter)" wrote: > > > > > -----Original Message----- > > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > > Sent: Wednesday, May 07, 2003 6:42 PM > > > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > Dave and all, > > > I agree with your assessment. Given that we want to progress the > > > PWE3 work, I propose to address the issues raised in 2 phases: > > > > > > Phase 1: > > > the current scope of the PWE3 working group is to provide for a PW > > > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > > > environment, the native service OAM and link management > achieves all > > > what is needed and we do not need to define a specific PW OAM. At > > > the PSN level, OAM can be achieved using either IP tools such as > > > LSP-Ping, or Y.1711 tools. Any OAM specific issues with > the PSN are > > > clearly outside the scope of the PWE3. > > > The only requirement is to address the IP aliasing issue. The most > > > straighforward way to resolve it is to make sure that all CWs have > > > the nibble following immediately the bottom label set to a value > > > different of 4, 6, or 8 (zero seems to be the accepted > value). This > > > means that the SONET encapsulation would have to go with > Option 3 in > > > Andy's three proposals. > > > > > > Phase 2: > > > the work of the PWE3 may expand to support endpoints of different > > > types (e.g., FR-MPLS-Ethernet). In this scenario, if the native > > > service is terminated locally at each PE, then clearly there is a > > > need for the following: > > > a. the ability to define a PW specific OAM and link management > > > functions and inteoperate it with the native service OAM and link > > > management. > > > b. the ability to self-identify the protocol carried in a > single PW. > > > A PW can carry both user packets and OAM packets and we > want them to > > > share the same path in the presence of ECMP. A PW can also carry > > > both a end-user bridged and a routed PDU (multiprotocol > PW). This is > > > where the MPLS/PW PID is useful but it should be > addressed in a much > > > wider scope than the current PWE3 issues. > > > > Mustapha, > > > > I don't think I agree with your rationale. In case of > service >interworking, e.g. Frame Relay to Ethernet, there is > one point in the >network where the two protocols meet. Let's > call that point A. Further >assume that CE1 is the Frame > Relay endpoint and CE2 is the Ethernet >endpoint. On the link > between CE1 and A, Frame Relay OAM applies. On the >link > between A and CE2 ethernet OAM applies. > > Now assume that A coincides with a PE, say PE2. In that > case, one >segment of the link between CE1 and A is carried > over a PW. I would >argue that from a PW perspective this is > an encapsulation of Frame >Relay, nothing more, nothing less. > Therefore: > > > > a)Frame Relay OAM can be used to validate the sanity of the > PW segment > > > > b)There is no need to self-identify the protocol. As is the > case for all PWs, the protocol carried over it is identified > during PW set up. > > I guess your observation is correct if one extends FR to the remote > PE. In my response to Neil, I mentioned three ways of performing > Ethernet-(PE1)-MPLS-(PE2)-FR: > a. Extend Ethernet over MPLS (network interworking) to PE2 and > then perform Ethernet-FR service interworking there. > b. Extend FR over MPLS (network interworking) to PE1 and then > perform Ethernet-ATM service interowrking there. > c. Terminate Ethernet and FR locally at each PE and perform 2 > service interworking functions, one at PE1 (Ethernet-MPLS), the > other at PE2 (FR-MPLS). > > Your observation applies to (a) and (b). In (c), a new mechanism for > OAM is required since both FR and Ethernet are terminated locally. > Mustapha, You are right and I have to apologize because I didn't read your first email carefully enough. Case c) as you identify is a perfectly valid way to interconnect Ethernet and Frame Relay endpoints over an MPLS core network. However, this would require Service Interworking between Ethernet and MPLS on the one hand and Frame Relay and MPLS on the other. Service Interworking is quite different from Network Interworking as specified in PWE3. I don't think it requires a "new" mechanism for OAM. I think it requires interworking of Frame Relay OWM with MPLS OAM and of Ethernet OAM with MPLS OAM. I also don't think it requires an MPLS PID. In any case, I think we should not try to get commonality between MPLS Network Interworking (i.e. PWE3) and MPLS Service Interworking, without analyzing carefully what exactly we are trying to do. I am with Neil on this one: G.805 and a clear understanding of what is the client layer and what is the service layer will avoid a lot of problems. Peter > > By the way, I agree with your observations on phase 1. > > > > Peter > > > > > > Let me know what you think. > > > Mustapha. > > > ------------ > > > > David Allan wrote: > > > > > > > > We do have two separate problems.... > > > > > > > > 1) Is a means of identifying a generic payload. This > would appear > > > > to potentially require additional services such as > sequencing etc. > > > > stuff already dealt with in the exissting PWE control > words. This > > > > would include ordering, and if this was preserved in > the presence > > > > of proprietary ECMP so much the better. > > > > > > > > 2) A means of instrumenting PWs such that packets fate shares > > > > with PW forwarding. Tom has proposed VCCV which needs an > > > > available bit in the CW and control handshaking to agree on what > > > > the bit means. The PPP DLL approach (Georges proposal) or my > > > > proposal permits the instrumenting protocol to self identify and > > > > therefore IMHO is preferable. > > > > > > > > But I am skeptical that simply having a protocol > identifier means > > > > a PW can carry anything. Its not designed with the requisite > > > > attributes for service bearing. If we want "carry anything" with > > > > ordering fragmentation etc. we have more to do. > > > > > > > > my 2 cents > > > > Dave > > > > > > > > > -----Original Message----- > > > > > From: Sasha Vainshtein [mailto:Sasha@axerra.com] > > > > > Sent: Tuesday, May 06, 2003 4:00 AM > > > > > To: 'Shahram Davari'; 'George Swallow'; Danny McPherson > > > > > Cc: pwe3@ietf.org > > > > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > I believe that George's comment has been very much in place. > > > > > > > > > > The "MPLS PID" story looks to me like following: > > > > > > > > > > 1. There was a recognized but, for some reasons, > undeclared need > > > > > > > > > to keep the 1st nibble of a PW CW zeroed. Some PWE3 drafts > > > > > complied with this, and some did not; some others simply > > > > > declared that the CW is optional. > > > > > > > > > > 2. At some (rather late) stage, the need has been declared, > > > > > explained (which is always good!) and proposed as part of > > > > > the standard (moving the architecture document int the > > > > > Standards Track). > > > > > > > > > > 3. In order to minimize impact on some pre-standard > > > > implementations > > > > > that have either utilized the 1st nibble of the CW or used > > > > RTP > > > > > (or both), an optional opaque 32-bit word has > between the PW > > > > label > > > > > (at the bottom of the label stack) and a the CW/RTP header > > > > has been > > > > > proposed as the simplest way out. The only requirement for > > > > this > > > > > block of data has been to keep its 1st nibble zeroed. > > > > > > > > > > 4. After that, this patch has been somehow "promoted" to the > > > > title > > > > > and associated status of of "MPLS PID". And this promotion > > > > has > > > > > triggered a long discussion of its possible uses far beyond > > > > the > > > > > original patchy fuctionality. > > > > > > > > > > 5. The proposals mentioned in is discussion are, IMO, > paramount > > > > > to an alternative PWE3 architecture (including allocation > > > > > of a PWE3 protocol number in IP header etc.). They also > > > > include > > > > > amendments to Y.1711 which is presumably out of > scope of PWE3 > > > > > > > > > (and IETF in general) etc. > > > > > And somehow the fact that existing LSRs carry IP > traffic over > > > > > > > > > LSPs without any MPLS PID and will hardly be ever > retrofitted > > > > > > > > > has been happily ignored by some of the participants. > > > > > > > > > > IMHO the best way out of the confusion would be to demote > > > > > "MPLS PID" to what it really is - a patch solving the ECMP > > > > > problem for the following three cases (and just for these > > > > cases): > > > > > > > > > > o PW encapsulations that do not mandate a CW, so that > > > > payload > > > > > immediately > > > > > follows the PW label. In other words, make SOME CW > > > > mandatory. > > > > > o PW encapsulations that mandate a CW but utilize its 1st > > > > nibble. > > > > > They would prepend an opaque 32-bit word with the > > > > > zeroed 1st nibble > > > > > by default, reserving an option to drop it if ECMP is > > > > > not used in > > > > > the core network. > > > > > o PW encapsulations that use RTP. They may follow the > > > > > same rules as in > > > > > the previous case, or may use weaker rules because the > > > > > first nibble > > > > > of an RTP header distinguishes it from IPv4/IPv6 > > > > > headers and this > > > > > is probably sufficient for ECMP. > > > > > > > > > > I think that building theories/architectures on patches is > > > > > counter-productive. > > > > > > > > > > With best regards, > > > > > Sasha Vainshtein > > > > > email: sasha@axerra.com > > > > > tel: +972-3-7659993 (office) > > > > > +972-8-9254948 (res.) > > > > > +972-58-674833 (cell.) > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 21:11:34 +0100 Lines: 29 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Sasha@axerra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 22:15:33 2003 Return-path: To: tnadeau@cisco.com, Shahram_Davari@pmc-sierra.com, mustapha.aissaoui@alcatel.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, > > No we should not ignore them. But you are confusing the > > solution with the requirement. I am sure the 25 SPs didn't > > mandate VCCV ! All they need is a way to manage their PWs and > > as I said above there are better architectural alternatives to VCCV. > > You are right that most SPs don't care about the > solution, just that it solves the problem, at least > at a high level. However, there are many ways to > skin a cat, and from the feedback I have been getting > use of VCCV and LSP ping are the way my customers > want to skin this cat (i.e.: they don't want to use > y.1711's so-called 'architecturally correct' solution). NH=> Once you have bought into a given direction it ain't easy to change....if its bad choice then kludge on kludge results. The poor cat they bought has no choice now but to be skinned in 1 way. What I very seriously object to however, is the misinformation you pedal that Y.1711 is 'complex/wrong' and your stuff is 'simple/right'. I can't speak for other carriers, but there is a major movement here (which has even surprised me and colleagues who have been closer to it for some time) as those who have to now get involved in considerations of deploying this stuff suddenly realise its (how shall I put this politely) 'not very nice'. You may be surprised how they feel about this (and I am not talking about the poor design team who have already bought the cat....ever heard of the hostage syndrome?). Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 16:18:50 -0400 Organization: Cisco Systems, Inc. Lines: 51 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6815@i2km07-ukbr.domain1.systemhost.net> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , , , X-From: pwe3-admin@ietf.org Thu May 08 22:22:53 2003 Return-path: To: , , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6815@i2km07-ukbr.domain1.systemhost.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Thursday, May 08, 2003 4:12 PM > To: tnadeau@cisco.com; Shahram_Davari@pmc-sierra.com; > mustapha.aissaoui@alcatel.com; dallan@nortelnetworks.com > Cc: Sasha@axerra.com; swallow@cisco.com; danny@tcb.net; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Tom, > > > > > No we should not ignore them. But you are confusing the > > > solution with the requirement. I am sure the 25 SPs didn't > > > mandate VCCV ! All they need is a way to manage their PWs and > > > as I said above there are better architectural > alternatives to VCCV. > > > > You are right that most SPs don't care about the > > solution, just that it solves the problem, at least > > at a high level. However, there are many ways to > > skin a cat, and from the feedback I have been getting > > use of VCCV and LSP ping are the way my customers > > want to skin this cat (i.e.: they don't want to use > > y.1711's so-called 'architecturally correct' solution). > NH=> Once you have bought into a given direction it ain't > easy to change....if its bad choice then kludge on kludge > results. The poor cat they bought has no choice now but to > be skinned in 1 way. What I very seriously object to > however, is the misinformation you pedal that Y.1711 is > 'complex/wrong' and your stuff is 'simple/right'. Frankly that message is coming from both sides, so lets put that argument aside for the moment. What would be misinformation would be the assertion you and others made a few years ago that operations should throw away all of their existing line cards to implement Y.1711 at the time in the name of architectural OAM purity. Y.1711 clearly didn't and doesn't work for LDP-based networks -- you have admitted to that as have the other Y.1711 authors -- yet at the time it was peddled as the ultimate OAM solution. If operators had listened to you at the time and replaced all of their line cards, they would be SOL right now, wouldn't they? Oh, but of course, they would just overhaul them again to support the kludges...ehm, addendums to Y.1711 so that they could be architecturally pure again...maybe. So why should anyone believe you this time? --Tom From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 16:25:47 -0400 Lines: 225 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C315A0.0150EDDC" Cc: "'Sasha Vainshtein'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 22:33:25 2003 Return-path: To: "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C315A0.0150EDDC Content-Type: text/plain; charset="iso-8859-1" Tom: It is irresponsible to tout a mechanism that doesn't work while claiming that it a) works, b) solves the worlds MPLS OAM problems, and c) does so in a cost-effective and timely manner. At the risk of wasting everyone;s time, I would be curious to have you substantiate some of these outlandish claims. Y.1711 did none of those things originally while claiming it did. It was and still is being positioned as the "architecturally correct" visionary solution. I like the term "originally", ECMP broke a lot of stuff. I also believe there have always been strong applicablity statements associated with 1711. At that time its proponents suggested that it was okay to replace all of a network's line cards to support this solution. Of course all of your implementations are merely IOS upgrades. Well, guess what, if we all had drunk the Y.1711 Koolaid then, SPs would have to be spending OPEX and CAPEX replacing line cards a second time because shortly after it was ratified at the ITU, folks like myself showed it not to work for LDP-based networks. WHy is it that you characterize a solution designed for ease of implementation is such an onerous burden. This is vendor specific implementation issues.... noone has mandated continual replacement of line cards. Yea, sure the number of SPs I just mentioned includes a mere %95, but heck, we should all obey architectural correctness because the Y.1711 folks said so the first time, so we should believe them this time too. So please stop passing the FUD about Y.1711 being something that it is not because that is indeed hysterical. If you have real technical issues, drafts are posted with real technical detail, lets discuss. Dave > I assert that it is certainly > not ready and should not be considered as an acceptable approach. > > > The only requirement is to > > address the IP aliasing issue. The most straighforward way to > > resolve it is to make sure that all CWs have the nibble > > following immediately the bottom label set to a value > > different of 4, 6, or 8 (zero seems to be the accepted > > value). This means that the SONET encapsulation would have to > > go with Option 3 in Andy's three proposals. > > > > Phase 2: > > the work of the PWE3 may expand to support endpoints of > > different types (e.g., FR-MPLS-Ethernet). In this scenario, > > if the native service is terminated locally at each PE, then > > clearly there is a need for the following: a. the ability to > > define a PW specific OAM and link management functions and > > inteoperate it with the native service OAM and link > > management. b. the ability to self-identify the protocol > > carried in a single PW. > > > A PW can carry both user packets and > > OAM packets and we want them to share the same path in the > > presence of ECMP. > > Again, read the OAM requirements referenced above. > OAM traffic MUST be carried on the same data path regardless > of whether ECMP is active or not. Are you suggesting that > we should ignore that 25 SPs have told us? Looks to me that he stated accurately in the sentence above what those 25 SPs told you. Just described it in two phases. So what are you objecting to? Is there a real technical point in this diatrabe? cheers Dave ------_=_NextPart_001_01C315A0.0150EDDC Content-Type: text/html; charset="iso-8859-1" Message
 Tom: 

  It is irresponsible to tout a mechanism that doesn't work while claiming that it a) works, b) solves the worlds MPLS OAM problems, and c) does so in a cost-effective and timely manner.   

At the risk of wasting everyone;s time, I would  be curious to have you substantiate some of these outlandish claims.

 Y.1711 did none of those things originally while claiming it did. It was and still is being positioned as the "architecturally correct" visionary solution.  

I like the term "originally", ECMP broke a lot of stuff. I also believe there have always been strong applicablity statements associated with 1711.

 

 At that time its proponents suggested that it was okay to replace all of a network's line cards to support this solution.  

Of course all of your implementations are merely IOS upgrades.

 

 Well, guess what, if we all had drunk the Y.1711 Koolaid then, SPs would have to be spending OPEX and CAPEX replacing line cards a second time because shortly after it was ratified at the ITU, folks like myself showed it not to work for LDP-based networks.  

WHy is it that you characterize a solution designed for ease of implementation is such an onerous burden. This is vendor specific implementation issues.... noone has mandated continual replacement of line cards.

 Yea, sure the number of SPs I just mentioned includes a mere %95, but heck, we should all obey architectural correctness because the Y.1711 folks said so the first time, so we should believe them this time too.  So please stop passing the FUD about Y.1711 being something that it is not because that is indeed hysterical.

If you have real technical issues, drafts are posted with real technical detail, lets discuss.

Dave 

 

 > I assert that it is certainly
> not ready and should not be considered as an acceptable approach.
>
> > The only requirement is to
> > address the IP aliasing issue. The most straighforward way to
> > resolve it is to make sure that all CWs have the nibble
> > following immediately the bottom label set to a value
> > different of 4, 6, or 8 (zero seems to be the accepted
> > value). This means that the SONET encapsulation would have to
> > go with Option 3 in Andy's three proposals.
> >
> > Phase 2:
> > the work of the PWE3 may expand to support endpoints of
> > different types (e.g., FR-MPLS-Ethernet). In this scenario,
> > if the native service is terminated locally at each PE, then
> > clearly there is a need for the following: a. the ability to
> > define a PW specific OAM and link management functions and
> > inteoperate it with the native service OAM and link
> > management. b. the ability to self-identify the protocol
> > carried in a single PW.
>
> > A PW can carry both user packets and
> > OAM packets and we want them to share the same path in the
> > presence of ECMP.
>
>       Again, read the OAM requirements referenced above.
> OAM traffic MUST be carried on the same data path regardless
> of whether ECMP is active or not.  Are you suggesting that
> we should ignore that 25 SPs have told us?

Looks to me that he stated accurately in the sentence above what those 25 SPs told you. Just described it in two phases. So what are you objecting to? Is there a real technical point in this diatrabe?

cheers
Dave



------_=_NextPart_001_01C315A0.0150EDDC-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 21:11:36 +0100 Lines: 27 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: Sasha@axerra.com, Shahram_Davari@pmc-sierra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 22:33:51 2003 Return-path: To: tnadeau@cisco.com, mustapha.aissaoui@alcatel.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, in-line and snipped. Neil > Also, pitching Y.1711 as a possible alternative is > irresponsible. NH=> Why does this worry you so? But maybe plagiarising is not irresponsible....the early stuff you did as 'requirements', when you eventually figured out OAM was important (which took quite a while I must say) was largely a cut-paste on what I wrote over a year previous in Y.1710 and you even choose to use similar 'CV' nomenclature. > It is badly broken for LDP-based networks NH=> The only broken thing here is all the kludges that LDP has spawned....this is the cat you sold us which we now have to skin in a fixed direction with pretty blunt tools. Your PW OAM stuff is p2p and between 2 fixed locations just like Y.1711, and has nothing to so with LDP....its just operating in some new 'in-between' layer that we have to manage (besides the client and MPLS). > Of course, its proponents > are working feverishly to patch it up within the ITU NH=> The only truly 'feverish' work in ITU I am aware of came from Cisco trying to object to 4 ITU Recommendations at the last minute. You stand in a class of 1 wrt this behaviour and I believe it is a record...it has not gone unoticed. You failed to derail the Recs in all cases (though I'll grant you delayed the stuff)...and BTW Cisco finally agreed to Y.1711 (and the other 3 Recs). From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 21:11:37 +0100 Lines: 19 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: dallan@nortelnetworks.com, Sasha@axerra.com, Shahram_Davari@pmc-sierra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 22:39:05 2003 Return-path: To: tnadeau@cisco.com, rahul@redback.com, mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, > > > > NH=> There is not a 'need' for PWs at all. The only 'need' > > arises due to reasons I pointed out in my response to > > Mustapha. > > Your lack of need aside, the fact still remains > that there are lots of deployments of PWs. Therefore, > they do indeed need PW-level OAM. NH=> You seem to have missed the point Tom. This is nothing to do with *my* need, I am merely pointing out the flaws in the architecture/thinking that has led to this unnecessary state.....and the bad stuff is still proliferating, eg your PW OAM stuff. Not sure where other trad operators are at with this stuff, but I would be amazed if their CTO equivalents were not thinking along the same lines as we are. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 16:39:47 -0400 Organization: Cisco Systems, Inc. Lines: 350 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EA_01C31580.72E9D4B0" X-From: pwe3-admin@ietf.org Thu May 08 22:42:14 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------=_NextPart_000_01EA_01C31580.72E9D4B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 It is irresponsible to tout a mechanism that doesn't work while = claiming that it a) works, b) solves the worlds MPLS OAM problems, and c) does so = in a cost-effective and timely manner. =20 At the risk of wasting everyone;s time, I would be curious to have you substantiate some of these outlandish claims. =20 T> I don't want to beat a dead horse. Just read back on the threads regarding Y.1711 on the MPLS list. Also check the many = comments/discussion on Y.1711 at the ITU. I think that the people that are interested and = are still listening know what I am referring to anyway. =20 Y.1711 did none of those things originally while claiming it did. It = was and still is being positioned as the "architecturally correct" visionary solution. =20 I like the term "originally", ECMP broke a lot of stuff. I also believe there have always been strong applicablity statements associated with = 1711.=20 T> I guess that is your opinion, and you are entitled to it. The fact is that many of my and other vendor's customers use it, so we have two = options: a) throw away all of our gear and redesign everything, b) work with what = we have to solve the problems at hand. =20 At that time its proponents suggested that it was okay to replace all = of a network's line cards to support this solution. =20 Of course all of your implementations are merely IOS upgrades.=20 T> Well, yes we do have implementations that people actually use. And yes, our first implementations of LSP ping and VCCV are in fact merely = IOS upgrades. Follow-ons are also planned as IOS upgrades with possible = hardware accelleration. The point is that out of the gate, we don't need hardware = to implement this stuff for it to be useful. =20 Well, guess what, if we all had drunk the Y.1711 Koolaid then, SPs = would have to be spending OPEX and CAPEX replacing line cards a second time because shortly after it was ratified at the ITU, folks like myself = showed it not to work for LDP-based networks. =20 WHy is it that you characterize a solution designed for ease of implementation is such an onerous burden. =20 T> There is nothing wrong with ease of implementation. The issue at hand = is that Y.1711 requires hardware accelleration to work at all on any = reasonable scale, especially if it were used as its authors originally intended -- = on all LSPs at 1 second intervals! This is vendor specific implementation issues.... =20 T> Yes, I realize that at the ITU implementation issues are not considered, but this is the IETF which is concerned with them. noone has mandated continual replacement of line cards.=20 T> I guess it depends on how you characterize "ease of = implementation". Sure the number of SPs I just mentioned includes a mere %95, but = heck, we should all obey architectural correctness because the Y.1711 folks said = so the first time, so we should believe them this time too. So please stop passing the FUD about Y.1711 being something that it is not because that = is indeed hysterical. If you have real technical issues, drafts are posted with real technical detail, lets discuss.=20 T> Yes, still wading through all of them. *) --Tom ------=_NextPart_000_01EA_01C31580.72E9D4B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
  It is=20 irresponsible to tout a mechanism that doesn't work while claiming = that it a)=20 works, b) solves the worlds MPLS OAM problems, and c) does so in a=20 cost-effective and timely manner.   

At the risk of = wasting everyone;s=20 time, I would  be curious to have you substantiate some of these=20 outlandish claims.  

T> I don't want to beat a dead horse. = Just read=20 back on the threads regarding Y.1711 on the MPLS list. Also check the = many=20 comments/discussion on Y.1711 at the ITU.  I think that the = people that=20 are interested and are still listening know what I am referring to=20 anyway.

 

 Y.1711 did none of those = things=20 originally while claiming it did. It was and still = is being=20 positioned as the "architecturally correct" visionary=20 solution.  

<= /BLOCKQUOTE>

I like the term = "originally", ECMP=20 broke a lot of stuff. I also believe there have always been strong=20 applicablity statements associated with 1711. 

T> I guess that is your opinion, = and you are=20 entitled to it. The fact is that many of my and other vendor's = customers use=20 it, so we have two options:  a) throw away all of our gear and = redesign=20 everything, b) work with what we have to solve the problems at=20 hand.  

 At=20 that time its proponents suggested that it was okay to replace all = of a=20 network's line cards to support this solution.  

<= /BLOCKQUOTE>

Of course all of = your=20 implementations are merely IOS upgrades. 

T>    Well, yes we = do have=20 implementations that people actually use. And yes, our first=20 implementations of LSP ping and VCCV are in fact merely IOS=20 upgrades. Follow-ons are also planned as IOS upgrades with = possible=20 hardware accelleration. The point is=20 that out of the gate, we don't need hardware to implement this stuff = for it to=20 be useful.

 

 Well, guess what, if we = all had=20 drunk the Y.1711 Koolaid then, SPs would have to be spending OPEX = and=20 CAPEX replacing line cards a second time because shortly after it = was=20 ratified at the ITU, folks like myself showed it not=20 to work for LDP-based networks.  

<= /BLOCKQUOTE>

WHy is it = that you=20 characterize a solution designed for ease of implementation is such an = onerous=20 burden.  

T> There is nothing wrong with ease of=20 implementation. The issue at hand is that Y.1711 requires hardware=20 accelleration to work at all on any reasonable scale, especially if it = were=20 used as its authors originally intended -- on all LSPs at 1 second=20 intervals!

 This is   vendor specific implementation = issues....  

    T> Yes, I realize = that at the=20 ITU implementation issues are not considered, but this is the IETF = which is=20 concerned with them.

 noone has mandated continual = replacement=20 of line cards. 

T>    I guess it depends = on how you=20 characterize "ease of=20 implementation".

   Sure the number of SPs = I just=20 mentioned includes a mere %95, but heck, we should all obey = architectural=20 correctness because the Y.1711 folks said so the first time, so we = should=20 believe them this time too.  So please stop passing the FUD about = Y.1711=20 being something that it is not because that is=20 indeed hysterical.

If you have real technical issues, = drafts are=20 posted with real technical detail, lets discuss. 

T> = Yes, still=20 wading through all of them. *)

   =20 = --Tom

------=_NextPart_000_01EA_01C31580.72E9D4B0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 21:59:16 +0100 Lines: 115 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 23:14:44 2003 Return-path: To: mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Thanks Mustapha....excellent responses, you have clearly a good grip on this stuff. My remarks/answers are below....snipped as necessary. regards, Neil > > > the current scope of the PWE3 working group is to provide for a PW > > > between two endpoints of the same type (e.g., FR-MPLS-FR). In this > > > environment, the native service OAM and link management > achieves all > > > what is needed and we do not need to define a specific PW OAM. > > NH=> Absolutely correct.....when I want to interwork > ATM/MPLS say there is > > not need whatsover for PW OAM, but further there is no need > for PWs at all! > > You raise an important question which I believe deserves much > attention. NH=> Yes indeed. Think about the large ATM networks trad operators have. They need a next generation core. ATM/MPLS interworking is pretty high on the agenda here. And it has nothing to do with PWs, let alone PW OAM stuff. > Is a PW layer a regular MPLS layer or not. NH=> No it can't be. It sits above the MPLS layer in its own 'in-between' layer world. Also note this: Tom makes a big thing that Y.1711 is broken for LDP....its p2p, but so is PW OAM. But, because LDP mp2p uses merging based on a co pkt-sw forwarding mode you *always* must have p2p LSPs above this to effect the demerging (ie the p2p 'martini' LSPs for want of a better term). So why not run Y.1711 on these! Pretty obvious solution I think. So even with the LDP mp2p stuff in the X/MPLS case there is always the possiblility to use the simple Y.1711 stuff on the higher p2p LSPs. And if these show a problem one can then roll-out the heavy-weight 'Leatherman' LSP-Ping toolbox (bit bigger than a swiss army knife!) at leisure to look at the mp2p layers *iff* any lower L1 layers don't show any problems. So I see next to no justification at all for the PW OAM stuff in the X/MPLS case. As I also remarked, we are going to have to manage the client/server layers anyway....so let's do it at least as well as possible. > Apart from the important question of whether a PW layer is a MPLS > layer, NH=> It is not. > the rest is not different from FR-ATM service interworking > (FRF.8.1). In the latter case, you can carry a bridged or routed PDU > across these 2 L2 networks. In fact you can carry a mix of protocols > over the same VC. NH=> Agreed. Let's keep the layers to a min and do things right....at some point we simply have to say 'we have had enough kludges thanks'. > > > > > and we want them to > > > share the same path in the presence of ECMP. A PW can also carry > > > both a end-user bridged and a routed PDU (multiprotocol PW). > > NH=> Whoa! You have just changed the service-interworking > case into a > > (partial) client/server case....in the former the etherent > component is > > simply a server layer access partition (terminates at the > IWF) but now you > > are describing the case where the ethernet pkts have to be > carried across > > all intervening networks....so, for example, it could be > that ethernet is > > client to both MPLS and ATM partitions say, but the MPLS > and ATM partitions > > are using service interworking. As I noted previously, if > you draw out the > > G.805 relationships this would be much clearer. > > I do not understand your point here. If I want to carry a higher > layer protocol PDU over a Ethernet-(PE1)-MPLS-(PE2)-ATM network, I > can do it in three different ways: > a. Extend Ethernet over MPLS (network interworking) to the PE2 and > then perform Ethernet-ATM service interworking there. > b. Extend ATM over MPLS (network interworking) to PE1 and then > perform Ethernet-ATM service interowrking there. > c. Terminate ATM and Ethernet locally at each PE and perform 2 > service interworking functions, one at PE1 (Ethernet-MPLS), the > other at PE2 (ATM-MPLS). > > It is clear to me that in (a) and (b), OAM messages of either the > Ethernet layer or the ATM layer need to be carried in the inner LSP. > It is not the case in (c), since both ATM and Ethernet are > terminated. Are we saying the same thing? NH=> Yes we are....its clear you understand....that make me feel far more comfortable. > > > > This is > > > where the MPLS/PW PID is useful but it should be > addressed in a much > > > wider scope than the current PWE3 issues. > > NH=> Please note this observation: A PID field is only > required to identify > > the *clients* of a given layer network when these can > change over the life > > of the (server) layer trail. In G.805 terms this is describing a > > multiplexing function that is related to the adaptation of > the client signal > > into the payload of the server signal. Each layer network > however, should > > have its own native OAM that is *independent* of any higher > client layer. > > That is, the PID field and the layer network's native OAM > are *not* in any > > way related (and the PID function sits above the OAM > > functionally).....putting this is very plain terms, the > *client* PID field > > should not be used to identify OAM pkts. > > I agree with you on this point. The PID is in principle an > identifier of the higher layer protocol, not of the OAM messages of > the layer below it. NH=> Thanks. Let's make sure we avoid this kludge then. Let's keep trying to move things to a sound arch basis. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Chris Liljenstolpe Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 08 May 2003 17:24:02 -0400 Lines: 159 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D681C@i2km07-ukbr.domain1.s ystemhost.net> Reply-To: Chris Liljenstolpe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 23:27:31 2003 Return-path: In-reply-to: <0536FC9B908BEC4597EE721BE6A35389025D681C@i2km07-ukbr.domain1.systemhost.net> To: neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com X-Mailer: Mulberry/3.0.3 (Mac OS X) Content-Disposition: inline Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is an issue here that needs to be addressed, however. If the PWE implimentation is A---C---A where A is a PWE3 aware ATM switch, and C is an MPLS core, then native signaling (i.e. PNNI) will work (C looks just like a circuit). However, if the case is A---B---C----D where B is an ATM core, and D is an MPLS MSE (running PWE3), then we have a problem in signaling and recovering from faults at the BC boundary. This is a problem that will hinder MSE deployment at carriers with deployed classical networks that need to interoperate them with new model systems. Chris - --It is whispered that on 2003-05-08 21:59 +0100, neil.2.harrison@bt.com mumbled this regarding RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > Thanks Mustapha....excellent responses, you have clearly a good grip on > this stuff. > > My remarks/answers are below....snipped as necessary. regards, Neil > >> > > the current scope of the PWE3 working group is to provide for a PW >> > > between two endpoints of the same type (e.g., FR-MPLS-FR). In this >> > > environment, the native service OAM and link management >> achieves all >> > > what is needed and we do not need to define a specific PW OAM. >> > NH=> Absolutely correct.....when I want to interwork >> ATM/MPLS say there is >> > not need whatsover for PW OAM, but further there is no need >> for PWs at all! >> >> You raise an important question which I believe deserves much >> attention. > NH=> Yes indeed. Think about the large ATM networks trad operators have. > They need a next generation core. ATM/MPLS interworking is pretty high > on the agenda here. And it has nothing to do with PWs, let alone PW OAM > stuff. > >> Is a PW layer a regular MPLS layer or not. > NH=> No it can't be. It sits above the MPLS layer in its own > 'in-between' layer world. Also note this: > Tom makes a big thing that Y.1711 is broken for LDP....its p2p, but so > is PW OAM. But, because LDP mp2p uses merging based on a co pkt-sw > forwarding mode you *always* must have p2p LSPs above this to effect the > demerging (ie the p2p 'martini' LSPs for want of a better term). So why > not run Y.1711 on these! Pretty obvious solution I think. So even with > the LDP mp2p stuff in the X/MPLS case there is always the possiblility > to use the simple Y.1711 stuff on the higher p2p LSPs. And if these > show a problem one can then roll-out the heavy-weight 'Leatherman' > LSP-Ping toolbox (bit bigger than a swiss army knife!) at leisure to > look at the mp2p layers *iff* any lower L1 layers don't show any > problems. So I see next to no justification at all for the PW OAM stuff > in the X/MPLS case. As I also remarked, we are going to have to manage > the client/server layers anyway....so let's do it at least as well as > possible. > > >> Apart from the important question of whether a PW layer is a MPLS >> layer, > NH=> It is not. > >> the rest is not different from FR-ATM service interworking >> (FRF.8.1). In the latter case, you can carry a bridged or routed PDU >> across these 2 L2 networks. In fact you can carry a mix of protocols >> over the same VC. > NH=> Agreed. Let's keep the layers to a min and do things right....at > some point we simply have to say 'we have had enough kludges thanks'. >> >> >> > > and we want them to >> > > share the same path in the presence of ECMP. A PW can also carry >> > > both a end-user bridged and a routed PDU (multiprotocol PW). >> > NH=> Whoa! You have just changed the service-interworking >> case into a >> > (partial) client/server case....in the former the etherent >> component is >> > simply a server layer access partition (terminates at the >> IWF) but now you >> > are describing the case where the ethernet pkts have to be >> carried across >> > all intervening networks....so, for example, it could be >> that ethernet is >> > client to both MPLS and ATM partitions say, but the MPLS >> and ATM partitions >> > are using service interworking. As I noted previously, if >> you draw out the >> > G.805 relationships this would be much clearer. >> >> I do not understand your point here. If I want to carry a higher >> layer protocol PDU over a Ethernet-(PE1)-MPLS-(PE2)-ATM network, I >> can do it in three different ways: >> a. Extend Ethernet over MPLS (network interworking) to the PE2 and >> then perform Ethernet-ATM service interworking there. >> b. Extend ATM over MPLS (network interworking) to PE1 and then >> perform Ethernet-ATM service interowrking there. >> c. Terminate ATM and Ethernet locally at each PE and perform 2 >> service interworking functions, one at PE1 (Ethernet-MPLS), the >> other at PE2 (ATM-MPLS). >> >> It is clear to me that in (a) and (b), OAM messages of either the >> Ethernet layer or the ATM layer need to be carried in the inner LSP. >> It is not the case in (c), since both ATM and Ethernet are >> terminated. Are we saying the same thing? > NH=> Yes we are....its clear you understand....that make me feel far more > comfortable. >> >> > > This is >> > > where the MPLS/PW PID is useful but it should be >> addressed in a much >> > > wider scope than the current PWE3 issues. >> > NH=> Please note this observation: A PID field is only >> required to identify >> > the *clients* of a given layer network when these can >> change over the life >> > of the (server) layer trail. In G.805 terms this is describing a >> > multiplexing function that is related to the adaptation of >> the client signal >> > into the payload of the server signal. Each layer network >> however, should >> > have its own native OAM that is *independent* of any higher >> client layer. >> > That is, the PID field and the layer network's native OAM >> are *not* in any >> > way related (and the PID function sits above the OAM >> > functionally).....putting this is very plain terms, the >> *client* PID field >> > should not be used to identify OAM pkts. >> >> I agree with you on this point. The PID is in principle an >> identifier of the higher layer protocol, not of the OAM messages of >> the layer below it. > NH=> Thanks. Let's make sure we avoid this kludge then. Let's keep > trying to move things to a sound arch basis. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 - -- Chris Liljenstolpe GPG keys: http://www.io.com/~cds/cdl-keys.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+usr0HhGWzf9XZ/YRAsODAJ9X8aVv401aKbAfsZcsrdQR5ZXOYgCfbS3a y4FiSS7/maf5zIcC6Mgieu8= =r7DP -----END PGP SIGNATURE----- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 17:33:16 -0400 Lines: 264 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C315A9.6F170CC6" X-From: pwe3-admin@ietf.org Thu May 08 23:35:41 2003 Return-path: To: "'tnadeau@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C315A9.6F170CC6 Content-Type: text/plain; charset="iso-8859-1" T> I don't want to beat a dead horse. Just read back on the threads regarding Y.1711 on the MPLS list. Also check the many comments/discussion on Y.1711 at the ITU. I think that the people that are interested and are still listening know what I am referring to anyway. D> Well the short history seems to be absurd idea, not needed, needed but proposed is wrong, etc.etc......I'd assume we're in a different OAM epoch than you are referring to ;-) T> I guess that is your opinion, and you are entitled to it. The fact is that many of my and other vendor's customers use it, so we have two options: a) throw away all of our gear and redesign everything, b) work with what we have to solve the problems at hand. D> I love the way that continuing to sell the "same old" is positioned as noble.....and anything but your preferred solution is "throwing away everything and starting over" At that time its proponents suggested that it was okay to replace all of a network's line cards to support this solution. Of course all of your implementations are merely IOS upgrades. T> Well, yes we do have implementations that people actually use. And yes, our first implementations of LSP ping and VCCV are in fact merely IOS upgrades. Follow-ons are also planned as IOS upgrades with possible hardware accelleration. The point is that out of the gate, we don't need hardware to implement this stuff for it to be useful. D> And you believe this to be a unique attribute of your solutions... T> There is nothing wrong with ease of implementation. The issue at hand is that Y.1711 requires hardware accelleration to work at all on any reasonable scale, especially if it were used as its authors originally intended -- on all LSPs at 1 second intervals! D> Folks I talk to suggest adapting the I.610 ucode is not a big deal, you may want to talk to folks down the hall. This is vendor specific implementation issues.... T> Yes, I realize that at the ITU implementation issues are not considered, but this is the IETF which is concerned with them. D> I'd characterize it a bit differently....I'm hardly a spokesperson but IMHO the ITU is less concerned with the standardizing of and being bound by existing implementations, this has it's good and bad points. If we believe that existing implementations trump any advancement of MPLS, then it is time to invent somthing new, which has more or less the exact same effect as the ITU approach as far as provider investment to replace equipment is concerned.... noone has mandated continual replacement of line cards. T> I guess it depends on how you characterize "ease of implementation". Sure the number of SPs I just mentioned includes a mere %95, but heck, we should all obey architectural correctness because the Y.1711 folks said so the first time, so we should believe them this time too. So please stop passing the FUD about Y.1711 being something that it is not because that is indeed hysterical. If you have real technical issues, drafts are posted with real technical detail, lets discuss. T> Yes, still wading through all of them. *) looking forward to your feedback ;-) Dave ------_=_NextPart_001_01C315A9.6F170CC6 Content-Type: text/html; charset="iso-8859-1" Message

T> I don't want to beat a dead horse. Just read back on the threads regarding Y.1711 on the MPLS list. Also check the many comments/discussion on Y.1711 at the ITU.  I think that the people that are interested and are still listening know what I am referring to anyway. 
 
D> Well the short history seems to be absurd idea, not needed, needed but proposed is wrong, etc.etc......I'd assume we're in a different OAM epoch than you are referring to ;-)

<snipped>

T> I guess that is your opinion, and you are entitled to it. The fact is that many of my and other vendor's customers use it, so we have two options:  a) throw away all of our gear and redesign everything, b) work with what we have to solve the problems at hand.   

D> I love the way that continuing to sell the "same old" is positioned as noble.....and anything but your preferred solution is "throwing away everything and starting over"

 

 At that time its proponents suggested that it was okay to replace all of a network's line cards to support this solution.  

Of course all of your implementations are merely IOS upgrades. 

T>    Well, yes we do have implementations that people actually use. And yes, our first implementations of LSP ping and VCCV are in fact merely IOS upgrades. Follow-ons are also planned as IOS upgrades with possible hardware accelleration. The point is that out of the gate, we don't need hardware to implement this stuff for it to be useful. 

D> And you believe this to be a unique attribute of your solutions...

T> There is nothing wrong with ease of implementation. The issue at hand is that Y.1711 requires hardware accelleration to work at all on any reasonable scale, especially if it were used as its authors originally intended -- on all LSPs at 1 second intervals! 

D> Folks I talk to suggest adapting the I.610 ucode is not a big deal, you may want to talk to folks down the hall. 

 This is   vendor specific implementation issues....  

    T> Yes, I realize that at the ITU implementation issues are not considered, but this is the IETF which is concerned with them. 

D> I'd characterize it a bit differently....I'm hardly a spokesperson but IMHO the ITU is less concerned with the standardizing of and being bound by existing implementations, this has it's good and bad points. If we believe that existing implementations trump any advancement of MPLS, then it is time to invent somthing new, which has more or less the exact same effect as the ITU approach as far as provider investment to replace equipment is concerned....

 noone has mandated continual replacement of line cards. 

T>    I guess it depends on how you characterize "ease of implementation".

   Sure the number of SPs I just mentioned includes a mere %95, but heck, we should all obey architectural correctness because the Y.1711 folks said so the first time, so we should believe them this time too.  So please stop passing the FUD about Y.1711 being something that it is not because that is indeed hysterical.

If you have real technical issues, drafts are posted with real technical detail, lets discuss. 

T> Yes, still wading through all of them. *)

looking forward to your feedback ;-)

Dave

------_=_NextPart_001_01C315A9.6F170CC6-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 22:34:52 +0100 Lines: 27 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 08 23:42:10 2003 Return-path: To: mustapha.aissaoui@alcatel.com, busschbach@lucent.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha/Peter, small remark below. regards, Neil > I guess your observation is correct if one extends FR to the remote > PE. In my response to Neil, I mentioned three ways of performing > Ethernet-(PE1)-MPLS-(PE2)-FR: > a. Extend Ethernet over MPLS (network interworking) to PE2 and > then perform Ethernet-FR service interworking there. > b. Extend FR over MPLS (network interworking) to PE1 and then > perform Ethernet-ATM service interowrking there. > c. Terminate Ethernet and FR locally at each PE and perform 2 > service interworking functions, one at PE1 (Ethernet-MPLS), the > other at PE2 (FR-MPLS). > > Your observation applies to (a) and (b). In (c), a new mechanism for > OAM is required since both FR and Ethernet are terminated locally. NH=> I don't think so. In case c. we have 3 peer trails: FR, MPLS and ethernet. Each trail should run its own independent OAM. Now whether mixing network modes in a service interworking case is sensible (recall there are the 3 network modes of cnls, co pkt-sw and co cct-sw) is debatable....it depends on what applcations are running across these 3 partitions. However, the key point is that in service interworking the OAM of the 3 network trails are strictly independent since they are peers and have no client/server relationships. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 22:34:54 +0100 Lines: 45 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-From: pwe3-admin@ietf.org Thu May 08 23:43:35 2003 Return-path: To: tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, > One point below. > > > NH=> Please note this observation: A PID field is only > required to > > > identify the *clients* of a given layer network when these > > can change > > > over the life of the (server) layer trail. In G.805 > terms this is > > > describing a multiplexing function that is related to the > > adaptation > > > of the client signal into the payload of the server signal. Each > > > layer network however, should have its own native OAM that is > > > *independent* of any higher client layer. That is, the PID > > field and > > > the layer network's native OAM are *not* in any way related > > (and the > > > PID function sits above the OAM functionally).....putting > > this is very > > > plain terms, the *client* PID field should not be used to > > identify OAM > > > pkts. > > > > I agree with you on this point. The PID is in principle an > > identifier of the higher layer protocol, not of the OAM > > messages of the layer below it. NH=> Not quite right Mustapha. You are right it should never indicate the OAM of a layer *below* the one in question, but I was also trying to point out it should also never indicate the *same* layer OAM, ie the PID field in a given layer network indicates the *clinet* carried....the OAM of the layer in question occurs functionally *below* this in the adpatation process, and is an intrinsic property of the layer per se *irrespective* of the client it carries. Re-read what I wrote above carefully and think about a G.805 functional model of what is going on here. If there are any G.805 experts reading this then please chip-in and confirm my comments. > > The PID gives an indication of what type of PW > VC is being carried, which includes the higher layer > protocol; thus, it is reasonable to indicate PW > OAM with this. NH=> You could do this kludge (not as bad as some) but it's not right for the reasons I gave above. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 21:59:18 +0100 Lines: 18 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Sasha@axerra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 09 00:17:46 2003 Return-path: To: Shahram_Davari@pmc-sierra.com, Davidz@corrigent.com, tnadeau@cisco.com, mustapha.aissaoui@alcatel.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram Davari wrote 08 May 2003 17:25 > >2) A unified approach, applicable to all carried signal types, has > >operational benefits for the operators who wish to use PW for > >carrying of > >more than one signal type. > > Are you saying that operators prefer introducing a new > protocol management layer > with a new management protocol, rather than using the native > OAM that is > available for carried services? I think service providers > need to speak on that. NH=> David...your company is coming to see us soon....we will give you chapter/verse on our arch requirements then. But if you have been understanding what I have been saying on the lists you will be fore-armed. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Thu, 8 May 2003 22:34:53 +0100 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 09 00:19:50 2003 Return-path: To: busschbach@lucent.com, mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Peter....please see below. regards, Neil > Mustapha, > > You are right and I have to apologize because I didn't read > your first email carefully enough. > > Case c) as you identify is a perfectly valid way to > interconnect Ethernet and Frame Relay endpoints over an MPLS > core network. However, this would require Service > Interworking between Ethernet and MPLS on the one hand and > Frame Relay and MPLS on the other. > > Service Interworking is quite different from Network > Interworking as specified in PWE3. I don't think it requires > a "new" mechanism for OAM. I think it requires interworking > of Frame Relay OWM with MPLS OAM and of Ethernet OAM with > MPLS OAM. I also don't think it requires an MPLS PID. > > In any case, I think we should not try to get commonality > between MPLS Network Interworking (i.e. PWE3) and MPLS > Service Interworking, without analyzing carefully what > exactly we are trying to do. > > I am with Neil on this one: G.805 and a clear understanding > of what is the client layer and what is the service layer > will avoid a lot of problems. > > Peter NH=> Just saw this after I posted my response to Mustapha...I think we are all in sync on this now. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 9 May 2003 00:08:52 +0100 Lines: 47 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: Sasha@axerra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 09 01:12:03 2003 Return-path: To: tnadeau@cisco.com, Shahram_Davari@pmc-sierra.com, mustapha.aissaoui@alcatel.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I think this is getting a little non technical now, so hopefully last posting in this vein....please see in-line Tom. regards, Neil > Frankly that message is coming from both sides, so > lets put that argument aside for the moment. What > would be misinformation would be the assertion you and others > made a few years ago that operations should throw away all of > their existing line cards to implement Y.1711 at the time in the > name of architectural OAM purity. NH=> Never said that AFAI recall. But there is nothing wrong with trying to do things right 1st time, and from bitter experience if you break the arch rules for some near-term expediency then you usually get paid back in spades in the long-run. > Y.1711 clearly didn't > and doesn't work for LDP-based networks -- you have admitted > to that as have the other Y.1711 authors -- yet at the time > it was peddled as the ultimate OAM solution. NH=> Never said that either...and I have never held that view, at least the way it seems you are trying to portray it. Y.1711 was written (I know because I did the original drafting) based on lessons learnt from previous co pkt-sw technologies. It is based on a concept which is now central to our internally agreed net arch strategy (which we have called 'functional convergence') that says we have/need 3 network modes (cnls, co pkt-sw and co cct-sw) and we want to see functional convergence of technologies *within* each mode but not across them. This is quite logical/sensible in our view. So I wrote Y.1711 with a view to it being a generic solution for *any* co pkt-sw technology, not just MPLS....because we don't want to see functions repeated in a variety of ways across a common mode (but this is more than data-plane OAM). The intention is to seek out/use best-of-breed functional components and try to avoid stovepies and/or gateways in data/control-planes. Again, this would seem logical/sensible. Now, in any technology that uses link-connection identifiers for forwarding the only architectural constructions that make sense (ie don't cause lots of problems) are p2p and p2mp. Further, if you create a mp2p construction you have to run a p2p instance over this to demerge....its all about losing sight of the source in the mp2p lower layer. I have *always* insisted therefore that mp2m is not a sensible topological structure for a co pkt-sw forwarding mode....so the right answer is not to keep fixing this but just accept it, live with it and ultimately find ways to move away from it. If any-any connectivity is required then use a cnls mode like IP....and I have also been consistent on that view too. Use the right mode in the right way for the job required. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 9 May 2003 09:56:57 -0400 Lines: 211 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 09 16:03:18 2003 Return-path: To: "'Chris Liljenstolpe'" , neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Chris, I am not sure I fully understand your A-B-C-D model. Are you describing a situation where a protocol X is carried over ATM in A and B and carried over MPLS in C and D? If so, then I believe that this is another example of service interworking and PWE3 does not apply. (Or, PWE3 could apply, but then the MPLS core would carry X-over-ATM instead of just X) I was told that the IETF is not interested in standardizing service interworking. Is that correct? Service interworking is an important element in the evolution towards a common MPLS core. AFAIK, both the MPLS Forum and the Metro Ethernet Forum started working on it. Peter > -----Original Message----- > From: Chris Liljenstolpe [mailto:chris@cw.net] > Sent: Thursday, May 08, 2003 5:24 PM > To: neil.2.harrison@bt.com; mustapha.aissaoui@alcatel.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > There is an issue here that needs to be addressed, however. > > If the PWE implimentation is > > A---C---A where A is a PWE3 aware ATM switch, and C is an > MPLS core, then > native signaling (i.e. PNNI) will work (C looks just like a circuit). > However, if the case is > > A---B---C----D where B is an ATM core, and D is an MPLS MSE (running > PWE3), then we have a problem in signaling and recovering > from faults at > the BC boundary. This is a problem that will hinder MSE > deployment at > carriers with deployed classical networks that need to > interoperate them > with new model systems. > > Chris > > > - --It is whispered that on 2003-05-08 21:59 +0100, > neil.2.harrison@bt.com > mumbled this regarding RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough > Consesus?) > > > Thanks Mustapha....excellent responses, you have clearly a > good grip on > > this stuff. > > > > My remarks/answers are below....snipped as necessary. regards, Neil > > > >> > > the current scope of the PWE3 working group is to > provide for a PW > >> > > between two endpoints of the same type (e.g., > FR-MPLS-FR). In this > >> > > environment, the native service OAM and link management > >> achieves all > >> > > what is needed and we do not need to define a specific PW OAM. > >> > NH=> Absolutely correct.....when I want to interwork > >> ATM/MPLS say there is > >> > not need whatsover for PW OAM, but further there is no need > >> for PWs at all! > >> > >> You raise an important question which I believe deserves much > >> attention. > > NH=> Yes indeed. Think about the large ATM networks trad > operators have. > > They need a next generation core. ATM/MPLS interworking is > pretty high > > on the agenda here. And it has nothing to do with PWs, let > alone PW OAM > > stuff. > > > >> Is a PW layer a regular MPLS layer or not. > > NH=> No it can't be. It sits above the MPLS layer in its own > > 'in-between' layer world. Also note this: > > Tom makes a big thing that Y.1711 is broken for LDP....its > p2p, but so > > is PW OAM. But, because LDP mp2p uses merging based on a co pkt-sw > > forwarding mode you *always* must have p2p LSPs above this > to effect the > > demerging (ie the p2p 'martini' LSPs for want of a better > term). So why > > not run Y.1711 on these! Pretty obvious solution I think. > So even with > > the LDP mp2p stuff in the X/MPLS case there is always the > possiblility > > to use the simple Y.1711 stuff on the higher p2p LSPs. And if these > > show a problem one can then roll-out the heavy-weight 'Leatherman' > > LSP-Ping toolbox (bit bigger than a swiss army knife!) at leisure to > > look at the mp2p layers *iff* any lower L1 layers don't show any > > problems. So I see next to no justification at all for the > PW OAM stuff > > in the X/MPLS case. As I also remarked, we are going to > have to manage > > the client/server layers anyway....so let's do it at least > as well as > > possible. > > > > > >> Apart from the important question of whether a PW layer is a MPLS > >> layer, > > NH=> It is not. > > > >> the rest is not different from FR-ATM service interworking > >> (FRF.8.1). In the latter case, you can carry a bridged or > routed PDU > >> across these 2 L2 networks. In fact you can carry a mix of > protocols > >> over the same VC. > > NH=> Agreed. Let's keep the layers to a min and do things > right....at > > some point we simply have to say 'we have had enough > kludges thanks'. > >> > >> > >> > > and we want them to > >> > > share the same path in the presence of ECMP. A PW can > also carry > >> > > both a end-user bridged and a routed PDU (multiprotocol PW). > >> > NH=> Whoa! You have just changed the service-interworking > >> case into a > >> > (partial) client/server case....in the former the etherent > >> component is > >> > simply a server layer access partition (terminates at the > >> IWF) but now you > >> > are describing the case where the ethernet pkts have to be > >> carried across > >> > all intervening networks....so, for example, it could be > >> that ethernet is > >> > client to both MPLS and ATM partitions say, but the MPLS > >> and ATM partitions > >> > are using service interworking. As I noted previously, if > >> you draw out the > >> > G.805 relationships this would be much clearer. > >> > >> I do not understand your point here. If I want to carry a higher > >> layer protocol PDU over a Ethernet-(PE1)-MPLS-(PE2)-ATM network, I > >> can do it in three different ways: > >> a. Extend Ethernet over MPLS (network interworking) to the PE2 and > >> then perform Ethernet-ATM service interworking there. > >> b. Extend ATM over MPLS (network interworking) to PE1 and then > >> perform Ethernet-ATM service interowrking there. > >> c. Terminate ATM and Ethernet locally at each PE and perform 2 > >> service interworking functions, one at PE1 (Ethernet-MPLS), the > >> other at PE2 (ATM-MPLS). > >> > >> It is clear to me that in (a) and (b), OAM messages of either the > >> Ethernet layer or the ATM layer need to be carried in the > inner LSP. > >> It is not the case in (c), since both ATM and Ethernet are > >> terminated. Are we saying the same thing? > > NH=> Yes we are....its clear you understand....that make me > feel far more > > comfortable. > >> > >> > > This is > >> > > where the MPLS/PW PID is useful but it should be > >> addressed in a much > >> > > wider scope than the current PWE3 issues. > >> > NH=> Please note this observation: A PID field is only > >> required to identify > >> > the *clients* of a given layer network when these can > >> change over the life > >> > of the (server) layer trail. In G.805 terms this is describing a > >> > multiplexing function that is related to the adaptation of > >> the client signal > >> > into the payload of the server signal. Each layer network > >> however, should > >> > have its own native OAM that is *independent* of any higher > >> client layer. > >> > That is, the PID field and the layer network's native OAM > >> are *not* in any > >> > way related (and the PID function sits above the OAM > >> > functionally).....putting this is very plain terms, the > >> *client* PID field > >> > should not be used to identify OAM pkts. > >> > >> I agree with you on this point. The PID is in principle an > >> identifier of the higher layer protocol, not of the OAM messages of > >> the layer below it. > > NH=> Thanks. Let's make sure we avoid this kludge then. Let's keep > > trying to move things to a sound arch basis. > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > - -- > Chris Liljenstolpe > GPG keys: http://www.io.com/~cds/cdl-keys.asc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (Darwin) > > iD8DBQE+usr0HhGWzf9XZ/YRAsODAJ9X8aVv401aKbAfsZcsrdQR5ZXOYgCfbS3a > y4FiSS7/maf5zIcC6Mgieu8= > =r7DP > -----END PGP SIGNATURE----- > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Himanshu Shah" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 9 May 2003 10:36:59 -0400 Lines: 254 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Fri May 09 16:41:41 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) Thread-Index: AcMWNrxVoQRsszvkSY2wQ+5YUnzNLQAAI3RQ To: "Busschbach, Peter B (Peter)" , "Chris Liljenstolpe" , , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h49Ej9812771 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yep, we tried unsuccessfully for service interworking in PPVPN. Metro E and MPLS forum is now working on this. However, I am hopeful that with PPVPN evolving with new groups and 'mgmt', we can make a case for importance of this subject again. /himanshu Wavesmith Networks > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Friday, May 09, 2003 9:57 AM > To: 'Chris Liljenstolpe'; neil.2.harrison@bt.com; > mustapha.aissaoui@alcatel.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Chris, > > I am not sure I fully understand your A-B-C-D model. Are you > describing a situation where a protocol X is carried over ATM > in A and B and carried over MPLS in C and D? > > If so, then I believe that this is another example of service > interworking and PWE3 does not apply. (Or, PWE3 could apply, > but then the MPLS core would carry X-over-ATM instead of just X) > > I was told that the IETF is not interested in standardizing > service interworking. Is that correct? > > Service interworking is an important element in the evolution > towards a common MPLS core. AFAIK, both the MPLS Forum and > the Metro Ethernet Forum started working on it. > > Peter > > > -----Original Message----- > > From: Chris Liljenstolpe [mailto:chris@cw.net] > > Sent: Thursday, May 08, 2003 5:24 PM > > To: neil.2.harrison@bt.com; mustapha.aissaoui@alcatel.com > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > There is an issue here that needs to be addressed, however. > > > > If the PWE implimentation is > > > > A---C---A where A is a PWE3 aware ATM switch, and C is an > > MPLS core, then > > native signaling (i.e. PNNI) will work (C looks just like a > circuit). > > However, if the case is > > > > A---B---C----D where B is an ATM core, and D is an MPLS MSE > (running > > PWE3), then we have a problem in signaling and recovering > > from faults at > > the BC boundary. This is a problem that will hinder MSE > > deployment at > > carriers with deployed classical networks that need to > > interoperate them > > with new model systems. > > > > Chris > > > > > > - --It is whispered that on 2003-05-08 21:59 +0100, > > neil.2.harrison@bt.com > > mumbled this regarding RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough > > Consesus?) > > > > > Thanks Mustapha....excellent responses, you have clearly a > > good grip on > > > this stuff. > > > > > > My remarks/answers are below....snipped as necessary. > regards, Neil > > > > > >> > > the current scope of the PWE3 working group is to > > provide for a PW > > >> > > between two endpoints of the same type (e.g., > > FR-MPLS-FR). In this > > >> > > environment, the native service OAM and link management > > >> achieves all > > >> > > what is needed and we do not need to define a > specific PW OAM. > > >> > NH=> Absolutely correct.....when I want to interwork > > >> ATM/MPLS say there is > > >> > not need whatsover for PW OAM, but further there is no need > > >> for PWs at all! > > >> > > >> You raise an important question which I believe deserves much > > >> attention. > > > NH=> Yes indeed. Think about the large ATM networks trad > > operators have. > > > They need a next generation core. ATM/MPLS interworking is > > pretty high > > > on the agenda here. And it has nothing to do with PWs, let > > alone PW OAM > > > stuff. > > > > > >> Is a PW layer a regular MPLS layer or not. > > > NH=> No it can't be. It sits above the MPLS layer in its own > > > 'in-between' layer world. Also note this: > > > Tom makes a big thing that Y.1711 is broken for LDP....its > > p2p, but so > > > is PW OAM. But, because LDP mp2p uses merging based on a > co pkt-sw > > > forwarding mode you *always* must have p2p LSPs above this > > to effect the > > > demerging (ie the p2p 'martini' LSPs for want of a better > > term). So why > > > not run Y.1711 on these! Pretty obvious solution I think. > > So even with > > > the LDP mp2p stuff in the X/MPLS case there is always the > > possiblility > > > to use the simple Y.1711 stuff on the higher p2p LSPs. > And if these > > > show a problem one can then roll-out the heavy-weight 'Leatherman' > > > LSP-Ping toolbox (bit bigger than a swiss army knife!) at > leisure to > > > look at the mp2p layers *iff* any lower L1 layers don't show any > > > problems. So I see next to no justification at all for the > > PW OAM stuff > > > in the X/MPLS case. As I also remarked, we are going to > > have to manage > > > the client/server layers anyway....so let's do it at least > > as well as > > > possible. > > > > > > > > >> Apart from the important question of whether a PW layer is a MPLS > > >> layer, > > > NH=> It is not. > > > > > >> the rest is not different from FR-ATM service interworking > > >> (FRF.8.1). In the latter case, you can carry a bridged or > > routed PDU > > >> across these 2 L2 networks. In fact you can carry a mix of > > protocols > > >> over the same VC. > > > NH=> Agreed. Let's keep the layers to a min and do things > > right....at > > > some point we simply have to say 'we have had enough > > kludges thanks'. > > >> > > >> > > >> > > and we want them to > > >> > > share the same path in the presence of ECMP. A PW can > > also carry > > >> > > both a end-user bridged and a routed PDU (multiprotocol PW). > > >> > NH=> Whoa! You have just changed the service-interworking > > >> case into a > > >> > (partial) client/server case....in the former the etherent > > >> component is > > >> > simply a server layer access partition (terminates at the > > >> IWF) but now you > > >> > are describing the case where the ethernet pkts have to be > > >> carried across > > >> > all intervening networks....so, for example, it could be > > >> that ethernet is > > >> > client to both MPLS and ATM partitions say, but the MPLS > > >> and ATM partitions > > >> > are using service interworking. As I noted previously, if > > >> you draw out the > > >> > G.805 relationships this would be much clearer. > > >> > > >> I do not understand your point here. If I want to carry a higher > > >> layer protocol PDU over a Ethernet-(PE1)-MPLS-(PE2)-ATM > network, I > > >> can do it in three different ways: > > >> a. Extend Ethernet over MPLS (network interworking) to > the PE2 and > > >> then perform Ethernet-ATM service interworking there. > > >> b. Extend ATM over MPLS (network interworking) to PE1 and then > > >> perform Ethernet-ATM service interowrking there. > > >> c. Terminate ATM and Ethernet locally at each PE and perform 2 > > >> service interworking functions, one at PE1 (Ethernet-MPLS), the > > >> other at PE2 (ATM-MPLS). > > >> > > >> It is clear to me that in (a) and (b), OAM messages of either the > > >> Ethernet layer or the ATM layer need to be carried in the > > inner LSP. > > >> It is not the case in (c), since both ATM and Ethernet are > > >> terminated. Are we saying the same thing? > > > NH=> Yes we are....its clear you understand....that make me > > feel far more > > > comfortable. > > >> > > >> > > This is > > >> > > where the MPLS/PW PID is useful but it should be > > >> addressed in a much > > >> > > wider scope than the current PWE3 issues. > > >> > NH=> Please note this observation: A PID field is only > > >> required to identify > > >> > the *clients* of a given layer network when these can > > >> change over the life > > >> > of the (server) layer trail. In G.805 terms this is > describing a > > >> > multiplexing function that is related to the adaptation of > > >> the client signal > > >> > into the payload of the server signal. Each layer network > > >> however, should > > >> > have its own native OAM that is *independent* of any higher > > >> client layer. > > >> > That is, the PID field and the layer network's native OAM > > >> are *not* in any > > >> > way related (and the PID function sits above the OAM > > >> > functionally).....putting this is very plain terms, the > > >> *client* PID field > > >> > should not be used to identify OAM pkts. > > >> > > >> I agree with you on this point. The PID is in principle an > > >> identifier of the higher layer protocol, not of the OAM > messages of > > >> the layer below it. > > > NH=> Thanks. Let's make sure we avoid this kludge then. > Let's keep > > > trying to move things to a sound arch basis. > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > - -- > > Chris Liljenstolpe > > GPG keys: http://www.io.com/~cds/cdl-keys.asc > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.1 (Darwin) > > > > iD8DBQE+usr0HhGWzf9XZ/YRAsODAJ9X8aVv401aKbAfsZcsrdQR5ZXOYgCfbS3a > > y4FiSS7/maf5zIcC6Mgieu8= > > =r7DP > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 09 May 2003 10:39:02 -0400 Organization: Alcatel Networks Corporaton Lines: 45 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6820@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tnadeau@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 09 16:42:58 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: neil.2.harrison@bt.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, neil.2.harrison@bt.com wrote: > Tom, > > > > One point below. > > > > NH=> Please note this observation: A PID field is only > > required to > > > > identify the *clients* of a given layer network when these > > > can change > > > > over the life of the (server) layer trail. In G.805 > > terms this is > > > > describing a multiplexing function that is related to the > > > adaptation > > > > of the client signal into the payload of the server signal. Each > > > > layer network however, should have its own native OAM that is > > > > *independent* of any higher client layer. That is, the PID > > > field and > > > > the layer network's native OAM are *not* in any way related > > > (and the > > > > PID function sits above the OAM functionally).....putting > > > this is very > > > > plain terms, the *client* PID field should not be used to > > > identify OAM > > > > pkts. > > > > > > I agree with you on this point. The PID is in principle an > > > identifier of the higher layer protocol, not of the OAM > > > messages of the layer below it. > NH=> Not quite right Mustapha. You are right it should never indicate the > OAM of a layer *below* the one in question, but I was also trying to point > out it should also never indicate the *same* layer OAM, ie the PID field in > a given layer network indicates the *clinet* carried....the OAM of the layer > in question occurs functionally *below* this in the adpatation process, and > is an intrinsic property of the layer per se *irrespective* of the client it > carries. Re-read what I wrote above carefully and think about a G.805 > functional model of what is going on here. If there are any G.805 experts > reading this then please chip-in and confirm my comments. I think my wording of it was incorrect. Indeed, the concept of PID indicates the higher layer protocol carried in this layer's PDU. This layer's OAM should be identifiable at this layer independently of any higher layer protocol running over it. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 09 May 2003 10:56:18 -0400 Organization: Alcatel Networks Corporaton Lines: 38 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D681C@i2km07-ukbr.domain1.s ystemhost.net> <2147483647.1052414642@[204.29.150.22]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: neil.2.harrison@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 09 16:58:17 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Chris Liljenstolpe Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Chris, Chris Liljenstolpe wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > There is an issue here that needs to be addressed, however. > > If the PWE implimentation is > > A---C---A where A is a PWE3 aware ATM switch, and C is an MPLS core, then > native signaling (i.e. PNNI) will work (C looks just like a circuit). > However, if the case is > > A---B---C----D where B is an ATM core, and D is an MPLS MSE (running > PWE3), then we have a problem in signaling and recovering from faults at > the BC boundary. This is a problem that will hinder MSE deployment at > carriers with deployed classical networks that need to interoperate them > with new model systems. I believe we have two options here: 1. If D can terminate ATM over MPLS, one can model the full ABCD path as a VCC. You can extend a PNNI SPVC towards D and you have got now a protected path. The ATM Forum is finalizing the extended PNNI specification in order to achieve that. Note here that only the MSE, not the core LSRs, need to participate in PNNI signaling and routing. 2. If D cannot terminate ATM over MPLS, or if one wants to use target LDP signaling between C and D, then you have got to coordinate the operation and failure recovery of the PNNI domain and the p2p LDP domain. This could be done either through a management system, or through a signaling interworking function. All I can say is that option 1 is the most straightforward way to do it currently, given the availability of the standards. Option 2 is an attractive longer term solution. If there is enough interest, this could be done as a joint work with the ATM Forum. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 09 May 2003 11:23:12 -0400 Lines: 25 Sender: pwe3-admin@ietf.org References: <3EBBBD86.E9602843@alcatel.com> Cc: neil.2.harrison@bt.com, tnadeau@cisco.com, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Fri May 09 17:26:53 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Mustapha Aissaoui In-reply-to: Your message of "Fri, 09 May 2003 10:39:02 EDT." <3EBBBD86.E9602843@alcatel.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I think my wording of it was incorrect. Indeed, the concept of PID indicates the > higher layer protocol carried in this layer's PDU. This layer's OAM should be > identifiable at this layer independently of any higher layer protocol running > over it. Here's the model I have in mind. It's exactly analogous to SONET/SDH -> DCC -> NLPID You have in the first Nibble an indication (0000 or 0001) of whether this packet belongs to the data flow or the DCC. If its part of the DCC then you have a PID which indicates the protocol carried in the DCC. Then you get your IP packet (or whatever you indicate). But it's a channel associated with the PW and *nothing more*. The DCC is bound to the control entities at the ends of a PW. It's there for those control entites at each end of a PW to communicate. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 9 May 2003 09:23:01 -0700 Lines: 55 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: neil.2.harrison@bt.com, tnadeau@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 09 18:25:50 2003 Return-path: To: "'George Swallow'" , Mustapha Aissaoui X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is not like DCC at all. A DCC is part of every frame which carries DCC traffic alongside user traffic inside the same frame. While your proposal cannot carry both user traffic and DCC traffic in a single packet. In fact your proposed DCC has no rate associated with it and can actually occupy the whole available user BW. I would categorize it more as in-band OAM indicator. But to be an in-band OAM indicator, this Nibble (or word) MUST be present after all bottom labels including those that carry IP user traffic. Why? because or two reasons: 1) Consistency and compatibility. For example consider the case of spliced PWs that Eric has raised. What happens if a SP uses this nibble/word and another one doesn't? 2) It is needed for IP payload (such as L3VPN) to test proper actual FEC to NHLFE mapping, which can't be done with LSP-ping, because LSP-ping does not get as close to the disposition point as the in-band OAM. -Shahram >> I think my wording of it was incorrect. Indeed, the concept >of PID indicates the >> higher layer protocol carried in this layer's PDU. This >layer's OAM should be >> identifiable at this layer independently of any higher layer >protocol running >> over it. > >Here's the model I have in mind. It's exactly analogous to > > SONET/SDH -> DCC -> NLPID > >You have in the first Nibble an indication (0000 or 0001) of whether >this packet belongs to the data flow or the DCC. If its part of the >DCC then you have a PID which indicates the protocol carried in the >DCC. > >Then you get your IP packet (or whatever you indicate). But it's a >channel associated with the PW and *nothing more*. The DCC is bound >to the control entities at the ends of a PW. It's there for those >control entites at each end of a PW to communicate. > >...George > >=============================================================== >========= >George Swallow Cisco Systems >(978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 09 May 2003 12:46:16 -0400 Lines: 38 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C93D@nt-exch-yow.pmc-sierra.bc.ca> Cc: "'George Swallow'" , Mustapha Aissaoui , neil.2.harrison@bt.com, tnadeau@cisco.com, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Fri May 09 18:54:34 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari In-reply-to: Your message of "Fri, 09 May 2003 09:23:01 PDT." <4B6D09F3B826D411A67300D0B706EFDE0115C93D@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > This is not like DCC at all. A DCC is part of every frame which carries > DCC traffic alongside user traffic inside the same frame. While your > proposal cannot carry both user traffic and DCC traffic in a single > packet. In fact your proposed DCC has no rate associated with it > and can actually occupy the whole available user BW. That just because of how you have to do the framing for SONET. > I would categorize it more as in-band OAM indicator. But to be an in-band OAM > indicator, this Nibble (or word) MUST be present after all bottom labels > including those that carry IP user traffic. Why? because or two reasons: Don't really care what it gets called. In fact I call it "in-band OAM indicator". I'm only saying that it is analogous to DCC > 1) Consistency and compatibility. For example consider the case of > spliced PWs that Eric has raised. What happens if a SP uses this > nibble/word and another one doesn't? Since you signal the use of this with each PW you don't have a problem. Just don't splice unlike things together. Not that I think splicing is a good idea. Different SPs are going to want to be able to certify whether their piece is working or not. So I would terminate the OAM at the edge. > 2) It is needed for IP payload (such as L3VPN) to test proper actual > FEC to NHLFE mapping, which can't be done with LSP-ping, because > LSP-ping does not get as close to the disposition point as the in-band > OAM. LSP Ping goes further. So what's the issue? ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Alex Zinin Subject: Re: IMPORTANT: Strategy for VPN work in IETF Date: Fri, 9 May 2003 10:35:19 -0700 Lines: 75 References: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> Reply-To: Alex Zinin Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , Thomas Narten , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Fri May 09 19:38:07 2003 Return-path: X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) To: "Paul Knight" In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF05A388C8@zbl6c004.corpeast.baynetworks.com> X-SMTP-HELO: psg.com X-SMTP-MAIL-FROM: zinin@psg.com X-SMTP-RCPT-TO: paul.knight@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: psg.com [147.28.0.62] Status: O Hi, Paul, > The proposed split seems to put very little emphasis on the "PP" of PPVPN. > The proposed focus on technologies for L2 and L3 is likely to seriously > disrupt the focus on the "Provider Provisioned" concept, where much of the > value comes from aiming for interoperation across all major VPN > technologies. Of course, we could have PPL2VPN and PPL3VPN, but as has been > pointed out, we then need to coordinate the "PP" parts across the two WGs. I think before we go and talk about interoperation across all major VPN technologies, we should first make visible progress on those technologies, which focused technology specific WGs are aimed to help. Regarding coordination--totally agree, we will indeed need to coordinate, we actually have an idea for this--create a PPVPN directorate that will ensure such close coordination. > VPN customers want a bundle of VPN services, and don't really care whether > it is L2 or L3 (or L1) or some mixture. VPN service providers want an > interoperable toolkit which they can use to design services that they can > differentiate in various ways to attract VPN customers. PPVPN is providing a > forum to define the operation of the VPN tools. Regardless of L2 or L3 > technologies, there is a need for simple and interoperable mechanisms for > VPN membership and discovery, security considerations, SLA verification, and > a host of management areas. These mechanisms are being defined, clarified, > and debated in PPVPN mostly without regard to the specific L2 or L3 > approaches. They should not be either dropped, or split across two WGs. I don't think anyone suggests to drop those. First, we are not splitting the community, only the WGs as organizational entities to help scaling the management part of the process. People should still talk to each other and discuss those. If folks believe something common for both WGs needs to be worked on, we'll put it in one of the WGs and will inform the other. Occasionally we can even have joint meetings, which happens in the IETF. It seems to me that at this moment, technology-specific work items should be high priority. Most of those pieces are not through the system yet. > Yes there is a lot of work in the group, but if it gets fragmented and > things slip through the cracks, then we will be forcing the VPN service > providers, vendors, and customers to do much more work and spend much more > time in the long run. > In terms of meeting logistics, we will find that many of the same people > will be attending and developing drafts for the proposed L2 and L3 WGs, so > we will have to make sure that they don't overlap... Just the same as if we > plan extended meeting times for the current PPVPN when it is needed. Same people attending different WGs is perfectly fine, this is a normal situation in the IETF (examples: RTG WGs, CCAMP and MPLS). Scheduling-wise, +1 WG is not going to make a big difference. > Finally, I'm closely involved with two areas of work in L3 VPNs in PPVPN, > and we are getting to the point where much of the basic work is stable, so > the L3VPN may not justify a dedicated WG for much longer, although it does > need a WG in which to operate. Lack of "heated" discussions does not mean everything is done. There are items that just need consistent attention and concentration of the participants to be finished, such as security or MIBs. There is also more stuff coming in the L3 space. > I would suggest planning for a longer meeting in Vienna (if the agenda > justifies it) and bringing this proposal up for discussion there. Noted. Alex From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 9 May 2003 19:03:58 +0100 Lines: 75 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: mustapha.aissaoui@alcatel.com, tnadeau@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 09 20:12:54 2003 Return-path: To: swallow@cisco.com, Shahram_Davari@pmc-sierra.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I've passed this across to our SDH and functional modelling guys to formally comment if they disagree with my remarks....but I don't see the relevance/connection. The DCC is a logically disjoint data-plane network (from that carrying traffic) that carries management/control protocols for SDH nodes....it has nothing to do with the traffic carrying data-plane(s) in SDH [there are more than 1, per VC type of layer network]. The notion of a PID here therefore means nothing to me in the context of my orginal observations wrt to where a PID field sits (and it's role) within the data-plane structure of a traffic carrying layer network wrt G.805. Further, in a co cct-sw network like SDH there is never a PID in the traffic's data-plane AFAIK....so the only valid context is in relation to a co pkt-sw mode. I therefore consider that my orginal observations, which elicited these remarks, remain valid as stated. regards, Neil > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: 09 May 2003 17:46 > To: Shahram Davari > Cc: 'George Swallow'; Mustapha Aissaoui; Harrison,N,Neil,IKL2 R; > tnadeau@cisco.com; pwe3@ietf.org; swallow@cisco.com > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > This is not like DCC at all. A DCC is part of every frame > which carries > > DCC traffic alongside user traffic inside the same frame. > While your > > proposal cannot carry both user traffic and DCC traffic in a single > > packet. In fact your proposed DCC has no rate associated with it > > and can actually occupy the whole available user BW. > > That just because of how you have to do the framing for SONET. > > > I would categorize it more as in-band OAM indicator. But to > be an in-band OAM > > indicator, this Nibble (or word) MUST be present after all > bottom labels > > including those that carry IP user traffic. Why? because or > two reasons: > > Don't really care what it gets called. In fact I call it "in-band OAM > indicator". I'm only saying that it is analogous to DCC > > > 1) Consistency and compatibility. For example consider the case of > > spliced PWs that Eric has raised. What happens if a SP uses this > > nibble/word and another one doesn't? > > Since you signal the use of this with each PW you don't have a > problem. Just don't splice unlike things together. Not that I think > splicing is a good idea. Different SPs are going to want to be able > to certify whether their piece is working or not. So I would > terminate the OAM at the edge. > > > 2) It is needed for IP payload (such as L3VPN) to test proper actual > > FEC to NHLFE mapping, which can't be done with LSP-ping, because > > LSP-ping does not get as close to the disposition point as > the in-band > > OAM. > > LSP Ping goes further. So what's the issue? > > ...George > > ============================================================== > ========== > George Swallow Cisco Systems > (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 9 May 2003 14:13:17 -0400 Organization: Cisco Systems, Inc. Lines: 104 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D683E@i2km07-ukbr.domain1.systemhost.net> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , X-From: pwe3-admin@ietf.org Fri May 09 20:17:07 2003 Return-path: To: , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D683E@i2km07-ukbr.domain1.systemhost.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I still don't see why this matters. Call the field what you wish or whatever layer you want to cram it into, but from the OAM perspective, the PID is only a means by which end points can identify in-line OAM messages. --Tom > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Friday, May 09, 2003 2:04 PM > To: swallow@cisco.com; Shahram_Davari@pmc-sierra.com > Cc: mustapha.aissaoui@alcatel.com; tnadeau@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > I've passed this across to our SDH and functional modelling > guys to formally comment if they disagree with my > remarks....but I don't see the relevance/connection. The DCC > is a logically disjoint data-plane network (from that > carrying traffic) that carries management/control protocols > for SDH nodes....it has nothing to do with the traffic > carrying data-plane(s) in SDH [there are more than 1, per VC > type of layer network]. The notion of a PID here therefore > means nothing to me in the context of my orginal observations > wrt to where a PID field sits (and it's role) within the > data-plane structure of a traffic carrying layer network wrt > G.805. Further, in a co cct-sw network like SDH there is > never a PID in the traffic's data-plane AFAIK....so the only > valid context is in relation to a co pkt-sw mode. > > I therefore consider that my orginal observations, which > elicited these remarks, remain valid as stated. > > regards, Neil > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: 09 May 2003 17:46 > > To: Shahram Davari > > Cc: 'George Swallow'; Mustapha Aissaoui; Harrison,N,Neil,IKL2 R; > > tnadeau@cisco.com; pwe3@ietf.org; swallow@cisco.com > > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > > This is not like DCC at all. A DCC is part of every frame > > which carries > > > DCC traffic alongside user traffic inside the same frame. > > While your > > > proposal cannot carry both user traffic and DCC traffic > in a single > > > packet. In fact your proposed DCC has no rate associated > with it and > > > can actually occupy the whole available user BW. > > > > That just because of how you have to do the framing for SONET. > > > > > I would categorize it more as in-band OAM indicator. But to > > be an in-band OAM > > > indicator, this Nibble (or word) MUST be present after all > > bottom labels > > > including those that carry IP user traffic. Why? because or > > two reasons: > > > > Don't really care what it gets called. In fact I call it > "in-band OAM > > indicator". I'm only saying that it is analogous to DCC > > > > > 1) Consistency and compatibility. For example consider > the case of > > > spliced PWs that Eric has raised. What happens if a SP uses this > > > nibble/word and another one doesn't? > > > > Since you signal the use of this with each PW you don't have a > > problem. Just don't splice unlike things together. Not > that I think > > splicing is a good idea. Different SPs are going to want > to be able > > to certify whether their piece is working or not. So I would > > terminate the OAM at the edge. > > > > > 2) It is needed for IP payload (such as L3VPN) to test > proper actual > > > FEC to NHLFE mapping, which can't be done with LSP-ping, because > > > LSP-ping does not get as close to the disposition point as > > the in-band > > > OAM. > > > > LSP Ping goes further. So what's the issue? > > > > ...George > > > > ============================================================== > > ========== > > George Swallow Cisco Systems > > (978) 936-1398 > > 1414 Massachusetts Avenue > > Boxborough, MA 01719 > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 9 May 2003 12:26:28 -0700 Lines: 122 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: mustapha.aissaoui@alcatel.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 09 21:29:25 2003 Return-path: To: "'tnadeau@cisco.com'" , neil.2.harrison@bt.com, swallow@cisco.com X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O If the protocol stack is: PSN layer - Muxing layer - CW - Payload Which layer will this OAM test? -Shahram >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Friday, May 09, 2003 2:13 PM >To: neil.2.harrison@bt.com; swallow@cisco.com; Shahram Davari >Cc: mustapha.aissaoui@alcatel.com; pwe3@ietf.org >Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > I still don't see why this matters. Call >the field what you wish or whatever layer you >want to cram it into, but from the OAM >perspective, the PID is only a means by >which end points can identify in-line OAM >messages. > > --Tom > > >> -----Original Message----- >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: Friday, May 09, 2003 2:04 PM >> To: swallow@cisco.com; Shahram_Davari@pmc-sierra.com >> Cc: mustapha.aissaoui@alcatel.com; tnadeau@cisco.com; pwe3@ietf.org >> Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) >> >> >> I've passed this across to our SDH and functional modelling >> guys to formally comment if they disagree with my >> remarks....but I don't see the relevance/connection. The DCC >> is a logically disjoint data-plane network (from that >> carrying traffic) that carries management/control protocols >> for SDH nodes....it has nothing to do with the traffic >> carrying data-plane(s) in SDH [there are more than 1, per VC >> type of layer network]. The notion of a PID here therefore >> means nothing to me in the context of my orginal observations >> wrt to where a PID field sits (and it's role) within the >> data-plane structure of a traffic carrying layer network wrt >> G.805. Further, in a co cct-sw network like SDH there is >> never a PID in the traffic's data-plane AFAIK....so the only >> valid context is in relation to a co pkt-sw mode. >> >> I therefore consider that my orginal observations, which >> elicited these remarks, remain valid as stated. >> >> regards, Neil >> >> > -----Original Message----- >> > From: George Swallow [mailto:swallow@cisco.com] >> > Sent: 09 May 2003 17:46 >> > To: Shahram Davari >> > Cc: 'George Swallow'; Mustapha Aissaoui; Harrison,N,Neil,IKL2 R; >> > tnadeau@cisco.com; pwe3@ietf.org; swallow@cisco.com >> > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) >> > >> > >> > > This is not like DCC at all. A DCC is part of every frame >> > which carries >> > > DCC traffic alongside user traffic inside the same frame. >> > While your >> > > proposal cannot carry both user traffic and DCC traffic >> in a single >> > > packet. In fact your proposed DCC has no rate associated >> with it and >> > > can actually occupy the whole available user BW. >> > >> > That just because of how you have to do the framing for SONET. >> > >> > > I would categorize it more as in-band OAM indicator. But to >> > be an in-band OAM >> > > indicator, this Nibble (or word) MUST be present after all >> > bottom labels >> > > including those that carry IP user traffic. Why? because or >> > two reasons: >> > >> > Don't really care what it gets called. In fact I call it >> "in-band OAM >> > indicator". I'm only saying that it is analogous to DCC >> > >> > > 1) Consistency and compatibility. For example consider >> the case of >> > > spliced PWs that Eric has raised. What happens if a SP uses this >> > > nibble/word and another one doesn't? >> > >> > Since you signal the use of this with each PW you don't have a >> > problem. Just don't splice unlike things together. Not >> that I think >> > splicing is a good idea. Different SPs are going to want >> to be able >> > to certify whether their piece is working or not. So I would >> > terminate the OAM at the edge. >> > >> > > 2) It is needed for IP payload (such as L3VPN) to test >> proper actual >> > > FEC to NHLFE mapping, which can't be done with LSP-ping, because >> > > LSP-ping does not get as close to the disposition point as >> > the in-band >> > > OAM. >> > >> > LSP Ping goes further. So what's the issue? >> > >> > ...George >> > >> > ============================================================== >> > ========== >> > George Swallow Cisco Systems >> > (978) 936-1398 >> > 1414 Massachusetts Avenue >> > Boxborough, MA 01719 >> > >> > >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Fri, 09 May 2003 16:56:50 -0400 Lines: 22 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C941@nt-exch-yow.pmc-sierra.bc.ca> Cc: "'tnadeau@cisco.com'" , neil.2.harrison@bt.com, swallow@cisco.com, mustapha.aissaoui@alcatel.com, pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Fri May 09 22:59:37 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari In-reply-to: Your message of "Fri, 09 May 2003 12:26:28 PDT." <4B6D09F3B826D411A67300D0B706EFDE0115C941@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram - > If the protocol stack is: > > PSN layer - Muxing layer - CW - Payload > > Which layer will this OAM test? You're the one that wants the extra layer. For L3VPNs the stack is: PSN -> VPN Label -> User Packet or LSP Ping. It tests at the user VPN level which is just what you want. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Danny McPherson Subject: Re: TTL value of VC Label? Date: Fri, 09 May 2003 15:23:13 -0600 Lines: 12 Sender: pwe3-admin@ietf.org References: <3EB97F7F.9020607@level3.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri May 09 23:26:26 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: In-Reply-To: <3EB97F7F.9020607@level3.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O On 5/7/03 3:49 PM, "Luca Martini" wrote: > How about this ? > > "The setting of the TTL value in the PW > label is application dependent, however in a strict point to point application > the TTL should be appropriately set to 2" I like this. Does anyone have objections to updating the current document with something along these lines? -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: George Swallow Subject: Re: TTL value of VC Label? Date: Fri, 09 May 2003 17:45:56 -0400 Lines: 17 Sender: pwe3-admin@ietf.org References: Cc: pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Fri May 09 23:55:19 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Danny McPherson In-reply-to: Your message of "Fri, 09 May 2003 15:23:13 MDT." Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > How about this ? > > > > "The setting of the TTL value in the PW > > label is application dependent, however in a strict point to point application > > the TTL should be appropriately set to 2" > > I like this. Does anyone have objections to updating the current document > with something along these lines? Works for me. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: David Zelig Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Sun, 11 May 2003 11:00:16 +0200 Lines: 55 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Sun May 11 10:03:03 2003 Return-path: To: "'Mustapha Aissaoui'" , Shahram Davari X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha, Maybe I was not clear enough in what a customer is: from my point of view it is the ATM entity that is connected through the PW. I am aware that for the simple case you mention you can use a segment ATM OAM, but the PW is applicable also for carrier of carriers scenarios, and even internally to an organization, there is a need for a clear demarcation point. We should be careful to define the PW transparent enough, where in transparency I mean also minimum knowledge is required from the PW provider point of view on the carried signal and the protocols that are used on top of it. David > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Thursday, May 08, 2003 6:43 PM > To: Shahram Davari > Cc: 'David Zelig'; pwe3@ietf.org > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Shahram and David, > > Shahram Davari wrote: > > > > David, > > > > > > > >Shahram, > > >two major points are not solved with the suggestion to use > > >segment OAM of > > >the native signal: > > >1) What happened if the customer is using the segmented OAM > > >over a span that > > >include the PW? > > > > You have a point, but I am not sure why customer wants to run > > segment OAM, rather than end-to-end OAM. > > We need to spearate customer testing from service provider testing. > Assume that we have a simple 3-hop network scenario (CE-PE-PE-CE). > Assume also we have a ATM-MPLS-ATM PW running over this network. > > The customer can test his/her connectivity using an end-to-end OAM > flow. The service provider will pass these cells unaffected provided > that: > a. There was an agreement allowing the customer to inject OAM cells. > b. The aggregate traffic on that connection des not violate the > traffic contract when policing user traffic in the PE. > > The service provider can run a segment OAM flow between the ATM > endpoints of the PW. These points are under his managment. Both the > customer OAM testing and the service provider OAM testing can > operate concurrently. > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Ali Sajassi Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 12 May 2003 01:10:24 -0700 Lines: 56 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C930@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 12 10:15:50 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Shahram Davari , "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C930@nt-exch-yow.pmc-s ierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram, Neil: By going through this email thread regarding OAM for PW, I realized that there are several areas of contentions that need further exploration/clarification. So lets go over them in a bit more details and see where we stand. We all advocate proper layering for PW OAM but we all have different views of what the proper layering should be. One view which I am hearing is that there should be a single OAM mechanism for the whole MPLS (both LSP tunnel and PW) and some people think that PW is an artificial layer that shouldn't have its own OAM. Another view is that PW OAM can be handled by the service layer (e.g., either segment ATM or segment Ethernet or segment Foo) and thus there is no need for the PW to have its own OAM. Lets look at them a bit more closely. First, I think each layer and sub-layer of transport need their own OAM mechanism since they operate independently and the each have different termination points (e.g., I.610 - OAM principles for B-ISDN). So if I have IP over ATM over SONET, there needs to be a OAM for each of these layers and one layer's OAM should not be used to replace another. Second if there are sub-layers within a transport layer, then these sub-layers also need their own OAM because again they can have different termination/disposition points. One example that we are all familiar with is ATM where VC and VP have their own end-to-end and segment OAM and one sub-layer OAM doesn't replace the other. So one can consider an MPLS PW analogous to an ATM VC and an MPLS LSP tunnel analogous to an ATM VP and thus similar to ATM each have their own OAM mechanism because each of these transport sub-layers have different termination/disposition points. Third, using a service layer OAM to replace/compensate for a transport sub-layer OAM is not the right approach for several reasons: A) In ATM network, when you transport FR between two end points over an ATM, you don't use FR OAM in the ATM network to detect/isolate fault but instead you relay on ATM OAM and as the matter of fact FR PVC status relies on the ATM PVC (FRF.5). B) Service layer OAM doesn't give you the right info. For example in a VPLS service, Ethernet OAM ping can span several PWs. Also again for proper layering, Ethernet OAM should be independent from MPLS layer OAM. C) There are cases that the service layer doesn't have an OAM mechanism associated with it - e.g., in case of a transport of routed packets over a PW without L2 layer (refer to draft-sajassi-l2vpn-interworking for different interworking scenarios). There are other reasons of why it is better for PW to have their own OAM mechanism such as the use of common mechanism for interworking between disparate interfaces but there is no need to get into the details right now since the above reasons should be sufficient. So at the end, I think we need to have a mechanism for PW OAM and VCCV as Tom has described it provides such mechanism. -Ali From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 12 May 2003 02:19:02 -0700 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'tnadeau@cisco.com'" , neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 12 11:23:16 2003 Return-path: To: "'George Swallow'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I was asking about PW or L2VPN. -Shahram >-----Original Message----- >From: George Swallow [mailto:swallow@cisco.com] >Sent: Friday, May 09, 2003 4:57 PM >To: Shahram Davari >Cc: 'tnadeau@cisco.com'; neil.2.harrison@bt.com; swallow@cisco.com; >mustapha.aissaoui@alcatel.com; pwe3@ietf.org; swallow@cisco.com >Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > >Shahram - > >> If the protocol stack is: >> >> PSN layer - Muxing layer - CW - Payload >> >> Which layer will this OAM test? > >You're the one that wants the extra layer. > >For L3VPNs the stack is: > >PSN -> VPN Label -> User Packet or LSP Ping. > >It tests at the user VPN level which is just what you want. > >...George > >=============================================================== >========= >George Swallow Cisco Systems >(978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 12 May 2003 03:11:15 -0700 Lines: 119 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 12 12:14:10 2003 Return-path: To: "'Ali Sajassi'" , "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ali, I think you are confusing 2 different points: 1) Each layer's OAM only tests that layer's connectivity. 2) In X over Y layer, in which X is the customer traffic and Y is the service provider tunnel, customer should have its X OAM, and service provider should have its Y OAM. But the service provider cannot test whether his X/Y mapping is done correctly or not without doing segment X OAM. This is required for if provider wants to detect a mapping fault before customer complaints. Now regarding PW, we can test both PSN label and PW label using MPLS OAM. Customer can also test its connection (let's say ATM VC) using ATM OAM. But the only way that provider can check the correct mapping between customer ATM VC to PW label, is by running segment ATM OAM between PEs. VCCV does not help you for doing so. Now please tell me what VCCV can do that the OAMs I described above can't do better. -Shahram >-----Original Message----- >From: Ali Sajassi [mailto:sajassi@cisco.com] >Sent: Monday, May 12, 2003 4:10 AM >To: Shahram Davari; 'tnadeau@cisco.com'; 'Mustapha Aissaoui'; 'David >Allan' >Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson'; >pwe3@ietf.org >Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > >Shahram, Neil: > >By going through this email thread regarding OAM for PW, I >realized that >there are several areas of contentions that need further >exploration/clarification. So lets go over them in a bit more >details and >see where we stand. > > >We all advocate proper layering for PW OAM but we all have >different views >of what the proper layering should be. One view which I am >hearing is that >there should be a single OAM mechanism for the whole MPLS >(both LSP tunnel >and PW) and some people think that PW is an artificial layer >that shouldn't >have its own OAM. Another view is that PW OAM can be handled >by the service >layer (e.g., either segment ATM or segment Ethernet or segment >Foo) and >thus there is no need for the PW to have its own OAM. Lets >look at them a >bit more closely. > >First, I think each layer and sub-layer of transport need >their own OAM >mechanism since they operate independently and the each have different >termination points (e.g., I.610 - OAM principles for B-ISDN). >So if I have >IP over ATM over SONET, there needs to be a OAM for each of >these layers >and one layer's OAM should not be used to replace another. > >Second if there are sub-layers within a transport layer, then these >sub-layers also need their own OAM because again they can have >different >termination/disposition points. One example that we are all >familiar with >is ATM where VC and VP have their own end-to-end and segment >OAM and one >sub-layer OAM doesn't replace the other. So one can consider >an MPLS PW >analogous to an ATM VC and an MPLS LSP tunnel analogous to an >ATM VP and >thus similar to ATM each have their own OAM mechanism because >each of these >transport sub-layers have different termination/disposition points. > >Third, using a service layer OAM to replace/compensate for a transport >sub-layer OAM is not the right approach for several reasons: >A) In ATM network, when you transport FR between two end >points over an >ATM, you don't use FR OAM in the ATM network to detect/isolate >fault but >instead you relay on ATM OAM and as the matter of fact FR PVC status >relies on the ATM PVC (FRF.5). >B) Service layer OAM doesn't give you the right info. For >example in a VPLS >service, Ethernet OAM ping can span several PWs. Also again for proper >layering, Ethernet OAM should be independent from MPLS layer OAM. >C) There are cases that the service layer doesn't have an OAM >mechanism >associated with it - e.g., in case of a transport of routed >packets over a >PW without L2 layer (refer to draft-sajassi-l2vpn-interworking for >different interworking scenarios). > > >There are other reasons of why it is better for PW to have >their own OAM >mechanism such as the use of common mechanism for interworking between >disparate interfaces but there is no need to get into the >details right now >since the above reasons should be sufficient. > >So at the end, I think we need to have a mechanism for PW OAM >and VCCV as >Tom has described it provides such mechanism. > >-Ali > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Eric Rosen Subject: Re: TTL value of VC Label? Date: Mon, 12 May 2003 10:35:04 -0400 Lines: 10 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 12 16:38:58 2003 Return-path: To: Danny McPherson In-reply-to: Your message of Fri, 09 May 2003 15:23:13 -0600. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >> "The setting of the TTL value in the PW label is application dependent, >> however in a strict point to point application the TTL should be >> appropriately set to 2" Danny> I like this. Does anyone have objections to updating the current Danny> document with something along these lines? Just make sure that the document also says what a strict point to point application is and how one knows whether a particular application is a strict point to point application. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Ali Sajassi Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 12 May 2003 09:21:46 -0700 Lines: 142 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C94A@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 12 18:32:04 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Shahram Davari , "'Ali Sajassi'" , "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C94A@nt-exch-yow.pmc-s ierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >1) Each layer's OAM only tests that layer's connectivity. Good, at least we agree that much :-) >2) In X over Y layer, in which X is the customer traffic >and Y is the service provider tunnel, customer should have >its X OAM, and service provider should have its Y OAM. But >the service provider cannot test whether his X/Y mapping >is done correctly or not without doing segment X OAM. This >is required for if provider wants to detect a mapping fault >before customer complaints. Lets make sure we are talking about the same segment and that is the segment between two PEs. There is a one-to-one relationship between PW and attachment circuit in VPWS and PW status can be mapped into AC segment OAM. When, you transport FR over ATM (FRF.5) this is how it is done and ATM PVC status is used (I am not aware of any special FR OAM segment running between the two PEs). Now how is it different for MPLS PW ? Maybe you want to tell me what is done in FRF.5 that cannot be done for FR over MPLS. >Now regarding PW, we can test both PSN label and PW label >using MPLS OAM. Customer can also test its connection (let's >say ATM VC) using ATM OAM. But the only way that provider >can check the correct mapping between customer ATM VC to >PW label, is by running segment ATM OAM between PEs. VCCV >does not help you for doing so. How do you check the mapping between FR VC and ATM VC when you have FRF.5 ? How do you check the mapping between an ATM physical port and a PW when the service is port based ? >Now please tell me what VCCV can do that the OAMs I described above >can't do better. As I said before VCCV for MPLS PW is analogous to ATM VC OAM and LSP OAM is analogous to ATM VP OAM. Now tell me, do you think we only need LSP tunnel OAM and not PW OAM. -Ali >-Shahram > > > >-----Original Message----- > >From: Ali Sajassi [mailto:sajassi@cisco.com] > >Sent: Monday, May 12, 2003 4:10 AM > >To: Shahram Davari; 'tnadeau@cisco.com'; 'Mustapha Aissaoui'; 'David > >Allan' > >Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson'; > >pwe3@ietf.org > >Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > >Shahram, Neil: > > > >By going through this email thread regarding OAM for PW, I > >realized that > >there are several areas of contentions that need further > >exploration/clarification. So lets go over them in a bit more > >details and > >see where we stand. > > > > > >We all advocate proper layering for PW OAM but we all have > >different views > >of what the proper layering should be. One view which I am > >hearing is that > >there should be a single OAM mechanism for the whole MPLS > >(both LSP tunnel > >and PW) and some people think that PW is an artificial layer > >that shouldn't > >have its own OAM. Another view is that PW OAM can be handled > >by the service > >layer (e.g., either segment ATM or segment Ethernet or segment > >Foo) and > >thus there is no need for the PW to have its own OAM. Lets > >look at them a > >bit more closely. > > > >First, I think each layer and sub-layer of transport need > >their own OAM > >mechanism since they operate independently and the each have different > >termination points (e.g., I.610 - OAM principles for B-ISDN). > >So if I have > >IP over ATM over SONET, there needs to be a OAM for each of > >these layers > >and one layer's OAM should not be used to replace another. > > > >Second if there are sub-layers within a transport layer, then these > >sub-layers also need their own OAM because again they can have > >different > >termination/disposition points. One example that we are all > >familiar with > >is ATM where VC and VP have their own end-to-end and segment > >OAM and one > >sub-layer OAM doesn't replace the other. So one can consider > >an MPLS PW > >analogous to an ATM VC and an MPLS LSP tunnel analogous to an > >ATM VP and > >thus similar to ATM each have their own OAM mechanism because > >each of these > >transport sub-layers have different termination/disposition points. > > > >Third, using a service layer OAM to replace/compensate for a transport > >sub-layer OAM is not the right approach for several reasons: > >A) In ATM network, when you transport FR between two end > >points over an > >ATM, you don't use FR OAM in the ATM network to detect/isolate > >fault but > >instead you relay on ATM OAM and as the matter of fact FR PVC status > >relies on the ATM PVC (FRF.5). > >B) Service layer OAM doesn't give you the right info. For > >example in a VPLS > >service, Ethernet OAM ping can span several PWs. Also again for proper > >layering, Ethernet OAM should be independent from MPLS layer OAM. > >C) There are cases that the service layer doesn't have an OAM > >mechanism > >associated with it - e.g., in case of a transport of routed > >packets over a > >PW without L2 layer (refer to draft-sajassi-l2vpn-interworking for > >different interworking scenarios). > > > > > >There are other reasons of why it is better for PW to have > >their own OAM > >mechanism such as the use of common mechanism for interworking between > >disparate interfaces but there is no need to get into the > >details right now > >since the above reasons should be sufficient. > > > >So at the end, I think we need to have a mechanism for PW OAM > >and VCCV as > >Tom has described it provides such mechanism. > > > >-Ali > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 12 May 2003 09:41:31 -0700 Lines: 81 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 12 18:44:05 2003 Return-path: To: "'Ali Sajassi'" , "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ali, >>1) Each layer's OAM only tests that layer's connectivity. > >Good, at least we agree that much :-) Good. > >>2) In X over Y layer, in which X is the customer traffic >>and Y is the service provider tunnel, customer should have >>its X OAM, and service provider should have its Y OAM. But >>the service provider cannot test whether his X/Y mapping >>is done correctly or not without doing segment X OAM. This >>is required for if provider wants to detect a mapping fault >>before customer complaints. > >Lets make sure we are talking about the same segment and that is the >segment between two PEs. There is a one-to-one relationship >between PW and >attachment circuit in VPWS and PW status can be mapped into AC >segment OAM. Correct. >When, you transport FR over ATM (FRF.5) this is how it is done >and ATM PVC >status is used (I am not aware of any special FR OAM segment running >between the two PEs). Now how is it different for MPLS PW ? >Maybe you want >to tell me what is done in FRF.5 that cannot be done for FR over MPLS. FR does not have proper OAM. So we shouldn't base MPLS on deficiencies of FR. > > > >>Now regarding PW, we can test both PSN label and PW label >>using MPLS OAM. Customer can also test its connection (let's >>say ATM VC) using ATM OAM. But the only way that provider >>can check the correct mapping between customer ATM VC to >>PW label, is by running segment ATM OAM between PEs. VCCV >>does not help you for doing so. > >How do you check the mapping between FR VC and ATM VC when you >have FRF.5 ? You can't. FR has poor OAM. >How do you check the mapping between an ATM physical port and >a PW when the >service is port based ? You can use ILM instead. > > >>Now please tell me what VCCV can do that the OAMs I described above >>can't do better. > >As I said before VCCV for MPLS PW is analogous to ATM VC OAM >and LSP OAM is >analogous to ATM VP OAM. Now tell me, do you think we only >need LSP tunnel >OAM and not PW OAM. I didn't say we only need LSP tunnel OAM. I said we can have both LSP tunnel OAM and PW label OAM using LSP-ping or anything else. LSP-ping for the PW label is analogous to ATM VP OAM. And if you needed deeper test you could use ATM segment OAM to test even the mapping of VCs to PW. No you tell me what problems you can detect with VCCV that you can't detect with LSP-ping over the PW label? -Shahram > >-Ali > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 12 May 2003 12:58:25 -0400 Organization: Cisco Systems, Inc. Lines: 110 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C94B@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , X-From: pwe3-admin@ietf.org Mon May 12 19:02:52 2003 Return-path: To: "'Shahram Davari'" , "'Ali Sajassi'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C94B@nt-exch-yow.pmc-sierra.bc.ca> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Monday, May 12, 2003 12:42 PM > To: 'Ali Sajassi'; 'tnadeau@cisco.com'; 'Mustapha Aissaoui'; > 'David Allan' > Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson'; > pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Ali, > > > >>1) Each layer's OAM only tests that layer's connectivity. > > > >Good, at least we agree that much :-) > > Good. > > > > >>2) In X over Y layer, in which X is the customer traffic > >>and Y is the service provider tunnel, customer should have > its X OAM, > >>and service provider should have its Y OAM. But the service > provider > >>cannot test whether his X/Y mapping is done correctly or > not without > >>doing segment X OAM. This is required for if provider wants > to detect > >>a mapping fault before customer complaints. > > > >Lets make sure we are talking about the same segment and that is the > >segment between two PEs. There is a one-to-one relationship > >between PW and > >attachment circuit in VPWS and PW status can be mapped into AC > >segment OAM. > > Correct. > > >When, you transport FR over ATM (FRF.5) this is how it is done > >and ATM PVC > >status is used (I am not aware of any special FR OAM segment running > >between the two PEs). Now how is it different for MPLS PW ? > >Maybe you want > >to tell me what is done in FRF.5 that cannot be done for FR > over MPLS. > > FR does not have proper OAM. So we shouldn't base MPLS on > deficiencies of FR. > > > > > > > > >>Now regarding PW, we can test both PSN label and PW label > using MPLS > >>OAM. Customer can also test its connection (let's say ATM VC) using > >>ATM OAM. But the only way that provider can check the > correct mapping > >>between customer ATM VC to PW label, is by running segment ATM OAM > >>between PEs. VCCV does not help you for doing so. > > > >How do you check the mapping between FR VC and ATM VC when you > >have FRF.5 ? > > You can't. FR has poor OAM. > > >How do you check the mapping between an ATM physical port and > >a PW when the > >service is port based ? > > You can use ILM instead. > > > > > > >>Now please tell me what VCCV can do that the OAMs I described above > >>can't do better. > > > >As I said before VCCV for MPLS PW is analogous to ATM VC OAM > >and LSP OAM is > >analogous to ATM VP OAM. Now tell me, do you think we only > >need LSP tunnel > >OAM and not PW OAM. > > I didn't say we only need LSP tunnel OAM. I said we can have > both LSP tunnel OAM and PW label OAM using LSP-ping or > anything else. LSP-ping for the PW label is analogous to ATM > VP OAM. And if you needed deeper test you could use ATM > segment OAM to test even the mapping of VCs to PW. No you > tell me what problems you can detect with VCCV that you can't > detect with LSP-ping over the PW label? The LSP ping capability cannot be negotiated during the VC set up using vanilla LSP ping. Use of VCCV can be used to automate the CV as a natural "feature" of the VC. Moreover, since VCCV provides an OAM "container" that allows for several types of OAM payloads depending on the PSN/VC combination if you like. This allows it to handle all cases in a generic way from the OSS/UI perspective. So one big advantage is that if your OSS is accustomed to talking to VCCV, then it doesn't matter what the PSN/VC combination is. Given your example, in many cases you can only do X/MPLS with just LSP ping. Let me complicate things for you further. Which probablems cannot be caught with VC/L2TPv3 using ICMP ping (i.e.: without VCCV)? --Tom From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Ali Sajassi Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 12 May 2003 10:29:32 -0700 Lines: 89 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C94B@nt-exch-yow.pmc-s ierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 12 19:32:55 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Shahram Davari , "'Ali Sajassi'" , "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C94B@nt-exch-yow.pmc-s ierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > >Lets make sure we are talking about the same segment and that is the > >segment between two PEs. There is a one-to-one relationship > >between PW and > >attachment circuit in VPWS and PW status can be mapped into AC > >segment OAM. > >Correct. > > >When, you transport FR over ATM (FRF.5) this is how it is done > >and ATM PVC > >status is used (I am not aware of any special FR OAM segment running > >between the two PEs). Now how is it different for MPLS PW ? > >Maybe you want > >to tell me what is done in FRF.5 that cannot be done for FR over MPLS. > >FR does not have proper OAM. So we shouldn't base MPLS on deficiencies of >FR. Oh, let me see. If I need to transport FR, Ethernet, PPP, or HDLC over MPLS, based on your suggestion of using ATM segment OAM , then I am out of luck since none of these L2 services have segment OAM. I hope you're not suggesting to put them over ATM and then over MPLS :-) My point in here is that if operators and providers see a problem here, then it should be addressed for the whole space and not just for couple of special cases. Besides, operators have been offering FR over ATM for years and years and if there are any issues with the mapping, they can shed some light here. > > > > > > > >>Now regarding PW, we can test both PSN label and PW label > >>using MPLS OAM. Customer can also test its connection (let's > >>say ATM VC) using ATM OAM. But the only way that provider > >>can check the correct mapping between customer ATM VC to > >>PW label, is by running segment ATM OAM between PEs. VCCV > >>does not help you for doing so. > > > >How do you check the mapping between FR VC and ATM VC when you > >have FRF.5 ? > >You can't. FR has poor OAM. It is not just FR. As I mentioned before, how about Ethernet, HDLC, and PPP and even port-based mode of ATM ? > >How do you check the mapping between an ATM physical port and > >a PW when the > >service is port based ? > >You can use ILM instead. Nice try :-) you cannot use ILMI to do it properly ! >I didn't say we only need LSP tunnel OAM. I said we can have both >LSP tunnel OAM and PW label OAM using LSP-ping or anything else. VCCV is not rocket science. It is an extension to LSP ping and it can be merged with it. So I guess we agree that we need to test both LSP tunnel and PWs and a mechanism need to exist to provide such test, right ? >LSP-ping for the PW label is analogous to ATM VP OAM. And if you needed >deeper test you could use ATM segment OAM to test >even the mapping of VCs to PW. No, that's the right way for several reasons: 1) In case of ATM network, you don't say that we only need ATM VP OAM and to do a deeper test, we need use "X" segment to do it. 2) What about non-ATM scenarios ? 3) What about port-based ATM scenario ? I am not going to say that you're confused here :-) but there are two separate topics here: a) sub-layer OAM for MPLS PW and b) AC to PW mapping verification. >No you tell me what problems you can detect with VCCV that you can't >detect with LSP-ping over the PW label? As I said VCCV is an extension to LSP-ping. So maybe we agree that we need an OAM mechanism for both LSP tunnel and PW. Now if you don't like the name VCCV, maybe we call it "LSP ping plus" :-) -Ali From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Yakov Rekhter Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Mon, 12 May 2003 10:59:37 -0700 Lines: 30 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Thomas Narten , Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon May 12 20:03:17 2003 Return-path: To: "Hamid Ould-Brahim" In-Reply-To: Your message of "Wed, 07 May 2003 14:08:52 EDT." Content-ID: <14457.1052762377.1@juniper.net> X-SMTP-HELO: merlot.juniper.net X-SMTP-MAIL-FROM: yakov@juniper.net X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com,hbrahim@nortelnetworks.com X-SMTP-PEER-INFO: natint.juniper.net [207.17.136.129] Status: O Hamid, > > Thomas> The above could be read as indicating that the > > discussion/urgency of > > Thomas> the L2 work is pushing out or drowning out discussion > > on L3 topics. > > > > Yes, I do think so. > > To be more precise, the discussions were mostly on vpls service, > and since l2vpn includes services other than vpls, this could > be read as well that vpls discussion/urgency is pushing out or > drowning out discussions on other l2vpn services. Agreed. In fact, if the justification for splitting the PPVNP WG into two is to allow discussion for L3 services, then following the same line of reasoning there should be not one, but two L2 VPN WGs, one for L2 VPN services (other than VPLS), and one for VPLS. Yet, the IESG said nothing about having two L2 VPN WGs. Perhaps the IESG would be kind enough to explain this inconsistency. > In that respect, creating a new l2vpn wg will not make the situation any > better. Agreed. Yakov. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Mon, 12 May 2003 15:50:07 -0400 Organization: Cisco Systems, Inc. Lines: 113 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C94B@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , X-From: pwe3-admin@ietf.org Mon May 12 21:55:11 2003 Return-path: To: "'Shahram Davari'" , "'Ali Sajassi'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C94B@nt-exch-yow.pmc-sierra.bc.ca> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Shahram Davari > Sent: Monday, May 12, 2003 12:42 PM > To: 'Ali Sajassi'; 'tnadeau@cisco.com'; 'Mustapha Aissaoui'; > 'David Allan' > Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson'; > pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Ali, > > > >>1) Each layer's OAM only tests that layer's connectivity. > > > >Good, at least we agree that much :-) > > Good. > > > > >>2) In X over Y layer, in which X is the customer traffic > >>and Y is the service provider tunnel, customer should have > its X OAM, > >>and service provider should have its Y OAM. But the service > provider > >>cannot test whether his X/Y mapping is done correctly or > not without > >>doing segment X OAM. This is required for if provider wants > to detect > >>a mapping fault before customer complaints. > > > >Lets make sure we are talking about the same segment and that is the > >segment between two PEs. There is a one-to-one relationship > >between PW and > >attachment circuit in VPWS and PW status can be mapped into AC > >segment OAM. > > Correct. > > >When, you transport FR over ATM (FRF.5) this is how it is done > >and ATM PVC > >status is used (I am not aware of any special FR OAM segment running > >between the two PEs). Now how is it different for MPLS PW ? > >Maybe you want > >to tell me what is done in FRF.5 that cannot be done for FR > over MPLS. > > FR does not have proper OAM. So we shouldn't base MPLS on > deficiencies of FR. Well, this is the first that I have heard of this. Given how long FR has been implemented, I would hope that if it really were, that dissatified SPs would have complained. > >>Now regarding PW, we can test both PSN label and PW label > using MPLS > >>OAM. Customer can also test its connection (let's say ATM VC) using > >>ATM OAM. But the only way that provider can check the > correct mapping > >>between customer ATM VC to PW label, is by running segment ATM OAM > >>between PEs. VCCV does not help you for doing so. > > > >How do you check the mapping between FR VC and ATM VC when you > >have FRF.5 ? > > You can't. FR has poor OAM. In your opinion it does. Again, I haven't heard from operators that it does. --Tom > >How do you check the mapping between an ATM physical port and > >a PW when the > >service is port based ? > > You can use ILM instead. > > > > > > >>Now please tell me what VCCV can do that the OAMs I described above > >>can't do better. > > > >As I said before VCCV for MPLS PW is analogous to ATM VC OAM > >and LSP OAM is > >analogous to ATM VP OAM. Now tell me, do you think we only > >need LSP tunnel > >OAM and not PW OAM. > > I didn't say we only need LSP tunnel OAM. I said we can have > both LSP tunnel OAM and PW label OAM using LSP-ping or > anything else. LSP-ping for the PW label is analogous to ATM > VP OAM. And if you needed deeper test you could use ATM > segment OAM to test even the mapping of VCs to PW. No you > tell me what problems you can detect with VCCV that you can't > detect with LSP-ping over the PW label? > > -Shahram > > > > >-Ali > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: Loa Andersson Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF Date: Tue, 13 May 2003 07:52:19 +0200 Lines: 44 References: <200305121759.h4CHxbu62438@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Hamid Ould-Brahim" , Thomas Narten , Alex Zinin , ppvpn@nortelnetworks.com, pwe3@ietf.org, "Wijnen, Bert (Bert)" , "Peterson, Jon" , Allison Mankin X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Tue May 13 07:54:42 2003 Return-path: X-Original-Recipient: hbrahim@nortelnetworks.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: en-us, en To: Yakov Rekhter X-SMTP-HELO: mailg.telia.com X-SMTP-MAIL-FROM: loa@pi.se X-SMTP-RCPT-TO: hbrahim@nortelnetworks.com,ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: mailg.telia.com [194.22.194.26] Status: O Yakov, just because something is "too big", you don't need to split each and every atom. "logical extremes" does not very often make sense in disucssion on how to organize a work load, we should look for opitmization in this context "splitting" makes perfetly sense /Loa Yakov Rekhter wrote: < snip > > > Agreed. In fact, if the justification for splitting the PPVNP WG > into two is to allow discussion for L3 services, then following > the same line of reasoning there should be not one, but two L2 VPN > WGs, one for L2 VPN services (other than VPLS), and one for VPLS. > Yet, the IESG said nothing about having two L2 VPN WGs. Perhaps the > IESG would be kind enough to explain this inconsistency. > > >>In that respect, creating a new l2vpn wg will not make the situation any >>better. > > > Agreed. > > Yakov. > > > > -- /Loa mobile + 46 739 81 21 64 email: loa@pi.se From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 13 May 2003 12:07:36 +0100 Lines: 121 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Sasha@axerra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 13 13:11:58 2003 Return-path: To: sajassi@cisco.com, Shahram_Davari@pmc-sierra.com, tnadeau@cisco.com, mustapha.aissaoui@alcatel.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ali, please see in-line....note my mail access is limited so I may not be able to quickly respond further. regards, Neil Ali Sajassi wrote 12 May 2003 09:10 > > Shahram, Neil: > > By going through this email thread regarding OAM for PW, I > realized that > there are several areas of contentions that need further > exploration/clarification. So lets go over them in a bit more > details and > see where we stand. > > > We all advocate proper layering for PW OAM but we all have > different views > of what the proper layering should be. One view which I am > hearing is that > there should be a single OAM mechanism for the whole MPLS > (both LSP tunnel > and PW) and some people think that PW is an artificial layer > that shouldn't > have its own OAM. NH=> Spot on....ask yourself this question....is a PW a networked (ie switched entity)? If the answer is no (and this is indeed the case) then it lives between proper layer networks X and Y in a client/server relationship...in G.805 sense it is part of some client->server adaptation process as some form of encaps function. Adapation requires to have minimal functionality.....the less to manage and specify (and go wrong) the better. Note however, that when we are considering *service* interworking then the X and Y trails terminate at the IWF and a PW entity has no need to exist at all.....in fact it better not. So if I am considering something like ATM/MPLS service interworking then I don't want to see any PW notion at all...it makes no sense. And of course, such service interworking ought to be a key consideraion for most major operators for the reasons of functional convergence across like-mode technologies (eg the resulting capex/opex savings) as I have noted in previous mails......which is why FR/ATM service interworking was previously also an important requirement. > by the service > layer (e.g., either segment ATM or segment Ethernet or > segment Foo) and > thus there is no need for the PW to have its own OAM. Lets > look at them a > bit more closely. > > First, I think each layer and sub-layer of transport need > their own OAM > mechanism since they operate independently and the each have > different > termination points (e.g., I.610 - OAM principles for B-ISDN). > So if I have > IP over ATM over SONET, there needs to be a OAM for each of > these layers > and one layer's OAM should not be used to replace another. NH=> Correct.....but note this is specifically *network* interworking case, where we have simple client/server layer relationships. There are no PWs here please note. > > Second if there are sub-layers within a transport layer, then these > sub-layers also need their own OAM because again they can > have different > termination/disposition points. One example that we are all > familiar with > is ATM where VC and VP have their own end-to-end and segment > OAM and one > sub-layer OAM doesn't replace the other. NH=>In ATM the VP layer network and the VC layer network are truly disjoint wrt access points, ie can't connect a VP access point to a VC access point. ) So one can consider > an MPLS PW > analogous to an ATM VC and an MPLS LSP tunnel analogous to an > ATM VP and > thus similar to ATM each have their own OAM mechanism because > each of these > transport sub-layers have different termination/disposition points. NH=> You might *like* to make this analogy, but its not correct. The LSP is a proper layer networked entity, but the PW is *not* a networked entity.....its an artifical 'in-between' layer construct and the reasons it exists are as I have pointed to out in previous mails. > > Third, using a service layer OAM to replace/compensate for a > transport > sub-layer OAM is not the right approach for several reasons: > A) In ATM network, when you transport FR between two end > points over an > ATM, you don't use FR OAM in the ATM network to > detect/isolate fault but > instead you relay on ATM OAM and as the matter of fact FR PVC status > relies on the ATM PVC (FRF.5). > B) Service layer OAM doesn't give you the right info. For > example in a VPLS > service, Ethernet OAM ping can span several PWs. Also again > for proper > layering, Ethernet OAM should be independent from MPLS layer OAM. > C) There are cases that the service layer doesn't have an OAM > mechanism > associated with it - e.g., in case of a transport of routed > packets over a > PW without L2 layer (refer to draft-sajassi-l2vpn-interworking for > different interworking scenarios). NH=> If one constructs the G.805 diagrams than all the above become clear wrt to what is/is-not required. > > > There are other reasons of why it is better for PW to have > their own OAM > mechanism such as the use of common mechanism for > interworking between > disparate interfaces but there is no need to get into the > details right now > since the above reasons should be sufficient. > > So at the end, I think we need to have a mechanism for PW OAM > and VCCV as > Tom has described it provides such mechanism. NH=> Try modelling FR/MPLS/ATM *service* interworking, you will very quickly discover the PW does not exist. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mustapha Aissaoui Subject: Re: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Tue, 13 May 2003 15:03:51 -0400 Organization: Alcatel Networks Corporaton Lines: 73 Sender: pwe3-admin@ietf.org References: <8FA6CEF9A4E42B48A5F8DC038655B353010457A8@mxtlv1.corrigent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 13 21:09:37 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: David Zelig Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O David, you are right, according to I.610, OAM segments on a given VCC should not overlap. Furthermore, I.610 states that once a segment is configured on a VCC, all segment OAM cells received from outside of this segment should be discarded at the source/sink of the configured segment. Thus, if the carrier offering the PW service activates a segment OAM between the PW endpoints, the segment OAM flow received from his customer will be discarded until he deactivates it. In any case, these issues are agreed upon on a bilateral agreement basis, and normally OAM cells are not just passed through a inter-carrier network interface. Regards, Mustapha. --------------- David Zelig wrote: > Mustapha, > Maybe I was not clear enough in what a customer is: from my point of view it > is the ATM entity that is connected through the PW. I am aware that for the > simple case you mention you can use a segment ATM OAM, but the PW is > applicable also for carrier of carriers scenarios, and even internally to an > organization, there is a need for a clear demarcation point. We should be > careful to define the PW transparent enough, where in transparency I mean > also minimum knowledge is required from the PW provider point of view on the > carried signal and the protocols that are used on top of it. > > David > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Thursday, May 08, 2003 6:43 PM > > To: Shahram Davari > > Cc: 'David Zelig'; pwe3@ietf.org > > Subject: Re: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > > > > Shahram and David, > > > > Shahram Davari wrote: > > > > > > David, > > > > > > > > > > >Shahram, > > > >two major points are not solved with the suggestion to use > > > >segment OAM of > > > >the native signal: > > > >1) What happened if the customer is using the segmented OAM > > > >over a span that > > > >include the PW? > > > > > > You have a point, but I am not sure why customer wants to run > > > segment OAM, rather than end-to-end OAM. > > > > We need to spearate customer testing from service provider testing. > > Assume that we have a simple 3-hop network scenario (CE-PE-PE-CE). > > Assume also we have a ATM-MPLS-ATM PW running over this network. > > > > The customer can test his/her connectivity using an end-to-end OAM > > flow. The service provider will pass these cells unaffected provided > > that: > > a. There was an agreement allowing the customer to inject OAM cells. > > b. The aggregate traffic on that connection des not violate the > > traffic contract when policing user traffic in the PE. > > > > The service provider can run a segment OAM flow between the ATM > > endpoints of the PW. These points are under his managment. Both the > > customer OAM testing and the service provider OAM testing can > > operate concurrently. > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Mark Seery" Subject: FR OAM (was RE: PWE3 Arch/CW & RTP Order (Rough Consesus?)) Date: Mon, 12 May 2003 19:49:22 -0700 Lines: 46 Sender: pwe3-admin@ietf.org References: <04d901c318bf$b3e252c0$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "Shahram Davari" , X-From: pwe3-admin@ietf.org Wed May 14 00:10:30 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <04d901c318bf$b3e252c0$6401a8c0@amer.cisco.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, [SNIP] > Shahram: FR does not have proper OAM. So we shouldn't base MPLS on deficiencies of FR. < > Tom : Well, this is the first that I have heard of this. Given how long FR has been implemented, I would hope that if it really were, that dissatified SPs would have complained. < Tom and Shahram both make good points. Perhaps expanding on Shahram's short assertion may help. Technically, [FR OAM] FRF.19 does not provide the functionality that ATM OAM does, this is acknowledged by primary authors of FRF.19. FR OAM was not standardized until around 2000? and not sure it has even been widely implemented. So bare in mind it is hard to complain about something that was not available for most of Frame Relay's history (that's assuming it is even today). FRF.19 was focused on CPE-to-CPE service quality measurements (apparently some small amount of NNI use has been found as well) seeing the network as being mostly transparent - for example FR/ATM OAM interworking spec. has not been created. ATM OAM has different focus and capabilities. This all begs the question that if OAM is so important, then how did Frame Relay become so successful without it? Well ultimately that is a question for a service provider to answer, I would just observe that a number of SPs view FR as a best effort service. Undoubtedly QoS is part of that assessment, but there are probably other considerations as well; and of course some SPs view a strong OAM capability as being key to being offer strong QoS. I suggest SPs define what OAM requirements they want/need for PWE3 and the group goes from there. Arguing about FR OAM is not likely to prove constructive or instructive given that it has been none-existent, for all intents and purposes, for most of FR's history. Perhaps one thing for the group to consider is whether PWE-based services are intended to be viewed as having similar quality to Frame Relay, or similar quality to ATM services. Frame Relay has essentially, in the enterprise data services context, essentially been a service interface, and not a service transport - something else to bare in mind. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yifat Migdal-Steinberg" Subject: Ethernet header after the PWE3 encapsulation Date: Tue, 13 May 2003 17:50:42 +0300 Lines: 17 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Wed May 14 00:15:09 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] [Fwd: draft-ietf-pwe3-control-protocol-02.txt] Thread-Index: AcLv5b8UH9UpfYw9SVav02e0n+AbJQpd/ejw To: "Luca Martini" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4DEEnB29067 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I was looking carefully at the ethernet encaps latest draft and at lassere-vkompella and sodder versions of VPLS/H-VPLS/VHLS. According to these, an Ethernet frame, after removing it's preamble and FCS should be encapsulated with a VC label and a new Ethernet header with DA' and SA'. In the sodder case, these are the L2PE addresses (if known, BC DA if unknown). Still moving through the MPLS/VPLS network, those are further encapsulated. Are the DA', SA' the mac addresses of the PEs on the way? In H-VPLS (vkompella), first encapsulation, would it be DA'=DA of PE and SA'=original SA ? Yifat Ms. Yifat Migdal-Steinberg RAD Data Communications E-Mail: yifat_ms@rad.co.il Tel: 972-3-7657035 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Vach Kompella" Subject: RE: Ethernet header after the PWE3 encapsulation Date: Tue, 13 May 2003 15:24:40 -0700 Lines: 41 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A528814EC@exrad2.ad.rad.co.il> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Wed May 14 00:30:29 2003 Return-path: To: "Yifat Migdal-Steinberg" , "Luca Martini" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <27A0F290348F8E45AEF79889DDE65A528814EC@exrad2.ad.rad.co.il> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-OriginalArrivalTime: 13 May 2003 22:24:23.0950 (UTC) FILETIME=[68283AE0:01C3199E] Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yifat, No, the DA/SA are not modified in draft-lasserre-vkompella. draft-sodder uses that encap. -Vach > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Yifat > Migdal-Steinberg > Sent: Tuesday, May 13, 2003 7:51 AM > To: Luca Martini > Cc: pwe3@ietf.org > Subject: [PWE3] Ethernet header after the PWE3 encapsulation > > > > I was looking carefully at the ethernet encaps latest draft and > at lassere-vkompella and sodder versions of VPLS/H-VPLS/VHLS. > According to these, an Ethernet frame, after removing it's preamble and FCS > should be encapsulated with a VC label and a new Ethernet header with > DA' and SA'. > In the sodder case, these are the L2PE addresses (if known, BC DA if unknown). > Still moving through the MPLS/VPLS network, those are further encapsulated. > Are the DA', SA' the mac addresses of the PEs on the way? > In H-VPLS (vkompella), first encapsulation, would it be DA'=DA of PE > and SA'=original SA ? > > > Yifat > > Ms. Yifat Migdal-Steinberg > RAD Data Communications > E-Mail: yifat_ms@rad.co.il > Tel: 972-3-7657035 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: Re: IMPORTANT: Strategy for VPN work in IETF Date: Tue, 13 May 2003 19:06:22 -0400 Lines: 69 Sender: pwe3-admin@ietf.org References: <3EC08813.5060202@pi.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Hamid Ould-Brahim'" , "'Thomas Narten'" , "'Alex Zinin'" , , , "'Wijnen, Bert \(Bert\)'" , "'Peterson, Jon'" , "'Allison Mankin'" X-From: pwe3-admin@ietf.org Wed May 14 01:09:06 2003 Return-path: To: "'Loa Andersson'" , "'Yakov Rekhter'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3EC08813.5060202@pi.se> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I agree Loa. The argument doesn't make much sense. I think the point is to optimize the work load not create administravia. --Tom > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Loa Andersson > Sent: Tuesday, May 13, 2003 1:52 AM > To: Yakov Rekhter > Cc: Hamid Ould-Brahim; Thomas Narten; Alex Zinin; > ppvpn@nortelnetworks.com; pwe3@ietf.org; Wijnen, Bert (Bert); > Peterson, Jon; Allison Mankin > Subject: Re: [PWE3] Re: IMPORTANT: Strategy for VPN work in IETF > > > Yakov, > > just because something is "too big", you don't need to split > each and every atom. "logical extremes" does not very often > make sense in disucssion on how to organize a work load, we > should look for opitmization > > in this context "splitting" makes perfetly sense > > /Loa > > Yakov Rekhter wrote: > < snip > > > > > Agreed. In fact, if the justification for splitting the > PPVNP WG into > > two is to allow discussion for L3 services, then following the same > > line of reasoning there should be not one, but two L2 VPN > WGs, one for > > L2 VPN services (other than VPLS), and one for VPLS. Yet, the IESG > > said nothing about having two L2 VPN WGs. Perhaps the IESG would be > > kind enough to explain this inconsistency. > > > > > >>In that respect, creating a new l2vpn wg will not make the > situation > >>any > >>better. > > > > > > Agreed. > > > > Yakov. > > > > > > > > > > > -- > /Loa > > mobile + 46 739 81 21 64 > email: loa@pi.se > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "N, Arvind" Subject: Need a draft copy of this Date: Thu, 15 May 2003 09:09:12 -0500 Lines: 48 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31AEB.8F67B100" X-From: pwe3-admin@ietf.org Thu May 15 18:52:53 2003 Return-path: To: pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C31AEB.8F67B100 Content-Type: text/plain Hi All, I was looking around for a draft-martini-l2circuit-encap-mpls-04.txt in the ietf site. I did not find the same. Could anyone give me a link of where it is moved to, or is the same draft been overwritten with something else. Thanks in advance rgds Arvind ------_=_NextPart_001_01C31AEB.8F67B100 Content-Type: text/html Message
Hi All,
        I was looking around for a draft-martini-l2circuit-encap-mpls-04.txt  in the ietf site. I did not find the same. Could anyone give me a link of where it is moved to, or is the same draft been overwritten with something else.
 
Thanks in advance
 
rgds
Arvind
 
------_=_NextPart_001_01C31AEB.8F67B100-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Qiu Jin Subject: Mapping between the connection verification status of PW and the native ATM services Date: Thu, 15 May 2003 16:25:23 -0700 Lines: 8 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Fri May 16 01:32:00 2003 Return-path: To: "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O In the draft-ietf-pwe3-arch-02.txt, section 8.3 says, If connection verification status of PW is needed by the CE, it must be mapped to the native connection status method. Are there any one can point me where can I find more detail information about the mapping between the connection verification status of PW and ATM OAM? Thanks Qiu From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Thomas D. Nadeau" Subject: RE: Mapping between the connection verification status of PW and the native ATM services Date: Thu, 15 May 2003 22:12:31 -0400 Organization: Cisco Systems Lines: 26 Sender: pwe3-admin@ietf.org References: <49D9473417F1234C9C86886EE8353FAA0E0D0D@mailman.sprintlabs.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri May 16 04:19:38 2003 Return-path: To: "'Qiu Jin'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <49D9473417F1234C9C86886EE8353FAA0E0D0D@mailman.sprintlabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-00.txt > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Qiu Jin > Sent: Thursday, May 15, 2003 7:25 PM > To: 'pwe3@ietf.org ' > Subject: [PWE3] Mapping between the connection verification > status of PW and the native ATM services > > > In the draft-ietf-pwe3-arch-02.txt, section 8.3 says, If > connection verification status of PW is needed by the CE, it > must be mapped to the native connection status method. Are > there any one can point me where can I find more detail > information about the mapping between the connection > verification status of PW and ATM OAM? > > Thanks > Qiu > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: FR OAM (was RE: PWE3 Arch/CW & RTP Order (Rough Conses us?)) Date: Thu, 15 May 2003 23:55:00 -0400 Lines: 140 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Sasha Vainshtein'" , "'George Swallow'" , "'Danny McPherson'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 16 06:02:40 2003 Return-path: To: "'Ali Sajassi'" , Shahram Davari , "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'David Allan'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ali's email is a good step forward to address the proper layering with respect to OAM. However, I think the biggest controvery is around MPLS OAM versus PW OAM. Ali addresses that specific issue only in one point, where he compares an LSP with an ATM VP and a PW with an ATM VC and argues that therefore both MPLS OAM and PW OAM need to exist. The rest of his email argues that client-layer OAM alone is not enough. That is correct, but it leaves open the question whether server-layer OAM should be MPLS OAM, PW OAM or both. Neil responded to Ali's VP/VC argument that it doesn't apply because a PW is not a networked entity and begins and ends at the same points as the LSP over which it is carried. That is indeed the case, although there are indications that people see exceptions. More about that at the end of this email. So assuming that a PW is not networked, what is the right solution: MPLS OAM, PW OAM or both? I think it depends on the way the core MPLS network is set up. If the core network is strictly point-to-point (i.e. Neil's ideal co pkt-sw network), I believe MPLS OAM is sufficient. E.g. it is sufficient to do connectivity verification for the LSP. If the LSP is down, obviously all PWs running over that LSP are down and the related NSP entities can be notified of the defect. Tom argued in earlier emails that LSP Ping is not sufficient and that you need VCCV-Ping for accurate OAM. In the absence of ECMP, I don't agree. Ultimately, one needs to know whether the NSP entities at either side of the PW are bound correctly. However, that can only be verified with a continuity verification in the native service layer (i.e. the client layer). VCCV-Ping might come "closer" than LSP Ping, but in the end it only proves connectivity within the server layer. In a network with ECMP, it is almost impossible to determine with full certainty connectivity of an LSP. In that case, VCCV-Ping is required. Maybe this is sophistry, but in my mind the use of VCCV-Ping doesn't turn the PW layer into some nebulous in-between layer. I would argue that it is a sensible way to do MPLS OAM in a network with ECMP. Currently, the vccv-draft specifies the tools (i.e. VCCV-Ping), but doesn't specify in great detail how they should be used. I propose that the following additions/modifications be made to the draft. 1) In core networks without ECMP, LSP Ping should be used to verify server-layer connectivity. In core networks with ECMP, VCCV-Ping should be used. Which of the two will be used is provisionable by the service provider. To the client layer it will be invisible which of the two is being used. In both cases, the same fault indications will be given (albeit that in the case of LSP-Ping all NSP entities bound to an LSP will be triggered, whereas in the case of VCCV-Ping only the NSP entity bound to that specific PW will be triggered) 2) PEs must support both LSP-Ping and VCCV-Ping. The negotiation process specified in the vccv-draft should be modified to include LSP Ping as an option for OAM. 3) LSP-Ping or VCCV-Ping requests will be sent by both PEs at regular intervals. A PE will interpret failure to receive a reply to its own ping and/or failure to receive ping requests from the far side as an error and it will give the appropriate defect indication to the client layer. The timer interval will be configurable by the service provider and will likely differ depending on the client layer. 4) Practically all client services are bi-directional, whereas LSPs are uni-directional. For the purposes of PW OAM, associated up and downstream LSPs must be seen as a pair. The reply to an upstream ping request will be returned over the associated downstream LSP or PW. 5)A comment on draft-nadeau-pwe3-oam-msg-map-00: The draft proposes in several instances to tear down the PW in response to error indications in the client layer (e.g. ATM AIS). I believe that that is fundamentally wrong. The ATM AIS and RDI messages are suffient to inform other ATM nodes about failures. The client layer should take care of itself. The PW should stay up. Networked PWs -------------- As stated at the beginning of this email, a PW is not a networked entity. However, there are indications that people see exceptions to that. Eric Rosen mentioned it in several of his emails and the recent discussion on TTL values (concluding that TTL should not always be set to 2) is another example. If PW becomes indeed a switched entity, we should bite the bullet and turn it into a full-blown MPLS layer. However, because of PW requirements, it would be strictly point-to-point and it could rightfully be called the "PW Layer". The OAM principles stated above would still apply. A final note: the fact that this email proposes a solution based on LSP Ping and VCCV Ping does not mean that I don't see the value of Y.1711. On the contrary. However, I think that the use of VCCV Ping over point-to-point paths (which PWs are, after all) avoids many of the problems identified in draft-allan-mpls-oam-frmwk-04. By being specific, I hope that we can get beyond the religious debates. I think there is an urgent need for a good OAM solution and I hope this email will help us get there. Peter > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: Monday, May 12, 2003 4:10 AM > To: Shahram Davari; 'tnadeau@cisco.com'; 'Mustapha Aissaoui'; 'David > Allan' > Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson'; > pwe3@ietf.org > Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) > > > Shahram, Neil: > > By going through this email thread regarding OAM for PW, I > realized that > there are several areas of contentions that need further > exploration/clarification. So lets go over them in a bit more > details and > see where we stand. > > > We all advocate proper layering for PW OAM but we all have > different views > of what the proper layering should be. One view which I am > hearing is that > there should be a single OAM mechanism for the whole MPLS > (both LSP tunnel > and PW) and some people think that PW is an artificial layer > that shouldn't > have its own OAM. Another view is that PW OAM can be handled > by the service > layer (e.g., either segment ATM or segment Ethernet or > segment Foo) and > thus there is no need for the PW to have its own OAM. Lets > look at them a > bit more closely. > > First, I think each layer and sub-layer of transport need > their own OAM > mechanism since they operate independently and the each have > different > termination points (e.g., I.610 - OAM principles for B-ISDN). > So if I have > IP over ATM over SONET, there needs to be a OAM for each of > these layers > and one layer's OAM should not be used to replace another. > > Second if there are sub-layers within a transport layer, then these > sub-layers also need their own OAM because again they can > have different > termination/disposition points. One example that we are all > familiar with > is ATM where VC and VP have their own end-to-end and segment > OAM and one > sub-layer OAM doesn't replace the other. So one can consider > an MPLS PW > analogous to an ATM VC and an MPLS LSP tunnel analogous to an > ATM VP and > thus similar to ATM each have their own OAM mechanism because > each of these > transport sub-layers have different termination/disposition points. > > Third, using a service layer OAM to replace/compensate for a > transport > sub-layer OAM is not the right approach for several reasons: > A) In ATM network, when you transport FR between two end > points over an > ATM, you don't use FR OAM in the ATM network to > detect/isolate fault but > instead you relay on ATM OAM and as the matter of fact FR PVC status > relies on the ATM PVC (FRF.5). > B) Service layer OAM doesn't give you the right info. For > example in a VPLS > service, Ethernet OAM ping can span several PWs. Also again > for proper > layering, Ethernet OAM should be independent from MPLS layer OAM. > C) There are cases that the service layer doesn't have an OAM > mechanism > associated with it - e.g., in case of a transport of routed > packets over a > PW without L2 layer (refer to draft-sajassi-l2vpn-interworking for > different interworking scenarios). > > > There are other reasons of why it is better for PW to have > their own OAM > mechanism such as the use of common mechanism for > interworking between > disparate interfaces but there is no need to get into the > details right now > since the above reasons should be sufficient. > > So at the end, I think we need to have a mechanism for PW OAM > and VCCV as > Tom has described it provides such mechanism. > > -Ali > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: FR OAM (was RE: PWE3 Arch/CW & RTP Order (Rough Conses us?)) Date: Fri, 16 May 2003 12:33:48 +0100 Lines: 172 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Sasha@axerra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 16 14:07:51 2003 Return-path: To: busschbach@lucent.com, sajassi@cisco.com, Shahram_Davari@pmc-sierra.com, tnadeau@cisco.com, mustapha.aissaoui@alcatel.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter....please see below. regards, Neil Busschbach, Peter B (Peter) wrote 16 May 2003 04:55 > Ali's email is a good step forward to address the proper > layering with respect to OAM. However, I think the biggest > controvery is around MPLS OAM versus PW OAM. Ali addresses > that specific issue only in one point, where he compares an > LSP with an ATM VP and a PW with an ATM VC and argues that > therefore both MPLS OAM and PW OAM need to exist. NH=> This is not a valid analogy for the reasons I gave previously. > The rest of > his email argues that client-layer OAM alone is not enough. NH=> Yes indeed...as will become crystal clear later. > That is correct, but it leaves open the question whether > server-layer OAM should be MPLS OAM, PW OAM or both. > > Neil responded to Ali's VP/VC argument that it doesn't apply > because a PW is not a networked entity and begins and ends at > the same points as the LSP over which it is carried. That is > indeed the case, although there are indications that people > see exceptions. More about that at the end of this email. > > So assuming that a PW is not networked, what is the right > solution: MPLS OAM, PW OAM or both? > > I think it depends on the way the core MPLS network is set > up. If the core network is strictly point-to-point (i.e. > Neil's ideal co pkt-sw network), NH=> This is something else entirely Peter (albeit yet another consequence of mp2p). Under *ALL* conditions of running mp2p when carrying XoverMPLS one must provide a p2p LSP *client* layer to the underlying mp2p LSP server layer to recover from the effects of merging. This is a forced requirement in order to be able to identify the source. It has nothing directly to do the additional PW creations. These exists to fix *other* problems caused by mp2p....such as: - the fact that misordering is allowed......this really should not be the case; - the fact that ECMP algorithms are being run over multiple layer networks (in a single layer network load-sharing is OK, but not over multiple layers) which, because of the 1st nibble hack on the payload leads to the other kludge on the client layer (X) PID...and BTW one should not be using a *client* layer PID field for *same/lower* layer OAM identification....further evidence of bad architecture; - the fact that some believe a bit of BW squeezing by compressing the client (X) is a worthwhile thing. Further, it is also related to the desire to force X/MPLS solutions to look like X/IP solutions.....this may seem laudable at 1st glance, but the behaviour of these 2 server modes ought to be different (else why have them?) and trying to force alignment is not really a 'good thing' IMO. - I believe MPLS OAM is > sufficient. E.g. it is sufficient to do connectivity > verification for the LSP. If the LSP is down, obviously all > PWs running over that LSP are down and the related NSP > entities can be notified of the defect. NH=> But can't you see that since one is *forced* to always run p2p LSPs above any mp2p construct for X/MPLS then the PW OAM stuff is a non-issue.....you simple do the proper OAM on these p2p constructs! > > Tom argued in earlier emails that LSP Ping is not sufficient NH=> Agreed. LSP-Ping is a heavyweight diagnostics tool....and this is quite different to a lightweight detection/handling function that should (nay must) be an intrinsic design component the data-plane. I refer those who wish to do this right to use Y.1711, and I would rather not see any further misinformation being stated about the Y.1711. > and that you need VCCV-Ping for accurate OAM. NH=> I believe VCCV is required to cater for limitations of LSP-Ping because of the way (one at least) vendor's ECMP algorithm works.....that is LSP-Ping uses an IP client payload and so requires a v4 exp null label, but X/MPLS client uses normal forwarding label and thus may not hash to the same forwarding path. However, I digress...... The simple fact is this: mp2p merging in a co pkt-sw forwarding mode is a topologically bizarre thing to do, and it leads to all sorts of problems...fault-management is but one of these. If one wants any-any connectivity use IP for goodness sake. However, the most obvious topological problem/consequence of mp2p is that it forces an extra client level of p2p LSP to allow demerging (ie recover the source identification). So, if we get the fault-management right on these p2p LSPs then we are done....PW OAM, and the problems this additionally creates (see next para), is simply not required for *OAM interworking* with the real client X. I am amazed this is not obvious to everyone....it is so simple. However, just to really ram home this point.....consider the case of FR<=>MPLS<=>ATM interworking. If FR/MPLS uses one type of PW adapatation and ATM/MPLS uses another type of PW adaptation (as indeed is the case) then there is a BIG problem.....because we also now have to interwork the different PW types. What nonsense! So FR<=>MPLS<=>ATM interworking really brings home the point that we *must* have clear native service-interworking between FR, MPLS and ATM and that PWs make very little sense here.....esp PW OAM. The PW notion can only be tolerated (note the word 'tolerated') in the simpler network-interworking case of X/MPLS as a client/server pair.....but network-interworking is not the only required case, we operators want service-interworking.....and we want to see it done properly, esp with ATM. In fact the need to recognise the above point was even brought out in a Cisco paper to a SG13/Q3 mtg I have been attending this week in Nice. Once the consequences were understood by all the engineers attendng this mtg there was unaminmous agreement that this needs fixing properly.....the logic is simply irrefutable. > > 1) In core networks without ECMP, LSP Ping should be used to > verify server-layer connectivity. In core networks with ECMP, > VCCV-Ping should be used. Which of the two will be used is > provisionable by the service provider. To the client layer it > will be invisible which of the two is being used. In both > cases, the same fault indications will be given (albeit that > in the case of LSP-Ping all NSP entities bound to an LSP will > be triggered, whereas in the case of VCCV-Ping only the NSP > entity bound to that specific PW will be triggered). NH=> Please distinguish *detection/handling* and *diagnostics* functions.....these are not at all the same. LSP-Ping is a useful diagnostic tool that operators who have deployed mp2p LSPs will probably need. But remember what I said above, ie mp2p forces p2p LSPs above these. So the right answer is to run Y.1711 on the p2p entities and if/when these show a problem *and* L1 shows 'clear' then wheel-out LSP-Ping. The wrong answer is to invent unnecessary PW OAM and/or try and run LSP-Ping in some detection/handling mode that (i) it was not designed for and (ii) is really not capable of delivering against anyway. > 5)A comment on draft-nadeau-pwe3-oam-msg-map-00: > The draft proposes in several instances to tear down the PW > in response to error indications in the client layer (e.g. > ATM AIS). I believe that that is fundamentally wrong. NH=> Too right it is! You simply don't start tearing down connections like this. > The ATM > AIS and RDI messages are suffient to inform other ATM nodes > about failures. The client layer should take care of itself. NH=> Quite so. > The PW should stay up. NH=> No, the PW should not exist....at least with the direction its going now. The only thing required between the true client X and MPLS is simple adapatation. It is only X and MPLS that require functional interworking, like OAM. > > > Networked PWs > -------------- > As stated at the beginning of this email, a PW is not a > networked entity. However, there are indications that people > see exceptions to that. Eric Rosen mentioned it in several of > his emails and the recent discussion on TTL values > (concluding that TTL should not always be set to 2) is > another example. NH=> Huh? Eric was talking about the TTL of the p2p LSP......not the artificial PW above this. PWs are not part of the MPLS layer network and they don't have a TTL field. > > If PW becomes indeed a switched entity, we should bite the > bullet and turn it into a full-blown MPLS layer. NH=> It would not be an MPLS layer network at all....but some new layer network. However, I am not at all clear you understand this given you immediately prior point. But what a further serious mistake this would be if one did this. Operators require the removal of layer networks to reduce opex/capex....not the adding of unnecessary layers (and the PW case this is hardly a proper layer network anyway, its just a set of 1/2-baked fixes to problems that exist elsewhere....most of which are in fact consequences of mp2p). From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: FR OAM (was RE: PWE3 Arch/CW & RTP Order (Rough Conses us?)) Date: Fri, 16 May 2003 14:43:17 -0400 Lines: 245 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Sasha@axerra.com, swallow@cisco.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 16 20:55:19 2003 Return-path: To: "'neil.2.harrison@bt.com'" , "Busschbach, Peter B (Peter)" , sajassi@cisco.com, Shahram_Davari@pmc-sierra.com, tnadeau@cisco.com, mustapha.aissaoui@alcatel.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, You keep stressing the point that constructs like mp2p and ecmp create problems and should not have been adopted in MPLS. I agree, but for now I think we should accept these as a given. I would be interested to see if we can define acceptable OAM on the foundation that we have today. You seem to propose a more rigorous approach: get rid of the rotten foundation and build the right framework from the ground up. Further comments in-line Peter > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Friday, May 16, 2003 7:34 AM > To: busschbach@lucent.com; sajassi@cisco.com; > Shahram_Davari@pmc-sierra.com; tnadeau@cisco.com; > mustapha.aissaoui@alcatel.com; dallan@nortelnetworks.com > Cc: Sasha@axerra.com; swallow@cisco.com; danny@tcb.net; pwe3@ietf.org > Subject: RE: FR OAM (was RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough > Conses us?)) > > > Peter....please see below. regards, Neil > > Busschbach, Peter B (Peter) wrote 16 May 2003 04:55 > > > Ali's email is a good step forward to address the proper > > layering with respect to OAM. [snipped] > > So assuming that a PW is not networked, what is the right > > solution: MPLS OAM, PW OAM or both? > > > > I think it depends on the way the core MPLS network is set > > up. If the core network is strictly point-to-point (i.e. > > Neil's ideal co pkt-sw network), > NH=> This is something else entirely Peter (albeit yet > another consequence > of mp2p). Under *ALL* conditions of running mp2p when > carrying XoverMPLS > one must provide a p2p LSP *client* layer to the underlying > mp2p LSP server > layer to recover from the effects of merging. This is a > forced requirement > in order to be able to identify the source. It has nothing > directly to do > the additional PW creations. These exists to fix *other* > problems caused by > mp2p....such as: > - the fact that misordering is allowed......this really > should not be > the case; > - the fact that ECMP algorithms are being run over multiple layer > networks (in a single layer network load-sharing is OK, but not over > multiple layers) which, because of the 1st nibble hack on the > payload leads > to the other kludge on the client layer (X) PID...and BTW one > should not be > using a *client* layer PID field for *same/lower* layer OAM > identification....further evidence of bad architecture; > - the fact that some believe a bit of BW squeezing by > compressing the > client (X) is a worthwhile thing. > I interpret your comments as a critique of bad design decisions in the past. I believe you are right, but given that ECMP exists and packet-ordering is not guaranteed, I think we need to find a solution that works around those problems. > NH=> Further, it is also related to the desire to force X/MPLS > solutions to look > like X/IP solutions.....this may seem laudable at 1st glance, but the > behaviour of these 2 server modes ought to be different (else why have > them?) and trying to force alignment is not really a 'good thing' IMO. > > > > - I believe MPLS OAM is > > sufficient. E.g. it is sufficient to do connectivity > > verification for the LSP. If the LSP is down, obviously all > > PWs running over that LSP are down and the related NSP > > entities can be notified of the defect. > NH=> But can't you see that since one is *forced* to always > run p2p LSPs > above any mp2p construct for X/MPLS then the PW OAM stuff is a > non-issue.....you simple do the proper OAM on these p2p constructs! Perhaps we are in violent agreement :-) That is exactly my point: if the underlying MPLS layer has properties that force you to create p2p PWs, then you should do OAM on those PWs. Maybe I have interpreted earlier email exchanges incorrectly. I thought the notion of PW OAM was rejected by some as wrong and unnecessary. Anyway, I would like to see if we can get agreement on what it means to do proper OAM for these p2p constructs. > > > > Tom argued in earlier emails that LSP Ping is not sufficient > NH=> Agreed. LSP-Ping is a heavyweight diagnostics > tool....and this is > quite different to a lightweight detection/handling function > that should > (nay must) be an intrinsic design component the data-plane. > I refer those > who wish to do this right to use Y.1711, and I would rather > not see any > further misinformation being stated about the Y.1711. > I mentioned LSP-Ping because in the IETF it seems to have a wider acceptance than Y.1711. I agree that it is primarily a diagnostics tool, but if PEs would use LSP-Ping periodically, it could serve for connectivity verification. I think the fundamental issue is that for proper OAM you at least need a periodic connectivity verification. If you can do that with a Ping message, good. If Ping is too heavyweight, use something else. I would be interested to hear from the proponents of Ping how they think it should be used. [snipped] > NH=> So, if we get the fault-management right on these p2p LSPs then we are > done....PW OAM, and the problems this additionally creates > (see next para), > is simply not required for *OAM interworking* with the real > client X. I am > amazed this is not obvious to everyone....it is so simple. > > However, just to really ram home this point.....consider the case of > FR<=>MPLS<=>ATM interworking. If FR/MPLS uses one type of PW > adapatation > and ATM/MPLS uses another type of PW adaptation (as indeed is > the case) then > there is a BIG problem.....because we also now have to interwork the > different PW types. What nonsense! So FR<=>MPLS<=>ATM > interworking really > brings home the point that we *must* have clear native > service-interworking > between FR, MPLS and ATM and that PWs make very little sense > here.....esp PW > OAM. The PW notion can only be tolerated (note the word > 'tolerated') in the > simpler network-interworking case of X/MPLS as a > client/server pair.....but > network-interworking is not the only required case, we operators want > service-interworking.....and we want to see it done properly, > esp with ATM. > I am not sure what point you are making. In the case of Service Interworking you terminate one layer and carry the payload over another layer. So the fact that PW encapsulation of FR differs from PW encapsulation of ATM is irrelevant, because in the case of service interworking you wouldn't carry FR or ATM over MPLS, but the respective payloads. You know that, so obviously that is not the point you are making. I think you are saying that: 1) PW is designed for network interworking, i.e. the emulation of specific protocols over MPLS. Each protocol has its own adaptation function and therefore PW is not the right tool for Service Interworking. (Nobody said it was, so I don't think there is disagreement about that) 2) Service Interworking, especially between ATM and MPLS, requires proper OAM in the MPLS layer 3) Once you define a solution for ATM - MPLS Service Interworking (which according to point 1 does not include PW), then you have basically proven that you don't need PW in the first place (or am I reading too much into your statements?) Anyway, I think that with respect to OAM you end up in the same situation: if you set up point-to-point LSPs for service interworking, then you can do OAM over those connections. However, if you would try to do service interworking over a general MPLS core with MP2P LSPs and ECMP, then you will have a problem defining proper OAM and you will be forced to use an additional PW-like p2p construct for OAM purposes. That brings us back to the point I made in the beginning of this email: do you rebuild the foundation or do you build on the foundation that you have (i.e. MPLS with ECMP and MP2P) > NH=> In fact the need to recognise the above point was even > brought out in a > Cisco paper to a SG13/Q3 mtg I have been attending this week > in Nice. Once > the consequences were understood by all the engineers > attendng this mtg > there was unaminmous agreement that this needs fixing > properly.....the logic > is simply irrefutable. > > > > > > 1) In core networks without ECMP, LSP Ping should be used to > > verify server-layer connectivity. In core networks with ECMP, > > VCCV-Ping should be used. Which of the two will be used is > > provisionable by the service provider. To the client layer it > > will be invisible which of the two is being used. In both > > cases, the same fault indications will be given (albeit that > > in the case of LSP-Ping all NSP entities bound to an LSP will > > be triggered, whereas in the case of VCCV-Ping only the NSP > > entity bound to that specific PW will be triggered). > NH=> Please distinguish *detection/handling* and *diagnostics* > functions.....these are not at all the same. LSP-Ping is a useful > diagnostic tool that operators who have deployed mp2p LSPs > will probably > need. But remember what I said above, ie mp2p forces p2p > LSPs above these. > So the right answer is to run Y.1711 on the p2p entities and > if/when these > show a problem *and* L1 shows 'clear' then wheel-out > LSP-Ping. The wrong > answer is to invent unnecessary PW OAM and/or try and run > LSP-Ping in some > detection/handling mode that (i) it was not designed for and > (ii) is really > not capable of delivering against anyway. So we agree that in the given situation the right answer is to run proper OAM over the p2p constructs introduced by PW. The question then is: what is proper OAM. I believe that proper OAM at a minimum requires a periodic verification of connectivity and proper binding between sink and source. Is there consensus in the WG that such a periodic verification is required? If so, the question is what messages to use. Is there any chance that we will get consensus around that without getting into another acrimonious debate around Y.1711 versus LSP-Ping? > > > > 5)A comment on draft-nadeau-pwe3-oam-msg-map-00: > > The draft proposes in several instances to tear down the PW > > in response to error indications in the client layer (e.g. > > ATM AIS). I believe that that is fundamentally wrong. > NH=> Too right it is! You simply don't start tearing down > connections like > this. > [snipped] > > > > Networked PWs > > -------------- > > As stated at the beginning of this email, a PW is not a > > networked entity. However, there are indications that people > > see exceptions to that. Eric Rosen mentioned it in several of > > his emails and the recent discussion on TTL values > > (concluding that TTL should not always be set to 2) is > > another example. > NH=> Huh? Eric was talking about the TTL of the p2p LSP......not the > artificial PW above this. PWs are not part of the MPLS layer > network and > they don't have a TTL field. > > There was a recent email exchange with subject line: "[PWE3] TTL value of VC Label?". Unless I am completely mistaken, this thread discussed the TTL value in the PW label and decided that one could not set it to 2 in all cases. > > If PW becomes indeed a switched entity, we should bite the > > bullet and turn it into a full-blown MPLS layer. > NH=> It would not be an MPLS layer network at all....but some > new layer > network. However, I am not at all clear you understand this given you > immediately prior point. PW Labels are MPLS labels. When you use MPLS labels; when you assume that there are intermediate aggregation points and TTL values > 2; when you use LDP for PW label distribution; and when you consider BGP for autodiscovery; how far away are you from creating a full-blown MPLS layer? > But what a further serious mistake > this would be > if one did this. Operators require the removal of layer > networks to reduce > opex/capex....not the adding of unnecessary layers (and the > PW case this is > hardly a proper layer network anyway, its just a set of > 1/2-baked fixes to > problems that exist elsewhere....most of which are in fact > consequences of > mp2p). > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Luca Martini Subject: Call for Presenations at MPLS 2003, October 26-28, Washington DC Date: Fri, 16 May 2003 16:38:30 -0600 Organization: Level3 Communications LLC. Lines: 31 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Sat May 17 00:52:49 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: Italian [it],French/Canada [fr- To: pwe3@ietf.org X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4GM8MB18049 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4GMCjB18186 Status: O The MPLS 2003 Conference will be held in Washington D.C. from October 26 through October 28. This year=92s conference will include but not limited to topics such as: - MPLS as a convergence technology - MPLS network management and operational issues - Provisioning and migration strategies - MPLS in multi-AS networks - L2 VPNs (pseudo-wire, VPLS, and other) - L3 VPNs (BGP/MPLS, IPSec interworking, virtual routers, and other) - Scalability and performance - Traffic engineering and QoS - Network processor architectures for next generation applications - Testing MPLS applications and performance - Network security - Disaster recovery - Reliability and graceful restart techniques - Optical Integration and challenges The Program Committee of MPLS 2003 is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution please send a one page long proposal, including speaker=92s contact details to the attention of the Technical Program Committee at TPC@mpls2003.com by June 27, 2003. See www.mpls2003.com for more details. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations from the vendor, service provider and user community are solicited on new technologies and operational experience. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Danny McPherson Subject: TDM/SONET & RTP Date: Fri, 16 May 2003 17:50:39 -0600 Lines: 78 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Sat May 17 01:52:53 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O The following is an attempt by Stewart and I to generate one final round of discussions regarding this topic (and another in a following email) and seek some semblance of consensus from the WG. If you've got comments, clarifications or additions to the following issue summary please provide them to the WG within the next week as we need to move forward ASAP. And whether we actively engage in any discussion or not, we are listening. Thanks, Stewart/Danny ============= There has been considerable discussion about the design of the TDM/SONET PWE3 headers, and three candidates solutions are on the table: 1) Use the same CW as is used for the packet encapsulations and extend this with a second longword that contains any necessary pointer information. This leads to the following layering: MPLS PW Label PWE3 Generic CW PWE3 CW extension for pointer (if needed) RTP (if needed) 2) Use a specialized CW (the CEP header) rather than the PW generic CW, allowing all necessary information to be compressed into 4 bytes. It results in the following layering: MPLS PW Label MPLS PID or convergence layer to discriminate from IP RTP (if needed) CEP header There is some discussion as to whether the PID is a PID or a convergence layer. Please can we discuss that issue on the thread set up for that purpose. 3) Used a specialized CW (the CEP header) rather than the PW generic CW, allowing all necessary information to be compressed into 4 bytes. It results in the following layers: MPLS PW Label MPLS PID or convergence layer to discriminate from IP CEP header RTP (if needed) Method 1 is highly controversial, but conforms to the PWE3 architecture. It has the technical disadvantage that it extends the minimum packet size in a non-ECMP network. It has the practical disadvantage that it is not consistent with any of the systems that are currently deployed / in the late stages of design. Method 2 has a smaller minimum packet size than Method 1 in a non-ECMP network, and the RTP/CEP layering is identical for IP and MPLS networks. It does not conform to the design of the CW used by most of the other payloads. In strict architectural terms, the MPLS PID if present should specify an RTP payload (if present), and the CEP header should be specified as an RTP payload. However since most experts in this area expect that the majority of deployments will not use RTP, we end up with two MPLS PID values and effectively two parallel definitions of this PWE3 encapsulation. Method 3 was the method originally sketched out in the PWE3 architecture draft. This has the disadvantage that stack would not look the same on an IP PSN and does not strictly conform to the RTP layering model, but does define the payload as PWE3 at an early stage. If it is assumed that RTP will not normally be present, then the stack is more compact than Method 1 on a non-ECMP network. From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Danny McPherson Subject: CW & MPLS "PID" Date: Fri, 16 May 2003 17:59:59 -0600 Lines: 132 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Sat May 17 02:02:25 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O The second issue gating progress with the PWE3, and the architecture draft specifically, that needs to be resolved relates to the design of the Control Word and its relationship to any MPLS protocol identification mechanism. Please provide feedback (of all sorts) to the following summary on the list within the next week if you've got something to say. We intend to move forward shortly. Thanks, Stewart/Danny ================== Section 5.4.3 of the current WG Architecture document mandates that if the CW is used the encoding MUST be as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID | Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The draft suggests the use of the value 0, to distinguish it from IP which uses the values 4 and 6. After the San Francisco meeting proposals were made to the list specifying a more general MPLS PID mechanism that used a value of 1 in bits 0..3 to indicate that the rest of the longword contained a protocol identifier drawn from a registry that allowed the following payload to be identified. The purpose of the identifier was to support the transport of OAM messages and to allow any PW payload that could not, for some reason, conform to the requirement that bits 0..3 = 0 to operate correctly over an ECMP MPLS network. There is some concern from the MPLS WG as to the extent to which they will support an MPLS PID, and it is suggested that the PWE3 work needs to be self contained. This needs to be future investigated. For all the payload design groups EXCLUDING the SONET and TDM groups there seems to be some consensus for the following wording: >5.4.3. PW over MPLS Generic Control Word > > To allow accurate packet inspection in an MPLS PSN, and to operate > correctly over MPLS PSNs that have deployed equal-cost multiple-path > load-balancing a PW packet MUST NOT alias an IP packet. IP packets > are carried in MPLS label stacks without any protocol identifier. > Historic values of the IP version number [RFC791] [RFC1881] are > therefore used to distinguish between IP and non-IP MPLS payloads. > > To disambiguate the PW from an IP flow the PW SHOULD employ either > the generic PW control word shown in Figure 12, or an MPLS payload > type identifier. Note that an MPLS payload with bits 0..3 = 4 is an > IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Specified by PW Encapsulation | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 12: Generic PW Control Word > > > The PW set-up protocol determines whether a PW uses a control word. > When a control word is used, it SHOULD have the following preferred > form: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 0| Flags |FRG| Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: MPLS Preferred Control Word > and >5.4.4. MPLS Payload Identifier > > If technical considerations result in a PW control word that may > alias an IP packet, the control word SHOULD be preceded by an MPLS > payload type identifier. > > For reference the MPLS payload type identifier [TBD] is defined as > follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved | PPP DLL Protocol Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | As defined by PPP DLL protocol definition | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: MPLS Payload Type Identifier This is the proposal put forward by George Swallow and is a subset of Dave Alan's proposal except for the sense of one bit. Figure 12 allows CWs that followed the Martini design to be grandfathered and due to the values found in a practical network, the Single ATM VCC Cell Encapsulation conforms to Figure 11. Figure 14 specifies a MPLS Payload identifier that is sufficient for PWE3 purposes (including the support of OAM messages), and yet is sufficiently general that other groups can likely make any extensions that they find necessary. The questions are: EXCLUDING any TDM/SONET specific issues is this CW design agreeable to the PWE3 WG? Is the MPLS payload identifier design acceptable to the group proposing OAM/VCCP mechanisms, and if not, what constraints does it place on future related work? Is the MPLS payload identifier design acceptable to the MPLS WG as the basis of a future mechanism should that be required? If so, is it acceptable to the MPLS WG that PWE3 incorporate this design within its normative documents in order to make progress? [Note that this message will be forwarded to the MPLS WG mailing list.] From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: TDM/SONET & RTP Date: Sat, 17 May 2003 18:28:28 +0200 Lines: 117 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Sat May 17 17:36:08 2003 Return-path: To: "'Danny McPherson'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Danny, My vote is for option 2. Please see inline Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Danny McPherson > Sent: Saturday, May 17, 2003 1:51 AM > To: pwe3@ietf.org > Subject: [PWE3] TDM/SONET & RTP > > > The following is an attempt by Stewart and I to generate one > final round of discussions regarding this topic (and another > in a following email) and seek some semblance of consensus > from the WG. If you've got comments, clarifications or > additions to the following issue summary please provide them > to the WG within the next week as we need to move forward ASAP. > > And whether we actively engage in any discussion or not, we > are listening. > > Thanks, > > Stewart/Danny > > > ============= > > There has been considerable discussion about the design of the > TDM/SONET PWE3 headers, and three candidates solutions are on the > table: > > 1) Use the same CW as is used for the packet encapsulations > and extend this with a second longword that contains any > necessary pointer information. This leads to the following > layering: > > MPLS PW Label > PWE3 Generic CW > PWE3 CW extension for pointer (if needed) > RTP (if needed) > > 2) Use a specialized CW (the CEP header) rather than the PW > generic CW, allowing all necessary information to be compressed > into 4 bytes. It results in the following layering: > > MPLS PW Label > MPLS PID or convergence layer to discriminate from IP > RTP (if needed) > CEP header > > There is some discussion as to whether the PID is a PID or > a convergence layer. Please can we discuss that issue on the > thread set up for that purpose. > > 3) Used a specialized CW (the CEP header) rather than the PW > generic CW, allowing all necessary information to be compressed > into 4 bytes. It results in the following layers: > > MPLS PW Label > MPLS PID or convergence layer to discriminate from IP > CEP header > RTP (if needed) > > Method 1 is highly controversial, but conforms to the PWE3 > architecture. It has the technical disadvantage that it > extends the minimum packet size in a non-ECMP network. It has > the practical disadvantage that it is not consistent with any > of the systems that are currently deployed / in the late > stages of design. > As well as having the RTP layering problem: CW over RTP for IP, RTP over CW for MPLS. > Method 2 has a smaller minimum packet size than Method 1 > in a non-ECMP network, and the RTP/CEP layering is > identical for IP and MPLS networks. It does not > conform to the design of the CW used by most of the other > payloads. CW for Layer-1 and Layer-2 should look different. They have different requirements. > In strict architectural terms, the MPLS PID if > present should specify an RTP payload (if present), and the > CEP header should be specified as an RTP payload. However > since most experts in this area expect that the majority of > deployments will not use RTP, we end up with two MPLS PID > values and effectively two parallel definitions of this PWE3 > encapsulation. By nature, a PID value is different depending on the layer above. The layering definition is identical, the design is identical, and the packet format is self describing. > > Method 3 was the method originally sketched out in the > PWE3 architecture draft. This has the disadvantage > that stack would not look the same on an IP PSN > and does not strictly conform to the RTP layering > model, but does define the payload as PWE3 at an > early stage. If it is assumed that RTP will not normally > be present, then the stack is more compact than > Method 1 on a non-ECMP network. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: FR OAM (was RE: PWE3 Arch/CW & RTP Order (Rough Conses us?)) Date: Sat, 17 May 2003 14:20:04 -0400 Lines: 55 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: Shahram Davari , pwe3@ietf.org X-From: pwe3-admin@ietf.org Sat May 17 20:28:45 2003 Return-path: To: "'Mark Seery'" , tnadeau@cisco.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: Monday, May 12, 2003 10:49 PM > Subject: FR OAM (was RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough > Consesus?)) [snipped] > > This all begs the question that if OAM is so important, then > how did Frame > Relay become so successful without it? Well ultimately that > is a question > for a service provider to answer, I would just observe that a > number of SPs > view FR as a best effort service. Undoubtedly QoS is part of that > assessment, but there are probably other considerations as > well; and of > course some SPs view a strong OAM capability as being key to > being offer > strong QoS. > There is another aspect to this. In many (most?) cases, Frame Relay services are carried across an ATM backbone. Therefore, service providers can rely on ATM's OAM functionality for fault sectionalization etc. In fact, I think ATM's OAM features were a major driver in the decision to carry FR over an ATM backbone. Therefore, in answer to Mark's question below, I think the PWE's OAM needs to resemble ATM's OAM in order to make PWE a suitable vehicle for carrying Frame Relay services. Peter > I suggest SPs define what OAM requirements they want/need for > PWE3 and the > group goes from there. Arguing about FR OAM is not likely to prove > constructive or instructive given that it has been > none-existent, for all > intents and purposes, for most of FR's history. > > Perhaps one thing for the group to consider is whether > PWE-based services > are intended to be viewed as having similar quality to Frame Relay, or > similar quality to ATM services. Frame Relay has essentially, in the > enterprise data services context, essentially been a service > interface, and > not a service transport - something else to bare in mind. > > Mark > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: TDM/SONET & RTP Date: Sun, 18 May 2003 08:55:46 +0300 Lines: 54 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Sun May 18 08:00:14 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] TDM/SONET & RTP Thread-Index: AcMcBuGIpVWikcXORS+D2+PkpvFK6QA+VsLw To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4I5MHB02451 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart/Danny > 1) Use the same CW as is used for the packet encapsulations > and extend this with a second longword that contains any > necessary pointer information. This leads to the following > layering: > > MPLS PW Label > PWE3 Generic CW > PWE3 CW extension for pointer (if needed) > RTP (if needed) > Method 1 is highly controversial, but conforms to the PWE3 > architecture. It has the technical disadvantage that it > extends the minimum packet size in a non-ECMP network. > It has the practical disadvantage that it is not consistent > with any of the systems that are currently deployed / in > the late stages of design. I disagree with the reasoning regarding the disadvantages. Method 1 does NOT extend the minimum packet size any more than methods 2 and 3. When the extension is NOT needed, we have only the standard generic PWE CW. When it IS needed, we indeed add an additional 32 bits, but the other two methods add an MPLS PID of 32 bits as well. Hence, there is NO size disadvantage in relation to the other two methods. The practical disadvantage is somewhat more worrying. However, I believe that ANY change at this point will require SOME re-engineering to those systems that did not reserve the first nibble after the PW label (something we have been warning about for a long time). So I vote for method 1 - the generic PWE method. If this is deemed impractical because of pre-standard implementations being too hard to rework, then I vote for method 3, where the RTP is considered a higher layer than the PW. However, I doubt that for the SONET case anyone cares about the difference between 2 and 3, since RTP is NOT used. So we return to the low-rate TDM case. Returning to the argument about re-engineering, the dominant low-rate TDM implementation in the marketplace uses the standard PWE CW, and not the CEP header. I strenuously argue that this should stay this way. With multiple interoperable implementations in the field, any change from the standard CW (even were such a change to be advisable) would be too costly at this point. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: PWE3 Arch/CW & RTP Order (Rough Consesus?) Date: Sun, 18 May 2003 09:22:05 +0300 Lines: 29 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "Alexander Vainshtein" , "George Swallow" , "Danny McPherson" , X-From: pwe3-admin@ietf.org Sun May 18 08:24:18 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?) Thread-Index: AcMYroKsHALh0HfYSIyCeeiyKcCOpgEVhvew To: "Ali Sajassi" , "Shahram Davari" , , "Mustapha Aissaoui" , "David Allan" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4I5mhB03869 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Oh, let me see. If I need to transport FR, Ethernet, PPP, or > HDLC over MPLS, based on your suggestion of using ATM segment OAM , > then I am out of luck since none of these L2 services have segment OAM. I hope > you're not suggesting to put them over ATM and then over MPLS :-) > > My point in here is that if operators and providers see a > problem here, then it should be addressed for the whole space and not just > for couple of special cases. Besides, operators have been offering FR over > ATM for years and years and if there are any issues with the mapping, they > can shed some light here. While addressing OAM issues "for the whole space" is a valid concern, it is unfortunately not relevant for the PWE WG. PWs are by definition native service tunnelings, and hence service interworking is considered out-of-scope in PWE3. So any feature not provided by the native service SHOULD NOT be provided by the PW emulation of that service, and any borrowing of techniques from one service to use on another should be outlawed. The proper PW method of providing a service's functionality is to use an IWF before each edge (which would be considered an NSP in PWE terms) to convert to the service with the desired functionality. If and when we start directly addressing service interworking issues, this question may be addressed in a more general way. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: David Zelig Subject: RE: TDM/SONET & RTP Date: Sun, 18 May 2003 11:38:28 +0200 Lines: 26 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-From: pwe3-admin@ietf.org Sun May 18 10:39:24 2003 Return-path: To: "'Danny McPherson'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Danny, I think correct layering in this case should be based on functionality, not order of fields in the header. RTP and CW are the same layer in the sense that they start and terminate together. >From practical point of view, both methods #1 and #3 require different pointer interpretation with/without RTP, so CW processing will be dependent on the RTP in these cases, - while keeping correct "layered" order in fields ordering, it is wrong layered dependency in practice. Method #2 is the most practical, same ordering for IP PSN - we should go this way. Having two MPLS PIDs value for this purpose is not really an issue here - if the packet needs to be self-describing (and it should), having the CW before the RTP won't help you here even in option #1 and #3. David > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net] > Sent: Saturday, May 17, 2003 1:51 AM > To: pwe3@ietf.org > Subject: [PWE3] TDM/SONET & RTP > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: TDM/SONET & RTP Date: Sun, 18 May 2003 13:17:12 +0300 Lines: 51 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Sun May 18 12:19:14 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] TDM/SONET & RTP Thread-Index: AcMdGfRmFShzZfhFTLynPz2ISvtcYwACv4tg To: "David Zelig" , "Danny McPherson" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4I9hbB32500 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I think correct layering in this case should be based on > functionality, not order of fields in the header. > RTP and CW are the same layer > in the sense that they start and terminate together. Good point. However, from the PWE point of view, the CW should be a "lower" layer since the PW architecture defines it (as an optional function); it is not the case that RTP defines PWs as an option of its payloads. Hence the RTP header should be closer to the payload and the CW closer to the MPLS labels. > > From practical point of view, both methods #1 and #3 require > different pointer interpretation with/without RTP, so CW processing > will be dependent on the RTP in these cases, - while keeping correct "layered" > order in fields ordering, it is wrong layered dependency in practice. We can decide on the meaning of the point from which the pointer references however we want. > Method #2 is the most practical, same ordering for IP PSN - > we should go this way. Method 1 can also be precisely the same for IP and MPLS, by defining an IP-Type for PWs (or perhaps two - for w/ and w/o RTP). For IP: For MPLS: L2 L2 IP with IP-type=PW outer label(s) UDP inner label CW CW [RTP] [RTP] Payload payload > Having two MPLS PIDs value for this purpose is not really an > issue here - if the packet needs to be self-describing (and it should), > having the CW before the RTP won't help you here even in option #1 and #3. See above. BTW, we never defined a static RTP-type for PWs either; so the "change in view" doesn't cost anything. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: TDM/SONET & RTP Date: Sun, 18 May 2003 13:28:33 +0200 Lines: 116 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Sun May 18 12:34:16 2003 Return-path: To: "'Danny McPherson'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Danny and all, I vote for Option 2 below with the following clarification: Encapsulation over IP looks like following: Demultiplexer (e.g., L2TPv3 header or UDP header) RTP (if needed) CEP header In other words, there is no need for MPLS PID/convergence layer for TDM/SONET traffic carried over an IP PSN. 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: Danny McPherson [mailto:danny@tcb.net] > Sent: Saturday, May 17, 2003 1:51 AM > To: pwe3@ietf.org > Subject: [PWE3] TDM/SONET & RTP > > > The following is an attempt by Stewart and I to generate one > final round of > discussions regarding this topic (and another in a following > email) and seek > some semblance of consensus from the WG. If you've got comments, > clarifications or additions to the following issue summary > please provide > them to the WG within the next week as we need to move forward ASAP. > > And whether we actively engage in any discussion or not, we > are listening. > > Thanks, > > Stewart/Danny > > > ============= > > There has been considerable discussion about the design of > the TDM/SONET PWE3 headers, and three candidates solutions > are on the table: > > 1) Use the same CW as is used for the packet encapsulations > and extend this with a second longword that contains any > necessary pointer information. This leads to the following > layering: > > MPLS PW Label > PWE3 Generic CW > PWE3 CW extension for pointer (if needed) > RTP (if needed) > > 2) Use a specialized CW (the CEP header) rather than the PW > generic CW, allowing all necessary information to be compressed > into 4 bytes. It results in the following layering: > > MPLS PW Label > MPLS PID or convergence layer to discriminate from IP > RTP (if needed) > CEP header > > There is some discussion as to whether the PID is a PID or > a convergence layer. Please can we discuss that issue on the > thread set up for that purpose. > > 3) Used a specialized CW (the CEP header) rather than the PW > generic CW, allowing all necessary information to be compressed > into 4 bytes. It results in the following layers: > > MPLS PW Label > MPLS PID or convergence layer to discriminate from IP > CEP header > RTP (if needed) > > Method 1 is highly controversial, but conforms to the PWE3 > architecture. It has the technical disadvantage that it > extends the minimum packet size in a non-ECMP network. > It has the practical disadvantage that it is not consistent > with any of the systems that are currently deployed / in > the late stages of design. > > Method 2 has a smaller minimum packet size than Method 1 > in a non-ECMP network, and the RTP/CEP layering is > identical for IP and MPLS networks. It does not > conform to the design of the CW used by most of the other > payloads. In strict architectural terms, the MPLS PID if > present should specify an RTP payload (if present), and > the CEP header should be specified as an RTP payload. > However since most experts in this area expect that the > majority of deployments will not use RTP, we end up with > two MPLS PID values and effectively two parallel > definitions of this PWE3 encapsulation. > > Method 3 was the method originally sketched out in the > PWE3 architecture draft. This has the disadvantage > that stack would not look the same on an IP PSN > and does not strictly conform to the RTP layering > model, but does define the payload as PWE3 at an > early stage. If it is assumed that RTP will not normally > be present, then the stack is more compact than > Method 1 on a non-ECMP network. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Sasha Vainshtein Subject: RE: TDM/SONET & RTP Date: Sun, 18 May 2003 14:28:07 +0200 Lines: 26 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: David Zelig , Danny McPherson , pwe3@ietf.org X-From: pwe3-admin@ietf.org Sun May 18 13:35:08 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Sunday, May 18, 2003 12:17 PM > To: David Zelig; Danny McPherson; pwe3@ietf.org > Subject: RE: [PWE3] TDM/SONET & RTP > > Method 1 can also be precisely the same for IP and MPLS, > by defining an IP-Type for PWs (or perhaps two - for w/ and w/o RTP). > IP Type today defines the type of protocol used for PW demultiplexing, e.g., L2TPv3 or (in case of TDM/SONET) UDP. Your proposal, if accepted, would effectively kill this. > ... snipped to the end ... From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: TDM/SONET & RTP Date: Sun, 18 May 2003 16:05:25 +0300 Lines: 13 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "David Zelig" , "Danny McPherson" , X-From: pwe3-admin@ietf.org Sun May 18 15:08:42 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] TDM/SONET & RTP Thread-Index: AcMdMRL1uhoAZr9qQVG6SqoErI+E3QADNe/A To: "Alexander Vainshtein" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4ICWCB09699 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > IP Type today defines the type of protocol used for PW demultiplexing, > e.g., L2TPv3 or (in case of TDM/SONET) UDP. Your proposal, if > accepted, would effectively kill this. I agree that this is the messy solution, which would require many types to be defined. I would much prefer using an IANA accepted UDP port number (which, as you now, is what we did for TDMoIP). Then UDP is clean, but we have a problem for L2TP. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mark Seery Subject: RE: FR OAM (was RE: PWE3 Arch/CW & RTP Order (Rough Conses us?)) Date: Sat, 17 May 2003 11:41:01 -0700 (PDT) Lines: 47 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Sun May 18 18:48:20 2003 Return-path: To: busschbach@lucent.com In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Thanks for the response Peter, Comments below, Mark --- "Busschbach, Peter B (Peter)" wrote: [snipped] > There is another aspect to this. In many (most?) > cases, Frame Relay services are carried across an > ATM backbone. Therefore, service providers can rely > on ATM's OAM functionality for fault > sectionalization etc. Agreed, on that part of the network. On the tail circults, and indeed all parts of the network, TDM OAM can be used, with the only limitation that it doesn't understand the logical topology of the client layers. > In fact, I think ATM's OAM > features were a major driver in the decision to > carry FR over an ATM backbone. If that is true, and I don't know one way or the other - I assumed that pipe size was a component, then that would be a very telling data point in terms of what OAM capabilities are desired by providers. Also, an alternative interpretation of this logic might be that a (robust) PSN (e.g. MPLS) OAM is sufficient to carry clients (i.e. FR) and their adaptation glue (PWE), and that it is up to the clients to determine what OAM they need, which may be similar or different; of course for true plug-and-play architectures, I guess all OAMs must be robust so that assumptions about underlying layers can be ignored. > Therefore, in answer to Mark's question below, I > think the PWE's OAM needs to resemble ATM's OAM in > order to make PWE a suitable vehicle for carrying > Frame Relay services. Which still leaves the question is PWE adaptation glue or a layer. If it is a layer, then I am a little confused about why MPLS and L2TP were created, but that's probably a different thread ;-) From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: Is PWE a layer? Date: Mon, 19 May 2003 08:22:37 +0300 Lines: 45 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Mon May 19 07:24:55 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: FR OAM (was RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Conses us?)) Thread-Index: AcMdXwaDhPxRVAfWQxKj+TsMv8R2HAAZNpwQ To: "Mark Seery" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4J4nNB02247 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > Therefore, in answer to Mark's question below, I > > think the PWE's OAM needs to resemble ATM's OAM in > > order to make PWE a suitable vehicle for carrying > > Frame Relay services. > > Which still leaves the question is PWE adaptation glue > or a layer. If it is a layer, then I am a little > confused about why MPLS and L2TP were created, but > that's probably a different thread ;-) So let's start that thread. First, is MPLS a layer network? Although originally thought of as an in-between shim, it later became "layer 2.5" and we now certainly seem to be making it into a full layer network. By elevating it to a network we define not only its user plane protocols, OAM, etc., we also invent new terminology and a whole new group of experts who are more familiar with it than those layers above and below it. If we now turn the PWE into a new layer between MPLS and the payload, then in addition to the encap protocols and the terminology we have already defined, we must start the formal treatment of control and management issues. As Mark asks, do we really need ANOTHER full network layer in between, or can PWs simply transparently carry EVERYTHING (OAM in addition to user data) transparently? As long as we limit ourselves to the pure network interworking case, we don't - we can leave PWs as an encap-only technology. In network interworking one carries the native service's OAM messages, while in service interworking one needs to translate states. So as long as we keep service interworking out of scope, we don't need "PW-OAM", and the answer to Mark's question is that we DON'T want to make PW into a layer network. Once service interworking IS allowed, the present PWE encap technology is no longer sufficient anyway. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mark Seery Subject: Re: Is PWE a layer? Date: Sun, 18 May 2003 22:54:37 -0700 (PDT) Lines: 18 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5283B401@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 07:56:33 2003 Return-path: To: Yaakov Stein In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5283B401@exrad2.ad.rad.co.il> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Yaakov, Thats for the response. [SNIP] > So as long as we keep service interworking out of > scope, > we don't need "PW-OAM", and the answer to Mark's > question > is that we DON'T want to make PW into a layer > network. Wondering why service interworking requires that PW be a layer. 1483 and 1490 are interworked without the requirement that they be layers - or did I misunderstand? Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Is PWE a layer? Date: Mon, 19 May 2003 09:35:07 +0300 Lines: 59 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Mon May 19 08:37:59 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Is PWE a layer? Thread-Index: AcMdyyN4EYIGYMjSTsCA2MDdtbT8GAAAmThg To: "Mark Seery" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4J61sB06874 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Wondering why service interworking requires that PW be > a layer. 1483 and 1490 are interworked without the > requirement that they be layers - or did I > misunderstand? Mark, Perhaps I am not understanding your question, so please let me define my terms. By network interworking I mean tunelling a native service over a network, with the SAME native service at both edges. Thus both 1483 and 1490 provide mechanisms for network interworking, e.g. IP datagrams over ATM or FR relay, respectively. By service interworking I mean connecting DIFFERENT native services to the edges of a network, without first providing an IWF that converts one of the native services to the other. Thus connecting a FR service to one edge and an ATM service to the other edge is service interworking. However, if I first convert the FR into ATM, or the ATM into FR, and use a pure FR or pure ATM encap PW, then this is still network interworking. Since network interworking has like services at both edges, we can transparently tunnel the OAM as well, and the PW can be a pure encap format, and needn't be a "layer". True service interworking is more complex. For example, assume network of type A is connecting to network of type C over a transporting network B. It is required to translate A's defect states into native B format at the A-B edge, and then translate them into C's format at edge B-C. To understand why this is absolutely required, consider that in the true service interworking scenario, network A does not know what the native format of network C is - it might be FR or it might be ATM, etc. So the A-B edge can not "pre-translate" the messages into C format. This is particular acute in p2mp scenarios. Of course we COULD get away with such translations. For example, although network C does not know a priori what type of network A is, this COULD be kludged by having part of the B network format include the source network type, and to place at the egress edge the intelligence to "post-translate" messages. Or we could signal C's network type back to A at setup, and perform the pre-translation. But, in addition to being undesirable, these kludges effectively make the scenario network interworking at the control plane, even if the user plane is service interworking. So what did you mean by 1483-1490 interworking? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mark Seery Subject: RE: Is PWE a layer? Date: Mon, 19 May 2003 00:13:14 -0700 (PDT) Lines: 62 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5283B402@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 09:14:38 2003 Return-path: To: Yaakov Stein , Mark Seery In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5283B402@exrad2.ad.rad.co.il> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, --- Yaakov Stein wrote: > By network interworking I mean tunelling a native service over a network, with the SAME native service at both edges. < Agreed. > Thus both 1483 and 1490 provide mechanisms for network interworking, e.g. IP datagrams over ATM or FR relay, respectively. < Hmmmmm, they both provide a mechanism for identifying what the upper layer protocol is in the frame being sent over that VC. They are an adaptation layer. When I think of networking interworking I think of standards like FRF 5 where the client layer characteristics are actually mapped to the underying service layer, i.e. ATM ensures that the Frame Relay service gets the support it needs so that the ATM network is transparent to each end, and the integrity of the Frame Service is maintained. > [SNIP]...Thus connecting a FR service to one edge and an ATM service to the other edge is service interworking. < Agreed. > However, if I first convert the FR into ATM, or the ATM into FR, and use a pure FR or pure ATM encap PW, then this is still network interworking. < Hmmmmmm, not sure. From the end-to-end point of view it would seem there is some service interworking. Certainly in FRF8 (FR/ATM Service interworking) frame is converted to ATM. > Since network interworking has like services at both edges, we can transparently tunnel the OAM as well, and the PW can be a pure encap format, and needn't be a "layer". < Agreed on PW encap. Whether SPs want to take advantage of an underlying segment OAM by mapping (interworking) client / server OAMs I do not know. For example interworking Frame and MPLS OAM (hypothetically speaking because I don't think Frame OAM supports segment OAM). > [SNIP] True service interworking is more complex.......< Agreed > So what did you mean by 1483-1490 interworking? I was referring to the translation mode ("Mode 2") of FRF 8 (FR/ATM PVC service interworking) Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mark Seery Subject: Re: Is PWE a layer? Date: Mon, 19 May 2003 00:26:07 -0700 (PDT) Lines: 13 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5283B401@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 09:27:16 2003 Return-path: To: Yaakov Stein In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5283B401@exrad2.ad.rad.co.il> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, --- Yaakov Stein wrote: [SNIP] >> First, is MPLS a layer network? Although originally thought of as an in-between shim, it later became "layer 2.5" and we now certainly seem to be making it into a full layer network. << BTW, not sure if you meant this as a warning/caution, but if you did, point taken, and I agree. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: FR OAM (was RE: PWE3 Arch/CW & RTP Order (Rough Conses us?)) Date: Mon, 19 May 2003 09:01:14 +0100 Lines: 76 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Shahram_Davari@pmc-sierra.com, dallan@nortelnetworks.com, yaakov_s@rad.co.il, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 10:04:23 2003 Return-path: To: busschbach@lucent.com, mark@mseery.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Peter, Busschbach, Peter B (Peter) wrote to Mark Seery 17 May 2003 19:20 > [snipped] > > > > > This all begs the question that if OAM is so important, then > > how did Frame > > Relay become so successful without it? Well ultimately that > > is a question > > for a service provider to answer, I would just observe that a > > number of SPs > > view FR as a best effort service. Undoubtedly QoS is part of that > > assessment, but there are probably other considerations as > > well; and of > > course some SPs view a strong OAM capability as being key to > > being offer > > strong QoS. > > > > There is another aspect to this. In many (most?) cases, Frame > Relay services are carried across an ATM backbone. Therefore, > service providers can rely on ATM's OAM functionality for > fault sectionalization etc. In fact, I think ATM's OAM > features were a major driver in the decision to carry FR over > an ATM backbone. NH=> You may also like to observe that FR/ATM *service* interworking is key....why? For the simple reason that operators don't want to run a stovepipe 'technology per service' regime and customers don't want to do a fork-lift change-out of CPE.....both of these communities have a need to reduce opex/capex and protect investments. Exactly the same issues hold for MPLS.....that is, when technologies belong to the *same* networking mode (in this case co pkt-sw) one should be striving for functional convergence across those technologies (and this implies a need for service interworking). {Note - This is *not* the same as convergence across all modes (cnls, co pkt-sw and co cct-sw) as that simply does not work technically/commercially.} So, for those operators who have large FR/ATM networks deployed which are earning real revenue and who have MPLS on the road-map as the core co pkt-sw technology, then I would suggest they should be thinking very carefully about this and looking at what is going on in PWE3 and what it means for their networks....ditto the key suppliers to those operators who also show MPLS as the core technology. One factor that becomes obvious when *service* interworking is considered is that the PW entity as currently defined is not required.....its just something else to manage/interwork and thus represents an unecessary cost/problem for an operator. We need simple clinet->server adaptation and simple OAM applied to the p2p LSPs that run between PE devices as defined in Y.1711 (and we don't want PW OAM that resides *above* this). Any mp2p LSPs underneath this can use LSP-Ping. > > Therefore, in answer to Mark's question below, I think the > PWE's OAM needs to resemble ATM's OAM in order to make PWE a > suitable vehicle for carrying Frame Relay services. NH=> Peter, it is not the *PW's* OAM that is required its the LSP's OAM that is required, ie the OAM is relevant to the networked entities and not the adapatation entities (ie the client->server mapping). One final point that some people may not be aware of: When I wrote the orginal drafts of Y.1710 (requirements) and Y.1711 (mechanisms) I did so with the 3 mode functional convergence vision in mind. That is, the functional behaviour of Y.1711 can be applied to *any* co pkt-sw mode technology. Further, it is about as lightweight yet powerful as you can get....it only defines 3 basic pkts for defect detection/handling: CV pkts to ensure correct connectivity and FDI/BDI pkts (forward/backward defect indicators) to indicate failures (inc 'where' and 'which'). All the defects are fully specified (ie entry/exit criteria) together with their required consequent actions. Further, availabiilty states (both directions) are also defined (and you need this if you then want any sort of sensible measurement basis for up-state QoS metrics/objectives). Unless one has considered/specified all these aspects then one does not have a proper OAM solution. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Tim.Frost@Zarlink.Com Subject: Re: TDM/SONET & RTP Date: Mon, 19 May 2003 09:47:25 +0100 Lines: 138 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: X-From: pwe3-admin@ietf.org Mon May 19 11:01:46 2003 Return-path: To: Danny McPherson X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.11 |July 24, 2002) at 05/19/2003 04:58:20 AM, Serialize complete at 05/19/2003 04:58:20 AM Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I'm curious to know why the stack in option 2: MPLS PW Label MPLS PID or convergence layer to discriminate from IP RTP CEP header requires the MPLS PID to discriminate RTP from IP (4 or 6). Looking at the RTP header (from RFC 1889): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ assuming that TDM PWs will not use either padding (P=0) or header extension (X=0), then the first nibble will be 1000. This does not conflict with either IPv4 or IPv6. Even if the RTP version incremented, or the padding/extensions were used, it could not conflict with IP - at least not until we are on IPv8 or higher, which judging by the amount of time its taken to establish IPv6 will be a long way ahead. Is there a reason why that first nibble must be 0000, rather than 1000 (or any other value that is not 0100 or 0110)? Of course, if the RTP was removed, and the underlying control word used the CEP format, then there is an issue. Therefore the CW should either use the generic format with an extension, or an MPLS PID. The net result is the same, a 64 bit header, although at least if the generic CW is used, then should the extension not be required, the size can be reduced. Therefore my vote would be for the order of option 2 (for the reasons David Zelig expressed about the pointer processing being dependent on RTP presence or not if the CW precedes RTP), but with a generic CW and extension for pointer if required (i.e. option 1 CW). Tim Danny McPherson Sent by: pwe3-admin@ietf.org 17-May-2003 12:50 AM To: cc: Subject: [PWE3] TDM/SONET & RTP The following is an attempt by Stewart and I to generate one final round of discussions regarding this topic (and another in a following email) and seek some semblance of consensus from the WG. If you've got comments, clarifications or additions to the following issue summary please provide them to the WG within the next week as we need to move forward ASAP. And whether we actively engage in any discussion or not, we are listening. Thanks, Stewart/Danny ============= There has been considerable discussion about the design of the TDM/SONET PWE3 headers, and three candidates solutions are on the table: 1) Use the same CW as is used for the packet encapsulations and extend this with a second longword that contains any necessary pointer information. This leads to the following layering: MPLS PW Label PWE3 Generic CW PWE3 CW extension for pointer (if needed) RTP (if needed) 2) Use a specialized CW (the CEP header) rather than the PW generic CW, allowing all necessary information to be compressed into 4 bytes. It results in the following layering: MPLS PW Label MPLS PID or convergence layer to discriminate from IP RTP (if needed) CEP header There is some discussion as to whether the PID is a PID or a convergence layer. Please can we discuss that issue on the thread set up for that purpose. 3) Used a specialized CW (the CEP header) rather than the PW generic CW, allowing all necessary information to be compressed into 4 bytes. It results in the following layers: MPLS PW Label MPLS PID or convergence layer to discriminate from IP CEP header RTP (if needed) Method 1 is highly controversial, but conforms to the PWE3 architecture. It has the technical disadvantage that it extends the minimum packet size in a non-ECMP network. It has the practical disadvantage that it is not consistent with any of the systems that are currently deployed / in the late stages of design. Method 2 has a smaller minimum packet size than Method 1 in a non-ECMP network, and the RTP/CEP layering is identical for IP and MPLS networks. It does not conform to the design of the CW used by most of the other payloads. In strict architectural terms, the MPLS PID if present should specify an RTP payload (if present), and the CEP header should be specified as an RTP payload. However since most experts in this area expect that the majority of deployments will not use RTP, we end up with two MPLS PID values and effectively two parallel definitions of this PWE3 encapsulation. Method 3 was the method originally sketched out in the PWE3 architecture draft. This has the disadvantage that stack would not look the same on an IP PSN and does not strictly conform to the RTP layering model, but does define the payload as PWE3 at an early stage. If it is assumed that RTP will not normally be present, then the stack is more compact than Method 1 on a non-ECMP network. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: TDM/SONET & RTP Date: Mon, 19 May 2003 10:39:46 +0100 Organization: Cisco Systems, Inc. Lines: 29 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Danny McPherson , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 11:45:39 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: Tim.Frost@zarlink.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > assuming that TDM PWs will not use either padding (P=0) or header > extension (X=0), then the first nibble will be 1000. This does not > conflict with either IPv4 or IPv6. Even if the RTP version incremented, or > the padding/extensions were used, it could not conflict with IP - at least > not until we are on IPv8 or higher, which judging by the amount of time > its taken to establish IPv6 will be a long way ahead. > Is there a reason why that first nibble must be 0000, rather than 1000 (or > any other value that is not 0100 or 0110)? > IPv8 exists, although I doubt very widely. Stewart Stewart Decimal Keyword Version References ------- ------- ------- ---------- 0 Reserved [JBP] 1-3 Unassigned [JBP] 4 IP Internet Protocol [RFC791,JBP] 5 ST ST Datagram Mode [RFC1190,JWF] 6 IPv6 Internet Protocol version 6 [RFC1752] 7 TP/IX TP/IX: The Next Internet [RXU] 8 PIP The P Internet Protocol [PXF] 9 TUBA TUBA [RXC] 10-14 Unassigned [JBP] 15 Reserved [JBP] From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Ron Cohen" Subject: RE: TDM/SONET & RTP Date: Mon, 19 May 2003 13:46:31 +0200 Lines: 173 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B3FB2CE@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Mon May 19 12:50:02 2003 Return-path: To: , "'Danny McPherson'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <89D0584BBFBFE74F9057A389BA3F239B3FB2CE@gaya.lycium.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tim, > I'm curious to know why the stack in option 2: > > MPLS PW Label > MPLS PID or convergence layer to discriminate from IP > RTP > CEP header > > requires the MPLS PID to discriminate RTP from IP (4 or 6). 1. Because the 4 bits are used as PID, and RTP would exhaust 1-5 other values from the non-allocated pool, assuming the version is fixed. Its not only IPv4/v6 discrimination. 2. Assumption on the RTP header usage (e.g. P=X=0) are ok only for the short term, but are not a good idea in the long run. Layers should be decoupled, to allow someone developing over RTP not to worry to much over the lower layers restrictions. Ron > > Looking at the RTP header (from RFC 1889): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V=2|P|X| CC |M| PT | sequence number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > assuming that TDM PWs will not use either padding (P=0) or header > extension (X=0), then the first nibble will be 1000. This does not > conflict with either IPv4 or IPv6. Even if the RTP version > incremented, or > the padding/extensions were used, it could not conflict with > IP - at least > not until we are on IPv8 or higher, which judging by the > amount of time > its taken to establish IPv6 will be a long way ahead. > Is there a reason why that first nibble must be 0000, rather > than 1000 (or > any other value that is not 0100 or 0110)? > > Of course, if the RTP was removed, and the underlying control > word used > the CEP format, then there is an issue. Therefore the CW > should either use > the generic format with an extension, or an MPLS PID. The net > result is > the same, a 64 bit header, although at least if the generic > CW is used, > then should the extension not be required, the size can be reduced. > > Therefore my vote would be for the order of option 2 (for the reasons > David Zelig expressed about the pointer processing being > dependent on RTP > presence or not if the CW precedes RTP), but with a generic CW and > extension for pointer if required (i.e. option 1 CW). > > Tim > > > > > > Danny McPherson > Sent by: pwe3-admin@ietf.org > 17-May-2003 12:50 AM > > > To: > cc: > Subject: [PWE3] TDM/SONET & RTP > > > The following is an attempt by Stewart and I to generate one > final round > of > discussions regarding this topic (and another in a following > email) and > seek > some semblance of consensus from the WG. If you've got > comments, clarifications or additions to the following issue > summary please provide them to the WG within the next week as > we need to move forward ASAP. > > And whether we actively engage in any discussion or not, we > are listening. > > Thanks, > > Stewart/Danny > > > ============= > > There has been considerable discussion about the design of > the TDM/SONET PWE3 headers, and three candidates solutions > are on the table: > > 1) Use the same CW as is used for the packet encapsulations > and extend this with a second longword that contains any > necessary pointer information. This leads to the following > layering: > > MPLS PW Label > PWE3 Generic CW > PWE3 CW extension for pointer (if needed) > RTP (if needed) > > 2) Use a specialized CW (the CEP header) rather than the PW > generic CW, allowing all necessary information to be compressed > into 4 bytes. It results in the following layering: > > MPLS PW Label > MPLS PID or convergence layer to discriminate from IP > RTP (if needed) > CEP header > > There is some discussion as to whether the PID is a PID or > a convergence layer. Please can we discuss that issue on the > thread set up for that purpose. > > 3) Used a specialized CW (the CEP header) rather than the PW > generic CW, allowing all necessary information to be compressed > into 4 bytes. It results in the following layers: > > MPLS PW Label > MPLS PID or convergence layer to discriminate from IP > CEP header > RTP (if needed) > > Method 1 is highly controversial, but conforms to the PWE3 > architecture. It has the technical disadvantage that it > extends the minimum packet size in a non-ECMP network. It has > the practical disadvantage that it is not consistent with any > of the systems that are currently deployed / in the late > stages of design. > > Method 2 has a smaller minimum packet size than Method 1 > in a non-ECMP network, and the RTP/CEP layering is > identical for IP and MPLS networks. It does not > conform to the design of the CW used by most of the other > payloads. In strict architectural terms, the MPLS PID if > present should specify an RTP payload (if present), and the > CEP header should be specified as an RTP payload. However > since most experts in this area expect that the majority of > deployments will not use RTP, we end up with two MPLS PID > values and effectively two parallel definitions of this PWE3 > encapsulation. > > Method 3 was the method originally sketched out in the > PWE3 architecture draft. This has the disadvantage > that stack would not look the same on an IP PSN > and does not strictly conform to the RTP layering > model, but does define the payload as PWE3 at an > early stage. If it is assumed that RTP will not normally > be present, then the stack is more compact than > Method 1 on a non-ECMP network. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Tim.Frost@Zarlink.Com Subject: RE: TDM/SONET & RTP Date: Mon, 19 May 2003 12:02:48 +0100 Lines: 104 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 13:17:18 2003 Return-path: To: "Yaakov Stein" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.11 |July 24, 2002) at 05/19/2003 07:13:41 AM, Serialize complete at 05/19/2003 07:13:41 AM Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, Looking at draft-anavi-tdmoip-05 (March '03), the first nibble of your control word is actually the FORMID, not 0000. At present this can take on the following values: 0, 8, 9, 12, 13, 14, and 15. Based on Stewart's last email therefore, there is a theoretical (albeit probably very small) chance that a draft-anavi implementation could be mistaken for one of these other IP types, e.g. PIP or TUBA. I agree that from a practical point of view, the range of FORMID values may run very little chance of causing a conflict, but it is certainly not a standard PWE CW (even the sequence number is different). Also, draft-anavi places the RTP header before the CW, not after (although as you frequently point out you never actually use RTP). Presumably if you did use it in an MPLS network, it could not be discriminated from FORMID=8. You conclude your argument for option 1 by referring to the number of field deployments. > With multiple interoperable implementations in the field, > any change from the standard CW (even were such a change > to be advisable) would be too costly at this point. So, are you going to change your own implementation to meet the rules you are so keen to impose on everyone else? Tim "Yaakov Stein" Sent by: pwe3-admin@ietf.org 18-May-2003 06:55 AM To: cc: Subject: RE: [PWE3] TDM/SONET & RTP Stewart/Danny > 1) Use the same CW as is used for the packet encapsulations > and extend this with a second longword that contains any > necessary pointer information. This leads to the following > layering: > > MPLS PW Label > PWE3 Generic CW > PWE3 CW extension for pointer (if needed) > RTP (if needed) > Method 1 is highly controversial, but conforms to the PWE3 > architecture. It has the technical disadvantage that it > extends the minimum packet size in a non-ECMP network. > It has the practical disadvantage that it is not consistent > with any of the systems that are currently deployed / in > the late stages of design. I disagree with the reasoning regarding the disadvantages. Method 1 does NOT extend the minimum packet size any more than methods 2 and 3. When the extension is NOT needed, we have only the standard generic PWE CW. When it IS needed, we indeed add an additional 32 bits, but the other two methods add an MPLS PID of 32 bits as well. Hence, there is NO size disadvantage in relation to the other two methods. The practical disadvantage is somewhat more worrying. However, I believe that ANY change at this point will require SOME re-engineering to those systems that did not reserve the first nibble after the PW label (something we have been warning about for a long time). So I vote for method 1 - the generic PWE method. If this is deemed impractical because of pre-standard implementations being too hard to rework, then I vote for method 3, where the RTP is considered a higher layer than the PW. However, I doubt that for the SONET case anyone cares about the difference between 2 and 3, since RTP is NOT used. So we return to the low-rate TDM case. Returning to the argument about re-engineering, the dominant low-rate TDM implementation in the marketplace uses the standard PWE CW, and not the CEP header. I strenuously argue that this should stay this way. With multiple interoperable implementations in the field, any change from the standard CW (even were such a change to be advisable) would be too costly at this point. Y(J)S _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: Re: TDM/SONET & RTP Date: Mon, 19 May 2003 07:22:28 -0400 Lines: 52 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 13:24:56 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: stbryant@cisco.com In-Reply-To: <3EC8A662.3030707@cisco.com> X-OriginalArrivalTime: 19 May 2003 11:22:33.0387 (UTC) FILETIME=[F14BAFB0:01C31DF8] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, IPv8 was only a proposal, I highly doubt that Paul Francis (or anyone else for that matter) implemented it. And I'm sure you knew that the P in "P Internet Protocol" stood for "Paul"? :-) Getting back on the topic of this thread, I agree with Ron, David, and Sasha, option 2 with the current CW is the way to go. While I also agree with Tim about using option 2, I disagree with him about using the generic CW - as Ron said, different requirements lead to a different CW. Thanks, Andy --------- At 5/19/2003 10:39 AM +0100, Stewart Bryant wrote: >>assuming that TDM PWs will not use either padding (P=0) or header >>extension (X=0), then the first nibble will be 1000. This does not >>conflict with either IPv4 or IPv6. Even if the RTP version incremented, >>or the padding/extensions were used, it could not conflict with IP - at >>least not until we are on IPv8 or higher, which judging by the amount of >>time its taken to establish IPv6 will be a long way ahead. >>Is there a reason why that first nibble must be 0000, rather than 1000 >>(or any other value that is not 0100 or 0110)? > >IPv8 exists, although I doubt very widely. > >Stewart > >Stewart > >Decimal Keyword Version References >------- ------- ------- ---------- > 0 Reserved [JBP] > 1-3 Unassigned [JBP] > 4 IP Internet Protocol [RFC791,JBP] > 5 ST ST Datagram Mode [RFC1190,JWF] > 6 IPv6 Internet Protocol version 6 [RFC1752] > 7 TP/IX TP/IX: The Next Internet [RXU] > 8 PIP The P Internet Protocol [PXF] > 9 TUBA TUBA [RXC] >10-14 Unassigned [JBP] > 15 Reserved [JBP] > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Stewart Bryant Subject: Re: TDM/SONET & RTP Date: Mon, 19 May 2003 12:48:53 +0100 Organization: Cisco Systems, Inc. Lines: 15 Sender: pwe3-admin@ietf.org References: <5.2.1.1.0.20030519071044.026260c8@mail.attbi.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 13:53:06 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "Andrew G. Malis" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andrew G. Malis wrote: > Stewart, > > IPv8 was only a proposal, I highly doubt that Paul Francis (or anyone > else for that matter) implemented it. And I'm sure you knew that the P > in "P Internet Protocol" stood for "Paul"? :-) > If we need the value 8 then we can't just kidknap it, we have to go through the formality of getting it reserved. If we don't then there is a danger of some other application reclaiming it and using it. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: Is PWE a layer? Date: Mon, 19 May 2003 16:25:14 +0300 Lines: 57 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Mon May 19 15:36:31 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Is PWE a layer? Thread-Index: AcMd1h/ST5kCUrhRTI6OkvdJ0YQLGwAMuYgw To: "Mark Seery" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4JCs9B15667 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > Thus both 1483 and 1490 provide mechanisms for > network interworking, e.g. IP datagrams over ATM or FR > relay, respectively. < > > Hmmmmm, they both provide a mechanism for identifying > what the upper layer protocol is in the frame being > sent over that VC. They are an adaptation layer. When > I think of networking interworking I think of > standards like FRF 5 where the client layer > characteristics are actually mapped to the underying > service layer, i.e. ATM ensures that the Frame Relay > service gets the support it needs so that the ATM > network is transparent to each end, and the integrity > of the Frame Service is maintained. You are saying that 1483/90 are deficient network interworking, and I agree. > > However, if I first convert the FR into ATM, or the > ATM into FR, and use a pure FR or pure ATM encap PW, > then this is still network interworking. < > > Hmmmmmm, not sure. From the end-to-end point of view > it would seem there is some service interworking. > Certainly in FRF8 (FR/ATM Service interworking) frame > is converted to ATM. Right. What I am saying is that from the PW point of view, there is NO service interworking, that is no "service interworking over MPLS". The service interworking being performed is direct FR-ATM service interworking, and does not impact the PW. > > So what did you mean by 1483-1490 interworking? > > I was referring to the translation mode ("Mode 2") of > FRF 8 (FR/ATM PVC service interworking) That's what I thought (see my comment above). My bottom line is that we needn't reinvent the wheel because of the requirement for what you called "end-to-end service interworking". If we can do the interworking before we get to the MPLS network, we can stick to PWs and bypass the issue. The question is whether we want to make MPLS into the new "universal network", relegating all others to status of legacy access technologies. Were this to happen, then indeed one access network might not know what the other access network's type is. In THAT case we can no longer use PWs, and have to go for true service interworking with MPLS. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Yaakov Stein" Subject: RE: TDM/SONET & RTP Date: Mon, 19 May 2003 16:30:57 +0300 Lines: 37 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Mon May 19 15:38:02 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] TDM/SONET & RTP Thread-Index: AcMd97aUKDis2FI3QduV9eRh52cYkgAEuBxA To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4JCwpB16011 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tim, > Looking at draft-anavi-tdmoip-05 (March '03), the first > nibble of your control word is actually the FORMID, not 0000. At present > this can take on the following values: 0, 8, 9, 12, 13, 14, > and 15. > > Based on Stewart's last email therefore, there is a > theoretical (albeit probably very small) chance that a draft-anavi implementation > could be mistaken for one of these other IP types, e.g. PIP or TUBA. I > agree that from a practical point of view, the range of FORMID values > may run very little chance of causing a conflict, but it is certainly not > a standard PWE CW (even the sequence number is different). I hadn't known about PIP and TUBA, and will look into it. > Also, draft-anavi places the RTP header before the CW, not > after (although as you frequently point out you never actually use RTP). > Presumably if you did use it in an MPLS network, it could not be discriminated from > FORMID=8. > > You conclude your argument for option 1 by referring to the number of > field deployments. > > > With multiple interoperable implementations in the field, > > any change from the standard CW (even were such a change > > to be advisable) would be too costly at this point. > > So, are you going to change your own implementation to meet > the rules you are so keen to impose on everyone else? Absolutely. I have already made the change in my documentation, and the next revision of draft-anavi will reflect this, unless the WG decides otherwise. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Andrew G. Malis" Subject: Re: TDM/SONET & RTP Date: Mon, 19 May 2003 09:57:21 -0400 Lines: 22 Sender: pwe3-admin@ietf.org References: <5.2.1.1.0.20030519071044.026260c8@mail.attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 16:04:07 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: stbryant@cisco.com In-Reply-To: <3EC8C4A5.7000904@cisco.com> X-OriginalArrivalTime: 19 May 2003 13:57:29.0975 (UTC) FILETIME=[967E7070:01C31E0E] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, Absolutely. My point was that if we make the request, I don't anticipate there being much opposition. Andy ------- At 5/19/2003 12:48 PM +0100, Stewart Bryant wrote: >Andrew G. Malis wrote: >>Stewart, >>IPv8 was only a proposal, I highly doubt that Paul Francis (or anyone >>else for that matter) implemented it. And I'm sure you knew that the P >>in "P Internet Protocol" stood for "Paul"? :-) > >If we need the value 8 then we can't just kidknap it, we have to go through >the formality of getting it reserved. If we don't then there is a danger >of some other application reclaiming it and using it. > >Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Is PWE a layer? Date: Mon, 19 May 2003 15:18:41 -0400 Lines: 89 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 21:24:56 2003 Return-path: To: "'Yaakov Stein'" , Mark Seery X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Monday, May 19, 2003 1:23 AM > To: Mark Seery; busschbach@lucent.com > Cc: pwe3@ietf.org > Subject: Is PWE a layer? > > > > > Therefore, in answer to Mark's question below, I > > > think the PWE's OAM needs to resemble ATM's OAM in > > > order to make PWE a suitable vehicle for carrying > > > Frame Relay services. > > > > Which still leaves the question is PWE adaptation glue > > or a layer. If it is a layer, then I am a little > > confused about why MPLS and L2TP were created, but > > that's probably a different thread ;-) > > So let's start that thread. > > First, is MPLS a layer network? > Although originally thought of as an in-between shim, > it later became "layer 2.5" and we now certainly seem to be > making it into a full layer network. > > By elevating it to a network we define not only its > user plane protocols, OAM, etc., we also invent > new terminology and a whole new group of experts > who are more familiar with it than those layers > above and below it. > > If we now turn the PWE into a new layer > between MPLS and the payload, then in addition to > the encap protocols and the terminology we have already defined, > we must start the formal treatment of control and management issues. > > As Mark asks, do we really need ANOTHER full network layer > in between, or can PWs simply transparently carry EVERYTHING > (OAM in addition to user data) transparently? > Yaakov, My view: - No, we don't need another full network layer - Yes, PWs can (must) carry everything, including client-layer OAM traffic. But there are a few caveats: a) TTL > 2 Eric Rosen made the point that there are cases in which it makes sense to splice PWs together and switch based on the PW label. IMO, that turns the "PW layer" into an MPLS layer. (It makes you wonder why there is a PW layer in the first place. Why not define how to adapt client traffic to MPLS (i.e. remove the demultiplexing function from PWE) and leave it to the service provider to decide whether there is a need for additional aggregation via MPLS label stacking.) b) There is a need for OAM in the server layer. When a service provider carries encapsulated traffic through a nation-wide core network, it is not enough to merely have a continuity check between the encapsulation point and the decapsulation point. E.g. if a failure occurs in the core network, the service provider needs to be able to determine as precisely as possible what the failure is and where it is located. c) OAM and MPLS In an MPLS network with MP2P and ECMP it is hard to do good OAM (see Neil's emails). Hence, the proposal in the VCCV draft to encapsulate the Ping message with the same label stack as the client traffic, including the PW label. In an earlier email, I made the argument that if you can't do OAM in the MPSL layer, you need to treat the PW as a point-to-point link and do OAM on the PW. However, this is far from ideal. Since the PW is essentially a direct link between two peers, you can't use it for fault localization in the core network. The more I think about it, the more I believe that: (1) You need robust OAM in the MPLS layer. If you have MPLS OAM you don't need PW OAM. (2) in the absence of MPLS OAM, you might decide to do connectivity verification on a per-PW basis, but it is a poor alternative. Peter > As long as we limit ourselves to the pure network interworking > case, we don't - we can leave PWs as an encap-only technology. > > In network interworking one carries the native service's OAM messages, > while in service interworking one needs to translate states. > So as long as we keep service interworking out of scope, > we don't need "PW-OAM", and the answer to Mark's question > is that we DON'T want to make PW into a layer network. > > Once service interworking IS allowed, the present PWE encap > technology > is no longer sufficient anyway. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: neil.2.harrison@bt.com Subject: RE: RE: Is PWE a layer? Date: Mon, 19 May 2003 21:13:27 +0100 Lines: 134 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon May 19 22:44:58 2003 Return-path: To: busschbach@lucent.com, yaakov_s@rad.com, mark@mseery.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Well done Peter! You are starting to piece it all together now....once you grasp what is really needed it becomes obvious. It becomes even more obvious in the case of service-interworking if one does the proper G.805 functional modelling (and I know some guys working on that right now), which is a precursor to building good information models for management. regards, Neil > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: 19 May 2003 20:19 > To: 'Yaakov Stein'; Mark Seery > Cc: pwe3@ietf.org > Subject: [PWE3] RE: Is PWE a layer? > > > > > > -----Original Message----- > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > Sent: Monday, May 19, 2003 1:23 AM > > To: Mark Seery; busschbach@lucent.com > > Cc: pwe3@ietf.org > > Subject: Is PWE a layer? > > > > > > > > Therefore, in answer to Mark's question below, I > > > > think the PWE's OAM needs to resemble ATM's OAM in > > > > order to make PWE a suitable vehicle for carrying > > > > Frame Relay services. > > > > > > Which still leaves the question is PWE adaptation glue > > > or a layer. If it is a layer, then I am a little > > > confused about why MPLS and L2TP were created, but > > > that's probably a different thread ;-) > > > > So let's start that thread. > > > > First, is MPLS a layer network? > > Although originally thought of as an in-between shim, > > it later became "layer 2.5" and we now certainly seem to be > > making it into a full layer network. > > > > By elevating it to a network we define not only its > > user plane protocols, OAM, etc., we also invent > > new terminology and a whole new group of experts > > who are more familiar with it than those layers > > above and below it. > > > > If we now turn the PWE into a new layer > > between MPLS and the payload, then in addition to > > the encap protocols and the terminology we have already defined, > > we must start the formal treatment of control and management issues. > > > > As Mark asks, do we really need ANOTHER full network layer > > in between, or can PWs simply transparently carry EVERYTHING > > (OAM in addition to user data) transparently? > > > > Yaakov, > > My view: > > - No, we don't need another full network layer > - Yes, PWs can (must) carry everything, including > client-layer OAM traffic. > > But there are a few caveats: > > a) TTL > 2 > Eric Rosen made the point that there are cases in which it > makes sense to splice PWs together and switch based on the PW > label. IMO, that turns the "PW layer" into an MPLS layer. > (It makes you wonder why there is a PW layer in the first > place. Why not define how to adapt client traffic to MPLS > (i.e. remove the demultiplexing function from PWE) and leave > it to the service provider to decide whether there is a need > for additional aggregation via MPLS label stacking.) > > b) There is a need for OAM in the server layer. > When a service provider carries encapsulated traffic through > a nation-wide core network, it is not enough to merely have a > continuity check between the encapsulation point and the > decapsulation point. E.g. if a failure occurs in the core > network, the service provider needs to be able to determine > as precisely as possible what the failure is and where it is located. > > c) OAM and MPLS > In an MPLS network with MP2P and ECMP it is hard to do good > OAM (see Neil's emails). Hence, the proposal in the VCCV > draft to encapsulate the Ping message with the same label > stack as the client traffic, including the PW label. > > In an earlier email, I made the argument that if you can't do > OAM in the MPSL layer, you need to treat the PW as a > point-to-point link and do OAM on the PW. However, this is > far from ideal. Since the PW is essentially a direct link > between two peers, you can't use it for fault localization in > the core network. > > The more I think about it, the more I believe that: > > (1) You need robust OAM in the MPLS layer. If you have MPLS > OAM you don't need PW OAM. > > (2) in the absence of MPLS OAM, you might decide to do > connectivity verification on a per-PW basis, but it is a poor > alternative. > > Peter > > > > > As long as we limit ourselves to the pure network interworking > > case, we don't - we can leave PWs as an encap-only technology. > > > > In network interworking one carries the native service's > OAM messages, > > while in service interworking one needs to translate states. > > So as long as we keep service interworking out of scope, > > we don't need "PW-OAM", and the answer to Mark's question > > is that we DON'T want to make PW into a layer network. > > > > Once service interworking IS allowed, the present PWE encap > > technology > > is no longer sufficient anyway. > > > > Y(J)S > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:44 2006 From: lidefeng Subject: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt Date: Tue, 20 May 2003 10:01:52 +0800 Lines: 43 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Cc: mpls@UU.NET, pwe3@ietf.org X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Tue May 20 04:00:16 2003 Return-path: To: ppvpn@nortelnetworks.com X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Priority: 3 X-MSMail-priority: Normal X-SMTP-HELO: mta0.huawei.com X-SMTP-MAIL-FROM: lidefeng@huawei.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: [61.144.161.2] Status: O Some questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt In 8.1.1 Hierarchical L2 Circuit FEC Stack Sub-Type ,there are "Encapsulation Type" field and " L2 specific Sub-TLV (Optional)" field in the proposed Hierarchical L2 Circuit,while,in the "L2 specific Sub-TLV (Optional)" field, there is "Type (0x000B)" field in it,I want to know what's the difference between the "Encapsulation Type" in the Hierarchical L2 Circuit and the "Type" in "L2 specific Sub-TLV (Optional)" ? If they are both used,isn't one of them is redundant? Isn't reasonable use only one of them? The relevant format is copied to the following. Hierarchical L2 Circuit: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encapsulation Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 specific Sub-TLV (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L2 specific Sub-TLV : 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x000B) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Ethernet MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 802.1Q Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Ethernet MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 802.1Q Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Mark Seery" Subject: RE: Is PWE a layer? Date: Mon, 19 May 2003 22:26:44 -0700 Lines: 46 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A52DDDE8E@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Tue May 20 07:32:00 2003 Return-path: To: "Yaakov Stein" 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.2600.0000 In-Reply-To: <27A0F290348F8E45AEF79889DDE65A52DDDE8E@exrad2.ad.rad.co.il> Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Yaakov, [Multiple SNIPs] >> You are saying that 1483/90 are deficient network interworking, and I agree. << But I didn't say they are defficient encapsulation mechanisms. >> The service interworking being performed is direct FR-ATM service interworking......<< agreed >>....., and does not impact the PW. << But can this be said if PW has OAM? >> If we can do the interworking before we get to the MPLS network, we can stick to PWs and bypass the issue. << I assume you mean X to MPLS interworking, where X is Frame, ATM, Etherent,.......? So what is the point of using PWE in this case. No encapsulation is needed because interworking has already occurred. Some muxing layer perhaps? >> The question is whether we want to make MPLS into the new "universal network", relegating all others to status of legacy access technologies. << Actually in a "universal network" MPLS is the access technology ;-) Seriously, I know what you mean. >> Were this to happen, then indeed one access network might not know what the other access network's type is. << If there is a service interworking function, not simply by virtue of encapsulation. >> In THAT case we can no longer use PWs, and have to go for true service interworking with MPLS. << Agreed. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Mark Seery" Subject: RE: RE: Is PWE a layer? Date: Mon, 19 May 2003 22:56:10 -0700 Lines: 56 Sender: pwe3-admin@ietf.org References: <20030520030013.24092.qmail@web13502.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Tue May 20 07:57:51 2003 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.2600.0000 In-Reply-To: <20030520030013.24092.qmail@web13502.mail.yahoo.com> Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, [SNIP] >> Since the PW is essentially a direct link between two peers, ......<< Which is probably why the Frame Relay OAM model appeared to be applicable. Perhaps it was also the focus on a connectivity test. >> .....you can't use it for fault localization in the core network. << Agreed >> (1) You need robust OAM in the MPLS layer. If you have MPLS OAM you don't need PW OAM. << Peter, agreed. However, systems vendors do have this practical issue though that the server layer may terminate on a different line card than where the client layer originates, and therefore the server layer OAM does not provide an end-to-end mechanism. Now the proper way to solve this is to get the client layer to create an OAM mechanism. So just say one of the clients you want to support is "owned" by a standards body not interested in pursuing such a capability. You might then be tempted to create an in between layer that gets originated on the client layer's line card, and then give it an OAM mechanism. And of course now that single OAM mechanism can be used for multiple clients. Sounds attractive. Alternate solutions would be to move the server OAM termination to the line card where the client layer originates , or to move the encapsulation to the line card where the server layer originates; of the two, I think the later makes the most sense - but for a variety of reasons, system architectures do not always evolve this way. Now if you do actually do the PWE encapsulation on the line card where the client layer originates, and the PWE OAM terminates on that line card, then you have created an OAM problem. When you run PWE OAM, what are you testing? The PSN, or the client layer? What you have created is a client layer OAM, but you are calling it a PWE OAM, but it may not go end to end because the PWE OAM does not go end-to-end, only over the PSN "segment" of the client layer; so you do not actually have a client-layer OAM. So in a round about way, what I am saying, is I can see the practical reason of why PWE OAM looks attractive, most especially for Ethernet (in fact if Ethernet OAM is not created, then vendors will have to create something proprietary); but I do agree it creates problems, and ultimately, it may not solve the problem it is intended to. So as an industry, we must work to make sure client layer OAMs are created, otherwise non-optimal solutions will be created, and in fact there will be no choice but to create them, or make sure that systems are architected in a certain way, which may not create optimal engineering choices; and of course there is no doubt the old installed base problem. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Tarun Bhalla" Subject: Field Installations of PWE3. Date: Tue, 20 May 2003 19:50:01 +0530 Lines: 88 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-093eff81-8a7d-11d7-ba7f-006067005148" X-From: pwe3-admin@ietf.org Tue May 20 16:20:04 2003 Return-path: To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 20 May 2003 14:12:22.0423 (UTC) FILETIME=[D4D8F270:01C31ED9] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------=_NextPartTM-000-093eff81-8a7d-11d7-ba7f-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0698_01C31F09.007A2F00" ------=_NextPart_000_0698_01C31F09.007A2F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all=20 I wanted to know if there have been some field installations of PWE3 or is it still in the draft phase.=20 Also, wanted to know if any of the OEMs are putting it in=20 their boxes or any stacks have been developed so far for=20 this. Any information on the deployment scenarios (notable advantages and hidden disadvantages shall help me a lot).=20 Any info on this aspect shall be very helpful. Thanks & Regards Tarun B _________________________________________________ Tarun Bhalla Wipro Technologies 26 Hosur Main Road,=20 Bommanahalli, Bangalore- 560 068. India Tel +91-80-5732293, Extn 3139 =20 ------=_NextPart_000_0698_01C31F09.007A2F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi all
 
I wanted to know if there have been = some field=20 installations
of PWE3 or is it still in the draft = phase.=20
 
Also, wanted to know if any of the OEMs = are putting=20 it in
their boxes or=20 any stacks have been developed so far for
this. Any information on the = deployment=20 scenarios (notable
advantages and hidden = disadvantages shall help=20 me a lot). 
 
Any info on this aspect shall be very=20 helpful.
 
Thanks & Regards
Tarun=20 B
_________________________________________________
Tarun = Bhalla
Wipro=20 Technologies
26 Hosur Main Road,
Bommanahalli,
Bangalore- 560 = 068.=20 India
Tel +91-80-5732293, Extn 3139 <http://www.wipro.com/> =
 
 
------=_NextPart_000_0698_01C31F09.007A2F00-- ------=_NextPartTM-000-093eff81-8a7d-11d7-ba7f-006067005148-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: Mapping between the connection verification status of PW and the native ATM services Date: Tue, 20 May 2003 15:27:17 -0400 Lines: 105 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31F05.D2AE9E24" X-From: pwe3-admin@ietf.org Tue May 20 21:33:39 2003 Return-path: To: "'Qiu Jin'" , "'pwe3@ietf.org '" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C31F05.D2AE9E24 Content-Type: text/plain; charset="iso-8859-1" Qui: If you have access to ITU documents, you may want to look at Y.17iw (SG13, Q3/5). cheers Dave > -----Original Message----- > From: Qiu Jin [mailto:qjin@sprintlabs.com] > Sent: Thursday, May 15, 2003 7:25 PM > To: 'pwe3@ietf.org ' > Subject: [PWE3] Mapping between the connection verification > status of PW and the native ATM services > > > In the draft-ietf-pwe3-arch-02.txt, section 8.3 says, If > connection verification status of PW is needed by the CE, it > must be mapped to the native connection status method. Are > there any one can point me where can I find more detail > information about the mapping between the connection > verification status of PW and ATM OAM? > > Thanks > Qiu > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C31F05.D2AE9E24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Mapping between the connection verification status of = PW and the native ATM services

Qui:

If you have access to ITU documents, you may want to = look at Y.17iw (SG13, Q3/5).

cheers
Dave

> -----Original Message-----
> From: Qiu Jin [mailto:qjin@sprintlabs.com] =
> Sent: Thursday, May 15, 2003 7:25 PM
> To: 'pwe3@ietf.org '
> Subject: [PWE3] Mapping between the connection = verification
> status of PW and the native ATM services
>
>
> In the draft-ietf-pwe3-arch-02.txt, section 8.3 = says, If
> connection verification status of PW is needed = by the CE, it
> must be mapped to the native connection status = method. Are
> there any one can point me where can I find = more detail
> information about the mapping between the = connection
> verification status of PW and ATM OAM?
>
> Thanks
> Qiu
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C31F05.D2AE9E24-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Olen Stokes Subject: RE: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt Date: Tue, 20 May 2003 14:47:31 -0700 Lines: 79 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Cc: mpls@uu.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 20 23:53:51 2003 Return-path: To: "'lidefeng'" , ppvpn@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2655.55) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O It was simply set up that way to allow for future flexibility. Cheers, Olen > -----Original Message----- > From: lidefeng [mailto:lidefeng@huawei.com] > Sent: Monday, May 19, 2003 10:02 PM > To: ppvpn@nortelnetworks.com > Cc: mpls@UU.NET; pwe3@ietf.org > Subject: Questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > > Some questions about draft-stokes-vkompella-ppvpn-hvpls-oam-01.txt > > In 8.1.1 Hierarchical L2 Circuit FEC Stack Sub-Type ,there are > "Encapsulation Type" field and " L2 specific Sub-TLV > (Optional)" field in > the proposed Hierarchical L2 Circuit,while,in the "L2 > specific Sub-TLV > (Optional)" field, there is "Type (0x000B)" field in it,I want to know > what's the difference between the "Encapsulation Type" in the > Hierarchical > L2 Circuit and the "Type" in "L2 specific Sub-TLV (Optional)" > ? If they are > both used,isn't one of them is redundant? Isn't reasonable > use only one of > them? > > The relevant format is copied to the following. > > Hierarchical L2 Circuit: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VC ID > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Encapsulation Type | Must Be Zero > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | L2 specific Sub-TLV (Optional) > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > L2 specific Sub-TLV : > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (0x000B) | Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Target Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sender Ethernet MAC address > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | 802.1Q Tag > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 14:04:38 -0400 Lines: 266 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31FC3.7205DBFA" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 20:09:52 2003 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'Yaakov Stein'" , Mark Seery X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C31FC3.7205DBFA Content-Type: text/plain; charset="iso-8859-1" Hi Peter: > My view: > > - No, we don't need another full network layer Agreed, if the PW is MPLS I thought we had one already ;-). > - Yes, PWs can (must) carry everything, including > client-layer OAM traffic. > > But there are a few caveats: > > a) TTL > 2 > Eric Rosen made the point that there are cases in which it > makes sense to splice PWs together and switch based on the PW > label. IMO, that turns the "PW layer" into an MPLS layer. (It > makes you wonder why there is a PW layer in the first place. > Why not define how to adapt client traffic to MPLS (i.e. > remove the demultiplexing function from PWE) and leave it to > the service provider to decide whether there is a need for > additional aggregation via MPLS label stacking.) I think this is a key point, I'm certainly in favor of common label semantics to simplify implementation. > > b) There is a need for OAM in the server layer. > When a service provider carries encapsulated traffic through > a nation-wide core network, it is not enough to merely have a > continuity check between the encapsulation point and the > decapsulation point. E.g. if a failure occurs in the core > network, the service provider needs to be able to determine > as precisely as possible what the failure is and where it is located. IMHO fault management is most frugally performed at the transport layer although it must also exist to some degree at the PW layer. Performance management hits both as well, network planners need the transport measurements, and SLA reporting needs the PW measurements. > > c) OAM and MPLS > In an MPLS network with MP2P and ECMP it is hard to do good > OAM (see Neil's emails). Hence, the proposal in the VCCV > draft to encapsulate the Ping message with the same label > stack as the client traffic, including the PW label. Key thing is that ECMP (depending on the implementation) currently breaks path semantics any IP payload and/or use of reserved labels. So explicit V4 as a PID, OAM alert and Router alert all have ECMP implementations that break their use. VCCV is one response, but requires an LDP adjacency to configure the meaning of the VCCV bit. IMHO I'd prefer the PID approach (however it manifests itself) as the ECMP "immune" payload self identifies. > In an earlier email, I made the argument that if you can't do > OAM in the MPSL layer, you need to treat the PW as a > point-to-point link and do OAM on the PW. However, this is > far from ideal. Since the PW is essentially a direct link > between two peers, you can't use it for fault localization in > the core network. One problem is sorting out the operational framework, once you move past the ability to detect problems, you then need the ability to react appropriately across the layers, transport, PW and PW client. Hierarchy and aggregation mean that a single failure can impact a large number of monitored entities (both transport and PW). Most problems will be isolated naturally (loss of light etc.), but if you overlay e2e detection mechanisms on the network (which you do need in some form to bridge into client OAM) and you start to distribute that functionality into the NEs, then the issue is not one of fault isolation but fault correlation. > > The more I think about it, the more I believe that: > > (1) You need robust OAM in the MPLS layer. If you have MPLS > OAM you don't need PW OAM. You need some functionality at each layer to bridge the operational paradigms of each layer together. Operational discontinuities between layers are a scaling nightmare as "problem ownership" does not percolate upwards. > (2) in the absence of MPLS OAM, you might decide to do > connectivity verification on a per-PW basis, but it is a poor > alternative. Agreed. Dave > ------_=_NextPart_001_01C31FC3.7205DBFA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

Hi Peter:

<snipped>

> My view:
>
> - No, we don't need another full network = layer

Agreed, if the PW is MPLS I thought we had one = already ;-).

> - Yes, PWs can (must) carry everything, = including
> client-layer OAM traffic.
> 
> But there are a few caveats:
>
> a) TTL > 2
> Eric Rosen made the point that there are cases = in which it
> makes sense to splice PWs together and switch = based on the PW
> label. IMO, that turns the "PW layer" = into an MPLS layer. (It
> makes you wonder why there is a PW layer in the = first place.
> Why not define how to adapt client traffic to = MPLS (i.e.
> remove the demultiplexing function from PWE) = and leave it to
> the service provider to decide whether there is = a need for
> additional aggregation via MPLS label = stacking.)

I think this is a key point, I'm certainly in favor = of common label semantics to simplify implementation.

>
> b) There is a need for OAM in the server = layer.
> When a service provider carries encapsulated = traffic through
> a nation-wide core network, it is not enough to = merely have a
> continuity check between the encapsulation = point and the
> decapsulation point. E.g. if a failure occurs = in the core
> network, the service provider needs to be able = to determine
> as precisely as possible what the failure is = and where it is located.

IMHO fault management is most frugally performed at = the transport layer although it must also exist to some degree at the = PW layer. Performance management hits both as well, network planners = need the transport measurements, and SLA reporting needs the PW = measurements.

>
> c) OAM and MPLS
> In an MPLS network with MP2P and ECMP it is = hard to do good
> OAM (see Neil's emails). Hence, the proposal in = the VCCV
> draft to encapsulate the Ping message with the = same label
> stack as the client traffic, including the PW = label.

Key thing is that ECMP (depending on the = implementation) currently breaks path semantics any IP payload and/or = use of reserved labels. So explicit V4 as a PID, OAM alert and Router = alert all have ECMP implementations that break their use. VCCV is one = response, but requires an LDP adjacency to configure the meaning of the = VCCV bit. IMHO I'd prefer the PID approach (however it manifests = itself) as the ECMP "immune" payload self = identifies.

 
> In an earlier email, I made the argument that = if you can't do
> OAM in the MPSL layer, you need to treat the PW = as a
> point-to-point link and do OAM on the PW. = However, this is
> far from ideal. Since the PW is essentially a = direct link
> between two peers, you can't use it for fault = localization in
> the core network.

One problem is sorting out the operational framework, = once you move past the ability to detect problems, you then need the = ability to react appropriately across the layers, transport, PW and PW = client. Hierarchy and aggregation mean that a single failure can impact = a large number of monitored entities (both transport and PW). Most = problems will be isolated naturally (loss of light etc.), but if you = overlay e2e detection mechanisms on the network (which you do need in = some form to bridge into client OAM) and you start to distribute that = functionality into the NEs, then the issue is not one of fault = isolation but fault correlation.


>
> The more I think about it, the more I believe = that:
>
> (1) You need robust OAM in the MPLS layer. If = you have MPLS
> OAM you don't need PW OAM.

You need some functionality at each layer to bridge = the operational paradigms of each layer together. Operational = discontinuities between layers are a scaling nightmare as "problem = ownership" does not percolate upwards.

> (2) in the absence of MPLS OAM, you might decide = to do
> connectivity verification on a per-PW basis, = but it is a poor
> alternative.

Agreed.

Dave

>

------_=_NextPart_001_01C31FC3.7205DBFA-- From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 11:40:24 -0700 Lines: 18 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 20:46:33 2003 Return-path: To: "'Mark Seery'" , busschbach@lucent.com X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mark, >However, systems vendors do have this practical issue though >that the server >layer may terminate on a different line card than where the >client layer >originates, and therefore the server layer OAM does not provide an >end-to-end mechanism. Now the proper way to solve this is to >get the client >layer to create an OAM mechanism. In that case the OAM of the in-between layer is only testing the faults between two line cards in a single switch/router. This can be accomplished using an internal/proprietory OAM between line cards, and does not need inventing edge-to-edge OAM for the in-between layer. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 11:43:19 -0700 Lines: 13 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 20:47:22 2003 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'Yaakov Stein'" , Mark Seery X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >a) TTL > 2 >Eric Rosen made the point that there are cases in which it >makes sense to splice PWs together and switch based on the PW >label. IMO, that turns the "PW layer" into an MPLS layer. >(It makes you wonder why there is a PW layer in the first >place. Why not define how to adapt client traffic to MPLS >(i.e. remove the demultiplexing function from PWE) and leave >it to the service provider to decide whether there is a need >for additional aggregation via MPLS label stacking.) If PW labels could be switched like MPLS labels, then why can't MPLS-ping be used to test it? -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 14:51:57 -0400 Lines: 36 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 20:54:40 2003 Return-path: To: "'Shahram Davari'" , "Busschbach, Peter B (Peter)" , "'Yaakov Stein'" , Mark Seery X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 21, 2003 2:43 PM > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > >a) TTL > 2 > >Eric Rosen made the point that there are cases in which it > >makes sense to splice PWs together and switch based on the PW > >label. IMO, that turns the "PW layer" into an MPLS layer. > >(It makes you wonder why there is a PW layer in the first > >place. Why not define how to adapt client traffic to MPLS > >(i.e. remove the demultiplexing function from PWE) and leave > >it to the service provider to decide whether there is a need > >for additional aggregation via MPLS label stacking.) > > If PW labels could be switched like MPLS labels, then why > can't MPLS-ping be used to test it? > Shahram, My statement should be read in the context of the question: is PW an adaptation function or a network layer in itself. My point was: if you use intermediate nodes to switch based on the PW Label, then it becomes a network layer in itself. Can one use Ping to test it? Yes, of course. Was there anything in my mail that gave you the impression that I thought one couldn't? I still have a question about Ping, though. Is it the intention that Ping messages be sent periodically? The vccv draft doesn't specify this. IMO, for fault management you need a periodic connectivity check and you need to define how you determine that there is a defect. Is it when you miss one reply or only after missing multiple replies? Frankly, you need a state machine as defined in Y.1711. Peter > -Shahram > From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 12:12:04 -0700 Lines: 34 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 21:22:09 2003 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'Yaakov Stein'" , Mark Seery X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, > If PW labels could be switched like MPLS labels, then why >> can't MPLS-ping be used to test it? >> > >Shahram, > >My statement should be read in the context of the question: is >PW an adaptation function or a network layer in itself. My >point was: if you use intermediate nodes to switch based on >the PW Label, then it becomes a network layer in itself. > >Can one use Ping to test it? Yes, of course. Was there >anything in my mail that gave you the impression that I >thought one couldn't? No, I just wanted to bring people's attention to this issue. > >I still have a question about Ping, though. Is it the >intention that Ping messages be sent periodically? The vccv >draft doesn't specify this. IMO, for fault management you need >a periodic connectivity check and you need to define how you >determine that there is a defect. Is it when you miss one >reply or only after missing multiple replies? Frankly, you >need a state machine as defined in Y.1711. Agree. Since MPLS-ping is a loopback mechanism, it seems that the period, processing, state machines, etc, are local matter to the source and probably don't need standardization. But off course if a service provider wants to offer a consistent service SLA across its network, then these issues need to be nailed down. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mark Seery Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 12:19:25 -0700 (PDT) Lines: 104 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C95E@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 21:24:17 2003 Return-path: To: Shahram Davari , "'Mark Seery'" , busschbach@lucent.com In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C95E@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Sharam, Comments below, Mark --- Shahram Davari wrote: > Mark, > > > >However, systems vendors do have this practical > issue though > >that the server > >layer may terminate on a different line card than > where the > >client layer > >originates, and therefore the server layer OAM does > not provide an > >end-to-end mechanism. Now the proper way to solve > this is to > >get the client > >layer to create an OAM mechanism. > > In that case the OAM of the in-between layer is only > testing the > faults between two line cards in a single > switch/router. This can > be accomplished using an internal/proprietory OAM > between line cards, > and does not need inventing edge-to-edge OAM for the > in-between layer. > > -Shahram So let me start by saying I think PWE OAM is a mistake in principal (architecturally speaking - under any circumstances) and a mistake in practice unless we can not get these other issues resolved. There are some big picture issues which play in here with respect to PWEs role and x/MPLS vs x/IP - but perhaps that should be a separate thread. Now to your point. In the absence of an edge-to-edge OAM, how are you going to know where the problem is in the first place to go use the proprietary OAM between the line cards? You then have to go running the proprietary OAM on every edge to find out where the problem is don't you? Isn't this a lot of work for the operator, not to mention the impact on historical verification of SLAs and pinning down transient errors. So then I guess you should run the proprietary OAM constantly. Now what, do you interwork it with the server layer, do you treat it as a client layer.....? It is really the same problem all over again. Clearly the solution is a) only design systems in certain ways or b) work with client layers to make sure they have the OAM they want. I think operators might want to have a chat with their vendors and understand a) before they put a hard stake in the ground on this one. b) is preferrable but the cooperation of other organizations is not exactly guaranteed. If as an industry we can't rely on client layers having their own OAM, then we have to force the PSN processing (for example MPLS) back to the client service interface (as we do today with TDM networks) or create an in-between kludge. Forcing the PSN processing back to the client interface essentially means that vendors have to develop two cards. One is a cost effective card that does not have the PSN processing, the other is a more expensive card that does have the PSN processing. The reason I say this is because MPLS processing, which essentially means IP as well, is non trivial today; much more say than TDM processing (and even if it is not, market forces with create a pricing difference to the operator). This is further complicated by the fact that for similar reasons, vendors will often have two versions of the network-side card already. My preference would be for the IETF to go back to client layer organizations and let them know that services can not be offered using their technology, that have strong SLAs, unless they do certain things. In the case of Ethernet, EFM has already done some work on OAM which **may** be a start. If this option is seen as beeing too much work (and too much delay to get solutions in to the field), then we are left with a kludge by any method, vendors creating two different solutions, or some other trickery to extend the PSN OAM back to the client interface (but then I would ask are you testing what you think you are testing? - but it can be done). If the above logic is right, and obviously interested in your feedback, then it is just one of those unfortunate real world issues where principal meets reality (for some transient period of time = the time it takes to make MPLS or other PSNs a commodity technology - which it is far from today). Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Shahram Davari Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 12:58:04 -0700 Lines: 79 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 22:07:11 2003 Return-path: To: "'Mark Seery'" , busschbach@lucent.com X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mark, >So let me start by saying I think PWE OAM is a mistake >in principal (architecturally speaking - under any >circumstances) and a mistake in practice unless we can >not get these other issues resolved. There are some >big picture issues which play in here with respect to >PWEs role and x/MPLS vs x/IP - but perhaps that should >be a separate thread. Agree. >Now to your point. In the absence of an edge-to-edge >OAM, how are you going to know where the problem is in >the first place to go use the proprietary OAM between >the line cards? You then have to go running the >proprietary OAM on every edge to find out where the >problem is don't you? Isn't this a lot of work for the >operator, I don't think so. This is confined within a box and should be easily configurable. ?ot to mention the impact on historical >verification of SLAs and pinning down transient >errors. So then I guess you should run the proprietary >OAM constantly. Yes, my suggestion was to run it continuously. >Now what, do you interwork it with the >server layer, do you treat it as a client layer.....? >It is really the same problem all over again. I think you have to generate AIS on the payload the PW is carrying such as ATM AIS. > >Clearly the solution is a) only design systems in >certain ways or b) work with client layers to make >sure they have the OAM they want. I think operators >might want to have a chat with their vendors and >understand a) before they put a hard stake in the >ground on this one. b) is preferrable but the >cooperation of other organizations is not exactly >guaranteed. > >If as an industry we can't rely on client layers >having their own OAM, then we have to force the PSN >processing (for example MPLS) back to the client >service interface (as we do today with TDM networks) >or create an in-between kludge. Forcing the PSN >processing back to the client interface essentially >means that vendors have to develop two cards. One is a >cost effective card that does not have the PSN >processing, the other is a more expensive card that >does have the PSN processing. The reason I say this is >because MPLS processing, which essentially means IP as >well, is non trivial today; much more say than TDM >processing (and even if it is not, market forces with >create a pricing difference to the operator). This is >further complicated by the fact that for similar >reasons, vendors will often have two versions of the >network-side card already. > >My preference would be for the IETF to go back to >client layer organizations and let them know that >services can not be offered using their technology, >that have strong SLAs, unless they do certain things. Agreed. As I said before the tunnel LSP (and even the multiplexing LSP) could be tested using MPLS-ping. If the client/server mapping needs to be tested then client segment OAM should be used. If that is not available, then the client/server mapping can't be tested. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: Mark Seery Subject: X/MPLS vs X/IP Date: Wed, 21 May 2003 13:16:08 -0700 (PDT) Lines: 28 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C962@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Wed May 21 22:19:22 2003 Return-path: To: pwe3@ietf.org In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C962@nt-exch-yow.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O So hadn't felt the need to get in to this before, but the "is PWE a layer" discussion kind of forces it, in a way. NH has lots of thoughts about why X/MPLS is different than X/IP, and perhaps when Neil has time he can briefly enumerate them, so leave the general question in his hands. But OAM raises a specific issue. If you run a client (ethernet) over a server (IP), then what server OAM are you going to use? And if neither the server nor the client have OAM, then where do you put it? More generally, how often are we going to be tempted to throw something into the PWE layer, because one or all server layers is missing something? Those questions invite the following questions: + Do we define one server layer, or multiple server layers in the IETF? + If we define multiple server layers in the IETF, do they have to be functionally equivalent? + If we have multiple server layers and they are not functionally equivalent, then can PWE work without turning PWE into a server layer itself? Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 16:26:22 -0400 Lines: 26 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 22:29:31 2003 Return-path: To: "'Shahram Davari'" , "Busschbach, Peter B (Peter)" , "'Yaakov Stein'" , Mark Seery X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 21, 2003 3:12 PM > Subject: RE: [PWE3] RE: Is PWE a layer? > > [snipped] > Agree. Since MPLS-ping is a loopback mechanism, it seems that > the period, processing, state machines, etc, are local matter to the > source and probably don't need standardization. But off > course if a service > provider wants to offer a consistent service SLA across its > network, then these issues need to be nailed down. > > -Shahram > Shahram, I think you need a tighter coupling between both ends of a PW than LSP Ping provides. E.g. the downstream end should generate an alarm if it doesn't receive the periodic connectivity verification message (which could be the same LSP Ping message, but with different semantics) from the upstream end. To enable such behavior, you need a standardized solution. Peter From pwe3-admin@ietf.org Wed Dec 27 16:41:44 2006 From: "Jack Pugaczewski" Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 15:30:05 -0500 Lines: 101 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C962@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Wed May 21 22:34:56 2003 Return-path: To: "Shahram Davari" , "'Mark Seery'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C962@nt-exch-yow.pmc-sierra.bc.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by uswgne22.uswest.com id h4LKU8C3013699 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4LJw8B14419 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4LK1AB14612 Status: O Why can we not standardize the FM OAM functionality for PWE-3 in a simila= r manner as Frame Relay and ATM have been defined ? PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Shahram Davari > Sent: Wednesday, May 21, 2003 2:58 PM > To: 'Mark Seery'; busschbach@lucent.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > Mark, > > >So let me start by saying I think PWE OAM is a mistake > >in principal (architecturally speaking - under any > >circumstances) and a mistake in practice unless we can > >not get these other issues resolved. There are some > >big picture issues which play in here with respect to > >PWEs role and x/MPLS vs x/IP - but perhaps that should > >be a separate thread. > > Agree. > > >Now to your point. In the absence of an edge-to-edge > >OAM, how are you going to know where the problem is in > >the first place to go use the proprietary OAM between > >the line cards? You then have to go running the > >proprietary OAM on every edge to find out where the > >problem is don't you? Isn't this a lot of work for the > >operator, > > I don't think so. This is confined within a box and should > be easily configurable. > > ?ot to mention the impact on historical > >verification of SLAs and pinning down transient > >errors. So then I guess you should run the proprietary > >OAM constantly. > > Yes, my suggestion was to run it continuously. > > > >Now what, do you interwork it with the > >server layer, do you treat it as a client layer.....? > >It is really the same problem all over again. > > I think you have to generate AIS on the payload the PW > is carrying such as ATM AIS. > > > > >Clearly the solution is a) only design systems in > >certain ways or b) work with client layers to make > >sure they have the OAM they want. I think operators > >might want to have a chat with their vendors and > >understand a) before they put a hard stake in the > >ground on this one. b) is preferrable but the > >cooperation of other organizations is not exactly > >guaranteed. > > > >If as an industry we can't rely on client layers > >having their own OAM, then we have to force the PSN > >processing (for example MPLS) back to the client > >service interface (as we do today with TDM networks) > >or create an in-between kludge. Forcing the PSN > >processing back to the client interface essentially > >means that vendors have to develop two cards. One is a > >cost effective card that does not have the PSN > >processing, the other is a more expensive card that > >does have the PSN processing. The reason I say this is > >because MPLS processing, which essentially means IP as > >well, is non trivial today; much more say than TDM > >processing (and even if it is not, market forces with > >create a pricing difference to the operator). This is > >further complicated by the fact that for similar > >reasons, vendors will often have two versions of the > >network-side card already. > > > >My preference would be for the IETF to go back to > >client layer organizations and let them know that > >services can not be offered using their technology, > >that have strong SLAs, unless they do certain things. > > Agreed. As I said before the tunnel LSP (and even > the multiplexing LSP) could be tested using MPLS-ping. > If the client/server mapping needs to be tested then client segment > OAM should be used. If that is not available, then the client/server > mapping can't be tested. > > > -Shahram > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: RE: Is PWE a layer? Date: Wed, 21 May 2003 16:35:55 -0400 Organization: Alcatel Networks Corporaton Lines: 47 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'Shahram Davari'" , "'Yaakov Stein'" , Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 22:36:59 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, "Busschbach, Peter B (Peter)" wrote: > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, May 21, 2003 2:43 PM > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > >a) TTL > 2 > > >Eric Rosen made the point that there are cases in which it > > >makes sense to splice PWs together and switch based on the PW > > >label. IMO, that turns the "PW layer" into an MPLS layer. > > >(It makes you wonder why there is a PW layer in the first > > >place. Why not define how to adapt client traffic to MPLS > > >(i.e. remove the demultiplexing function from PWE) and leave > > >it to the service provider to decide whether there is a need > > >for additional aggregation via MPLS label stacking.) > > > > If PW labels could be switched like MPLS labels, then why > > can't MPLS-ping be used to test it? > > > > Shahram, > > My statement should be read in the context of the question: is PW an adaptation function or a network layer in itself. My point was: if you use intermediate nodes to switch based on the PW Label, then it becomes a network layer in itself. > > Can one use Ping to test it? Yes, of course. Was there anything in my mail that gave you the impression that I thought one couldn't? > > I still have a question about Ping, though. Is it the intention that >Ping messages be sent periodically? The vccv draft doesn't specify this. >IMO, for fault management you need a periodic connectivity check and you >need to define how you determine that there is a defect. Is it when you >miss one reply or only after missing multiple replies? Frankly, you need >a state machine as defined in Y.1711. A Ping mechanism is similar to a connectivity verification mechanism. This is not suited for alarm indication/suppression. It is intended to be mostly proactive and can have a significant processing impact on the node for monitoring a large number of entities. Let us consider again the scenario of ATM-MPLS-FR service interworking, with local termination of ATM and FR at each PE. If the ATM port in the ingress PE fails, you need to generate a reactive alarm indication on all PWs which are sourced on this port to inform the remote PE of the defect. You need to be able to do that without injecting connectivity verification traffic. A lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is more suitable. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 16:55:04 -0400 Lines: 39 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Shahram Davari'" , "'Yaakov Stein'" , Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 21 22:58:56 2003 Return-path: To: "'Mustapha Aissaoui'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, May 21, 2003 4:36 PM > To: Busschbach, Peter B (Peter) > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > Subject: Re: [PWE3] RE: Is PWE a layer? > > [snipped] > > A Ping mechanism is similar to a connectivity verification > mechanism. This is not suited for alarm indication/suppression. It > is intended to be mostly proactive and can have a significant > processing impact on the node for monitoring a large number of > entities. > Let us consider again the scenario of ATM-MPLS-FR service > interworking, with local termination of ATM and FR at each PE. If > the ATM port in the ingress PE fails, you need to generate a > reactive alarm indication on all PWs which are sourced on this port > to inform the remote PE of the defect. You need to be able to do > that without injecting connectivity verification traffic. A > lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is > more suitable. Thanks, Mustapha. Two things: - If an ATM port fails, the ATM NSP function should generate the appropriate I.610 messages. This is independent of whether the port is a PW or otherwise. I think you agree with that, but your comment somehow links ATM port failures with injecting connectivity verification, which confuses me. I would think it is the other way around: through connectivity verification you find that a PW is down, which is reported to the NSP, which in turn will generate AIS and RDI. - I don't have any experimental evidence that LSP Ping is too heavy-weight to serve as a periodic connectivity verification messages. I leave that to the experts to decide. Peter > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 23:05:42 +0100 Lines: 97 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Shahram_Davari@pmc-sierra.com, yaakov_s@rad.com, mark@mseery.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 00:07:22 2003 Return-path: To: mustapha.aissaoui@alcatel.com, busschbach@lucent.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Mustapha......Please see below. regards, Neil Mustapha Aissaoui wrote 21 May 2003 21:36 > Let us consider again the scenario of ATM-MPLS-FR service > interworking, with local termination of ATM and FR at each PE. If > the ATM port in the ingress PE fails, you need to generate a > reactive alarm indication on all PWs which are sourced on this port > to inform the remote PE of the defect. You need to be able to do > that without injecting connectivity verification traffic. A > lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is > more suitable. This is how to trivially interwork ATM and MPLS as peer layer networks (aka service-interworking). Note: - assumes defect detection/handling is unidirectional, and implemented as an inherent property (ie distributed/automatic executive action) of the trail sink (which was effectively a point I saw Peter B make earlier about requiring simple 'state machines' defined in Y.1711); - assumes all defects are unambiguously specified, ie entry-exit criteria and consequent actions (all done in Y.1711); - assumes we run CV/CC in each technology partition in a sort of 'segment' sense (using I.610 terminology); - but map FDI/AIS and BDI/RDI across IWF to reflect defects in other technology partition; - may need new DT (defect type) for FDI/AIS and BDI/RDI to reflect 'other partition' detected defect; - in following description I have used CV, FDI and BDI as the generic terms for either MPLS or ATM case......to save repeating as the functions are similar. Network model: [CPEa]-------ATM partition-------{IWF}--------MPLS partition-------[CPEm] Consider 2 cases of L1 defects and L2 defects. In former case we have a simple L2/L1 client/server (aka network-interworking) defect handling model (as there are L1 trails between adjacent L2 nodes in either ATM or MPLS partitions), whilst in L2 case we have the peer mode (aka service-interworking). L1 DEFECTS (i) In direction *towards* IWF: FDI mapped up from L1 to ATM or MPLS partition as relevant. At IWF incoming FDI suppresses alarm that would otherwise exist from missing CV. FDI mapped immediately across to other partition in 1:1 fashion and CV generation there suppressed. There is now a question wrt to BDI. Does this get mapped back at the IWF *or* do we wait for the BDI to come back from far-end CPE, eg for failure in ATM partition above this would be CPEm? Note - In next case considered only a simple mapping across the IWF is required, which tends to suggest waiting for a far-end CPE BDI reflection is the simplest solution. The alternative is to 'OR' this at the IWF for defects in direction towards the IWF. (ii) In direction *towards* CPE: FDI mapped up from L1 to ATM or MPLS partition as relevant. At CPE (either a or m) incoming FDI suppresses alarm that would otherwise exist from missing CV. Incoming FDI at CPE generates corresponding BDI towards IWF. BDI must have 1:1 mapping across IWF. Note in this case the CV flow in the partition *not* affected by the failures carries on as normal (and in *both* directions here). L2 DEFECTS (i) In direction *towards* IWF: At IWF defects detected from CV flow (consequent actions are dependent on type of defect). FDI generated immediately in other partition and CV generation there suppressed. We have the same question as before as to whether the BDI is generated at the IWF. However, like suggested before I propose we either wait for a far end CPE turn round and then do 1:1 mapping across IWF or do an 'OR' on this with a locally turned-round BDI. (ii) In direction *towards* CPE: At CPE (either a or m) defects detected from CV flow (consequent actions are dependent on type of defect). CPE generates corresponding BDI towards IWF in other direction. BDI must have 1:1 mapping across IWF. Note in this case the CV flow in the partition *not* affected by the failures carries on as normal (and in *both* directions here). And it's as simple as that. Now I saw Mark raise questions about layer network technologies that don't have proper OAM specified. Well, the right answer is to fix the problem in the layer network in question. Note that this could be either a client or server layer when a pair of technologies is being considered in such a relationship. You can of course rely on the server to proxy for missing client defect detection *iff* we are considering client/serrver network interworking....but of course this assumes the server layer is *not* functionally deficient. The wrong answer (under all circumstances) is to create such functionality in some new entity that resides between the client and server layers (this should be simple adaptation). The folly of this idea should be obvious, but if its not think what this means when one wants to have peer service-interworking between 2 technologies....all of sudden this artifical entity has disappeared! regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: RE: Is PWE a layer? Date: Wed, 21 May 2003 15:19:36 -0700 (PDT) Lines: 15 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D68A0@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Shahram_Davari@pmc-sierra.com, yaakov_s@rad.com, mark@mseery.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 00:22:24 2003 Return-path: To: neil.2.harrison@bt.com, mustapha.aissaoui@alcatel.com, busschbach@lucent.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D68A0@i2km07-ukbr.domain1.systemhost.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --- neil.2.harrison@bt.com wrote: [SNIP] > The folly of this > idea should be obvious, but if its not think what > this means when one wants > to have peer service-interworking between 2 > technologies....all of sudden > this artifical entity has disappeared! > > regards, Neil The folly is now obvious - thanks. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: RE: Is PWE a layer? Date: Wed, 21 May 2003 18:23:06 -0400 Organization: Alcatel Networks Corporaton Lines: 68 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'Shahram Davari'" , "'Yaakov Stein'" , Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 00:23:50 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, see a couple of clarification points below. Regards, Mustapha. ------------ "Busschbach, Peter B (Peter)" wrote: > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Wednesday, May 21, 2003 4:36 PM > > To: Busschbach, Peter B (Peter) > > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > > Subject: Re: [PWE3] RE: Is PWE a layer? > > > > > > [snipped] > > > > > A Ping mechanism is similar to a connectivity verification > > mechanism. This is not suited for alarm indication/suppression. It > > is intended to be mostly proactive and can have a significant > > processing impact on the node for monitoring a large number of > > entities. > > Let us consider again the scenario of ATM-MPLS-FR service > > interworking, with local termination of ATM and FR at each PE. If > > the ATM port in the ingress PE fails, you need to generate a > > reactive alarm indication on all PWs which are sourced on this port > > to inform the remote PE of the defect. You need to be able to do > > that without injecting connectivity verification traffic. A > > lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is > > more suitable. > > Thanks, Mustapha. > > Two things: > > - If an ATM port fails, the ATM NSP function should generate the >appropriate I.610 messages. This is independent of whether the port is a >PW or otherwise. I think you agree with that, but your comment somehow >links ATM port failures with injecting connectivity verification, which >confuses me. I would think it is the other way around: through >connectivity verification you find that a PW is down, which is reported >to the NSP, which in turn will generate AIS and RDI. Maybe I misunderstood what you said. I thought you were describing a method relying on turning connectivity verification on all PWs in the egress PE in order to detect such a failure of a ATM port in the ingress PE. My point was that it is more suitable to have a built in fault indication mechanism to inform the egress PE that the PWs sourced on the failed ingress PE ATM port are in defect state. But because in the scenario above ATM is terminated at the ingress PE, you cannot use ATM AIS but will need a defect indication mechanism for the PW or inner LSP. The ATM facing side of the PE will continue to operate as in I.610. > - I don't have any experimental evidence that LSP Ping is too >heavy-weight to serve as a periodic connectivity verification messages. >I leave that to the experts to decide. I do not have any evidence about LSP Ping either. I meant that using connectivity verification for detecting a failure is process intensive because it requires injecting OAM messages continuously. You do not expect a service provider to run continuously connectivity verification on all connections (be they VCs, PWs, or what have you) in the hope to catch a failure. Connectivity verification has a different role than alarm indication. So for fault management of PWs, we need both alarm indication/suppression and connectivity verification. I noticed most of the discussion on this list focused on the latter and omitted the former. > Peter > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: X/MPLS vs X/IP Date: Thu, 22 May 2003 09:51:45 +0300 Lines: 69 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Thu May 22 08:56:18 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] X/MPLS vs X/IP Thread-Index: AcMf2F53TiQONcw8TDqMeQttYIP2YgAT9L+wAAD1yrA= To: "Mark Seery" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4M6L7B03851 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > NH has lots of thoughts about why X/MPLS is different > than X/IP, and perhaps when Neil has time he can > briefly enumerate them, so leave the general question > in his hands. I'd like to step in here before Neil does, since we don't completely agree on this issue. PWs have been defined in the IETF to be lower layer agnostic in order to simplify their encapsulation. However, there ARE important differences between IP and MPLS networks, the most important deriving from the fact that IP is connectionless while MPLS is connection-oriented (but see below). Now it is perfectly legal to layer a connectionless network on top of a connection-oriented one, or a connection-oriented one on top of a connectionless one (although in this latter case the performance may degrade somewhat). The problems arise when we want to support real-time streams. Connectionless networks have problems with QoS in general, and QoS for the support of real-time streams in particular. There is simply somewhat of a contradiction between expressing disdain for dedicated connections and emulating them sufficiently well as to be able to give service guarantees. For example, a TDM link transports not only the user's traffic, but the accurate clocking information needed for its proper playout. The recovery of such timing information is already difficult for connection-oriented networks (this difficulty being evidenced, e.g. by the plethora of patents for clock recovery over ATM) and becomes more so for connectionless one (this greater difficulty being evidenced by the dearth of patents for TDM clock recovery over IP). Now that I have explained the difficulties essentially as Neil would, I have to add that these technical difficulties are not insurmountable, and that accurate timing can be recovered over IP networks. In addition, service guarantees are just what their name implies, promises of a CERTAIN LEVEL of service. While carriers have pre-defined notions as to what level of service their customers desire, these notions tend not to take everything of interest into account. Cell-phones deliver audio considered to be below "toll quality", but the added feature of mobility makes them desirable nonetheless. Similarly, pricing has a major impact on end-users. People are sometimes willing to suffer lower levels of service, if the price is considerably reduced. So transporting eal-time streams such as TDM over IP and over MPLS are somewhat different problems. The question is whether they are sufficiently different as to merit different protocols. Were MPLS to have been originally designed as a variable-length-packet ATM, rather than as "accelerated-IP" then perhaps the answer would have been yes. However, MPLS does NOT have a physical layer clock as ATM has, and does NOT guarantee that no mis-ordering will take place (being at the mercy of the IP routing), and does NOT universally promise lower PDV (although TE can help). So the differences between pure IP and MPLS are really a matter of degree, and not of essence, and the design of a single TDMoIP/MPLS protocol DOES makes sense. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: X/MPLS vs X/IP Date: Thu, 22 May 2003 12:13:43 +0200 Lines: 40 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: neil.2.harrison@bt.com, Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 11:28:49 2003 Return-path: To: "'Yaakov Stein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Thursday, May 22, 2003 8:52 AM > To: Mark Seery; pwe3@ietf.org > Cc: neil.2.harrison@bt.com > Subject: RE: [PWE3] X/MPLS vs X/IP > > .snipped ... > > PWs have been defined in the IETF to be lower layer agnostic > in order to simplify their encapsulation. > Exactly. > ... snipped ... > and the design of a single TDMoIP/MPLS protocol DOES makes sense. > I agree with the last sentence even if I disagree with your reasoning. If you are interested, we can discuss it off the list. > > Y(J)S > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: X/MPLS vs X/IP Date: Thu, 22 May 2003 11:43:23 +0100 Lines: 144 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Thu May 22 12:45:48 2003 Return-path: To: yaakov_s@rad.com, mark@mseery.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Yaakov, Yaakov S wrote to Mark S 22 May 2003 07:52 > > NH has lots of thoughts about why X/MPLS is different > > than X/IP, and perhaps when Neil has time he can > > briefly enumerate them, so leave the general question > > in his hands. > > I'd like to step in here before Neil does, > since we don't completely agree on this issue. > > PWs have been defined in the IETF to be lower layer agnostic > in order to simplify their encapsulation. NH=> That's an interesting way of putting it, ie 'simplifying'. I could easily argue that it 'complicates' the situation. There is no technical reason to require that IP and MPLS are the same......they both have individual properties and both modes are required However, this is not the sole reason as you know why the encaps has the functionality it does. > > However, there ARE important differences between IP and MPLS > networks, > the most important deriving from the fact that IP is connectionless > while MPLS is connection-oriented (but see below). NH=> Indeed....the only really significant problems arise from certain topological constructions when using a co pkt-sw forwarding mode. > > Now it is perfectly legal to layer a connectionless network > on top of a connection-oriented one, or a connection-oriented > one on top of a connectionless one (although in this latter case > the performance may degrade somewhat). > The problems arise when we want to support real-time streams. NH=> Yes it is 'legal' to do this. But have you also ever considered how many times one is allowed to swap modes in some global reference connection, and whether an abitrary number of such mode swapping instances would allow timing recovery? It's an interesting problem.....esp when it comes to breaking-down an end-end performance metric objective to *fair* subnetwork (G.805-sense) apportionments.....which is something carriers ought to be concerned about. > > Connectionless networks have problems with QoS in general, > and QoS for the support of real-time streams in particular. NH=> Two points here often overlooked: - there is a difference in how one needs to treat public and private traffic; - currently pkts only carry an up-state 'urgency' semantic and not an 'importance' semantic.....this is a big difference, eg a mission critical voice call or one to the emergency services vs 'office gossip'. A key observation here for the co pkt-sw mode is that one can't just consider the pkt level.....it has to be intrinsically associated with its parent trail. This observation is paraticularly important for private services. The bottom-line conclusion from this (when you fill-in all the other details) is that one needs both a cnls mode and a co pkt-sw mode and there are major differences in what they can/cannot do (I am saying this with a traditional operator's hat on, not an ISPs). So we should recognise this and properly exploit it. > There is simply somewhat of a contradiction between > expressing disdain for dedicated connections > and emulating them sufficiently well as to be able to give > service guarantees. > > For example, a TDM link transports not only the user's traffic, > but the accurate clocking information needed for its proper playout. > The recovery of such timing information is already difficult > for connection-oriented networks (this difficulty being > evidenced, e.g. by the plethora of patents for clock recovery > over ATM) > and becomes more so for connectionless one > (this greater difficulty being evidenced by the dearth of patents for > TDM clock recovery over IP). NH=> Precisely so. > > Now that I have explained the difficulties essentially > as Neil would, I have to add that these technical difficulties > are not insurmountable, and that accurate timing can be > recovered over IP networks. NH=> I'd generalise that to cnls networks as ethernet access is also a factor here. > > In addition, service guarantees are just what their name implies, > promises of a CERTAIN LEVEL of service. > While carriers have pre-defined notions as to what level of service > their customers desire, these notions tend not to take everything > of interest into account. Cell-phones deliver audio considered to > be below "toll quality", but the added feature of mobility makes > them desirable nonetheless. Similarly, pricing has a major impact > on end-users. People are sometimes willing to suffer lower levels > of service, if the price is considerably reduced. NH=> That's true....but recall my observation above wrt end-end performance objectives and fair allocations to subnetworks (which, to have any credibility, also implies an ability to measure such metrics/objcetives). Further, and I can only speak for BT here, we have a relentless drive to improve the network reliability/performance for our customers......so we are looking for both stds and vendors who support/share this view. > > So transporting eal-time streams such as TDM over IP and over MPLS > are somewhat different problems. NH=> Correct. > The question is whether they are > sufficiently different as to merit different protocols. NH=> There are 2 aspects to this (if I ignore seperating the private/public services case, which as I noted earlier does actually need to be considered in practice): (i) the WAN mode and (ii) the application-interfacing protocol. Both have to be considered. And in an ideal case (ie to minimise capex/opex costs), for technologies belonging to the same WAN mode one wants service-interworking with consistent application-interfacing protocols. A further factor to consider is who are you selling this solution to? Is if for (i) the Internet (big 'I') (ii) an ISP or (ii) a traditional operator? These are all quite different IMO. I have absolutely no problems at all in addressing all 3 'customers'.......my problems start when someone tries to tell me there is only one solution for all cases and no other will be considered (usually because of political, commercial or religious factors). > > Were MPLS to have been originally designed as a variable-length-packet > ATM, rather than as "accelerated-IP" then perhaps the answer > would have been yes. However, MPLS does NOT have a physical layer > clock as ATM has, NH=> Not sure what you mean by this......ATM (as indeed every framing format above the physical/media level) invariably relies on a co cct-sw trail to convey the timing between nodes (the exception is the case of ethernet and wireless/radio, but these too have their own phy/media stds for clock recovery) > and does NOT guarantee that no mis-ordering > will take place (being at the mercy of the IP routing), NH=> I understand your point, but this could apply to any mode where routes/connections can vary at will....a distributed routing protocol can be used with a cnls, co pkt-sw and even a co cct-sw mode. So its a choice whether this behavior is allowed and has strictly nothing to do with 'IP routing' whatever that really means. > and does NOT > universally promise lower PDV (although TE can help). NH=> Agreed, this is a function of bit rates and network loading. > > So the differences between pure IP and MPLS > are really a matter of degree, and not of essence, > and the design of a single TDMoIP/MPLS protocol DOES makes sense. NH=> I understand what you are saying here.....and I am sure you recognise that you are restricted to the client/server network-interworking case. I also just saw Sasha's comment to 'maybe take this off-list'. That's fine, I think I understand why this is suggested......but I just ask the question 'who is your target market/customer here?' From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: X/MPLS vs X/IP Date: Thu, 22 May 2003 06:07:28 -0700 (PDT) Lines: 10 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5283B40A@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 15:12:14 2003 Return-path: To: Yaakov Stein In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5283B40A@exrad2.ad.rad.co.il> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Yaakov, Thanks for response. I didn't quite get the bottom line. Where you arguing that IP and MPLS are not so different that they can both use PWE as just an encapsulation without making PWE a new layer? Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 09:14:42 -0400 Lines: 103 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "Shahram Davari" , "Yaakov Stein" , "Mark Seery" , X-From: pwe3-admin@ietf.org Thu May 22 15:20:06 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: Is PWE a layer? Thread-Index: AcMf3aWYBdPyKUGhRgGnF/T7dOaDXgAg8nEw To: "Mustapha Aissaoui" , "Busschbach, Peter B (Peter)" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4MChRB04761 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Another approach to connection verification is to have ingress PE notify egress PE about the status of the AC via PWE3 control signaling (in lieu of withdrawing VC label which is what the current approach is). The PWE3 status signaling can also be used by the head end PE to notify the status of his PW (in the event tunnel carrying the PW is inoperational). I find low grade loopbacks such as ping or in line notification via some control bits in the control word, less appealing. Such extensions to PWE3 control signaling has been proposed by an extension draft. There is, however, one disadvantage to this approach. It does not detect compromised forwarding capability of PE (PW handoff) or P (tunnel traffic propagation) if the control elements on the affected box does not detect it either. /himanshu wavesmith networks PS. It seems that this discussions is repeating. > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, May 21, 2003 4:36 PM > To: Busschbach, Peter B (Peter) > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > Subject: Re: [PWE3] RE: Is PWE a layer? > > > Peter, > > "Busschbach, Peter B (Peter)" wrote: > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Wednesday, May 21, 2003 2:43 PM > > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > >a) TTL > 2 > > > >Eric Rosen made the point that there are cases in which it > > > >makes sense to splice PWs together and switch based on the PW > > > >label. IMO, that turns the "PW layer" into an MPLS layer. > > > >(It makes you wonder why there is a PW layer in the first > > > >place. Why not define how to adapt client traffic to MPLS > > > >(i.e. remove the demultiplexing function from PWE) and leave > > > >it to the service provider to decide whether there is a need > > > >for additional aggregation via MPLS label stacking.) > > > > > > If PW labels could be switched like MPLS labels, then why > > > can't MPLS-ping be used to test it? > > > > > > > Shahram, > > > > My statement should be read in the context of the question: > is PW an adaptation function or a network layer in itself. My > point was: if you use intermediate nodes to switch based on > the PW Label, then it becomes a network layer in itself. > > > > Can one use Ping to test it? Yes, of course. Was there > anything in my mail that gave you the impression that I > thought one couldn't? > > > > I still have a question about Ping, though. Is it the > intention that >Ping messages be sent periodically? The vccv > draft doesn't specify this. >IMO, for fault management you > need a periodic connectivity check and you >need to define > how you determine that there is a defect. Is it when you > >miss one reply or only after missing multiple replies? > Frankly, you need >a state machine as defined in Y.1711. > > A Ping mechanism is similar to a connectivity verification > mechanism. This is not suited for alarm indication/suppression. It > is intended to be mostly proactive and can have a significant > processing impact on the node for monitoring a large number of > entities. > Let us consider again the scenario of ATM-MPLS-FR service > interworking, with local termination of ATM and FR at each PE. If > the ATM port in the ingress PE fails, you need to generate a > reactive alarm indication on all PWs which are sourced on this port > to inform the remote PE of the defect. You need to be able to do > that without injecting connectivity verification traffic. A > lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is > more suitable. > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 11:16:26 -0400 Lines: 193 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32075.1D026206" Cc: Shahram Davari , Yaakov Stein , Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 17:25:53 2003 Return-path: To: "'Himanshu Shah'" , Mustapha Aissaoui , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32075.1D026206 Content-Type: text/plain; charset="iso-8859-1" Hi, reply in line... I think you're confusing notification with verification. I think there is agreement that notification of attachment circuit status is required and this is required for proper alarm suppression. I think there is general agreement that label withdrawl as a notification mechanism is not a good idea. However IMHO there are numerous mechanisms available ranging from service OAM (e.g. I.610 AIS), PW data plane and PW control plane. [Himanshu>] I am wondering why notification is not adequate for verification. [Dave] I don't think we're talking the same language. I think of notification as informing peer systems of a problem, and verification as performing some type of probing action to detect a problem. Detection results in notification... > Another approach to connection verification > is to have ingress PE notify egress PE about > the status of the AC via PWE3 control signaling > (in lieu of withdrawing VC label which is what > the current approach is). > > The PWE3 status signaling can also be used by > the head end PE to notify the status of his PW > (in the event tunnel carrying the PW is > inoperational). This comment I did not understand. COuld you clarify the scenario you are discussing. [Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2 VC-LSPs make PW bidirectional. Each head end PE is responsible for notification of status changes of his AC and VC-LSP. [Dave] My question is more how does the head end PE know the status of his PW. A secondary issue would be that if there is a PW failure, there is a possiblity of control plane discontinuity as well. > > I find low grade loopbacks such as ping or > in line notification via some control bits in > the control word, less appealing. I'm curious as to your reasoning, as the net result of control plane notification frequently would be some type of dataplane action in the far attachment circuit. [Himanshu>] I am referring to method of connection verification via notification only when the status changes. For example, if you are terminating FR AC, I believe you can respond to LMI status query locally without generating in line ping over PW. If the status changes (as notified by PW3-control), receiving PE would generate LMI async status for the corresponding AC. [DAVE] IMHO apriori distribution of e2e status is not verification. Some mechanism is required to determine the status of each disjoint piece of technology before such status information is available for distribution...I do agree that the information should be distributed rather than having to be queried. I think the disconnect is that in your description above, you are proposing an alternative to triggering a ping as a result of an LMI status query. I would not so tightly couple the maintenance entities. If the PW is broken, it should be known independent of the AC OAM mechanisms and the network be able to distribute that information to the AC facing PEs. cheers Dave ------_=_NextPart_001_01C32075.1D026206 Content-Type: text/html; charset="iso-8859-1" Message
Hi, reply in line...
I think you're confusing notification with verification. I think there is agreement that notification of attachment circuit status is required and this is required for proper alarm suppression. I think there is general agreement that label withdrawl as a notification mechanism is not a good idea. However IMHO there are numerous mechanisms available ranging from service OAM (e.g. I.610 AIS), PW data plane and PW control plane.
[Himanshu>] I am wondering why notification is not adequate for verification. 
 
[Dave] I don't think we're talking the same language. I think of notification as informing peer systems of a problem, and verification as performing some type of probing action to detect a problem.  Detection results in notification...

> Another approach to connection verification
> is to have ingress PE notify egress PE about
> the status of the AC via PWE3 control signaling
> (in lieu of withdrawing VC label which is what
> the current approach is).
>
> The PWE3 status signaling can also be used by
> the head end PE to notify the status of his PW
> (in the event tunnel carrying the PW is
> inoperational).

This comment I did not understand. COuld you clarify the scenario you are discussing.
[Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2 VC-LSPs make PW bidirectional. Each head end PE is responsible for notification of status changes of his AC and VC-LSP. 

[Dave] My question is more how does the head end PE know the status of his PW. A secondary issue would be that if there is a PW failure, there is a possiblity of control plane discontinuity as well. 

 

>
> I find low grade loopbacks such as ping or
> in line notification via some control bits in
> the control word, less appealing.

I'm curious as to your reasoning, as the net result of  control plane notification frequently would be some type of dataplane action in the far attachment circuit.
[Himanshu>]  I am referring to method of connection verification via notification only when the status changes. For example, if you are terminating FR AC, I believe you can respond to LMI status query locally without generating in line ping over PW. If the status changes (as notified by PW3-control), receiving PE would generate LMI async status for the corresponding AC. 

[DAVE] IMHO apriori distribution of e2e status  is not verification. Some mechanism is required to determine the status of each disjoint piece of technology before such status information is available for distribution...I do agree that the information should be distributed rather than having to be queried.

I think the disconnect is that in your description above, you are proposing an alternative to triggering a ping as a result of an LMI status query. I would not so tightly couple the maintenance entities. If the PW is broken, it should be known independent of the AC OAM mechanisms and the network be able to distribute that information to the AC facing PEs.

cheers

Dave

 

------_=_NextPart_001_01C32075.1D026206-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: X/MPLS vs X/IP Date: Thu, 22 May 2003 08:52:53 -0700 (PDT) Lines: 28 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5283B410@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 17:59:59 2003 Return-path: To: Yaakov Stein In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5283B410@exrad2.ad.rad.co.il> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, --- Yaakov Stein wrote: [SNIP] > I wasn't arguing the layering issue here, > but you are quite right that it is relevant. > If MPLS is now a connection oriented layer in its > own right, then we don't need the PW to be And when we talk of MPLS in this context, do we assume that all MPLS control planes result in the same network mode? I know you have stated that MPLS is not quite CO yet, but I was wondering whether you think all forms of MPLS are the same degree of separation from CO? And if not, how does that impact your comments? Additionally, as I re-read the PWE foundation documents, it is clear that it is the intention that a PSN is in fact a layer. What is not clear is whether a PSN is an abstract notion for either the IP or MPLS layers, or whether a PSN is IP or MPLS+ some other glue. If someone could fill me in on the intention, that would be helpful, thanks. thanks, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: X/MPLS vs X/IP Date: Thu, 22 May 2003 16:55:13 +0100 Lines: 81 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 18:08:05 2003 Return-path: To: yaakov_s@rad.com, mark@mseery.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Yakov.....few small points. regards, Neil > > > Connectionless networks have problems with QoS in general, > > > and QoS for the support of real-time streams in particular. > > NH=> Two points here often overlooked: > > there is a difference in how one needs to treat public and > private traffic; > > currently pkts only carry an up-state 'urgency' semantic and not an > > 'importance' semantic.....this is a big difference, eg a > mission critical > > voice call or one to the emergency services vs 'office gossip'. > > As you know Neil, I think that this issue can be properly handled > by using my "paying for quality of service" paradigm. > For those not familiar I will give the distilled version. > > People can get free telephone service over the Internet using > "Free World Dialup", but are willing to pay premium price for > full "toll-quality" service. They are probably also willing to pay > intermediate amounts for intermediate service levels. > So why not give the user the choice? > By allowing the user to select a quality/price level > on a call-to-call basis (e.g. by pressing a digit from 1 to 5) > one can select the bandwidth and network parameters > that match the user's desires, and the importance > rather than the real-time constraint is the dominant factor. NH=> Understood. This makes sense when there is a clear understanding of service between operator and user and across all users. A general public service is the obvious case here. This is not true however in the private case, ie a VPN. It's far less clear how 'importance' can be attached to a pkt which only carries 'urgency' semantics both in an operator-user relationship and *between* different (VPN) users. > I agree that big-I Internet is a different case, > especially with the special mechanisms implemented > for TCP flows. However, once again, I believe it is a valid > offering for low-cost / low-performance services. > > You will probably agree with me that private overprovisioned > well engineered IP networks are more like the MPLS case > from the raw performance (PDV, packet loss) point of view. NH=> Which flavour of MPLS? If you are referring to mp2p I'd say the IP network is a better proposaition because it does any-any as a natural behaviour and does not have the same defect problems. However, MPLS does NOT have a physical layer > > > clock as ATM has, > > NH=> Not sure what you mean by this......ATM (as indeed > every framing format > > above the physical/media level) invariably relies on a co > cct-sw trail to > > convey the timing between nodes (the exception is the case > of ethernet and > > wireless/radio, but these too have their own phy/media stds > for clock recovery) > > I was hinting at mechanisms such as SRTS whereby the clock to > be transfered is referenced to the physical layer clock. NH=> OK thanks, I understand what you meant now, but that is not ATM....that is AAL1 which is an application-interfacing protocol that can sit above any co pkt-sw trechnology in principle. > In my opinion TDM services over PWs are most attractive > to enterprises and specific cases such as long-distance > toll-bypass operators. > I am not expecting major operators to dump their SDH/SONET > networks overnight NH=> Established technologies have a lifetime of order 25 years. I had a large hand in designing the structure/behaviour of the E1 G.704/706 frame about 20 years ago.....still plenty of E1 about. So anyone who discounts the large deployed base of SDH (and ATM) is making a mistake if they intend to deal with large operators. > and run to TDMoMPLS. > which is the reason I deal exclusively with low-rate TDM > and do not consider the SONET/SDHoMPLS case to be important. NH=> You are a wise man Yaakov......but I realised that when I met you. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: X/MPLS vs X/IP Date: Thu, 22 May 2003 17:51:02 +0100 Lines: 40 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 19:01:23 2003 Return-path: To: yaakov_s@rad.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Thanks Yaakov....yes, I agree, in case of *carrying* timing for far-end recovery then you need a decent physical layer. regards, Neil > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: 22 May 2003 17:40 > To: Harrison,N,Neil,IKL2 R > Cc: pwe3@ietf.org > Subject: RE: [PWE3] X/MPLS vs X/IP > > > Neil, > > Just one small point. > > Y(J)S > > > > I was hinting at mechanisms such as SRTS whereby the clock to > > > be transfered is referenced to the physical layer clock. > > > NH=> OK thanks, I understand what you meant now, but that is > > not ATM....that is AAL1 which is an application-interfacing > protocol that can > > sit above any co pkt-sw trechnology in principle. > > Unfortunately it can't. > > The SRTS and similar methods rely on the physical layer. > Since ATM has well defined physical timing, > SRTS can encode the offset of the TDM clock from the > ATM clock. > > So although most of AAL1 is able to work over any layer 2+, > the special clock mechanisms are only for the cases > where the physical layer carries clock. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 13:25:21 -0400 Lines: 354 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32087.1F74DE94" Cc: Shahram Davari , Yaakov Stein , Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 19:29:51 2003 Return-path: To: "'Himanshu Shah'" , Mustapha Aissaoui , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32087.1F74DE94 Content-Type: text/plain; charset="iso-8859-1" Himanshu: I think we are misunderstanding each other. Agreed ;-) I am assuming that underlying tunnelling mechanisms is used to determine the status of the PW. Sort of like, if interface goes down, so does the DLCIs. If tunnel status is down, so are the PWs mapped on it. Yes, although actually determining the tunnel is "down" in the presence of LDP, ECMP etc. it a good trick. IMHO I'd rather see the PWs inherit "down" status from the tunnel status but I do not think that is always possible. With ECMP, you may see failure of only a subset of the PWs carried by the tunnel. Or your ability to detect PSN problems may be much slower than the PW client OAM mechanisms... If LDP is used as tunneling than it is possible that tunnel going down also translates to inability to signal PW status. But in this case, LDP session will go down too. However, in case of RSVP-TE, tunnel may take diff path than directed LDP session and tunnel going down does not translate to inability to signal PW status. BTW, I am not proposing that ping be triggered. All I am saying is that I don't see a need to generate at some time intervals to verify the PW connection. It has scalability issues. Agreed, as mentioned above, would prefer to inherit availability from teh tunnel and simply cover off corner cases... Dave /himanshu -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Thursday, May 22, 2003 11:16 AM To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B (Peter) Cc: Shahram Davari; Yaakov Stein; Mark Seery; pwe3@ietf.org Subject: RE: [PWE3] RE: Is PWE a layer? Hi, reply in line... I think you're confusing notification with verification. I think there is agreement that notification of attachment circuit status is required and this is required for proper alarm suppression. I think there is general agreement that label withdrawl as a notification mechanism is not a good idea. However IMHO there are numerous mechanisms available ranging from service OAM (e.g. I.610 AIS), PW data plane and PW control plane. [Himanshu>] I am wondering why notification is not adequate for verification. [Dave] I don't think we're talking the same language. I think of notification as informing peer systems of a problem, and verification as performing some type of probing action to detect a problem. Detection results in notification... > Another approach to connection verification > is to have ingress PE notify egress PE about > the status of the AC via PWE3 control signaling > (in lieu of withdrawing VC label which is what > the current approach is). > > The PWE3 status signaling can also be used by > the head end PE to notify the status of his PW > (in the event tunnel carrying the PW is > inoperational). This comment I did not understand. COuld you clarify the scenario you are discussing. [Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2 VC-LSPs make PW bidirectional. Each head end PE is responsible for notification of status changes of his AC and VC-LSP. [Dave] My question is more how does the head end PE know the status of his PW. A secondary issue would be that if there is a PW failure, there is a possiblity of control plane discontinuity as well. > > I find low grade loopbacks such as ping or > in line notification via some control bits in > the control word, less appealing. I'm curious as to your reasoning, as the net result of control plane notification frequently would be some type of dataplane action in the far attachment circuit. [Himanshu>] I am referring to method of connection verification via notification only when the status changes. For example, if you are terminating FR AC, I believe you can respond to LMI status query locally without generating in line ping over PW. If the status changes (as notified by PW3-control), receiving PE would generate LMI async status for the corresponding AC. [DAVE] IMHO apriori distribution of e2e status is not verification. Some mechanism is required to determine the status of each disjoint piece of technology before such status information is available for distribution...I do agree that the information should be distributed rather than having to be queried. I think the disconnect is that in your description above, you are proposing an alternative to triggering a ping as a result of an LMI status query. I would not so tightly couple the maintenance entities. If the PW is broken, it should be known independent of the AC OAM mechanisms and the network be able to distribute that information to the AC facing PEs. cheers Dave ------_=_NextPart_001_01C32087.1F74DE94 Content-Type: text/html; charset="iso-8859-1" Message
Himanshu:
I think we are misunderstanding each other.
Agreed ;-)
 
I am assuming that underlying tunnelling
mechanisms is used to determine the
status of the PW. Sort of like, if interface goes
down, so does the DLCIs. If tunnel status is
down, so are the PWs mapped on it.
Yes, although actually determining the tunnel is "down" in the presence of LDP, ECMP etc. it a good trick. IMHO I'd rather see the PWs inherit "down" status from the tunnel status but I do not think that is always possible. With ECMP, you may see failure of only a subset of the PWs carried by the tunnel. Or your ability to detect PSN problems may be much slower than the PW client OAM mechanisms...
 
If LDP is used as tunneling than it is possible that
tunnel going down also translates to inability to
signal PW status. But in this case, LDP session
will go down too. However, in case of RSVP-TE,
tunnel may take diff path than directed LDP session
and tunnel going down does not translate to inability
to signal PW status.
 
 
BTW, I am not proposing that ping be triggered. All
I am saying is that I don't see a need to generate at
some time intervals to verify the PW connection. It
has scalability issues. 
 
Agreed, as mentioned above, would prefer to inherit availability from teh tunnel and simply cover off corner cases...
 
Dave 
 
/himanshu
 
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Thursday, May 22, 2003 11:16 AM
To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery; pwe3@ietf.org
Subject: RE: [PWE3] RE: Is PWE a layer?

Hi, reply in line...
I think you're confusing notification with verification. I think there is agreement that notification of attachment circuit status is required and this is required for proper alarm suppression. I think there is general agreement that label withdrawl as a notification mechanism is not a good idea. However IMHO there are numerous mechanisms available ranging from service OAM (e.g. I.610 AIS), PW data plane and PW control plane.
[Himanshu>] I am wondering why notification is not adequate for verification. 
 
[Dave] I don't think we're talking the same language. I think of notification as informing peer systems of a problem, and verification as performing some type of probing action to detect a problem.  Detection results in notification...

> Another approach to connection verification
> is to have ingress PE notify egress PE about
> the status of the AC via PWE3 control signaling
> (in lieu of withdrawing VC label which is what
> the current approach is).
>
> The PWE3 status signaling can also be used by
> the head end PE to notify the status of his PW
> (in the event tunnel carrying the PW is
> inoperational).

This comment I did not understand. COuld you clarify the scenario you are discussing.
[Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2 VC-LSPs make PW bidirectional. Each head end PE is responsible for notification of status changes of his AC and VC-LSP. 

[Dave] My question is more how does the head end PE know the status of his PW. A secondary issue would be that if there is a PW failure, there is a possiblity of control plane discontinuity as well. 

 

>
> I find low grade loopbacks such as ping or
> in line notification via some control bits in
> the control word, less appealing.

I'm curious as to your reasoning, as the net result of  control plane notification frequently would be some type of dataplane action in the far attachment circuit.
[Himanshu>]  I am referring to method of connection verification via notification only when the status changes. For example, if you are terminating FR AC, I believe you can respond to LMI status query locally without generating in line ping over PW. If the status changes (as notified by PW3-control), receiving PE would generate LMI async status for the corresponding AC. 

[DAVE] IMHO apriori distribution of e2e status  is not verification. Some mechanism is required to determine the status of each disjoint piece of technology before such status information is available for distribution...I do agree that the information should be distributed rather than having to be queried.

I think the disconnect is that in your description above, you are proposing an alternative to triggering a ping as a result of an LMI status query. I would not so tightly couple the maintenance entities. If the PW is broken, it should be known independent of the AC OAM mechanisms and the network be able to distribute that information to the AC facing PEs.

cheers

Dave

 

------_=_NextPart_001_01C32087.1F74DE94-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 14:04:55 -0400 Lines: 56 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Shahram Davari'" , "'Yaakov Stein'" , Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu May 22 20:07:47 2003 Return-path: To: "'Mustapha Aissaoui'" , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, May 21, 2003 6:23 PM > To: Busschbach, Peter B (Peter) > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > Subject: Re: [PWE3] RE: Is PWE a layer? > > [snipped] > My point was that it is more suitable to have a built in fault > indication mechanism to inform the egress PE that the PWs sourced on > the failed ingress PE ATM port are in defect state. But because in > the scenario above ATM is terminated at the ingress PE, you cannot > use ATM AIS but will need a defect indication mechanism for the PW > or inner LSP. The ATM facing side of the PE will continue to operate > as in I.610. > Mustapha, Just to be precise: PWE is a form of network interworking, not service interworking. Therefore, ATM in not "terminated" in the PE. All ATM traffic, including OAM cells, is carried over PWs. Your email suggests that you believe AIS and RDI can not be carried over PWs and that therefore there is a need for some kind of fault indication message to convey failures on the access circuit. That is incorrect. There are two scenarios. 1) An access circuit fails. In that case, the NSP function in the PE that interfaces with that access circuit will generate the appropriate AIS and RDI messages. 2) A PW between two PEs fails. The downstream PE will find out because the PW connectivity verification check fails. The downstream PE will generate AIS and RDI. In fact, it will generate an RDI message that is sent to the upstream PE over the "return PW". I can see only one scenario where you need an additional PW error indication message: if for some reason it is possible that the NSP function in a PE goes down, while the PW adaptation function still works (e.g. when the two are implemented on different circuit packs), then it might be necessary to inform the remote PE of that condition. However, one could probably just rely on the continuity check in the client layer. Peter > > - I don't have any experimental evidence that LSP Ping is > too >heavy-weight to serve as a periodic connectivity > verification messages. >I leave that to the experts to decide. > > I do not have any evidence about LSP Ping either. I meant that using > connectivity verification for detecting a failure is process > intensive because it requires injecting OAM messages continuously. > You do not expect a service provider to run continuously > connectivity verification on all connections (be they VCs, PWs, or > what have you) in the hope to catch a failure. Connectivity > verification has a different role than alarm indication. So for > fault management of PWs, we need both alarm indication/suppression > and connectivity verification. I noticed most of the discussion on > this list focused on the latter and omitted the former. > > > Peter > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 09:51:55 -0400 Lines: 113 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32069.4E6E0978" Cc: Shahram Davari , Yaakov Stein , Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 18:15:43 2003 Return-path: To: "'Himanshu Shah'" , Mustapha Aissaoui , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32069.4E6E0978 Content-Type: text/plain; charset="iso-8859-1" Himanshu: I think you're confusing notification with verification. I think there is agreement that notification of attachment circuit status is required and this is required for proper alarm suppression. I think there is general agreement that label withdrawl as a notification mechanism is not a good idea. However IMHO there are numerous mechanisms available ranging from service OAM (e.g. I.610 AIS), PW data plane and PW control plane. > Another approach to connection verification > is to have ingress PE notify egress PE about > the status of the AC via PWE3 control signaling > (in lieu of withdrawing VC label which is what > the current approach is). > > The PWE3 status signaling can also be used by > the head end PE to notify the status of his PW > (in the event tunnel carrying the PW is > inoperational). This comment I did not understand. COuld you clarify the scenario you are discussing. > > I find low grade loopbacks such as ping or > in line notification via some control bits in > the control word, less appealing. I'm curious as to your reasoning, as the net result of control plane notification frequently would be some type of dataplane action in the far attachment circuit. Dave ------_=_NextPart_001_01C32069.4E6E0978 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

Himanshu:

I think you're confusing notification with = verification. I think there is agreement that notification of = attachment circuit status is required and this is required for proper = alarm suppression. I think there is general agreement that label = withdrawl as a notification mechanism is not a good idea. However IMHO = there are numerous mechanisms available ranging from service OAM (e.g. = I.610 AIS), PW data plane and PW control plane.

> Another approach to connection verification =
> is to have ingress PE notify egress PE = about
> the status of the AC via PWE3 control = signaling
> (in lieu of withdrawing VC label which is = what
> the current approach is).
>
> The PWE3 status signaling can also be used = by
> the head end PE to notify the status of his = PW
> (in the event tunnel carrying the PW is
> inoperational).

This comment I did not understand. COuld you clarify = the scenario you are discussing.

>
> I find low grade loopbacks such as ping or =
> in line notification via some control bits = in
> the control word, less appealing.

I'm curious as to your reasoning, as the net result = of  control plane notification frequently would be some type of = dataplane action in the far attachment circuit.

<snipped to end>

Dave

------_=_NextPart_001_01C32069.4E6E0978-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: X/MPLS vs X/IP Date: Thu, 22 May 2003 17:38:37 +0300 Lines: 107 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Fri May 23 18:27:42 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] X/MPLS vs X/IP Thread-Index: AcMgYxvmSXFT1QgXQTKsm9/zV6VTHgABwVZg To: "Mark Seery" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4ME70B12200 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mark and Neil (I'll try catching Sasha off-line to see what point he wants to make), > [Mark] I didn't quite get the bottom line. Were you arguing > that IP and MPLS are not so different that they can > both use PWE as just an encapsulation without making > PWE a new layer? I was arguing that were MPLS to have been properly designed, or when and if we finish its design to make it truly "carrier class" then perhaps some simplification could be made for MPLS, and it would make sense to keep the two cases separate. I wasn't arguing the layering issue here, but you are quite right that it is relevant. If MPLS is now a connection oriented layer in its own right, then we don't need the PW to be, but then with IP something might be missing. You might have noticed that in earlier versions of draft-anavi I had my own diagnostics and performance measurement mechanisms (based on ICMP packets), which is what we use for the IP case. I removed it from the draft when the MPLS mechanisms improved sufficiently, but we still use them for IP. > > Connectionless networks have problems with QoS in general, > > and QoS for the support of real-time streams in particular. > NH=> Two points here often overlooked: > there is a difference in how one needs to treat public and private traffic; > currently pkts only carry an up-state 'urgency' semantic and not an > 'importance' semantic.....this is a big difference, eg a mission critical > voice call or one to the emergency services vs 'office gossip'. As you know Neil, I think that this issue can be properly handled by using my "paying for quality of service" paradigm. For those not familiar I will give the distilled version. People can get free telephone service over the Internet using "Free World Dialup", but are willing to pay premium price for full "toll-quality" service. They are probably also willing to pay intermediate amounts for intermediate service levels. So why not give the user the choice? By allowing the user to select a quality/price level on a call-to-call basis (e.g. by pressing a digit from 1 to 5) one can select the bandwidth and network parameters that match the user's desires, and the importance rather than the real-time constraint is the dominant factor. > > Now it is perfectly legal to layer a connectionless network > > on top of a connection-oriented one, or a connection-oriented > > one on top of a connectionless one (although in this latter case > > the performance may degrade somewhat). > > The problems arise when we want to support real-time streams. > NH=> Yes it is 'legal' to do this. But have you also ever considered how > many times one is allowed to swap modes in some global reference connection, > and whether an abitrary number of such mode swapping instances would allow > timing recovery? It's an interesting problem... I haven't ever tried measuring the performance as a function of the number of mode swaps, but arbitrary numbers of swaps are not expected. We've done clock recovery for TCP/IP POS, UDP/IP/Ethernet/optical, UDP/IP/Ethernet/cable-modem, UDP/IP/ATM/DSL, and similar cases, and conform to the standard TDM jitter and wander requirements. > > The question is whether they are > > sufficiently different as to merit different protocols. > NH=> There are 2 aspects to this I agree that big-I Internet is a different case, especially with the special mechanisms implemented for TCP flows. However, once again, I believe it is a valid offering for low-cost / low-performance services. You will probably agree with me that private overprovisioned well engineered IP networks are more like the MPLS case from the raw performance (PDV, packet loss) point of view. We will probably have a lot to argue about for the intermediate cases, e.g. using RSVP for IP networks, MPLS networks without TE, etc. > > Were MPLS to have been originally designed as a variable-length-packet > > ATM, rather than as "accelerated-IP" then perhaps the answer > > would have been yes. However, MPLS does NOT have a physical layer > > clock as ATM has, > NH=> Not sure what you mean by this......ATM (as indeed every framing format > above the physical/media level) invariably relies on a co cct-sw trail to > convey the timing between nodes (the exception is the case of ethernet and > wireless/radio, but these too have their own phy/media stds for clock recovery) I was hinting at mechanisms such as SRTS whereby the clock to be transfered is referenced to the physical layer clock. Since ATM defines the lower layers, this can be done. It also MAY be possible for some single hop MPLS cases, but this depends on the lower layer. In general this feature is lost for multi-hop MPLS or IP connections. > NH: but I just ask the question > 'who is your target market/customer here?' In my opinion TDM services over PWs are most attractive to enterprises and specific cases such as long-distance toll-bypass operators. I am not expecting major operators to dump their SDH/SONET networks overnight and run to TDMoMPLS. which is the reason I deal exclusively with low-rate TDM and do not consider the SONET/SDHoMPLS case to be important. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 10:52:44 -0400 Lines: 174 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32071.CD4DD07C" Cc: "Shahram Davari" , "Yaakov Stein" , "Mark Seery" , X-From: pwe3-admin@ietf.org Fri May 23 18:29:38 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: Is PWE a layer? Thread-Index: AcMgaVIJYIfDNVHzTHGY+TjxHhVBnQAAPEOw To: "David Allan" , "Mustapha Aissaoui" , "Busschbach, Peter B (Peter)" Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C32071.CD4DD07C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments in line. -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Thursday, May 22, 2003 9:52 AM To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B (Peter) Cc: Shahram Davari; Yaakov Stein; Mark Seery; pwe3@ietf.org Subject: RE: [PWE3] RE: Is PWE a layer? Himanshu:=20 I think you're confusing notification with verification. I think there = is agreement that notification of attachment circuit status is required = and this is required for proper alarm suppression. I think there is = general agreement that label withdrawl as a notification mechanism is = not a good idea. However IMHO there are numerous mechanisms available = ranging from service OAM (e.g. I.610 AIS), PW data plane and PW control = plane.=20 [Himanshu>] I am wondering why notification is not adequate for = verification. > Another approach to connection verification=20 > is to have ingress PE notify egress PE about=20 > the status of the AC via PWE3 control signaling=20 > (in lieu of withdrawing VC label which is what=20 > the current approach is).=20 >=20 > The PWE3 status signaling can also be used by=20 > the head end PE to notify the status of his PW=20 > (in the event tunnel carrying the PW is=20 > inoperational).=20 This comment I did not understand. COuld you clarify the scenario you = are discussing.=20 [Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2 = VC-LSPs make PW bidirectional. Each head end PE is responsible for = notification of status changes of his AC and VC-LSP. =20 >=20 > I find low grade loopbacks such as ping or=20 > in line notification via some control bits in=20 > the control word, less appealing.=20 I'm curious as to your reasoning, as the net result of control plane = notification frequently would be some type of dataplane action in the = far attachment circuit. [Himanshu>] I am referring to method of connection verification via = notification only when the status changes. For example, if you are = terminating FR AC, I believe you can respond to LMI status query locally = without generating in line ping over PW. If the status changes (as = notified by PW3-control), receiving PE would generate LMI async status = for the corresponding AC. /himanshu =20 Dave=20 ------_=_NextPart_001_01C32071.CD4DD07C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?
Comments in line.
-----Original Message-----
From: David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Thursday, May 22, = 2003 9:52=20 AM
To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B = (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery;=20 pwe3@ietf.org
Subject: RE: [PWE3] RE: Is PWE a=20 layer?

Himanshu:

I think you're confusing notification with = verification. I=20 think there is agreement that notification of attachment circuit = status is=20 required and this is required for proper alarm suppression. I think = there is=20 general agreement that label withdrawl as a notification mechanism is = not a=20 good idea. However IMHO there are numerous mechanisms available = ranging from=20 service OAM (e.g. I.610 AIS), PW data plane and PW control plane. =
[Himanshu>] I=20 am wondering why notification is not adequate for=20 verification.

> Another approach to connection verification=20
> is to have ingress PE notify egress PE=20 about
> the status of the AC via PWE3 = control=20 signaling
> (in lieu of withdrawing VC = label which=20 is what
> the current approach = is).=20
>
> The PWE3 status = signaling=20 can also be used by
> the head end PE to = notify the=20 status of his PW
> (in the event tunnel = carrying=20 the PW is
> inoperational).

This comment I did not understand. COuld you clarify = the=20 scenario you are discussing.
[Himanshu>] I am refering to = the status of=20 the unidirectional VC-LSP. 2 VC-LSPs make PW bidirectional. Each head = end PE=20 is responsible for notification of status changes of his AC and=20 VC-LSP.

 

>
> I find low grade = loopbacks=20 such as ping or
> in line notification = via some=20 control bits in
> the control word, less=20 appealing.

I'm curious as to your reasoning, as the net result = of =20 control plane notification frequently would be some type of dataplane = action=20 in the far attachment circuit.
[Himanshu>]  I am referring to = method of=20 connection verification via notification only when the status changes. = For=20 example, if you are terminating FR AC, I believe you can respond to = LMI status=20 query locally without generating in line ping over PW. If the = status=20 changes (as notified by PW3-control), receiving PE would generate LMI = async=20 status for the corresponding AC.

/himanshu

<snipped to end>

Dave

------_=_NextPart_001_01C32071.CD4DD07C-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 11:47:48 -0400 Lines: 382 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32079.7E83CF82" Cc: "Shahram Davari" , "Yaakov Stein" , "Mark Seery" , X-From: pwe3-admin@ietf.org Fri May 23 18:42:44 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: Is PWE a layer? Thread-Index: AcMgdSBLMzfh4SWQQL2lA+L6pslOQQAAeNaw To: "David Allan" , "Mustapha Aissaoui" , "Busschbach, Peter B (Peter)" Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C32079.7E83CF82 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think we are misunderstanding each other. =20 I am assuming that underlying tunnelling mechanisms is used to determine the status of the PW. Sort of like, if interface goes down, so does the DLCIs. If tunnel status is down, so are the PWs mapped on it. =20 If LDP is used as tunneling than it is possible that tunnel going down also translates to inability to signal PW status. But in this case, LDP session will go down too. However, in case of RSVP-TE, tunnel may take diff path than directed LDP session and tunnel going down does not translate to inability to signal PW status. =20 =20 BTW, I am not proposing that ping be triggered. All=20 I am saying is that I don't see a need to generate at some time intervals to verify the PW connection. It has scalability issues. =20 /himanshu =20 -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Thursday, May 22, 2003 11:16 AM To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B (Peter) Cc: Shahram Davari; Yaakov Stein; Mark Seery; pwe3@ietf.org Subject: RE: [PWE3] RE: Is PWE a layer? Hi, reply in line... I think you're confusing notification with verification. I think there = is agreement that notification of attachment circuit status is required = and this is required for proper alarm suppression. I think there is = general agreement that label withdrawl as a notification mechanism is = not a good idea. However IMHO there are numerous mechanisms available = ranging from service OAM (e.g. I.610 AIS), PW data plane and PW control = plane.=20 [Himanshu>] I am wondering why notification is not adequate for = verification.=20 =20 [Dave] I don't think we're talking the same language. I think of = notification as informing peer systems of a problem, and verification as = performing some type of probing action to detect a problem. Detection = results in notification... > Another approach to connection verification=20 > is to have ingress PE notify egress PE about=20 > the status of the AC via PWE3 control signaling=20 > (in lieu of withdrawing VC label which is what=20 > the current approach is).=20 >=20 > The PWE3 status signaling can also be used by=20 > the head end PE to notify the status of his PW=20 > (in the event tunnel carrying the PW is=20 > inoperational).=20 This comment I did not understand. COuld you clarify the scenario you = are discussing.=20 [Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2 = VC-LSPs make PW bidirectional. Each head end PE is responsible for = notification of status changes of his AC and VC-LSP.=20 [Dave] My question is more how does the head end PE know the status of = his PW. A secondary issue would be that if there is a PW failure, there = is a possiblity of control plane discontinuity as well.=20 =20 >=20 > I find low grade loopbacks such as ping or=20 > in line notification via some control bits in=20 > the control word, less appealing.=20 I'm curious as to your reasoning, as the net result of control plane = notification frequently would be some type of dataplane action in the = far attachment circuit. [Himanshu>] I am referring to method of connection verification via = notification only when the status changes. For example, if you are = terminating FR AC, I believe you can respond to LMI status query locally = without generating in line ping over PW. If the status changes (as = notified by PW3-control), receiving PE would generate LMI async status = for the corresponding AC.=20 [DAVE] IMHO apriori distribution of e2e status is not verification. = Some mechanism is required to determine the status of each disjoint = piece of technology before such status information is available for = distribution...I do agree that the information should be distributed = rather than having to be queried. I think the disconnect is that in your description above, you are = proposing an alternative to triggering a ping as a result of an LMI = status query. I would not so tightly couple the maintenance entities. If = the PW is broken, it should be known independent of the AC OAM = mechanisms and the network be able to distribute that information to the = AC facing PEs. cheers Dave =20 ------_=_NextPart_001_01C32079.7E83CF82 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
I=20 think we are misunderstanding each other.
 
I am=20 assuming that underlying tunnelling
mechanisms is used to determine = the
status=20 of the PW. Sort of like, if interface goes
down,=20 so does the DLCIs. If tunnel status is
down,=20 so are the PWs mapped on it.
 
If LDP=20 is used as tunneling than it is possible that
tunnel=20 going down also translates to inability to
signal=20 PW status. But in this case, LDP session
will=20 go down too. However, in case of RSVP-TE,
tunnel=20 may take diff path than directed LDP session
and=20 tunnel going down does not translate to inability
to=20 signal PW status.
 
 
BTW, I=20 am not proposing that ping be triggered. All
I am=20 saying is that I don't see a need to generate at
some=20 time intervals to verify the PW connection. It
has=20 scalability issues.
 
/himanshu
 
-----Original Message-----
From: David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Thursday, May 22, = 2003=20 11:16 AM
To: Himanshu Shah; Mustapha Aissaoui; Busschbach, = Peter B=20 (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery;=20 pwe3@ietf.org
Subject: RE: [PWE3] RE: Is PWE a=20 layer?

Hi,=20 reply in line...
I=20 think you're confusing notification with verification. I think there = is=20 agreement that notification of attachment circuit status is required = and=20 this is required for proper alarm suppression. I think there is = general=20 agreement that label withdrawl as a notification mechanism is not a = good=20 idea. However IMHO there are numerous mechanisms available ranging = from=20 service OAM (e.g. I.610 AIS), PW data plane and PW control plane. =
[Himanshu>] I am wondering why notification = is not=20 adequate for verification. 
 
[Dave] I don't think = we're=20 talking the same language. I think of notification as informing peer = systems=20 of a problem, and verification as performing some type of probing = action=20 to detect a problem.  Detection results in=20 notification...

> Another approach to connection verification =
> is to have ingress PE notify egress = PE=20 about
> the status of the AC via PWE3 = control=20 signaling
> (in lieu of withdrawing = VC label=20 which is what
> the current approach=20 is).
>
> = The PWE3=20 status signaling can also be used by
> the head=20 end PE to notify the status of his PW
> (in the=20 event tunnel carrying the PW is
>=20 inoperational).

This comment I did not understand. COuld you = clarify the=20 scenario you are discussing.
[Himanshu>] I am refering to the status of the = unidirectional=20 VC-LSP. 2 VC-LSPs make PW bidirectional. Each head end PE is = responsible=20 for notification of status changes of his AC and VC-LSP. 

<= /BLOCKQUOTE>

[Dave] = My question=20 is more how does the head end PE know the status of his PW. A = secondary=20 issue would be that if there is a PW failure, there is a = possiblity of=20 control plane discontinuity as=20 well. 

 

>
> I find low = grade=20 loopbacks such as ping or
> in line=20 notification via some control bits in
> the=20 control word, less appealing.

I'm curious as to your reasoning, as the net = result=20 of  control plane notification frequently would be some type = of=20 dataplane action in the far attachment circuit.
[Himanshu>]  I am referring = to method=20 of connection verification via notification only when the status=20 changes. For example, if you are terminating FR = AC, I=20 believe you can respond to LMI status query locally without=20 generating in line ping over PW. If the status changes (as notified by=20 PW3-control), receiving PE would generate LMI async status for the = corresponding AC. 

<= /BLOCKQUOTE>

[DAVE] = IMHO apriori=20 distribution of e2e status  is not verification. Some mechanism = is=20 required to determine the status of each disjoint piece of technology = before=20 such status information is available for distribution...I do agree = that the=20 information should be distributed rather than having to be=20 queried.

I think = the disconnect=20 is that in your description above, you are proposing an alternative to = triggering a ping as a result of an LMI status query. I would not so = tightly=20 couple the maintenance entities. If the PW is broken, it should be = known=20 independent of the AC OAM mechanisms and the network be able to = distribute=20 that information to the AC facing = PEs.

cheers

Dave

 

------_=_NextPart_001_01C32079.7E83CF82-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: X/MPLS vs X/IP Date: Thu, 22 May 2003 19:39:55 +0300 Lines: 25 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: X-From: pwe3-admin@ietf.org Fri May 23 18:49:47 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] X/MPLS vs X/IP Thread-Index: AcMgeqH7gyrLh28iR4mKx/PFORWyFAABZzeA To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4MG8JB24182 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, Just one small point. Y(J)S > > I was hinting at mechanisms such as SRTS whereby the clock to > > be transfered is referenced to the physical layer clock. > NH=> OK thanks, I understand what you meant now, but that is > not ATM....that is AAL1 which is an application-interfacing protocol that can > sit above any co pkt-sw trechnology in principle. Unfortunately it can't. The SRTS and similar methods rely on the physical layer. Since ATM has well defined physical timing, SRTS can encode the offset of the TDM clock from the ATM clock. So although most of AAL1 is able to work over any layer 2+, the special clock mechanisms are only for the cases where the physical layer carries clock. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 15:35:43 -0400 Organization: Cisco Systems Lines: 78 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Fri May 23 18:56:30 2003 Return-path: To: "'Busschbach, Peter B \(Peter\)'" , "'Shahram Davari'" , "'Yaakov Stein'" , "'Mark Seery'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Busschbach, Peter B (Peter) > Sent: Wednesday, May 21, 2003 2:52 PM > To: 'Shahram Davari'; Busschbach, Peter B (Peter); 'Yaakov > Stein'; Mark Seery > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, May 21, 2003 2:43 PM > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > >a) TTL > 2 > > >Eric Rosen made the point that there are cases in which it > > >makes sense to splice PWs together and switch based on the PW > > >label. IMO, that turns the "PW layer" into an MPLS layer. > > >(It makes you wonder why there is a PW layer in the first > > >place. Why not define how to adapt client traffic to MPLS > > >(i.e. remove the demultiplexing function from PWE) and leave > > >it to the service provider to decide whether there is a need > > >for additional aggregation via MPLS label stacking.) > > > > If PW labels could be switched like MPLS labels, then why > > can't MPLS-ping be used to test it? > > > > Shahram, > > My statement should be read in the context of the question: > is PW an adaptation function or a network layer in itself. My > point was: if you use intermediate nodes to switch based on > the PW Label, then it becomes a network layer in itself. > > Can one use Ping to test it? Yes, of course. Was there > anything in my mail that gave you the impression that I > thought one couldn't? > I still have a question about Ping, though. Is it the > intention that Ping messages be sent periodically? The vccv > draft doesn't specify this. IMO, for fault management you > need a periodic connectivity check and you need to define how > you determine that there is a defect. Is it when you miss one > reply or only after missing multiple replies? This is more of an operational issue. My team and I have spoken to over 25 operators about VCCV and LSP Ping, and all 25 give me preciesely different answers about how often they want to run either tool. It depends largely on the application being used, as well as the SLA. Based on these data points, the VCCV draft does not specify any periodicity. > Frankly, you need a state machine as defined in Y.1711. This is contrary to the aforementioned customer input I have received. --Tom > Peter > > > -Shahram > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: Mapping between the connection verification status of PW and the native ATM services Date: Thu, 22 May 2003 14:57:34 -0400 Organization: Cisco Systems Lines: 80 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06FC_01C32072.7AAA7D60" X-From: pwe3-admin@ietf.org Fri May 23 19:01:37 2003 Return-path: To: "'Qiu Jin'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------=_NextPart_000_06FC_01C32072.7AAA7D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Take a look at: http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-00.txt > In the draft-ietf-pwe3-arch-02.txt, section 8.3 says, If > connection verification status of PW is needed by the CE, it > must be mapped to the native connection status method. Are > there any one can point me where can I find more detail > information about the mapping between the connection > verification status of PW and ATM OAM? > > Thanks > Qiu > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------=_NextPart_000_06FC_01C32072.7AAA7D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
    Take a look = at:
 
http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-ma= p-00.txt
> In the draft-ietf-pwe3-arch-02.txt, section 8.3 says, If =
> connection verification status of PW is = needed by=20 the CE, it
> must be mapped to the native = connection status method. Are
> there any = one can=20 point me where can I find more detail
> = information=20 about the mapping between the connection
>=20 verification status of PW and ATM OAM?
>=20
> Thanks
> = Qiu=20
> = _______________________________________________=20
> pwe3 mailing list
>=20 pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3 =
>
------=_NextPart_000_06FC_01C32072.7AAA7D60-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: RE: Is PWE a layer? Date: Thu, 22 May 2003 14:39:20 -0400 Organization: Alcatel Networks Corporaton Lines: 63 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'Shahram Davari'" , "'Yaakov Stein'" , Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 19:01:48 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, I think we are in agreement for the network interworking case. I was referring to a service interworking case where each Layer 2 access technology is terminated locally at a PE. Regards, Mustapha. ---------- "Busschbach, Peter B (Peter)" wrote: > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Wednesday, May 21, 2003 6:23 PM > > To: Busschbach, Peter B (Peter) > > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > > Subject: Re: [PWE3] RE: Is PWE a layer? > > > > > [snipped] > > > My point was that it is more suitable to have a built in fault > > indication mechanism to inform the egress PE that the PWs sourced on > > the failed ingress PE ATM port are in defect state. But because in > > the scenario above ATM is terminated at the ingress PE, you cannot > > use ATM AIS but will need a defect indication mechanism for the PW > > or inner LSP. The ATM facing side of the PE will continue to operate > > as in I.610. > > > > Mustapha, > > Just to be precise: PWE is a form of network interworking, not service interworking. Therefore, ATM in not "terminated" in the PE. All ATM traffic, including OAM cells, is carried over PWs. > > Your email suggests that you believe AIS and RDI can not be carried over PWs and that therefore there is a need for some kind of fault indication message to convey failures on the access circuit. That is incorrect. > > There are two scenarios. > > 1) An access circuit fails. In that case, the NSP function in the PE that interfaces with that access circuit will generate the appropriate AIS and RDI messages. > > 2) A PW between two PEs fails. The downstream PE will find out because the PW connectivity verification check fails. The downstream PE will generate AIS and RDI. In fact, it will generate an RDI message that is sent to the upstream PE over the "return PW". > > I can see only one scenario where you need an additional PW error indication message: if for some reason it is possible that the NSP function in a PE goes down, while the PW adaptation function still works (e.g. when the two are implemented on different circuit packs), then it might be necessary to inform the remote PE of that condition. However, one could probably just rely on the continuity check in the client layer. > > Peter > > > > - I don't have any experimental evidence that LSP Ping is > > too >heavy-weight to serve as a periodic connectivity > > verification messages. >I leave that to the experts to decide. > > > > I do not have any evidence about LSP Ping either. I meant that using > > connectivity verification for detecting a failure is process > > intensive because it requires injecting OAM messages continuously. > > You do not expect a service provider to run continuously > > connectivity verification on all connections (be they VCs, PWs, or > > what have you) in the hope to catch a failure. Connectivity > > verification has a different role than alarm indication. So for > > fault management of PWs, we need both alarm indication/suppression > > and connectivity verification. I noticed most of the discussion on > > this list focused on the latter and omitted the former. > > > > > Peter > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 17:30:34 +0100 Lines: 54 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: Shahram_Davari@pmc-sierra.com, yaakov_s@rad.com, mark@mseery.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 19:03:40 2003 Return-path: To: dallan@nortelnetworks.com, hshah@wavesmithnetworks.com, mustapha.aissaoui@alcatel.com, busschbach@lucent.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Dave...I agree with your comments....but wish to add a small extra point. regards, Neil > Another approach to connection verification > is to have ingress PE notify egress PE about > the status of the AC via PWE3 control signaling > (in lieu of withdrawing VC label which is what > the current approach is). > > The PWE3 status signaling can also be used by > the head end PE to notify the status of his PW > (in the event tunnel carrying the PW is > inoperational). This comment I did not understand. COuld you clarify the scenario you are discussing. [Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2 VC-LSPs make PW bidirectional. Each head end PE is responsible for notification of status changes of his AC and VC-LSP. [Dave] My question is more how does the head end PE know the status of his PW. A secondary issue would be that if there is a PW failure, there is a possiblity of control plane discontinuity as well. NH=>Date-plane defect handling should be automatic/executive, independent of the control-plane signalling (and must work the same with no signalling) and be unidirectional, ie actions are to be taken at the sink. > > I find low grade loopbacks such as ping or > in line notification via some control bits in > the control word, less appealing. I'm curious as to your reasoning, as the net result of control plane notification frequently would be some type of dataplane action in the far attachment circuit. [Himanshu>] I am referring to method of connection verification via notification only when the status changes. For example, if you are terminating FR AC, I believe you can respond to LMI status query locally without generating in line ping over PW. If the status changes (as notified by PW3-control), receiving PE would generate LMI async status for the corresponding AC. [DAVE] IMHO apriori distribution of e2e status is not verification. Some mechanism is required to determine the status of each disjoint piece of technology before such status information is available for distribution...I do agree that the information should be distributed rather than having to be queried. I think the disconnect is that in your description above, you are proposing an alternative to triggering a ping as a result of an LMI status query. I would not so tightly couple the maintenance entities. If the PW is broken, it should be known independent of the AC OAM mechanisms and the network be able to distribute that information to the AC facing PEs. cheers NH=> Correct. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 15:38:30 -0400 Organization: Cisco Systems Lines: 56 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Fri May 23 19:04:30 2003 Return-path: To: "'Busschbach, Peter B \(Peter\)'" , "'Shahram Davari'" , "'Yaakov Stein'" , "'Mark Seery'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Busschbach, Peter B (Peter) > Sent: Wednesday, May 21, 2003 4:26 PM > To: 'Shahram Davari'; Busschbach, Peter B (Peter); 'Yaakov > Stein'; Mark Seery > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, May 21, 2003 3:12 PM > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > [snipped] > > > Agree. Since MPLS-ping is a loopback mechanism, it seems that the > > period, processing, state machines, etc, are local matter to the > > source and probably don't need standardization. But off course if a > > service provider wants to offer a consistent service SLA across its > > network, then these issues need to be nailed down. And that is precisely what my customers are doing -- nailing down the problem based on local constraints. Even in a multi-vendor network, this still works. There is no need for the tools to mandate specifically how they should be used. --Tom > > > > -Shahram > > > > Shahram, > > I think you need a tighter coupling between both ends of a PW > than LSP Ping provides. E.g. the downstream end should > generate an alarm if it doesn't receive the periodic > connectivity verification message (which could be the same > LSP Ping message, but with different semantics) from the > upstream end. To enable such behavior, you need a > standardized solution. > > Peter > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 15:48:42 -0400 Organization: Cisco Systems Lines: 109 Sender: pwe3-admin@ietf.org References: <3ECBE32B.6D7F4D38@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Shahram Davari'" , "'Yaakov Stein'" , "'Mark Seery'" , X-From: pwe3-admin@ietf.org Fri May 23 19:11:02 2003 Return-path: To: "'Mustapha Aissaoui'" , "'Busschbach, Peter B \(Peter\)'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3ECBE32B.6D7F4D38@alcatel.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mustapha Aissaoui > Sent: Wednesday, May 21, 2003 4:36 PM > To: Busschbach, Peter B (Peter) > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > Subject: Re: [PWE3] RE: Is PWE a layer? > > > Peter, > > "Busschbach, Peter B (Peter)" wrote: > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Wednesday, May 21, 2003 2:43 PM > > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > >a) TTL > 2 > > > >Eric Rosen made the point that there are cases in which it makes > > > >sense to splice PWs together and switch based on the PW > label. IMO, > > > >that turns the "PW layer" into an MPLS layer. (It makes > you wonder > > > >why there is a PW layer in the first place. Why not > define how to > > > >adapt client traffic to MPLS (i.e. remove the demultiplexing > > > >function from PWE) and leave it to the service provider > to decide > > > >whether there is a need for additional aggregation via > MPLS label > > > >stacking.) > > > > > > If PW labels could be switched like MPLS labels, then why can't > > > MPLS-ping be used to test it? > > > > > > > Shahram, > > > > My statement should be read in the context of the question: > is PW an > > adaptation function or a network layer in itself. My point > was: if you > > use intermediate nodes to switch based on the PW Label, then it > > becomes a network layer in itself. > > > > Can one use Ping to test it? Yes, of course. Was there > anything in my > > mail that gave you the impression that I thought one couldn't? > > > > I still have a question about Ping, though. Is it the > intention that > > >Ping messages be sent periodically? The vccv draft doesn't specify > > this. >IMO, for fault management you need a periodic connectivity > > check and you >need to define how you determine that there is a > > defect. Is it when you >miss one reply or only after > missing multiple > > replies? Frankly, you need >a state machine as defined in Y.1711. > > A Ping mechanism is similar to a connectivity verification > mechanism. This is not suited for alarm > indication/suppression. It is intended to be mostly proactive > and can have a significant processing impact on the node for > monitoring a large number of entities. Not necessarily. The triggering of CV (whether VCCV, ICMP ping or LSP ping) can be automated on a device, and this can be done in such a way as to have minimal impact on the device's CPU. This same device can also be programmed to trigger or suppress alarms based on the status of such actions. But arguing about this in theory is a waste of time. The proof is in the pudding, so check the implementations that have implemented these tools and see how scalable they are. As usual, the market will decide which solutions are most appropriate. > Let us consider again the scenario of ATM-MPLS-FR service > interworking, with local termination of ATM and FR at each > PE. If the ATM port in the ingress PE fails, you need to > generate a reactive alarm indication on all PWs which are > sourced on this port to inform the remote PE of the defect. > You need to be able to do that without injecting connectivity > verification traffic. A lightweight mechanism such as I.610 > AIS/RDI or Y.1711 FDI/BDI is more suitable. Since Y.1711 only works for MPLS as the PSN, this doesn't seem appropriate for PWE3 which must have solutions that work for both L2TPv3 and MPLS. BTW, VCCV works for both L2TPv3 and MPLS as of the next draft, and provides a consistent interface for operators regardless of the underlying PSN or VC type being tested. --Tom > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: RE: Is PWE a layer? Date: Thu, 22 May 2003 16:00:34 -0400 Organization: Alcatel Networks Corporaton Lines: 28 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D68A0@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: busschbach@lucent.com, Shahram_Davari@pmc-sierra.com, yaakov_s@rad.com, mark@mseery.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 19:15:15 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: neil.2.harrison@bt.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, thanks for the details. My main point in the message to Peter, and you said that below too, was that the forward and backward defect indication should be automatic and not be queried for. While connectivity verification is a query mechanism. Also, see a question below. Mustapha. ---------- neil.2.harrison@bt.com wrote: [snipped] > L2 DEFECTS > > (i) In direction *towards* IWF: > At IWF defects detected from CV flow (consequent actions are dependent on > type of defect). FDI generated immediately in other partition and CV > generation there suppressed. I am not sure I understand why the CV generation in the defect-free partition should be suppressed. Since the ATM and MPLS (innel LSP) are peer layers in this case, I would have thought that the CV in the other partition should continue to operate since it checks only that parition. [snipped] From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 16:14:43 -0400 Organization: Cisco Systems Lines: 89 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Fri May 23 19:15:28 2003 Return-path: To: "'Busschbach, Peter B \(Peter\)'" , "'Shahram Davari'" , "'Yaakov Stein'" , "'Mark Seery'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Thursday, May 22, 2003 3:45 PM > To: 'tnadeau@cisco.com'; Busschbach, Peter B (Peter); > 'Shahram Davari'; 'Yaakov Stein'; 'Mark Seery' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > [snipped] > > > > > I still have a question about Ping, though. Is it the > > > intention that Ping messages be sent periodically? The vccv > > > draft doesn't specify this. IMO, for fault management you > > > need a periodic connectivity check and you need to define how > > > you determine that there is a defect. Is it when you miss one > > > reply or only after missing multiple replies? > > > > This is more of an operational issue. > > My team and I have spoken to over 25 operators about VCCV and > > LSP Ping, and all 25 give me preciesely different answers about > > how often they want to run either tool. It depends largely on > > the application being used, as well as the SLA. Based on these > > data points, the VCCV draft does not specify any periodicity. > > > > > Frankly, you need a state machine as defined in Y.1711. > > > > This is contrary to the aforementioned customer > > input I have received. > > > > Tom, > > When you say "how often they want to run the tool", what is > the model?: > > a) the operator (or network management system) instructing > the PE to execute LSP Ping > > or, > > b) the PE autonomously generating LSP Ping messages. > > In case of b), is a failure on the PW translated to an alarm > indication in the client layer (e.g. ATM AIS/RDI)? Both, and not necessarily one or the other (i.e.: some like a combination of the two simultaneously). As I mentioned, I have spoken to a lot of customers about using this tool, and all of them like using LSP ping/VCCV, but all of them have different ideas about just how to use these tools. Many have different ideas about how to use the tools *together* as well, BTW. Some want to run the tools from remote management stations (and have it integrated into their existing OSS), while others want the device to do as much as possible and only tell them when something has gone really wrong (i.e.: the device cannot fix things itself), at which point they might do ad hoc trouble-shooting using one or more of the tools (vrf-aware ping, LSP ping, ICMP ping, VCCV). --Tom > Thanks, > > Peter > > > --Tom > > > > > > > > > Peter > > > > > > > -Shahram > > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: RE: Is PWE a layer? Date: Thu, 22 May 2003 16:15:36 -0400 Organization: Alcatel Networks Corporaton Lines: 123 Sender: pwe3-admin@ietf.org References: <072801c3209b$29311c90$6601a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'Busschbach, Peter B (Peter)'" , "'Shahram Davari'" , "'Yaakov Stein'" , "'Mark Seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 19:15:53 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: tnadeau@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, "Thomas D. Nadeau" wrote: > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Mustapha Aissaoui > > Sent: Wednesday, May 21, 2003 4:36 PM > > To: Busschbach, Peter B (Peter) > > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > > Subject: Re: [PWE3] RE: Is PWE a layer? > > > > > > Peter, > > > > "Busschbach, Peter B (Peter)" wrote: > > > > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Wednesday, May 21, 2003 2:43 PM > > > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > > > > Cc: pwe3@ietf.org > > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > > > > >a) TTL > 2 > > > > >Eric Rosen made the point that there are cases in which it makes > > > > >sense to splice PWs together and switch based on the PW > > label. IMO, > > > > >that turns the "PW layer" into an MPLS layer. (It makes > > you wonder > > > > >why there is a PW layer in the first place. Why not > > define how to > > > > >adapt client traffic to MPLS (i.e. remove the demultiplexing > > > > >function from PWE) and leave it to the service provider > > to decide > > > > >whether there is a need for additional aggregation via > > MPLS label > > > > >stacking.) > > > > > > > > If PW labels could be switched like MPLS labels, then why can't > > > > MPLS-ping be used to test it? > > > > > > > > > > Shahram, > > > > > > My statement should be read in the context of the question: > > is PW an > > > adaptation function or a network layer in itself. My point > > was: if you > > > use intermediate nodes to switch based on the PW Label, then it > > > becomes a network layer in itself. > > > > > > Can one use Ping to test it? Yes, of course. Was there > > anything in my > > > mail that gave you the impression that I thought one couldn't? > > > > > > I still have a question about Ping, though. Is it the > > intention that > > > >Ping messages be sent periodically? The vccv draft doesn't specify > > > this. >IMO, for fault management you need a periodic connectivity > > > check and you >need to define how you determine that there is a > > > defect. Is it when you >miss one reply or only after > > missing multiple > > > replies? Frankly, you need >a state machine as defined in Y.1711. > > > > A Ping mechanism is similar to a connectivity verification > > mechanism. This is not suited for alarm > > indication/suppression. It is intended to be mostly proactive > > and can have a significant processing impact on the node for > > monitoring a large number of entities. > > Not necessarily. The triggering of CV (whether > VCCV, ICMP ping or LSP ping) can be automated on a device, > and this can be done in such a way as to have > minimal impact on the device's CPU. This same device > can also be programmed to trigger or suppress alarms > based on the status of such actions. Sure. Nontheless, a ping mechanism is a query mechanism. You need to turn it on continously on LSPs in order to catch a fault. Fault detection should be automatic and OAM messages are only generated at the detection of a fault for the impacted LSPs only. Though connectivity verification is important for detecting discontinuity in the user plane which are not the result of a physical layer fault or which are not detected through the control plane. > But arguing about this in theory is a waste of > time. The proof is in the pudding, so check the > implementations that have implemented these tools > and see how scalable they are. Good for you :-) >As usual, the market > will decide which solutions are most appropriate. > > Let us consider again the scenario of ATM-MPLS-FR service > > interworking, with local termination of ATM and FR at each > > PE. If the ATM port in the ingress PE fails, you need to > > generate a reactive alarm indication on all PWs which are > > sourced on this port to inform the remote PE of the defect. > > You need to be able to do that without injecting connectivity > > verification traffic. A lightweight mechanism such as I.610 > > AIS/RDI or Y.1711 FDI/BDI is more suitable. > > Since Y.1711 only works for MPLS > as the PSN, this doesn't seem appropriate for PWE3 which > must have solutions that work for both L2TPv3 and MPLS. > BTW, VCCV works for both L2TPv3 and MPLS as of the next > draft, and provides a consistent interface for operators > regardless of the underlying PSN or VC type being > tested. > > --Tom > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 15:45:25 -0400 Lines: 55 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 19:16:39 2003 Return-path: To: "'tnadeau@cisco.com'" , "Busschbach, Peter B (Peter)" , "'Shahram Davari'" , "'Yaakov Stein'" , "'Mark Seery'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O [snipped] > > I still have a question about Ping, though. Is it the > > intention that Ping messages be sent periodically? The vccv > > draft doesn't specify this. IMO, for fault management you > > need a periodic connectivity check and you need to define how > > you determine that there is a defect. Is it when you miss one > > reply or only after missing multiple replies? > > This is more of an operational issue. > My team and I have spoken to over 25 operators about VCCV and > LSP Ping, and all 25 give me preciesely different answers about > how often they want to run either tool. It depends largely on > the application being used, as well as the SLA. Based on these > data points, the VCCV draft does not specify any periodicity. > > > Frankly, you need a state machine as defined in Y.1711. > > This is contrary to the aforementioned customer > input I have received. > Tom, When you say "how often they want to run the tool", what is the model?: a) the operator (or network management system) instructing the PE to execute LSP Ping or, b) the PE autonomously generating LSP Ping messages. In case of b), is a failure on the PW translated to an alarm indication in the client layer (e.g. ATM AIS/RDI)? Thanks, Peter > --Tom > > > > > Peter > > > > > -Shahram > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: Is PWE a layer? Date: Thu, 22 May 2003 14:21:51 -0700 (PDT) Lines: 27 Sender: pwe3-admin@ietf.org References: <072201c32099$58d0a620$6601a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 19:21:37 2003 Return-path: To: tnadeau@cisco.com In-Reply-To: <072201c32099$58d0a620$6601a8c0@amer.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Tom, --- "Thomas D. Nadeau" wrote: > This is more of an operational issue. > My team and I have spoken to over 25 operators about > VCCV and > LSP Ping, and all 25 give me preciesely different > answers about > how often they want to run either tool. It depends > largely on > the application being used, as well as the SLA. > Based on these > data points, the VCCV draft does not specify any > periodicity. Good to see you are getting much feedback. Was curious what your team/25 operators have been hearing about the interworking of these mechanisms to other networks and the "theoretical" problem caused by the PWE "layer" disappearing when you do; and whether theye are concerned with interworking applications. And of course whatever your thoughts are on the subject. Thanks, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: Is PWE a layer? Date: Thu, 22 May 2003 19:44:42 -0400 Organization: Cisco Systems Lines: 65 Sender: pwe3-admin@ietf.org References: <20030522212151.71546.qmail@web13501.mail.yahoo.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Fri May 23 19:22:44 2003 Return-path: To: "'Mark Seery'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20030522212151.71546.qmail@web13501.mail.yahoo.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: Thursday, May 22, 2003 5:22 PM > To: tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: RE: Is PWE a layer? > > > Hi Tom, > > --- "Thomas D. Nadeau" wrote: > > This is more of an operational issue. > > My team and I have spoken to over 25 operators about > > VCCV and > > LSP Ping, and all 25 give me preciesely different > > answers about > > how often they want to run either tool. It depends > > largely on > > the application being used, as well as the SLA. > > Based on these > > data points, the VCCV draft does not specify any > > periodicity. > > Good to see you are getting much feedback. Was curious > what your team/25 operators have been hearing about > the interworking of these mechanisms to other networks > and the "theoretical" problem caused by the PWE > "layer" disappearing when you do; and whether theye > are concerned with interworking applications. Mark, We do have a real implementation of any-to-any PWE3, so yes our customers are interested in these issues. As with like-to-like, we are providing customers with LSP ping/VCCV/ICMP ping as well as other automated tools both now and very soon to solve the any-to-any case, which seems to satisfy the requirements we are getting. I won't get into more details here, but if you are interested more, contact me off-line. Regarding the theoretical "layer" disappearing and causing problems, I personally think it is a bit of a red herring that the layering purists are trying to use to obfuscate things. > And of course whatever your thoughts are on the > subject. I personally think that this issue needs to be addressed and spelled out clearly based on the requirements so that defect handling is well defined. If it is, then both devices and management systems can have a well-defined set of actions and assumptions about what to do when defects occur, and how to possibly handle them. --Tom > Thanks, > Mark > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Thu, 22 May 2003 19:23:53 -0400 Organization: Cisco Systems Lines: 155 Sender: pwe3-admin@ietf.org References: <3ECD2FE8.E2125B5C@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Busschbach, Peter B \(Peter\)'" , "'Shahram Davari'" , "'Yaakov Stein'" , "'Mark Seery'" , X-From: pwe3-admin@ietf.org Fri May 23 19:24:07 2003 Return-path: To: "'Mustapha Aissaoui'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3ECD2FE8.E2125B5C@alcatel.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Thursday, May 22, 2003 4:16 PM > To: tnadeau@cisco.com > Cc: 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov > Stein'; 'Mark Seery'; pwe3@ietf.org > Subject: Re: [PWE3] RE: Is PWE a layer? > > > Tom, > > "Thomas D. Nadeau" wrote: > > > > > -----Original Message----- > > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of > > > Mustapha Aissaoui > > > Sent: Wednesday, May 21, 2003 4:36 PM > > > To: Busschbach, Peter B (Peter) > > > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > > > Subject: Re: [PWE3] RE: Is PWE a layer? > > > > > > > > > Peter, > > > > > > "Busschbach, Peter B (Peter)" wrote: > > > > > > > > > -----Original Message----- > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Wednesday, May 21, 2003 2:43 PM > > > > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > > > > > Cc: pwe3@ietf.org > > > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > > > > > > > >a) TTL > 2 > > > > > >Eric Rosen made the point that there are cases in which it > > > > > >makes sense to splice PWs together and switch based on the PW > > > label. IMO, > > > > > >that turns the "PW layer" into an MPLS layer. (It makes > > > you wonder > > > > > >why there is a PW layer in the first place. Why not > > > define how to > > > > > >adapt client traffic to MPLS (i.e. remove the demultiplexing > > > > > >function from PWE) and leave it to the service provider > > > to decide > > > > > >whether there is a need for additional aggregation via > > > MPLS label > > > > > >stacking.) > > > > > > > > > > If PW labels could be switched like MPLS labels, then > why can't > > > > > MPLS-ping be used to test it? > > > > > > > > > > > > > Shahram, > > > > > > > > My statement should be read in the context of the question: > > > is PW an > > > > adaptation function or a network layer in itself. My point > > > was: if you > > > > use intermediate nodes to switch based on the PW Label, then it > > > > becomes a network layer in itself. > > > > > > > > Can one use Ping to test it? Yes, of course. Was there > > > anything in my > > > > mail that gave you the impression that I thought one couldn't? > > > > > > > > I still have a question about Ping, though. Is it the > > > intention that > > > > >Ping messages be sent periodically? The vccv draft doesn't > > > > >specify > > > > this. >IMO, for fault management you need a periodic > connectivity > > > > check and you >need to define how you determine that there is a > > > > defect. Is it when you >miss one reply or only after > > > missing multiple > > > > replies? Frankly, you need >a state machine as defined > in Y.1711. > > > > > > A Ping mechanism is similar to a connectivity verification > > > mechanism. This is not suited for alarm > indication/suppression. It > > > is intended to be mostly proactive and can have a significant > > > processing impact on the node for monitoring a large number of > > > entities. > > > > Not necessarily. The triggering of CV (whether > > VCCV, ICMP ping or LSP ping) can be automated on a device, and this > > can be done in such a way as to have minimal impact on the device's > > CPU. This same device can also be programmed to trigger or suppress > > alarms based on the status of such actions. > > Sure. Nontheless, a ping mechanism is a query mechanism. You > need to turn it on continously on LSPs in order to catch a > fault. That is only true if you are interested in catching faults just as they happen. > Fault detection should be automatic and OAM messages > are only generated at the detection of a fault for the > impacted LSPs only. And that is what you get using the existing tools depending on how you use them. > Though connectivity verification is important for detecting > discontinuity in the user plane which are not the result of a > physical layer fault or which are not detected through the > control plane. Connectivity verification is useful for several things, including what you point out. --Tom > > But arguing about this in theory is a waste of > > time. The proof is in the pudding, so check the > implementations that > > have implemented these tools and see how scalable they are. > > Good for you :-) > > >As usual, the market > > will decide which solutions are most appropriate. > > > > Let us consider again the scenario of ATM-MPLS-FR service > > > interworking, with local termination of ATM and FR at each PE. If > > > the ATM port in the ingress PE fails, you need to generate a > > > reactive alarm indication on all PWs which are sourced on > this port > > > to inform the remote PE of the defect. You need to be able to do > > > that without injecting connectivity verification traffic. A > > > lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is > > > more suitable. > > > > Since Y.1711 only works for MPLS > > as the PSN, this doesn't seem appropriate for PWE3 which > > must have solutions that work for both L2TPv3 and MPLS. > > BTW, VCCV works for both L2TPv3 and MPLS as of the next draft, and > > provides a consistent interface for operators regardless of the > > underlying PSN or VC type being tested. > > > > --Tom > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: PWE3 meeting in Vienna Date: Fri, 23 May 2003 18:17:48 +0100 Organization: Cisco Systems, Inc. Lines: 9 Sender: pwe3-admin@ietf.org References: <20030522212151.71546.qmail@web13501.mail.yahoo.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri May 23 19:33:20 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: pwe3@ietf.org Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I have agreed with Danny that I will pull together the agenda for the PWE3 session at IETF Vienna. Please can I have requests/suggestions for slots. Thanks Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Fri, 23 May 2003 13:10:57 -0400 Lines: 418 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3214E.2764C20A" Cc: "'Busschbach, Peter B (Peter)'" , "'Shahram Davari'" , "'Yaakov Stein'" , "'Mark Seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 19:37:56 2003 Return-path: To: "'Mustapha Aissaoui'" , tnadeau@cisco.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3214E.2764C20A Content-Type: text/plain; charset="iso-8859-1" Tom: As the previous VCCV draft used LDP as a negoitation/configuration mechanism, and either ICMP PING or LSP-PING as the test protocol, could you outline how this combination is applicable to L2TPv3? Or is VCCV a generic term that can have many instantiations? Dave > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Thursday, May 22, 2003 4:16 PM > To: tnadeau@cisco.com > Cc: 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov > Stein'; 'Mark Seery'; pwe3@ietf.org > Subject: Re: [PWE3] RE: Is PWE a layer? > > > Tom, > > "Thomas D. Nadeau" wrote: > > > > > -----Original Message----- > > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of > > > Mustapha Aissaoui > > > Sent: Wednesday, May 21, 2003 4:36 PM > > > To: Busschbach, Peter B (Peter) > > > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > > > Subject: Re: [PWE3] RE: Is PWE a layer? > > > > > > > > > Peter, > > > > > > "Busschbach, Peter B (Peter)" wrote: > > > > > > > > > -----Original Message----- > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Wednesday, May 21, 2003 2:43 PM > > > > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > > > > > Cc: pwe3@ietf.org > > > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > > > > > > > >a) TTL > 2 > > > > > >Eric Rosen made the point that there are cases in which it > > > > > >makes sense to splice PWs together and switch based on the PW > > > label. IMO, > > > > > >that turns the "PW layer" into an MPLS layer. (It makes > > > you wonder > > > > > >why there is a PW layer in the first place. Why not > > > define how to > > > > > >adapt client traffic to MPLS (i.e. remove the demultiplexing > > > > > >function from PWE) and leave it to the service provider > > > to decide > > > > > >whether there is a need for additional aggregation via > > > MPLS label > > > > > >stacking.) > > > > > > > > > > If PW labels could be switched like MPLS labels, then > why can't > > > > > MPLS-ping be used to test it? > > > > > > > > > > > > > Shahram, > > > > > > > > My statement should be read in the context of the question: > > > is PW an > > > > adaptation function or a network layer in itself. My point > > > was: if you > > > > use intermediate nodes to switch based on the PW Label, then it > > > > becomes a network layer in itself. > > > > > > > > Can one use Ping to test it? Yes, of course. Was there > > > anything in my > > > > mail that gave you the impression that I thought one couldn't? > > > > > > > > I still have a question about Ping, though. Is it the > > > intention that > > > > >Ping messages be sent periodically? The vccv draft doesn't > > > > >specify > > > > this. >IMO, for fault management you need a periodic > connectivity > > > > check and you >need to define how you determine that there is a > > > > defect. Is it when you >miss one reply or only after > > > missing multiple > > > > replies? Frankly, you need >a state machine as defined > in Y.1711. > > > > > > A Ping mechanism is similar to a connectivity verification > > > mechanism. This is not suited for alarm > indication/suppression. It > > > is intended to be mostly proactive and can have a significant > > > processing impact on the node for monitoring a large number of > > > entities. > > > > Not necessarily. The triggering of CV (whether > > VCCV, ICMP ping or LSP ping) can be automated on a device, and this > > can be done in such a way as to have minimal impact on the device's > > CPU. This same device can also be programmed to trigger or suppress > > alarms based on the status of such actions. > > Sure. Nontheless, a ping mechanism is a query mechanism. You > need to turn it on continously on LSPs in order to catch a > fault. Fault detection should be automatic and OAM messages > are only generated at the detection of a fault for the > impacted LSPs only. > > Though connectivity verification is important for detecting > discontinuity in the user plane which are not the result of a > physical layer fault or which are not detected through the > control plane. > > > But arguing about this in theory is a waste of > > time. The proof is in the pudding, so check the > implementations that > > have implemented these tools and see how scalable they are. > > Good for you :-) > > >As usual, the market > > will decide which solutions are most appropriate. > > > > Let us consider again the scenario of ATM-MPLS-FR service > > > interworking, with local termination of ATM and FR at each PE. If > > > the ATM port in the ingress PE fails, you need to generate a > > > reactive alarm indication on all PWs which are sourced on > this port > > > to inform the remote PE of the defect. You need to be able to do > > > that without injecting connectivity verification traffic. A > > > lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is > > > more suitable. > > > > Since Y.1711 only works for MPLS > > as the PSN, this doesn't seem appropriate for PWE3 which > > must have solutions that work for both L2TPv3 and MPLS. > > BTW, VCCV works for both L2TPv3 and MPLS as of the next draft, and > > provides a consistent interface for operators regardless of the > > underlying PSN or VC type being tested. > > > > --Tom > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C3214E.2764C20A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

Tom:

As the previous VCCV draft used LDP as a = negoitation/configuration mechanism, and either ICMP PING or LSP-PING = as the test protocol, could you outline how this combination is = applicable to L2TPv3? Or is VCCV a generic term that can have many = instantiations?

Dave

> -----Original Message-----
> From: Mustapha Aissaoui [mailto:mustapha.aissaoui@a= lcatel.com]
> Sent: Thursday, May 22, 2003 4:16 PM
> To: tnadeau@cisco.com
> Cc: 'Busschbach, Peter B (Peter)'; 'Shahram = Davari'; 'Yaakov
> Stein'; 'Mark Seery'; pwe3@ietf.org
> Subject: Re: [PWE3] RE: Is PWE a layer?
>
>
> Tom,
>
> "Thomas D. Nadeau" wrote:
> >
> > > -----Original Message-----
> > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On =
> Behalf Of
> > > Mustapha Aissaoui
> > > Sent: Wednesday, May 21, 2003 4:36 = PM
> > > To: Busschbach, Peter B = (Peter)
> > > Cc: 'Shahram Davari'; 'Yaakov Stein'; = Mark Seery; pwe3@ietf.org
> > > Subject: Re: [PWE3] RE: Is PWE a = layer?
> > >
> > >
> > > Peter,
> > >
> > > "Busschbach, Peter B = (Peter)" wrote:
> > > >
> > > > > -----Original = Message-----
> > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-= sierra.com]
> > > > > Sent: Wednesday, May 21, = 2003 2:43 PM
> > > > > To: 'Busschbach, Peter B = (Peter)'; 'Yaakov Stein'; Mark Seery
> > > > > Cc: pwe3@ietf.org
> > > > > Subject: RE: [PWE3] RE: Is = PWE a layer?
> > > > >
> > > > >
> > > > > >a) TTL > 2
> > > > > >Eric Rosen made the = point that there are cases in which it
> > > > > >makes sense to splice = PWs together and switch based on the PW
> > > label. IMO,
> > > > > >that turns the "PW = layer" into an MPLS layer. (It makes
> > > you wonder
> > > > > >why there is a PW layer = in the first place. Why not
> > > define how to
> > > > > >adapt client traffic to = MPLS (i.e. remove the demultiplexing
> > > > > >function from PWE) and = leave it to the service provider
> > > to decide
> > > > > >whether there is a need = for additional aggregation via
> > > MPLS label
> > > > > >stacking.)
> > > > >
> > > > > If PW labels could be = switched like MPLS labels, then
> why can't
> > > > > MPLS-ping be used to test = it?
> > > > >
> > > >
> > > > Shahram,
> > > >
> > > > My statement should be read in = the context of the question:
> > > is PW an
> > > > adaptation function or a network = layer in itself. My point
> > > was: if you
> > > > use intermediate nodes to switch = based on the PW Label, then it
> > > > becomes a network layer in = itself.
> > > >
> > > > Can one use Ping to test it? = Yes, of course. Was there
> > > anything in my
> > > > mail that gave you the = impression that I thought one couldn't?
> > > >
> > > > I still have a question about = Ping, though. Is it the
> > > intention that
> > > > >Ping messages be sent = periodically? The vccv draft doesn't
> > > > >specify
> > > > this. >IMO, for fault = management you need a periodic
> connectivity
> > > > check and you >need to define = how you determine that there is a
> > > > defect. Is it when you >miss = one reply or only after
> > > missing multiple
> > > > replies? Frankly, you need >a = state machine as defined
> in Y.1711.
> > >
> > > A Ping mechanism is similar to a = connectivity verification
> > > mechanism. This is not suited for = alarm
> indication/suppression. It
> > > is intended to be mostly proactive = and can have a significant
> > > processing impact on the node for = monitoring a large number of
> > > entities.
> >
> = >         Not necessarily. = The triggering of CV (whether
> > VCCV, ICMP ping or LSP ping) can be = automated on a device, and this
> > can be done in such a way as to have = minimal impact on the device's
> > CPU. This same device can also be = programmed to trigger or suppress
> > alarms based on the status of such = actions.
>
> Sure. Nontheless, a ping mechanism is a query = mechanism. You
> need to turn it on continously on LSPs in order = to catch a
> fault. Fault detection should be automatic and = OAM messages
> are only generated at the detection of a fault = for the
> impacted LSPs only.
>
> Though connectivity verification is important = for detecting
> discontinuity in the user plane which are not = the result of a
> physical layer fault or which are not detected = through the
> control plane.
> 
> = >         But arguing about = this in theory is a waste of
> > time. The proof is in the pudding, so = check the
> implementations that
> > have implemented these tools and see how = scalable they are.
>
> Good for you :-)
>
> >As usual, the market
> > will decide which solutions are most = appropriate.
>
> > > Let us consider again the scenario of = ATM-MPLS-FR service
> > > interworking, with local termination = of ATM and FR at each PE. If
> > > the ATM port in the ingress PE fails, = you need to generate a
> > > reactive alarm indication on all PWs = which are sourced on
> this port
> > > to inform the remote PE of the = defect. You need to be able to do
> > > that without injecting connectivity = verification traffic. A
> > > lightweight mechanism such as I.610 = AIS/RDI or Y.1711 FDI/BDI is
> > > more suitable.
> >
> = >         Since Y.1711 only = works for MPLS
> > as the PSN, this doesn't seem appropriate = for PWE3 which
> > must have solutions that work for both = L2TPv3 and MPLS.
> > BTW, VCCV works for both L2TPv3 and MPLS = as of the next draft, and
> > provides a consistent interface for = operators regardless of the
> > underlying PSN or VC type being = tested.
> >
> = >         --Tom
> >
> > > = _______________________________________________
> > > pwe3 mailing list
> > > pwe3@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/pwe3=
> > >
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C3214E.2764C20A-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: RE: Is PWE a layer? Date: Fri, 23 May 2003 18:20:56 +0100 Lines: 83 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 19:39:25 2003 Return-path: To: busschbach@lucent.com, tnadeau@cisco.com, Shahram_Davari@pmc-sierra.com, yaakov_s@rad.com, mark@mseery.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Something is awry with mail I think......however just to respond to Tom's point (though I await the orginal). I believe this is misinformation. I assume you (tom) were discussing LDP and specifically the rfc2547 application when you spoke to those 25 operators? You certainly were when you came to see us in BT. Further, we made it quite clear to you that when we consider X/MPLS we want Y.1711.....and I thought you understood that too. LSP-Ping is no answer here. regards, Neil > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: 22 May 2003 20:45 > To: 'tnadeau@cisco.com'; Busschbach, Peter B (Peter); > 'Shahram Davari'; > 'Yaakov Stein'; 'Mark Seery' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > [snipped] > > > > > I still have a question about Ping, though. Is it the > > > intention that Ping messages be sent periodically? The vccv > > > draft doesn't specify this. IMO, for fault management you > > > need a periodic connectivity check and you need to define how > > > you determine that there is a defect. Is it when you miss one > > > reply or only after missing multiple replies? > > > > This is more of an operational issue. > > My team and I have spoken to over 25 operators about VCCV and > > LSP Ping, and all 25 give me preciesely different answers about > > how often they want to run either tool. It depends largely on > > the application being used, as well as the SLA. Based on these > > data points, the VCCV draft does not specify any periodicity. > > > > > Frankly, you need a state machine as defined in Y.1711. > > > > This is contrary to the aforementioned customer > > input I have received. > > > > Tom, > > When you say "how often they want to run the tool", what is > the model?: > > a) the operator (or network management system) instructing > the PE to execute LSP Ping > > or, > > b) the PE autonomously generating LSP Ping messages. > > In case of b), is a failure on the PW translated to an alarm > indication in the client layer (e.g. ATM AIS/RDI)? > > Thanks, > > Peter > > > --Tom > > > > > > > > > Peter > > > > > > > -Shahram > > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: RE: Is PWE a layer? Date: Fri, 23 May 2003 11:13:29 +0100 Lines: 48 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: busschbach@lucent.com, Shahram_Davari@pmc-sierra.com, yaakov_s@rad.com, mark@mseery.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 19:53:44 2003 Return-path: To: mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Mustapha...please see below for an answer to your question. regards, Neil > > Neil, > thanks for the details. My main point in the message to Peter, and > you said that below too, was that the forward and backward defect > indication should be automatic and not be queried for. While > connectivity verification is a query mechanism. > > Also, see a question below. > > Mustapha. > ---------- > neil.2.harrison@bt.com wrote: > > [snipped] > > > L2 DEFECTS > > > > (i) In direction *towards* IWF: > > At IWF defects detected from CV flow (consequent actions > are dependent on > > type of defect). FDI generated immediately in other > partition and CV > > generation there suppressed. > > I am not sure I understand why the CV generation in the defect-free > partition should be suppressed. Since the ATM and MPLS (innel LSP) > are peer layers in this case, I would have thought that the CV in > the other partition should continue to operate since it checks only > that parition. NH=> The simple answer is that architecturally one should never allow both a valid CV (ie contains expected TTSI) and an FDI flow together on the same trail. Further, defect processing is only based on the CV (both entry and exit criteria) to decouple it from user traffic behaviour and to ensure consistent (and effectively simultaneous) recovery of nested trails after a failure is corrected (there are several subtle issues here wrt I.610 that I don't want to get into on mail....would take to long to explain. If you want to know more give me a call.). Y.1711 is about as sparse/powerful as you can get for a defect detection/handling solution in *any* co pkt-sw technology. It corrects all (or at least I tried as best I could) of the problems I discovered in I.610. Indeed, Y.1710 is effectively a statement of the requirements to force these corrections. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: RE: Is PWE a layer? Date: Fri, 23 May 2003 06:57:30 -0700 Lines: 15 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Yaakov Stein'" , "'Mark Seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 23 20:03:30 2003 Return-path: To: "'tnadeau@cisco.com'" , "'Mustapha Aissaoui'" , "'Busschbach, Peter B (Peter)'" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Since Y.1711 only works for MPLS >as the PSN, this doesn't seem appropriate for PWE3 which >must have solutions that work for both L2TPv3 and MPLS. >BTW, VCCV works for both L2TPv3 and MPLS as of the next >draft, and provides a consistent interface for operators >regardless of the underlying PSN or VC type being >tested. > > --Tom The only thing in Y.1711 that is MPLS specific is the identification of OAM packets. Everything else in Y.1711 applies to any co-pkt-sw network. Pretty much like VCCV in which you are reusing LSP-ping for any PSN type, but without explicit null label. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Mark Seery" Subject: RE: RE: Is PWE a layer? Date: Fri, 23 May 2003 20:52:45 -0700 Lines: 72 Sender: pwe3-admin@ietf.org References: <076601c320bc$21e8a0e0$6601a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Sat May 24 06:01:32 2003 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.2600.0000 In-Reply-To: <076601c320bc$21e8a0e0$6601a8c0@amer.cisco.com> Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, >> Tom: We do have a real implementation of any-to-any PWE3, so yes our customers are interested in these issues. As with like-to-like, we are providing customers with LSP ping/VCCV/ICMP ping as well as other automated tools both now and very soon to solve the any-to-any case, which seems to satisfy the requirements we are getting. I won't get into more details here, but if you are interested more, contact me off-line. << Will do, thanks for the offer, very interested in how it is going in the real world - certainly an important data point. >> Tom: Regarding the theoretical "layer" disappearing and causing problems, I personally think it is a bit of a red herring that the layering purists are trying to use to obfuscate things. << I assume you mean to have Y.1711 adopted, or some draft that encapsulates it? Certainly in a number of WGs we see strong advocation for various approaches, by the primary authors/promoters - and clearly the last year has seen strong disagreement and conflict over a number of OAM issues; so I can understand the frustration you express, especially in light of pressures we all feel to help our customers move forward with solutions/services and keep the industry moving. Hopefully the organization/system has a framework that encourages us all to rise above our personal interests and provide facilitation of our differences and move towards solutions which we can feel good about; alternatively, an organization that attempts to serve the needs of such a broad range of service providers is going to encourage this kind of tension, unless very special people (and there are precious few of them) are able to step in with broad competence and broker understanding and progress. So while we try to do this **incredibly** difficult thing of trying to create a common framework over both CO and CNLS networks, we will have to expect these kind of problems. FWIW, I do perceive a deep commitment to these layered principles of network architecture, a sense of investment from many years of developing and using these principles, and a real belief that they deliver important benefits. I have to admit to finding these principles one tool (I try not to use one data point to the exclusion of others), among a number, that is useful in thinking through certain issues. I will however concede that despite the fact that in theory CNLS networks comply to layered principles, these layered principles do seem to me, who probably does not understand them as well as I should, to be more intuitive to CO networks, which might be one of the problems we are finding in trying to create a common framework above both CO and CNLS networks. We also have to find ways to balance short-term vs long-term interests. We can not focus on the short-term to the exculsion of the long-term, and vice-versa we can not focus on the long-term to the exclusion of people's and organizations short-term success, careers, etc. I do feel that examining some of these layering issues might be one tool we can use to examine the impact on our long-term interests. I also understand it is challenging to be a leader and author as yourself, because it is always easier to criticize and modify, than to do the original creation. I think we need to evaluate whether the framework we are working under is inevitably going to create conflict, or whether we just need to work harder at finding a common ground. I often think people get in to personal conflict because of the environment they are working in, sometimes more than because of the individuals involved (it can go both ways of course). >> Tom: I personally think that this issue needs to be addressed and spelled out clearly based on the requirements so that defect handling is well defined. If it is, then both devices and management systems can have a well-defined set of actions and assumptions about what to do when defects occur, and how to possibly handle them. << That sounds more than reasonable to me. Best, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Tue, 27 May 2003 08:37:48 -0400 Organization: Cisco Systems Lines: 500 Sender: pwe3-admin@ietf.org References: <049AAFED91851244B9FF74D0D9D0EB720215262A@WHISTLER.WaveSmithNet.com> Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09A9_01C3242B.44956160" X-From: pwe3-admin@ietf.org Tue May 27 14:41:46 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB720215262A@WHISTLER.WaveSmithNet.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------=_NextPart_000_09A9_01C3242B.44956160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of = Himanshu Shah Sent: Thursday, May 22, 2003 11:48 AM To: David Allan; Mustapha Aissaoui; Busschbach, Peter B (Peter) Cc: Shahram Davari; Yaakov Stein; Mark Seery; pwe3@ietf.org Subject: RE: [PWE3] RE: Is PWE a layer? I think we are misunderstanding each other. =20 I am assuming that underlying tunnelling mechanisms is used to determine the status of the PW. Sort of like, if interface goes down, so does the DLCIs. If tunnel status is down, so are the PWs mapped on it. =20 If LDP is used as tunneling than it is possible that tunnel going down also translates to inability to signal PW status. But in this case, LDP session will go down too. However, in case of RSVP-TE, tunnel may take diff path than directed LDP session and tunnel going down does not translate to inability to signal PW status. =20 =20 BTW, I am not proposing that ping be triggered. All=20 I am saying is that I don't see a need to generate at some time intervals to verify the PW connection. It has scalability issues.=20 =20 As with any tool, when used incorrectly undesired=20 results will occur. If used wisely however, a tool such as LSP ping/VCCV can be quite effective AND scalable. =20 --Tom =20 =20 =20 =20 /himanshu =20 -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Thursday, May 22, 2003 11:16 AM To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B (Peter) Cc: Shahram Davari; Yaakov Stein; Mark Seery; pwe3@ietf.org Subject: RE: [PWE3] RE: Is PWE a layer? Hi, reply in line... I think you're confusing notification with verification. I think there = is agreement that notification of attachment circuit status is required and this is required for proper alarm suppression. I think there is general agreement that label withdrawl as a notification mechanism is not a good idea. However IMHO there are numerous mechanisms available ranging from service OAM (e.g. I.610 AIS), PW data plane and PW control plane.=20 [Himanshu>] I am wondering why notification is not adequate for verification.=20 =20 [Dave] I don't think we're talking the same language. I think of notification as informing peer systems of a problem, and verification as performing some type of probing action to detect a problem. Detection results in notification... > Another approach to connection verification=20 > is to have ingress PE notify egress PE about=20 > the status of the AC via PWE3 control signaling=20 > (in lieu of withdrawing VC label which is what=20 > the current approach is).=20 >=20 > The PWE3 status signaling can also be used by=20 > the head end PE to notify the status of his PW=20 > (in the event tunnel carrying the PW is=20 > inoperational).=20 This comment I did not understand. COuld you clarify the scenario you = are discussing.=20 [Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2 VC-LSPs make PW bidirectional. Each head end PE is responsible for notification of status changes of his AC and VC-LSP.=20 [Dave] My question is more how does the head end PE know the status of = his PW. A secondary issue would be that if there is a PW failure, there is a possiblity of control plane discontinuity as well.=20 =20 >=20 > I find low grade loopbacks such as ping or=20 > in line notification via some control bits in=20 > the control word, less appealing.=20 I'm curious as to your reasoning, as the net result of control plane notification frequently would be some type of dataplane action in the = far attachment circuit. [Himanshu>] I am referring to method of connection verification via notification only when the status changes. For example, if you are terminating FR AC, I believe you can respond to LMI status query locally without generating in line ping over PW. If the status changes (as = notified by PW3-control), receiving PE would generate LMI async status for the corresponding AC.=20 [DAVE] IMHO apriori distribution of e2e status is not verification. = Some mechanism is required to determine the status of each disjoint piece of technology before such status information is available for = distribution...I do agree that the information should be distributed rather than having = to be queried. I think the disconnect is that in your description above, you are = proposing an alternative to triggering a ping as a result of an LMI status query. = I would not so tightly couple the maintenance entities. If the PW is = broken, it should be known independent of the AC OAM mechanisms and the network = be able to distribute that information to the AC facing PEs. cheers Dave =20 ------=_NextPart_000_09A9_01C3242B.44956160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From:=20 pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of = Himanshu=20 Shah
Sent: Thursday, May 22, 2003 11:48 AM
To: = David=20 Allan; Mustapha Aissaoui; Busschbach, Peter B (Peter)
Cc: = Shahram=20 Davari; Yaakov Stein; Mark Seery; pwe3@ietf.org
Subject: RE: = [PWE3]=20 RE: Is PWE a layer?

I=20 think we are misunderstanding each other.
 
I am=20 assuming that underlying tunnelling
mechanisms is used to determine=20 the
status of the PW. Sort of like, if = interface=20 goes
down, so does the DLCIs. If tunnel status=20 is
down, so are the PWs mapped on=20 it.
 
If=20 LDP is used as tunneling than it is possible that
tunnel going down also translates to = inability=20 to
signal PW status. But in this case, LDP=20 session
will=20 go down too. However, in case of RSVP-TE,
tunnel may take diff path than directed LDP = session
and=20 tunnel going down does not translate to inability
to=20 signal PW status.
 
 
BTW,=20 I am not proposing that ping be triggered. All
I am=20 saying is that I don't see a need to generate at
some=20 time intervals to verify the PW connection. It
has scalability issues. 
 
    As with = any tool,=20 when used incorrectly undesired =
results will=20 occur. If used wisely however, a = tool=20 such
as LSP ping/VCCV can be = quite=20 effective AND=20 scalable.
 
   =20 --Tom
 
 
 
 
/himanshu
 
-----Original Message-----
From: David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Thursday, May 22, = 2003=20 11:16 AM
To: Himanshu Shah; Mustapha Aissaoui; Busschbach, = Peter B=20 (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery;=20 pwe3@ietf.org
Subject: RE: [PWE3] RE: Is PWE a=20 layer?

Hi, reply in line...
I think you're confusing notification with verification. = I think=20 there is agreement that notification of attachment circuit status = is=20 required and this is required for proper alarm suppression. I = think there=20 is general agreement that label withdrawl as a notification = mechanism is=20 not a good idea. However IMHO there are numerous mechanisms = available=20 ranging from service OAM (e.g. I.610 AIS), PW data plane and PW = control=20 plane.
[Himanshu>] I am wondering why = notification is not=20 adequate for verification. 
 
[Dave] I don't = think we're=20 talking the same language. I think of notification as informing peer = systems=20 of a problem, and verification as performing some type of = probing=20 action to detect a problem.  Detection results in=20 notification...

> Another approach to connection = verification=20
> is to have ingress PE notify = egress PE=20 about
> the status of the AC via = PWE3 control=20 signaling
> (in lieu of withdrawing = VC label=20 which is what
> the current = approach=20 is).
>
> The PWE3=20 status signaling can also be used by
> the=20 head end PE to notify the status of his PW
>=20 (in the event tunnel carrying the PW is
>=20 inoperational).

This comment I did not understand. COuld you = clarify the=20 scenario you are discussing.
[Himanshu>] I am refering to the status of the = unidirectional=20 VC-LSP. 2 VC-LSPs make PW bidirectional. Each head end PE is = responsible=20 for notification of status changes of his AC and VC-LSP. 

<= /BLOCKQUOTE>

[Dave] My question=20 is more how does the head end PE know the status of his PW. A = secondary=20 issue would be that if there is a PW failure, there is a = possiblity of=20 control plane discontinuity as=20 well. 

 

>
> I find low = grade=20 loopbacks such as ping or
> in line = notification via some control bits in
> the=20 control word, less appealing.

I'm curious as to your reasoning, as the net = result=20 of  control plane notification frequently would be some = type of=20 dataplane action in the far attachment circuit.
[Himanshu>]  I am = referring to=20 method of connection verification via notification only when the = status=20 changes. For example, if you are terminating = FR AC, I=20 believe you can respond to LMI status query locally without=20 generating in line ping over PW. If the status changes (as notified by = PW3-control), receiving PE would generate LMI async status for = the=20 corresponding AC. 

<= /BLOCKQUOTE>

[DAVE] = IMHO apriori=20 distribution of e2e status  is not verification. Some mechanism = is=20 required to determine the status of each disjoint piece of = technology before=20 such status information is available for distribution...I do agree = that the=20 information should be distributed rather than having to be=20 queried.

I think = the=20 disconnect is that in your description above, you are proposing an=20 alternative to triggering a ping as a result of an LMI status query. = I would=20 not so tightly couple the maintenance entities. If the PW is broken, = it=20 should be known independent of the AC OAM mechanisms and the network = be able=20 to distribute that information to the AC facing=20 PEs.

cheers

Dave

 

------=_NextPart_000_09A9_01C3242B.44956160-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Tue, 27 May 2003 08:42:35 -0400 Organization: Cisco Systems Lines: 154 Sender: pwe3-admin@ietf.org References: <3ECD2FE8.E2125B5C@alcatel.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue May 27 14:44:20 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3ECD2FE8.E2125B5C@alcatel.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mustapha Aissaoui > Sent: Thursday, May 22, 2003 4:16 PM > To: tnadeau@cisco.com > Cc: 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov > Stein'; 'Mark Seery'; pwe3@ietf.org > Subject: Re: [PWE3] RE: Is PWE a layer? > > > Tom, > > "Thomas D. Nadeau" wrote: > > > > > -----Original Message----- > > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of > > > Mustapha Aissaoui > > > Sent: Wednesday, May 21, 2003 4:36 PM > > > To: Busschbach, Peter B (Peter) > > > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > > > Subject: Re: [PWE3] RE: Is PWE a layer? > > > > > > > > > Peter, > > > > > > "Busschbach, Peter B (Peter)" wrote: > > > > > > > > > -----Original Message----- > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Wednesday, May 21, 2003 2:43 PM > > > > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > > > > > Cc: pwe3@ietf.org > > > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > > > > > > > >a) TTL > 2 > > > > > >Eric Rosen made the point that there are cases in which it > > > > > >makes sense to splice PWs together and switch based on the PW > > > label. IMO, > > > > > >that turns the "PW layer" into an MPLS layer. (It makes > > > you wonder > > > > > >why there is a PW layer in the first place. Why not > > > define how to > > > > > >adapt client traffic to MPLS (i.e. remove the demultiplexing > > > > > >function from PWE) and leave it to the service provider > > > to decide > > > > > >whether there is a need for additional aggregation via > > > MPLS label > > > > > >stacking.) > > > > > > > > > > If PW labels could be switched like MPLS labels, then > why can't > > > > > MPLS-ping be used to test it? > > > > > > > > > > > > > Shahram, > > > > > > > > My statement should be read in the context of the question: > > > is PW an > > > > adaptation function or a network layer in itself. My point > > > was: if you > > > > use intermediate nodes to switch based on the PW Label, then it > > > > becomes a network layer in itself. > > > > > > > > Can one use Ping to test it? Yes, of course. Was there > > > anything in my > > > > mail that gave you the impression that I thought one couldn't? > > > > > > > > I still have a question about Ping, though. Is it the > > > intention that > > > > >Ping messages be sent periodically? The vccv draft doesn't > > > > >specify > > > > this. >IMO, for fault management you need a periodic > connectivity > > > > check and you >need to define how you determine that there is a > > > > defect. Is it when you >miss one reply or only after > > > missing multiple > > > > replies? Frankly, you need >a state machine as defined > in Y.1711. > > > > > > A Ping mechanism is similar to a connectivity verification > > > mechanism. This is not suited for alarm > indication/suppression. It > > > is intended to be mostly proactive and can have a significant > > > processing impact on the node for monitoring a large number of > > > entities. > > > > Not necessarily. The triggering of CV (whether > > VCCV, ICMP ping or LSP ping) can be automated on a device, and this > > can be done in such a way as to have minimal impact on the device's > > CPU. This same device can also be programmed to trigger or suppress > > alarms based on the status of such actions. > > Sure. Nontheless, a ping mechanism is a query mechanism. You > need to turn it on continously on LSPs in order to catch a > fault. Fault detection should be automatic and OAM messages > are only generated at the detection of a fault for the > impacted LSPs only. Although I agree with you that a ping/CV mechanism must be configured to function, so does any other fault detection mechanism that would arrive at the same conclusion. --Tom > Though connectivity verification is important for detecting > discontinuity in the user plane which are not the result of a > physical layer fault or which are not detected through the > control plane. > > > But arguing about this in theory is a waste of > > time. The proof is in the pudding, so check the > implementations that > > have implemented these tools and see how scalable they are. > > Good for you :-) > > >As usual, the market > > will decide which solutions are most appropriate. > > > > Let us consider again the scenario of ATM-MPLS-FR service > > > interworking, with local termination of ATM and FR at each PE. If > > > the ATM port in the ingress PE fails, you need to generate a > > > reactive alarm indication on all PWs which are sourced on > this port > > > to inform the remote PE of the defect. You need to be able to do > > > that without injecting connectivity verification traffic. A > > > lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is > > > more suitable. > > > > Since Y.1711 only works for MPLS > > as the PSN, this doesn't seem appropriate for PWE3 which > > must have solutions that work for both L2TPv3 and MPLS. > > BTW, VCCV works for both L2TPv3 and MPLS as of the next draft, and > > provides a consistent interface for operators regardless of the > > underlying PSN or VC type being tested. > > > > --Tom > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Tue, 27 May 2003 08:43:53 -0400 Organization: Cisco Systems Lines: 507 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09B2_01C3242C.1C60C210" X-From: pwe3-admin@ietf.org Tue May 27 14:47:07 2003 Return-path: To: "'David Allan'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------=_NextPart_000_09B2_01C3242C.1C60C210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Friday, May 23, 2003 1:11 PM To: 'Mustapha Aissaoui'; tnadeau@cisco.com Cc: 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov Stein'; 'Mark Seery'; pwe3@ietf.org Subject: RE: [PWE3] RE: Is PWE a layer? Tom: As the previous VCCV draft used LDP as a negoitation/configuration mechanism, and either ICMP PING or LSP-PING as the test protocol, could you outline how this combination is applicable to L2TPv3? Or is VCCV a generic term that can have many instantiations? The next version of the VCCV draft will include full support for L2TPv3 and should be out this week. --Tom Dave > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Thursday, May 22, 2003 4:16 PM > To: tnadeau@cisco.com > Cc: 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov > Stein'; 'Mark Seery'; pwe3@ietf.org > Subject: Re: [PWE3] RE: Is PWE a layer? > > > Tom, > > "Thomas D. Nadeau" wrote: > > > > > -----Original Message----- > > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of > > > Mustapha Aissaoui > > > Sent: Wednesday, May 21, 2003 4:36 PM > > > To: Busschbach, Peter B (Peter) > > > Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; pwe3@ietf.org > > > Subject: Re: [PWE3] RE: Is PWE a layer? > > > > > > > > > Peter, > > > > > > "Busschbach, Peter B (Peter)" wrote: > > > > > > > > > -----Original Message----- > > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > > Sent: Wednesday, May 21, 2003 2:43 PM > > > > > To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery > > > > > Cc: pwe3@ietf.org > > > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > > > > > > > >a) TTL > 2 > > > > > >Eric Rosen made the point that there are cases in which it > > > > > >makes sense to splice PWs together and switch based on the PW > > > label. IMO, > > > > > >that turns the "PW layer" into an MPLS layer. (It makes > > > you wonder > > > > > >why there is a PW layer in the first place. Why not > > > define how to > > > > > >adapt client traffic to MPLS (i.e. remove the demultiplexing > > > > > >function from PWE) and leave it to the service provider > > > to decide > > > > > >whether there is a need for additional aggregation via > > > MPLS label > > > > > >stacking.) > > > > > > > > > > If PW labels could be switched like MPLS labels, then > why can't > > > > > MPLS-ping be used to test it? > > > > > > > > > > > > > Shahram, > > > > > > > > My statement should be read in the context of the question: > > > is PW an > > > > adaptation function or a network layer in itself. My point > > > was: if you > > > > use intermediate nodes to switch based on the PW Label, then it > > > > becomes a network layer in itself. > > > > > > > > Can one use Ping to test it? Yes, of course. Was there > > > anything in my > > > > mail that gave you the impression that I thought one couldn't? > > > > > > > > I still have a question about Ping, though. Is it the > > > intention that > > > > >Ping messages be sent periodically? The vccv draft doesn't > > > > >specify > > > > this. >IMO, for fault management you need a periodic > connectivity > > > > check and you >need to define how you determine that there is a > > > > defect. Is it when you >miss one reply or only after > > > missing multiple > > > > replies? Frankly, you need >a state machine as defined > in Y.1711. > > > > > > A Ping mechanism is similar to a connectivity verification > > > mechanism. This is not suited for alarm > indication/suppression. It > > > is intended to be mostly proactive and can have a significant > > > processing impact on the node for monitoring a large number of > > > entities. > > > > Not necessarily. The triggering of CV (whether > > VCCV, ICMP ping or LSP ping) can be automated on a device, and this > > can be done in such a way as to have minimal impact on the device's > > CPU. This same device can also be programmed to trigger or suppress > > alarms based on the status of such actions. > > Sure. Nontheless, a ping mechanism is a query mechanism. You > need to turn it on continously on LSPs in order to catch a > fault. Fault detection should be automatic and OAM messages > are only generated at the detection of a fault for the > impacted LSPs only. > > Though connectivity verification is important for detecting > discontinuity in the user plane which are not the result of a > physical layer fault or which are not detected through the > control plane. > > > But arguing about this in theory is a waste of > > time. The proof is in the pudding, so check the > implementations that > > have implemented these tools and see how scalable they are. > > Good for you :-) > > >As usual, the market > > will decide which solutions are most appropriate. > > > > Let us consider again the scenario of ATM-MPLS-FR service > > > interworking, with local termination of ATM and FR at each PE. If > > > the ATM port in the ingress PE fails, you need to generate a > > > reactive alarm indication on all PWs which are sourced on > this port > > > to inform the remote PE of the defect. You need to be able to do > > > that without injecting connectivity verification traffic. A > > > lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is > > > more suitable. > > > > Since Y.1711 only works for MPLS > > as the PSN, this doesn't seem appropriate for PWE3 which > > must have solutions that work for both L2TPv3 and MPLS. > > BTW, VCCV works for both L2TPv3 and MPLS as of the next draft, and > > provides a consistent interface for operators regardless of the > > underlying PSN or VC type being tested. > > > > --Tom > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------=_NextPart_000_09B2_01C3242C.1C60C210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: = David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Friday, May 23, = 2003 1:11=20 PM
To: 'Mustapha Aissaoui'; tnadeau@cisco.com
Cc:=20 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov Stein'; 'Mark = Seery';=20 pwe3@ietf.org
Subject: RE: [PWE3] RE: Is PWE a=20 layer?

Tom:

As the previous VCCV draft used LDP as a=20 negoitation/configuration mechanism, and either ICMP PING or LSP-PING = as the=20 test protocol, could you outline how this combination is applicable to = L2TPv3?=20 Or is VCCV a generic term that can have many instantiations? 

    = The next=20 version of the VCCV draft will include full support = for L2TPv3 and should be out = this=20 week.

   =20 --Tom

   =20

 

Dave

> -----Original Message-----
>=20 From: Mustapha Aissaoui [mailto:mustapha.aissaoui@al= catel.com]=20
> Sent: Thursday, May 22, 2003 4:16 = PM=20
> To: tnadeau@cisco.com
> Cc:=20 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov =
> Stein'; 'Mark Seery'; pwe3@ietf.org
>=20 Subject: Re: [PWE3] RE: Is PWE a layer?
> =
>
> = Tom,=20
>
> "Thomas D. = Nadeau"=20 wrote:
> >
> >=20 > -----Original Message-----
> > = > From:=20 pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On =
> Behalf Of
> > >=20 Mustapha Aissaoui
> > > Sent: = Wednesday, May=20 21, 2003 4:36 PM
> > > To: = Busschbach, Peter=20 B (Peter)
> > > Cc: 'Shahram = Davari'; 'Yaakov=20 Stein'; Mark Seery; pwe3@ietf.org
> > = >=20 Subject: Re: [PWE3] RE: Is PWE a layer?
> = >=20 >
> > >
> >=20 > Peter,
> > >
> > > "Busschbach, Peter B (Peter)" wrote: =
> > > >
> > > = > >=20 -----Original Message-----
> > > = > >=20 From: Shahram Davari [mailto:Shahram_Davari@pmc-s= ierra.com]=20
> > > > > Sent: Wednesday, May 21, = 2003 2:43=20 PM
> > > > > To: 'Busschbach, = Peter B=20 (Peter)'; 'Yaakov Stein'; Mark Seery
> = > >=20 > > Cc: pwe3@ietf.org
> > > = > >=20 Subject: RE: [PWE3] RE: Is PWE a layer?
> = > >=20 > >
> > > > > =
> > > > > >a) TTL > 2
>=20 > > > > >Eric Rosen made the point that there are cases = in=20 which it
> > > > > >makes = sense to=20 splice PWs together and switch based on the PW
>=20 > > label. IMO,
> > > > = >=20 >that turns the "PW layer" into an MPLS layer. (It makes =
> > > you wonder
> > = > >=20 > >why there is a PW layer in the first place. Why not =
> > > define how to
> = > >=20 > > >adapt client traffic to MPLS (i.e. remove the = demultiplexing=20
> > > > > >function from = PWE) and=20 leave it to the service provider
> > = > to=20 decide
> > > > > >whether = there is a=20 need for additional aggregation via
> = > >=20 MPLS label
> > > > >=20 >stacking.)
> > > > = >=20
> > > > > If PW labels could be = switched like=20 MPLS labels, then
> why can't =
> > > > > MPLS-ping be used to test it? =
> > > > >
> > = >=20 >
> > > > Shahram, =
> > > >
> > > = > My=20 statement should be read in the context of the question: =
> > > is PW an
> > = > >=20 adaptation function or a network layer in itself. My point =
> > > was: if you
> = > > >=20 use intermediate nodes to switch based on the PW Label, then it=20
> > > > becomes a network layer = in=20 itself.
> > > >
> > > > Can one use Ping to test it? Yes, of = course. Was=20 there
> > > anything in my =
> > > > mail that gave you the impression that I = thought=20 one couldn't?
> > > > =
> > > > I still have a question about Ping, = though. Is it=20 the
> > > intention that =
> > > > >Ping messages be sent periodically? = The vccv=20 draft doesn't
> > > > = >specify=20
> > > > this. >IMO, for fault = management you=20 need a periodic
> connectivity =
> > > > check and you >need to define how you = determine=20 that there is a
> > > > defect. = Is it when=20 you >miss one reply or only after
> = > >=20 missing multiple
> > > > = replies? Frankly,=20 you need >a state machine as defined
> = in=20 Y.1711.
> > >
>=20 > > A Ping mechanism is similar to a connectivity verification=20
> > > mechanism. This is not suited = for alarm=20
> indication/suppression. It =
> > > is intended to be mostly proactive and can = have a=20 significant
> > > processing impact = on the=20 node for monitoring a large number of
> = > >=20 entities.
> >
>=20 >         Not necessarily. = The=20 triggering of CV (whether
> > VCCV, = ICMP ping or=20 LSP ping) can be automated on a device, and this
>=20 > can be done in such a way as to have minimal impact on the = device's=20
> > CPU. This same device can also be = programmed=20 to trigger or suppress
> > alarms = based on the=20 status of such actions.
> =
> Sure. Nontheless, a ping mechanism is a query mechanism. = You=20
> need to turn it on continously on LSPs = in order=20 to catch a
> fault. Fault detection = should be=20 automatic and OAM messages
> are only = generated at=20 the detection of a fault for the
> = impacted LSPs=20 only.
>
> = Though=20 connectivity verification is important for detecting
> discontinuity in the user plane which are not the result = of a=20
> physical layer fault or which are not = detected=20 through the
> control plane. =
> 
>=20 >         But arguing about = this in=20 theory is a waste of
> > time. The = proof is in=20 the pudding, so check the
> = implementations that=20
> > have implemented these tools and = see how=20 scalable they are.
>
>=20 Good for you :-)
>
>=20 >As usual, the market
> > will = decide which=20 solutions are most appropriate.
> =
> > > Let us consider again the scenario of = ATM-MPLS-FR=20 service
> > > interworking, with = local=20 termination of ATM and FR at each PE. If
> >=20 > the ATM port in the ingress PE fails, you need to generate a=20
> > > reactive alarm indication on = all PWs=20 which are sourced on
> this port =
> > > to inform the remote PE of the defect. You = need to be=20 able to do
> > > that without = injecting=20 connectivity verification traffic. A
> = > >=20 lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is=20
> > > more suitable. =
> >
>=20 >         Since Y.1711 only = works=20 for MPLS
> > as the PSN, this doesn't = seem=20 appropriate for PWE3 which
> > must = have=20 solutions that work for both L2TPv3 and MPLS.
>=20 > BTW, VCCV works for both L2TPv3 and MPLS as of the next draft, = and=20
> > provides a consistent interface = for=20 operators regardless of the
> > = underlying PSN=20 or VC type being tested.
> > =
> >         = --Tom=20
> >
> > >=20 _______________________________________________
>=20 > > pwe3 mailing list
> > >=20 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 =
>

------=_NextPart_000_09B2_01C3242C.1C60C210-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: RE: Is PWE a layer? Date: Tue, 27 May 2003 09:47:42 -0400 Lines: 208 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32456.8BC36EEA" X-From: pwe3-admin@ietf.org Tue May 27 16:00:00 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: Is PWE a layer? Thread-Index: AcMkUaRkaGnCNIcYTFaZnXwtNy4iwwAA8vVQ To: , Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C32456.8BC36EEA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Himanshu>] On demand connection verification using LSP Ping/VCCV can indeed be very effective. However, I am skeptical on how continuous monitoring for fault=20 detection of few hundred thousands PWs by all PE peers using LSP Ping/VCCV could be scalable. =20 Perhaps you could address this issue in your next revision of VCCV draft. =20 regards, himanshu =20 ----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Tuesday, May 27, 2003 8:38 AM To: pwe3@ietf.org Subject: RE: [PWE3] RE: Is PWE a layer? =20 -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of = Himanshu Shah Sent: Thursday, May 22, 2003 11:48 AM To: David Allan; Mustapha Aissaoui; Busschbach, Peter B (Peter) Cc: Shahram Davari; Yaakov Stein; Mark Seery; pwe3@ietf.org Subject: RE: [PWE3] RE: Is PWE a layer? =20 BTW, I am not proposing that ping be triggered. All=20 I am saying is that I don't see a need to generate at some time intervals to verify the PW connection. It has scalability issues.=20 =20 As with any tool, when used incorrectly undesired=20 results will occur. If used wisely however, a tool such as LSP ping/VCCV can be quite effective AND scalable. =20 --Tom =20 =20 ------_=_NextPart_001_01C32456.8BC36EEA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

[Himanshu>] On demand connection verification=20 using
LSP Ping/VCCV can indeed be very effective.=20 However,
I am skeptical on how continuous monitoring = for fault=20
detection of few hundred thousands PWs by all PE = peers
using LSP Ping/VCCV could=20 be scalable.
 
Perhaps you could address this issue in your = next=20 revision of
VCCV draft.
 
regards,
himanshu
 
 ----Original=20 Message-----
From: Thomas=20 D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Tuesday, May 27, = 2003 8:38=20 AM
To: pwe3@ietf.org
Subject: RE: [PWE3] RE: Is PWE = a=20 layer?

 
-----Original Message-----
From:=20 pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of=20 Himanshu Shah
Sent: Thursday, May 22, 2003 11:48=20 AM
To: David Allan; Mustapha Aissaoui; Busschbach, Peter B = (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery;=20 pwe3@ietf.org
Subject: RE: [PWE3] RE: Is PWE a=20 layer?

<snip>
 
BTW, I am not proposing that ping be = triggered. All=20
I=20 am saying is that I don't see a need to generate = at
some time intervals to verify the PW = connection.=20 It
has scalability issues. 
 
   =20 As with any tool, when used incorrectly undesired=20
results will=20 occur. If used wisely however, a = tool=20 such
as = LSP=20 ping/VCCV can be quite=20 effective AND=20 scalable.
 
   =20 --Tom
 
 
------_=_NextPart_001_01C32456.8BC36EEA-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Tue, 27 May 2003 10:26:07 -0400 Lines: 355 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3245B.E963C1DE" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 27 16:36:17 2003 Return-path: To: "'Mark Seery'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3245B.E963C1DE Content-Type: text/plain; charset="iso-8859-1" Mark: > >> Tom: Regarding the theoretical "layer" disappearing and causing > >> problems, > I personally think it is a bit of a red herring that the > layering purists are trying to use to obfuscate things. << > > I assume you mean to have Y.1711 adopted, or some draft that > encapsulates it? Certainly in a number of WGs we see strong > advocation for various approaches, by the primary > authors/promoters - and clearly the last year has seen strong > disagreement and conflict over a number of OAM issues; so I > can understand the frustration you express, especially in > light of pressures we all feel to help our customers move > forward with solutions/services and keep the industry moving. > Hopefully the organization/system has a framework that > encourages us all to rise above our personal interests and > provide facilitation of our differences and move towards > solutions which we can feel good about; alternatively, an > organization that attempts to serve the needs of such a broad > range of service providers is going to encourage this kind of > tension, unless very special people (and there are precious > few of them) are able to step in with broad competence and > broker understanding and progress. So while we try to do this > **incredibly** difficult thing of trying to create a common > framework over both CO and CNLS networks, we will have to > expect these kind of problems. I trying to understand the fundamentals under your words above and the aspersions cast as to motivations of proponents of different solutions. Underlying this whole OAM discussion is a more fundamental tension as to whether OAM means functionality pushed into the network fabric, and designed as an operational system, or whether at least initial instantiations of this are a centralized bolt-on box that uses telnet etc. to periodically poke the network and direct boxes to ping specific resources. The network is a system, or the system is overlaid upon the network. I see this as an issue independent of personal agendas, or layering. Large carriers do have paranoia based upon experience with this technology. Some may claim that layering is a red herring, that's not the anecotal feedback I get from folks who've deployed 2547 networks. LDP and PWs do pose a challenge as we are overlaying CO networks on Connectionless behavior, and there are many issues with how one operationalizes this in a scalable fashion and harmonizes this with the service carried (which may have its own OAM, e.g. ATM I.610). IMHO insufficient thought has been given to the problem space whereby MPLS introduces path failures into what normally is a connectionless hop by hop network. Simply overlaying path testing and measurement is not necessarily a scalable answer, as if you tighten your criteria, it breaks quite promptly as you cannot rationalize both e2e testing and hop by hop testing without some centralized fault correlation function; the more you are testing simultaneously, the more indications of failure a centralzied system needs to process when somthing goes wrong. IMHO more functionality needs to be pushed into the network elements for this to scale (and appropriately filter fault indications) and has been noted this means specifying much more than has been done to date. Similarly there is a connection oriented dimension to MPLS that suffers a dearth of tools as most of the engergy has been focused on replicating IP. So I would tend to characterize the debate as between those interesting in doing their perception of the "right thing" where the criteria of "rightness" is not necessarily aligned ;-) cheers Dave > > FWIW, I do perceive a deep commitment to these layered > principles of network architecture, a sense of investment > from many years of developing and using these principles, and > a real belief that they deliver important benefits. I have to > admit to finding these principles one tool (I try not to use > one data point to the exclusion of others), among a number, > that is useful in thinking through certain issues. I will > however concede that despite the fact that in theory CNLS > networks comply to layered principles, these layered > principles do seem to me, who probably does not understand > them as well as I should, to be more intuitive to CO > networks, which might be one of the problems we are finding > in trying to create a common framework above both CO and CNLS > networks. > > We also have to find ways to balance short-term vs long-term > interests. We can not focus on the short-term to the > exculsion of the long-term, and vice-versa we can not focus > on the long-term to the exclusion of people's and > organizations short-term success, careers, etc. I do feel > that examining some of these layering issues might be one > tool we can use to examine the impact on our long-term interests. > > I also understand it is challenging to be a leader and author > as yourself, because it is always easier to criticize and > modify, than to do the original creation. > > I think we need to evaluate whether the framework we are > working under is inevitably going to create conflict, or > whether we just need to work harder at finding a common > ground. I often think people get in to personal conflict > because of the environment they are working in, sometimes > more than because of the individuals involved (it can go both > ways of course). > > >> Tom: I personally think that this issue needs to be addressed and > >> spelled > out clearly based on the requirements so that defect handling > is well defined. If it is, then both devices and management > systems can have a well-defined set of actions and > assumptions about what to do when defects occur, and how to > possibly handle them. << > > That sounds more than reasonable to me. > > Best, > Mark > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C3245B.E963C1DE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

Mark:


> >> Tom: Regarding the theoretical = "layer" disappearing and causing
> >> problems,
> I personally think it is a bit of a red herring = that the
> layering purists are trying to use to obfuscate = things. <<
>
> I assume you mean to have Y.1711 adopted, or = some draft that
> encapsulates it? Certainly in a number of WGs = we see strong
> advocation for various approaches, by the = primary
> authors/promoters - and clearly the last year = has seen strong
> disagreement and conflict over a number of OAM = issues; so I
> can understand the frustration you express, = especially in
> light of pressures we all feel to help our = customers move
> forward with solutions/services and keep the = industry moving.
> Hopefully the organization/system has a = framework that
> encourages us all to rise above our personal = interests and
> provide facilitation of our differences and = move towards
> solutions which we can feel good about; = alternatively, an
> organization that attempts to serve the needs = of such a broad
> range of service providers is going to = encourage this kind of
> tension, unless very special people (and there = are precious
> few of them) are able to step in with broad = competence and
> broker understanding and progress. So while we = try to do this
> **incredibly** difficult thing of trying to = create a common
> framework over both CO and CNLS networks, we = will have to
> expect these kind of problems.

I trying to understand the fundamentals under your = words above and the aspersions cast as to motivations of proponents of = different solutions.

Underlying this whole OAM discussion is a more = fundamental tension as to whether OAM means functionality pushed into = the network fabric, and designed as an operational system, or whether = at least initial instantiations of this are a centralized bolt-on box = that uses telnet etc. to periodically poke the network and direct boxes = to ping specific resources. The network is a system, or the system is = overlaid upon the network.

I see this as an issue independent of personal = agendas, or layering. Large carriers do have paranoia based upon = experience with this technology. Some may claim that layering is a red = herring, that's not the anecotal feedback I get from folks who've = deployed 2547 networks.

LDP and PWs do pose a challenge as we are overlaying = CO networks on Connectionless behavior, and there are many issues with = how one operationalizes this in a scalable fashion and harmonizes this = with the service carried (which may have its own OAM, e.g. ATM I.610). = IMHO insufficient thought has been given to the problem space whereby = MPLS introduces path failures into what normally is a connectionless = hop by hop network.

Simply overlaying path testing and measurement is not = necessarily a scalable answer, as if you tighten your criteria, it = breaks quite promptly as you cannot rationalize both e2e testing and = hop by hop testing without some centralized fault correlation function; = the more you are testing simultaneously, the more indications of = failure a centralzied system needs to process when somthing goes wrong. = IMHO more functionality needs to be pushed into the network elements = for this to scale (and appropriately filter fault indications) and has = been noted this means specifying much more than has been done to date. = Similarly there is a connection oriented dimension to MPLS that suffers = a dearth of tools as most of the engergy has been focused on = replicating IP.

So I would tend to characterize the debate as between = those interesting in doing their perception of the "right = thing" where the criteria of "rightness" is not = necessarily aligned ;-)

cheers
Dave

 



>
> FWIW, I do perceive a deep commitment to these = layered
> principles of network architecture, a sense of = investment
> from many years of developing and using these = principles, and
> a real belief that they deliver important = benefits. I have to
> admit to finding these principles one tool (I = try not to use
> one data point to the exclusion of others), = among a number,
> that is useful in thinking through certain = issues. I will
> however concede that despite the fact that in = theory CNLS
> networks comply to layered principles, these = layered
> principles do seem to me, who probably does not = understand
> them as well as I should, to be more intuitive = to CO
> networks, which might be one of the problems we = are finding
> in trying to create a common framework above = both CO and CNLS
> networks.
>
> We also have to find ways to balance short-term = vs long-term
> interests. We can not focus on the short-term = to the
> exculsion of the long-term, and vice-versa we = can not focus
> on the long-term to the exclusion of people's = and
> organizations short-term success, careers, etc. = I do feel
> that examining some of these layering issues = might be one
> tool we can use to examine the impact on our = long-term interests.
>
> I also understand it is challenging to be a = leader and author
> as yourself, because it is always easier to = criticize and
> modify, than to do the original = creation.
>
> I think we need to evaluate whether the = framework we are
> working under is inevitably going to create = conflict, or
> whether we just need to work harder at finding = a common
> ground. I often think people get in to personal = conflict
> because of the environment they are working in, = sometimes
> more than because of the individuals involved = (it can go both
> ways of course).
>
> >> Tom: I personally think that this = issue needs to be addressed and
> >> spelled
> out clearly based on the requirements so that = defect handling
> is well defined. If it is, then both devices = and management
> systems can have a well-defined set of actions = and
> assumptions about what to do when defects = occur, and how to
> possibly handle them. <<
>
> That sounds more than reasonable to me.
>
> Best,
> Mark
>
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C3245B.E963C1DE-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: RE: Is PWE a layer? Date: Tue, 27 May 2003 11:43:02 -0700 (PDT) Lines: 136 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 27 20:56:24 2003 Return-path: To: David Allan In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Thanks Dave. Enjoyed reading your response. Comments below, Mark >> Dave: Underlying this whole OAM discussion is a more fundamental tension as to whether OAM means functionality pushed into the network fabric, and designed as an operational system, or whether at least initial instantiations of this are a centralized bolt-on box that uses telnet etc. to periodically poke the network and direct boxes to ping specific resources. The network is a system, or the system is overlaid upon the network. << If I am understanding what you are saying, then this raises the following questions (in my mind): 1) If I am a service provider that wants to offer a best effort, low operations overhead service, that philisophically believes in "lazy error checking", should I have to pay the burden of this capability being incorporated into the network? 2) If I am a service provider that has a great deal of installed equipment and I want to test market a service, or see it as not ever being very large, should I have to replace all my equipment to provide that service? 3) What role does a centralized bolt-on solution provide in the standards process. For example, if by such stroke of luck we were to reach consensus about the long-term requirements for OAM, would we forgo standardization of an approach that allows service providers to leverage their existing assets? 4) I assume the implied suggestion is that any centralized push/polling mechanism is not scalable, so it can not be the long-term solution? In other words, the method of invocation is kind of orthogonal as long as the OAM function is doing what it needs to do; the only remaining issue is whether the method of innvocation has some fundamental flaws. >> Dave: I see this as an issue independent of personal agendas, or layering. << If I understood you correctly, then yes I agree. >> Large carriers do have paranoia based upon experience with this technology. Some may claim that layering is a red herring, that's not the anecotal feedback I get from folks who've deployed 2547 networks. << Could you be more explicit about the feedback you are receiving. Is it related to the use of central management tools? >> LDP and PWs do pose a challenge as we are overlaying CO networks on Connectionless behavior, and there are many issues with how one operationalizes this in a scalable fashion and harmonizes this with the service carried (which may have its own OAM, e.g. ATM I.610). IMHO insufficient thought has been given to the problem space whereby MPLS introduces path failures into what normally is a connectionless hop by hop network. << I have now come to the conclusion, that you obviously did some time ago, that LDP-MPLS (I think we should get in the habit of being specific and not just saying MPLS) uses hop-by-hop identifiers in the user plane, but those identifiers do not represent connections (and hence do not require connection state within the transit nodes) they represent FECs. So at this point, I would have to say I am trending towards the position that LDP-MPLS is a CNLS network, with the complication of having CO fault modes introduced through incorrect label swapping. To this then I would respond, is it any more likely that LDP-MPLS would create incorrect label swapping, than in any other CO network? I think the answer is no. And I state this only in a hope that we can reach some level of consensus before continuing the logic tree. So even though the answer is no, it is as you say a problem that other CNLS networks do not have to deal with, and therefore a problem to which a solution is required. I can envision two possible solutions: 1) a P2P overlay 2) OAM messages that have the source address embedded in them (this would need to be an interface/sub-interface address as opposed to a LSR identifier is my guess). To me, option 2) is preferable - what is wrong with this approach? >> Simply overlaying path testing and measurement is not necessarily a scalable answer, as if you tighten your criteria, it breaks quite promptly as you cannot rationalize both e2e testing and hop by hop testing without some centralized fault correlation function; the more you are testing simultaneously, the more indications of failure a centralzied system needs to process when somthing goes wrong. IMHO more functionality needs to be pushed into the network elements for this to scale (and appropriately filter fault indications) and has been noted this means specifying much more than has been done to date. Similarly there is a connection oriented dimension to MPLS that suffers a dearth of tools as most of the engergy has been focused on replicating IP. << On the CO dimension of MPLS, it strikes me that there is no RSVP-TE solution for PWE - is this correct and should this be so? On the issue of fault correlation, as this is inherently a multi-layer problem, can this be solved within the standards process for one layer. i.e. what can be done without looking at the top to bottom solution? >> So I would tend to characterize the debate as between those interesting in doing their perception of the "right thing" where the criteria of "rightness" is not necessarily aligned ;-) << So then you agree that both parties have good intentions to do the right thing ;-) Then it is just a matter of people of good will....... ;-) Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Tue, 27 May 2003 16:23:47 -0400 Lines: 479 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3248D.E0B8EC30" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue May 27 22:32:30 2003 Return-path: To: "'Mark Seery'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3248D.E0B8EC30 Content-Type: text/plain; charset="iso-8859-1" Hi Mark: > Enjoyed reading your response. Good...;-), replies in line > > If I am understanding what you are saying, then this > raises the following questions (in my mind): > > 1) If I am a service provider that wants to offer a > best effort, low operations overhead service, that > philisophically believes in "lazy error checking", should I > have to pay the burden of this capability being incorporated > into the network? The "burden" you refer to is a function of commoditization (and the corresponding "ease of commoditization"). The good news about Moore's law is that relative to the cost of other components (optics, lasers etc.), adding packet processing capability drops in relative cost quite quickly. If you believe that any solution in this space will migrate to some form of H/W assist, the cost will be built into your gear at some point whether you use it or not and compared to the overall complexity of the system, will only be a small component. > 2) If I am a service provider that has a great deal of > installed equipment and I want to test market a service, or > see it as not ever being very large, should I have to replace > all my equipment to provide that service? You state this like deploying a PW service is the only motivation for OAM and deploying OAM requires a network wide fork lift. > 3) What role does a centralized bolt-on solution > provide in the standards process. For example, if by > such stroke of luck we were to reach consensus about > the long-term requirements for OAM, would we forgo > standardization of an approach that allows service providers > to leverage their existing assets? Orthogonal question IMO. As an extension of a craftsperson CLI interface, we'd do it anyway. > 4) I assume the implied suggestion is that any > centralized push/polling mechanism is not scalable, so > it can not be the long-term solution? In other words, > the method of invocation is kind of orthogonal as long > as the OAM function is doing what it needs to do; the > only remaining issue is whether the method of > innvocation has some fundamental flaws. Not as much the method of invocation, it is a combination of attributes: how determinitic testing is, whether a fault will turn up in multiple diverse places and how that is correlated such that the most frugal response is possible, can responding be delegated into the network etc.etc. > >> Dave: I see this as an issue independent of > personal agendas, or layering. << > > If I understood you correctly, then yes I agree. > > >> Large carriers do have paranoia based upon > experience with this technology. Some may claim that > layering is a red herring, that's not the anecotal > feedback I get from folks who've deployed 2547 > networks. << > > Could you be more explicit about the feedback you are > receiving. Is it related to the use of central management tools? The feedback is a mix depending on where the carrier is using MPLS now and the experience they've had, and how they envision using it in the future. > > > I have now come to the conclusion, that you obviously > did some time ago, that LDP-MPLS (I think we should > get in the habit of being specific and not just saying > MPLS) uses hop-by-hop identifiers in the user plane, > but those identifiers do not represent connections > (and hence do not require connection state within the > transit nodes) they represent FECs. So at this point, > I would have to say I am trending towards the position > that LDP-MPLS is a CNLS network, with the complication > of having CO fault modes introduced through incorrect > label swapping. To this then I would respond, is it > any more likely that LDP-MPLS would create incorrect > label swapping, than in any other CO network? > > I think the answer is no. And I state this only in a > hope that we can reach some level of consensus before > continuing the logic tree. Some potential counterpoints are: 1) lots more code driving the label swapping configuration and with higher frequency. As a counterpoint, in an ATM PVC network, the cross connect table is only touched when there is a provisioning change. Even in an SVC network, a routing change frequently may not change the forwarding state of the switch. 2) MPLS has a label stack, so there is an extra dimension to things that can go wrong. 3) MPLS originally assumed it would exist in a hybrid IP network, and packets coming up for air at arbitrary plances in the middle was "OK", so failure to configure LDP on a link or using independent label distribution mode etc. was only a minor inconvenience rather than service disrupting. As far as LDP is concerned, the only question in my mind is what is an appropriate response to the additional modes of failure when considering the potential frequency. Throw in the label stack as well and what you need is somthing ubiquitous as the problem may not occur uniquely in the LDP layer. > So even though the answer is no, it is as you say a > problem that other CNLS networks do not have to deal > with, and therefore a problem to which a solution is > required. I can envision two possible solutions: 1) a > P2P overlay 2) OAM messages that have the source > address embedded in them (this would need to be an > interface/sub-interface address as opposed to a LSR > identifier is my guess). To me, option 2) is preferable - > what is wrong with this approach? A p2p overlay is a solution, but if used in isolation, you have the problem that an LDP problem spills a lot of overlay p2p LSPs, therefore who owns the problem. IMHO the LDP layer needs a bit of help in this regard. As for '2', an access point ID is the basis of the villified TTSI in Y.1711. It is straightforward for p2p but requires the egress to track many access points for mp2p. For mp2p we're working on y.17fec-cv (SG13) where the FEC info is encoded in the probe and that is what is checked. > > > On the CO dimension of MPLS, it strikes me that there > is no RSVP-TE solution for PWE - is this correct and > should this be so? Technically an RSVP-TE LSP could carry a PW directly (it does have a PID exchanged in one of the objects) and not as an LDP overlay. So I'm unaware of anything that precludes this option. > > On the issue of fault correlation, as this is > inherently a multi-layer problem, can this be solved > within the standards process for one layer. i.e. what > can be done without looking at the top to bottom > solution? You phrase the problem strangely. Each layer is required to communicate knowledge of the fault to the NE that has knowledge of the impacted clients (usually means the egress LSR for a given layer). Meeting that requirement will naturally telescope upwards. The wrinkle is when a layer implements local resilience to the fault and the node detecting the fault has no knowledge of the workaround (it doesn't know when to stop or withdraw the notification). It also throws a curve if the MTTR of a layer is slower that the detection time of a client, now we're into hold off timers etc. > >> So I would tend to characterize the debate as > between those interesting in doing their perception of > the "right thing" where the criteria of "rightness" is > not necessarily aligned ;-) << > > So then you agree that both parties have good > intentions to do the right thing ;-) Then it is just a > matter of people of good will....... ;-) There's a few subtleties still to be addressed ;-) rgds Dave ------_=_NextPart_001_01C3248D.E0B8EC30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

Hi Mark:

> Enjoyed reading your response.

Good...;-), replies in line

<snipped>
>
> If I am understanding what you are saying, then = this
> raises the following questions (in my = mind):
>
> 1) If I am a service provider that wants to = offer a
> best effort, low operations overhead service, = that
> philisophically believes in "lazy error = checking", should I
> have to pay the burden of this capability being = incorporated
> into the network?

The "burden" you refer to is a function of = commoditization (and the corresponding "ease of = commoditization"). The good news about Moore's law is that = relative to the cost of other components (optics, lasers etc.), adding = packet processing capability drops in relative cost quite quickly. If = you believe that any solution in this space will migrate to some form = of H/W assist, the cost will be built into your gear at some point = whether you use it or not and compared to the overall complexity of the = system, will only be a small component.

> 2) If I am a service provider that has a great = deal of
> installed equipment and I want to test market a = service, or
> see it as not ever being very large, should I = have to replace
> all my equipment to provide that = service?

You state this like deploying a PW service is the = only motivation for OAM and deploying OAM requires a network wide fork = lift.

 
> 3) What role does a centralized bolt-on = solution
> provide in the standards process. For example, = if by
> such stroke of luck we were to reach consensus = about
> the long-term requirements for OAM, would we = forgo
> standardization of an approach that allows = service providers
> to leverage their existing assets?

Orthogonal question IMO. As an extension of a = craftsperson CLI interface, we'd do it anyway.

> 4) I assume the implied suggestion is that = any
> centralized push/polling mechanism is not = scalable, so
> it can not be the long-term solution? In other = words,
> the method of invocation is kind of orthogonal = as long
> as the OAM function is doing what it needs to = do; the
> only remaining issue is whether the method = of
> innvocation has some fundamental flaws.

Not as much the method of invocation, it is a = combination of attributes: how determinitic testing is, whether a fault = will turn up in multiple diverse places and how that is correlated such = that the most frugal response is possible, can responding be delegated = into the network etc.etc.

 
> >> Dave: I see this as an issue = independent of
> personal agendas, or layering. <<
>
> If I understood you correctly, then yes I = agree.
>
> >> Large carriers do have paranoia based = upon
> experience with this technology. Some may claim = that
> layering is a red herring, that's not the = anecotal
> feedback I get from folks who've deployed = 2547
> networks. <<
>
> Could you be more explicit about the feedback = you are
> receiving. Is it related to the use of central = management tools?

The feedback is a mix depending on where the carrier = is using MPLS now and the experience they've had, and how they envision = using it in the future.

>
<snipped>
>
> I have now come to the conclusion, that you = obviously
> did some time ago, that LDP-MPLS (I think we = should
> get in the habit of being specific and not just = saying
> MPLS) uses hop-by-hop identifiers in the user = plane,
> but those identifiers do not represent = connections
> (and hence do not require connection state = within the
> transit nodes) they represent FECs. So at this = point,
> I would have to say I am trending towards the = position
> that LDP-MPLS is a CNLS network, with the = complication
> of having CO fault modes introduced through = incorrect
> label swapping. To this then I would respond, = is it
> any more likely that LDP-MPLS would create = incorrect
> label swapping, than in any other CO network? =
>
> I think the answer is no. And I state this only = in a
> hope that we can reach some level of consensus = before
> continuing the logic tree.

Some potential counterpoints are:

1) lots more code driving the label swapping = configuration and with higher frequency. As a counterpoint, in an ATM = PVC network, the cross connect table is only touched when there is a = provisioning change. Even in an SVC network, a routing change = frequently may not change the forwarding state of the = switch.

2) MPLS has a label stack, so there is an extra = dimension to things that can go wrong.

3) MPLS originally assumed it would exist in a hybrid = IP network, and packets coming up for air at arbitrary plances in the = middle was "OK", so failure to configure LDP on a link or = using independent label distribution mode etc. was only a minor = inconvenience rather than service disrupting.

As far as LDP is concerned, the only question in my = mind is what is an appropriate response to the additional modes of = failure when considering the potential frequency. Throw in the label = stack as well and what you need is somthing ubiquitous as the problem = may not occur uniquely in the LDP layer.

> So even though the answer is no, it is as you = say a
> problem that other CNLS networks do not have to = deal
> with, and therefore a problem to which a = solution is
> required. I can envision two possible = solutions: 1) a
> P2P overlay 2) OAM messages that have the = source
> address embedded in them (this would need to be = an
> interface/sub-interface address as opposed to a = LSR
> identifier is my guess). To me, option 2) is = preferable -
> what is wrong with this approach?

A p2p overlay is a solution, but if used in = isolation, you have the problem that an LDP problem spills a lot of = overlay p2p LSPs, therefore who owns the problem. IMHO the LDP layer = needs a bit of help in this regard.

As for '2', an access point ID is the basis of the = villified TTSI in Y.1711. It is straightforward for p2p but requires = the egress to track many access points for mp2p. For mp2p we're working = on y.17fec-cv (SG13) where the FEC info is encoded in the probe and = that is what is checked.

>
<snipped>
>
> On the CO dimension of MPLS, it strikes me that = there
> is no RSVP-TE solution for PWE - is this = correct and
> should this be so?

Technically an RSVP-TE LSP could carry a PW directly = (it does have a PID exchanged in one of the objects) and not as an LDP = overlay. So I'm unaware of anything that precludes this = option.

>
> On the issue of fault correlation, as this = is
> inherently a multi-layer problem, can this be = solved
> within the standards process for one layer. = i.e. what
> can be done without looking at the top to = bottom
> solution?

You phrase the problem strangely. Each layer is = required to communicate knowledge of the fault to the NE that has = knowledge of the impacted clients (usually means the egress LSR for a = given layer). Meeting that requirement will naturally telescope = upwards.

The wrinkle is when a layer implements local = resilience to the fault and the node detecting the fault has no = knowledge of the workaround (it doesn't know when to stop or withdraw = the notification). It also throws a curve if the MTTR of a layer is = slower that the detection time of a client, now we're into hold off = timers etc.

> >> So I would tend to characterize the = debate as
> between those interesting in doing their = perception of
> the "right thing" where the criteria = of "rightness" is
> not necessarily aligned ;-) <<
>
> So then you agree that both parties have = good
> intentions to do the right thing ;-) Then it is = just a
> matter of people of good will....... ;-)

There's a few subtleties still to be addressed = ;-)

rgds
Dave

------_=_NextPart_001_01C3248D.E0B8EC30-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: RE: Is PWE a layer? Date: Tue, 27 May 2003 19:00:22 -0700 (PDT) Lines: 327 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed May 28 04:01:39 2003 Return-path: To: David Allan In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Dave, The first batch of questions in my previous response was to try and flush out the fact that this effort is trying to meet the needs of a wide range of service providers with different mindsets and business models; including stand-alone ISPs, ISPs within a carrier, carriers upgrading ATM networks to MPLS, carriers building new MPLS networks for Ethernet, etc. >From this flows two distinct categories of conflict: 1) What can be implemented in existing equipment 2) The operations culture variance among different SPs Quoting from draft-allan-y1711-and-lsp-ping: "LSP-PING is designed to be retrofitted to existing deployed networks....." "Y.1711 depends on some degree of ubiquitous deployment at the edge to maximize coverage of fault detection" These two comments alone lead to various substantial inferences: 1) That LSP-PING can be used with existing installed equipment and that other approaches may not be optimized for that purpose and b) substantial benefits may only accrue via Y.1711 if there is ubiquity of deployment. So perhaps my previous comments were badly worded if they implied that the entire network needs to be replaced, but clearly there is an existing assets issue here. The accomodation of existing equipment and network evolution is not without precedent, as an example I would cite the DSL Forum's working text 81 (WT81) which proposes significant capability increase to the network, but clearly accomodates the presence of existing DSLAMs by the creation of a new gateway function. With respect to your comment that this functionality is easily assumed into silicon, I'd like to first make the flipant remark that a few gates here, and a few gates there, and all of a sudden we are talking serious silicon; or rather if you take one approach as a whole and compare it to another approach as a whole, on aggregate there may be significant differences. I would also observe that packet processing remains bit for bit significantly more expensive (in terms of power at least) than TDM processing, so the packet processing industry's goal as a whole should be further reduction, and that additional processing should be examined skeptically. This may be the wrong place to cut back on, but there should be a general intent to cut back on processing, (including the unnecessary adding of new layers - I am not one sided on this issue), where possible, and therefore we should not assume that adding functionality to silicon has no impact, we should justify the addition. Specifically, say my PE supports 10,000 LSPs. Now the design has to allow for the possibility of 10,000 OAMs per second (depending on the network architecture, many of them may be on the same interface). Each of these OAMs requires a BIP calculation (simple logic to be sure) in addition to what ever OAM processing is required. The OAMs might be occurring on multiple stack levels (3 or more) concurrently - so how is this impacting my pipeline? Now say there is a fault. In the midst of a network error I am now creating additional processing in the form of FDI flows at 1/sec. (perhaps even BDI, but most LSPs are unidirectional....). So at the worst time, during a fault, I am throwing even more processing in to the user plane - a tractable issue (but actually an interesting debate is to be had here about avoiding non-linearality - yes I know, alarm storms could create another type), but has to be allowed for in the design. I do not say this to criticize Y.1711, I think it is essential functionality for a certain type of carrier, seeking to achieve certain goals - my only point is that it is not clear cut to me that the addition of OAM (especially for a multi-level stack of indefinite depth) is painless and with out need for tradeoffs in the packet processing pipeline (you can do what early ATM implementations did and shunt everything off to an adjunct processor, but that has its own costs and complications). What would be really useful is to actually have a digital logic expert present on this issue - otherwise it is just opinions and there is no actual engineering going on. Now it is perfectly OK to implement such functionality if it is highly valued by the prospective customer, but it is clear that this a heterogeneous market place - which is the crux of why we struggle to come to consensus in areas such as this. I can well imagine it being hard to go to some ISPs and justify why it was implemented when it will never be used. I can just as easily imagine (in fact I know) that it would be equally hard to go to some carriers and justify why it was not implemented when it would be constantly used. Where the process broke down, from my position on the sideline in the cheap seats , was a) we as a group had a learning process about how we thought of MPLS-LDP, i.e. CO, CNLS,....and that created a lot of communication problems with respect to getting down to the real meat of the issues and really understanding the requirements (still today some people think of MPLS-LDP as CO when clearly this is a really grey area) b) while the IETF community understood intuitively the kind of solution that was appropriate to the CNLS networks of traditional target customers (LSP-PING) and also for IP-VPN networks (an area which I think it might be slightly stronger in, in some non-trail/tunnel respects, when compared to Y.1711), it was slower to understand the kind of solution that was required for a carrier-class, robust SLA, CO network - which based on experience is actually to be expected. This may have been manifested in the vilification of Y.1711 as the grand drama of competitive approaches and lack of understanding played out, but hopefully this can be acknowledged and we can move on from here. Ultimately there has to be some decision point (either consciously or unconciously) by the IESG about whether we really want to merge the standards setting process for carriers, ISPs, and enterprises + CO and CNLS in to one standards group; and if so, how are we going to improve our sophistication about "signaling" what proposal addresses what end user and what network mode. What I personally would like to see is as much possible identification of commanility, leading to as much possible reuse of PDU structures across different (or subset/superset) implementations. This I think is the larger tragedy that gets forgotten in the day to day banter (in multiple WGs). A good engineering process would, IMHO, acknowledge the implications for existing equipment, acknowledge where we want to be in the long run, and build a roadmap to get from here to there that allows for graceful evolution. This is perhaps where the mantra of "one solution" may break down if we are not careful (and that is not even including the issues stated above WRT to different audiences and network modes). Some specific comments on some snips below. Thanks, Mark > 4) I assume the implied suggestion is that any > centralized push/polling mechanism is not scalable, so > it can not be the long-term solution? In other words, > the method of invocation is kind of orthogonal as long > as the OAM function is doing what it needs to do; the > only remaining issue is whether the method of > innvocation has some fundamental flaws. >>Not as much the method of invocation, it is a combination of attributes: how determinitic testing is, whether a fault will turn up in multiple diverse places and how that is correlated such that the most frugal response is possible, can responding be delegated into the network etc.etc. << MS=> so now we are adding even more complexity to the network element - delegated responding. So clearly two different classes of equipment are emerging with diverging paths, and diverging customer bases - how to we accomodate this is one standards process? > Could you be more explicit about the feedback you are > receiving. Is it related to the use of central management tools? >> The feedback is a mix depending on where the carrier is using MPLS now and the experience they've had, and how they envision using it in the future. << MS=> I understand the difficulty in answering the question. Hopefully you understand my difficulty in understanding the problem within a void of some characterization of it. > I think the answer is no. And I state this only in a > hope that we can reach some level of consensus before > continuing the logic tree. >>Some potential counterpoints are: 1) lots more code driving the label swapping configuration and with higher frequency. As a counterpoint, in an ATM PVC network, the cross connect table is only touched when there is a provisioning change. Even in an SVC network, a routing change frequently may not change the forwarding state of the switch. << MS=> Fair enough. >> 2) MPLS has a label stack, so there is an extra dimension to things that can go wrong. << MS=> Yes, in all forms of processing. >> 3) MPLS originally assumed it would exist in a hybrid IP network......<< MS=> Has this changed (in the IETF)? >> As far as LDP is concerned, the only question in my mind is what is an appropriate response to the additional modes of failure << MS=> agreed >> when considering the potential frequency. << MS=> so given that LDP has been deployed, are we actually seeing these types of errors with any "greater" frequency. If the label mis-swap problem has to be solved for any label swapping network that is fine, but are we proposing something different than we would for say ATM because of an assumed greater/potential frequency? >> Throw in the label stack as well and what you need is somthing ubiquitous as the problem may not occur uniquely in the LDP layer. << MS=>I assume you mean that the user plane may not be carrying IP, if not then I didn't understand the comment. > So even though the answer is no, it is as you say a > problem that other CNLS networks do not have to deal > with, and therefore a problem to which a solution is > required. I can envision two possible solutions: 1) a > P2P overlay 2) OAM messages that have the source > address embedded in them (this would need to be an > interface/sub-interface address as opposed to a LSR > identifier is my guess). To me, option 2) is preferable - > what is wrong with this approach? >> A p2p overlay is a solution, but if used in isolation, you have the problem that an LDP problem spills a lot of overlay p2p LSPs, therefore who owns the problem. IMHO the LDP layer needs a bit of help in this regard. As for '2', an access point ID is the basis of the villified TTSI in Y.1711. << MS=> I don't remember why the TTSI was villified (though it does look like the tunnel construct is not applicable to LDP) >> It is straightforward for p2p but requires the egress to track many access points for mp2p. For mp2p we're working on y.17fec-cv (SG13) where the FEC info is encoded in the probe and that is what is checked. << MS=> I couldn't see this on the ITU website, could you or someone else shoot me a copy, would be interested in taking a look, specifically at the TTSI. > > > On the CO dimension of MPLS, it strikes me that there > is no RSVP-TE solution for PWE - is this correct and > should this be so? >> Technically an RSVP-TE LSP could carry a PW directly (it does have a PID exchanged in one of the objects) and not as an LDP overlay. So I'm unaware of anything that precludes this option. << MS=> I only raise this issue to ask the question that if a CO mode is required, why is there not more RSVP-TE based proposals for both PWE and VPLS? Clearly RSVP-TE based implementation is possible. > > On the issue of fault correlation, as this is > inherently a multi-layer problem, can this be solved > within the standards process for one layer. i.e. what > can be done without looking at the top to bottom > solution? >> You phrase the problem strangely. << MS=> Agreed, and thanks for the explanation. > >> So I would tend to characterize the debate as > between those interesting in doing their perception of > the "right thing" where the criteria of "rightness" is > not necessarily aligned ;-) << > > So then you agree that both parties have good > intentions to do the right thing ;-) Then it is just a > matter of people of good will....... ;-) >> There's a few subtleties still to be addressed ;-) << MS=> :-)) From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Is PWE a layer - thread summary Date: Thu, 29 May 2003 13:13:19 -0700 (PDT) Lines: 181 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Thu May 29 22:18:42 2003 Return-path: To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Felt it might be useful to summarize some of the issues/thoughts raised on this thread. Mark The thread started with an observance that is easy for a protocol to creep from an in-between layer to a full layer, siting the history of MPLS that was first proposed as a simple shim; it was further noted that when this occurs then formal treatment to control and management is required. The inference then is that we as a group should be concerned about actions we take which make lead us down the road of developing a new layer. Issue 1. Is it the intention that PWE be just an adaptation function? The suggestion was then made that if we stick to network interworking any client OAM/PWE OAM can be carried transparently. Further, it was suggested that service interworking could be avoided by doing protocol translations either side of the PWE core, and thereby creating a like-to-like service, end-to-end. Issue 2. Can service interworking be avoided by translations either side of PWE? Issue 3. Is service interworking in or out of scope? The still debated OAM issues leaked in to this thread (in fact were the original genesis of the thread) with a number of people supporting the view that the server layer (MPLS) requires OAM in order to support network interworking. Some stated that in the absence of MPLS OAM, PWE OAM would be required, but that it was not the preferred path. Issue 4. Is it essential for the IETF to provide the kind of MPLS OAM that is desired (or can another standards body provide this)? The problem with adapting a common mechanism to do different PSN types is that each PSN different capabilities. So it has been observed that if neither the client layer (Ethernet) or the server/PSN (IP or MPLS) has OAM, then there is a problem. It has been further observed that the correct fix is to fix each layer independently. The obvious attraction of the PWE OAM approach is quick time to market with one mechanism. Various opinions have been expressed as to the architectural downsides of this approach. Issue 5. Is it conceivable to think of PWE OAM as an extension to the client layer for the network interworking case? Issue 6. Is it conceivable to think of PWE OAM as a not required extension for the cleint layer for the service interworking case? The issue of how many layes of the stack does OAM need to be performed at arose. It was mentioned "..fault management is most frugally performed at the transport layer although it must also exist to some degree at the PW layer. Performance management hits both as well, network planners need the transport measurements, and SLA reporting needs the PW measurements. " But in an MPLS network with "n" layers, which is the layer that is considered transport, and which is the layer that SLA needs to be performed on. For example, take a network that has a label for restoration, a label for traffic engineering, a label for PE-PE, a label for each VPN, and PWE. Which of these "layers" is OAM required on? This many layers above the facility layer is a new capability in networks, so hwo do we think about it? It was also mentioned that when e2e mechanisms are overlayed, the problem becomes not one of fault correction, but fault correlation - so does fault correlation become too complex with this many layers? Issue 7. Is OAM required on every layer? Issue 8: Are there different OAM requirements at different layers - and if so, does this problem become too complex? Issue 9: Is it possible that PWE OAM is a good SLA-level mechanism but other transport-level OAMs may be needed/optional? Some disagreement occurred over whether LSP ping was too heavy weight to do periodic connectivity verification, with the later suggestion that much of the discussion on the list focused in connectivity verification rather than alarm indication suppression. Issue 10. Is PWE OAM too heavy weight for alarm indication/suppression or connectivity verification; and if so why, and is there any evidence of this? A criticism of the PWE OAM approach is that it generates messages regardless of whether a fault exist or not, which some see as being at variance to typical/desired OAM behavior. Issue 11. Should PWE OAM have an option to suppress outputs? The thread is winding down with discussion on the difficulties of a generalized approach as MPLS injects link swapping fault modes into what otherwise might be considered a CNLS network; whether a P2P overlay is ineeded needed to achieve OAM (to overcome MP2P merge) vs just using OAM messages that indicate source (and it seems to me both LSP-PING and Y.1711 can). Personal observations: -With the exception that there was disagreement about whether mode swaps would prevent clock recovery, there was general agreement that PWE over both MPLS and IP can work -PWE OAM appears to me to be rooted in concepts of SLA management (vis-a-vis FR OAM was used as a model). -Other transport OAM mechanisms should be available to operators as an option (potentially developed by other standards bodies if the IETF wants to pass on this work). -The terms CNLS and CO can be limiting. For example, LDP is clearly CNLS in many respects, but because of the label swap forwarding elelement, it introduces fault modes that would normally be associated with CO networks, and because of the semantics of the user plane (i.e. no source address) it has restrictions that would normally be associated with a CO network. Therefore, it is my conclusion that LDP-MPLS is a hybrid CO-CNLS mode; and clarity in discussion can be achieved by referring specifically to the characteristic that is at issue, i.e. label swap fault modes, rather than assuming people understand the moniker "CO". -Ethernet is a service that SPs have indicated to many vendors that they want to roll out over a PSN, and they want to do it quickly in some cases. Ethernet is defficient in a numer of ways, not the least of which is a standardized OAM (though since the EFM is working on one, it may be forthcoming). If we can use PWE OAM as a client-layer psuedo OAM, and at the same time bound the problems this causes and comit not to being here in three years discussing Diffserv for PWE ;-) then it could be a win-win for many people. Issues summary ============ Issue 1. Is it the intention that PWE be just an adaptation function? Issue 2. Can service interworking be avoided by translations either side of PWE? Issue 3. Is service interworking in or out of scope? Issue 4. Is it essential for the IETF to provide the kind of MPLS OAM that is desired (or can another standards body provide this)? Issue 5. Is it conceivable to think of PWE OAM as an extension to the client layer for the network interworking case? Issue 6. Is it conceivable to think of PWE OAM as a not required extension for the cleint layer for the service interworking case? Issue 7. Is OAM required on every layer? Issue 8: Are there different OAM requirements at different layers - and if so, does this problem become too complex? Issue 9: Is it possible that PWE OAM is a good SLA-level mechanism but other transport-level OAMs may be needed/optional? Issue 10. Is PWE OAM too heavy weight for alarm indication/suppression or connectivity verification; and if so why, and is there any evidence of this? Issue 11. Should PWE OAM have an option to suppress message output? From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RE: Is PWE a layer? Date: Thu, 29 May 2003 18:01:39 -0400 Lines: 359 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 30 00:05:02 2003 Return-path: To: "'Mark Seery'" , David Allan X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mark, I agree with many of the points that you raise. However, there is one issue that keeps bothering me whenever we discuss Y.1711 and LSP Ping, which you bring up in your email as well. It is the notion that Y.1711 requires to a lot of processing whereas LSP Ping does not. According to Y.1711, Connection Verification messages are sent at a rate of one packet per second, but "other configurable CV generation rates are for further study". Let's assume that the CV generation rate is configurable. The rate required by a Service Provider depends on the client service (e.g. VPLS probably doesn't require frequent CV), the architecture of the MLS network (e.g. can fault detection be done at a lower layer of MPLS pipes, thus reducing the number of connections that need to be monitored), etc. For the purposes of specifying OAM for PWE3, I don't think there is any reason to require that the generation rate of Y.1711 CV messages is necessarily higher than the generation rate of LSP Ping messages. Comparing Y.1711 and LSP Ping, I see one big difference: With LSP Ping, if a PE doesn't receive a reply, it doesn't know what the problem is. It is possible that the PW is down, but it is also possible that the return path is unavailable. In Y.1711, upstream and downstream PEs work in tandem and it is the downstream PE that determines that the link is down. To me it seems evident that the fault detection mechanism defined in Y.1711 is superior to that of LSP Ping, no matter what Tom's 25 happy customers say. So what exactly is the problem with adopting Y.1711 for PW OAM, as long as we speciify that the CV generation rate is configurable? This would not require any vendor to implement the function in ASICs or provide some other form of HW acceleration. Peter > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: Tuesday, May 27, 2003 10:00 PM > To: David Allan > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > Dave, > > The first batch of questions in my previous response > was to try and flush out the fact that this effort is > trying to meet the needs of a wide range of service > providers with different mindsets and business models; > including stand-alone ISPs, ISPs within a carrier, > carriers upgrading ATM networks to MPLS, carriers > building new MPLS networks for Ethernet, etc. > > From this flows two distinct categories of conflict: > > 1) What can be implemented in existing equipment > 2) The operations culture variance among different SPs > > Quoting from draft-allan-y1711-and-lsp-ping: > > "LSP-PING is designed to be retrofitted to existing > deployed networks....." > "Y.1711 depends on some degree of ubiquitous > deployment at the edge to maximize coverage of fault > detection" > > These two comments alone lead to various substantial > inferences: 1) That LSP-PING can be used with existing > installed equipment and that other approaches may not > be optimized for that purpose and b) substantial > benefits may only accrue via Y.1711 if there is > ubiquity of deployment. So perhaps my previous > comments were badly worded if they implied that the > entire network needs to be replaced, but clearly there > is an existing assets issue here. The accomodation of > existing equipment and network evolution is not > without precedent, as an example I would cite the DSL > Forum's working text 81 (WT81) which proposes > significant capability increase to the network, but > clearly accomodates the presence of existing DSLAMs by > the creation of a new gateway function. > > With respect to your comment that this functionality > is easily assumed into silicon, I'd like to first make > the flipant remark that a few gates here, and a few > gates there, and all of a sudden we are talking > serious silicon; or rather if you take one approach as > a whole and compare it to another approach as a whole, > on aggregate there may be significant differences. I > would also observe that packet processing remains bit > for bit significantly more expensive (in terms of > power at least) than TDM processing, so the packet > processing industry's goal as a whole should be > further reduction, and that additional processing > should be examined skeptically. This may be the wrong > place to cut back on, but there should be a general > intent to cut back on processing, (including the > unnecessary adding of new layers - I am not one sided > on this issue), where possible, and therefore we > should not assume that adding functionality to silicon > has no impact, we should justify the addition. > > Specifically, say my PE supports 10,000 LSPs. Now the > design has to allow for the possibility of 10,000 OAMs > per second (depending on the network architecture, > many of them may be on the same interface). Each of > these OAMs requires a BIP calculation (simple logic to > be sure) in addition to what ever OAM processing is > required. The OAMs might be occurring on multiple > stack levels (3 or more) concurrently - so how is this > impacting my pipeline? Now say there is a fault. In > the midst of a network error I am now creating > additional processing in the form of FDI flows at > 1/sec. (perhaps even BDI, but most LSPs are > unidirectional....). So at the worst time, during a > fault, I am throwing even more processing in to the > user plane - a tractable issue (but actually an > interesting debate is to be had here about avoiding > non-linearality - yes I know, alarm storms could > create another type), but has to be allowed for in the > design. I do not say this to criticize Y.1711, I think > it is essential functionality for a certain type of > carrier, seeking to achieve certain goals - my only > point is that it is not clear cut to me that the > addition of OAM (especially for a multi-level stack of > indefinite depth) is painless and with out need for > tradeoffs in the packet processing pipeline (you can > do what early ATM implementations did and shunt > everything off to an adjunct processor, but that has > its own costs and complications). What would be really > useful is to actually have a digital logic expert > present on this issue - otherwise it is just opinions > and there is no actual engineering going on. > > Now it is perfectly OK to implement such functionality > if it is highly valued by the prospective customer, > but it is clear that this a heterogeneous market place > - which is the crux of why we struggle to come to > consensus in areas such as this. I can well imagine it > being hard to go to some ISPs and justify why it was > implemented when it will never be used. I can just as > easily imagine (in fact I know) that it would be > equally hard to go to some carriers and justify why it > was not implemented when it would be constantly used. > > Where the process broke down, from my position on the > sideline in the cheap seats , was a) we as a group had > a learning process about how we thought of MPLS-LDP, > i.e. CO, CNLS,....and that created a lot of > communication problems with respect to getting down to > the real meat of the issues and really understanding > the requirements (still today some people think of > MPLS-LDP as CO when clearly this is a really grey > area) b) while the IETF community understood > intuitively the kind of solution that was appropriate > to the CNLS networks of traditional target customers > (LSP-PING) and also for IP-VPN networks (an area which > I think it might be slightly stronger in, in some > non-trail/tunnel respects, when compared to Y.1711), > it was slower to understand the kind of solution that > was required for a carrier-class, robust SLA, CO > network - which based on experience is actually to be > expected. This may have been manifested in the > vilification of Y.1711 as the grand drama of > competitive approaches and lack of understanding > played out, but hopefully this can be acknowledged and > we can move on from here. > > Ultimately there has to be some decision point (either > consciously or unconciously) by the IESG about whether > we really want to merge the standards setting process > for carriers, ISPs, and enterprises + CO and CNLS in > to one standards group; and if so, how are we going to > improve our sophistication about "signaling" what > proposal addresses what end user and what network > mode. > What I personally would like to see is as much > possible identification of commanility, leading to as > much possible reuse of PDU structures across different > (or subset/superset) implementations. This I think is > the larger tragedy that gets forgotten in the day to > day banter (in multiple WGs). > > A good engineering process would, IMHO, acknowledge > the implications for existing equipment, acknowledge > where we want to be in the long run, and build a > roadmap to get from here to there that allows for > graceful evolution. This is perhaps where the mantra > of "one solution" may break down if we are not careful > (and that is not even including the issues stated > above WRT to different audiences and network modes). > Some specific comments on some snips below. > > Thanks, > Mark > > > 4) I assume the implied suggestion is that any > > centralized push/polling mechanism is not scalable, > so > > it can not be the long-term solution? In other > words, > > the method of invocation is kind of orthogonal as > long > > as the OAM function is doing what it needs to do; > the > > only remaining issue is whether the method of > > innvocation has some fundamental flaws. > > >>Not as much the method of invocation, it is a > combination of attributes: how determinitic testing > is, whether a fault will turn up in multiple diverse > places and how that is correlated such that the most > frugal response is possible, can responding be > delegated into the network etc.etc. << > > MS=> so now we are adding even more complexity to the > network element - delegated responding. So clearly two > different classes of equipment are emerging with > diverging paths, and diverging customer bases - how to > we accomodate this is one standards process? > > > Could you be more explicit about the feedback you > are > > receiving. Is it related to the use of central > management tools? > > >> The feedback is a mix depending on where the > carrier is using MPLS now and the experience they've > had, and how they envision using it in the future. << > > MS=> I understand the difficulty in answering the > question. Hopefully you understand my difficulty in > understanding the problem within a void of some > characterization of it. > > > I think the answer is no. And I state this only in a > > > hope that we can reach some level of consensus > before > > continuing the logic tree. > > >>Some potential counterpoints are: > > 1) lots more code driving the label swapping > configuration and with higher frequency. As a > counterpoint, in an ATM PVC network, the cross connect > table is only touched when there is a provisioning > change. Even in an SVC network, a routing change > frequently may not change the forwarding state of the > switch. << > > MS=> Fair enough. > > >> 2) MPLS has a label stack, so there is an extra > dimension to things that can go wrong. << > > MS=> Yes, in all forms of processing. > > >> 3) MPLS originally assumed it would exist in a > hybrid IP network......<< > > MS=> Has this changed (in the IETF)? > > >> As far as LDP is concerned, the only question in my > mind is what is an appropriate response to the > additional modes of failure << > > MS=> agreed > > >> when considering the potential frequency. << > > MS=> so given that LDP has been deployed, are we > actually seeing these types of errors with any > "greater" frequency. If the label mis-swap problem has > to be solved for any label swapping network that is > fine, but are we proposing something different than we > would for say ATM because of an assumed > greater/potential frequency? > > >> Throw in the label stack as well and what you need > is somthing ubiquitous as the problem may not occur > uniquely in the LDP layer. << > > MS=>I assume you mean that the user plane may not be > carrying IP, if not then I didn't understand the > comment. > > > So even though the answer is no, it is as you say a > > problem that other CNLS networks do not have to deal > > > with, and therefore a problem to which a solution is > > > required. I can envision two possible solutions: 1) > a > > P2P overlay 2) OAM messages that have the source > > address embedded in them (this would need to be an > > interface/sub-interface address as opposed to a LSR > > identifier is my guess). To me, option 2) is > preferable - > > what is wrong with this approach? > > >> A p2p overlay is a solution, but if used in > isolation, you have the problem that an LDP problem > spills a lot of overlay p2p LSPs, therefore who owns > the problem. IMHO the LDP layer needs a bit of help in > this regard. > As for '2', an access point ID is the basis of the > villified TTSI in Y.1711. << > > MS=> I don't remember why the TTSI was villified > (though it does look like the tunnel construct is not > applicable to LDP) > > >> It is straightforward for p2p but requires the > egress to track many access points for mp2p. For mp2p > we're working on y.17fec-cv (SG13) where the FEC info > is encoded in the probe and that is what is checked. > << > > MS=> I couldn't see this on the ITU website, could you > or someone else shoot me a copy, would be interested > in taking a look, specifically at the TTSI. > > > > > > > > On the CO dimension of MPLS, it strikes me that > there > > is no RSVP-TE solution for PWE - is this correct and > > > should this be so? > > >> Technically an RSVP-TE LSP could carry a PW > directly (it does have a PID exchanged in one of the > objects) and not as an LDP overlay. So I'm unaware of > anything that precludes this option. << > > MS=> I only raise this issue to ask the question that > if a CO mode is required, why is there not more > RSVP-TE based proposals for both PWE and VPLS? Clearly > RSVP-TE based implementation is possible. > > > > On the issue of fault correlation, as this is > > inherently a multi-layer problem, can this be solved > > > within the standards process for one layer. i.e. > what > > can be done without looking at the top to bottom > > solution? > > >> You phrase the problem strangely. << > > MS=> Agreed, and thanks for the explanation. > > > >> So I would tend to characterize the debate as > > between those interesting in doing their perception > of > > the "right thing" where the criteria of "rightness" > is > > not necessarily aligned ;-) << > > > > So then you agree that both parties have good > > intentions to do the right thing ;-) Then it is just > a > > matter of people of good will....... ;-) > > >> There's a few subtleties still to be addressed ;-) > << > > MS=> :-)) > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: RE: Is PWE a layer? Date: Thu, 29 May 2003 15:48:46 -0700 (PDT) Lines: 110 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, dallan@nortelnetworks.com X-From: pwe3-admin@ietf.org Fri May 30 00:52:26 2003 Return-path: To: "Busschbach, Peter B \(Peter\)" In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Peter, > According to Y.1711, Connection Verification > messages are sent at a rate of one packet per > second, but "other configurable CV generation rates > are for further study". I have a couple of challenges with this: a) what has to be implemented b) if the rate is lessoned, are the exit/entry requirements met. What is implemented =================== If a standard is written in such a way as to suggest that an operator may wish to operate a feature at its boundary conditions, on all layers of the network, then I have a problem in terms of what I tell engineers to implement. Now you could probably respond, that if I had any clue about what I was doing, then the answer would be obvious - which is a far comment in this case ;-) - but then it brings up the issue of what does it mean to be standards compliant. You suggested one compromise in that maybe we don't need the same functionality (transport) at every layer of the network - thank you for offering that and it would be interesting to see if there is any support for that position. Meeting entry/exit requirements =============================== The authors of Y.1711 have done a great job in really thinking through what they want to achieve; but if course in this business you can't win for losing. The downside of the meticulous detail they have gone to is that I now question if I know whether entry/exit criterias can be met if I start running at different rates. Now Y.17fec-cv does try to give some guidance on this (fig.1 required probe insertion rate); and Dave was kind enough to shoot me a message offline explaining at that in the MP2P case there may be room for relaxing requirements, but to me this then becomes the issue: what rate achieves the desired goal, and until I feel comfortable with that issue, it is hard for me to make implementation tradeoffs about what rates I would offer to a customer. > For the purposes of specifying OAM for PWE3, I don't > think there is any reason to require that the > generation rate of Y.1711 CV messages is necessarily > higher than the generation rate of LSP Ping > messages. At this point I question whether LSP Ping and Y.1711 have the same goals, so I am not sure that is a valid assertion. For example, if Y.1711 is a robust mechanism for carrier class transport layer fault management, whereas the LSP PING is really focused on some connectivity verification and SLA feedback, then I don't think the assertion stands; moreover, maybe both are applicable, which may be what Dave was alluding to in: allan-y1711-and-lsp-ping > Comparing Y.1711 and LSP Ping, I see one big > difference: With LSP Ping, if a PE doesn't receive a > reply, it doesn't know what the problem is. It is > possible that the PW is down, but it is also > possible that the return path is unavailable. In > Y.1711, upstream and downstream PEs work in tandem > and it is the downstream PE that determines that the > link is down. So I can only comment once I understand the requirements that LSP Ping is trying to meet, though obviously looking at your statement at face value, I can see the problem; and if LSP Ping purports to be a robust fault detection mechanism, then it has some defficiences WRT requirements as they have been interpreted by other standards bodies + the desired tools by a class of carriers. > To me it seems evident that the fault detection > mechanism defined in Y.1711 is superior to that of > LSP Ping, no matter what Tom's 25 happy customers > say. This seems like a valid assertion. > So what exactly is the problem with adopting Y.1711 > for PW OAM, as long as we speciify that the CV > generation rate is configurable? This would not > require any vendor to implement the function in > ASICs or provide some other form of HW acceleration. So putting aside the question should we do any OAM at the PWE "layer" ;-) the next issue is does that OAM capability need to be a robust transport layer like fault detection mechanism; if so, then will it work over other PSNs is the next question; followed by does it have functionality that Y.1711 does not (seems like it has some pretty good VPN support which Y.1711 is now addressing but might be some room for requirements merge here at least). Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Zhou Yun\(HarbourNetworks\)" Subject: Why can't send Label release message when receiving lable withdraw message Date: Fri, 30 May 2003 09:21:19 +0800 Lines: 3 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Fri May 30 03:28:00 2003 Return-path: To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4U1QbB08098 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O In draft-ietf-pwe3-control-protocol-02.txt, it is said that"If at any time after a Label Mapping message has been received, a corresponding Label Withdraw or Release is received, the action taken is the same as for any Label Withdraw or Release that might be received at any time. Note that receiving a Label Withdraw should not cause a corresponding Label Release to be sent." Why can't response Label release messsge when receiving Label withdraw message? How the downstream knows that the upstream has released this label then it can reuse this label? From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Is PWE a layer - thread summary Date: Thu, 29 May 2003 22:06:03 -0400 Lines: 100 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Fri May 30 04:07:42 2003 Return-path: To: "'Mark Seery'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mark, Great summary. Thanks. A couple of the issues that you raise deal with the questions "how much OAM is required and where?" (issues 7, 8 and 9), and "is it the IETF's business anyway?" (issue 4). This is indeed the problem and we don't seem to be moving towards consensus. I think there is a big difference between an ISP offering VPLS-like services over an MPLS network and a more traditional Telco looking at MPLS as a way to evolve its Frame Relay and ATM networks. The ISP may be able to get away with very little OAM. The Telco will definitely require a much more robust solution. In my view, the IETF has taken a big step by deciding to define encapsulations of ATM and Frame Relay. If these respective standards move forward and become proposed standards, there needs to be an companion document that specifies a sufficently robust OAM solution. Vice versa, if the IETF decides not to define OAM and relegates it to another standards body, I believe it should stop all work on ATM and Frame Relay encapsulation. Further comments in-line. Peter > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: Thursday, May 29, 2003 4:13 PM > To: pwe3@ietf.org > Subject: [PWE3] Is PWE a layer - thread summary > > > Felt it might be useful to summarize some of the > issues/thoughts raised on this thread. > > Mark > > [snipped] > Issues summary > ============ > > Issue 1. Is it the intention that PWE be just an > adaptation function? I think that PWE was supposed to be just an adaptation layer. I think there are two forces that are turning into something more than that: a) Difficulties in fault detection in the MPLS layer due to ECMP, which leads to the need for fault detection per PW. b) The possibility of threading PWs together though switching based on the PW label (i.e. the TTL>2 discussion) I am not sure how we would benefit from agreeing on an answer to your question. For the purist, it may not matter much. If PW is just adaptation, you do OAM in the underlying MPLS layer. If PW is a layer in and of itself, you do OAM in both the PW layer and the underlying MPLS layer. However, you would use the same mechanisms on both layers and the overall solution would not necessarily be more complex. > Issue 2. Can service interworking be avoided by > translations either side of PWE? Yes, you can avoid service inteworking with the MPLS layer. E.g. to achieve FR-ATM Service Interworking, you can use FRF.8 somewhere in the network (possibly in the NSP function of the PEs) and carry either FR or ATM over PW. However, the issue that Neil brought up was different. I thought that in his view, Service Interworking was the preferred way to carry ATM and FR services over an MPLS core. In other words, to do FR-ATM Service Interworking, it might be best to do FR-MPLS Service Interworking at the ingress of the MPLS core and MPLS - ATM Service Interworking at the egress of the MPLS core. I actually think Issue 2 is irrelevant to PWE. PWE is a solution for Network Interworking. If you want to use PWE and you need Service Interworking, you need to do it outside the PW between the respecive client layers. > Issue 3. Is service interworking in or out of scope? Right now it is out of scope. Should that change? I think Service Interworking is important and needs to be standardized. However, I see little synergy between the solutions that have been developed for PWE and what you would need for Service Interworking. Hence, adding Service Interworking to the charter might open Pandora's box. > Issue 4. Is it essential for the IETF to provide the > kind of MPLS OAM that is desired (or can another > standards body provide this)? > Issue 5. Is it conceivable to think of PWE OAM as an > extension to the client layer for the network > interworking case? It is conceivable, but wrong :-) But seriously, you are thinking of using PW OAM to provide OAM for Ethernet services, right? I think we have to be very careful with that. The discussion on "VPLS model for L2VPN Framework" that is currently going on on the PPVPN mailing list shows how tricky it is to correctly map IEEE bridging models. I believe that Ethernet OAM should be defined by the IEEE. Making some short-cuts using PW OAM may lead to big problems later. > Issue 6. Is it conceivable to think of PWE OAM as a > not required extension for the cleint layer for the > service interworking case? As I mentioned above, the current definition of PWE is not well suited for Service Interworking. I find it hard to parse your formulation of Issue 6, but by all means, let's not link PWE and Service Interworking. > Issue 7. Is OAM required on every layer? > Issue 8: Are there different OAM requirements at > different layers - and if so, does this problem become > too complex? > Issue 9: Is it possible that PWE OAM is a good > SLA-level mechanism but other transport-level OAMs may > be needed/optional? > Issue 10. Is PWE OAM too heavy weight for alarm > indication/suppression or connectivity verification; > and if so why, and is there any evidence of this? > Issue 11. Should PWE OAM have an option to suppress > message output? In your email you wrote >> A criticism of the PWE OAM approach is that it generates messages regardless of whether a fault exist or not, which some see as being at variance to typical/desired OAM behavior. << I am not sure which PWE OAM approach you are referring to. Is your point: if a PW is down, should a PE suppress client layer traffic? I don't think so. Layers should be independent as much as possible. A PWE OAM function needs to detect failures in the PW/MPLS layer and inform the client layer of the failure. From that point on it is up to the client layer to decide what should happen. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: Is PWE a layer - thread summary Date: Thu, 29 May 2003 21:38:24 -0700 (PDT) Lines: 269 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 30 06:40:07 2003 Return-path: To: busschbach@lucent.com In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Peter, --- "Busschbach, Peter B (Peter)" wrote: > Mark, > > Great summary. Thanks. thx. > I think there is a big difference between an ISP > offering VPLS-like services over an MPLS network and > a more traditional Telco looking at MPLS as a way to > evolve its Frame Relay and ATM networks. The ISP may > be able to get away with very little OAM. The Telco > will definitely require a much more robust solution. There is no such thing as a free lunch - there is a tradeoff for "robust"; but which SPs pursue what value proposition with what solutions should not be bounded by what type of SP they are - going forward, this is a choice that each makes. In a sense, this and other comments you make, suggest a larger issue - that various organizations have traditionally been integral elements of various and often competing ecosystems. The real issue is that the IETF has traditionally pursued a certain approach to networking that was believed to deliver certain values: lower cost, greater scalability, faster time to market, open ness, the unix philosophy of many small tools rather than monolithic architectures,..... All great value propositions are a package of elements - aimed and focused. It is as hard for the IETF to change one element of the package and still assert its value proposition is whole, as it would be for the ITU. This is related to your comment in the sense that the IETF has traditionally been closely aligned to the ISP ecosystem, and the ITU (and various other bodies) have traditionally been aligned to the carrier ecosystem. Then there is the vendor element. It is **probably** easier to migrate an ATM switch along the Y.1711 approach than to migrate a router along that approach; and because ATM vendors already understand the OAM concepts being discussed, it is also easier for them to understand Y.1711, how to implement it, and how to use it to solve a customer requirement. And there is the operator element. Because a carrier already undertands how to organize an operation around OAM, then it is easier to migrate their operation around Y.1711. Because an ISP may not have organized their operation around OAM, it is much harder, and possibly expensive, to organize their operation around OAM. And then there is the issue of a carrier doing a greenfield deployment for a new service - should they pursue a new path for the sake of leading the rest of the SP? The only real problem here is defining what problem we are solving. Once that is done, there is no lack of brain power on this list (with the exception of me of course) to go solve that problem. All that said, there should be no reason why we can not work together to develop solutions for a variety of problems, network evolution scenarios, and operators, while also finding commonality that allows us to build upon a common framework. > In my view, the IETF has taken a big step by > deciding to define encapsulations of ATM and Frame > Relay. If these respective standards move forward > and become proposed standards, there needs to be an > companion document that specifies a sufficently > robust OAM solution. Vice versa, if the IETF decides > not to define OAM and relegates it to another > standards body, I believe it should stop all work on > ATM and Frame Relay encapsulation. I don't. The LSP-PING / PWE OAM approaches are consistent with an alternative approach to building networks. If it remains consistent with a package of elements, then that allows the market to provide differentiation among service providers - this is in my purists point of view what makes for a beautiful "market". The participants in this working group do need to make a decision though about whether one solution will meet the needs of all significant elements of the SP industry. It is valid for them to make that choice. I do believe however that if the participants of this WG are unable to come to agreement on an implementation for an additional robust transport layer OAM, then there are implications for the use and future of MPLS, and for vendors who do not pursue additional elements through other organizations (that is purely a personal opinion - there is no impirical proof for this, especially given the current health of the vendor community). At the very least, vendors wil be laying down a bet, which may or may not pay off; each vendor will have to decide if they want to make that bet. Each operator will have to decide if they want to pursue alternative approaches through different organizations. Now back to more OT issues ;-) > I think that PWE was supposed to be just an > adaptation layer. I think there are two forces that > are turning into something more than that: > > a) Difficulties in fault detection in the MPLS layer > due to ECMP, which leads to the need for fault > detection per PW. Thanks Pete, I forgot about that. Additionally I need to educate myself on a) the implications of ECMP on OAM, and b) whether OAM upper layer OAM even makes any sense in an ECMP environment. > b) The possibility of threading PWs together though > switching based on the PW label (i.e. the TTL>2 > discussion) So if something is not a layer, how can you stitch it together? Seems to me this is heading down the road that some of us are worried about. 3 years from now we will be here discussing TE and Diffserv for PW ;-) > I am not sure how we would benefit from agreeing on > an answer to your question. For the purist, it may > not matter much. If PW is just adaptation, you do > OAM in the underlying MPLS layer. If PW is a layer > in and of itself, you do OAM in both the PW layer > and the underlying MPLS layer. However, you would > use the same mechanisms on both layers and the > overall solution would not necessarily be more > complex. The importance of such questions is to test the premise whether PW over both IP and MPLS makes sense. What I suspect is that some PWE elements should only be used when running over IP; and then, the issue arises of whether the package of elements that is IP, is consistent with that approach. > > Issue 2. Can service interworking be avoided by > > translations either side of PWE? > > Yes, you can avoid service inteworking with the MPLS > layer. E.g. to achieve FR-ATM Service Interworking, > you can use FRF.8 somewhere in the network (possibly > in the NSP function of the PEs) and carry either FR > or ATM over PW. Sounds reasonable to me. > However, the issue that Neil brought up was > different. I thought that in his view, Service > Interworking was the preferred way to carry ATM and > FR services over an MPLS core. In other words, to do > FR-ATM Service Interworking, it might be best to do > FR-MPLS Service Interworking at the ingress of the > MPLS core and MPLS - ATM Service Interworking at the > egress of the MPLS core. > > I actually think Issue 2 is irrelevant to PWE. PWE > is a solution for Network Interworking. If you want > to use PWE and you need Service Interworking, you > need to do it outside the PW between the respecive > client layers. So the issue becomes can we get consensus that it is OK to use PWE for network interworking, but it is OK for PWE to just disappear when doing service interworking; but if you of the mindset that PWE is actually a layer, you are bound to be perpetually confused about what choice to make when. >> Issue 3. Is service interworking in or out of > scope? > > Right now it is out of scope. Should that change? I > think Service Interworking is important and needs to > be standardized. However, I see little synergy > between the solutions that have been developed for > PWE and what you would need for Service > Interworking. Hence, adding Service Interworking to > the charter might open Pandora's box. OK, thanks. > > Issue 4. Is it essential for the IETF to provide > the > > kind of MPLS OAM that is desired (or can another > > standards body provide this)? > > > Issue 5. Is it conceivable to think of PWE OAM as > an > > extension to the client layer for the network > > interworking case? > > It is conceivable, but wrong :-) But seriously, you > are thinking of using PW OAM to provide OAM for > Ethernet services, right? That is a potential, yes. Other potentials include any future client that does not have OAM; not such an issue if we can get robust OAM in to all the server layers (IP and MPLS), but it appears we are not there yet. > I think we have to be very > careful with that. The discussion on "VPLS model for > L2VPN Framework" that is currently going on on the > PPVPN mailing list shows how tricky it is to > correctly map IEEE bridging models. Yes, has all the hallmarks of being as much fun as GMPLS ;-) > I believe that > Ethernet OAM should be defined by the IEEE. EFM is, I have to investigate how generalized it is though. However, there is a lot of Ethernet out there already. > Making > some short-cuts using PW OAM may lead to big > problems later. Not making them may lead to some people's careers being terminated sooner ;-) And I am not just talking about at vendors, I am talking about operators as well. Seriously, I have not seen a comprehensive conversation yet which follows the line of...this is the short-term problem, this is the long-term problem, if we do it this way, we can evolve in the following way. May be it is not possible, and perhaps that is too idealistic. > In your email you wrote >> A criticism of the PWE > OAM approach is that it > generates messages regardless of whether a fault > exist or not, which some see as being at variance to > typical/desired OAM behavior. << I'll have to try and dig it up. One of the posts made the comment that an OAM mechanism should only produce events if it detects a fault, whereas LSP Ping does on every occassion. Though not explicitly stated, I think the essential inference was that there is a difference between a break-fix diagnostic tool, and an integrated OAM mechanism. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 13:10:33 +0100 Lines: 443 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 30 14:13:40 2003 Return-path: To: busschbach@lucent.com, mark@mseery.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Peter......agree with all of your comments....few small remarks however in-line. regards, Neil Peter B wrote 29 May 2003 23:02 > I agree with many of the points that you raise. However, > there is one issue that keeps bothering me whenever we > discuss Y.1711 and LSP Ping, which you bring up in your email > as well. It is the notion that Y.1711 requires to a lot of > processing whereas LSP Ping does not. > > According to Y.1711, Connection Verification messages are > sent at a rate of one packet per second, but "other > configurable CV generation rates are for further study". NH=> The only reason CV rates are 'fixed' at a 1/s default is to ensure consistency of defect entry/exit criteria and consquent actions, and set a sensible/pragmatic period over which defects are detected (and subsequently cleared). One does not want too fast a reaction (else inapproriate actions may result, eg unecessary prot-sw on error bursts) nor does one want too slow a reaction. This also has consequences for consistent SLA specifications (of availability and performance metrics) and vendor/operator interworking. However, if one does not wish such consistency one can change the CV rate. One word of warning however: If you have different CV rates on different LSPs in the same network it can lead to odd behaviour. For example, consider 1 LSP with a 1/sec CV rate and another with a 1/min CV rate. If the 'slow' CV LSP leaks into the 'normal' CV LSP then it will cause the following cycle of events: - detection of dmismerge at t=3s (and take consequent actions, eg suppress traffic, issue FDI to client layers, etc); - dmismerge cleared at t=6s (remove all consequent actions) - re-detection of dmismerge at t=63s - etc This may also have some implications on protection switching (if revertive in a period less than the 'slow' rate). > > Let's assume that the CV generation rate is configurable. The > rate required by a Service Provider depends on the client > service (e.g. VPLS probably doesn't require frequent CV), the > architecture of the MLS network (e.g. can fault detection be > done at a lower layer of MPLS pipes, thus reducing the number > of connections that need to be monitored), etc. > > For the purposes of specifying OAM for PWE3, I don't think > there is any reason to require that the generation rate of > Y.1711 CV messages is necessarily higher than the generation > rate of LSP Ping messages. > > Comparing Y.1711 and LSP Ping, I see one big difference: With > LSP Ping, if a PE doesn't receive a reply, it doesn't know > what the problem is. It is possible that the PW is down, but > it is also possible that the return path is unavailable. In > Y.1711, upstream and downstream PEs work in tandem and it is > the downstream PE that determines that the link is down. NH=> Correct. Defect detection/handling must be unidirectional. > > To me it seems evident that the fault detection mechanism > defined in Y.1711 is superior to that of LSP Ping, no matter > what Tom's 25 happy customers say. NH=> I don't think Tom was discussing PWs with those customers (but he can correct me if I am wrong). I assume BT is one of these and when he came to see us the key topic was fault management of rfc2547 VPNs when a LDP mp2p server layer is used. LSP-Ping (or something like this) seems a necessary consequence of doing mp2p......but we can also do rfc2547 over IP and don't need LSP-Ping in that case. Architecturally speaking, if one wants an any-any behaviour than use the proper cnls mode for this. Conversely, if one want hard/measurable SLAs then a co pkt-sw mode using p2p constructs is required. These 2 cases also apply to X/IP and X/MPLS relationships ......there is not reason at all (except for dogma) why they should be treated the same. Its horses for courses. Y.1711 is all about optimised defect detection/handling in the topologies that make sense using a co pkt-sw forwarding mode. Its about as simple/sparse yet powerful as you can get and we are getting a bit hacked off when misinformation is given about this. When one considers service-interworking the PWs can't exist. I would imagine all large operators like BT have the same issue of migrating their FR/ATM network services to a common co pkt-sw core. If this core is to be MPLS then we want a form of MPLS that will suit this and we need service-interworking. So given PWs can't exist with edge conversion service-interworking then its high time people realised what was required here. > > So what exactly is the problem with adopting Y.1711 for PW > OAM, as long as we speciify that the CV generation rate is > configurable? This would not require any vendor to implement > the function in ASICs or provide some other form of HW acceleration. NH=> Sure you can do this (that is the whole point of the *same mode* functional convergence argument that one can use a best-of-breed solution in all cases where it is appropriate). I wrote Y.1711 to be generic for any p2p co pkt-sw case. However, I must point out that a PW is not a layer network (ie it is not switched/routed) and so is quite different to MPLS. Further, since one has to manage the MPLS network anyway then do it right from the off. Finally, with service-interworking PWs disappear and the need to native interwork the X and MPLS layer networks becomes very obvious.....solutions are already drafted for ATM/MPLS interworking in Y.17iw > > Peter > > > > -----Original Message----- > > From: Mark Seery [mailto:mark@mseery.com] > > Sent: Tuesday, May 27, 2003 10:00 PM > > To: David Allan > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > Dave, > > > > The first batch of questions in my previous response > > was to try and flush out the fact that this effort is > > trying to meet the needs of a wide range of service > > providers with different mindsets and business models; > > including stand-alone ISPs, ISPs within a carrier, > > carriers upgrading ATM networks to MPLS, carriers > > building new MPLS networks for Ethernet, etc. > > > > From this flows two distinct categories of conflict: > > > > 1) What can be implemented in existing equipment > > 2) The operations culture variance among different SPs > > > > Quoting from draft-allan-y1711-and-lsp-ping: > > > > "LSP-PING is designed to be retrofitted to existing > > deployed networks....." > > "Y.1711 depends on some degree of ubiquitous > > deployment at the edge to maximize coverage of fault > > detection" > > > > These two comments alone lead to various substantial > > inferences: 1) That LSP-PING can be used with existing > > installed equipment and that other approaches may not > > be optimized for that purpose and b) substantial > > benefits may only accrue via Y.1711 if there is > > ubiquity of deployment. So perhaps my previous > > comments were badly worded if they implied that the > > entire network needs to be replaced, but clearly there > > is an existing assets issue here. The accomodation of > > existing equipment and network evolution is not > > without precedent, as an example I would cite the DSL > > Forum's working text 81 (WT81) which proposes > > significant capability increase to the network, but > > clearly accomodates the presence of existing DSLAMs by > > the creation of a new gateway function. > > > > With respect to your comment that this functionality > > is easily assumed into silicon, I'd like to first make > > the flipant remark that a few gates here, and a few > > gates there, and all of a sudden we are talking > > serious silicon; or rather if you take one approach as > > a whole and compare it to another approach as a whole, > > on aggregate there may be significant differences. I > > would also observe that packet processing remains bit > > for bit significantly more expensive (in terms of > > power at least) than TDM processing, so the packet > > processing industry's goal as a whole should be > > further reduction, and that additional processing > > should be examined skeptically. This may be the wrong > > place to cut back on, but there should be a general > > intent to cut back on processing, (including the > > unnecessary adding of new layers - I am not one sided > > on this issue), where possible, and therefore we > > should not assume that adding functionality to silicon > > has no impact, we should justify the addition. > > > > Specifically, say my PE supports 10,000 LSPs. Now the > > design has to allow for the possibility of 10,000 OAMs > > per second (depending on the network architecture, > > many of them may be on the same interface). Each of > > these OAMs requires a BIP calculation (simple logic to > > be sure) in addition to what ever OAM processing is > > required. The OAMs might be occurring on multiple > > stack levels (3 or more) concurrently - so how is this > > impacting my pipeline? Now say there is a fault. In > > the midst of a network error I am now creating > > additional processing in the form of FDI flows at > > 1/sec. (perhaps even BDI, but most LSPs are > > unidirectional....). So at the worst time, during a > > fault, I am throwing even more processing in to the > > user plane - a tractable issue (but actually an > > interesting debate is to be had here about avoiding > > non-linearality - yes I know, alarm storms could > > create another type), but has to be allowed for in the > > design. I do not say this to criticize Y.1711, I think > > it is essential functionality for a certain type of > > carrier, seeking to achieve certain goals - my only > > point is that it is not clear cut to me that the > > addition of OAM (especially for a multi-level stack of > > indefinite depth) is painless and with out need for > > tradeoffs in the packet processing pipeline (you can > > do what early ATM implementations did and shunt > > everything off to an adjunct processor, but that has > > its own costs and complications). What would be really > > useful is to actually have a digital logic expert > > present on this issue - otherwise it is just opinions > > and there is no actual engineering going on. > > > > Now it is perfectly OK to implement such functionality > > if it is highly valued by the prospective customer, > > but it is clear that this a heterogeneous market place > > - which is the crux of why we struggle to come to > > consensus in areas such as this. I can well imagine it > > being hard to go to some ISPs and justify why it was > > implemented when it will never be used. I can just as > > easily imagine (in fact I know) that it would be > > equally hard to go to some carriers and justify why it > > was not implemented when it would be constantly used. > > > > Where the process broke down, from my position on the > > sideline in the cheap seats , was a) we as a group had > > a learning process about how we thought of MPLS-LDP, > > i.e. CO, CNLS,....and that created a lot of > > communication problems with respect to getting down to > > the real meat of the issues and really understanding > > the requirements (still today some people think of > > MPLS-LDP as CO when clearly this is a really grey > > area) b) while the IETF community understood > > intuitively the kind of solution that was appropriate > > to the CNLS networks of traditional target customers > > (LSP-PING) and also for IP-VPN networks (an area which > > I think it might be slightly stronger in, in some > > non-trail/tunnel respects, when compared to Y.1711), > > it was slower to understand the kind of solution that > > was required for a carrier-class, robust SLA, CO > > network - which based on experience is actually to be > > expected. This may have been manifested in the > > vilification of Y.1711 as the grand drama of > > competitive approaches and lack of understanding > > played out, but hopefully this can be acknowledged and > > we can move on from here. > > > > Ultimately there has to be some decision point (either > > consciously or unconciously) by the IESG about whether > > we really want to merge the standards setting process > > for carriers, ISPs, and enterprises + CO and CNLS in > > to one standards group; and if so, how are we going to > > improve our sophistication about "signaling" what > > proposal addresses what end user and what network > > mode. > > What I personally would like to see is as much > > possible identification of commanility, leading to as > > much possible reuse of PDU structures across different > > (or subset/superset) implementations. This I think is > > the larger tragedy that gets forgotten in the day to > > day banter (in multiple WGs). > > > > A good engineering process would, IMHO, acknowledge > > the implications for existing equipment, acknowledge > > where we want to be in the long run, and build a > > roadmap to get from here to there that allows for > > graceful evolution. This is perhaps where the mantra > > of "one solution" may break down if we are not careful > > (and that is not even including the issues stated > > above WRT to different audiences and network modes). > > Some specific comments on some snips below. > > > > Thanks, > > Mark > > > > > 4) I assume the implied suggestion is that any > > > centralized push/polling mechanism is not scalable, > > so > > > it can not be the long-term solution? In other > > words, > > > the method of invocation is kind of orthogonal as > > long > > > as the OAM function is doing what it needs to do; > > the > > > only remaining issue is whether the method of > > > innvocation has some fundamental flaws. > > > > >>Not as much the method of invocation, it is a > > combination of attributes: how determinitic testing > > is, whether a fault will turn up in multiple diverse > > places and how that is correlated such that the most > > frugal response is possible, can responding be > > delegated into the network etc.etc. << > > > > MS=> so now we are adding even more complexity to the > > network element - delegated responding. So clearly two > > different classes of equipment are emerging with > > diverging paths, and diverging customer bases - how to > > we accomodate this is one standards process? > > > > > Could you be more explicit about the feedback you > > are > > > receiving. Is it related to the use of central > > management tools? > > > > >> The feedback is a mix depending on where the > > carrier is using MPLS now and the experience they've > > had, and how they envision using it in the future. << > > > > MS=> I understand the difficulty in answering the > > question. Hopefully you understand my difficulty in > > understanding the problem within a void of some > > characterization of it. > > > > > I think the answer is no. And I state this only in a > > > > > hope that we can reach some level of consensus > > before > > > continuing the logic tree. > > > > >>Some potential counterpoints are: > > > > 1) lots more code driving the label swapping > > configuration and with higher frequency. As a > > counterpoint, in an ATM PVC network, the cross connect > > table is only touched when there is a provisioning > > change. Even in an SVC network, a routing change > > frequently may not change the forwarding state of the > > switch. << > > > > MS=> Fair enough. > > > > >> 2) MPLS has a label stack, so there is an extra > > dimension to things that can go wrong. << > > > > MS=> Yes, in all forms of processing. > > > > >> 3) MPLS originally assumed it would exist in a > > hybrid IP network......<< > > > > MS=> Has this changed (in the IETF)? > > > > >> As far as LDP is concerned, the only question in my > > mind is what is an appropriate response to the > > additional modes of failure << > > > > MS=> agreed > > > > >> when considering the potential frequency. << > > > > MS=> so given that LDP has been deployed, are we > > actually seeing these types of errors with any > > "greater" frequency. If the label mis-swap problem has > > to be solved for any label swapping network that is > > fine, but are we proposing something different than we > > would for say ATM because of an assumed > > greater/potential frequency? > > > > >> Throw in the label stack as well and what you need > > is somthing ubiquitous as the problem may not occur > > uniquely in the LDP layer. << > > > > MS=>I assume you mean that the user plane may not be > > carrying IP, if not then I didn't understand the > > comment. > > > > > So even though the answer is no, it is as you say a > > > problem that other CNLS networks do not have to deal > > > > > with, and therefore a problem to which a solution is > > > > > required. I can envision two possible solutions: 1) > > a > > > P2P overlay 2) OAM messages that have the source > > > address embedded in them (this would need to be an > > > interface/sub-interface address as opposed to a LSR > > > identifier is my guess). To me, option 2) is > > preferable - > > > what is wrong with this approach? > > > > >> A p2p overlay is a solution, but if used in > > isolation, you have the problem that an LDP problem > > spills a lot of overlay p2p LSPs, therefore who owns > > the problem. IMHO the LDP layer needs a bit of help in > > this regard. > > As for '2', an access point ID is the basis of the > > villified TTSI in Y.1711. << > > > > MS=> I don't remember why the TTSI was villified > > (though it does look like the tunnel construct is not > > applicable to LDP) > > > > >> It is straightforward for p2p but requires the > > egress to track many access points for mp2p. For mp2p > > we're working on y.17fec-cv (SG13) where the FEC info > > is encoded in the probe and that is what is checked. > > << > > > > MS=> I couldn't see this on the ITU website, could you > > or someone else shoot me a copy, would be interested > > in taking a look, specifically at the TTSI. > > > > > > > > > > > > > On the CO dimension of MPLS, it strikes me that > > there > > > is no RSVP-TE solution for PWE - is this correct and > > > > > should this be so? > > > > >> Technically an RSVP-TE LSP could carry a PW > > directly (it does have a PID exchanged in one of the > > objects) and not as an LDP overlay. So I'm unaware of > > anything that precludes this option. << > > > > MS=> I only raise this issue to ask the question that > > if a CO mode is required, why is there not more > > RSVP-TE based proposals for both PWE and VPLS? Clearly > > RSVP-TE based implementation is possible. > > > > > > On the issue of fault correlation, as this is > > > inherently a multi-layer problem, can this be solved > > > > > within the standards process for one layer. i.e. > > what > > > can be done without looking at the top to bottom > > > solution? > > > > >> You phrase the problem strangely. << > > > > MS=> Agreed, and thanks for the explanation. > > > > > >> So I would tend to characterize the debate as > > > between those interesting in doing their perception > > of > > > the "right thing" where the criteria of "rightness" > > is > > > not necessarily aligned ;-) << > > > > > > So then you agree that both parties have good > > > intentions to do the right thing ;-) Then it is just > > a > > > matter of people of good will....... ;-) > > > > >> There's a few subtleties still to be addressed ;-) > > << > > > > MS=> :-)) > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 13:10:27 +0100 Lines: 381 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Fri May 30 14:14:52 2003 Return-path: To: mark@mseery.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Mark, comments in-line. regards, Neil >Mark Seery wrote 29 May 2003 21:13 > Felt it might be useful to summarize some of the > issues/thoughts raised on this thread. NH=> A good idea. > > Mark > > The thread started with an observance that is easy for > a protocol NH=> What do you mean by a 'protocol'? There are 'protocols' that are layer networks and there are those that are not. Any 'protocol' that can be switched/routed at the native protocol level must be a layer network.......the converse also holds, ie a protocol that only exists at 2 source/sinks points (eg UDP, TCP, AAL, PW, GFP, etc) is not a layer network. This has some very significant architectural ramifications wrt what is right/wrong. > to creep from an in-between layer to a full > layer, siting the history of MPLS that was first > proposed as a simple shim; it was further noted that > when this occurs then formal treatment to control and > management is required. The inference then is that we > as a group should be concerned about actions we take > which make lead us down the road of developing a new > layer. NH=> MPLS can be switched/routed and so must be a layer network...PWs can't be switched/routed (AKAIK) and so are not a layer network. Being a layer network has consequences that may not be palatable but are nevertheless true, eg MPLS requires its own access point addresing scheme. It does indeed get this (simply because it has to) but its *different* for each signalling type used (which is really bad, since addresses belong to the data-plane and not the protocols of the control-plane that distribute and act on them....and they also should be signalling protocol agnostic). Further, the MPLS access point addresses do *not* belong to the IP address space (or any other client address space for that matter). There is more to a layer network than just addressing of course. > > Issue 1. Is it the intention that PWE be just an > adaptation function? > > The suggestion was then made that if we stick to > network interworking any client OAM/PWE OAM can be > carried transparently. NH=> This is not a suggestion, it is a requirement. Think about all the layer networks to the duct that have a recusive clinet/server relationship.......client transparency is invariably taken for granted. If one starts tinkering with the client (ie to save a bit of BW or whatever) then beware. And remember that quite often a given operating entity will *not* own all the layers to the duct, and so may lease these.....in that case the operating entity will be expecting transparency. A further observation here is that amongst the 3 networking modes some client/server relationships make more sense than others. This is simply an expectancy of the normal performance a given client layer would get if it's nodes were interconnected by L1 co cct-sw trails. Of course one can deviate from this, but again one should be aware of the consequences to avoid doing stupid things.....for example trying to carry an SDH STM-N signal over IP does not seem very sensible to me. > Further, it was suggested that > service interworking could be avoided by doing > protocol translations either side of the PWE core, and > thereby creating a like-to-like service, end-to-end. NH=> Service interworking *is* protocol translation....across all functions of the data and control planes that require conversion. So I am not sure I grasp your point. More generally however, PWs are an adaptation function.....that is quite clear to me. But what really fazes me is *why* some want to pretend that IP=~MPLS? If IP=MPLS then why bother with MPLS at all? I can only assume its based on a desire *not* to allow MPLS to be seen as a layer network in its own right. I can actually understand why some might hold this view for commercial or political reasons, but doing so does not 'make it right' or beneficial to our industry at large. MPLS uses a co pkt-sw fowarding mode that is patently clear.....and we ought to use that behavior to advantage. The spoilier here is LDP mp2p....this is actually the cause of nearly all the problems simply because its a topological misuse of a co pkt-sw forwarding mode.....if one wants any-any behaviour one should use a proper cnls mode like IP (or maybe ethernet.....though this has its own problems because it does not have proper addressing (semantic of 'where') and no proper routing). > > Issue 2. Can service interworking be avoided by > translations either side of PWE? NH=> Not sure what you mean by this. In any case *why* would one want to avoid service-interworking given it's really important? It makes a great deal of sense to us to drive down opex/capex by requiring that technologies which belong to the *same* network mode should have edge conversion to a common target technology for that mode. Is this not simply common-sense? If IETF cannot see the logic in this for whatever reason then they really ought to stop playing in the co pkt-sw and co cct-sw space. > Issue 3. Is service interworking in or out of scope? NH=> I can really understand why some people would regard this as 'out of scope'. This view must be held by those who wish to constrain MPLS to a role of IP-helper only. But this is not a logical/rational view. If IETF believe MPLS is nothing more that an IP-helper they should not sanction PWE3 activities for arbitrary non-IP clients nor should they sanction GMPLS activities...seems some want to have to their cake and (mistr)eat it. > > The still debated OAM issues leaked in to this thread > (in fact were the original genesis of the thread) with > a number of people supporting the view that the server > layer (MPLS) requires OAM in order to support network > interworking. Some stated that in the absence of MPLS > OAM, PWE OAM would be required, but that it was not > the preferred path. NH=> I wish *all* engineers who participate in any stds work were forced to take a course in layered networks and understood G.805....if they did so much of the nonsense I read/see would be avoided. MPLS is a layer network (though its not well specified as such) and PWs are not a layer network....though they are now being imbued with 'functions' to cater for poor functional architecture in MPLS (specifically the effects of mp2p LSPs). However, this issue (ie layer network functional components, where OAM is simply one of these) is not specific to MPLS.....it applies to all technologies that aspire to be used as layer networks. When a technology is functionally deficient problems arise when that technology is used in a more general layer network sense......just look at the issues ethernet is generating. Ethernet is functionally deficient in many aspects from a general layer network perspective, but especially addressing and routing. > > Issue 4. Is it essential for the IETF to provide the > kind of MPLS OAM that is desired (or can another > standards body provide this)? NH=> No of course not. But the more relevant question IMO is 'why are IETF working on co pkt-sw and co cct-sw technologies when they don't understand layered networks, won't use functional modelling techniques and refuse to use protocols that they don't own/control (when some are clearly not best of breed)'. > > The problem with adapting a common mechanism to > different PSN types is that each PSN has different > capabilities. NH=> Exactly so....each network mode (cnls, co pkt-sw and co cct-sw) has specific behaviours that are really important. We need them all. We want solutions that bring the modes together in the *right* way. So MPLS is different to IP. SDH is different to MPLS and IP. Those people who started off pushing the GMPLS peer-model stuff have a lot to answer for IMO. I am amazed how many people were (are still?) taken-in by this nonsense. > So it has been observed that if neither > the client layer (Ethernet) or the server/PSN (IP or > MPLS) has OAM, then there is a problem. It has been > further observed that the correct fix is to fix each > layer independently. The obvious attraction of the PWE > OAM approach is quick time to market with one > mechanism. NH=> Or is this 'marry in haste and repent at leisure'? Being quick to market is 1 thing but this does not imply being stupid too......bad solutions have a longer-term opex hit. Once established, WAN technologiues tend to have a 25 year lifetime > Various opinions have been expressed as to > the architectural downsides of this approach. NH=> We don't mind people doing crazy things. What we do object to however is trying to force those same stupid things on the whole community and not allowing an alternative set of solutions to be produced. > > Issue 5. Is it conceivable to think of PWE OAM as an > extension to the client layer for the network > interworking case? NH=> It's not sufficient. It only exists at the 2 end points......you still have to manage the real layer network inbetween. > Issue 6. Is it conceivable to think of PWE OAM as a > not required extension for the cleint layer for the > service interworking case? NH=> I don't understand this. PWs can't exist in service interworking.....the 2 normally disjoint points of the PW (in the client/server case) are now effectively co-located at the point of interworking, ie the PW vanishes! > > The issue of how many layes of the stack does OAM need > to be performed at arose. NH=> Its not an issue......all leayers need their own OAM independently. This is not something we should even be discussing, its an obvious requirement. > It was mentioned "..fault > management is most frugally performed at the transport > layer although it must also exist to some degree at > the PW layer. Performance management hits both as > well, network planners need the transport > measurements, and SLA reporting needs the PW > measurements. " NH=> So what? If a node fails at layer N all lower layers *must* be blissfully unaware of this. > > But in an MPLS network with "n" layers, which is the > layer that is considered transport, and which is the > layer that SLA needs to be performed on. For example, > take a network that has a label for restoration, a > label for traffic engineering, a label for PE-PE, a > label for each VPN, and PWE. Which of these "layers" > is OAM required on? NH=> All of them independently. Marteen Vissers and my colleague Alan McGuire who are both well respected experts in functional modelling are developing the right functional models for MPLS right now. So this activity is well in-hand. > This many layers above the > facility layer is a new capability in networks, NH=> Dealing with multiple layered networks is not new (see how many there are in SDH), the novel feature of MPLS is that is has no fixed hierarchy....its a true digital wrapper. But we do know how to model it and the required work is already well underway as noted above. > so hwo > do we think about it? NH=> I can recommend a good book written by my colleague Andy Reid. The answer lies in taking the right architectural approach to describing layered networks. This has proved immensely useful as a precursor activity to ensuring smoother vendor interworking, developing management models and stopping people doing stupid things.....open-minded IETFers should try and embrace this stuff. It was not done just for the sake of it...it has real value. > It was also mentioned that when > e2e mechanisms are overlayed, the problem becomes not > one of fault correction, but fault correlation - so > does fault correlation become too complex with this > many layers? NH=> No, providing one uses the right approach quite the opposite is true. It will become very complex however if you don't. > > Issue 7. Is OAM required on every layer? NH=> Ideally yes. But there are different levels of monitoring that can be used. Further the source generation and sink processing operations can be decoupled (see Appendix I of Y.1711). > Issue 8: Are there different OAM requirements at > different layers - and if so, does this problem become > too complex? NH=> I think the question is wrongly phrased...if you are discussing MPLS. The right observation here is that the OAM for a cnls mode is different to the OAM for a co pkt-sw mode and is different to the OAM for a co cct-sw mode. However, within *each* mode there is an optimal best-of-breed solution that *all* technologies belonging to that mode should use.....Y.1711 is an optimal (sparse/poweful) solution for all technologies belonging to the co pkt-sw mode (when that mode is correctly used of course). > > Issue 9: Is it possible that PWE OAM is a good > SLA-level mechanism but other transport-level OAMs may > be needed/optional? NH=> So we are offering PWs as services are we? In that case is anyone ever going to define the currently open-ended issue of entry/exit defect criteria for sequence number aberrations and the consequent actions then? > > Some disagreement occurred over whether LSP ping was > too heavy weight to do periodic connectivity > verification, with the later suggestion that much of > the discussion on the list focused in connectivity > verification rather than alarm indication suppression. NH=> LSP-Ping is a necessary, albeit complex, fix for mp2p LSPs. However, its hardly a 'always-on' defect detection/handling tool......in fact no defects have even been defined for mp2p constructs. Might make sense to start there I think (but I can sure understand why this has not been done)! > > Issue 10. Is PWE OAM too heavy weight for alarm > indication/suppression or connectivity verification; NH=> This is not the issue. The simple fact it is unecessary and can't exist anyway with service-interworking. > and if so why, and is there any evidence of this? > A criticism of the PWE OAM approach is that it > generates messages regardless of whether a fault exist > or not, which some see as being at variance to > typical/desired OAM behavior. NH=> Not sure I understand. You have to generate some form of 'hello' to detect failures. Sending notifications only post failure makes no sense.....esp if the data-plane used to send such notifications is broken. Further, how does one detect misconfiguration/misbranching detects? > > Issue 11. Should PWE OAM have an option to suppress > outputs? NH=> No.....it should not be *optional*. Under certain failure cases the traffic must be supressed. > > The thread is winding down with discussion on the > difficulties of a generalized approach as MPLS injects > link swapping fault modes into what otherwise might be > considered a CNLS network; NH=> I don't agree MPLS gives a cnls network. mp2p attempts to mimic the cnls behaviour but can't, viz: cnls *multiplexes* pkts, mp2p *merges* pkts....these actions are not the same, which is why one is forced to always run a higher level of p2p LSP to identify the source uniquely for an arbitrary client layer above MPLS. A whole raft of problems and kludges stem from this. > whether a P2P overlay is > ineeded needed to achieve OAM (to overcome MP2P merge) > vs just using OAM messages that indicate source (and > it seems to me both LSP-PING and Y.1711 can). NH=> If we have to run p2p LSPs then use Y.1711 on these....why add yet further functions higher up. We can now do service-interworking (with ATM say) very easily. In fact its already defined in Y.17iw. > > Personal observations: > > -With the exception that there was disagreement about > whether mode swaps would prevent clock recovery, there > was general agreement that PWE over both MPLS and IP > can work > -PWE OAM appears to me to be rooted in concepts of SLA > management (vis-a-vis FR OAM was used as a model). > -Other transport OAM mechanisms should be available to > operators as an option (potentially developed by other > standards bodies if the IETF wants to pass on this > work). > -The terms CNLS and CO can be limiting. For example, > LDP is clearly CNLS in many respects, but because of > the label swap forwarding elelement, it introduces > fault modes that would normally be associated with CO > networks, and because of the semantics of the user > plane (i.e. no source address) it has restrictions > that would normally be associated with a CO network. > Therefore, it is my conclusion that LDP-MPLS is a > hybrid CO-CNLS mode; and clarity in discussion can be > achieved by referring specifically to the > characteristic that is at issue, i.e. label swap fault > modes, rather than assuming people understand the > moniker "CO". NH=> If you use G.805 to model mp2p the problems become obvious......ideally before one embarks on letting it loose on an unspecting public. Water under the bridge now.....but the thing is to learn from this. > -Ethernet is a service that SPs have indicated to many > vendors that they want to roll out over a PSN, NH=> Are you sure this is not the other way round, ie we get vendor after vendor trying to flog us this stuff and we are not asking for it? More tellingly, I don't hear customers asking us to build ethernet WANs either......they want to interface to our WANs with ethernet, and how we deliver this over the WAN is a different issue. > and > they want to do it quickly in some cases. Ethernet is > defficient in a numer of ways, not the least of which > is a standardized OAM (though since the EFM is working > on one, it may be forthcoming). If we can use PWE OAM > as a client-layer psuedo OAM, and at the same time > bound the problems this causes and comit not to being > here in three years discussing Diffserv for PWE ;-) > then it could be a win-win for many people. > > Issues summary > ============ > > Issue 1. Is it the intention that PWE be just an > adaptation function? > Issue 2. Can service interworking be avoided by > translations either side of PWE? > Issue 3. Is service interworking in or out of scope? > Issue 4. Is it essential for the IETF to provide the > kind of MPLS OAM that is desired (or can another > standards body provide this)? > Issue 5. Is it conceivable to think of PWE OAM as an > extension to the client layer for the network > interworking case? > Issue 6. Is it conceivable to think of PWE OAM as a > not required extension for the cleint layer for the > service interworking case? > Issue 7. Is OAM required on every layer? > Issue 8: Are there different OAM requirements at > different layers - and if so, does this problem become > too complex? > Issue 9: Is it possible that PWE OAM is a good > SLA-level mechanism but other transport-level OAMs may > be needed/optional? > Issue 10. Is PWE OAM too heavy weight for alarm > indication/suppression or connectivity verification; > and if so why, and is there any evidence of this? > Issue 11. Should PWE OAM have an option to suppress > message output? > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 07:26:44 -0500 Lines: 500 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6902@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Fri May 30 14:29:43 2003 Return-path: To: , , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6902@i2km07-ukbr.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by uswgco34.uswest.com id h4UCQlLE001316 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UCR0B29784 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UCVMB29925 Status: O I think it is important to distinguish between an OAM Loopback and OAM Continuity Check (CC). The OAM CC is a continuous stream once per second. The OAM Loopback can = be a single request. The OAM Loopback provides much benefit and does not require a lot of resources. Utilization of the Loopback Location ID provides the ability to determine dynamic topology which is also very use= ful for a carrier. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > neil.2.harrison@bt.com > Sent: Friday, May 30, 2003 7:11 AM > To: busschbach@lucent.com; mark@mseery.com; dallan@nortelnetworks.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > Hi Peter......agree with all of your comments....few small remarks howe= ver > in-line. regards, Neil > > Peter B wrote 29 May 2003 23:02 > > I agree with many of the points that you raise. However, > > there is one issue that keeps bothering me whenever we > > discuss Y.1711 and LSP Ping, which you bring up in your email > > as well. It is the notion that Y.1711 requires to a lot of > > processing whereas LSP Ping does not. > > > > According to Y.1711, Connection Verification messages are > > sent at a rate of one packet per second, but "other > > configurable CV generation rates are for further study". > NH=3D> The only reason CV rates are 'fixed' at a 1/s default is to ensu= re > consistency of defect entry/exit criteria and consquent actions, and se= t a > sensible/pragmatic period over which defects are detected (and > subsequently > cleared). One does not want too fast a reaction (else > inapproriate actions > may result, eg unecessary prot-sw on error bursts) nor does one want to= o > slow a reaction. This also has consequences for consistent SLA > specifications (of availability and performance metrics) and > vendor/operator > interworking. However, if one does not wish such consistency one > can change > the CV rate. One word of warning however: If you have different CV ra= tes > on different LSPs in the same network it can lead to odd behaviour. Fo= r > example, consider 1 LSP with a 1/sec CV rate and another with a 1/min C= V > rate. If the 'slow' CV LSP leaks into the 'normal' CV LSP then it will > cause the following cycle of events: > - detection of dmismerge at t=3D3s (and take consequent actions, eg > suppress traffic, issue FDI to client layers, etc); > - dmismerge cleared at t=3D6s (remove all consequent actions) > - re-detection of dmismerge at t=3D63s > - etc > This may also have some implications on protection switching (if revert= ive > in a period less than the 'slow' rate). > > > > Let's assume that the CV generation rate is configurable. The > > rate required by a Service Provider depends on the client > > service (e.g. VPLS probably doesn't require frequent CV), the > > architecture of the MLS network (e.g. can fault detection be > > done at a lower layer of MPLS pipes, thus reducing the number > > of connections that need to be monitored), etc. > > > > For the purposes of specifying OAM for PWE3, I don't think > > there is any reason to require that the generation rate of > > Y.1711 CV messages is necessarily higher than the generation > > rate of LSP Ping messages. > > > > Comparing Y.1711 and LSP Ping, I see one big difference: With > > LSP Ping, if a PE doesn't receive a reply, it doesn't know > > what the problem is. It is possible that the PW is down, but > > it is also possible that the return path is unavailable. In > > Y.1711, upstream and downstream PEs work in tandem and it is > > the downstream PE that determines that the link is down. > NH=3D> Correct. Defect detection/handling must be unidirectional. > > > > To me it seems evident that the fault detection mechanism > > defined in Y.1711 is superior to that of LSP Ping, no matter > > what Tom's 25 happy customers say. > NH=3D> I don't think Tom was discussing PWs with those customers (but h= e can > correct me if I am wrong). I assume BT is one of these and when > he came to > see us the key topic was fault management of rfc2547 VPNs when a LDP mp= 2p > server layer is used. LSP-Ping (or something like this) seems a necess= ary > consequence of doing mp2p......but we can also do rfc2547 over IP > and don't > need LSP-Ping in that case. Architecturally speaking, if one wants an > any-any behaviour than use the proper cnls mode for this. Conversely, = if > one want hard/measurable SLAs then a co pkt-sw mode using p2p > constructs is > required. These 2 cases also apply to X/IP and X/MPLS relationships > ......there is not reason at all (except for dogma) why they should be > treated the same. Its horses for courses. > > Y.1711 is all about optimised defect detection/handling in the topologi= es > that make sense using a co pkt-sw forwarding mode. Its about as > simple/sparse yet powerful as you can get and we are getting a bit hack= ed > off when misinformation is given about this. When one considers > service-interworking the PWs can't exist. I would imagine all large > operators like BT have the same issue of migrating their FR/ATM network > services to a common co pkt-sw core. If this core is to be MPLS then w= e > want a form of MPLS that will suit this and we need service-interworkin= g. > So given PWs can't exist with edge conversion > service-interworking then its > high time people realised what was required here. > > > > So what exactly is the problem with adopting Y.1711 for PW > > OAM, as long as we speciify that the CV generation rate is > > configurable? This would not require any vendor to implement > > the function in ASICs or provide some other form of HW acceleration. > NH=3D> Sure you can do this (that is the whole point of the *same mode* > functional convergence argument that one can use a best-of-breed > solution in > all cases where it is appropriate). I wrote Y.1711 to be generic for a= ny > p2p co pkt-sw case. However, I must point out that a PW is not a layer > network (ie it is not switched/routed) and so is quite different to MPL= S. > Further, since one has to manage the MPLS network anyway then do it rig= ht > from the off. Finally, with service-interworking PWs disappear > and the need > to native interwork the X and MPLS layer networks becomes very > obvious.....solutions are already drafted for ATM/MPLS interworking in > Y.17iw > > > > Peter > > > > > > > -----Original Message----- > > > From: Mark Seery [mailto:mark@mseery.com] > > > Sent: Tuesday, May 27, 2003 10:00 PM > > > To: David Allan > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > Dave, > > > > > > The first batch of questions in my previous response > > > was to try and flush out the fact that this effort is > > > trying to meet the needs of a wide range of service > > > providers with different mindsets and business models; > > > including stand-alone ISPs, ISPs within a carrier, > > > carriers upgrading ATM networks to MPLS, carriers > > > building new MPLS networks for Ethernet, etc. > > > > > > From this flows two distinct categories of conflict: > > > > > > 1) What can be implemented in existing equipment > > > 2) The operations culture variance among different SPs > > > > > > Quoting from draft-allan-y1711-and-lsp-ping: > > > > > > "LSP-PING is designed to be retrofitted to existing > > > deployed networks....." > > > "Y.1711 depends on some degree of ubiquitous > > > deployment at the edge to maximize coverage of fault > > > detection" > > > > > > These two comments alone lead to various substantial > > > inferences: 1) That LSP-PING can be used with existing > > > installed equipment and that other approaches may not > > > be optimized for that purpose and b) substantial > > > benefits may only accrue via Y.1711 if there is > > > ubiquity of deployment. So perhaps my previous > > > comments were badly worded if they implied that the > > > entire network needs to be replaced, but clearly there > > > is an existing assets issue here. The accomodation of > > > existing equipment and network evolution is not > > > without precedent, as an example I would cite the DSL > > > Forum's working text 81 (WT81) which proposes > > > significant capability increase to the network, but > > > clearly accomodates the presence of existing DSLAMs by > > > the creation of a new gateway function. > > > > > > With respect to your comment that this functionality > > > is easily assumed into silicon, I'd like to first make > > > the flipant remark that a few gates here, and a few > > > gates there, and all of a sudden we are talking > > > serious silicon; or rather if you take one approach as > > > a whole and compare it to another approach as a whole, > > > on aggregate there may be significant differences. I > > > would also observe that packet processing remains bit > > > for bit significantly more expensive (in terms of > > > power at least) than TDM processing, so the packet > > > processing industry's goal as a whole should be > > > further reduction, and that additional processing > > > should be examined skeptically. This may be the wrong > > > place to cut back on, but there should be a general > > > intent to cut back on processing, (including the > > > unnecessary adding of new layers - I am not one sided > > > on this issue), where possible, and therefore we > > > should not assume that adding functionality to silicon > > > has no impact, we should justify the addition. > > > > > > Specifically, say my PE supports 10,000 LSPs. Now the > > > design has to allow for the possibility of 10,000 OAMs > > > per second (depending on the network architecture, > > > many of them may be on the same interface). Each of > > > these OAMs requires a BIP calculation (simple logic to > > > be sure) in addition to what ever OAM processing is > > > required. The OAMs might be occurring on multiple > > > stack levels (3 or more) concurrently - so how is this > > > impacting my pipeline? Now say there is a fault. In > > > the midst of a network error I am now creating > > > additional processing in the form of FDI flows at > > > 1/sec. (perhaps even BDI, but most LSPs are > > > unidirectional....). So at the worst time, during a > > > fault, I am throwing even more processing in to the > > > user plane - a tractable issue (but actually an > > > interesting debate is to be had here about avoiding > > > non-linearality - yes I know, alarm storms could > > > create another type), but has to be allowed for in the > > > design. I do not say this to criticize Y.1711, I think > > > it is essential functionality for a certain type of > > > carrier, seeking to achieve certain goals - my only > > > point is that it is not clear cut to me that the > > > addition of OAM (especially for a multi-level stack of > > > indefinite depth) is painless and with out need for > > > tradeoffs in the packet processing pipeline (you can > > > do what early ATM implementations did and shunt > > > everything off to an adjunct processor, but that has > > > its own costs and complications). What would be really > > > useful is to actually have a digital logic expert > > > present on this issue - otherwise it is just opinions > > > and there is no actual engineering going on. > > > > > > Now it is perfectly OK to implement such functionality > > > if it is highly valued by the prospective customer, > > > but it is clear that this a heterogeneous market place > > > - which is the crux of why we struggle to come to > > > consensus in areas such as this. I can well imagine it > > > being hard to go to some ISPs and justify why it was > > > implemented when it will never be used. I can just as > > > easily imagine (in fact I know) that it would be > > > equally hard to go to some carriers and justify why it > > > was not implemented when it would be constantly used. > > > > > > Where the process broke down, from my position on the > > > sideline in the cheap seats , was a) we as a group had > > > a learning process about how we thought of MPLS-LDP, > > > i.e. CO, CNLS,....and that created a lot of > > > communication problems with respect to getting down to > > > the real meat of the issues and really understanding > > > the requirements (still today some people think of > > > MPLS-LDP as CO when clearly this is a really grey > > > area) b) while the IETF community understood > > > intuitively the kind of solution that was appropriate > > > to the CNLS networks of traditional target customers > > > (LSP-PING) and also for IP-VPN networks (an area which > > > I think it might be slightly stronger in, in some > > > non-trail/tunnel respects, when compared to Y.1711), > > > it was slower to understand the kind of solution that > > > was required for a carrier-class, robust SLA, CO > > > network - which based on experience is actually to be > > > expected. This may have been manifested in the > > > vilification of Y.1711 as the grand drama of > > > competitive approaches and lack of understanding > > > played out, but hopefully this can be acknowledged and > > > we can move on from here. > > > > > > Ultimately there has to be some decision point (either > > > consciously or unconciously) by the IESG about whether > > > we really want to merge the standards setting process > > > for carriers, ISPs, and enterprises + CO and CNLS in > > > to one standards group; and if so, how are we going to > > > improve our sophistication about "signaling" what > > > proposal addresses what end user and what network > > > mode. > > > What I personally would like to see is as much > > > possible identification of commanility, leading to as > > > much possible reuse of PDU structures across different > > > (or subset/superset) implementations. This I think is > > > the larger tragedy that gets forgotten in the day to > > > day banter (in multiple WGs). > > > > > > A good engineering process would, IMHO, acknowledge > > > the implications for existing equipment, acknowledge > > > where we want to be in the long run, and build a > > > roadmap to get from here to there that allows for > > > graceful evolution. This is perhaps where the mantra > > > of "one solution" may break down if we are not careful > > > (and that is not even including the issues stated > > > above WRT to different audiences and network modes). > > > Some specific comments on some snips below. > > > > > > Thanks, > > > Mark > > > > > > > 4) I assume the implied suggestion is that any > > > > centralized push/polling mechanism is not scalable, > > > so > > > > it can not be the long-term solution? In other > > > words, > > > > the method of invocation is kind of orthogonal as > > > long > > > > as the OAM function is doing what it needs to do; > > > the > > > > only remaining issue is whether the method of > > > > innvocation has some fundamental flaws. > > > > > > >>Not as much the method of invocation, it is a > > > combination of attributes: how determinitic testing > > > is, whether a fault will turn up in multiple diverse > > > places and how that is correlated such that the most > > > frugal response is possible, can responding be > > > delegated into the network etc.etc. << > > > > > > MS=3D> so now we are adding even more complexity to the > > > network element - delegated responding. So clearly two > > > different classes of equipment are emerging with > > > diverging paths, and diverging customer bases - how to > > > we accomodate this is one standards process? > > > > > > > Could you be more explicit about the feedback you > > > are > > > > receiving. Is it related to the use of central > > > management tools? > > > > > > >> The feedback is a mix depending on where the > > > carrier is using MPLS now and the experience they've > > > had, and how they envision using it in the future. << > > > > > > MS=3D> I understand the difficulty in answering the > > > question. Hopefully you understand my difficulty in > > > understanding the problem within a void of some > > > characterization of it. > > > > > > > I think the answer is no. And I state this only in a > > > > > > > hope that we can reach some level of consensus > > > before > > > > continuing the logic tree. > > > > > > >>Some potential counterpoints are: > > > > > > 1) lots more code driving the label swapping > > > configuration and with higher frequency. As a > > > counterpoint, in an ATM PVC network, the cross connect > > > table is only touched when there is a provisioning > > > change. Even in an SVC network, a routing change > > > frequently may not change the forwarding state of the > > > switch. << > > > > > > MS=3D> Fair enough. > > > > > > >> 2) MPLS has a label stack, so there is an extra > > > dimension to things that can go wrong. << > > > > > > MS=3D> Yes, in all forms of processing. > > > > > > >> 3) MPLS originally assumed it would exist in a > > > hybrid IP network......<< > > > > > > MS=3D> Has this changed (in the IETF)? > > > > > > >> As far as LDP is concerned, the only question in my > > > mind is what is an appropriate response to the > > > additional modes of failure << > > > > > > MS=3D> agreed > > > > > > >> when considering the potential frequency. << > > > > > > MS=3D> so given that LDP has been deployed, are we > > > actually seeing these types of errors with any > > > "greater" frequency. If the label mis-swap problem has > > > to be solved for any label swapping network that is > > > fine, but are we proposing something different than we > > > would for say ATM because of an assumed > > > greater/potential frequency? > > > > > > >> Throw in the label stack as well and what you need > > > is somthing ubiquitous as the problem may not occur > > > uniquely in the LDP layer. << > > > > > > MS=3D>I assume you mean that the user plane may not be > > > carrying IP, if not then I didn't understand the > > > comment. > > > > > > > So even though the answer is no, it is as you say a > > > > problem that other CNLS networks do not have to deal > > > > > > > with, and therefore a problem to which a solution is > > > > > > > required. I can envision two possible solutions: 1) > > > a > > > > P2P overlay 2) OAM messages that have the source > > > > address embedded in them (this would need to be an > > > > interface/sub-interface address as opposed to a LSR > > > > identifier is my guess). To me, option 2) is > > > preferable - > > > > what is wrong with this approach? > > > > > > >> A p2p overlay is a solution, but if used in > > > isolation, you have the problem that an LDP problem > > > spills a lot of overlay p2p LSPs, therefore who owns > > > the problem. IMHO the LDP layer needs a bit of help in > > > this regard. > > > As for '2', an access point ID is the basis of the > > > villified TTSI in Y.1711. << > > > > > > MS=3D> I don't remember why the TTSI was villified > > > (though it does look like the tunnel construct is not > > > applicable to LDP) > > > > > > >> It is straightforward for p2p but requires the > > > egress to track many access points for mp2p. For mp2p > > > we're working on y.17fec-cv (SG13) where the FEC info > > > is encoded in the probe and that is what is checked. > > > << > > > > > > MS=3D> I couldn't see this on the ITU website, could you > > > or someone else shoot me a copy, would be interested > > > in taking a look, specifically at the TTSI. > > > > > > > > > > > > > > > > > > On the CO dimension of MPLS, it strikes me that > > > there > > > > is no RSVP-TE solution for PWE - is this correct and > > > > > > > should this be so? > > > > > > >> Technically an RSVP-TE LSP could carry a PW > > > directly (it does have a PID exchanged in one of the > > > objects) and not as an LDP overlay. So I'm unaware of > > > anything that precludes this option. << > > > > > > MS=3D> I only raise this issue to ask the question that > > > if a CO mode is required, why is there not more > > > RSVP-TE based proposals for both PWE and VPLS? Clearly > > > RSVP-TE based implementation is possible. > > > > > > > > On the issue of fault correlation, as this is > > > > inherently a multi-layer problem, can this be solved > > > > > > > within the standards process for one layer. i.e. > > > what > > > > can be done without looking at the top to bottom > > > > solution? > > > > > > >> You phrase the problem strangely. << > > > > > > MS=3D> Agreed, and thanks for the explanation. > > > > > > > >> So I would tend to characterize the debate as > > > > between those interesting in doing their perception > > > of > > > > the "right thing" where the criteria of "rightness" > > > is > > > > not necessarily aligned ;-) << > > > > > > > > So then you agree that both parties have good > > > > intentions to do the right thing ;-) Then it is just > > > a > > > > matter of people of good will....... ;-) > > > > > > >> There's a few subtleties still to be addressed ;-) > > > << > > > > > > MS=3D> :-)) > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 08:27:43 -0400 Organization: Cisco Systems Lines: 170 Sender: pwe3-admin@ietf.org References: <20030529224846.37432.qmail@web13505.mail.yahoo.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri May 30 14:33:08 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20030529224846.37432.qmail@web13505.mail.yahoo.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mark Seery > Sent: Thursday, May 29, 2003 6:49 PM > To: Busschbach, Peter B (Peter) > Cc: pwe3@ietf.org; dallan@nortelnetworks.com > Subject: RE: [PWE3] RE: Is PWE a layer? > > > Hi Peter, > > > According to Y.1711, Connection Verification > > messages are sent at a rate of one packet per > > second, but "other configurable CV generation rates > > are for further study". > > I have a couple of challenges with this: > > a) what has to be implemented > b) if the rate is lessoned, are the exit/entry > requirements met. > > What is implemented > =================== > > If a standard is written in such a way as to suggest > that an operator may wish to operate a feature at its > boundary conditions, on all layers of the network, > then I have a problem in terms of what I tell > engineers to implement. Now you could probably > respond, that if I had any clue about what I was > doing, then the answer would be obvious - which is a > far comment in this case ;-) - but then it brings up > the issue of what does it mean to be standards > compliant. You suggested one compromise in that maybe > we don't need the same functionality (transport) at > every layer of the network - thank you for offering > that and it would be interesting to see if there is > any support for that position. > > Meeting entry/exit requirements > =============================== > > The authors of Y.1711 have done a great job in really > thinking through what they want to achieve; but if > course in this business you can't win for losing. The > downside of the meticulous detail they have gone to is > that I now question if I know whether entry/exit > criterias can be met if I start running at different > rates. > > Now Y.17fec-cv does try to give some guidance on this > (fig.1 required probe insertion rate); and Dave was > kind enough to shoot me a message offline explaining > at that in the MP2P case there may be room for > relaxing requirements, but to me this then becomes the > issue: what rate achieves the desired goal, and until > I feel comfortable with that issue, it is hard for me > to make implementation tradeoffs about what rates I > would offer to a customer. Even in the P2P case, there is room for relaxing the 1 second interval. Just ask any operator's operational department and you will hear 9 times out of 10 that they want control over whatever interval is used! I assert that there is no need to specify an interval; just that it SHOULD be consistent at ends of a particular path. This does not imply that ALL paths must be measured in the same way either, as they may have different constraints. > > For the purposes of specifying OAM for PWE3, I don't > > think there is any reason to require that the > > generation rate of Y.1711 CV messages is necessarily > > higher than the generation rate of LSP Ping > > messages. > > At this point I question whether LSP Ping and Y.1711 > have the same goals, so I am not sure that is a valid > assertion. For example, if Y.1711 is a robust mechanism for > carrier class transport layer fault management, whereas the > LSP PING is really focused on some connectivity verification > and SLA feedback, then I don't think the assertion stands; > moreover, maybe both are applicable, which may be what Dave > was alluding to in: allan-y1711-and-lsp-ping IMHO, they have many of the same goals in mind, but they might achieve those goals in different ways. It will be up to the market to decide which solution is preferred. > > Comparing Y.1711 and LSP Ping, I see one big > > difference: With LSP Ping, if a PE doesn't receive a > > reply, it doesn't know what the problem is. It is > > possible that the PW is down, but it is also > > possible that the return path is unavailable. In > > Y.1711, upstream and downstream PEs work in tandem > > and it is the downstream PE that determines that the > > link is down. > > So I can only comment once I understand the > requirements that LSP Ping is trying to meet, though > obviously looking at your statement at face value, I > can see the problem; and if LSP Ping purports to be a > robust fault detection mechanism, then it has some > defficiences WRT requirements as they have been > interpreted by other standards bodies + the desired > tools by a class of carriers. This seems to be the case. Other standards bodies seem to have seen fit to design the other mechanism without much if any real world operational feedback in mind, thus there is no way it could work as originally designed in the majority of cases that are deployed. > > To me it seems evident that the fault detection > > mechanism defined in Y.1711 is superior to that of > > LSP Ping, no matter what Tom's 25 happy customers > > say. > > This seems like a valid assertion. Again, this comes down to an argument over architectural purity versus practicality of use and implementation. On the one hand the other standards body asserts that it is okay to write standards in a vaccuum making all sorts of convenient assumptions which were found to be wrong once, so who is to say that they won't be again? Meanwhile, we are re-writing our code and redeplying hardware based on these standards? OTOH, while I will be the first to admit the mechanisms being proposed here are not perfect, they have specific practical use today and tomorrow for sure. > > So what exactly is the problem with adopting Y.1711 > > for PW OAM, as long as we speciify that the CV > > generation rate is configurable? This would not > > require any vendor to implement the function in > > ASICs or provide some other form of HW acceleration. > > So putting aside the question should we do any OAM at > the PWE "layer" ;-) the next issue is does that OAM > capability need to be a robust transport layer like > fault detection mechanism; if so, then will it work > over other PSNs is the next question; followed by does > it have functionality that Y.1711 does not (seems like > it has some pretty good VPN support which Y.1711 is > now addressing but might be some room for requirements > merge here at least). It isn't an issue of requirements; we are working from the same set of basic requirements for these solutions. It is IMHO a matter of perspective, as I explained above. --Tom > > Mark > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 13:51:39 +0100 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 30 14:58:01 2003 Return-path: To: jtpugac@qwest.com, busschbach@lucent.com, mark@mseery.com, dallan@nortelnetworks.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Good point Jack. I'd regard LB as a complimentary tool for operators. It's not designed to take executive actions (at the sink and in a unidirectional sense), it can detect breaks (but not which direction) but it is not designed to detect swaps/mismerges (Note that the stuff in I.610 on MLT (multiple level LB technique) which is supposed to help diagnose (not detect) misbranching has some technical problems). And if its not periodic but just on-demand, then it still requires detection by some other means, eg customer complaint 1st. However, where continuous connectivity verification is not required then LB is a useful tool (also for a check of RTD). BTW don't confuse the ATM CC and the Y.1711 CV. There are several things wrong with I.610 that have been corrected in Y.1711. regards, Neil > -----Original Message----- > From: Jack Pugaczewski [mailto:jtpugac@qwest.com] > Sent: 30 May 2003 13:27 > To: Harrison,N,Neil,IKL2 R; busschbach@lucent.com; mark@mseery.com; > dallan@nortelnetworks.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > I think it is important to distinguish between an OAM Loopback and OAM > Continuity Check (CC). > The OAM CC is a continuous stream once per second. The OAM > Loopback can be > a single request. The OAM Loopback provides much benefit and does not > require a lot of resources. Utilization of the Loopback Location ID > provides the ability to determine dynamic topology which is > also very useful > for a carrier. > > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 07:58:57 -0500 Lines: 72 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6905@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Fri May 30 15:04:06 2003 Return-path: To: , , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6905@i2km07-ukbr.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by uswgco35.uswest.com id h4UCwxvf016929 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UCx5B31935 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UD2PB32085 Status: O Absolutely. However, most ATM implementations are utilizing a subset of = the functionality of I.610. The OAM LB is most likely invoked from a TMN network (or element) management system as part of a fault isolation proce= ss. The modes of operation provide end-to-end and segment loopbacks. The ent= ire functionality (if implemented fully) provides the carrier with an extreme= ly useful tool for end-to-end connectivity verification. This same functionality will be absolutely necessary in a PWE-3 network. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Friday, May 30, 2003 7:52 AM > To: jtpugac@qwest.com; busschbach@lucent.com; mark@mseery.com; > dallan@nortelnetworks.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > Good point Jack. I'd regard LB as a complimentary tool for > operators. It's > not designed to take executive actions (at the sink and in a > unidirectional > sense), it can detect breaks (but not which direction) but it is not > designed to detect swaps/mismerges (Note that the stuff in I.610 on MLT > (multiple level LB technique) which is supposed to help diagnose (not > detect) misbranching has some technical problems). And if its > not periodic > but just on-demand, then it still requires detection by some > other means, eg > customer complaint 1st. However, where continuous connectivity > verification is not required then LB is a useful tool (also for a check= of > RTD). > > BTW don't confuse the ATM CC and the Y.1711 CV. There are several thin= gs > wrong with I.610 that have been corrected in Y.1711. > > regards, Neil > > > > -----Original Message----- > > From: Jack Pugaczewski [mailto:jtpugac@qwest.com] > > Sent: 30 May 2003 13:27 > > To: Harrison,N,Neil,IKL2 R; busschbach@lucent.com; mark@mseery.com; > > dallan@nortelnetworks.com > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > I think it is important to distinguish between an OAM Loopback and OA= M > > Continuity Check (CC). > > The OAM CC is a continuous stream once per second. The OAM > > Loopback can be > > a single request. The OAM Loopback provides much benefit and does no= t > > require a lot of resources. Utilization of the Loopback Location ID > > provides the ability to determine dynamic topology which is > > also very useful > > for a carrier. > > > > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 09:06:26 -0400 Organization: Cisco Systems Lines: 296 Sender: pwe3-admin@ietf.org References: <20030530043824.71010.qmail@web13508.mail.yahoo.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Fri May 30 15:09:13 2003 Return-path: To: "'Mark Seery'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20030530043824.71010.qmail@web13508.mail.yahoo.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mark Seery > Sent: Friday, May 30, 2003 12:38 AM > To: busschbach@lucent.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Is PWE a layer - thread summary > > > Hi Peter, > > --- "Busschbach, Peter B (Peter)" > wrote: > > Mark, > > > > Great summary. Thanks. > > thx. > > > I think there is a big difference between an ISP > > offering VPLS-like services over an MPLS network and > > a more traditional Telco looking at MPLS as a way to > > evolve its Frame Relay and ATM networks. The ISP may > > be able to get away with very little OAM. The Telco > > will definitely require a much more robust solution. > > There is no such thing as a free lunch - there is a > tradeoff for "robust"; but which SPs pursue what value > proposition with what solutions should not be bounded by what > type of SP they are - going forward, this is a choice that > each makes. > > In a sense, this and other comments you make, suggest > a larger issue - that various organizations have > traditionally been integral elements of various and > often competing ecosystems. > > The real issue is that the IETF has traditionally > pursued a certain approach to networking that was > believed to deliver certain values: lower cost, > greater scalability, faster time to market, open ness, > the unix philosophy of many small tools rather than > monolithic architectures,..... > > All great value propositions are a package of elements > - aimed and focused. It is as hard for the IETF to > change one element of the package and still assert its > value proposition is whole, as it would be for the > ITU. This is related to your comment in the sense that > the IETF has traditionally been closely aligned to the > ISP ecosystem, and the ITU (and various other bodies) > have traditionally been aligned to the carrier > ecosystem. > > Then there is the vendor element. It is **probably** > easier to migrate an ATM switch along the Y.1711 > approach than to migrate a router along that approach; > and because ATM vendors already understand the OAM > concepts being discussed, it is also easier for them > to understand Y.1711, how to implement it, and how to > use it to solve a customer requirement. > > And there is the operator element. Because a carrier > already undertands how to organize an operation around > OAM, then it is easier to migrate their operation > around Y.1711. Not necessarily. My customer feedback indicates that this is certainly not the case. In fact, the majority my customers have told me that they do not want Y.1711 at all because of the added cost associated both in terms of hardware and operational cost. --Tom > Because an ISP may not have organized > their operation around OAM, it is much harder, and > possibly expensive, to organize their operation around > OAM. And then there is the issue of a carrier doing a > greenfield deployment for a new service - should they pursue > a new path for the sake of leading the rest of the SP? > > The only real problem here is defining what problem we > are solving. Once that is done, there is no lack of > brain power on this list (with the exception of me of > course) to go solve that problem. > > All that said, there should be no reason why we can > not work together to develop solutions for a variety > of problems, network evolution scenarios, and > operators, while also finding commonality that allows > us to build upon a common framework. > > > In my view, the IETF has taken a big step by > > deciding to define encapsulations of ATM and Frame > > Relay. If these respective standards move forward > > and become proposed standards, there needs to be an > > companion document that specifies a sufficently > > robust OAM solution. Vice versa, if the IETF decides > > not to define OAM and relegates it to another > > standards body, I believe it should stop all work on > > ATM and Frame Relay encapsulation. > > I don't. The LSP-PING / PWE OAM approaches are > consistent with an alternative approach to building > networks. If it remains consistent with a package of > elements, then that allows the market to provide > differentiation among service providers - this is in my > purists point of view what makes for a beautiful "market". > > The participants in this working group do need to make > a decision though about whether one solution will meet > the needs of all significant elements of the SP > industry. It is valid for them to make that choice. > > I do believe however that if the participants of this > WG are unable to come to agreement on an > implementation for an additional robust transport > layer OAM, then there are implications for the use and > future of MPLS, and for vendors who do not pursue > additional elements through other organizations (that > is purely a personal opinion - there is no impirical > proof for this, especially given the current health of > the vendor community). At the very least, vendors wil > be laying down a bet, which may or may not pay off; > each vendor will have to decide if they want to make > that bet. Each operator will have to decide if they > want to pursue alternative approaches through > different organizations. > > Now back to more OT issues ;-) > > > I think that PWE was supposed to be just an > > adaptation layer. I think there are two forces that > > are turning into something more than that: > > > > a) Difficulties in fault detection in the MPLS layer > > due to ECMP, which leads to the need for fault > > detection per PW. > > Thanks Pete, I forgot about that. Additionally I need > to educate myself on a) the implications of ECMP on > OAM, and b) whether OAM upper layer OAM even makes any > sense in an ECMP environment. > > > b) The possibility of threading PWs together though > > switching based on the PW label (i.e. the TTL>2 > > discussion) > > So if something is not a layer, how can you stitch it > together? Seems to me this is heading down the road > that some of us are worried about. 3 years from now we > will be here discussing TE and Diffserv for PW ;-) > > > I am not sure how we would benefit from agreeing on > > an answer to your question. For the purist, it may > > not matter much. If PW is just adaptation, you do > > OAM in the underlying MPLS layer. If PW is a layer > > in and of itself, you do OAM in both the PW layer > > and the underlying MPLS layer. However, you would > > use the same mechanisms on both layers and the > > overall solution would not necessarily be more > > complex. > > The importance of such questions is to test the > premise whether PW over both IP and MPLS makes sense. > What I suspect is that some PWE elements should only > be used when running over IP; and then, the issue > arises of whether the package of elements that is IP, > is consistent with that approach. > > > > Issue 2. Can service interworking be avoided by > translations either > > > side of PWE? > > > > Yes, you can avoid service inteworking with the MPLS > > layer. E.g. to achieve FR-ATM Service Interworking, > > you can use FRF.8 somewhere in the network (possibly > > in the NSP function of the PEs) and carry either FR > > or ATM over PW. > > Sounds reasonable to me. > > > However, the issue that Neil brought up was > > different. I thought that in his view, Service > > Interworking was the preferred way to carry ATM and > > FR services over an MPLS core. In other words, to do > > FR-ATM Service Interworking, it might be best to do > > FR-MPLS Service Interworking at the ingress of the > > MPLS core and MPLS - ATM Service Interworking at the > > egress of the MPLS core. > > > > I actually think Issue 2 is irrelevant to PWE. PWE > > is a solution for Network Interworking. If you want > > to use PWE and you need Service Interworking, you > > need to do it outside the PW between the respecive > > client layers. > > So the issue becomes can we get consensus that it is > OK to use PWE for network interworking, but it is OK > for PWE to just disappear when doing service > interworking; but if you of the mindset that PWE is > actually a layer, you are bound to be perpetually > confused about what choice to make when. > > >> Issue 3. Is service interworking in or out of > > scope? > > > > Right now it is out of scope. Should that change? I > > think Service Interworking is important and needs to > > be standardized. However, I see little synergy > > between the solutions that have been developed for > > PWE and what you would need for Service > > Interworking. Hence, adding Service Interworking to > > the charter might open Pandora's box. > > OK, thanks. > > > > Issue 4. Is it essential for the IETF to provide > > the > > > kind of MPLS OAM that is desired (or can another > > > standards body provide this)? > > > > > Issue 5. Is it conceivable to think of PWE OAM as > > an > > > extension to the client layer for the network > > > interworking case? > > > > It is conceivable, but wrong :-) But seriously, you > > are thinking of using PW OAM to provide OAM for > > Ethernet services, right? > > That is a potential, yes. Other potentials include any > future client that does not have OAM; not such an > issue if we can get robust OAM in to all the server > layers (IP and MPLS), but it appears we are not there > yet. > > > I think we have to be very > > careful with that. The discussion on "VPLS model for > > L2VPN Framework" that is currently going on on the > > PPVPN mailing list shows how tricky it is to > > correctly map IEEE bridging models. > > Yes, has all the hallmarks of being as much fun as > GMPLS ;-) > > > I believe that > > Ethernet OAM should be defined by the IEEE. > > EFM is, I have to investigate how generalized it is > though. However, there is a lot of Ethernet out there > already. > > > Making > > some short-cuts using PW OAM may lead to big > > problems later. > > Not making them may lead to some people's careers > being terminated sooner ;-) And I am not just talking > about at vendors, I am talking about operators as > well. > > Seriously, I have not seen a comprehensive > conversation yet which follows the line of...this is > the short-term problem, this is the long-term problem, > if we do it this way, we can evolve in the following > way. > > May be it is not possible, and perhaps that is too > idealistic. > > > In your email you wrote >> A criticism of the PWE > > OAM approach is that it > > generates messages regardless of whether a fault > > exist or not, which some see as being at variance to > typical/desired > > OAM behavior. << > > I'll have to try and dig it up. One of the posts made > the comment that an OAM mechanism should only produce > events if it detects a fault, whereas LSP Ping does on > every occassion. Though not explicitly stated, I think > the essential inference was that there is a difference > between a break-fix diagnostic tool, and an integrated > OAM mechanism. > > Mark > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Mark Seery" Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 06:28:47 -0700 Lines: 69 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6901@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Fri May 30 15:36:58 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6901@i2km07-ukbr.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, > Further, it was suggested that > service interworking could be avoided by doing > protocol translations either side of the PWE core, and > thereby creating a like-to-like service, end-to-end. NH=> Service interworking *is* protocol translation.... MS=> Of course. The suggestion was made, by Yaakov.S. I think, that the service interworking could be done in existing equipment, say an ATM switch, before entering the MPLS cloud, to match to what ever was needed coming out the other side of the MPLS cloud, and therefore relax the need to define service interworking within the MPLS cloud. Now you may argue this is not sufficient, and does not meet your needs in the long term, ......but seems like a pragmatic short-term approach for some carriers. For example, a number of carriers in the U.S. **are** planning to do this already. > Various opinions have been expressed as to > the architectural downsides of this approach. NH=> We don't mind people doing crazy things. What we do object to however is trying to force those same stupid things on the whole community and not allowing an alternative set of solutions to be produced. MS=> From a practical perspective, if you assert something is crazy it becomes impossible to broker an evolution path between two competing solutions. This ensures that vendors will have to implement two disparate approaches, or not. Which means either a) every operator pays the cost of both approaches or b) some operators will have more equipment choices than others. > The issue of how many layes of the stack does OAM need > to be performed at arose. NH=> Its not an issue......all leayers need their own OAM independently. This is not something we should even be discussing, its an obvious requirement. > This many layers above the > facility layer is a new capability in networks, NH=> Dealing with multiple layered networks is not new (see how many there are in SDH)..... MS=> The way SONET/SDH do OAM is much different, and actually preferable in my opinion. With this approach, vendors will come to you and say, my product has this granularity and in this part of the network it does section, line, path, whatever,....but there is no expectation that every piece of SONET/SDH equipment can terminate every layer of OAM in every part of the network. More over when a fault does occur, you simply flip some indicators in existing overhead and the fault is inidcated, you are not creating extra bandwidth/processing at exactly the point the network is experiencing stress. To take the SONET/SDH approach of OAM on every layer and apply it to packet networks is problematic for implementors unless you are willing to specify a hierarchy so the implementors can bound the problem. If the implementors can not bound the problem (and I am not the only one who sees this problem) then they have to choose between a worst case implementation, or make assumptions on the operators behalf (and many operator are likely to have a different networks given such extraordinary layering flexibility) which may or may not meet requirements. There has to be a more sophisticated conversion between implementors and operators than simply a stand-off between "you must do every layer at x/sec to y/sec" and "this is too expensive to implement". At least with ATM the problem is bounded, ATM only supports two layers. With MPLS the problem is wide-open; and the more layers deep a network is, the more complex the processing pipeline becomes - once again it would be very different if OAM was a fixed element of every packet and the implementors could choose what granularity (which layers) they were operating on. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Mark Seery" Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 06:38:55 -0700 Lines: 24 Sender: pwe3-admin@ietf.org References: <007a01c326ac$47258ee0$6601a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Fri May 30 15:43:37 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <007a01c326ac$47258ee0$6601a8c0@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > And there is the operator element. Because a carrier > already undertands how to organize an operation around > OAM, then it is easier to migrate their operation > around Y.1711. Not necessarily. My customer feedback indicates that this is certainly not the case. In fact, the majority my customers have told me that they do not want Y.1711 at all because of the added cost associated both in terms of hardware and operational cost. MS=> Of course this becomes a matter of conjecture without any formal way to recognize the expression of an operator's desire ;-) Jack's and Neil's remarks are at least to dissenting opinions. I suspect what you might be seeing is feedack related to a set of expectations about service characteristics+the assumption that if the underlying layers are robust there is less need for heavy-weight approaches at the higher layers. Which is one way to look at the problem - clearly not every one agrees. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Zhou Yun(163)" Subject: Why can't send Label release message when receiving lable withdraw message Date: Thu, 29 May 2003 09:20:15 +0800 Lines: 2 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Fri May 30 15:52:23 2003 Return-path: To: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4T1OnB29448 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O In draft-ietf-pwe3-control-protocol-02.txt, it is said that"If at any time after a Label Mapping message has been received, a corresponding Label Withdraw or Release is received, the action taken is the same as for any Label Withdraw or Release that might be received at any time. Note that receiving a Label Withdraw should not cause a corresponding Label Release to be sent." Why can't response Label release messsge when receiving Label withdraw message? How the downstream knows that the upstream has released this label then it can reuse this label? From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 08:57:04 -0500 Lines: 57 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Fri May 30 15:58:44 2003 Return-path: To: "Mark Seery" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by uswgco35.uswest.com id h4UDv5vf022915 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UDvBB04295 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UE0BB04401 Status: O I find it amazing that manufacturers are itemizing the cost of functional= ity (i.e.,Y.1711). The functionality of I.610 currently leveraged pays for itself over the life of the product. The ability to fault isolate issues= in an automated fashion using the combination of an EMS and the embedded switch/router OAM functionality is essential. This functionality allows fault isolation to the location within the path as well as the protocol layer. In a PWE-3 network and the combination of Frame Relay, ATM, TDM, etc. this will more important than ever. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Mark > Seery > Sent: Friday, May 30, 2003 8:39 AM > To: tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Is PWE a layer - thread summary > > > > > And there is the operator element. Because a carrier > > already undertands how to organize an operation around > > OAM, then it is easier to migrate their operation > > around Y.1711. > > Not necessarily. My customer feedback indicates > that this is certainly not the case. In fact, the majority > my customers have told me that they do not want Y.1711 > at all because of the added cost associated both in > terms of hardware and operational cost. > > MS=3D> Of course this becomes a matter of conjecture without any > formal way to > recognize the expression of an operator's desire ;-) > > Jack's and Neil's remarks are at least to dissenting opinions. > > I suspect what you might be seeing is feedack related to a set of > expectations about service characteristics+the assumption that if the > underlying layers are robust there is less need for heavy-weight > approaches > at the higher layers. Which is one way to look at the problem - > clearly not > every one agrees. > > Mark > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Eric Rosen Subject: Re: Why can't send Label release message when receiving lable withdraw message Date: Fri, 30 May 2003 10:02:57 -0400 Lines: 12 Sender: pwe3-admin@ietf.org References: <003d01c32580$76378ee0$4d16050a@zhouyun> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 30 16:04:30 2003 Return-path: To: "Zhou Yun(163)" In-reply-to: Your message of Thu, 29 May 2003 09:20:15 +0800. <003d01c32580$76378ee0$4d16050a@zhouyun> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > "Note that receiving a Label Withdraw should not cause a corresponding > Label Release to be sent." Why can't response Label release messsge when > receiving Label withdraw message? How the downstream knows that the > upstream has released this label then it can reuse this label? This is just an error in the specification. Per RFC 3036, the Withdraw should be followed by a Release. However, it is not necessarily a good practice to reuse the label immediately upon receiving a release, as there could be packets in transit with the label. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 07:16:27 -0700 (PDT) Lines: 32 Sender: pwe3-admin@ietf.org References: <004b01c326b3$59d13470$854c1cac@dyn.interprise.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 30 16:18:35 2003 Return-path: To: Jack Pugaczewski In-Reply-To: <004b01c326b3$59d13470$854c1cac@dyn.interprise.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UEJLB06699 Status: O Jack, I appreciate your point. My point is simply that if the problem (read layers) are not bounded via some implementation agreements, then it is very hard for the implementor to know exactly what the requirement is. As I stated before, the problem is well-bounded in both SONET/SDH and ATM networks. It is not well-bounded in MPLS networks. Mark --- Jack Pugaczewski wrote: > I find it amazing that manufacturers are itemizing > the cost of functionality > (i.e.,Y.1711). The functionality of I.610 currently > leveraged pays for > itself over the life of the product. The ability to > fault isolate issues in > an automated fashion using the combination of an EMS > and the embedded > switch/router OAM functionality is essential. This > functionality allows > fault isolation to the location within the path as > well as the protocol > layer. In a PWE-3 network and the combination of > Frame Relay, ATM, TDM, > etc. this will more important than ever. >=20 > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > =A0 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 09:37:06 -0500 Lines: 60 Sender: pwe3-admin@ietf.org References: <20030530141627.42698.qmail@web13505.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Fri May 30 16:41:43 2003 Return-path: To: "Mark Seery" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <20030530141627.42698.qmail@web13505.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by uswgco35.uswest.com id h4UEb8vf028834 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UEbQB08363 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UEekB08850 Status: O Then this looks like a great forum to get ideas out and explore the prope= r means for implementation aggrements. Now is the time to define these mechanism between Layer 2 (Frame Relay, ATM, Ethernet, etc.) and MPLS. T= his functionality will be essential in the deployment of a quality network th= at can be properly and efficiently maintained. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Mark > Seery > Sent: Friday, May 30, 2003 9:16 AM > To: Jack Pugaczewski > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Is PWE a layer - thread summary > > > Jack, > > I appreciate your point. > > My point is simply that if the problem (read layers) > are not bounded via some implementation agreements, > then it is very hard for the implementor to know > exactly what the requirement is. As I stated before, > the problem is well-bounded in both SONET/SDH and ATM > networks. It is not well-bounded in MPLS networks. > > Mark > > --- Jack Pugaczewski wrote: > > I find it amazing that manufacturers are itemizing > > the cost of functionality > > (i.e.,Y.1711). The functionality of I.610 currently > > leveraged pays for > > itself over the life of the product. The ability to > > fault isolate issues in > > an automated fashion using the combination of an EMS > > and the embedded > > switch/router OAM functionality is essential. This > > functionality allows > > fault isolation to the location within the path as > > well as the protocol > > layer. In a PWE-3 network and the combination of > > Frame Relay, ATM, TDM, > > etc. this will more important than ever. > > > > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > > =A0 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 15:42:31 +0100 Lines: 21 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 30 16:46:25 2003 Return-path: To: tnadeau@cisco.com, mark@mseery.com, busschbach@lucent.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, > > And there is the operator element. Because a carrier > > already undertands how to organize an operation around > > OAM, then it is easier to migrate their operation > > around Y.1711. > > Not necessarily. My customer feedback indicates > that this is certainly not the case. In fact, the majority > my customers have told me that they do not want Y.1711 > at all because of the added cost associated both in > terms of hardware and operational cost. > > --Tom NH=> The whole point of having decent OAM is to try and reduce operational cost (and the customer disatisfaction index) not increase it. Why do you think there are major efforts in IEEE, MEF and ITU to provide ethernet with OAM.....and there is 1 very large operator who is driving this (at least in ITU) and its not BT? regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 15:42:29 +0100 Lines: 23 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Fri May 30 16:51:53 2003 Return-path: To: tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Tom, > > At this point I question whether LSP Ping and Y.1711 > > have the same goals, so I am not sure that is a valid > > assertion. For example, if Y.1711 is a robust mechanism for > > carrier class transport layer fault management, whereas the > > LSP PING is really focused on some connectivity verification > > and SLA feedback, then I don't think the assertion stands; > > moreover, maybe both are applicable, which may be what Dave > > was alluding to in: allan-y1711-and-lsp-ping > > IMHO, they have many of the same goals in mind, > but they might achieve those goals in different ways. > It will be up to the market to decide which solution > is preferred. NH=> The market (and I assume we realise this has little relevance to Internet stds now) has little choice when the dominant supplier just goes and does X. To be fair though, we deserve what we get as operators if we abdicate our role in stds production/moderation, as has been the case for too many years now.....but maybe things are starting to change again. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 16:09:48 +0100 Lines: 98 Sender: pwe3-admin@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-admin@ietf.org Fri May 30 17:15:34 2003 Return-path: To: jtpugac@qwest.com, mark@mseery.com, tnadeau@cisco.com X-Mailer: Internet Mail Service (5.5.2654.89) X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UFAiB11534 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UFDLB11665 Status: O Absolutely right Jack. I can't believe there are operators who don't hav= e an aim of driving down their opex costs (esp thesedays)....so decent OAM = is not a 'desirable function' its a critical component. In BT we also have = a some stretching targets on driving down the customer disastisfaction index....again this means automated OAM as we don't want the customer to = be telling us (or even another operator) there is a problem with out network. Sure one has to balance doing the right thing with time to market.....but= if one pays attention to these matters *before* deploying kit (ie during std= s work) then that is the best....retrospective fitting is painful, costly a= nd not a good idea. regards, Neil =20 > -----Original Message----- > From: Jack Pugaczewski [mailto:jtpugac@qwest.com] > Sent: 30 May 2003 14:57 > To: Mark Seery; tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Is PWE a layer - thread summary >=20 >=20 > I find it amazing that manufacturers are itemizing the cost=20 > of functionality > (i.e.,Y.1711). The functionality of I.610 currently=20 > leveraged pays for > itself over the life of the product. The ability to fault=20 > isolate issues in > an automated fashion using the combination of an EMS and the embedded > switch/router OAM functionality is essential. This=20 > functionality allows > fault isolation to the location within the path as well as=20 > the protocol > layer. In a PWE-3 network and the combination of Frame=20 > Relay, ATM, TDM, > etc. this will more important than ever. >=20 > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > =A0 >=20 >=20 > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On=20 > Behalf Of Mark > > Seery > > Sent: Friday, May 30, 2003 8:39 AM > > To: tnadeau@cisco.com > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] Is PWE a layer - thread summary > > > > > > > > > And there is the operator element. Because a carrier > > > already undertands how to organize an operation around > > > OAM, then it is easier to migrate their operation > > > around Y.1711. > > > > Not necessarily. My customer feedback indicates > > that this is certainly not the case. In fact, the majority > > my customers have told me that they do not want Y.1711 > > at all because of the added cost associated both in > > terms of hardware and operational cost. > > > > MS=3D> Of course this becomes a matter of conjecture without any > > formal way to > > recognize the expression of an operator's desire ;-) > > > > Jack's and Neil's remarks are at least to dissenting opinions. > > > > I suspect what you might be seeing is feedack related to a set of > > expectations about service characteristics+the assumption=20 > that if the > > underlying layers are robust there is less need for heavy-weight > > approaches > > at the higher layers. Which is one way to look at the problem - > > clearly not > > every one agrees. > > > > Mark > > > > _______________________________________________ > > 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 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 16:09:49 +0100 Lines: 59 Sender: pwe3-admin@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-admin@ietf.org Fri May 30 17:18:53 2003 Return-path: To: mark@mseery.com, jtpugac@qwest.com X-Mailer: Internet Mail Service (5.5.2654.89) X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UFAiB11538 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UFFTB11784 Status: O Mark....How many layers do you think would be required in MPLS? My guess= is not that many. The beauty of being able to create an ad hoc LSP between = 2 points (as a server to some higher layer trail) from an operators point o= f view is that we can monitor the partition very simply. This type of functionality is limited or complex when layers have a fixed hierarchy (check out some of the tandem connection monitoring ideas for G.709 for example). Regards, Neil > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: 30 May 2003 15:16 > To: Jack Pugaczewski > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Is PWE a layer - thread summary >=20 >=20 > Jack, >=20 > I appreciate your point. >=20 > My point is simply that if the problem (read layers) > are not bounded via some implementation agreements, > then it is very hard for the implementor to know > exactly what the requirement is. As I stated before, > the problem is well-bounded in both SONET/SDH and ATM > networks. It is not well-bounded in MPLS networks. >=20 > Mark >=20 > --- Jack Pugaczewski wrote: > > I find it amazing that manufacturers are itemizing > > the cost of functionality > > (i.e.,Y.1711). The functionality of I.610 currently > > leveraged pays for > > itself over the life of the product. The ability to > > fault isolate issues in > > an automated fashion using the combination of an EMS > > and the embedded > > switch/router OAM functionality is essential. This > > functionality allows > > fault isolation to the location within the path as > > well as the protocol > > layer. In a PWE-3 network and the combination of > > Frame Relay, ATM, TDM, > > etc. this will more important than ever. > >=20 > > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > > =A0 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 11:24:48 -0400 Lines: 95 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Fri May 30 17:26:07 2003 Return-path: To: "'tnadeau@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, May 30, 2003 8:28 AM > To: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? [snipped] > > > > To me it seems evident that the fault detection > > > mechanism defined in Y.1711 is superior to that of > > > LSP Ping, no matter what Tom's 25 happy customers > > > say. > > > > This seems like a valid assertion. > > Again, this comes down to an argument over > architectural purity versus practicality of use > and implementation. On the one hand the other standards > body asserts that it is okay to write standards in > a vaccuum making all sorts of convenient assumptions > which were found to be wrong once, so who is to say > that they won't be again? Meanwhile, we are re-writing > our code and redeplying hardware based on these > standards? OTOH, while I will be the first to admit > the mechanisms being proposed here are not perfect, > they have specific practical use today and tomorrow > for sure. > Tom, I am not sure I understand your argument. If we want to check the state of a PW, there are two ways to do it: 1. The ingress PE sends an LSP-Ping message and declares a failure if it doesn't receive a reply 2. The ingress PE sends CV messages at regular intervals and the egress PE declares a failure if it doesn't receive several messages in a row. My assertion was that 2) is superior to 1) for obvious technical reasons. You counter with two arguments: a) That 2) is an attempt to "write standards in a vaccuum making all sorts of convenient assumptions which were found to be wrong once, so who is to say that they won't be again?" b)There are existing implementations for 1) and we don't want to rewrite code and redeploy hardware. Regarding a), it would help if you could identify why mechanism 2) wouldn't work for connectivity verification of PW. I don't see why the "convenient assumptions" that you refer to have any relevance to this case. Regarding b), I don't see why that is relevant at all. The whole PWE stndardization work is still based on draft documents. The fact that code may need to be rewritten is the risk that a vendor willingly accepts if he decides to bring out a product based on proprietary protocols. Finally, the issue is not whether it should be one or the other. I haven't seen anyone argue that LSP-Ping as defined in the VCCV draft is not a useful tool to have. But there are several people who feel (strongly) that it should be augmented with additional OAM tools for those operators who need it. Peter > > > So what exactly is the problem with adopting Y.1711 > > > for PW OAM, as long as we speciify that the CV > > > generation rate is configurable? This would not > > > require any vendor to implement the function in > > > ASICs or provide some other form of HW acceleration. > > > > So putting aside the question should we do any OAM at > > the PWE "layer" ;-) the next issue is does that OAM > > capability need to be a robust transport layer like > > fault detection mechanism; if so, then will it work > > over other PSNs is the next question; followed by does > > it have functionality that Y.1711 does not (seems like > > it has some pretty good VPN support which Y.1711 is > > now addressing but might be some room for requirements > > merge here at least). > > It isn't an issue of requirements; we are working > from the same set of basic requirements for these > solutions. It is IMHO a matter of perspective, as I > explained above. > > --Tom > > > > > > > Mark > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 12:03:09 -0400 Lines: 378 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C326C4.F6CD2692" X-From: pwe3-admin@ietf.org Fri May 30 18:15:25 2003 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'tnadeau@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C326C4.F6CD2692 Content-Type: text/plain; charset="iso-8859-1" I get the feeling that claiming the "wrong approach to standards" is to "assume in a vaccuum" sentences us to re-prove the validity of Murphy's law over and over again. Given the amound of experience we've accumulated with label switching technologies, and more recently with label stacking, I'd assume we have a body of knowledge and experience that "fills the vaccuum". cheers Dave > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Friday, May 30, 2003 11:25 AM > To: 'tnadeau@cisco.com'; pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Friday, May 30, 2003 8:28 AM > > To: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > [snipped] > > > > > > > To me it seems evident that the fault detection > > > > mechanism defined in Y.1711 is superior to that of > > > > LSP Ping, no matter what Tom's 25 happy customers > > > > say. > > > > > > This seems like a valid assertion. > > > > Again, this comes down to an argument over > > architectural purity versus practicality of use > > and implementation. On the one hand the other standards > > body asserts that it is okay to write standards in > > a vaccuum making all sorts of convenient assumptions > > which were found to be wrong once, so who is to say > > that they won't be again? Meanwhile, we are re-writing > > our code and redeplying hardware based on these > > standards? OTOH, while I will be the first to admit > > the mechanisms being proposed here are not perfect, > > they have specific practical use today and tomorrow > > for sure. > > > > Tom, > > I am not sure I understand your argument. If we want to check > the state of a PW, there are two ways to do it: > > 1. The ingress PE sends an LSP-Ping message and declares a > failure if it doesn't receive a reply > > 2. The ingress PE sends CV messages at regular intervals and > the egress PE declares a failure if it doesn't receive > several messages in a row. > > My assertion was that 2) is superior to 1) for obvious > technical reasons. You counter with two arguments: > > a) That 2) is an attempt to "write standards in a vaccuum > making all sorts of convenient assumptions which were found > to be wrong once, so who is to say that they won't be again?" > > b)There are existing implementations for 1) and we don't want > to rewrite code and redeploy hardware. > > Regarding a), it would help if you could identify why > mechanism 2) wouldn't work for connectivity verification of > PW. I don't see why the "convenient assumptions" that you > refer to have any relevance to this case. > > Regarding b), I don't see why that is relevant at all. The > whole PWE stndardization work is still based on draft > documents. The fact that code may need to be rewritten is the > risk that a vendor willingly accepts if he decides to bring > out a product based on proprietary protocols. > > Finally, the issue is not whether it should be one or the > other. I haven't seen anyone argue that LSP-Ping as defined > in the VCCV draft is not a useful tool to have. But there are > several people who feel (strongly) that it should be > augmented with additional OAM tools for those operators who need it. > > Peter > > > > > > > So what exactly is the problem with adopting Y.1711 > > > > for PW OAM, as long as we speciify that the CV > > > > generation rate is configurable? This would not > > > > require any vendor to implement the function in > > > > ASICs or provide some other form of HW acceleration. > > > > > > So putting aside the question should we do any OAM at > > > the PWE "layer" ;-) the next issue is does that OAM > > > capability need to be a robust transport layer like > > > fault detection mechanism; if so, then will it work > > > over other PSNs is the next question; followed by does > > > it have functionality that Y.1711 does not (seems like > > > it has some pretty good VPN support which Y.1711 is > > > now addressing but might be some room for requirements > > > merge here at least). > > > > It isn't an issue of requirements; we are working > > from the same set of basic requirements for these > > solutions. It is IMHO a matter of perspective, as I > > explained above. > > > > --Tom > > > > > > > > > > > > Mark > > > _______________________________________________ > > > 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 > ------_=_NextPart_001_01C326C4.F6CD2692 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

I get the feeling that claiming the "wrong = approach to standards" is to "assume in a vaccuum" = sentences us to re-prove the validity of Murphy's law over and over = again.

Given the amound of experience we've accumulated with = label switching technologies, and more recently with label stacking, = I'd assume we have a body of knowledge and experience that "fills = the vaccuum".

cheers
Dave

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] =
> Sent: Friday, May 30, 2003 11:25 AM
> To: 'tnadeau@cisco.com'; pwe3@ietf.org
> Subject: RE: [PWE3] RE: Is PWE a layer?
>
>
>
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > Sent: Friday, May 30, 2003 8:28 AM
> > To: pwe3@ietf.org
> > Subject: RE: [PWE3] RE: Is PWE a = layer?
>
> [snipped]
>
> > 
> > > > To me it seems evident that the = fault detection
> > > > mechanism defined in Y.1711 is = superior to that of
> > > > LSP Ping, no matter what Tom's = 25 happy customers
> > > > say.
> > >
> > > This seems like a valid = assertion.
> >
> >     Again, this comes down = to an argument over
> > architectural purity versus practicality = of use
> > and implementation.  On the one hand = the other standards
> > body asserts that it is okay to write = standards in
> > a vaccuum making all sorts of convenient = assumptions
> > which were found to be wrong once, so who = is to say
> > that they won't be again? Meanwhile, we = are re-writing
> > our code and redeplying hardware based on = these
> > standards? OTOH, while I will be the first = to admit
> > the mechanisms being proposed here are not = perfect,
> > they have specific practical use today and = tomorrow
> > for sure.
> >
>
> Tom,
>
> I am not sure I understand your argument. If we = want to check
> the state of a PW, there are two ways to do = it:
>
> 1. The ingress PE sends an LSP-Ping message and = declares a
> failure if it doesn't receive a reply
>
> 2. The ingress PE sends CV messages at regular = intervals and
> the egress PE declares a failure if it doesn't = receive
> several messages in a row.
>
> My assertion was that 2) is superior to 1) for = obvious
> technical reasons. You counter with two = arguments:
>
> a) That 2) is an attempt to "write = standards in a vaccuum
> making all sorts of convenient assumptions = which were found
> to be wrong once, so who is to say that they = won't be again?"
>
> b)There are existing implementations for 1) and = we don't want
> to rewrite code and redeploy hardware.
>
> Regarding a), it would help if you could = identify why
> mechanism 2) wouldn't work for connectivity = verification of
> PW. I don't see why the "convenient = assumptions" that you
> refer to have any relevance to this = case.
>
> Regarding b), I don't see why that is relevant = at all. The
> whole PWE stndardization work is still based on = draft
> documents. The fact that code may need to be = rewritten is the
> risk that a vendor willingly accepts if he = decides to bring
> out a product based on proprietary = protocols.
>
> Finally, the issue is not whether it should be = one or the
> other. I haven't seen anyone argue that = LSP-Ping as defined
> in the VCCV draft is not a useful tool to have. = But there are
> several people who feel (strongly) that it = should be
> augmented with additional OAM tools for those = operators who need it.
>
> Peter
>
>
>
> > > > So what exactly is the problem = with adopting Y.1711
> > > > for PW OAM, as long as we = speciify that the CV
> > > > generation rate is configurable? = This would not
> > > > require any vendor to implement = the function in
> > > > ASICs or provide some other form = of HW acceleration.
> > >
> > > So putting aside the question should = we do any OAM at
> > > the PWE "layer" ;-) the = next issue is does that OAM
> > > capability need to be a robust = transport layer like
> > > fault detection mechanism; if so, = then will it work
> > > over other PSNs is the next question; = followed by does
> > > it have functionality that Y.1711 = does not (seems like
> > > it has some pretty good VPN support = which Y.1711 is
> > > now addressing but might be some room = for requirements
> > > merge here at least).
> >
> >     It isn't an issue of = requirements; we are working
> > from the same set of basic requirements = for these
> > solutions. It is IMHO a matter of = perspective, as I
> > explained above.
> >
> >     --Tom
> >
> >
> >
> > >
> > > Mark
> > > = _______________________________________________
> > > 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=
>

------_=_NextPart_001_01C326C4.F6CD2692-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: Is PWE a layer - thread summary Date: Fri, 30 May 2003 09:25:31 -0700 (PDT) Lines: 110 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D690C@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri May 30 18:27:47 2003 Return-path: To: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D690C@i2km07-ukbr.domain1.systemhost.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, --- neil.2.harrison@bt.com wrote: > Mark....How many layers do you think would be > required in MPLS? My guess is > not that many. If as an operator you make a decision that OAM is just **one** aspect of a proper CO-PKT-SW network, and therefore you will continue to run services, of a particular type, over an ATM/MPLS network you are probably not as likely to get "creative" with the use of layers, and the vendors providing equipment for such a network (more than likely the incumbent you already have) can very comfortably support your requirements. There is a well-known operator in the U.S., running FR over MPLS today, without the use of Y.1711, who has stated in the past quite a large number of layers (I won't get in to details because of confidentiality issues of which I am unsure where I stand). But as an example: One layer for restoration (multiple LSPs restored by a server layer LSP). One layer for traffic engineering and/or per class QoS One layer for the BGP network (BGP overlay over a TE core) One layer for the PE-PE base LSP One layer for each VPN over the PE-PE LSP And of course PWE (if that ends up being a layer) These are the kinds of network architectures (and the above is not even a worse case) that vendors who develop IP/MPLS products get presented with. One one hand saying each layer requires the same OAM makes the problem easier, because the implementor does not have to guess which of the myriad of layer options might be used. On the other hand it imposes a certain burden on each layer. At any rate, it is not my opinion of how many layers that are necessary that really counts, it is the operators opinion, and as you can see from above, the requirements vary greatly. In all MPLS networks (running VPNs) there is going to be at least 2 layers, we know this much from the VPN standards that are being ratified. In many MPLS networks there will be 3 layers, in a number I suspect there will be 4 layers; and in some networks - the number of layers will be certifiably pathological ;-) But hey, at least it is flexible ;-) Seriously, I don't have a problem if an operator wants to have lots of layers, that is one of the things I really like about MPLS - I really believe it has the power to create innovative architectures. It just becomes pathological if a variety of requirements are imposed on each layer. In addition, unless I misunderstand the behavior of FDI, then I am concerned about the implications if multiple layers injecting FDI concurrently, trying to percolate fault information up multiple layers, and do correlation. The potential for coupling problems and non-linearalities seems to be there. But it is also possible that I simply don't understand how it works - so I will try to study it some more. > The beauty of being able to create > an ad hoc LSP between 2 > points (as a server to some higher layer trail) from > an operators point of > view is that we can monitor the partition very > simply. There is a cost to flexibility, that has to be understood. Bound the flexibility, and the cost can be bounded. If the flexibility is not bounded by the operators, then implementors will have to make arbitary choices. You can take your chances with that, or you can go lay down some money at Monte Carlo - your choice. I would speculate that if SONET/SDH was not as bounded as it is, that it would cost even more than what it does (which BTW is less than packet solutions last time I checked - but you tell me, you would know best). > This type of > functionality is limited or complex when layers have > a fixed hierarchy > (check out some of the tandem connection monitoring > ideas for G.709 for > example). I flicked through G.709 and it wasn't obvious to me which section dealt with tandem connection monitoring, but I will take a closer look. Thanks for the pointer, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Implementation agreement for Y.1711-like OAM approach to PWE/MPLS (was: Is PWE a layer - thread) Date: Fri, 30 May 2003 10:27:05 -0700 (PDT) Lines: 52 Sender: pwe3-admin@ietf.org References: <004d01c326b8$f19ad540$854c1cac@dyn.interprise.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, Andy.Malis@vivacenetworks.com X-From: pwe3-admin@ietf.org Fri May 30 19:29:38 2003 Return-path: To: danny@tcb.net, jtpugac@qwest.com, stbryant@cisco.com In-Reply-To: <004d01c326b8$f19ad540$854c1cac@dyn.interprise.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Jack, If enough carriers and vendors are interested in pursuing this, then I think what you suggest would be very beneficial to the industry. It is possible another organization like the MPLS Forum is doing this - I don't know because I haven't been involved in it - I have copied Andy in case he knows (Andy we are discussing things such as applying a Y.1711 aproach to MPLS/PWE OAM, bounding the number of layers that it is applied to, and FR/ATM/MPLS OAM interworking). I suspect that because the real solution that some have expressed is applying this mechanism to MPLS and not to PWE, then this is the wrong working group to ultimately resolve this problem in. The best we can do within this working group is get in the way of something that is seen as undesirable at another "layer" - that being PWE. But before progressing this idea I would like to direct a few questions to the chairs: Danny, and Stewart. Danny/Stewart, 1) A Y.1711 approach to OAM seems not to be consistent with the way the IETF has historically approached solutions to these types of problems. As such, what is your view on whether a proposal such as this would be acceptable to the IESG, even if a rough consensus within the WG was achieved to progress it for PWE? 2) Is the development of an implementation agreement consistent with the current charter of the working group. Thanks, Mark --- Jack Pugaczewski wrote: > Then this looks like a great forum to get ideas out > and explore the proper > means for implementation aggrements. Now is the > time to define these > mechanism between Layer 2 (Frame Relay, ATM, > Ethernet, etc.) and MPLS. This > functionality will be essential in the deployment of > a quality network that > can be properly and efficiently maintained. > > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: Implementation agreement for Y.1711-like OAM approach to PWE/MPLS (was: Is PWE a layer - thread) Date: Fri, 30 May 2003 14:15:34 -0400 Lines: 291 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C326D7.764C198E" Cc: pwe3@ietf.org, Andy.Malis@vivacenetworks.com X-From: pwe3-admin@ietf.org Fri May 30 20:17:16 2003 Return-path: To: "'Mark Seery'" , danny@tcb.net, jtpugac@qwest.com, stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C326D7.764C198E Content-Type: text/plain; charset="iso-8859-1" Mark: Independent of the process and culture questions there are some technical issues to be addressed independent of the solutions, we're a few steps short of : 1) We require a mechanism to distinguish OAM flows in PWs. The discussion is moving in a direction whereby there is a requirement to support multiple flows or combinations of the same (LSP-PING, Y.1711, other) depending on operator sensibilities. 2) The mechanism needs to work and have useful OAM characteristics (aka fate sharing) in the presence of all known (or alluded to) ECMP mechanisms (which I believe uniquely impact PWs over MPLS unless folks have bizzare plans for L2TPv3 ;-). This means no reserved labels or appearance as an IP packet directly as MPLS/PW payload for any OAM tools, or aliasing as an IP packet. IMHO this pushes us directly into the MPLS PID space as the only tractable compromise solution that meets the criteria above (we needed more header bits somewhere and it has to be somthing new :-( ). It complicates life as PW control words now pretty much become mandatory. This has a number of benefits as it can also apply to MPLS as a layer independent of the PW application, so it would appear that both MPLS and PWs in general have a mechanism for muxing OAM (and possibly control) flows with payload. So the above being said, some practical steps that facilitate getting to your proposal are: 1) Agree on the above requirements 2) Devise a converged MPLS/PW PID approach that permits multiple OAM tools to be employed over PWs and LSPs 3) Get the requisite missing PIDs from IANA for tools we wish to have as candidiates cheers Dave > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: Friday, May 30, 2003 1:27 PM > To: danny@tcb.net; jtpugac@qwest.com; stbryant@cisco.com > Cc: pwe3@ietf.org; Andy.Malis@vivacenetworks.com > Subject: [PWE3] Implementation agreement for Y.1711-like OAM > approach to PWE/MPLS (was: Is PWE a layer - thread) > > > Jack, > > If enough carriers and vendors are interested in > pursuing this, then I think what you suggest would be > very beneficial to the industry. It is possible > another organization like the MPLS Forum is doing this > - I don't know because I haven't been involved in it - > I have copied Andy in case he knows (Andy we are > discussing things such as applying a Y.1711 aproach to > MPLS/PWE OAM, bounding the number of layers that it is > applied to, and FR/ATM/MPLS OAM interworking). > > I suspect that because the real solution that some > have expressed is applying this mechanism to MPLS and > not to PWE, then this is the wrong working group to > ultimately resolve this problem in. The best we can do > within this working group is get in the way of > something that is seen as undesirable at another > "layer" - that being PWE. > > But before progressing this idea I would like to > direct a few questions to the chairs: Danny, and > Stewart. > > Danny/Stewart, > > 1) A Y.1711 approach to OAM seems not to be consistent > with the way the IETF has historically approached > solutions to these types of problems. As such, what is > your view on whether a proposal such as this would be > acceptable to the IESG, even if a rough consensus within the > WG was achieved to progress it for PWE? > > 2) Is the development of an implementation agreement > consistent with the current charter of the working > group. > > Thanks, > Mark > > --- Jack Pugaczewski wrote: > > Then this looks like a great forum to get ideas out > > and explore the proper > > means for implementation aggrements. Now is the > > time to define these > > mechanism between Layer 2 (Frame Relay, ATM, > > Ethernet, etc.) and MPLS. This > > functionality will be essential in the deployment of > > a quality network that > > can be properly and efficiently maintained. > > > > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C326D7.764C198E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Implementation agreement for Y.1711-like OAM approach = to PWE/MPLS (was: Is PWE a layer - thread)

Mark:

Independent of the process and culture questions = there are some technical issues to be addressed independent of the = solutions, we're a few steps short of :

1) We require a mechanism to distinguish OAM flows in = PWs. The discussion is moving in a direction whereby there is a = requirement to support multiple flows or combinations of the same = (LSP-PING, Y.1711, other) depending on operator = sensibilities.

2) The mechanism needs to work and have useful OAM = characteristics (aka fate sharing) in the presence of all known (or = alluded to) ECMP mechanisms (which I believe uniquely impact PWs over = MPLS unless folks have bizzare plans for L2TPv3 ;-). This means no = reserved labels or appearance as an IP packet directly as MPLS/PW = payload for any OAM tools, or aliasing as an IP packet.

IMHO this pushes us directly into the MPLS PID space = as the only tractable compromise solution that meets the criteria above = (we needed more header bits somewhere and it has to be somthing new :-( = ). It complicates life as PW control words now pretty much become = mandatory.

This has a number of benefits as it can also apply to = MPLS as a layer independent of the PW application, so it would appear = that both MPLS and PWs in general have a mechanism for muxing OAM (and = possibly control) flows with payload.

So the above being said, some practical steps that = facilitate getting to your proposal  are:

1) Agree on the above requirements
2) Devise a converged MPLS/PW PID approach that = permits multiple OAM tools to be employed over PWs and LSPs
3) Get the requisite missing PIDs from IANA for = tools we wish to have as candidiates

cheers
Dave



> -----Original Message-----
> From: Mark Seery [mailto:mark@mseery.com]
> Sent: Friday, May 30, 2003 1:27 PM
> To: danny@tcb.net; jtpugac@qwest.com; = stbryant@cisco.com
> Cc: pwe3@ietf.org; = Andy.Malis@vivacenetworks.com
> Subject: [PWE3] Implementation agreement for = Y.1711-like OAM
> approach to PWE/MPLS (was: Is PWE a layer - = thread)
>
>
> Jack,
>
> If enough carriers and vendors are interested = in
> pursuing this, then I think what you suggest = would be
> very beneficial to the industry. It is = possible
> another organization like the MPLS Forum is = doing this
> - I don't know because I haven't been involved = in it -
> I have copied Andy in case he knows (Andy we = are
> discussing things such as applying a Y.1711 = aproach to
> MPLS/PWE OAM, bounding the number of layers = that it is
> applied to, and FR/ATM/MPLS OAM = interworking).
>
> I suspect that because the real solution that = some
> have expressed is applying this mechanism to = MPLS and
> not to PWE, then this is the wrong working = group to
> ultimately resolve this problem in. The best we = can do
> within this working group is get in the way = of
> something that is seen as undesirable at = another
> "layer" - that being PWE.
>
> But before progressing this idea I would like = to
> direct a few questions to the chairs: Danny, = and
> Stewart.
>
> Danny/Stewart,
>
> 1) A Y.1711 approach to OAM seems not to be = consistent
> with the way the IETF has historically = approached
> solutions to these types of problems. As such, = what is
> your view on whether a proposal such as this = would be
> acceptable to the IESG, even if a rough = consensus within the
> WG was achieved to progress it for PWE?
>
> 2) Is the development of an implementation = agreement
> consistent with the current charter of the = working
> group.
>
> Thanks,
> Mark
>
> --- Jack Pugaczewski <jtpugac@qwest.com> = wrote:
> > Then this looks like a great forum to get = ideas out
> > and explore the proper
> > means for implementation aggrements.  = Now is the
> > time to define these
> > mechanism between Layer 2 (Frame Relay, = ATM,
> > Ethernet, etc.) and MPLS.  = This
> > functionality will be essential in the = deployment of
> > a quality network that
> > can be properly and efficiently = maintained.
> >
> > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C326D7.764C198E-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 14:26:04 -0400 Organization: Cisco Systems Lines: 164 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri May 30 20:27:05 2003 Return-path: To: "'Busschbach, Peter B \(Peter\)'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Friday, May 30, 2003 11:25 AM > To: 'tnadeau@cisco.com'; pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Friday, May 30, 2003 8:28 AM > > To: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > [snipped] > > > > > > > To me it seems evident that the fault detection > > > > mechanism defined in Y.1711 is superior to that of > > > > LSP Ping, no matter what Tom's 25 happy customers > > > > say. > > > > > > This seems like a valid assertion. > > > > Again, this comes down to an argument over > > architectural purity versus practicality of use > > and implementation. On the one hand the other standards > > body asserts that it is okay to write standards in > > a vaccuum making all sorts of convenient assumptions > > which were found to be wrong once, so who is to say > > that they won't be again? Meanwhile, we are re-writing > > our code and redeplying hardware based on these > > standards? OTOH, while I will be the first to admit > > the mechanisms being proposed here are not perfect, > > they have specific practical use today and tomorrow > > for sure. > > > > Tom, > > I am not sure I understand your argument. If we want to check > the state of a PW, there are two ways to do it: > > 1. The ingress PE sends an LSP-Ping message and declares a > failure if it doesn't receive a reply > > 2. The ingress PE sends CV messages at regular intervals and > the egress PE declares a failure if it doesn't receive > several messages in a row. > > My assertion was that 2) is superior to 1) for obvious > technical reasons. You counter with two arguments: > > a) That 2) is an attempt to "write standards in a vaccuum > making all sorts of convenient assumptions which were found > to be wrong once, so who is to say that they won't be again?" > > b)There are existing implementations for 1) and we don't want > to rewrite code and redeploy hardware. > > Regarding a), it would help if you could identify why > mechanism 2) wouldn't work for connectivity verification of > PW. It will. I am not arguing that it will not. Periodic CV is what I am advocating, just NOT with Y.1711. There is nothing wrong with using the other mechanisms we have discussed for this. > I don't see why the "convenient assumptions" that you > refer to have any relevance to this case. The authors of Y.1711 originally convienently disregarded LDP-signalled LSPs, which we all know is used in about %95 of MPLS deployments. In a vaccuum, it apparently made sense to disregard this small point in exchange for focusing on p2p LSPs. Yes, it has been pointed out by the authors that this is incorrect now, but it IS still an ITU recommendation nonetheless. > Regarding b), I don't see why that is relevant at all. The > whole PWE stndardization work is still based on draft > documents. The fact that code may need to be rewritten is the > risk that a vendor willingly accepts if he decides to bring > out a product based on proprietary protocols. But the base MPLS stuff is not. Since PWE runs over MPLS, it is very relevant to re-use what is there as much as possible to preserve operators' investments in hardware and OSS used to manage this rather than re-invent the wheel. In fact, isn't this part of the reason why we are tryin to emulate VCs over existing MPLS/IP cores? > Finally, the issue is not whether it should be one or the > other. I haven't seen anyone argue that LSP-Ping as defined > in the VCCV draft is not a useful tool to have. > But there are several people who feel (strongly) that it should be > augmented with additional OAM tools for those operators who need it. I am totally in favor of this approach. In fact, I have been advocating an evolutionary approach for over a year now that includes lots of tools and techniques, not any single one. There is no one tool that is applicable to any one application of MPLS; instead, many need to be used in concert to satisfy all of the requirements. Meanwhile, those who were proponents of Y.1711 were arguing against this approach in favor of Y.1711 being used as the sole and ultimate OAM solution. Just think about this. If we had drank the Y.1711 Koolaid 2 years ago, we would have all re-designed our devices/OSS for a tool that does not apply to %90+ of the cases being used. --Tom > Peter > > > > > > > So what exactly is the problem with adopting Y.1711 > > > > for PW OAM, as long as we speciify that the CV > > > > generation rate is configurable? This would not > > > > require any vendor to implement the function in > > > > ASICs or provide some other form of HW acceleration. > > > > > > So putting aside the question should we do any OAM at > > > the PWE "layer" ;-) the next issue is does that OAM > > > capability need to be a robust transport layer like > > > fault detection mechanism; if so, then will it work > > > over other PSNs is the next question; followed by does > > > it have functionality that Y.1711 does not (seems like > > > it has some pretty good VPN support which Y.1711 is > > > now addressing but might be some room for requirements > > > merge here at least). > > > > It isn't an issue of requirements; we are working > > from the same set of basic requirements for these > > solutions. It is IMHO a matter of perspective, as I > > explained above. > > > > --Tom > > > > > > > > > > > > Mark > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: Implementation agreement for Y.1711-like OAM approach to PWE/MPLS (was: Is PWE a layer - thread) Date: Fri, 30 May 2003 22:47:25 +0100 Lines: 17 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, Andy.Malis@vivacenetworks.com X-From: pwe3-admin@ietf.org Fri May 30 23:51:49 2003 Return-path: To: mark@mseery.com, danny@tcb.net, jtpugac@qwest.com, stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mark, > If enough carriers and vendors are interested in > pursuing this, then I think what you suggest would be > very beneficial to the industry. It is possible > another organization like the MPLS Forum is doing this > - I don't know because I haven't been involved in it - > I have copied Andy in case he knows (Andy we are > discussing things such as applying a Y.1711 aproach to > MPLS/PWE OAM, bounding the number of layers that it is > applied to, and FR/ATM/MPLS OAM interworking). NH=> Your comments here seem to indicate that you regard Y.1711, or maybe any outputs from the ITU, as something other bodies can pass judgement on as they see fit. Is this correct? Note SG13 have already got a draft Rec on ATM/MPLS OAM network and service interworking in the pipeline. Shall we also check to see if this is fit for purpose too? regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: Implementation agreement for Y.1711-like OAM approach to PWE/MPLS (was: Is PWE a layer - thread) Date: Fri, 30 May 2003 22:47:26 +0100 Lines: 14 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org, Andy.Malis@vivacenetworks.com X-From: pwe3-admin@ietf.org Fri May 30 23:53:03 2003 Return-path: To: mark@mseery.com, danny@tcb.net, jtpugac@qwest.com, stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mark, > Danny/Stewart, > > 1) A Y.1711 approach to OAM seems not to be consistent > with the way the IETF has historically approached > solutions to these types of problems. NH=> Can I just do a sanity check on what you have just requested. IETF are now working on co-pkt-sw and co cct-sw technologies and you think this has some 'historical precedent' in IETF from which you feel the chairs can give some value judgement? This is clearly not the case IMO. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: Implementation agreement for Y.1711-like OAM approach to PWE/MPLS (was: Is PWE a layer - thread) Date: Fri, 30 May 2003 16:39:15 -0700 (PDT) Lines: 64 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, Andy.Malis@vivacenetworks.com X-From: pwe3-admin@ietf.org Sat May 31 01:40:53 2003 Return-path: To: David Allan , "'Mark Seery'" , danny@tcb.net, jtpugac@qwest.com, stbryant@cisco.com In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Dave, Thanks for the feedback much appreciated. Mark --- David Allan wrote: > Mark: > > Independent of the process and culture questions > there are some technical > issues to be addressed independent of the solutions, > we're a few steps short > of : > > 1) We require a mechanism to distinguish OAM flows > in PWs. The discussion is > moving in a direction whereby there is a requirement > to support multiple > flows or combinations of the same (LSP-PING, Y.1711, > other) depending on > operator sensibilities. > > 2) The mechanism needs to work and have useful OAM > characteristics (aka fate > sharing) in the presence of all known (or alluded > to) ECMP mechanisms (which > I believe uniquely impact PWs over MPLS unless folks > have bizzare plans for > L2TPv3 ;-). This means no reserved labels or > appearance as an IP packet > directly as MPLS/PW payload for any OAM tools, or > aliasing as an IP packet. > > IMHO this pushes us directly into the MPLS PID space > as the only tractable > compromise solution that meets the criteria above > (we needed more header > bits somewhere and it has to be somthing new :-( ). > It complicates life as > PW control words now pretty much become mandatory. > > This has a number of benefits as it can also apply > to MPLS as a layer > independent of the PW application, so it would > appear that both MPLS and PWs > in general have a mechanism for muxing OAM (and > possibly control) flows with > payload. > > So the above being said, some practical steps that > facilitate getting to > your proposal are: > > 1) Agree on the above requirements > 2) Devise a converged MPLS/PW PID approach that > permits multiple OAM tools > to be employed over PWs and LSPs > 3) Get the requisite missing PIDs from IANA for > tools we wish to have as > candidiates > > cheers > Dave From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: Implementation agreement for Y.1711-like OAM approach to PWE/MPLS (was: Is PWE a layer - thread) Date: Fri, 30 May 2003 16:41:23 -0700 (PDT) Lines: 39 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6912@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, Andy.Malis@vivacenetworks.com X-From: pwe3-admin@ietf.org Sat May 31 01:44:11 2003 Return-path: To: neil.2.harrison@bt.com, mark@mseery.com, danny@tcb.net, jtpugac@qwest.com, stbryant@cisco.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6912@i2km07-ukbr.domain1.systemhost.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sorry Neil, did not mean to imply that. I did not mean to imply that the IETF could tell the ITU what to standardize - in fact quite the opposite. What I meant to ask was whether the IESG would be likely to adopt an approach like this as its own. if it was an inappropriate question to ask, then my apologies again. Mark --- neil.2.harrison@bt.com wrote: > Mark, > > If enough carriers and vendors are interested in > > pursuing this, then I think what you suggest would > be > > very beneficial to the industry. It is possible > > another organization like the MPLS Forum is doing > this > > - I don't know because I haven't been involved in > it - > > I have copied Andy in case he knows (Andy we are > > discussing things such as applying a Y.1711 > aproach to > > MPLS/PWE OAM, bounding the number of layers that > it is > > applied to, and FR/ATM/MPLS OAM interworking). > NH=> Your comments here seem to indicate that you > regard Y.1711, or maybe > any outputs from the ITU, as something other bodies > can pass judgement on as > they see fit. Is this correct? Note SG13 have > already got a draft Rec on > ATM/MPLS OAM network and service interworking in the > pipeline. Shall we > also check to see if this is fit for purpose too? > > regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: Implementation agreement for Y.1711-like OAM approach to PWE/MPLS (was: Is PWE a layer - thread) Date: Fri, 30 May 2003 16:41:54 -0700 (PDT) Lines: 28 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6913@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, Andy.Malis@vivacenetworks.com X-From: pwe3-admin@ietf.org Sat May 31 01:46:01 2003 Return-path: To: neil.2.harrison@bt.com, mark@mseery.com, danny@tcb.net, jtpugac@qwest.com, stbryant@cisco.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6913@i2km07-ukbr.domain1.systemhost.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Fair point. Mark --- neil.2.harrison@bt.com wrote: > Mark, > > > > Danny/Stewart, > > > > 1) A Y.1711 approach to OAM seems not to be > consistent > > with the way the IETF has historically approached > > solutions to these types of problems. > NH=> Can I just do a sanity check on what you have > just requested. IETF are > now working on co-pkt-sw and co cct-sw technologies > and you think this has > some 'historical precedent' in IETF from which you > feel the chairs can give > some value judgement? This is clearly not the case > IMO. > > regards, Neil > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: RE: Is PWE a layer? Date: Fri, 30 May 2003 21:09:56 -0700 (PDT) Lines: 55 Sender: pwe3-admin@ietf.org References: <00c501c326d8$f11ac240$6601a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Sat May 31 06:13:48 2003 Return-path: To: tnadeau@cisco.com In-Reply-To: <00c501c326d8$f11ac240$6601a8c0@amer.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --- "Thomas D. Nadeau" wrote: [SNIP] >> I am totally in favor of this approach. In fact, I have been advocating an evolutionary approach for over a year now that includes lots of tools and techniques, not any single one. << Tom, that seems like a constructive position to take, thanks for offering that. That being the case, how do you feel about Dave's suggestion of the following: "1) We require a mechanism to distinguish OAM flows in PWs. The discussion is moving in a direction whereby there is a requirement to support multiple flows or combinations of the same (LSP-PING, Y.1711, other) depending on operator sensibilities. 2) The mechanism needs to work and have useful OAM characteristics (aka fate sharing) in the presence of all known (or alluded to) ECMP mechanisms (which I believe uniquely impact PWs over MPLS unless folks have bizzare plans for L2TPv3 ;-). This means no reserved labels or appearance as an IP packet directly as MPLS/PW payload for any OAM tools, or aliasing as an IP packet. IMHO this pushes us directly into the MPLS PID space as the only tractable compromise solution that meets the criteria above (we needed more header bits somewhere and it has to be somthing new :-( ). It complicates life as PW control words now pretty much become mandatory. This has a number of benefits as it can also apply to MPLS as a layer independent of the PW application, so it would appear that both MPLS and PWs in general have a mechanism for muxing OAM (and possibly control) flows with payload. So the above being said, some practical steps that facilitate getting to your proposal are: 1) Agree on the above requirements 2) Devise a converged MPLS/PW PID approach that permits multiple OAM tools to be employed over PWs and LSPs 3) Get the requisite missing PIDs from IANA for tools we wish to have as candidiates " -Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Sat, 31 May 2003 09:31:02 -0400 Organization: Cisco Systems Lines: 80 Sender: pwe3-admin@ietf.org References: <20030531040956.97486.qmail@web13506.mail.yahoo.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Sat May 31 15:32:30 2003 Return-path: To: "'Mark Seery'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20030531040956.97486.qmail@web13506.mail.yahoo.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mark Seery > Sent: Saturday, May 31, 2003 12:10 AM > To: tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > --- "Thomas D. Nadeau" wrote: > [SNIP] > > >> I am totally in favor of this approach. In fact, > I have been advocating an evolutionary approach for > over > a year now that includes lots of tools and techniques, > not any single one. << > > Tom, that seems like a constructive position to take, > thanks for offering that. > > That being the case, how do you feel about Dave's > suggestion of the following: > > "1) We require a mechanism to distinguish OAM flows in > PWs. The discussion is moving in a direction whereby > there is a requirement to support multiple flows or > combinations of the same (LSP-PING, Y.1711, other) depending > on operator sensibilities. I am in favor of George Swallow's original PID proposal that took this into account. I believe that Dave's proposal was along those lines with the exception of a few bits. --Tom > 2) The mechanism needs to work and have useful OAM > characteristics (aka fate sharing) in the presence of all > known (or alluded to) ECMP mechanisms (which I believe > uniquely impact PWs over MPLS unless folks have bizzare plans > for L2TPv3 ;-). This means no reserved labels or appearance > as an IP packet directly as MPLS/PW payload for any OAM > tools, or aliasing as an IP packet. > > IMHO this pushes us directly into the MPLS PID space > as the only tractable compromise solution that meets > the criteria above (we needed more header bits > somewhere and it has to be somthing new :-( ). It > complicates life as PW control words now pretty much > become mandatory. > > This has a number of benefits as it can also apply to > MPLS as a layer independent of the PW application, so > it would appear that both MPLS and PWs in general have > a mechanism for muxing OAM (and possibly control) > flows with payload. > > So the above being said, some practical steps that > facilitate getting to your proposal are: > > 1) Agree on the above requirements > 2) Devise a converged MPLS/PW PID approach that > permits multiple OAM tools to be employed over PWs and > LSPs > 3) Get the requisite missing PIDs from IANA for tools > we wish to have as candidiates " > > -Mark > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >