From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Mon, 2 Jun 2003 09:46:24 -0400 Lines: 318 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3290D.5B6C78D8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 02 15:51:11 2003 Return-path: To: "'tnadeau@cisco.com'" , "'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_01C3290D.5B6C78D8 Content-Type: text/plain; charset="iso-8859-1" Tom: You're correct. IMHO PPP DLL is fine as a protocol authority. For reference, the key deltas between the proposals were: - presence of an authority ID, such that PIDs other than PPP DLL could be used. The intent was not to produce an overlapping nightmare, but to provide the option of using the IP protocol identifier, and collapse out the IP header (similar to VCCV). - presence of the "router alert" bit (as a replacement for the MPLS RA label, and new functionality unique to multi-hop non-MPLS PWs), which is orthogonal to the specific problem being solved but falls into the same general category of addressing ECMP issues. I'd be happy to discuss these as separate topics. cheers Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Saturday, May 31, 2003 9:31 AM > To: 'Mark Seery' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > -----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 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C3290D.5B6C78D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

Tom:

You're correct. IMHO PPP DLL is fine as a protocol = authority.

For reference, the key deltas between the proposals = were:

- presence of an authority ID, such that PIDs other = than PPP DLL could be used. The intent was not to produce an = overlapping nightmare, but to provide the option of using the IP = protocol identifier, and collapse out the IP header (similar to = VCCV).

- presence of the "router alert" bit (as a = replacement for the MPLS RA label, and new functionality unique to = multi-hop non-MPLS PWs), which is orthogonal to the specific problem = being solved but falls into the same general category of addressing = ECMP issues.

I'd be happy to discuss these as separate = topics.

cheers
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Saturday, May 31, 2003 9:31 AM
> To: 'Mark Seery'
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] RE: Is PWE a layer?
>
>
>
>
> > -----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" = <tnadeau@cisco.com> 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=
> >
>
>
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C3290D.5B6C78D8-- 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, 3 Jun 2003 08:14:56 -0400 Organization: Cisco Systems Lines: 430 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 Tue Jun 03 14:19:50 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: 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, Just catching up on some old emails... > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Busschbach, Peter B (Peter) > Sent: Thursday, May 29, 2003 6:02 PM > To: 'Mark Seery'; David Allan > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > 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. You can run LSP ping in a one-way mode (no reply), just as you can run Y.1711, and have the downstream LSR determine that that direction is not working. You can also run it in normal mode from both sides of the PW. > 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. It seems evident to me that the way to go is to listen to what the market and customers say are the tools and techniques they want. > 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? A few reasons. First, Y.1711 is NOT currently specified this way, thus adopting it still requires the interval regardless of what patches/fixes are in the works. Second, as I just pointed out, you can do the same things based on mechanisms defined here at the IETF. Third, the mechanisms defined by the IETF that are already in use for other MPLS applications, can be re-used for PWs, thus obviating the need to implement/manage another mechanism for just PWE implementations. --Tom > 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 > > > _______________________________________________ > 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, 3 Jun 2003 08:23:07 -0400 Organization: Cisco Systems Lines: 76 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 Tue Jun 03 14:24:21 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: Mark Seery [mailto:mark@mseery.com] > 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 don't think that we need to define more than one mechanism for the reasons I have explained my my prior posting. My customers certainly don't want more than one mechanism. Also, before any conclusion is drawn, I suggest asking the WG for consensus on such a decision. --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 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: RE: Is PWE a layer? Date: Tue, 3 Jun 2003 07:33:34 -0500 Lines: 452 Sender: pwe3-admin@ietf.org References: <037401c329c9$bec9d710$6601a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Tue Jun 03 14:33:56 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: <037401c329c9$bec9d710$6601a8c0@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by uswgco34.uswest.com id h53CXbZU021156 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h53CXfB08372 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h53CaBB08585 Status: O Great points and fully agree ! PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Thomas D. Nadeau > Sent: Tuesday, June 03, 2003 7:15 AM > To: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > Hi, > > Just catching up on some old emails... > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Busschbach, Peter B (Peter) > > Sent: Thursday, May 29, 2003 6:02 PM > > To: 'Mark Seery'; David Allan > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > 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. > > You can run LSP ping in a one-way > mode (no reply), just as you can run Y.1711, and have the > downstream LSR determine that that direction is not working. > You can also run it in normal mode from both sides > of the PW. > > > 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. > > It seems evident to me that the way to go is to > listen to what the market and customers say are the tools > and techniques they want. > > > 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? > > A few reasons. First, Y.1711 is NOT currently specified > this way, thus adopting it still requires the interval regardless > of what patches/fixes are in the works. Second, as I just > pointed out, you can do the same things based on mechanisms > defined here at the IETF. Third, the mechanisms defined by the > IETF that are already in use for other MPLS applications, > can be re-used for PWs, thus obviating the need to implement/manage > another mechanism for just PWE implementations. > > --Tom > > > > > 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=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: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Tue, 3 Jun 2003 10:01:22 -0400 Lines: 1258 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C329D8.9D3D66AC" X-From: pwe3-admin@ietf.org Tue Jun 03 16:05:24 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_01C329D8.9D3D66AC Content-Type: text/plain; charset="iso-8859-1" Tom: The difference in the proposals IMO is that 1711 CV and FEC-CV PDUs are designed to be fully processed in more or less the same number of cycles it takes to identify that you've received an LSP ping packet. (verify BIP 16, if function code x compare field y and you are done). That LSP PING can run in one way mode doesn't change this. It should stick to ad-hoc ping/loopback, which it is good at. Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, June 03, 2003 8:15 AM > To: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > Hi, > > Just catching up on some old emails... > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Busschbach, Peter B (Peter) > > Sent: Thursday, May 29, 2003 6:02 PM > > To: 'Mark Seery'; David Allan > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > 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. > > You can run LSP ping in a one-way > mode (no reply), just as you can run Y.1711, and have the > downstream LSR determine that that direction is not working. > You can also run it in normal mode from both sides of the PW. > > > 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. > > It seems evident to me that the way to go is to > listen to what the market and customers say are the tools > and techniques they want. > > > 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? > > A few reasons. First, Y.1711 is NOT currently specified > this way, thus adopting it still requires the interval > regardless of what patches/fixes are in the works. Second, as I just > pointed out, you can do the same things based on mechanisms > defined here at the IETF. Third, the mechanisms defined by the > IETF that are already in use for other MPLS applications, > can be re-used for PWs, thus obviating the need to implement/manage > another mechanism for just PWE implementations. > > --Tom > > > > > 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 > > > > > _______________________________________________ > > 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_01C329D8.9D3D66AC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

Tom:

The difference in the proposals IMO is that 1711 CV = and FEC-CV PDUs are designed to be fully processed in more or less the = same number of cycles it takes to identify that you've received an LSP = ping packet. (verify BIP 16, if function code x compare field y and you = are done).

That LSP PING can run in one way mode doesn't change = this. It should stick to ad-hoc ping/loopback, which it is good = at.

Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Tuesday, June 03, 2003 8:15 AM
> To: pwe3@ietf.org
> Subject: RE: [PWE3] RE: Is PWE a layer?
>
>
>
>       Hi,
>
>       Just catching up = on some old emails...
>
> > -----Original Message-----
> > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] = On
> > Behalf Of Busschbach, Peter B = (Peter)
> > Sent: Thursday, May 29, 2003 6:02 = PM
> > To: 'Mark Seery'; David Allan
> > Cc: pwe3@ietf.org
> > Subject: RE: [PWE3] RE: Is PWE a = layer?
> >
> >
> > 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.
>
>       You can run LSP = ping in a one-way
> mode (no reply), just as you can run Y.1711, = and have the
> downstream LSR determine that that direction is = not working.
> You can also run it in normal mode from both = sides of the PW.
> 
> > 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.
>
>       It seems evident = to me that the way to go is to
> listen to what the market and customers say are = the tools
> and techniques they want.
>
> > 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?
>      
>       A few reasons. = First, Y.1711 is NOT currently specified
> this way, thus adopting it still requires the = interval
> regardless of what patches/fixes are in the = works. Second, as I just
> pointed out, you can do the same things based = on mechanisms
> defined here at the IETF.  Third, the = mechanisms defined by the
> IETF that are already in use for other MPLS = applications,
> can be re-used for PWs, thus obviating the need = to implement/manage
> another mechanism for just PWE = implementations.
>
>       --Tom
>
>
>
> > 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=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.
> > >
> > > >
> > > <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. = <<
> > >
> > > 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=
>

------_=_NextPart_001_01C329D8.9D3D66AC-- 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: Tue, 3 Jun 2003 10:26:32 -0400 Lines: 462 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Tue Jun 03 16:29:57 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: Tuesday, June 03, 2003 8:15 AM > To: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > Hi, > > Just catching up on some old emails... > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Busschbach, Peter B (Peter) > > Sent: Thursday, May 29, 2003 6:02 PM > > To: 'Mark Seery'; David Allan > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > 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. > > You can run LSP ping in a one-way > mode (no reply), just as you can run Y.1711, and have the > downstream LSR determine that that direction is not working. > You can also run it in normal mode from both sides > of the PW. > > > 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. > > It seems evident to me that the way to go is to > listen to what the market and customers say are the tools > and techniques they want. > > > 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? > > A few reasons. First, Y.1711 is NOT currently specified > this way, thus adopting it still requires the interval regardless > of what patches/fixes are in the works. Second, as I just > pointed out, you can do the same things based on mechanisms > defined here at the IETF. Third, the mechanisms defined by the > IETF that are already in use for other MPLS applications, > can be re-used for PWs, thus obviating the need to implement/manage > another mechanism for just PWE implementations. > > --Tom > Tom, It seems that we are moving towards consensus. As I have stated in earlier emails, my main concern is with the fault detection mechanism that we specify. If we can agree on the need for a one-way, perdiodic check, we have made progress. At this point, I don't care whether the Connection Verification message is an LSP Ping message or a Y.1711 CV message. Or better, I think the Y.1711 CV message requires less processing, but I have no reason to believe that an LSP Ping message could not serve the same purpose. Do you plan to add the one-way, periodic mode for LSP Ping to your VCCV document? Peter > > > > 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 > > > > > _______________________________________________ > > 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: George Swallow Subject: Re: RE: Is PWE a layer? Date: Tue, 03 Jun 2003 11:12:30 -0400 Lines: 12 Sender: pwe3-admin@ietf.org References: Cc: "'tnadeau@cisco.com'" , pwe3@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Tue Jun 03 17:16:58 2003 Return-path: X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "Busschbach, Peter B (Peter)" In-reply-to: Your message of "Tue, 03 Jun 2003 10:26:32 EDT." Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Do you plan to add the one-way, periodic mode for LSP Ping to your > VCCV document? The one-way mode is part of LSP-Ping. But some details on how to use it for CV need to be added to VCCV. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: RE: Is PWE a layer? Date: Tue, 3 Jun 2003 11:30:57 -0400 Organization: Cisco Systems Lines: 519 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 Tue Jun 03 17:33:00 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: Tuesday, June 03, 2003 10:27 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: Tuesday, June 03, 2003 8:15 AM > > To: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > Hi, > > > > Just catching up on some old emails... > > > > > -----Original Message----- > > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > > Behalf Of Busschbach, Peter B (Peter) > > > Sent: Thursday, May 29, 2003 6:02 PM > > > To: 'Mark Seery'; David Allan > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > 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. > > > > You can run LSP ping in a one-way > > mode (no reply), just as you can run Y.1711, and have the > downstream > > LSR determine that that direction is not working. You can > also run it > > in normal mode from both sides of the PW. > > > > > 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. > > > > It seems evident to me that the way to go is to > > listen to what the market and customers say are the tools > > and techniques they want. > > > > > 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? > > > > A few reasons. First, Y.1711 is NOT currently specified > > this way, thus adopting it still requires the interval > regardless of > > what patches/fixes are in the works. Second, as I just pointed out, > > you can do the same things based on mechanisms defined here at the > > IETF. Third, the mechanisms defined by the IETF that are > already in > > use for other MPLS applications, can be re-used for PWs, thus > > obviating the need to implement/manage another mechanism > for just PWE > > implementations. > > > > --Tom > > > > Tom, > Hi Peter, > It seems that we are moving towards consensus. As I have > stated in earlier emails, my main concern is with the fault > detection mechanism that we specify. If we can agree on the > need for a one-way, perdiodic check, we have made progress. > At this point, I don't care whether the Connection > Verification message is an LSP Ping message or a Y.1711 CV > message. Or better, I think the Y.1711 CV message requires > less processing, but I have no reason to believe that an LSP > Ping message could not serve the same purpose. Excellent. > Do you plan to add the one-way, periodic mode for LSP Ping to > your VCCV document? I agree with you that a one-way mechanism is needed. As I stated earlier, one is available in LSP ping. Since VCCV uses LSP ping as a payload type, it can thus leverage this mode as well. However, based on your suggestion, we should add some text to the draft that explains this more explicitly. --Tom > Peter > > > > > > > > > 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 > > > > > > > _______________________________________________ > > > 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: Mark Seery Subject: PWE OAM Resolution / MPLS PID Date: Tue, 3 Jun 2003 09:06:39 -0700 (PDT) Lines: 50 Sender: pwe3-admin@ietf.org References: <20030531040956.97486.qmail@web13506.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Tue Jun 03 18:09:11 2003 Return-path: To: pwe3@ietf.org In-Reply-To: <20030531040956.97486.qmail@web13506.mail.yahoo.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 It was suggested to me that it would be advisable to repost Dave Allan's suggestion under a different subject line as many people have stopped listening to the is PWE a layer thread. So here it is again.... Comments please. Mark Dave's proposal: 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 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: PWE Service interworking Date: Tue, 3 Jun 2003 09:54:57 -0700 (PDT) Lines: 43 Sender: pwe3-admin@ietf.org References: <20030603160639.25199.qmail@web13508.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Tue Jun 03 18:58:17 2003 Return-path: To: pwe3@ietf.org In-Reply-To: <20030603160639.25199.qmail@web13508.mail.yahoo.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 It has been stated that service interworking is not part of the current charter. This might be appropriate, but I believe some consideration to this issue is advisable, most especially the encapsulations fixed on in the standards. My best current view of the situation is that PWE is an adaptation layer in both the IP and MPLS cases, and in the MPLS case, a 1:1 mapping between attachment circuits and unique LSPs (i.e. not the PSN LSP) is also provided; in the IP case PWE provides a multiplexing field rather than creating a new layer as it does in the MPLS case. As such, I have no philisophical problem with viewing PW as an adaptation layer that is equivalent to 1490 over FR, 1483 over ATM, AAL1 over ATM, or AAl5 over ATM. Therefore, to me the test is whether PW can interwork with 1490, 1483, AAL1, and AAL5. This I imagine is mostly a function of whether the encaps are defined for PW in such a way that interworking is possible without too many contortions (0 being desireable) I understand the argument that by placing too much functionality in the PW adaption process, then PW runs the risk of evolving into being more than a minimalist adaptation - I am still study the implications of this, but for now my main concern is that encaps chosen for x/PW services enables interworking with existing service networks that use 1490, 1483, AAL1, and AAL5. So even though authors of such encaps are not bound by the current charter to make an assessment of this, it would seem to me to be valuable if they did before these encaps become further entrenched in service networks. Is this being considered already in encap specifications? Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE Service interworking Date: Tue, 3 Jun 2003 10:25:49 -0700 (PDT) Lines: 9 Sender: pwe3-admin@ietf.org References: <20030603165457.50016.qmail@web13504.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Tue Jun 03 19:30:00 2003 Return-path: To: pwe3@ietf.org In-Reply-To: <20030603165457.50016.qmail@web13504.mail.yahoo.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 would be curious to know whether encaps authors looked at existing adaptations (1490, 1483, AAL1, AAL5) and decided they were unsuitable for some reason. An historical curiousity at this point (within this organization) I guess..... Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: PWE Service interworking Date: Tue, 03 Jun 2003 13:34:30 -0400 Organization: Alcatel Networks Corporaton Lines: 67 Sender: pwe3-admin@ietf.org References: <20030603165457.50016.qmail@web13504.mail.yahoo.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 Jun 03 19:35:13 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Mark Seery 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 Mark, in service interworking, there is one case in which one should be able to identify more than one protocol by inspecting the PW header. This is the case where each L2 access layer is terminated at the PE. A CPE running RFC 2684 (obsoletes 1483) or RFC 2427 (obsoletes 1490) may route more than one network layer protocol, or may combine a routed protocol and a bridged protocol in the same VC. We need to be able to interwork with this case, similar to FR/ATM service interworking (FRF.8.1). It is my opinion that the proper way to addres this case is to add multiprotocol support to the PW/MPLS PID in a way compatible with the above RFC's. I am planning to post a proposal on this soon. Mustapha. ------------ Mark Seery wrote: > It has been stated that service interworking is not > part of the current charter. This might be > appropriate, but I believe some consideration to this > issue is advisable, most especially the encapsulations > fixed on in the standards. > > My best current view of the situation is that PWE is > an adaptation layer in both the IP and MPLS cases, and > in the MPLS case, a 1:1 mapping between attachment > circuits and unique LSPs (i.e. not the PSN LSP) is > also provided; in the IP case PWE provides a > multiplexing field rather than creating a new layer as > it does in the MPLS case. > > As such, I have no philisophical problem with viewing > PW as an adaptation layer that is equivalent to 1490 > over FR, 1483 over ATM, AAL1 over ATM, or AAl5 over > ATM. Therefore, to me the test is whether PW can > interwork with 1490, 1483, AAL1, and AAL5. This I > imagine is mostly a function of whether the encaps are > defined for PW in such a way that interworking is > possible without too many contortions (0 being > desireable) > > I understand the argument that by placing too much > functionality in the PW adaption process, then PW runs > the risk of evolving into being more than a minimalist > adaptation - I am still study the implications of > this, but for now my main concern is that encaps > chosen for x/PW services enables interworking with > existing service networks that use 1490, 1483, AAL1, > and AAL5. > > So even though authors of such encaps are not bound by > the current charter to make an assessment of this, it > would seem to me to be valuable if they did before > these encaps become further entrenched in service > networks. > > Is this being considered already in encap > specifications? > > 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: "Busschbach, Peter B (Peter)" Subject: RE: RE: Is PWE a layer? Date: Tue, 3 Jun 2003 13:41:43 -0400 Lines: 52 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Tue Jun 03 19:46:41 2003 Return-path: To: "'tnadeau@cisco.com'" , "Busschbach, Peter B (Peter)" , 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 > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, June 03, 2003 11:31 AM > To: 'Busschbach, Peter B (Peter)'; pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: Tuesday, June 03, 2003 10:27 AM > > To: 'tnadeau@cisco.com'; pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > [clipped] > > It seems that we are moving towards consensus. As I have > > stated in earlier emails, my main concern is with the fault > > detection mechanism that we specify. If we can agree on the > > need for a one-way, perdiodic check, we have made progress. > > At this point, I don't care whether the Connection > > Verification message is an LSP Ping message or a Y.1711 CV > > message. Or better, I think the Y.1711 CV message requires > > less processing, but I have no reason to believe that an LSP > > Ping message could not serve the same purpose. > > Excellent. > > > Do you plan to add the one-way, periodic mode for LSP Ping to > > your VCCV document? > > I agree with you that a one-way mechanism is needed. > As I stated earlier, one is available in LSP ping. Since > VCCV uses LSP ping as a payload type, it can thus > leverage this mode as well. However, based on your suggestion, > we should add some text to the draft that explains this > more explicitly. > > --Tom > > Great! Looking forward to the new draft. Peter [clipped] From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE Service interworking Date: Tue, 3 Jun 2003 10:46:03 -0700 (PDT) Lines: 14 Sender: pwe3-admin@ietf.org References: <3EDCDC26.6D890C26@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 19:52:53 2003 Return-path: To: Mustapha Aissaoui In-Reply-To: <3EDCDC26.6D890C26@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 Aissaoui wrote: [SNIP] > It is my opinion that the proper way to addres this > case is to add > multiprotocol support to the PW/MPLS PID in a way > .... Thanks, I suspect the above would provide a lot of benefits and if it had already been present may have influenced the design direction of PW over MPLS. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Eric Rosen Subject: Re: PWE Service interworking Date: Tue, 03 Jun 2003 13:46:09 -0400 Lines: 20 Sender: pwe3-admin@ietf.org References: <20030603165457.50016.qmail@web13504.mail.yahoo.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 19:55:32 2003 Return-path: To: Mark Seery In-reply-to: Your message of Tue, 03 Jun 2003 09:54:57 -0700. <20030603165457.50016.qmail@web13504.mail.yahoo.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 Mark> It has been stated that service interworking is not Mark> part of the current charter. This might be Mark> appropriate, but I believe some consideration to this Mark> issue is advisable, most especially the encapsulations Mark> fixed on in the standards. To head off the start of another long, useless, and in-bred thread, could you start by offering a precise definition of "service interworking"? In your answer, please do not refer to any document whose designation consists of a letter followed by a period followed by a sequence of numbers. Also, please do not use the word "layer" in your answer. Mark> I would be curious to know whether encaps authors Mark> looked at existing adaptations (1490, 1483, AAL1, Mark> AAL5) and decided they were unsuitable for some Mark> reason. Those existing adaptations are for a completely different purpose, so I'm not sure just what you're asking. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Tue, 3 Jun 2003 14:25:03 -0400 Lines: 341 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C329FD.738ACAAA" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 20:28:01 2003 Return-path: To: "'tnadeau@cisco.com'" , "'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_01C329FD.738ACAAA Content-Type: text/plain; charset="iso-8859-1" Tom: I agree we need to get to a consensus decision, I also think it should be an informed one. 1) Use of LSP-PING in one way mode is an option, however what the far end should do is not specified (which is absolutely mandatory for interoperability). VCCV/LSP-PING specification would need to be extended to either define the exact far end message handling, permit the handling to be negotiated, or configured as part of LDP exchange. If this is configured via control plane exchange, then there is a few other details to sort out (Shah draft & graceful restart come to mind). Merely claiming a one way mode exists is insufficient. 2) I have trouble with the characterization of LSP-PING as a single mechanism. We're already into numerous encapsulations of it to overcome ECMP issues and carry variations of FEC information, so there is no possibility of a single simple implementation for on the wire handling, something we've worked to overcome with CV/FEC-CV. The information model to control one way periodic mode vs. ping mode will again be significantly different. Don't think there is a lot of benefit to be had on the northbound interface or a CLI unless for some perverse reason we're required to name the protocol used rather than the desired function. I wouldn't particularly care. My point is that we're already into numerous variations of behavior for a tool that I do not believe is suited for all applications. This is on the claimed basis that operators want one tool. I'd like to test that assumption as I presume they want a consistent operator interface and really do not care what is on the wire so long as it meets useful criteria and the overall system behavior is useful. 3) As for re-application of tools already in use, on MPLS-OPS I got the impression that LSP-PING will be in an IOS release Q4 this year (?). And if implementations of it does already exist, given the shortcomings discussed in '1' above, are you planning on "fixing/patching" it? cheers Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, June 03, 2003 8:23 AM > To: 'Mark Seery' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > -----Original Message----- > > From: Mark Seery [mailto:mark@mseery.com] > > 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 don't think that we need to define > more than one mechanism for the reasons I have > explained my my prior posting. My customers certainly > don't want more than one mechanism. Also, before any > conclusion is drawn, I suggest asking the WG for consensus on > such a decision. > > --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 > ------_=_NextPart_001_01C329FD.738ACAAA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

Tom:

I agree we need to get to a consensus decision, I = also think it should be an informed one.

1) Use of LSP-PING in one way mode is an option, = however what the far end should do is not specified (which is = absolutely mandatory for interoperability).  VCCV/LSP-PING = specification would need to be extended to either define the exact far = end message handling, permit the handling to be negotiated, or = configured as part of LDP exchange. If this is configured via control = plane exchange, then there is a few other details to sort out (Shah = draft & graceful restart come to mind). Merely claiming a one way = mode exists is insufficient.

2) I have trouble with the characterization of = LSP-PING as a single mechanism. We're already into numerous = encapsulations of it to overcome ECMP issues and carry variations of = FEC information, so there is no possibility of a single simple = implementation for on the wire handling, something we've worked to = overcome with CV/FEC-CV. The information model to control one way = periodic mode vs. ping mode will again be significantly different. = Don't think there is a lot of benefit to be had on the northbound = interface or a CLI unless for some perverse reason we're required to = name the protocol used rather than the desired function. I wouldn't = particularly care.

My point is that we're already into numerous = variations of behavior for a tool that I do not believe is suited for = all applications. This is on the claimed basis that operators want one = tool. I'd like to test that assumption as I presume they want a = consistent operator interface and really do not care what is on the = wire so long as it meets useful criteria and the overall system = behavior is useful.

3) As for re-application of tools already in use, on = MPLS-OPS I got the impression that LSP-PING will be in an IOS release = Q4 this year (?). And if implementations of it does already exist, = given the shortcomings discussed in '1' above, are you planning on = "fixing/patching" it?

cheers
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Tuesday, June 03, 2003 8:23 AM
> To: 'Mark Seery'
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] RE: Is PWE a layer?
>
>
>
>
> > -----Original Message-----
> > From: Mark Seery [mailto:mark@mseery.com]
> > 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" = <tnadeau@cisco.com> 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 don't think = that we need to define
> more than one mechanism for the reasons I have =
> explained my my prior posting.  My = customers certainly
> don't want more than one mechanism.  Also, = before any
> conclusion is drawn, I suggest asking the WG = for consensus on
> such a decision.
>
>       --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=
>

------_=_NextPart_001_01C329FD.738ACAAA-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: RE: Is PWE a layer? Date: Tue, 03 Jun 2003 13:12:38 -0600 Organization: Level3 Communications LLC. Lines: 571 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'tnadeau@cisco.com'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 21:19: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: "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 Tom, Peter, I agree with the need for fault detection mechanism on a PW, but right now level3 has designed and deployed a PW ping based solution that works quite well. I think LSP ping builds on existing IETF well understood standards, and is in my mind the only logical solution to this problem. Since the PWs are bi-directional , and IP seems to be quite manageable with ping, I do not see what the need for a unidirectional ping is ? Luca Busschbach, Peter B (Peter) wrote: > >>-----Original Message----- >>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>Sent: Tuesday, June 03, 2003 8:15 AM >>To: pwe3@ietf.org >>Subject: RE: [PWE3] RE: Is PWE a layer? >> >> >> >> Hi, >> >> Just catching up on some old emails... >> >> >>>-----Original Message----- >>>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >>>Behalf Of Busschbach, Peter B (Peter) >>>Sent: Thursday, May 29, 2003 6:02 PM >>>To: 'Mark Seery'; David Allan >>>Cc: pwe3@ietf.org >>>Subject: RE: [PWE3] RE: Is PWE a layer? >>> >>> >>>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. >> >> You can run LSP ping in a one-way >>mode (no reply), just as you can run Y.1711, and have the >>downstream LSR determine that that direction is not working. >>You can also run it in normal mode from both sides >>of the PW. >> >> >>>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. >> >> It seems evident to me that the way to go is to >>listen to what the market and customers say are the tools >>and techniques they want. >> >> >>>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? >> >> >> A few reasons. First, Y.1711 is NOT currently specified >>this way, thus adopting it still requires the interval regardless >>of what patches/fixes are in the works. Second, as I just >>pointed out, you can do the same things based on mechanisms >>defined here at the IETF. Third, the mechanisms defined by the >>IETF that are already in use for other MPLS applications, >>can be re-used for PWs, thus obviating the need to implement/manage >>another mechanism for just PWE implementations. >> >> --Tom >> > > > Tom, > > It seems that we are moving towards consensus. As I have stated in earlier emails, my main concern is with the fault detection mechanism that we specify. If we can agree on the need for a one-way, perdiodic check, we have made progress. At this point, I don't care whether the Connection Verification message is an LSP Ping message or a Y.1711 CV message. Or better, I think the Y.1711 CV message requires less processing, but I have no reason to believe that an LSP Ping message could not serve the same purpose. > > Do you plan to add the one-way, periodic mode for LSP Ping to your VCCV document? > > Peter > > > >> >>>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 >>>> >>> >>>_______________________________________________ >>>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: Mark Seery Subject: Re: PWE Service interworking Date: Tue, 3 Jun 2003 12:21:36 -0700 (PDT) Lines: 25 Sender: pwe3-admin@ietf.org References: <200306031746.h53HkA51016350@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 21:26:26 2003 Return-path: To: erosen@cisco.com In-Reply-To: <200306031746.h53HkA51016350@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 Hi Eric, --- Eric Rosen wrote: [SNIP] > Mark> I would be curious to know whether encaps > authors > Mark> looked at existing adaptations (1490, 1483, > AAL1, > Mark> AAL5) and decided they were unsuitable for > some > Mark> reason. > > Those existing adaptations are for a completely > different purpose, so I'm > not sure just what you're asking. Before I attempt to define service interworking, I think it would be valuable for you to explain the different purposes these encapsulations have. Your answer **may** dramatically lower the size of the thread and also help me better define service interworking. Thanks, Mark 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: Tue, 3 Jun 2003 15:27:36 -0400 Lines: 607 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'tnadeau@cisco.com'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 21:29:55 2003 Return-path: To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Tuesday, June 03, 2003 3:13 PM > To: Busschbach, Peter B (Peter) > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org > Subject: Re: [PWE3] RE: Is PWE a layer? > > > Tom, Peter, > > I agree with the need for fault detection mechanism on a PW, > but right now > level3 has designed and deployed a PW ping based solution > that works quite well. Luca, Do you carry Frame Relay and ATM over your MPLS network? I can see that Ping is sufficient for VPLS and VPWS, but I know carriers who are offering Frame Relay service today and who want to extend those across an MPLS core, who need OAM functions similar to what they get today from an ATM core network. The problem with regular (bi-directional) Ping is that it is a poor mechanism to localize failures. If a PE doesn't receive a reply, it doesn't know whether the forward or backward PW is down. In fact, it could even be that neither the forward nor backward PW is down, but that there is a problem in the control plane. Uni-directional Ping would solve that problem. Peter > I think LSP ping builds on existing IETF well understood > standards, and is in > my mind the only logical solution to this problem. > Since the PWs are bi-directional , and IP seems to be quite > manageable with > ping, I do not see what the need for a unidirectional ping is ? > > Luca > > > > Busschbach, Peter B (Peter) wrote: > > > >>-----Original Message----- > >>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >>Sent: Tuesday, June 03, 2003 8:15 AM > >>To: pwe3@ietf.org > >>Subject: RE: [PWE3] RE: Is PWE a layer? > >> > >> > >> > >> Hi, > >> > >> Just catching up on some old emails... > >> > >> > >>>-----Original Message----- > >>>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > >>>Behalf Of Busschbach, Peter B (Peter) > >>>Sent: Thursday, May 29, 2003 6:02 PM > >>>To: 'Mark Seery'; David Allan > >>>Cc: pwe3@ietf.org > >>>Subject: RE: [PWE3] RE: Is PWE a layer? > >>> > >>> > >>>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. > >> > >> You can run LSP ping in a one-way > >>mode (no reply), just as you can run Y.1711, and have the > >>downstream LSR determine that that direction is not working. > >>You can also run it in normal mode from both sides > >>of the PW. > >> > >> > >>>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. > >> > >> It seems evident to me that the way to go is to > >>listen to what the market and customers say are the tools > >>and techniques they want. > >> > >> > >>>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? > >> > >> > >> A few reasons. First, Y.1711 is NOT currently specified > >>this way, thus adopting it still requires the interval regardless > >>of what patches/fixes are in the works. Second, as I just > >>pointed out, you can do the same things based on mechanisms > >>defined here at the IETF. Third, the mechanisms defined by the > >>IETF that are already in use for other MPLS applications, > >>can be re-used for PWs, thus obviating the need to implement/manage > >>another mechanism for just PWE implementations. > >> > >> --Tom > >> > > > > > > Tom, > > > > It seems that we are moving towards consensus. As I have > stated in earlier emails, my main concern is with the fault > detection mechanism that we specify. If we can agree on the > need for a one-way, perdiodic check, we have made progress. > At this point, I don't care whether the Connection > Verification message is an LSP Ping message or a Y.1711 CV > message. Or better, I think the Y.1711 CV message requires > less processing, but I have no reason to believe that an LSP > Ping message could not serve the same purpose. > > > > Do you plan to add the one-way, periodic mode for LSP Ping > to your VCCV document? > > > > Peter > > > > > > > >> > >>>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 > >>>> > >>> > >>>_______________________________________________ > >>>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: Tue, 3 Jun 2003 15:33:48 -0400 Organization: Cisco Systems Lines: 196 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 Tue Jun 03 21:38:09 2003 Return-path: To: "'David Allan'" , "'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: David Allan [mailto:dallan@nortelnetworks.com] > Sent: Tuesday, June 03, 2003 2:25 PM > To: 'tnadeau@cisco.com'; 'Mark Seery' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > Tom: > > I agree we need to get to a consensus decision, I also think > it should be an informed one. > > 1) Use of LSP-PING in one way mode is an option, however what > the far end should do is not specified (which is absolutely > mandatory for interoperability). VCCV/LSP-PING specification > would need to be extended to either define the exact far end > message handling, permit the handling to be negotiated, or > configured as part of LDP exchange. If this is configured via > control plane exchange, then there is a few other details to > sort out (Shah draft & graceful restart come to mind). Merely > claiming a one way mode exists is insufficient. I think that we are in agreement that perhaps more details about what to do need to be specified. George and I have already agreed for example, to add this to the next VCCV draft. > 2) I have trouble with the characterization of LSP-PING as a > single mechanism. We're already into numerous encapsulations > of it to overcome ECMP issues and carry variations of FEC > information, so there is no possibility of a single simple > implementation for on the wire handling, something we've > worked to overcome with CV/FEC-CV. I never claimed it was a single mechanism; it should be used in concert with things like VRF-aware ping, ICMP ping, VCCV, etc... The key observation is that these tools all are formulated together for the specific application in question while being available for re-use for other applications. For instance, in the case of L3 VPN, you can use the existing VRF-aware ping that many vendors offer plus LSP ping/trace. If you want to use EoMPLS, you use Ethernet ping, VCCV and possibly Lsp ping. Guess what? Doing this, you can leverage most of that solution based on the existing LSP ping code and OSS investment. > The information model to > control one way periodic mode vs. ping mode will again be > significantly different. Don't think there is a lot of > benefit to be had on the northbound interface or a CLI unless > for some perverse reason we're required to name the protocol > used rather than the desired function. I wouldn't particularly care. There is nothing perverse about it. A consistent interface makes for consistent management of the device. I don't see what impact this has on the north-bound interface. > My point is that we're already into numerous variations of > behavior for a tool that I do not believe is suited for all > applications. This is on the claimed basis that operators > want one tool. Not one tool, one solution. > I'd like to test that assumption as I presume > they want a consistent operator interface and really do not > care what is on the wire so long as it meets useful criteria > and the overall system behavior is useful. Yes, but given that we have already adopted LSP ping for MPLS networks, why not leverage this for PW/MPLS networks and re-use the implementations and OSS investments in that approach? Surely many devices and networks are going to be deployed with not only PWs but also LDP, TE and L3 VPN all of which can utilize LSP ping, VRF-aware ping and ICMP ping. It seems that you are advocating an approach that requires lots of investment and churn this time for PWs, whereby you want the operator to do something completely different just because it is a new application and you claim it is a superior solution. I assert that it is better in terms of cost, effort and time to market to incorporate the tools and techniques that exist today as part of the approach for the new application. This is precisely what we have done in defining VCCV to re-use LSP ping when used for PW/MPLS. > 3) As for re-application of tools already in use, on MPLS-OPS > I got the impression that LSP-PING will be in an IOS release > Q4 this year (?). And if implementations of it does already > exist, given the shortcomings discussed in '1' above, are you > planning on "fixing/patching" it? We do code fixes based on customer requirements. --Tom > cheers > Dave > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Tuesday, June 03, 2003 8:23 AM > > To: 'Mark Seery' > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > > > -----Original Message----- > > > From: Mark Seery [mailto:mark@mseery.com] > > > 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 don't think that we need to define > > more than one mechanism for the reasons I have > > explained my my prior posting. My customers certainly > > don't want more than one mechanism. Also, before any > > conclusion is drawn, I suggest asking the WG for consensus on > > such a decision. > > > > --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 > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Ghassem Koleyni" Subject: RE: PWE Service interworking Date: Tue, 3 Jun 2003 15:38:34 -0400 Lines: 117 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32A07.B88BB1AA" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 21:41:06 2003 Return-path: To: "'Mark Seery'" , erosen@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_01C32A07.B88BB1AA Content-Type: text/plain; charset="iso-8859-1" There is a useful and accepted definition in ITU-T Recommendations, e.g. I.555 for Service Interworking. Please take a look at it. Regards, Ghassem Hi Eric, --- Eric Rosen wrote: [SNIP] > Mark> I would be curious to know whether encaps > authors > Mark> looked at existing adaptations (1490, 1483, > AAL1, > Mark> AAL5) and decided they were unsuitable for > some > Mark> reason. > > Those existing adaptations are for a completely > different purpose, so I'm > not sure just what you're asking. Before I attempt to define service interworking, I think it would be valuable for you to explain the different purposes these encapsulations have. Your answer **may** dramatically lower the size of the thread and also help me better define service interworking. Thanks, Mark _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C32A07.B88BB1AA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE Service interworking

There is a useful and accepted definition in ITU-T = Recommendations, e.g. I.555 for Service Interworking. Please take a = look at it.

Regards, Ghassem

Hi Eric,

--- Eric Rosen <erosen@cisco.com> wrote:
[SNIP]
> Mark> I would be curious to know whether = encaps
> authors
> Mark> looked at existing adaptations (1490, = 1483,
> AAL1,
> Mark> AAL5) and decided they were unsuitable = for
> some
> Mark> reason.
>
> Those existing  adaptations are for  = a completely
> different purpose,  so I'm
> not sure just what you're asking.

Before I attempt to define service interworking, = I
think it would be valuable for you to explain = the
different purposes these encapsulations have. = Your
answer **may** dramatically lower the size of = the
thread and also help me better define service
interworking.

Thanks,
Mark

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

------_=_NextPart_001_01C32A07.B88BB1AA-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Eric Rosen Subject: Re: PWE Service interworking Date: Tue, 03 Jun 2003 15:44:00 -0400 Lines: 12 Sender: pwe3-admin@ietf.org References: <20030603192136.82524.qmail@web13506.mail.yahoo.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 21:45:25 2003 Return-path: To: Mark Seery In-reply-to: Your message of Tue, 03 Jun 2003 12:21:36 -0700. <20030603192136.82524.qmail@web13506.mail.yahoo.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 Mark> Before I attempt to define service interworking, I think it would be Mark> valuable for you to explain the different purposes these Mark> encapsulations have. All I meant is that RFC 1483, e.g., defines an encapsulation for carrying arbitrary layer 2 or layer 3 PDUs over ATM, whereas PWE3 defines an encapsulation for carrying layer 2 frames over a pseudowire over IP or MPLS. As the "gap" between the emulated service and network service is very different in the two cases, it's not obvious what one means by saying "why didn't you use the 1483 encaps for pseudowires"? There was also an expectation that a given pw would carry a single kind of payload. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE Service interworking Date: Tue, 3 Jun 2003 13:10:44 -0700 (PDT) Lines: 36 Sender: pwe3-admin@ietf.org References: <200306031944.h53Ji051024083@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 22:12:13 2003 Return-path: To: erosen@cisco.com In-Reply-To: <200306031944.h53Ji051024083@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 --- Eric Rosen wrote: > > Mark> Before I attempt to define service > interworking, I think it would be > Mark> valuable for you to explain the > different purposes these > Mark> encapsulations have. > > All I meant is that RFC 1483, e.g., defines an > encapsulation for carrying > arbitrary layer 2 or layer 3 PDUs over ATM, > whereas PWE3 defines an > encapsulation for carrying layer 2 frames over a > pseudowire over IP or > MPLS. As the "gap" between the emulated service > and network service is > very different in the two cases, it's not obvious > what one means by saying > "why didn't you use the 1483 encaps for > pseudowires"? There was also an > expectation that a given pw would carry a single > kind of payload. It is not that I specifically think 1483 should be used for all traffic types, just noting that while 1490 and 1483 deal with different underlying protocols, they are so similar as to be easily interworked. But thanks for the clarification, in my next post I wil now do as you request and try to define service interworking in such a way as we can all have a constructive, and hopefully brief dialog on the issue. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Tue, 3 Jun 2003 13:13:20 -0700 (PDT) Lines: 23 Sender: pwe3-admin@ietf.org References: <0D7FC1D8D861D511AEA70002A52CE5E6057BD7C1@zcard0ke.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 22:14:16 2003 Return-path: To: Ghassem Koleyni In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6057BD7C1@zcard0ke.ca.nortel.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 understand the intention, but if we can not explain this simply without reference to another document, then we can not have a general discussion where general concepts are agreed to. I also realize that there would be a desire not to reinvent the wheel, but Eric has suggested a way of getting in the same page without pulling in potentially stale state associated with any given reference, and I think it is worth a try. We can always reference the detail later. mark --- Ghassem Koleyni wrote: > There is a useful and accepted definition in ITU-T > Recommendations, e.g. > I.555 for Service Interworking. Please take a look > at it. > > Regards, Ghassem > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: RE: Is PWE a layer? Date: Tue, 3 Jun 2003 16:22:54 -0400 Lines: 608 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32A0D.E9C9BE00" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 03 22:23:57 2003 Return-path: To: "'tnadeau@cisco.com'" , "'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_01C32A0D.E9C9BE00 Content-Type: text/plain; charset="iso-8859-1" Tom: In essence, your idea of one solution is an application specific variation of a particular style of tool where you've already operationalized the general style, and plan on managing everything on that basis. OK, I obviously do not agree on all points, and on more than simply PW specifics, so its time for other folks to chime in as to whether your approach meets their needs. cheers Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, June 03, 2003 3:34 PM > To: Allan, David [CAR:NS00:EXCH]; 'Mark Seery' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > -----Original Message----- > > From: David Allan [mailto:dallan@nortelnetworks.com] > > Sent: Tuesday, June 03, 2003 2:25 PM > > To: 'tnadeau@cisco.com'; 'Mark Seery' > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > Tom: > > > > I agree we need to get to a consensus decision, I also think > > it should be an informed one. > > > > 1) Use of LSP-PING in one way mode is an option, however what > > the far end should do is not specified (which is absolutely > > mandatory for interoperability). VCCV/LSP-PING specification > > would need to be extended to either define the exact far end > > message handling, permit the handling to be negotiated, or > > configured as part of LDP exchange. If this is configured via > > control plane exchange, then there is a few other details to > > sort out (Shah draft & graceful restart come to mind). Merely > > claiming a one way mode exists is insufficient. > > I think that we are in agreement that perhaps more > details about what to do need to be specified. George and > I have already agreed for example, to add this to the next > VCCV draft. > > > 2) I have trouble with the characterization of LSP-PING as a > > single mechanism. We're already into numerous encapsulations > > of it to overcome ECMP issues and carry variations of FEC > > information, so there is no possibility of a single simple > > implementation for on the wire handling, something we've > > worked to overcome with CV/FEC-CV. > > I never claimed it was a single mechanism; it should be > used in concert with things like VRF-aware ping, ICMP ping, > VCCV, etc... The key observation is that these tools all are > formulated together for the specific application in question > while being available for re-use for other applications. For > instance, > in the case of L3 VPN, you can use the existing VRF-aware ping > that many vendors offer plus LSP ping/trace. If you want to use > EoMPLS, you use Ethernet ping, VCCV and possibly Lsp ping. > Guess what? Doing this, you can leverage most of that > solution based on the existing LSP ping code and OSS investment. > > > The information model to > > control one way periodic mode vs. ping mode will again be > > significantly different. Don't think there is a lot of > > benefit to be had on the northbound interface or a CLI unless > > for some perverse reason we're required to name the protocol > > used rather than the desired function. I wouldn't > particularly care. > > There is nothing perverse about it. A consistent > interface makes for consistent management of the device. I > don't see what impact this has on the north-bound interface. > > > My point is that we're already into numerous variations of > > behavior for a tool that I do not believe is suited for all > > applications. This is on the claimed basis that operators > > want one tool. > > Not one tool, one solution. > > > I'd like to test that assumption as I presume > > they want a consistent operator interface and really do not > > care what is on the wire so long as it meets useful criteria > > and the overall system behavior is useful. > > Yes, but given that we have already adopted > LSP ping for MPLS networks, why not leverage this > for PW/MPLS networks and re-use the implementations > and OSS investments in that approach? Surely > many devices and networks are going to be deployed > with not only PWs but also LDP, TE and L3 VPN all > of which can utilize LSP ping, VRF-aware ping and > ICMP ping. It seems that you are advocating an > approach that requires lots of investment and churn > this time for PWs, whereby you want the operator to > do something completely different just because it > is a new application and you claim it is a superior > solution. I assert that it is better in terms of cost, > effort and time to market to incorporate the tools and > techniques that exist today as part of the approach for > the new application. This is precisely what we have done > in defining VCCV to re-use LSP ping when used for PW/MPLS. > > > 3) As for re-application of tools already in use, on MPLS-OPS > > I got the impression that LSP-PING will be in an IOS release > > Q4 this year (?). And if implementations of it does already > > exist, given the shortcomings discussed in '1' above, are you > > planning on "fixing/patching" it? > > We do code fixes based on customer requirements. > > --Tom > > > > cheers > > Dave > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Tuesday, June 03, 2003 8:23 AM > > > To: 'Mark Seery' > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] RE: Is PWE a layer? > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mark Seery [mailto:mark@mseery.com] > > > > 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 don't think that we need to define > > > more than one mechanism for the reasons I have > > > explained my my prior posting. My customers certainly > > > don't want more than one mechanism. Also, before any > > > conclusion is drawn, I suggest asking the WG for consensus on > > > such a decision. > > > > > > --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 > > > > > > > > > > ------_=_NextPart_001_01C32A0D.E9C9BE00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: Is PWE a layer?

Tom:

In essence, your idea of one solution is an = application specific variation of a particular style of tool where = you've already operationalized the general style, and plan on managing = everything on that basis.

OK, I obviously do not agree on all points, and on = more than simply PW specifics, so its time for other folks to chime in = as to whether your approach meets their needs.

cheers
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Tuesday, June 03, 2003 3:34 PM
> To: Allan, David [CAR:NS00:EXCH]; 'Mark = Seery'
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] RE: Is PWE a layer?
>
>
>
>
> > -----Original Message-----
> > From: David Allan [mailto:dallan@nortelnetworks.c= om]
> > Sent: Tuesday, June 03, 2003 2:25 = PM
> > To: 'tnadeau@cisco.com'; 'Mark = Seery'
> > Cc: pwe3@ietf.org
> > Subject: RE: [PWE3] RE: Is PWE a = layer?
> >
> >
> > Tom:
> >
> > I agree we need to get to a consensus = decision, I also think
> > it should be an informed one.
> >
> > 1) Use of LSP-PING in one way mode is an = option, however what
> > the far end should do is not specified = (which is absolutely
> > mandatory for interoperability).  = VCCV/LSP-PING specification
> > would need to be extended to either define = the exact far end
> > message handling, permit the handling to = be negotiated, or
> > configured as part of LDP exchange. If = this is configured via
> > control plane exchange, then there is a = few other details to
> > sort out (Shah draft & graceful = restart come to mind). Merely
> > claiming a one way mode exists is = insufficient.
>
>       I think that we = are in agreement that perhaps more
> details about what to do need to be specified. = George and
> I have already agreed for example, to add this = to the next
> VCCV draft.
> 
> > 2) I have trouble with the = characterization of LSP-PING as a
> > single mechanism. We're already into = numerous encapsulations
> > of it to overcome ECMP issues and carry = variations of FEC
> > information, so there is no possibility of = a single simple
> > implementation for on the wire handling, = something we've
> > worked to overcome with CV/FEC-CV.
>
>       I never claimed = it was a single mechanism; it should be
> used in concert with things like VRF-aware = ping, ICMP ping,
> VCCV, etc... The key observation is that these = tools all are
> formulated together for the specific = application in question
> while being available for re-use for other = applications. For
> instance,
> in the case of L3 VPN, you can use the existing = VRF-aware ping
> that many vendors offer plus LSP ping/trace. If = you want to use
> EoMPLS, you use Ethernet ping, VCCV and = possibly Lsp ping.
> Guess what? Doing this, you can leverage most = of that
> solution based on the existing LSP ping code = and OSS investment.
>
> > The information model to
> > control one way periodic mode vs. ping = mode will again be
> > significantly different. Don't think there = is a lot of
> > benefit to be had on the northbound = interface or a CLI unless
> > for some perverse reason we're required to = name the protocol
> > used rather than the desired function. I = wouldn't
> particularly care.
>
>       There is nothing = perverse about it. A consistent
> interface makes for consistent management of = the device. I
> don't see what impact this has on the = north-bound interface.
> 
> > My point is that we're already into = numerous variations of
> > behavior for a tool that I do not believe = is suited for all
> > applications. This is on the claimed basis = that operators
> > want one tool.
>
>       Not one tool, = one solution.
>
> > I'd like to test that assumption as I = presume
> > they want a consistent operator interface = and really do not
> > care what is on the wire so long as it = meets useful criteria
> > and the overall system behavior is = useful.
>
>       Yes, but given = that we have already adopted
> LSP ping for MPLS networks, why not leverage = this
> for PW/MPLS networks and re-use the = implementations
> and OSS investments in that approach?  = Surely
> many devices and networks are going to be = deployed
> with not only PWs but also LDP, TE and L3 VPN = all
> of which can utilize LSP ping, VRF-aware ping = and
> ICMP ping.  It seems that you are = advocating an
> approach that requires lots of investment and = churn
> this time for PWs, whereby you want the = operator to
> do something completely different just because = it
> is a new application and you claim it is a = superior
> solution.  I assert that it is better in = terms of cost,
> effort and time to market to incorporate the = tools and
> techniques that exist today as part of the = approach for
> the new application. This is precisely what we = have done
> in defining VCCV to re-use LSP ping when used = for PW/MPLS.
> 
> > 3) As for re-application of tools already = in use, on MPLS-OPS
> > I got the impression that LSP-PING will be = in an IOS release
> > Q4 this year (?). And if implementations = of it does already
> > exist, given the shortcomings discussed in = '1' above, are you
> > planning on "fixing/patching" = it?
>
>       We do code fixes = based on customer requirements.
>
>       --Tom
>
>
> > cheers
> > Dave
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > > Sent: Tuesday, June 03, 2003 8:23 AM =
> > > To: 'Mark Seery'
> > > Cc: pwe3@ietf.org
> > > Subject: RE: [PWE3] RE: Is PWE a = layer?
> > >
> > >
> > >
> > >
> > > > -----Original = Message-----
> > > > From: Mark Seery [mailto:mark@mseery.com]
> > > > 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" = <tnadeau@cisco.com> 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 = don't think that we need to define
> > > more than one mechanism for the = reasons I have
> > > explained my my prior posting.  = My customers certainly
> > > don't want more than one = mechanism.  Also, before any
> > > conclusion is drawn, I suggest asking = the WG for consensus on
> > > such a decision.
> > >
> > >       = --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 =
> > >
> >
> >
>
>
>

------_=_NextPart_001_01C32A0D.E9C9BE00-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE Service interworking Date: Tue, 3 Jun 2003 14:00:59 -0700 (PDT) Lines: 122 Sender: pwe3-admin@ietf.org References: <200306031944.h53Ji051024083@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Tue Jun 03 23:02:35 2003 Return-path: To: pwe3@ietf.org In-Reply-To: <200306031944.h53Ji051024083@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 All, remember the constraints: a) can't quote from a non-IETF standard, b) can't use the word layer. Will do my best. Defining service interworking ===================== The simplest explanations (IMO) for interworking are as follows: Network interworking - ingress and egress attachment circuits use the same protocols Service interworking - ingress and egress attachment circuits use different protocols Now any interworking agreement is going to specify exactly what protocols, so the actual definition necessarily becomes less generalized. Typical protocols that have been involved in interworking standards are link-layer PDUs and adaptation layers (FR, ATM, AAL1, AAL5) and Multiprotocol encapsulation standards (RFC 1483, RFC 1490). Simplistically a network interworking function has to map a service PDU to an encapsulation that provides service attributes on an underlying network such that the service entrities at each side of the network do not realize they are not operating over a native service network. An example of this would be two Frame Relay attachment circuits connected to an ATM network, or two Ethernet attachment circuits connected to a MPLS or IP network (i.e. PW) For example: CE--FR--PE--FR/PW/PSN--PE-FR-CE I don't think there has been much controversy about this, the only real area of controversy I recall is the degree to which the PW/PSN emualtes the ingress/egress service definitions. In providing this service emulation things such as the following may be mapped: 1. Variable length PDU formatting and delimiting 2. Error detection 3. Connection multiplexing 4. Loss Priority Indication 5. Congestion Indication (Forward and Backward) 6. PVC Status Management So in this sense Eric is correct. RFC 1490/1483 are not the same as the encapsulations used to perform network interworking, or what might otherwise be referred to as (sub)convergence. In this context the more appropriate question might be, was AAL1 or AAL5 explored as to their applicability for encapsulating services over MPLS or IP; they may not provide what is needed, and that is a perfectly acceptable answer if that is the case. Some standards differentiate between the case when two subscribers are communicating over a cloud, and when two networks are communicating over a third cloud; I will not for the sake of trying to establish some basic concepts. Now we move to service interworking, where we are trying to provide for a service to have two different interfaces at either end of a cloud. In this case, simple encapsulation does not work, the hard task (and I do understand it is not considered trivial by some developers) is to have say Frame Relay go in one side, and have ATM come out the other side. For example: CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE The IWF (interworking function) could be in a variety of places, I just put it there for grins. In this example, we now have to not only convert the Frame Relay base protocol to ATM, but if we do not convert RFC1490 running above it to RFC1483, then there will be problems at that level of protocol interaction. NLPIDs are used often in encapsulations to provide indication of encapsulated protocols. Service interworking could be done at the ingress PE, in which case the resultant PW is really in the format of the egress attachment circuit. Another option is to do it at the egress PE, which would mean translating from the 1490/FR/PW/MPLS or IP PDUs to the resultant 1483/aal5/atm attachment circuit. The question then becomes should the FR PDU just be popped from the PW and examined, or should the PW indicate, by a NLPID equivalent, what is contained within the FR PDU? That would probably be an implementation decision, but those types of dicussions may uncover any weaknesses in the current methods, if they exist at all, and they may not. If the PW is discarded before the IWF function, then that is probably not a problem as long as the resultant FR PDU is sufficient to perform the mapping; and therefore I am not concerned that the PW "whatever" disappears, this is analgous to the ATM AAL5 PDU disappearing and a new one being created, if the service interworking was performed in the same way So the more I think about, the less problems I see.......... There is some thought floating around that if the PW encap was similar to or identical to whatever network is most likely to be interworked to, then that may make like easier for implementors and operators - that I leave as a discussion point, and note the horse has probably already bolted on that one, for this WG, in this time slot. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE OAM Resolution / MPLS PID Date: Tue, 3 Jun 2003 09:15:49 -0700 (PDT) Lines: 36 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 04 00:16:45 2003 Return-path: To: tnadeau@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 > 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 don't think that we need to define more than one mechanism for the reasons I have explained my my prior posting. My customers certainly don't want more than one mechanism. Also, before any conclusion is drawn, I suggest asking the WG for consensus on such a decision. --Tom MS=> So now we get in to the old what is a major problem. Dave has asserted that Y.1711 requires meaningful less processing than PW VCCV. This is considered important in the mode where OAM is being run x/sec on every LSP in order to identify defects and suppress alarm storms. Tom, Can you please comment on how you see the processing difference and whether you think it would/would not make a difference if running OAM in this way. More generally, do you assert that PW VCCV has equivalent functionality to Y.1711 including the generation of FDI etc. Thanks, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE Service interworking Date: Tue, 3 Jun 2003 14:16:53 -0700 (PDT) Lines: 15 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Wed Jun 04 00:18:43 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 --- Mark Seery wrote: > All, remember the constraints: a) can't quote from a > non-IETF standard, b) can't use the word layer. Will > do my best. > > Defining service interworking > ===================== > This obviously was user/data plane discussion only, and the details of mapping/interworking all the various types of PDUs (OAM....) etc. not discussed. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Tue, 3 Jun 2003 16:54:21 -0700 (PDT) Lines: 44 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 Jun 04 01:54:47 2003 Return-path: To: Lloyd Wood In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Lloyd, --- Lloyd Wood wrote: [SNIP] > While management interworking is well defined for > ATM/Frame Relay [FRF.8, ITU-T I.555], the mapping of > PW > failures to the equivalent ATM/Frame Relay OAM > messages when > pseudo wires are used to interconnect these > technologies is > not well defined. Specifically what you essentially end up with (in the case where the IWF is not done at the ingress point) is service interworking occuring over a network interworking function, which complicates the decision process of where to map OAMs to (i.e. the far-end service interface, the PW, the PSN,.....); probably depends on how much transparency is desireable WRT the intermediate cloud. Can probably be done, but makes things interesting. Moreover, if the interworked "technologies" have different capabilities, then becomes even harder. As has been noted, on some occassions, some types of IWF can occur outside the PSN cloud, so there are some short-term options available. IMHO, the value of looking at above referenced documents would be to try and glean the types of mappings that past IWF implementors have considered; therefore becoming a guide, and diminishing the chances of reinventing the wheel - but as you say, they do not cover this particular case. In practice (in the short-term at least), I suspect that when shipping traffic to an MPLS core, the IWF will occur before the PW entry point; and after the PW exit point in the reverse direction, thus avoiding the issue all together. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE Service interworking Date: Tue, 3 Jun 2003 21:00:40 -0700 (PDT) Lines: 119 Sender: pwe3-admin@ietf.org References: <20030603210059.68794.qmail@web13508.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Wed Jun 04 06:02:15 2003 Return-path: To: pwe3@ietf.org In-Reply-To: <20030603210059.68794.qmail@web13508.mail.yahoo.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 So having tried a general description, a slightly (not constructing access points etc.) treatment of this issue might look something like the following. Acronyms NIWF - network internetworking function and SIWF - Service interworking function are not acronyms used by any standards body (that I know of). fig.1 is essentially how I think of PW today. Network Interworking ==================== fig.1 CE1 PE1 P PE2 CE2 ----------- ----------- | NIWF | | NIWF | ------ |---------| ------ |---------| ------ | FR |--| FR | PW |---| PW |---| PW | FR |--| FR | ------ ----------- ------ ----------- ------ Where FR could be FR, Ethernet, or ATM. In the ATM case, AAL5 would (typically) be encapsulated on to a PW, and no understanding of upper layer protocols would be required. Service Interworking ==================== fig.2 CE1 PE1 P PE2 CE2 ----------- ----------- | SIWF | | | ------ |---------| ------ | | ------ | FR |--| FR | PW |---| PW |---| PW |--| PW | ------ ----------- ------ ----------- ------ The scenario of a PW going to a CE is unlikely today, of course, but shown here as a theoretical option. or fig.3 CE1 PE1 P PE2 CE2 ----------- ----------- | SIWF | | | ------ |---------| ------ | | ------ | FR |--| FR | MP |---| MP |---| MP |--| MP | ------ ----------- ------ ----------- ------ The scenario of a MPLS (MP) service going to a CE is more likely than that of a PW, but still not likely to be widespread in the near term or fig.4 CE1 PE1 P PE2 CE2 ----------- ----------------- | NIWF | | NIWF | SIWF | ------ |---------| ------ |---------------| ----- | FR |--| FR | PW |---| PW |---| PW | FR | ATM |--|ATM| ------ ----------- ------ ----------------- ----- In this scenario FR is encapsulated on to a PW at PE1 and decapsulated off of a PW at PE2 and then service interworked to an ATM service. The ATM service may be going to a CE or to an ATM network (in which case the SIWF would be slightly different) or fig.5 CE1 PE1 P PE2 CE2 ----------- ----------- | SIWF | | SIWF | ------ |---------| ------ |---------| ------ | FR |--| FR | PW |---| PW |---| PW | ATM|--| ATM| ------ ----------- ------ ----------- ------ this seems simpler than some of the previous examples but might actually be quite hard and is where translation to from PW encaps would need to be pretty good (my guess). or fig.6 CE1 FR SW ATM SW PE1 P ----------- ----------- | SIWF | |NIWF/SIWF| ------ |---------| ------- | --------| ------ | FR |--| FR | ATM|---| ATM |---| ATM | MP|--| MP | ------ ----------- ------- ----------- ------ In this case FR is interworked with ATM, and RFC 1490 with RFC 1483 at the FR SW. Then at the PE, ATM is network or service interworked with MP. In the case of routed RFC 1490/1483, an IP packet could be popped and encapsulated over MPLS, but there would still be OAM interworking between the ATM and MPLS functions. In the case of bridged RFC1490/1483, it may be possibly to interwork the ATM and MPLS functions and then interwork RFC1483 and PW. Just some ideas of scenarios we may be looking at in the future. Having thought about it, there is probably no getting by with just a casual discussion of this issue. So we either add it to the charter now, or delay it as seems to be the consensus (i.e. I have only heard one strong voice pushing it to the forefront). Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 08:41:44 +0300 Lines: 10 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 Wed Jun 04 07:44:22 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE Service interworking Thread-Index: AcMp9tToMCt2IHKpR6SmrenmrcZeHAAZQ1Fw To: "Mark Seery" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h545gMB00676 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 curious to know whether encaps authors > looked at existing adaptations (1490, 1483, AAL1, > AAL5) and decided they were unsuitable for some > reason. At least one encap author looked at AAL1 and decided that it was most suitable. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 08:43:39 +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: X-From: pwe3-admin@ietf.org Wed Jun 04 07:45:42 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE Service interworking Thread-Index: AcMp+0dgiY9tavj9QxiDqJJCAJpeTgAYNUXg To: , "Mark Seery" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h545iFB00719 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > To head off the start of another long, useless, and > in-bred thread, could you start by offering a precise definition of "service > interworking"? In your answer, please do not refer to any document whose > designation consists of a letter followed by a period followed by a sequence of > numbers. Also, please do not use the word "layer" in your answer. The definitions were in the architecture draft, but were removed due to lack of interest at the time. Stewart - perhaps this should be rethought. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 06:46:45 -0500 Lines: 163 Sender: pwe3-admin@ietf.org References: <20030604040040.17328.qmail@web13503.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Wed Jun 04 13:48:54 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: <20030604040040.17328.qmail@web13503.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by uswgne22.uswest.com id h54Bkl19000792 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54BlMB07385 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h54BocB07545 Status: O A carrier's perspective: The existing customer based is a combination of the following Networking Interworking options: ATM-ATM, FR-FR, CE-CE, Ethernet-Ethernet and Service Interworking Options: ATM-FR, ATM-CES A major purpose for moving to a converged MPLS (or PWE-3) network is to t= ake all of this functionality with as well a have the ability to introduce ne= w services (MPLS, IP,...). This functionality must bring with it the OAM fault and performance functionality that allows carriers to use the combination of PE, CE and element management systems to perform fault localization. Specifications such as FRF.5 and FRF.8 are clearly defined and this same approach should be used int the PWE3 space. Respectfully, Jack PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 F > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Mark > Seery > Sent: Tuesday, June 03, 2003 11:01 PM > To: pwe3@ietf.org > Subject: Re: [PWE3] PWE Service interworking > > > So having tried a general description, a slightly > (not constructing access points etc.) treatment of > this issue might look something like the following. > > Acronyms NIWF - network internetworking function and > SIWF - Service interworking function are not acronyms > used by any standards body (that I know of). > > fig.1 is essentially how I think of PW today. > > Network Interworking > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > fig.1 > > CE1 PE1 P PE2 CE2 > ----------- ----------- > | NIWF | | NIWF | > ------ |---------| ------ |---------| ------ > | FR |--| FR | PW |---| PW |---| PW | FR |--| FR | > ------ ----------- ------ ----------- ------ > > Where FR could be FR, Ethernet, or ATM. > In the ATM case, AAL5 would (typically) be > encapsulated on to a PW, and no understanding of upper > layer protocols would be required. > > Service Interworking > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > fig.2 > > CE1 PE1 P PE2 CE2 > ----------- ----------- > | SIWF | | | > ------ |---------| ------ | | ------ > | FR |--| FR | PW |---| PW |---| PW |--| PW | > ------ ----------- ------ ----------- ------ > > The scenario of a PW going to a CE is unlikely today, > of course, but shown here as a theoretical option. > > or > fig.3 > > CE1 PE1 P PE2 CE2 > ----------- ----------- > | SIWF | | | > ------ |---------| ------ | | ------ > | FR |--| FR | MP |---| MP |---| MP |--| MP | > ------ ----------- ------ ----------- ------ > > The scenario of a MPLS (MP) service going to a CE is > more likely than that of a PW, but still not likely to > be widespread in the near term > > or > fig.4 > > CE1 PE1 P PE2 CE2 > ----------- ----------------- > | NIWF | | NIWF | SIWF | > ------ |---------| ------ |---------------| > ----- > | FR |--| FR | PW |---| PW |---| PW | FR | ATM > |--|ATM| > ------ ----------- ------ ----------------- > ----- > > In this scenario FR is encapsulated on to a PW at PE1 > and decapsulated off of a PW at PE2 and then service > interworked to an ATM service. The ATM service may be > going to a CE or to an ATM network (in which case the > SIWF would be slightly different) > > or > fig.5 > > CE1 PE1 P PE2 CE2 > ----------- ----------- > | SIWF | | SIWF | > ------ |---------| ------ |---------| ------ > | FR |--| FR | PW |---| PW |---| PW | ATM|--| ATM| > ------ ----------- ------ ----------- ------ > > this seems simpler than some of the previous examples > but might actually be quite hard and is where > translation to from PW encaps would need to be pretty > good (my guess). > > or > fig.6 > > CE1 FR SW ATM SW PE1 P > ----------- ----------- > | SIWF | |NIWF/SIWF| > ------ |---------| ------- | --------| ------ > | FR |--| FR | ATM|---| ATM |---| ATM | MP|--| MP | > ------ ----------- ------- ----------- ------ > > In this case FR is interworked with ATM, and RFC 1490 > with RFC 1483 at the FR SW. Then at the PE, ATM is > network or service interworked with MP. In the case of > routed RFC 1490/1483, an IP packet could be popped and > encapsulated over MPLS, but there would still be OAM > interworking between the ATM and MPLS functions. > > In the case of bridged RFC1490/1483, it may be > possibly to interwork the ATM and MPLS functions and > then interwork RFC1483 and PW. > > Just some ideas of scenarios we may be looking at in > the future. > > Having thought about it, there is probably no getting > by with just a casual discussion of this issue. So we > either add it to the charter now, or delay it as seems > to be the consensus (i.e. I have only heard one strong > voice pushing it to the forefront). > > Mark > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-luo-l2tpext-l2vpn-signaling-02.txt Date: Wed, 04 Jun 2003 07:57:43 -0400 Lines: 90 Sender: nsyracus@cnri.reston.va.us Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: l2tpext@ietf.org, ppvpn@nortelnetworks.com, pwe3@ietf.org X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Jun 04 13:55:41 2003 Return-path: To: IETF-Announce: ; X-SMTP-HELO: ietf.org X-SMTP-MAIL-FROM: nsyracus@cnri.reston.va.us X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: odin.ietf.org [132.151.1.176] Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : L2VPN Signaling Using L2TPv3 Author(s) : W. Luo Filename : draft-luo-l2tpext-l2vpn-signaling-02.txt Pages : 20 Date : 2003-6-3 The Layer 2 Tunneling Protocol (L2TPv3) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TPv3 describes the use of an L2TP session to cross-connect two Layer 2 circuits attached to a pair of peering LACs. A cross-connect is a basic form of Layer 2 Virtual Private Networks (L2VPNs). This document describes mechanisms which utilize the building blocks that L2TP provides to construct different types of L2VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-luo-l2tpext-l2vpn-signaling-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-luo-l2tpext-l2vpn-signaling-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-luo-l2tpext-l2vpn-signaling-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 07:42:08 -0700 Lines: 159 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Wed Jun 04 16:50:03 2003 Return-path: To: "'Mark Seery'" , 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 Mark, Regarding Service interworking I believe the simplest and most logical model is to do service interworking with MPLS on both IWFs. Assuming (PL= Payload), the following figure shows an example of what I think is a proper AT-MPLS-FR service interworking: CE--------PE-------P--------PE---------CE PL PL PL PL AAL5 X X Q.922 ATM MPLS MPLS FR Both PEs do service interworking. One does ATM-MPLS service interworking and the other one does FR-MPLS service interworking. The advantage is that each PE needs to support a maximum of N service interworking functions (N is all known L2 protocols). While your proposed model requires N square service interworking functions to be supported in a single PE. Yours, -Shahram >-----Original Message----- >From: Mark Seery [mailto:mark@mseery.com] >Sent: Tuesday, June 03, 2003 5:01 PM >To: pwe3@ietf.org >Subject: Re: [PWE3] PWE Service interworking > > >All, remember the constraints: a) can't quote from a >non-IETF standard, b) can't use the word layer. Will >do my best. > >Defining service interworking >===================== > >The simplest explanations (IMO) for interworking are >as follows: > >Network interworking - ingress and egress attachment >circuits use the same protocols >Service interworking - ingress and egress attachment >circuits use different protocols > >Now any interworking agreement is going to specify >exactly what protocols, so the actual definition >necessarily becomes less generalized. Typical >protocols that have been involved in interworking >standards are link-layer PDUs and adaptation layers >(FR, ATM, AAL1, AAL5) and Multiprotocol encapsulation >standards (RFC 1483, RFC 1490). > >Simplistically a network interworking function has to >map a service PDU to an encapsulation that provides >service attributes on an underlying network such that >the service entrities at each side of the network do >not realize they are not operating over a native >service network. An example of this would be two Frame >Relay attachment circuits connected to an ATM network, >or two Ethernet attachment circuits connected to a >MPLS or IP network (i.e. PW) > >For example: > >CE--FR--PE--FR/PW/PSN--PE-FR-CE > >I don't think there has been much controversy about >this, the only real area of controversy I recall is >the degree to which the PW/PSN emualtes the >ingress/egress service definitions. In providing this >service emulation things such as the following may be >mapped: > >1. Variable length PDU formatting and delimiting >2. Error detection >3. Connection multiplexing >4. Loss Priority Indication >5. Congestion Indication (Forward and Backward) >6. PVC Status Management > >So in this sense Eric is correct. RFC 1490/1483 are >not the same as the encapsulations used to perform >network interworking, or what might otherwise be >referred to as (sub)convergence. In this context the >more appropriate question might be, was AAL1 or AAL5 >explored as to their applicability for encapsulating >services over MPLS or IP; they may not provide what is >needed, and that is a perfectly acceptable answer if >that is the case. > >Some standards differentiate between the case when two >subscribers are communicating over a cloud, and when >two networks are communicating over a third cloud; I >will not for the sake of trying to establish some >basic concepts. > >Now we move to service interworking, where we are >trying to provide for a service to have two different >interfaces at either end of a cloud. In this case, >simple encapsulation does not work, the hard task (and >I do understand it is not considered trivial by some >developers) is to have say Frame Relay go in one side, >and have ATM come out the other side. For example: > >CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE > >The IWF (interworking function) could be in a variety >of places, I just put it there for grins. > >In this example, we now have to not only convert the >Frame Relay base protocol to ATM, but if we do not >convert RFC1490 running above it to RFC1483, then >there will be problems at that level of protocol >interaction. > >NLPIDs are used often in encapsulations to provide >indication of encapsulated protocols. Service >interworking could be done at the ingress PE, in which >case the resultant PW is really in the format of the >egress attachment circuit. Another option is to do it >at the egress PE, which would mean translating from >the 1490/FR/PW/MPLS or IP PDUs to the resultant >1483/aal5/atm attachment circuit. The question then >becomes should the FR PDU just be popped from the PW >and examined, or should the PW indicate, by a NLPID >equivalent, what is contained within the FR PDU? That >would probably be an implementation decision, but >those types of dicussions may uncover any weaknesses >in the current methods, if they exist at all, and they >may not. > >If the PW is discarded before the IWF function, then >that is probably not a problem as long as the >resultant FR PDU is sufficient to perform the mapping; >and therefore I am not concerned that the PW >"whatever" disappears, this is analgous to the ATM >AAL5 PDU disappearing and a new one being created, if >the service interworking was performed in the same way > >So the more I think about, the less problems I >see.......... > >There is some thought floating around that if the PW >encap was similar to or identical to whatever network >is most likely to be interworked to, then that may >make like easier for implementors and operators - that >I leave as a discussion point, and note the horse has >probably already bolted on that one, for this WG, in >this time slot. > >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: Sasha Vainshtein Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 18:27:52 +0200 Lines: 212 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 Wed Jun 04 17:36:36 2003 Return-path: To: "'Shahram Davari'" , "'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 Shahram, Mark and all, A couple of comments/questions. 1. I agree with Shahram that the model he has proposed is much simpler than one proposed by Mark in his "explanation email". To me, this makes it preferable. 2. My gut feeling is that: a) This difference in approaches is exactly what the current PWE3 WG Charter defines as the rationale for the PWE3 work when it says: The PSN can transport PDUs for multiple services, and the conversion/interworking functions per service pair are not needed. b) It means (and has been correctly interpreted by many people including, I think, Mark) that the Charter defines "service interworking" out of scope for PWE3 - and for a good reason. 3. I am not sure if the term "X-to-MPLS service interworking" is applicable to Shahram's diagram. E.g., for PL=Ethernet I do not expect that the EXC bits in the MPLS encap will reflect DE/CLP markings of the containing FR/ATM-based AC. All the ETHoATM/ETHoFR-specific information will be simply discarded by the PEs! (At least this is, IMO, what the current Ethernet encapsulation draft says:-). However, this does not affect the conclusions of (1) and (2) above in any way. Did I miss something? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, June 04, 2003 4:42 PM > To: 'Mark Seery'; pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Mark, > > Regarding Service interworking I believe the simplest and > most logical model is to do service interworking with MPLS > on both IWFs. Assuming (PL= Payload), the following figure shows an > example of what I think is a proper AT-MPLS-FR service interworking: > > > CE--------PE-------P--------PE---------CE > PL PL PL PL > AAL5 X X Q.922 > ATM MPLS MPLS FR > > Both PEs do service interworking. One does ATM-MPLS service > interworking and the other one does FR-MPLS service interworking. > > The advantage is that each PE needs to support a maximum of N service > interworking functions (N is all known L2 protocols). While your > proposed model requires N square service interworking functions to be > supported in a single PE. > > Yours, > -Shahram > > > >-----Original Message----- > >From: Mark Seery [mailto:mark@mseery.com] > >Sent: Tuesday, June 03, 2003 5:01 PM > >To: pwe3@ietf.org > >Subject: Re: [PWE3] PWE Service interworking > > > > > >All, remember the constraints: a) can't quote from a > >non-IETF standard, b) can't use the word layer. Will > >do my best. > > > >Defining service interworking > >===================== > > > >The simplest explanations (IMO) for interworking are > >as follows: > > > >Network interworking - ingress and egress attachment > >circuits use the same protocols > >Service interworking - ingress and egress attachment > >circuits use different protocols > > > >Now any interworking agreement is going to specify > >exactly what protocols, so the actual definition > >necessarily becomes less generalized. Typical > >protocols that have been involved in interworking > >standards are link-layer PDUs and adaptation layers > >(FR, ATM, AAL1, AAL5) and Multiprotocol encapsulation > >standards (RFC 1483, RFC 1490). > > > >Simplistically a network interworking function has to > >map a service PDU to an encapsulation that provides > >service attributes on an underlying network such that > >the service entrities at each side of the network do > >not realize they are not operating over a native > >service network. An example of this would be two Frame > >Relay attachment circuits connected to an ATM network, > >or two Ethernet attachment circuits connected to a > >MPLS or IP network (i.e. PW) > > > >For example: > > > >CE--FR--PE--FR/PW/PSN--PE-FR-CE > > > >I don't think there has been much controversy about > >this, the only real area of controversy I recall is > >the degree to which the PW/PSN emualtes the > >ingress/egress service definitions. In providing this > >service emulation things such as the following may be > >mapped: > > > >1. Variable length PDU formatting and delimiting > >2. Error detection > >3. Connection multiplexing > >4. Loss Priority Indication > >5. Congestion Indication (Forward and Backward) > >6. PVC Status Management > > > >So in this sense Eric is correct. RFC 1490/1483 are > >not the same as the encapsulations used to perform > >network interworking, or what might otherwise be > >referred to as (sub)convergence. In this context the > >more appropriate question might be, was AAL1 or AAL5 > >explored as to their applicability for encapsulating > >services over MPLS or IP; they may not provide what is > >needed, and that is a perfectly acceptable answer if > >that is the case. > > > >Some standards differentiate between the case when two > >subscribers are communicating over a cloud, and when > >two networks are communicating over a third cloud; I > >will not for the sake of trying to establish some > >basic concepts. > > > >Now we move to service interworking, where we are > >trying to provide for a service to have two different > >interfaces at either end of a cloud. In this case, > >simple encapsulation does not work, the hard task (and > >I do understand it is not considered trivial by some > >developers) is to have say Frame Relay go in one side, > >and have ATM come out the other side. For example: > > > >CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE > > > >The IWF (interworking function) could be in a variety > >of places, I just put it there for grins. > > > >In this example, we now have to not only convert the > >Frame Relay base protocol to ATM, but if we do not > >convert RFC1490 running above it to RFC1483, then > >there will be problems at that level of protocol > >interaction. > > > >NLPIDs are used often in encapsulations to provide > >indication of encapsulated protocols. Service > >interworking could be done at the ingress PE, in which > >case the resultant PW is really in the format of the > >egress attachment circuit. Another option is to do it > >at the egress PE, which would mean translating from > >the 1490/FR/PW/MPLS or IP PDUs to the resultant > >1483/aal5/atm attachment circuit. The question then > >becomes should the FR PDU just be popped from the PW > >and examined, or should the PW indicate, by a NLPID > >equivalent, what is contained within the FR PDU? That > >would probably be an implementation decision, but > >those types of dicussions may uncover any weaknesses > >in the current methods, if they exist at all, and they > >may not. > > > >If the PW is discarded before the IWF function, then > >that is probably not a problem as long as the > >resultant FR PDU is sufficient to perform the mapping; > >and therefore I am not concerned that the PW > >"whatever" disappears, this is analgous to the ATM > >AAL5 PDU disappearing and a new one being created, if > >the service interworking was performed in the same way > > > >So the more I think about, the less problems I > >see.......... > > > >There is some thought floating around that if the PW > >encap was similar to or identical to whatever network > >is most likely to be interworked to, then that may > >make like easier for implementors and operators - that > >I leave as a discussion point, and note the horse has > >probably already bolted on that one, for this WG, in > >this time slot. > > > >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: Mark Seery Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 08:32:33 -0700 (PDT) Lines: 207 Sender: pwe3-admin@ietf.org References: <00e101c32a8e$f958e0e0$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 Wed Jun 04 17:37:07 2003 Return-path: To: Jack Pugaczewski In-Reply-To: <00e101c32a8e$f958e0e0$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 h54Fc0B27196 Status: O thanks for the feedback Jack and understood. Quick question, when you say service interworking between ATM-CES, I an not quite sure what that means, does that mean ATM to TDM or non AAL1 ATM to AAL1 ATM? Thanks, Mark --- Jack Pugaczewski wrote: > A carrier's perspective: >=20 > The existing customer based is a combination of the > following Networking > Interworking options: > ATM-ATM, FR-FR, CE-CE, Ethernet-Ethernet >=20 > and Service Interworking Options: > ATM-FR, ATM-CES >=20 > A major purpose for moving to a converged MPLS (or > PWE-3) network is to take > all of this functionality with as well a have the > ability to introduce new > services (MPLS, IP,...). This functionality must > bring with it the OAM > fault and performance functionality that allows > carriers to use the > combination of PE, CE and element management systems > to perform fault > localization. >=20 > Specifications such as FRF.5 and FRF.8 are clearly > defined and this same > approach should be used int the PWE3 space. >=20 > Respectfully, >=20 > Jack >=20 > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > =A0 >=20 > F > > -----Original Message----- > > From: pwe3-admin@ietf.org > [mailto:pwe3-admin@ietf.org]On Behalf Of Mark > > Seery > > Sent: Tuesday, June 03, 2003 11:01 PM > > To: pwe3@ietf.org > > Subject: Re: [PWE3] PWE Service interworking > > > > > > So having tried a general description, a slightly > > (not constructing access points etc.) treatment of > > this issue might look something like the > following. > > > > Acronyms NIWF - network internetworking function > and > > SIWF - Service interworking function are not > acronyms > > used by any standards body (that I know of). > > > > fig.1 is essentially how I think of PW today. > > > > Network Interworking > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > fig.1 > > > > CE1 PE1 P PE2 CE2 > > ----------- ----------- > > | NIWF | | NIWF | > > ------ |---------| ------ |---------| ------ > > | FR |--| FR | PW |---| PW |---| PW | FR |--| FR | > > ------ ----------- ------ ----------- ------ > > > > Where FR could be FR, Ethernet, or ATM. > > In the ATM case, AAL5 would (typically) be > > encapsulated on to a PW, and no understanding of > upper > > layer protocols would be required. > > > > Service Interworking > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > fig.2 > > > > CE1 PE1 P PE2 CE2 > > ----------- ----------- > > | SIWF | | | > > ------ |---------| ------ | | ------ > > | FR |--| FR | PW |---| PW |---| PW |--| PW | > > ------ ----------- ------ ----------- ------ > > > > The scenario of a PW going to a CE is unlikely > today, > > of course, but shown here as a theoretical option. > > > > or > > fig.3 > > > > CE1 PE1 P PE2 CE2 > > ----------- ----------- > > | SIWF | | | > > ------ |---------| ------ | | ------ > > | FR |--| FR | MP |---| MP |---| MP |--| MP | > > ------ ----------- ------ ----------- ------ > > > > The scenario of a MPLS (MP) service going to a CE > is > > more likely than that of a PW, but still not > likely to > > be widespread in the near term > > > > or > > fig.4 > > > > CE1 PE1 P PE2 =20 > CE2 > > ----------- ----------------- > > | NIWF | | NIWF | SIWF | > > ------ |---------| ------ |---------------| > > ----- > > | FR |--| FR | PW |---| PW |---| PW | FR | ATM > > |--|ATM| > > ------ ----------- ------ ----------------- > > ----- > > > > In this scenario FR is encapsulated on to a PW at > PE1 > > and decapsulated off of a PW at PE2 and then > service > > interworked to an ATM service. The ATM service may > be > > going to a CE or to an ATM network (in which case > the > > SIWF would be slightly different) > > > > or > > fig.5 > > > > CE1 PE1 P PE2 CE2 > > ----------- ----------- > > | SIWF | | SIWF | > > ------ |---------| ------ |---------| ------ > > | FR |--| FR | PW |---| PW |---| PW | ATM|--| ATM| > > ------ ----------- ------ ----------- ------ > > > > this seems simpler than some of the previous > examples > > but might actually be quite hard and is where > > translation to from PW encaps would need to be > pretty > > good (my guess). > > > > or > > fig.6 > > > > CE1 FR SW ATM SW PE1 P > > ----------- ----------- > > | SIWF | |NIWF/SIWF| > > ------ |---------| ------- | --------|=20 > ------ > > | FR |--| FR | ATM|---| ATM |---| ATM | MP|--| MP > | > > ------ ----------- ------- -----------=20 > ------ > > > > In this case FR is interworked with ATM, and RFC > 1490 > > with RFC 1483 at the FR SW. Then at the PE, ATM is > > network or service interworked with MP. In the > case of > > routed RFC 1490/1483, an IP packet could be popped > and > > encapsulated over MPLS, but there would still be > OAM > > interworking between the ATM and MPLS functions. > > > > In the case of bridged RFC1490/1483, it may be > > possibly to interwork the ATM and MPLS functions > and > > then interwork RFC1483 and PW. > > > > Just some ideas of scenarios we may be looking at > in > > the future. > > > > Having thought about it, there is probably no > getting > > by with just a casual discussion of this issue. So > we > > either add it to the charter now, or delay it as > seems > > to be the consensus (i.e. I have only heard one > strong > > voice pushing it to the forefront). > > > > Mark > > > > > > _______________________________________________ > > 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: Mark Seery Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 08:38:59 -0700 (PDT) Lines: 58 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C99C@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 Jun 04 17:42:36 2003 Return-path: To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C99C@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 Sharam, I agree this is simpler and also more technically accurate/and more reflective of current interworking standards by the inclusion of "Q.922". So happy to go with your model. Question for you though, is it interworking to MPLS that is required, or interworking to PW that is required. I would also not that at one of the IWFs RFC1483/RFC1490 interworking should be an option, what would you suggest in that regard? Also I assume you don't ever see MPLS as being as service interface from your response? And do you see this model working also for Ethernet to ATM/FR interworking? Thanks, Mark --- Shahram Davari wrote: > Mark, > > Regarding Service interworking I believe the > simplest and > most logical model is to do service interworking > with MPLS > on both IWFs. Assuming (PL= Payload), the following > figure shows an > example of what I think is a proper AT-MPLS-FR > service interworking: > > > CE--------PE-------P--------PE---------CE > PL PL PL PL > AAL5 X X Q.922 > ATM MPLS MPLS FR > > Both PEs do service interworking. One does ATM-MPLS > service > interworking and the other one does FR-MPLS service > interworking. > > The advantage is that each PE needs to support a > maximum of N service > interworking functions (N is all known L2 > protocols). While your > proposed model requires N square service > interworking functions to be > supported in a single PE. > > Yours, > -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 08:49:09 -0700 (PDT) Lines: 73 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 Jun 04 17:52:19 2003 Return-path: To: Sasha Vainshtein In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, --- Sasha Vainshtein wrote: > Shahram, Mark and all, > A couple of comments/questions. > > 1. I agree with Shahram that the model he has > proposed > is much simpler than one proposed by Mark in his > "explanation email". To me, this makes it > preferable. I agree, Shahram got it right (even mention one letter.number standard), though curious about how he sees PW playing in all this. > > 2. My gut feeling is that: > a) This difference in approaches is exactly what > the current PWE3 WG Charter defines as the > rationale for the PWE3 work when it says: > > The PSN can transport PDUs for multiple > services, > and the conversion/interworking functions per > service pair are not needed. > > b) It means (and has been correctly interpreted > by many > people including, I think, Mark) that the > Charter defines > "service interworking" out of scope for PWE3 - > and for a good > reason. MS=> See below as well as my response to Shahram > 3. I am not sure if the term "X-to-MPLS service > interworking" > is applicable to Shahram's diagram. E.g., for > PL=Ethernet I > do not expect that the EXC bits in the MPLS encap > will reflect > DE/CLP markings of the containing FR/ATM-based > AC. All the > ETHoATM/ETHoFR-specific information will be > simply discarded by the PEs! > (At least this is, IMO, what the current Ethernet > encapsulation > draft says:-). However, this does not affect the > conclusions of (1) > and (2) above in any way. > > Did I miss something? > MS=> No, you did not miss something. This is in essence one of the concerns I was raising when I previously asked whether encap authors had considered the service interworking case - though clearly I had not formulated or articulated my thoughts properly. This is I think also the same as the concern which has sometimes been articulated as "..every encap author doing their work independent of the others.." i.e. no generalized format for interworking encaps. So it is one of those things like inter-AS work, it is good to put it off because it helps you to break down the problem, but it is bad to put to off because as a result, you don't actuallt see the long-term problem for what it is. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 10:53:26 -0500 Lines: 236 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 Wed Jun 04 17:54:24 2003 Return-path: To: "Sasha Vainshtein" , "'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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by uswgco34.uswest.com id h54FrTZU005409 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54FrYB28332 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h54FuAB28500 Status: O Then what group/organization is going to take on the interworking and all= of the issues ? PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Sash= a > Vainshtein > Sent: Wednesday, June 04, 2003 11:28 AM > To: 'Shahram Davari'; 'Mark Seery' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Shahram, Mark and all, > A couple of comments/questions. > > 1. I agree with Shahram that the model he has proposed > is much simpler than one proposed by Mark in his > "explanation email". To me, this makes it preferable. > > 2. My gut feeling is that: > a) This difference in approaches is exactly what > the current PWE3 WG Charter defines as the > rationale for the PWE3 work when it says: > > The PSN can transport PDUs for multiple services, > and the conversion/interworking functions per > service pair are not needed. > > b) It means (and has been correctly interpreted by many > people including, I think, Mark) that the Charter defines > "service interworking" out of scope for PWE3 - and for a good > reason. > > 3. I am not sure if the term "X-to-MPLS service interworking" > is applicable to Shahram's diagram. E.g., for PL=3DEthernet I > do not expect that the EXC bits in the MPLS encap will reflect > DE/CLP markings of the containing FR/ATM-based AC. All the > ETHoATM/ETHoFR-specific information will be simply discarded > by the PEs! > (At least this is, IMO, what the current Ethernet encapsulation > draft says:-). However, this does not affect the conclusions of (1) > and (2) above in any way. > > Did I miss something? > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Wednesday, June 04, 2003 4:42 PM > > To: 'Mark Seery'; pwe3@ietf.org > > Subject: RE: [PWE3] PWE Service interworking > > > > > > Mark, > > > > Regarding Service interworking I believe the simplest and > > most logical model is to do service interworking with MPLS > > on both IWFs. Assuming (PL=3D Payload), the following figure shows an > > example of what I think is a proper AT-MPLS-FR service interworking: > > > > > > CE--------PE-------P--------PE---------CE > > PL PL PL PL > > AAL5 X X Q.922 > > ATM MPLS MPLS FR > > > > Both PEs do service interworking. One does ATM-MPLS service > > interworking and the other one does FR-MPLS service interworking. > > > > The advantage is that each PE needs to support a maximum of N service > > interworking functions (N is all known L2 protocols). While your > > proposed model requires N square service interworking functions to be > > supported in a single PE. > > > > Yours, > > -Shahram > > > > > > >-----Original Message----- > > >From: Mark Seery [mailto:mark@mseery.com] > > >Sent: Tuesday, June 03, 2003 5:01 PM > > >To: pwe3@ietf.org > > >Subject: Re: [PWE3] PWE Service interworking > > > > > > > > >All, remember the constraints: a) can't quote from a > > >non-IETF standard, b) can't use the word layer. Will > > >do my best. > > > > > >Defining service interworking > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > >The simplest explanations (IMO) for interworking are > > >as follows: > > > > > >Network interworking - ingress and egress attachment > > >circuits use the same protocols > > >Service interworking - ingress and egress attachment > > >circuits use different protocols > > > > > >Now any interworking agreement is going to specify > > >exactly what protocols, so the actual definition > > >necessarily becomes less generalized. Typical > > >protocols that have been involved in interworking > > >standards are link-layer PDUs and adaptation layers > > >(FR, ATM, AAL1, AAL5) and Multiprotocol encapsulation > > >standards (RFC 1483, RFC 1490). > > > > > >Simplistically a network interworking function has to > > >map a service PDU to an encapsulation that provides > > >service attributes on an underlying network such that > > >the service entrities at each side of the network do > > >not realize they are not operating over a native > > >service network. An example of this would be two Frame > > >Relay attachment circuits connected to an ATM network, > > >or two Ethernet attachment circuits connected to a > > >MPLS or IP network (i.e. PW) > > > > > >For example: > > > > > >CE--FR--PE--FR/PW/PSN--PE-FR-CE > > > > > >I don't think there has been much controversy about > > >this, the only real area of controversy I recall is > > >the degree to which the PW/PSN emualtes the > > >ingress/egress service definitions. In providing this > > >service emulation things such as the following may be > > >mapped: > > > > > >1. Variable length PDU formatting and delimiting > > >2. Error detection > > >3. Connection multiplexing > > >4. Loss Priority Indication > > >5. Congestion Indication (Forward and Backward) > > >6. PVC Status Management > > > > > >So in this sense Eric is correct. RFC 1490/1483 are > > >not the same as the encapsulations used to perform > > >network interworking, or what might otherwise be > > >referred to as (sub)convergence. In this context the > > >more appropriate question might be, was AAL1 or AAL5 > > >explored as to their applicability for encapsulating > > >services over MPLS or IP; they may not provide what is > > >needed, and that is a perfectly acceptable answer if > > >that is the case. > > > > > >Some standards differentiate between the case when two > > >subscribers are communicating over a cloud, and when > > >two networks are communicating over a third cloud; I > > >will not for the sake of trying to establish some > > >basic concepts. > > > > > >Now we move to service interworking, where we are > > >trying to provide for a service to have two different > > >interfaces at either end of a cloud. In this case, > > >simple encapsulation does not work, the hard task (and > > >I do understand it is not considered trivial by some > > >developers) is to have say Frame Relay go in one side, > > >and have ATM come out the other side. For example: > > > > > >CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE > > > > > >The IWF (interworking function) could be in a variety > > >of places, I just put it there for grins. > > > > > >In this example, we now have to not only convert the > > >Frame Relay base protocol to ATM, but if we do not > > >convert RFC1490 running above it to RFC1483, then > > >there will be problems at that level of protocol > > >interaction. > > > > > >NLPIDs are used often in encapsulations to provide > > >indication of encapsulated protocols. Service > > >interworking could be done at the ingress PE, in which > > >case the resultant PW is really in the format of the > > >egress attachment circuit. Another option is to do it > > >at the egress PE, which would mean translating from > > >the 1490/FR/PW/MPLS or IP PDUs to the resultant > > >1483/aal5/atm attachment circuit. The question then > > >becomes should the FR PDU just be popped from the PW > > >and examined, or should the PW indicate, by a NLPID > > >equivalent, what is contained within the FR PDU? That > > >would probably be an implementation decision, but > > >those types of dicussions may uncover any weaknesses > > >in the current methods, if they exist at all, and they > > >may not. > > > > > >If the PW is discarded before the IWF function, then > > >that is probably not a problem as long as the > > >resultant FR PDU is sufficient to perform the mapping; > > >and therefore I am not concerned that the PW > > >"whatever" disappears, this is analgous to the ATM > > >AAL5 PDU disappearing and a new one being created, if > > >the service interworking was performed in the same way > > > > > >So the more I think about, the less problems I > > >see.......... > > > > > >There is some thought floating around that if the PW > > >encap was similar to or identical to whatever network > > >is most likely to be interworked to, then that may > > >make like easier for implementors and operators - that > > >I leave as a discussion point, and note the horse has > > >probably already bolted on that one, for this WG, in > > >this time slot. > > > > > >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 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 08:56:40 -0700 (PDT) Lines: 20 Sender: pwe3-admin@ietf.org References: <010601c32ab1$6f8cc3e0$854c1cac@dyn.interprise.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 04 17:59:43 2003 Return-path: To: Jack Pugaczewski In-Reply-To: <010601c32ab1$6f8cc3e0$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 the requirement is to interwork with MPLS, then I suspect a number of organizations are probably already delving in this area including MPLS Forum/FR Forum, ITU, and possibly MEF (though I don't have much visibility in there). If the requirement is to interwork with PW, then I suspect it would probably land in the IETF's court so to speak. Mark --- Jack Pugaczewski wrote: > Then what group/organization is going to take on the > interworking and all of > the issues ? > > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 11:00:10 -0500 Lines: 238 Sender: pwe3-admin@ietf.org References: <20030604153233.46028.qmail@web13506.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 Wed Jun 04 18:09:19 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: <20030604153233.46028.qmail@web13506.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 h54G0c73000244 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54G0hB28822 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h54GBaB30684 Status: O CES per ATM Forum specification af-vtoa-0078.000 which discusses AAL1 and specifically Structured and Unstructed CES. The benefit of ATM-CES is th= at a customer can share a common facility for both AAL-5 and CES traffic. T= he CE (or CPE) is responsible for being CES compliant. Within the carrier cloud the CES termination can be handed off to a Class 5 switch TDM circu= it. It should also be noted that the CES functionality requires DCS functionality for the trunk conditioning. It would be expected that any PWE-3 implementation would provide the same functionality. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Mark > Seery > Sent: Wednesday, June 04, 2003 10:33 AM > To: Jack Pugaczewski > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > thanks for the feedback Jack and understood. > > Quick question, when you say service interworking > between ATM-CES, I an not quite sure what that means, > does that mean ATM to TDM or non AAL1 ATM to AAL1 ATM? > > Thanks, > Mark > > --- Jack Pugaczewski wrote: > > A carrier's perspective: > > > > The existing customer based is a combination of the > > following Networking > > Interworking options: > > ATM-ATM, FR-FR, CE-CE, Ethernet-Ethernet > > > > and Service Interworking Options: > > ATM-FR, ATM-CES > > > > A major purpose for moving to a converged MPLS (or > > PWE-3) network is to take > > all of this functionality with as well a have the > > ability to introduce new > > services (MPLS, IP,...). This functionality must > > bring with it the OAM > > fault and performance functionality that allows > > carriers to use the > > combination of PE, CE and element management systems > > to perform fault > > localization. > > > > Specifications such as FRF.5 and FRF.8 are clearly > > defined and this same > > approach should be used int the PWE3 space. > > > > Respectfully, > > > > Jack > > > > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > > =A0 > > > > F > > > -----Original Message----- > > > From: pwe3-admin@ietf.org > > [mailto:pwe3-admin@ietf.org]On Behalf Of Mark > > > Seery > > > Sent: Tuesday, June 03, 2003 11:01 PM > > > To: pwe3@ietf.org > > > Subject: Re: [PWE3] PWE Service interworking > > > > > > > > > So having tried a general description, a slightly > > > (not constructing access points etc.) treatment of > > > this issue might look something like the > > following. > > > > > > Acronyms NIWF - network internetworking function > > and > > > SIWF - Service interworking function are not > > acronyms > > > used by any standards body (that I know of). > > > > > > fig.1 is essentially how I think of PW today. > > > > > > Network Interworking > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > fig.1 > > > > > > CE1 PE1 P PE2 CE2 > > > ----------- ----------- > > > | NIWF | | NIWF | > > > ------ |---------| ------ |---------| ------ > > > | FR |--| FR | PW |---| PW |---| PW | FR |--| FR | > > > ------ ----------- ------ ----------- ------ > > > > > > Where FR could be FR, Ethernet, or ATM. > > > In the ATM case, AAL5 would (typically) be > > > encapsulated on to a PW, and no understanding of > > upper > > > layer protocols would be required. > > > > > > Service Interworking > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > fig.2 > > > > > > CE1 PE1 P PE2 CE2 > > > ----------- ----------- > > > | SIWF | | | > > > ------ |---------| ------ | | ------ > > > | FR |--| FR | PW |---| PW |---| PW |--| PW | > > > ------ ----------- ------ ----------- ------ > > > > > > The scenario of a PW going to a CE is unlikely > > today, > > > of course, but shown here as a theoretical option. > > > > > > or > > > fig.3 > > > > > > CE1 PE1 P PE2 CE2 > > > ----------- ----------- > > > | SIWF | | | > > > ------ |---------| ------ | | ------ > > > | FR |--| FR | MP |---| MP |---| MP |--| MP | > > > ------ ----------- ------ ----------- ------ > > > > > > The scenario of a MPLS (MP) service going to a CE > > is > > > more likely than that of a PW, but still not > > likely to > > > be widespread in the near term > > > > > > or > > > fig.4 > > > > > > CE1 PE1 P PE2 > > CE2 > > > ----------- ----------------- > > > | NIWF | | NIWF | SIWF | > > > ------ |---------| ------ |---------------| > > > ----- > > > | FR |--| FR | PW |---| PW |---| PW | FR | ATM > > > |--|ATM| > > > ------ ----------- ------ ----------------- > > > ----- > > > > > > In this scenario FR is encapsulated on to a PW at > > PE1 > > > and decapsulated off of a PW at PE2 and then > > service > > > interworked to an ATM service. The ATM service may > > be > > > going to a CE or to an ATM network (in which case > > the > > > SIWF would be slightly different) > > > > > > or > > > fig.5 > > > > > > CE1 PE1 P PE2 CE2 > > > ----------- ----------- > > > | SIWF | | SIWF | > > > ------ |---------| ------ |---------| ------ > > > | FR |--| FR | PW |---| PW |---| PW | ATM|--| ATM| > > > ------ ----------- ------ ----------- ------ > > > > > > this seems simpler than some of the previous > > examples > > > but might actually be quite hard and is where > > > translation to from PW encaps would need to be > > pretty > > > good (my guess). > > > > > > or > > > fig.6 > > > > > > CE1 FR SW ATM SW PE1 P > > > ----------- ----------- > > > | SIWF | |NIWF/SIWF| > > > ------ |---------| ------- | --------| > > ------ > > > | FR |--| FR | ATM|---| ATM |---| ATM | MP|--| MP > > | > > > ------ ----------- ------- ----------- > > ------ > > > > > > In this case FR is interworked with ATM, and RFC > > 1490 > > > with RFC 1483 at the FR SW. Then at the PE, ATM is > > > network or service interworked with MP. In the > > case of > > > routed RFC 1490/1483, an IP packet could be popped > > and > > > encapsulated over MPLS, but there would still be > > OAM > > > interworking between the ATM and MPLS functions. > > > > > > In the case of bridged RFC1490/1483, it may be > > > possibly to interwork the ATM and MPLS functions > > and > > > then interwork RFC1483 and PW. > > > > > > Just some ideas of scenarios we may be looking at > > in > > > the future. > > > > > > Having thought about it, there is probably no > > getting > > > by with just a casual discussion of this issue. So > > we > > > either add it to the charter now, or delay it as > > seems > > > to be the consensus (i.e. I have only heard one > > strong > > > voice pushing it to the forefront). > > > > > > 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: "Hamid Ould-Brahim" Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 12:07:49 -0400 Lines: 112 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32AB3.71C30668" X-From: pwe3-admin@ietf.org Wed Jun 04 18:14:40 2003 Return-path: To: Shahram Davari , "'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 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_01C32AB3.71C30668 Content-Type: text/plain; charset="iso-8859-1" Shahram, > > Regarding Service interworking I believe the simplest and > most logical model is to do service interworking with MPLS > on both IWFs. Assuming (PL= Payload), the following figure shows an > example of what I think is a proper AT-MPLS-FR service interworking: > > > CE--------PE-------P--------PE---------CE > PL PL PL PL > AAL5 X X Q.922 > ATM MPLS MPLS FR > > Both PEs do service interworking. One does ATM-MPLS service > interworking and the other one does FR-MPLS service interworking. > Okay, but in this example MPLS is just a transport not a service (I don't think ATM-MPLS service interworking is the right term). I would have assumed service interworking implies interworking between an attachment circuit of type X (that attaches to the client device) and another attachment circuit of type Y and there is a pw or tunnel between X and Y (like in your example). In fact if I reuse the scheme described in the PW architecture document (the "protocol layering model" - sorry Eric for the use of the term layer ;-)), for that scenario (as in Shahram figure), a service interworking is as well a pseudo-wire (PW) that: a) connects two heterogeneous attachment/service types where b) the encapsulation is null and c) the PSN convergence which can be null (we still have the PW demultiplexing and PSN) In that case there is a service interworking scenario even if there is no service interworking function implemented on the PE that takes frames received on attachment circuit X and send them as type Y on that PE on either the PSN or CE sides. Hamid. ------_=_NextPart_001_01C32AB3.71C30668 Content-Type: text/html; charset="iso-8859-1"
Shahram,

>
> Regarding Service interworking I believe the simplest and
> most logical model is to do service interworking with MPLS
> on both IWFs. Assuming (PL= Payload), the following figure shows an
> example of what I think is a proper AT-MPLS-FR service interworking:
>
>
> CE--------PE-------P--------PE---------CE
>      PL        PL      PL        PL
>     AAL5       X       X        Q.922
>     ATM       MPLS    MPLS       FR
>
> Both PEs do service interworking. One does ATM-MPLS service
> interworking and the other one does FR-MPLS service interworking.
>

Okay, but in this example MPLS is just a transport not a service
(I don't think ATM-MPLS service interworking is the
right term).

I would have assumed service interworking implies interworking
between an attachment circuit of type X (that attaches
to the client device) and another attachment circuit
of type Y and there is a pw or tunnel between X and Y (like
in your example).
 
In fact if I reuse the scheme described in the PW architecture
document (the "protocol layering model" - sorry Eric for the
use of the term layer ;-)), for that scenario (as in
Shahram figure), a service interworking is as well a
pseudo-wire (PW) that:
 
a) connects two heterogeneous attachment/service types where
b) the encapsulation is null and
c) the PSN convergence which can be null
 
(we still have the PW demultiplexing and PSN)
 
In that case there is a service interworking scenario even if there
is no service interworking function implemented on the PE that takes
frames received on attachment circuit X and send them as type Y
on that PE on either the PSN or CE sides.

Hamid.

------_=_NextPart_001_01C32AB3.71C30668-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 09:16:52 -0700 (PDT) Lines: 18 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 04 18:23:39 2003 Return-path: To: Jack Pugaczewski Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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, --- Mark Seery wrote: [SNIP] > If the requirement is to interwork with PW, then I > suspect it would probably land in the IETF's court > so > to speak. Though I have been informed offline that MPLS Forum is already doing work in the area of PW, with the inference that the IETF tends not to pursue interworking projects. So perhaps pursuing this discussion further is not fruitful, lest the thread becomes an annoyance. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 11:21:24 -0500 Lines: 33 Sender: pwe3-admin@ietf.org References: <20030604161652.46864.qmail@web13502.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 Wed Jun 04 18:25:53 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: <20030604161652.46864.qmail@web13502.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 h54GLQ73004640 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54GLTB31346 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h54GOCB31517 Status: O Agree. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: Wednesday, June 04, 2003 11:17 AM > To: Jack Pugaczewski > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Jack, > > --- Mark Seery wrote: > [SNIP] > > If the requirement is to interwork with PW, then I > > suspect it would probably land in the IETF's court > > so > > to speak. > > Though I have been informed offline that MPLS Forum is > already doing work in the area of PW, with the > inference that the IETF tends not to pursue > interworking projects. > > So perhaps pursuing this discussion further is not > fruitful, lest the thread becomes an annoyance. > > Mark > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Eric Rosen Subject: Re: PWE Service interworking Date: Wed, 04 Jun 2003 12:41:26 -0400 Lines: 24 Sender: pwe3-admin@ietf.org References: <20030603210059.68794.qmail@web13508.mail.yahoo.com> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 04 18:51:47 2003 Return-path: To: Mark Seery In-reply-to: Your message of Tue, 03 Jun 2003 14:00:59 -0700. <20030603210059.68794.qmail@web13508.mail.yahoo.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 Mark> Service interworking - ingress and egress attachment circuits use Mark> different protocols That's clear enough. My assumption has always been that the interworking function would be applied either before or after the use of the pseudowire. When there is already a well-defined service interworking function, as in ATM/FR case, that function would be used. Hence the fact that service interworking is taking place is transparent to the pseudowire, and no PWE3 (or IETF) issues are raised. I think this is the same as you indicate in your example: CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE Is there anything more to say about it? In the special case where the payload is always IP datagrams, but the ingress and egress ACs use different data link protocols, then "ARP Mediation" can be used for interworking, as long as there is no need to provide any sort of faithful data link emulation. This seems to be the one case that might be of interest to the IETF. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE Service interworking Date: Wed, 4 Jun 2003 10:00:41 -0700 (PDT) Lines: 79 Sender: pwe3-admin@ietf.org References: <200306041641.h54GfQ51026443@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 04 19:06:43 2003 Return-path: To: erosen@cisco.com In-Reply-To: <200306041641.h54GfQ51026443@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 Hi Eric, --- Eric Rosen wrote: > > Mark> Service interworking - ingress and egress > attachment circuits use > Mark> different protocols > > That's clear enough. Good. > My assumption has always been that the > interworking function would be > applied either before or after the use of the > pseudowire. When there is > already a well-defined service interworking > function, as in ATM/FR case, > that function would be used. Hence the fact that > service interworking is > taking place is transparent to the pseudowire, and > no PWE3 (or IETF) issues > are raised. In addition, for those that have already implemented PW, this is the most intuitive way to now add service interworking (which is why I think I was leaning in this direction as opposed to the models others have presented). > > I think this is the same as you indicate in your > example: > > CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE Agreed. > Is there anything more to say about it? If the consenus in the WG is that this is the right approach for *this* WG and organization to pursue, then no. The only thing I am not sure about is whether others want the PW to be considered as a transparent cloud to OAM functions. If that is not the case, then yes, I guess we are done, given the above assumptions. Other organizations will no doubt pursue other approaches with the consequent tradeoffs and benefits; and no doubt these will compete in the market place. > In the special case where the payload is always > IP datagrams, but the > ingress and egress ACs use different data link > protocols, then "ARP > Mediation" can be used for interworking, as long > as there is no need to > provide any sort of faithful data link emulation. > This seems to be the one > case that might be of interest to the IETF. Agreed, which really gets to the meat of the issue. The IETF is an organization that has facilitated wide-spread connectivity by developing a protocol (IP) that works across multiple subnetworks and hence views IP as the service layer and not ATM, FR, Ethernet, TDM,...which is why I suspect it tends to pass on layer 2 interworking projects. That said, by developing layer 2 VPN standards, among other things, the IETF has opened a small window in the old time/space continuem (sp?) through which a variety of activities could be punched through if rough consensus was achieved. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 13:08:51 -0400 Lines: 285 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Wed Jun 04 19:17:22 2003 Return-path: Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [PWE3] PWE Service interworking Thread-Index: AcMqtTGoXxxinJTvSZGAoIgQ5wQTMgABQX1w To: "Jack Pugaczewski" , "Sasha Vainshtein" , "Shahram Davari" , "Mark Seery" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54H9YB03091 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h54HC2B03207 Status: O I am participating in this effort in all three groups (IETF, MPLS and MEF= ). IETF showed the door for service interworking (i.e. not a charter :-), although this may change and I believe IP-inteworking PW type already defined? MPLS forum is tackling service interworking when disparate ACs are connected through MPLS PW. MEF is concentrating on service interworking when disparate ACs are directly attached. Both MPLS forum and MEF are going to concentrate first on service interworking for protocols that would work - such as IP. For multiprotocol, some assumptions are made. Such as=20 CEs would treat the underlying FR/ATM transport as Ethernet and generate bridged Ethernet frames over that transport. As for "service" aspects of the interworking, details are being hammered out; Ethernet-LMI of MEF would help. At MPLS forum, what frame format to use over the service interworking PW is being discussed; canonical format of ATM SDU is one of the option. Again, at both forums this work is in infancy but charter exist. /himanshu wavesmith networks > -----Original Message----- > From: Jack Pugaczewski [mailto:jtpugac@qwest.com] > Sent: Wednesday, June 04, 2003 11:53 AM > To: Sasha Vainshtein; 'Shahram Davari'; 'Mark Seery' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking=20 >=20 >=20 > Then what group/organization is going to take on the=20 > interworking and all of > the issues ? >=20 > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > =A0 >=20 >=20 > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On=20 > Behalf Of Sasha > > Vainshtein > > Sent: Wednesday, June 04, 2003 11:28 AM > > To: 'Shahram Davari'; 'Mark Seery' > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] PWE Service interworking > > > > > > Shahram, Mark and all, > > A couple of comments/questions. > > > > 1. I agree with Shahram that the model he has proposed > > is much simpler than one proposed by Mark in his > > "explanation email". To me, this makes it preferable. > > > > 2. My gut feeling is that: > > a) This difference in approaches is exactly what > > the current PWE3 WG Charter defines as the > > rationale for the PWE3 work when it says: > > > > The PSN can transport PDUs for multiple services, > > and the conversion/interworking functions per > > service pair are not needed. > > > > b) It means (and has been correctly interpreted by many > > people including, I think, Mark) that the Charter defines > > "service interworking" out of scope for PWE3 - and for a good > > reason. > > > > 3. I am not sure if the term "X-to-MPLS service interworking" > > is applicable to Shahram's diagram. E.g., for PL=3DEthernet I > > do not expect that the EXC bits in the MPLS encap will reflect > > DE/CLP markings of the containing FR/ATM-based AC. All the > > ETHoATM/ETHoFR-specific information will be simply discarded > > by the PEs! > > (At least this is, IMO, what the current Ethernet encapsulation > > draft says:-). However, this does not affect the=20 > conclusions of (1) > > and (2) above in any way. > > > > Did I miss something? > > > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Wednesday, June 04, 2003 4:42 PM > > > To: 'Mark Seery'; pwe3@ietf.org > > > Subject: RE: [PWE3] PWE Service interworking > > > > > > > > > Mark, > > > > > > Regarding Service interworking I believe the simplest and > > > most logical model is to do service interworking with MPLS > > > on both IWFs. Assuming (PL=3D Payload), the following=20 > figure shows an > > > example of what I think is a proper AT-MPLS-FR service=20 > interworking: > > > > > > > > > CE--------PE-------P--------PE---------CE > > > PL PL PL PL > > > AAL5 X X Q.922 > > > ATM MPLS MPLS FR > > > > > > Both PEs do service interworking. One does ATM-MPLS service > > > interworking and the other one does FR-MPLS service interworking. > > > > > > The advantage is that each PE needs to support a maximum=20 > of N service > > > interworking functions (N is all known L2 protocols). While your > > > proposed model requires N square service interworking=20 > functions to be > > > supported in a single PE. > > > > > > Yours, > > > -Shahram > > > > > > > > > >-----Original Message----- > > > >From: Mark Seery [mailto:mark@mseery.com] > > > >Sent: Tuesday, June 03, 2003 5:01 PM > > > >To: pwe3@ietf.org > > > >Subject: Re: [PWE3] PWE Service interworking > > > > > > > > > > > >All, remember the constraints: a) can't quote from a > > > >non-IETF standard, b) can't use the word layer. Will > > > >do my best. > > > > > > > >Defining service interworking > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > >The simplest explanations (IMO) for interworking are > > > >as follows: > > > > > > > >Network interworking - ingress and egress attachment > > > >circuits use the same protocols > > > >Service interworking - ingress and egress attachment > > > >circuits use different protocols > > > > > > > >Now any interworking agreement is going to specify > > > >exactly what protocols, so the actual definition > > > >necessarily becomes less generalized. Typical > > > >protocols that have been involved in interworking > > > >standards are link-layer PDUs and adaptation layers > > > >(FR, ATM, AAL1, AAL5) and Multiprotocol encapsulation > > > >standards (RFC 1483, RFC 1490). > > > > > > > >Simplistically a network interworking function has to > > > >map a service PDU to an encapsulation that provides > > > >service attributes on an underlying network such that > > > >the service entrities at each side of the network do > > > >not realize they are not operating over a native > > > >service network. An example of this would be two Frame > > > >Relay attachment circuits connected to an ATM network, > > > >or two Ethernet attachment circuits connected to a > > > >MPLS or IP network (i.e. PW) > > > > > > > >For example: > > > > > > > >CE--FR--PE--FR/PW/PSN--PE-FR-CE > > > > > > > >I don't think there has been much controversy about > > > >this, the only real area of controversy I recall is > > > >the degree to which the PW/PSN emualtes the > > > >ingress/egress service definitions. In providing this > > > >service emulation things such as the following may be > > > >mapped: > > > > > > > >1. Variable length PDU formatting and delimiting > > > >2. Error detection > > > >3. Connection multiplexing > > > >4. Loss Priority Indication > > > >5. Congestion Indication (Forward and Backward) > > > >6. PVC Status Management > > > > > > > >So in this sense Eric is correct. RFC 1490/1483 are > > > >not the same as the encapsulations used to perform > > > >network interworking, or what might otherwise be > > > >referred to as (sub)convergence. In this context the > > > >more appropriate question might be, was AAL1 or AAL5 > > > >explored as to their applicability for encapsulating > > > >services over MPLS or IP; they may not provide what is > > > >needed, and that is a perfectly acceptable answer if > > > >that is the case. > > > > > > > >Some standards differentiate between the case when two > > > >subscribers are communicating over a cloud, and when > > > >two networks are communicating over a third cloud; I > > > >will not for the sake of trying to establish some > > > >basic concepts. > > > > > > > >Now we move to service interworking, where we are > > > >trying to provide for a service to have two different > > > >interfaces at either end of a cloud. In this case, > > > >simple encapsulation does not work, the hard task (and > > > >I do understand it is not considered trivial by some > > > >developers) is to have say Frame Relay go in one side, > > > >and have ATM come out the other side. For example: > > > > > > > >CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE > > > > > > > >The IWF (interworking function) could be in a variety > > > >of places, I just put it there for grins. > > > > > > > >In this example, we now have to not only convert the > > > >Frame Relay base protocol to ATM, but if we do not > > > >convert RFC1490 running above it to RFC1483, then > > > >there will be problems at that level of protocol > > > >interaction. > > > > > > > >NLPIDs are used often in encapsulations to provide > > > >indication of encapsulated protocols. Service > > > >interworking could be done at the ingress PE, in which > > > >case the resultant PW is really in the format of the > > > >egress attachment circuit. Another option is to do it > > > >at the egress PE, which would mean translating from > > > >the 1490/FR/PW/MPLS or IP PDUs to the resultant > > > >1483/aal5/atm attachment circuit. The question then > > > >becomes should the FR PDU just be popped from the PW > > > >and examined, or should the PW indicate, by a NLPID > > > >equivalent, what is contained within the FR PDU? That > > > >would probably be an implementation decision, but > > > >those types of dicussions may uncover any weaknesses > > > >in the current methods, if they exist at all, and they > > > >may not. > > > > > > > >If the PW is discarded before the IWF function, then > > > >that is probably not a problem as long as the > > > >resultant FR PDU is sufficient to perform the mapping; > > > >and therefore I am not concerned that the PW > > > >"whatever" disappears, this is analgous to the ATM > > > >AAL5 PDU disappearing and a new one being created, if > > > >the service interworking was performed in the same way > > > > > > > >So the more I think about, the less problems I > > > >see.......... > > > > > > > >There is some thought floating around that if the PW > > > >encap was similar to or identical to whatever network > > > >is most likely to be interworked to, then that may > > > >make like easier for implementors and operators - that > > > >I leave as a discussion point, and note the horse has > > > >probably already bolted on that one, for this WG, in > > > >this time slot. > > > > > > > >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 > > >=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: Eric Rosen Subject: Re: PWE Service interworking Date: Wed, 04 Jun 2003 13:47:51 -0400 Lines: 18 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C99C@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "'Mark Seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 04 19:51:21 2003 Return-path: To: Shahram Davari In-reply-to: Your message of Wed, 04 Jun 2003 07:42:08 -0700. <4B6D09F3B826D411A67300D0B706EFDE0115C99C@nt-exch-yow.pmc-sierra.bc.ca> 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 Shahram> Regarding Service interworking I believe the simplest and Shahram> most logical model is to do service interworking with MPLS Shahram> on both IWFs. Fortunately, "service interworking with MPLS" is not possible at the current time as there is such thing (at least not in the IETF) as an "MPLS service". And hopefully things will stay that way. Shahram> The advantage is that each PE needs to support a maximum of N Shahram> service interworking functions (N is all known L2 protocols). While Shahram> your proposed model requires N square service interworking Shahram> functions to be supported in a single PE. There are certain theoretical advantages to having a sort of "generic service" to/from which all other services could be mapped. However, if FR/ATM interworking on the one hand and ARP Mediation on the other hand cover 99% of the space, there doesn't really seem to be much need for this generic service. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 11:00:39 -0700 (PDT) Lines: 46 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C99C@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 Jun 04 20:02:04 2003 Return-path: To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C99C@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, A follow-up below, Mark --- Shahram Davari wrote: > Mark, > > Regarding Service interworking I believe the > simplest and > most logical model is to do service interworking > with MPLS > on both IWFs. Assuming (PL= Payload), the following > figure shows an > example of what I think is a proper AT-MPLS-FR > service interworking: > > > CE--------PE-------P--------PE---------CE > PL PL PL PL > AAL5 X X Q.922 > ATM MPLS MPLS FR > > Both PEs do service interworking. One does ATM-MPLS > service > interworking and the other one does FR-MPLS service > interworking. MS=> From a logisitical perspective, does this approach require the common "X" payload to be (re)defined, and then does it replace existing encap definitions - my assumption is that it would. Note: not making a value judgement, just asking what the path forward would look like. > The advantage is that each PE needs to support a > maximum of N service > interworking functions (N is all known L2 > protocols). While your > proposed model requires N square service > interworking functions to be > supported in a single PE. Understood, thanks for pointing out. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 19:46:06 -0400 Lines: 250 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32AF3.779C794E" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 05 01:52:32 2003 Return-path: To: erosen@cisco.com, 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_01C32AF3.779C794E Content-Type: text/plain; charset="iso-8859-1" Eric, [clipped]... > I think this is the same as you indicate in your example: > > CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE > I think you meant something like: CE--FR--PE--FR/PW/PSN--PE-FR-IWF-ATM-CE ^^ > Is there anything more to say about it? > > In the special case where the payload is always IP > datagrams, but the > ingress and egress ACs use different data link > protocols, then "ARP > Mediation" can be used for interworking, as long as there > is no need to > provide any sort of faithful data link emulation. This > seems to be the one > case that might be of interest to the IETF. > I have no problem with IP-only interworking approach when there is no available interworking function to use (outside the pw), particularly if most of the traffic carried over a PW is IP. However, my questions probably best answered by the providers deploying pws where both attachment circuits are of different protocols are: a) Are there applications/situations where even if the payload is IP, the client requires the provider not to make any assumption on the payload (maybe situations of regulatory scenarios)? b) For the case where the provider has upgraded his l2 network to MPLS/IP and the native l2 services are replaced with PWs, can the provider guarantee/assume in all cases that the traffic is always IP, or can he assumes that on any given PW there is no case where both IP and non IP traffic are being sent (since the upgraded service initially didn't make that assumption, or maybe the provider can't tell whether it is always IP since it doesn't control customer devices)? c) Is there a situation/application even for IP only interworking/payload where items like sequencing, etc need to be supported as part of the service being interworked? Regardless what solution is provided and even in what appropriate standard body that solution needs to be pursued it will be good to have an overall view on what category and percentage the interworking scenarios fall into. Hamid. ------_=_NextPart_001_01C32AF3.779C794E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Eric,

[clipped]...


> I think this is the same as you indicate in your=20 example:
>
>     =20 CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE
>

I think you meant = something=20 like:
 
     =20 CE--FR--PE--FR/PW/PSN--PE-FR-IWF-ATM-CE
           &= nbsp;           &= nbsp;       =20 ^^

> Is there anything = more to say=20 about it?
>
> In  the special  case where  = the =20 payload is  always IP 
> datagrams, but  = the
>=20 ingress  and  egress  ACs  use  different = data =20 link 
> protocols,  then  "ARP
> Mediation" = can =20 be used  for interworking, as  long as  there
> is = no =20 need to
> provide any sort of faithful data  link = emulation. =20 This
> seems to be the one
> case that might be of interest = to the=20 IETF.
>
 
I have no=20 problem with IP-only interworking approach when
there is no=20 available interworking function to use
(outside the=20 pw), particularly if most of the traffic carried =
over a PW is=20 IP. However, my questions probably best answered=20
by the=20 providers deploying pws where both = attachment=20 circuits
are of=20 different protocols are:
 
a)=20 Are there applications/situations where
   even if the payload is = IP, the=20 client requires the=20
   provider not to make any assumption = on the=20 payload
   (maybe situations of regulatory = scenarios)?
 
b) For=20 the case where the provider has upgraded his l2 network=20
   to MPLS/IP and the = native = l2 services are=20 replaced with PWs,
  =20 can the provider guarantee/assume in all = cases that the=20 traffic
  =20 is always IP, or can he assumes that on any given PW there=20 is
  =20 no case where both IP and non IP traffic are = being sent=20 (since
  =20 the upgraded service initially didn't make that = assumption,
  =20 or maybe the provider can't tell whether it is = always
  =20 IP since it doesn't control customer devices)?
 
c)=20 Is there a situation/application even for IP only=20
   interworking/payload = where items=20 like sequencing, etc
   need to be supported as = part of the=20 service being =
   = interworked?
 
Regardless what solution is=20 provided and even in=20 what
appropriate standard body that solution = needs to be=20 pursued
it=20 will be good to have an overall view on what category=20 and
percentage = the interworking=20 scenarios fall into.
 
Hamid.
------_=_NextPart_001_01C32AF3.779C794E-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Wed, 4 Jun 2003 16:53:53 -0700 (PDT) Lines: 25 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 Thu Jun 05 01:53:44 2003 Return-path: To: Hamid Ould-Brahim 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 Hamid, --- Hamid Ould-Brahim wrote: > Eric, > > [clipped]... > > > > I think this is the same as you indicate in your > example: > > > > CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE > > > > I think you meant something like: > > CE--FR--PE--FR/PW/PSN--PE-FR-IWF-ATM-CE > ^^ As I was the originator of this, let me comment. Yes, what you have depicted is more accurate. Thanks, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE Service interworking Date: Wed, 4 Jun 2003 22:04:53 -0700 (PDT) Lines: 54 Sender: pwe3-admin@ietf.org References: <200306041747.h54Hlp51016526@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 05 07:05:40 2003 Return-path: To: erosen@cisco.com, Shahram Davari In-Reply-To: <200306041747.h54Hlp51016526@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 Eric, Comments in line, Mark --- Eric Rosen wrote: > Shahram> Regarding Service interworking I believe > the simplest and > Shahram> most logical model is to do service > interworking with MPLS > Shahram> on both IWFs. > >> [ERIC] Fortunately, "service interworking with MPLS" is not possible at the current time as there is such thing (at least not in the IETF) as an "MPLS service". << MS=> Well perhaps the term is a bad one - that should not be enough to disqualify the idea, but the point you make below is worth discussing. [ERIC] And hopefully things will stay that way. MS=> Somehow I doubt it ;-) > Shahram> The advantage is that each PE needs to > support a maximum of N > Shahram> service interworking functions (N is all > known L2 protocols). While > Shahram> your proposed model requires N > square service interworking > Shahram> functions to be supported in a single PE. > >> [ERIC] There are certain theoretical advantages to having a sort of "generic service" to/from which all other services could be mapped. However,if FR/ATM interworking on the one hand and ARP mediation on the other hand cover 99% of the space, there doesn't really seem to be much need for this generic service. << MS=> Well there is this emerging thing called Ethernet; and there was Jack's note about a requirement for ATM CES-TDM service interworking. But to your point, FR/ATM/IP cover I would say at least 90% of the cases today (not including private line TDM); so a lot can be achieved with the approach of doing IWF either side of the PW, as a practical matter today. Probably the trickier discussion is what makes sense for tomorrow, and what makes sense for people that want to move towards one integrated network from an OAM, management plane, and control plane perspective; and what volume will be achieved with these new services. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 08:53:26 +0100 Lines: 176 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Thu Jun 05 09:57:21 2003 Return-path: To: Shahram_Davari@pmc-sierra.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 Agreed Shahram.....using MPLS as a common core reduces the SIWF function from N^2/2 to N dimension. regards, Neil > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: 04 June 2003 15:42 > To: 'Mark Seery'; pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Mark, > > Regarding Service interworking I believe the simplest and > most logical model is to do service interworking with MPLS > on both IWFs. Assuming (PL= Payload), the following figure shows an > example of what I think is a proper AT-MPLS-FR service interworking: > > > CE--------PE-------P--------PE---------CE > PL PL PL PL > AAL5 X X Q.922 > ATM MPLS MPLS FR > > Both PEs do service interworking. One does ATM-MPLS service > interworking and the other one does FR-MPLS service interworking. > > The advantage is that each PE needs to support a maximum of N service > interworking functions (N is all known L2 protocols). While your > proposed model requires N square service interworking functions to be > supported in a single PE. > > Yours, > -Shahram > > > >-----Original Message----- > >From: Mark Seery [mailto:mark@mseery.com] > >Sent: Tuesday, June 03, 2003 5:01 PM > >To: pwe3@ietf.org > >Subject: Re: [PWE3] PWE Service interworking > > > > > >All, remember the constraints: a) can't quote from a > >non-IETF standard, b) can't use the word layer. Will > >do my best. > > > >Defining service interworking > >===================== > > > >The simplest explanations (IMO) for interworking are > >as follows: > > > >Network interworking - ingress and egress attachment > >circuits use the same protocols > >Service interworking - ingress and egress attachment > >circuits use different protocols > > > >Now any interworking agreement is going to specify > >exactly what protocols, so the actual definition > >necessarily becomes less generalized. Typical > >protocols that have been involved in interworking > >standards are link-layer PDUs and adaptation layers > >(FR, ATM, AAL1, AAL5) and Multiprotocol encapsulation > >standards (RFC 1483, RFC 1490). > > > >Simplistically a network interworking function has to > >map a service PDU to an encapsulation that provides > >service attributes on an underlying network such that > >the service entrities at each side of the network do > >not realize they are not operating over a native > >service network. An example of this would be two Frame > >Relay attachment circuits connected to an ATM network, > >or two Ethernet attachment circuits connected to a > >MPLS or IP network (i.e. PW) > > > >For example: > > > >CE--FR--PE--FR/PW/PSN--PE-FR-CE > > > >I don't think there has been much controversy about > >this, the only real area of controversy I recall is > >the degree to which the PW/PSN emualtes the > >ingress/egress service definitions. In providing this > >service emulation things such as the following may be > >mapped: > > > >1. Variable length PDU formatting and delimiting > >2. Error detection > >3. Connection multiplexing > >4. Loss Priority Indication > >5. Congestion Indication (Forward and Backward) > >6. PVC Status Management > > > >So in this sense Eric is correct. RFC 1490/1483 are > >not the same as the encapsulations used to perform > >network interworking, or what might otherwise be > >referred to as (sub)convergence. In this context the > >more appropriate question might be, was AAL1 or AAL5 > >explored as to their applicability for encapsulating > >services over MPLS or IP; they may not provide what is > >needed, and that is a perfectly acceptable answer if > >that is the case. > > > >Some standards differentiate between the case when two > >subscribers are communicating over a cloud, and when > >two networks are communicating over a third cloud; I > >will not for the sake of trying to establish some > >basic concepts. > > > >Now we move to service interworking, where we are > >trying to provide for a service to have two different > >interfaces at either end of a cloud. In this case, > >simple encapsulation does not work, the hard task (and > >I do understand it is not considered trivial by some > >developers) is to have say Frame Relay go in one side, > >and have ATM come out the other side. For example: > > > >CE--FR--PE--FR/PW/PSN--PE-IWF-ATM-CE > > > >The IWF (interworking function) could be in a variety > >of places, I just put it there for grins. > > > >In this example, we now have to not only convert the > >Frame Relay base protocol to ATM, but if we do not > >convert RFC1490 running above it to RFC1483, then > >there will be problems at that level of protocol > >interaction. > > > >NLPIDs are used often in encapsulations to provide > >indication of encapsulated protocols. Service > >interworking could be done at the ingress PE, in which > >case the resultant PW is really in the format of the > >egress attachment circuit. Another option is to do it > >at the egress PE, which would mean translating from > >the 1490/FR/PW/MPLS or IP PDUs to the resultant > >1483/aal5/atm attachment circuit. The question then > >becomes should the FR PDU just be popped from the PW > >and examined, or should the PW indicate, by a NLPID > >equivalent, what is contained within the FR PDU? That > >would probably be an implementation decision, but > >those types of dicussions may uncover any weaknesses > >in the current methods, if they exist at all, and they > >may not. > > > >If the PW is discarded before the IWF function, then > >that is probably not a problem as long as the > >resultant FR PDU is sufficient to perform the mapping; > >and therefore I am not concerned that the PW > >"whatever" disappears, this is analgous to the ATM > >AAL5 PDU disappearing and a new one being created, if > >the service interworking was performed in the same way > > > >So the more I think about, the less problems I > >see.......... > > > >There is some thought floating around that if the PW > >encap was similar to or identical to whatever network > >is most likely to be interworked to, then that may > >make like easier for implementors and operators - that > >I leave as a discussion point, and note the horse has > >probably already bolted on that one, for this WG, in > >this time slot. > > > >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: PWE Service interworking Date: Thu, 5 Jun 2003 09:29:45 +0100 Lines: 44 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: mark@mseery.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 05 10:31:44 2003 Return-path: To: erosen@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 Eric, > Shahram> Regarding Service interworking I believe the simplest and > Shahram> most logical model is to do service interworking with MPLS > Shahram> on both IWFs. > > Fortunately, "service interworking with MPLS" is not possible > at the current > time as there is such thing (at least not in the > IETF) as an "MPLS > service". And hopefully things will stay that way. NH=> I can understand why you might say this.....and I can certainly see its a good way to keep market control ;-) > > Shahram> The advantage is that each PE needs to support > a maximum of N > Shahram> service interworking functions (N is all known L2 > protocols). While > Shahram> your proposed model requires N square > service interworking > Shahram> functions to be supported in a single PE. > > There are certain theoretical advantages to having a > sort of "generic > service" to/from which all other services could be > mapped. NH=> It's not theoretical...and its also about trying to get away from the notion that 'technology-service'....that leads to overlaid stovepipes. If we have a common MPLS core to which we can interwork FR/ATM (with maybe ethernet access) it will significantly reduce our capex/opex. If we have to run parallel networks (which is effectively what you are advocating) then we won't see those capex/opex savings. Remember, there are many large operators out there with hugh FR/ATM network deployments who are looking to where the next generation equipment will be. All vendors show MPLS in this space. But it will have to be the right type of MPLS. I can't speak for other operators but we want to have 3 core modes - cnls, co pkt-sw and co cct-sw. They all do different jobs and they are all required in our view. What we don't want is several different technologies effectively doing the same job. So functional convergence of technologies *within* each mode makes a great deal of technical and business sense. If for whatever reason you find this rationale is unpalatable then OK, but I do think it has great merit if one can look at the issues dispassionately. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 06:38:45 -0500 Lines: 82 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6971@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 Thu Jun 05 13:39:12 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: <0536FC9B908BEC4597EE721BE6A35389025D6971@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 h55Bcm73007820 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55BctB26592 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h55BfQB26695 Status: O Neil's comments are right on the money - literally. Any convergence solution must address the service interworking issue. Now is the time fo= r manufacturers to recognize this and take appropriate design action. It w= ill not be to the manufacturers, nor carriers advantage to discover this once equipment is brought into the carrier's lab. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > neil.2.harrison@bt.com > Sent: Thursday, June 05, 2003 3:30 AM > To: erosen@cisco.com; Shahram_Davari@pmc-sierra.com > Cc: mark@mseery.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Eric, > > Shahram> Regarding Service interworking I believe the simplest and > > Shahram> most logical model is to do service interworking with MPLS > > Shahram> on both IWFs. > > > > Fortunately, "service interworking with MPLS" is not possible > > at the current > > time as there is such thing (at least not in the > > IETF) as an "MPLS > > service". And hopefully things will stay that way. > NH=3D> I can understand why you might say this.....and I can > certainly see its > a good way to keep market control ;-) > > > > Shahram> The advantage is that each PE needs to support > > a maximum of N > > Shahram> service interworking functions (N is all known L2 > > protocols). While > > Shahram> your proposed model requires N square > > service interworking > > Shahram> functions to be supported in a single PE. > > > > There are certain theoretical advantages to having a > > sort of "generic > > service" to/from which all other services could be > > mapped. > NH=3D> It's not theoretical...and its also about trying to get away fro= m the > notion that 'technology-service'....that leads to overlaid stovepipes. = If > we have a common MPLS core to which we can interwork FR/ATM (with maybe > ethernet access) it will significantly reduce our capex/opex. If > we have to > run parallel networks (which is effectively what you are > advocating) then we > won't see those capex/opex savings. Remember, there are many large > operators out there with hugh FR/ATM network deployments who are > looking to > where the next generation equipment will be. All vendors show > MPLS in this > space. But it will have to be the right type of MPLS. > > I can't speak for other operators but we want to have 3 core modes - cn= ls, > co pkt-sw and co cct-sw. They all do different jobs and they are all > required in our view. What we don't want is several different > technologies > effectively doing the same job. So functional convergence of technolog= ies > *within* each mode makes a great deal of technical and business sense. = If > for whatever reason you find this rationale is unpalatable then > OK, but I do > think it has great merit if one can look at the issues dispassionately. > > 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: PWE Service interworking Date: Thu, 5 Jun 2003 07:42:19 -0700 (PDT) Lines: 39 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6971@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 Thu Jun 05 16:45:03 2003 Return-path: To: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6971@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 Hi Neil, --- neil.2.harrison@bt.com wrote: [SNIP] >> I can't speak for other operators but we want to have 3 core modes - cnls, co pkt-sw and co cct-sw. They all do different jobs and they are all required in our view. What we don't want is several different technologies effectively doing the same job. So functional convergence of technologies *within* each mode makes a great deal of technical and business sense. << ms=> WRT this issue, I am not sure I understand the point you are making. For example, if an equipment operator was to implement the following: CE--FR--PE--FR/PW/PSN--PE-FR-IWF-ATM-CE Where the FR-IWF-ATM step was implemented in the same PE, why that would lead to: -Parallel networks -Lack of functional convergence If the problem is that MPLS is not perceived as truly CO-PKT-SW, then that of course is a problem, but orthogonal to this particular issue? What exactly about this approach does not get you where you need to be? I think expanding on your initial statement would aid our understanding greatly. Thanks, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Eric Rosen Subject: Re: PWE Service interworking Date: Thu, 05 Jun 2003 10:42:26 -0400 Lines: 14 Sender: pwe3-admin@ietf.org References: <20030605050453.6158.qmail@web13501.mail.yahoo.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: Shahram Davari , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 05 16:53:14 2003 Return-path: To: Mark Seery In-reply-to: Your message of Wed, 04 Jun 2003 22:04:53 -0700. <20030605050453.6158.qmail@web13501.mail.yahoo.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 MS=> Well there is this emerging thing called Ethernet; True, but there is no service interworking between ethernet and p2p technologies. When you want to hook up an ethernet interface to a p2p interface you usually end up having the CE encapsulate ethernet frames inside the p2p data link so that the higher layers see an ethernet. It's difficult to see what the alternative might be, since you can't just "map" a broadcast medium to a p2p medium. And ethernet has no OAM to pass along anyway; no doubt this will keep it from ever succeeding ;-) I don't know whether there's an ATM-TDM interworking issue or not, but if there is, we can be pretty sure that our TDM sub-group would never agree on what needs to be done ;-) From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: Re: PWE Service interworking Date: Thu, 5 Jun 2003 08:27:43 -0700 (PDT) Lines: 33 Sender: pwe3-admin@ietf.org References: <200306051442.h55EgQ51004320@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 05 17:34:08 2003 Return-path: To: erosen@cisco.com In-Reply-To: <200306051442.h55EgQ51004320@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 Hi Eric, --- Eric Rosen wrote: > > MS=> Well there is this emerging thing called > Ethernet; > > True, but there is no service interworking > between ethernet and p2p > technologies. Challenging to be sure...... I don't think it is the broadcast vs P2P that is the problem so much (VPLS for example), but it is really the CNLS addressing vs CO addressing (not even a VLAN tagged Ethernet frame ultimately uses a CNLS address) If the P2P technology is carrying an Ethernet frame then something can be made to work. If not, then translating a DLCI/VC to a DA/SA MAC pair would undoubtely be quite a challenge; unless there is a router on each end. > I don't know whether there's an ATM-TDM > interworking issue or not, but if > there is, we can be pretty sure that our TDM > sub-group would never agree on > what needs to be done ;-) Not touching that one ;-) Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 18:51:12 +0100 Lines: 109 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 Jun 05 19:53:09 2003 Return-path: To: 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 Mark, I have attempted to answer your question as briefly as I can.....but I am not doing full justice to it wrt to all the activities ongoing here (in BT) to address this. regards, Neil > > Hi Neil, > > --- neil.2.harrison@bt.com wrote: > [SNIP] > >> I can't speak for other operators but we want to > have 3 core modes - cnls, co pkt-sw and co cct-sw. > They all do different jobs and they are all required > in our view. What we don't want is several different > technologies effectively doing the same job. So > functional convergence of technologies *within* each > mode makes a great deal of technical and business > sense. << > > ms=> WRT this issue, I am not sure I understand the > point you are making. > > For example, if an equipment operator was to implement > the following: > > CE--FR--PE--FR/PW/PSN--PE-FR-IWF-ATM-CE > > Where the FR-IWF-ATM step was implemented in the same > PE, why that would lead to: > > -Parallel networks > -Lack of functional convergence > > If the problem is that MPLS is not perceived as truly > CO-PKT-SW, then that of course is a problem, but > orthogonal to this particular issue? > > What exactly about this approach does not get you > where you need to be? > > I think expanding on your initial statement would aid > our understanding greatly. NH=> You can indeed do what you are suggesting Mark if the only concern is FR/ATM Service I/W, ie retain network I/W wrt to MPLS for *one* of these technologies (you show the case of FR above) and with a PW adaptation function, and you are not overly concerned with the 'quality' of the resulting solution. However, one can do far better than this in our opinion. But remember, I am discussing what follows in the context of a large operator seeking a common co pkt-sw core to which I feel *comfortable* in migrating my current FR/ATM legacy networks to (ie I am looking for something which we would deem as carrier-strength for this case), and also with one eye on future service opportunities. Firstly we have to recognise why the PW functions are present. My 1st observation is that I want all 3 modes of cnls, co pkt-sw and co cct-sw (I mean SDH/OTNs by this). They serve different roles, they have quite different behaviours and I need them all. So I am looking for functional convergence of technologies that belong to the *same* mode. Based on this observation, I don't need PWs to try and make IP and MPLS cases look alike.....if IP and MPLS were indeed the same thing why would I need MPLS at all? My 2nd observation is wrt Seq. Nos. These are there to address pkt re-ordering....but I don't want to buy MPLS kit from a supplier who re-orders pkts as a 'feature'. My 3rd observation is that I am not overly concerned with the trivial BW squeezing of the clients (esp when I see other technologies that create BW wasting) and I have no intention of sending pkts over ethernet in the network core and so have no need to pad them out. So exactly what real value is the PW stuff providing for us? Very little is our view. But it will provide us with some problems. Adding the PW stuff creates a new problem of mapping defect indications across the PW 'layer' that lies between the real client technology and the MPLS server. Moreover, if there are functions in the PW layer (like Seq. No.s) then I need to define defects for handling these, ie entry/exit criteria and consequent actions. Currently this is left open-ended....as is the case for defects in general for MPLS, at least in IETF. This is simply not good enough for us. We are looking for defect detection/handling like that described in Y.1711.....which also specifies how to measure availability. And the answer is not to introduce even more functionality in the PW layer like a MPLS PID field (a fix for the ECMP hack in mp2p) and PW OAM. So all I am getting is a load of stuff to manage that really has no reason to be there other than to fix problems created elsewhere. So an alternative/simpler answer *if* I can get the right sort of MPLS from suppliers is to directly interwork with MPLS. It also allows me the option to offer an MPLS-based service interface one day (if I so choose) and it also addresses the point Shahram made about reducing the interworking dimension by requiring legacy protocols to interwork only with MPLS, ie MPLS is the common core broker technology. In summary, its simpler and I can get a carrier-strength solution this way. Remember however, as I noted above, I am looking at this problem from a technical/commercial perspective as a large operator seeking to reduce capex/opex by having a sensible migratory solution to a common co pkt-sw core. This is probably not something IETF may want to work on...and I do understand/accept that. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 11:16:16 -0700 (PDT) Lines: 20 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D6984@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 Thu Jun 05 20:19:49 2003 Return-path: To: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D6984@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 Thanks Neil, So to summarize, what you have essentially stated is that any interworking scenario that includes PW is not going to meet your needs? The other problems indicated have been the N2 interworking problem which I assume is mostly an equipment vendor problem. Curious if and how this creates a problem for operators? Are there any other issues raised by this approach (excluding for the moment that PW, MP2P, etc.) does not meet your needs? -Do service layers need to be able to do segment OAM in the core (i.e. network interworking might create transparency of the core) Thanks, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 13:37:59 -0500 Lines: 45 Sender: pwe3-admin@ietf.org References: <20030605181616.4932.qmail@web13501.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 Thu Jun 05 20:39:23 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: <20030605181616.4932.qmail@web13501.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by uswgco34.uswest.com id h55Ic2ZU015990 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55Ic8B30579 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h55IfNB30728 Status: O Segment and End-to-End OAM are utilized on an every day basis and a strategic part of the fault isolation process. More specifically, the ability to generate an End-to-End at an intermediate node is essential. This allows the client (or client application) to initiate the request to= a single element management system. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Mark > Seery > Sent: Thursday, June 05, 2003 1:16 PM > To: neil.2.harrison@bt.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Thanks Neil, > > So to summarize, what you have essentially stated is > that any interworking scenario that includes PW is not > going to meet your needs? > > The other problems indicated have been the N2 > interworking problem which I assume is mostly an > equipment vendor problem. Curious if and how this > creates a problem for operators? > > Are there any other issues raised by this approach > (excluding for the moment that PW, MP2P, etc.) does > not meet your needs? > -Do service layers need to be able to do segment OAM > in the core (i.e. network interworking might create > transparency of the core) > > Thanks, > Mark > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:45 2006 From: "Vishal Sharma" Subject: "OAM in MPLS-based Networks": IEEE Comm. Mag. Sp. Issue Call for Papers Date: Thu, 5 Jun 2003 12:24:03 -0700 Lines: 143 Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Thu Jun 05 21:23:22 2003 Return-path: To: , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-SMTP-HELO: smtp101.mail.sc5.yahoo.com X-SMTP-MAIL-FROM: v.sharma@ieee.org X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: smtp101.mail.sc5.yahoo.com [216.136.174.139] Status: O Folks, The IEEE Communications Magazine has just approved the publication of a Feature Topic issue on "OAM-in MPLS-based Networks." The CFP is attached below. We invite those working in this area to consider sending in their contributions. If you intend to submit a paper for this special issue, please drop one of the Guest Editors a note, so that we can plan the issue. We look forward to your participation! Thanks, -Vishal ************************************* Vishal Sharma Metanoia, Inc. http://www.metanoia-inc.com ************************************* ==================================================================== CALL FOR PAPERS IEEE Communications Magazine Feature Topic on "OAM in MPLS-Based Networks" ********************************************** As carriers and service providers converge multiple services and associated networks on to an MPLS-based infrastructure, OAM functionality becomes pivotal for enabling them to provide service level agreement (SLA) guarantees, service assurance, quality of service (QoS) assurance and overall interworking service management. The advent of new applications of MPLS such as Layer 2 Virtual Private LAN Services (VPLS) and Layer 3 Virtual Private Networks (L3VPNs) also means the emergence of added OAM requirements from operators deploying those networks. As a result, providers today require more efficient means of monitoring network health, performance, and robustness, and of quickly identifying and resolving performance problems. This is leading to the emergence of improved or novel tools and techniques, whose goal is to improve security and billing/accounting, aid in verifying QoS commitments, and reduce operating costs. Standards organizations such as the IETF and the ITU have in the recent past done significant work in this area, and this subject is also being investigated by the IEEE and the Metro Ethernet Forum. This feature topic issue of the IEEE Communications Magazine has a dual focus: to highlight operator requirements and deployment experiences with OAM in MPLS-based networks, and to present a survey of the current engineering and research developments in this area. Thus, focused tutorial and survey contributions as well as research papers are solicited on (but not limited to) the following: * Operational consequences of inadequate OAM capabilities * Service provider requirements for efficient OAM - current operational needs and future demands * Deployment experiences with OAM over MPLS-based networks * Overview or comparative analysis of different approaches/philosophies for OAM * Standards activities o Emerging architectures o New mechanisms for OAM in development (e.g. IETF LSP ping, ITU-T Y.1711, virtual circuit connection verification (VCCV)) * Platform support for OAM * OAM impact on edge services (such as metro Ethernet) using MPLS transport * Interoperability issues, interworking with other technologies (e.g. ATM) * Review of current research in the area - E.g. setting parameters for connectivity verification and their impact on LSP recovery, trade-offs between bandwidth usage by OAM traffic and efficiency of failure/anomaly detection, and results from testbed deployments or simulations On-line CFP with submission instructions can be found at: http://www.comsoc.org/pubs/commag/cfpcommag1004.htm Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three simple equations could be allowed, provided the consent of the Guest Editor; more than three equations require permission from the Editor-in-Chief). Articles should have no more than 4,500 words, no more than 6 tables/figures, and no more than 15 references. Guidelines for prospective authors can be found on-line at: http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please submit no later than November 30, 2003. Accepted papers will also be included in Communications Interactive (CI), the online version of Communications Magazine. Schedule: Manuscript Due: November 30, 2003 Acceptance Notification: February 28, 2004 Final Manuscript Due: April 15, 2004 Publication Date: October 2004 Guest Editors: Monique J. Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Tom Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824, USA. Email: tnadeau@cisco.com Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA. Email: v.sharma@ieee.org About the IEEE Communications Magazine: The IEEE Comm. Mag. is the official technical publication of conferences such as Supercomm, and has the unique distinction of being the most widely read IEEE journal, with its over 50,000 paid subscribers representing key communications engineers and technical managers in our industry. More information on the IEEE Comm. Mag., may be found here: www.comsoc.org/adv/pp/Adpp2003revisedweb.ppt From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 12:47:39 -0700 (PDT) Lines: 43 Sender: pwe3-admin@ietf.org References: <014301c32b91$96ea36d0$854c1cac@dyn.interprise.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 05 21:48:54 2003 Return-path: To: Jack Pugaczewski In-Reply-To: <014301c32b91$96ea36d0$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 Pugaczewski wrote: > Segment and End-to-End OAM are utilized on an every > day basis and a > strategic part of the fault isolation process. More > specifically, the > ability to generate an End-to-End at an intermediate > node is essential. > This allows the client (or client application) to > initiate the request to a > single element management system. > > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY Thanks Jack, 1) Is it important that every layer be able to do a segment OAM on every segment, or just the segments that logically belong to that layer (i.e. as delineated by access points of that layer)? For example, in the following network: 1 2 3 4 5 6 7 CE----ATM_SW-----PE----P----PE----ATM_SW----CE >From the perspective of the ATM layer (assume VCC, no VPC), Is a segment between 2 and 6 or are 2-3, 3-4, 4-5, and 5-6 also considered segments (from the perspective of your requirements as an operator). 2) When an end-to-end OAM is initiated from an intermediate node, what is considered end-to-end? For example, in the following network: 1 2 3 4 5 6 7 CE----FR_SW-----PE----P----PE----ATM_SW----CE If an end-to-end OAM is initiated at "6" towards the direction of "1", where would you expect the OAM to terminate/take action? Thanks, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 12:55:46 -0700 Lines: 65 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 05 21:57:36 2003 Return-path: To: "'Mark Seery'" , Jack Pugaczewski 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, 1) Each layer should have segment OAM mechanism that applies only to that layer. 2) End-to-end OAM at each layer corresponds to the terminating points of that layer. -Shahram >-----Original Message----- >From: Mark Seery [mailto:mark@mseery.com] >Sent: Thursday, June 05, 2003 3:48 PM >To: Jack Pugaczewski >Cc: pwe3@ietf.org >Subject: RE: [PWE3] PWE Service interworking > > >--- Jack Pugaczewski wrote: >> Segment and End-to-End OAM are utilized on an every >> day basis and a >> strategic part of the fault isolation process. More >> specifically, the >> ability to generate an End-to-End at an intermediate >> node is essential. >> This allows the client (or client application) to >> initiate the request to a >> single element management system. >> >> PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > >Thanks Jack, > >1) Is it important that every layer be able to do a >segment OAM on every segment, or just the segments >that logically belong to that layer (i.e. as >delineated by access points of that layer)? For >example, in the following network: > > 1 2 3 4 5 6 7 >CE----ATM_SW-----PE----P----PE----ATM_SW----CE > >From the perspective of the ATM layer (assume VCC, no >VPC), Is a segment between 2 and 6 or are 2-3, 3-4, >4-5, and 5-6 also considered segments (from the >perspective of your requirements as an operator). > >2) When an end-to-end OAM is initiated from an >intermediate node, what is considered end-to-end? For >example, in the following network: > > > 1 2 3 4 5 6 7 >CE----FR_SW-----PE----P----PE----ATM_SW----CE > >If an end-to-end OAM is initiated at "6" towards the >direction of "1", where would you expect the OAM to >terminate/take action? > >Thanks, >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: PWE Service interworking Date: Thu, 5 Jun 2003 13:18:58 -0700 (PDT) Lines: 20 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C9B8@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 Thu Jun 05 22:21:32 2003 Return-path: To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115C9B8@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, --- Shahram Davari wrote: > Mark, > > 1) Each layer should have segment OAM mechanism that > applies only to that layer. What does that mean in an SIWF scenario. Does a layer terminate when it hits a SIWF? If so, then seems like a network interworking approach provides a better end-to-end OAM view. If not, then does that mean a subscriber gets an OAM view of the internals of a network in the X/MPLS case be suggested as an alternative? Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Jack Pugaczewski" Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 15:27:00 -0500 Lines: 90 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C9B8@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 Thu Jun 05 22:27:50 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: <4B6D09F3B826D411A67300D0B706EFDE0115C9B8@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 uswgco34.uswest.com id h55KR1ZU004756 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55KR5B06543 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h55KUBB06680 Status: O Agreed. However, for OAM fault management interworking is required. For example, a Frame Relay PVC being marked as inactive should map to an F5 V= CC ATM OAM AIS condition. In the case of OAM for loopback testing the interworking entity in conjunction with the element management system is responsible for the relationship between layers. Therefore, it is possib= le to initiate Layer n OAM in one direction and Layer n+1 in the other direction. PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY =A0 > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, June 05, 2003 2:56 PM > To: 'Mark Seery'; Jack Pugaczewski > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Mark, > > 1) Each layer should have segment OAM mechanism that applies only > to that layer. > 2) End-to-end OAM at each layer corresponds to the terminating > points of that layer. > > -Shahram > > >-----Original Message----- > >From: Mark Seery [mailto:mark@mseery.com] > >Sent: Thursday, June 05, 2003 3:48 PM > >To: Jack Pugaczewski > >Cc: pwe3@ietf.org > >Subject: RE: [PWE3] PWE Service interworking > > > > > >--- Jack Pugaczewski wrote: > >> Segment and End-to-End OAM are utilized on an every > >> day basis and a > >> strategic part of the fault isolation process. More > >> specifically, the > >> ability to generate an End-to-End at an intermediate > >> node is essential. > >> This allows the client (or client application) to > >> initiate the request to a > >> single element management system. > >> > >> PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > > > >Thanks Jack, > > > >1) Is it important that every layer be able to do a > >segment OAM on every segment, or just the segments > >that logically belong to that layer (i.e. as > >delineated by access points of that layer)? For > >example, in the following network: > > > > 1 2 3 4 5 6 7 > >CE----ATM_SW-----PE----P----PE----ATM_SW----CE > > > >From the perspective of the ATM layer (assume VCC, no > >VPC), Is a segment between 2 and 6 or are 2-3, 3-4, > >4-5, and 5-6 also considered segments (from the > >perspective of your requirements as an operator). > > > >2) When an end-to-end OAM is initiated from an > >intermediate node, what is considered end-to-end? For > >example, in the following network: > > > > > > 1 2 3 4 5 6 7 > >CE----FR_SW-----PE----P----PE----ATM_SW----CE > > > >If an end-to-end OAM is initiated at "6" towards the > >direction of "1", where would you expect the OAM to > >terminate/take action? > > > >Thanks, > >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: "David Allan" Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 16:33:50 -0400 Lines: 141 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32BA1.C58539BC" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 05 22:39:25 2003 Return-path: To: "'Mark Seery'" , 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 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_01C32BA1.C58539BC Content-Type: text/plain; charset="iso-8859-1" If you're concatenating technologies together for SWIF, then yes the layers terminate. Its also a pain to interwork OAM protocols as the semantics may not match. The 17iw stuff assume we're interworking states of separate entities to get an overall view. NIWF does have a better e2e story but as a pure overlay, you're just keeping the old game alive. Deploying old edge and new core. Didn't quite get your third comment? cheers Dave > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: Thursday, June 05, 2003 4:19 PM > To: Shahram Davari > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Shahram, > > --- Shahram Davari > wrote: > > Mark, > > > > 1) Each layer should have segment OAM mechanism that > > applies only to that layer. > > What does that mean in an SIWF scenario. Does a layer > terminate when it hits a SIWF? > > If so, then seems like a network interworking approach > provides a better end-to-end OAM view. > > If not, then does that mean a subscriber gets an OAM > view of the internals of a network in the X/MPLS case > be suggested as an alternative? > > Mark > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C32BA1.C58539BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE Service interworking

If you're concatenating technologies together for = SWIF, then yes the layers terminate. Its also a pain to interwork OAM = protocols as the semantics may not match. The 17iw stuff assume we're = interworking states of separate entities to get an overall view. =

NIWF does have a better e2e story but as a pure = overlay, you're just keeping the old game alive. Deploying old edge and = new core.

Didn't quite get your third comment?

cheers
Dave

> -----Original Message-----
> From: Mark Seery [mailto:mark@mseery.com]
> Sent: Thursday, June 05, 2003 4:19 PM
> To: Shahram Davari
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PWE Service interworking =
>
>
> Shahram,
>
> --- Shahram Davari = <Shahram_Davari@pmc-sierra.com>
> wrote:
> > Mark,
> >
> > 1) Each layer should have segment OAM = mechanism that
> > applies only to that layer.
>
> What does that mean in an SIWF scenario. Does a = layer
> terminate when it hits a SIWF?
>
> If so, then seems like a network interworking = approach
> provides a better end-to-end OAM view.
>
> If not, then does that mean a subscriber gets = an OAM
> view of the internals of a network in the = X/MPLS case
> be suggested as an alternative?
>
> Mark
>
>
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C32BA1.C58539BC-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: PWE Service interworking Date: Thu, 5 Jun 2003 13:40:01 -0700 Lines: 28 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 05 22:42:08 2003 Return-path: To: "'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 >> 1) Each layer should have segment OAM mechanism that >> applies only to that layer. > >What does that mean in an SIWF scenario. Does a layer >terminate when it hits a SIWF? Yes. > >If so, then seems like a network interworking approach >provides a better end-to-end OAM view. Yes, but these are different ball games. You need service interworking if Attached circuits are different. > >If not, then does that mean a subscriber gets an OAM >view of the internals of a network in the X/MPLS case >be suggested as an alternative? No. The basic idea is to only map defect states between peer layers. -Shahram > >Mark > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: David Sinicrope Subject: RE: PWE Service interworking Date: Wed, 04 Jun 2003 13:06:17 -0400 Lines: 93 Sender: pwe3-admin@ietf.org References: <20030604161652.46864.qmail@web13502.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9309997==.ALT" Cc: pwe3@ietf.org, "Rao Cherukuri" , "Andrew G. Malis" X-From: pwe3-admin@ietf.org Thu Jun 05 23:14:21 2003 Return-path: X-Sender: dsinicro@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Mark Seery In-Reply-To: <20030604161652.46864.qmail@web13502.mail.yahoo.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 --=====================_9309997==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Mark, The MPLS/FR Alliance (a.k.a. MPLS Forum/FR Forum) is currently working on FR/ATM/Ethernet Service interworking. The current work item scope is to address only AAL5 in ATM, similar to FRF.8. However, consideration of TDM and AAL1 service interworking has certainly not been ruled out. At this point the working group is debating exactly the issues you and Shahram have described previously. (i.e., N interworking units or N squared, etc.) Regards, David At 12:16 PM 6/4/2003, you wrote: >Jack, > >--- Mark Seery wrote: >[SNIP] > > If the requirement is to interwork with PW, then I > > suspect it would probably land in the IETF's court > > so > > to speak. > >Though I have been informed offline that MPLS Forum is >already doing work in the area of PW, with the >inference that the IETF tends not to pursue >interworking projects. > >So perhaps pursuing this discussion further is not >fruitful, lest the thread becomes an annoyance. > >Mark >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 ============================================================ David Sinicrope +1-919-472-9967 David.Sinicrope@Ericsson.com Ericsson IP Infrastructure Fax:+1-919-472-9999 --=====================_9309997==.ALT Content-Type: text/html; charset="us-ascii" Mark,

The MPLS/FR Alliance (a.k.a. MPLS Forum/FR Forum) is currently working on FR/ATM/Ethernet Service interworking.
The current work item scope is to address only AAL5 in ATM, similar to FRF.8.  However, consideration of TDM and AAL1 service interworking has certainly not been ruled out.

At this point the working group is debating exactly the issues you and Shahram have described previously.  (i.e., N interworking units or N squared, etc.)

Regards,
David

At 12:16 PM 6/4/2003, you wrote:
Jack,

--- Mark Seery <mark@mseery.com> wrote:
[SNIP]
> If the requirement is to interwork with PW, then I
> suspect it would probably land in the IETF's court
> so
> to speak.

Though I have been informed offline that MPLS Forum is
already doing work in the area of PW, with the
inference that the IETF tends not to pursue
interworking projects.

So perhaps pursuing this discussion further is not
fruitful, lest the thread becomes an annoyance.

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



============================================================
David Sinicrope +1-919-472-9967 David.Sinicrope@Ericsson.com            
Ericsson IP Infrastructure               Fax:+1-919-472-9999 --=====================_9309997==.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: PWE Service interworking Date: Fri, 6 Jun 2003 06:31:46 -0700 Lines: 107 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 Jun 06 15:36:30 2003 Return-path: To: "'Lin, Zhi-Wei'" , "'Mark Seery'" , Jack Pugaczewski 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 Correct. -Shahram >-----Original Message----- >From: Lin, Zhi-Wei [mailto:Zhiwlin@NYCT.com] >Sent: Friday, June 06, 2003 8:52 AM >To: Shahram Davari; 'Mark Seery'; Jack Pugaczewski >Cc: pwe3@ietf.org >Subject: RE: [PWE3] PWE Service interworking > > >Hi all, > >Sorry to interrupt your very informative discussions, but I >have a question. >In the case of the MPLS (which is our topic?) my understanding >is that OAMs >are always end-to-end? "Segment" OAMs similar to ATM can be >created for MPLS >simply by stacking a new MPLS header? > >Thanks for any clarification >Zhi > > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: Thursday, June 05, 2003 3:56 PM >> To: 'Mark Seery'; Jack Pugaczewski >> Cc: pwe3@ietf.org >> Subject: RE: [PWE3] PWE Service interworking >> >> >> Mark, >> >> 1) Each layer should have segment OAM mechanism that applies >> only to that layer. >> 2) End-to-end OAM at each layer corresponds to the >> terminating points of that layer. >> >> -Shahram >> >> >-----Original Message----- >> >From: Mark Seery [mailto:mark@mseery.com] >> >Sent: Thursday, June 05, 2003 3:48 PM >> >To: Jack Pugaczewski >> >Cc: pwe3@ietf.org >> >Subject: RE: [PWE3] PWE Service interworking >> > >> > >> >--- Jack Pugaczewski wrote: >> >> Segment and End-to-End OAM are utilized on an every >> >> day basis and a >> >> strategic part of the fault isolation process. More >> >> specifically, the >> >> ability to generate an End-to-End at an intermediate >> >> node is essential. >> >> This allows the client (or client application) to >> >> initiate the request to a >> >> single element management system. >> >> >> >> PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY >> > >> >Thanks Jack, >> > >> >1) Is it important that every layer be able to do a >> >segment OAM on every segment, or just the segments >> >that logically belong to that layer (i.e. as >> >delineated by access points of that layer)? For >> >example, in the following network: >> > >> > 1 2 3 4 5 6 7 >> >CE----ATM_SW-----PE----P----PE----ATM_SW----CE >> > >> >From the perspective of the ATM layer (assume VCC, no >> >VPC), Is a segment between 2 and 6 or are 2-3, 3-4, >> >4-5, and 5-6 also considered segments (from the >> >perspective of your requirements as an operator). >> > >> >2) When an end-to-end OAM is initiated from an >> >intermediate node, what is considered end-to-end? For >> >example, in the following network: >> > >> > >> > 1 2 3 4 5 6 7 >> >CE----FR_SW-----PE----P----PE----ATM_SW----CE >> > >> >If an end-to-end OAM is initiated at "6" towards the >> >direction of "1", where would you expect the OAM to >> >terminate/take action? >> > >> >Thanks, >> >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: "Lin, Zhi-Wei" Subject: RE: PWE Service interworking Date: Fri, 6 Jun 2003 08:52:00 -0400 Lines: 91 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 Jun 06 15:44:55 2003 Return-path: To: "'Shahram Davari'" , "'Mark Seery'" , Jack Pugaczewski X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi all, Sorry to interrupt your very informative discussions, but I have a question. In the case of the MPLS (which is our topic?) my understanding is that OAMs are always end-to-end? "Segment" OAMs similar to ATM can be created for MPLS simply by stacking a new MPLS header? Thanks for any clarification Zhi > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, June 05, 2003 3:56 PM > To: 'Mark Seery'; Jack Pugaczewski > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Mark, > > 1) Each layer should have segment OAM mechanism that applies > only to that layer. > 2) End-to-end OAM at each layer corresponds to the > terminating points of that layer. > > -Shahram > > >-----Original Message----- > >From: Mark Seery [mailto:mark@mseery.com] > >Sent: Thursday, June 05, 2003 3:48 PM > >To: Jack Pugaczewski > >Cc: pwe3@ietf.org > >Subject: RE: [PWE3] PWE Service interworking > > > > > >--- Jack Pugaczewski wrote: > >> Segment and End-to-End OAM are utilized on an every > >> day basis and a > >> strategic part of the fault isolation process. More > >> specifically, the > >> ability to generate an End-to-End at an intermediate > >> node is essential. > >> This allows the client (or client application) to > >> initiate the request to a > >> single element management system. > >> > >> PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > > > >Thanks Jack, > > > >1) Is it important that every layer be able to do a > >segment OAM on every segment, or just the segments > >that logically belong to that layer (i.e. as > >delineated by access points of that layer)? For > >example, in the following network: > > > > 1 2 3 4 5 6 7 > >CE----ATM_SW-----PE----P----PE----ATM_SW----CE > > > >From the perspective of the ATM layer (assume VCC, no > >VPC), Is a segment between 2 and 6 or are 2-3, 3-4, > >4-5, and 5-6 also considered segments (from the > >perspective of your requirements as an operator). > > > >2) When an end-to-end OAM is initiated from an > >intermediate node, what is considered end-to-end? For > >example, in the following network: > > > > > > 1 2 3 4 5 6 7 > >CE----FR_SW-----PE----P----PE----ATM_SW----CE > > > >If an end-to-end OAM is initiated at "6" towards the > >direction of "1", where would you expect the OAM to > >terminate/take action? > > > >Thanks, > >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: Mustapha Aissaoui Subject: Re: PWE Service interworking Date: Fri, 06 Jun 2003 09:45:24 -0400 Organization: Alcatel Networks Corporaton Lines: 54 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, Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 06 15:49:58 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Hamid Ould-Brahim Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hamid, see below. Mustapha. ----------- > Hamid Ould-Brahim wrote: [snipped] > > In the special case where the payload is always IP > > datagrams, but the > > ingress and egress ACs use different data link > > protocols, then "ARP > > Mediation" can be used for interworking, as long as there > > is no need to > > provide any sort of faithful data link emulation. This > > seems to be the one > > case that might be of interest to the IETF. > > > > I have no problem with IP-only interworking approach when > there is no available interworking function to use > (outside the pw), particularly if most of the traffic carried > over a PW is IP. However, my questions probably best answered > by the providers deploying pws where both attachment circuits > are of different protocols are: > > a) Are there applications/situations where > even if the payload is IP, the client requires the > provider not to make any assumption on the payload > (maybe situations of regulatory scenarios)? > > b) For the case where the provider has upgraded his l2 network > to MPLS/IP and the native l2 services are replaced with PWs, > can the provider guarantee/assume in all cases that the traffic > is always IP, or can he assumes that on any given PW there is > no case where both IP and non IP traffic are being sent (since > the upgraded service initially didn't make that assumption, > or maybe the provider can't tell whether it is always > IP since it doesn't control customer devices)? This is the case that requires the most attention. One of my customer's customers runs IPX and IP over the same FR connection. Also, some ISPs buy leased line service from a SP to connect their POPs. Today, they use FR and ATM. That one connection can carry IP and CLNP (for IS-IS). Although IP might be the dominant protocol in volume, many of the existing L2 VPN services have a small amount of other protocols. That is why if one terminates each L2 locally at a PE in service interworking between different link layers (e.g., FR-MPLS-Ethernet), then there is a need to identify multiple protocols in the same PW or LSP. Mustapha. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: PWE Service interworking Date: Fri, 6 Jun 2003 07:18:44 -0700 Lines: 37 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Mark Seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 06 16:19:59 2003 Return-path: To: "'erosen@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 > >Shahram> Regarding Service interworking I believe the simplest and >Shahram> most logical model is to do service interworking with MPLS >Shahram> on both IWFs. > >Fortunately, "service interworking with MPLS" is not possible >at the current >time as there is such thing (at least not in the IETF) > as an "MPLS >service". And hopefully things will stay that way. Service is a term to indicate the service that a layer provides to its upper layers. And MPLS provides connectivity service to its upper layers. > >Shahram> The advantage is that each PE needs to support a >maximum of N >Shahram> service interworking functions (N is all known L2 >protocols). While >Shahram> your proposed model requires N square service > interworking >Shahram> functions to be supported in a single PE. > >There are certain theoretical advantages to having a >sort of "generic >service" to/from which all other services could be mapped. > However, if >FR/ATM interworking on the one hand and ARP Mediation on >the other hand >cover 99% of the space, there doesn't really seem to be much >need for this >generic service. If no other Access technology is used or get invented. -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: PWE Service interworking Date: Fri, 6 Jun 2003 07:33:02 -0700 Lines: 68 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 06 16:37:30 2003 Return-path: To: "'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 >Question for you though, is it interworking to MPLS >that is required, or interworking to PW that is >required. Interworking with MPLS is required, but MPLS itself must have some sort of adaptation layer, which could be similar to CW in the PW. > >I would also not that at one of the IWFs >RFC1483/RFC1490 interworking should be an option, what >would you suggest in that regard? If the core is MPLS, then I don't see the need. > >Also I assume you don't ever see MPLS as being as >service interface from your response? No, it might be. > >And do you see this model working also for Ethernet to >ATM/FR interworking? I don't know. -Shahram > >Thanks, >Mark > >--- Shahram Davari >wrote: >> Mark, >> >> Regarding Service interworking I believe the >> simplest and >> most logical model is to do service interworking >> with MPLS >> on both IWFs. Assuming (PL= Payload), the following >> figure shows an >> example of what I think is a proper AT-MPLS-FR >> service interworking: >> >> >> CE--------PE-------P--------PE---------CE >> PL PL PL PL >> AAL5 X X Q.922 >> ATM MPLS MPLS FR >> >> Both PEs do service interworking. One does ATM-MPLS >> service >> interworking and the other one does FR-MPLS service >> interworking. >> >> The advantage is that each PE needs to support a >> maximum of N service >> interworking functions (N is all known L2 >> protocols). While your >> proposed model requires N square service >> interworking functions to be >> supported in a single PE. >> >> Yours, >> -Shahram > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: Re: PWE OAM Resolution / MPLS PID Date: Fri, 6 Jun 2003 13:39:30 -0400 Lines: 162 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32C52.95093598" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 06 19:45:28 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 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_01C32C52.95093598 Content-Type: text/plain; charset="iso-8859-1" I was looking forward to the answer to this one. Dave > -----Original Message----- > From: Mark Seery [mailto:m_seery@yahoo.com] > Sent: Tuesday, June 03, 2003 12:16 PM > To: tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: [PWE3] Re: PWE OAM Resolution / MPLS PID > > > > > 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 don't think that we need to define > more than one mechanism for the reasons I have > explained my my prior posting. My customers certainly > > don't want more than one mechanism. Also, before any > conclusion is drawn, I suggest asking the WG for consensus on > such a decision. > > --Tom > > MS=> So now we get in to the old what is a major > problem. Dave has asserted that Y.1711 requires > meaningful less processing than PW VCCV. This is > considered important in the mode where OAM is being > run x/sec on every LSP in order to identify defects > and suppress alarm storms. > > Tom, Can you please comment on how you see the > processing difference and whether you think it > would/would not make a difference if running OAM in > this way. > > More generally, do you assert that PW VCCV has > equivalent functionality to Y.1711 including the > generation of FDI etc. > > Thanks, > Mark > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C32C52.95093598 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Re: PWE OAM Resolution / MPLS PID

I was looking forward to the answer to this = one.

Dave

> -----Original Message-----
> From: Mark Seery [mailto:m_seery@yahoo.com]
> Sent: Tuesday, June 03, 2003 12:16 PM
> To: tnadeau@cisco.com
> Cc: pwe3@ietf.org
> Subject: [PWE3] Re: PWE OAM Resolution / MPLS = PID
>
>
>
> > 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 don't think that we need to define
> more than one mechanism for the reasons I have =
> explained my my prior posting.  My = customers certainly
>
> don't want more than one mechanism.  Also, = before any
> conclusion is drawn, I suggest asking the WG = for consensus on
> such a decision.
>
>       --Tom
>
> MS=3D> So now we get in to the old what is a = major
> problem. Dave has asserted that Y.1711 = requires
> meaningful less processing than PW VCCV. This = is
> considered important in the mode where OAM is = being
> run x/sec on every LSP in order to identify = defects
> and suppress alarm storms.
>
> Tom, Can you please comment on how you see = the
> processing difference and whether you think = it
> would/would not make a difference if running = OAM in
> this way.
>
> More generally, do you assert that PW VCCV = has
> equivalent functionality to Y.1711 including = the
> generation of FDI etc.
>
> Thanks,
> Mark
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C32C52.95093598-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: PWE Service interworking Date: Sat, 7 Jun 2003 08:32:13 -0400 Organization: Cisco Systems Lines: 103 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 Sat Jun 07 14:36:12 2003 Return-path: To: "'Lin, Zhi-Wei'" 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 I think you need to clarify what "end to end" means. In the way of PWE/MPLS I believe it means PE-PE imposition/disposition points. --Tom > Sorry to interrupt your very informative discussions, but I > have a question. In the case of the MPLS (which is our > topic?) my understanding is that OAMs are always end-to-end? > "Segment" OAMs similar to ATM can be created for MPLS simply > by stacking a new MPLS header? > > Thanks for any clarification > Zhi > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, June 05, 2003 3:56 PM > > To: 'Mark Seery'; Jack Pugaczewski > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] PWE Service interworking > > > > > > Mark, > > > > 1) Each layer should have segment OAM mechanism that applies > > only to that layer. > > 2) End-to-end OAM at each layer corresponds to the > > terminating points of that layer. > > > > -Shahram > > > > >-----Original Message----- > > >From: Mark Seery [mailto:mark@mseery.com] > > >Sent: Thursday, June 05, 2003 3:48 PM > > >To: Jack Pugaczewski > > >Cc: pwe3@ietf.org > > >Subject: RE: [PWE3] PWE Service interworking > > > > > > > > >--- Jack Pugaczewski wrote: > > >> Segment and End-to-End OAM are utilized on an every > > >> day basis and a > > >> strategic part of the fault isolation process. More > specifically, > > >> the ability to generate an End-to-End at an intermediate > > >> node is essential. > > >> This allows the client (or client application) to > > >> initiate the request to a > > >> single element management system. > > >> > > >> PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > > > > > >Thanks Jack, > > > > > >1) Is it important that every layer be able to do a > > >segment OAM on every segment, or just the segments > > >that logically belong to that layer (i.e. as > > >delineated by access points of that layer)? For > > >example, in the following network: > > > > > > 1 2 3 4 5 6 7 > > >CE----ATM_SW-----PE----P----PE----ATM_SW----CE > > > > > >From the perspective of the ATM layer (assume VCC, no > > >VPC), Is a segment between 2 and 6 or are 2-3, 3-4, > > >4-5, and 5-6 also considered segments (from the > > >perspective of your requirements as an operator). > > > > > >2) When an end-to-end OAM is initiated from an > > >intermediate node, what is considered end-to-end? For > example, in the > > >following network: > > > > > > > > > 1 2 3 4 5 6 7 > > >CE----FR_SW-----PE----P----PE----ATM_SW----CE > > > > > >If an end-to-end OAM is initiated at "6" towards the direction of > > >"1", where would you expect the OAM to terminate/take action? > > > > > >Thanks, > > >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 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: PWE Service interworking Date: Sat, 7 Jun 2003 23:39:03 +0100 Lines: 128 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 Jun 08 00:41:32 2003 Return-path: To: tnadeau@cisco.com, Zhiwlin@nyct.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, If you understand G.805/809 (and therein lies the major problem) the meaning of 'end-end' is obvious, ie it's between the trail termination points in whatever layer network is considered. Forget the wrong/misleading OSI model......there is more to networking than 'one' network layer. regards, Neil > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: 07 June 2003 13:32 > To: 'Lin, Zhi-Wei' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > > > I think you need to clarify what "end to end" > means. In the way of PWE/MPLS I believe it means > PE-PE imposition/disposition points. > > --Tom > > > Sorry to interrupt your very informative discussions, but I > > have a question. In the case of the MPLS (which is our > > topic?) my understanding is that OAMs are always end-to-end? > > "Segment" OAMs similar to ATM can be created for MPLS simply > > by stacking a new MPLS header? > > > > Thanks for any clarification > > Zhi > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Thursday, June 05, 2003 3:56 PM > > > To: 'Mark Seery'; Jack Pugaczewski > > > Cc: pwe3@ietf.org > > > Subject: RE: [PWE3] PWE Service interworking > > > > > > > > > Mark, > > > > > > 1) Each layer should have segment OAM mechanism that applies > > > only to that layer. > > > 2) End-to-end OAM at each layer corresponds to the > > > terminating points of that layer. > > > > > > -Shahram > > > > > > >-----Original Message----- > > > >From: Mark Seery [mailto:mark@mseery.com] > > > >Sent: Thursday, June 05, 2003 3:48 PM > > > >To: Jack Pugaczewski > > > >Cc: pwe3@ietf.org > > > >Subject: RE: [PWE3] PWE Service interworking > > > > > > > > > > > >--- Jack Pugaczewski wrote: > > > >> Segment and End-to-End OAM are utilized on an every > > > >> day basis and a > > > >> strategic part of the fault isolation process. More > > specifically, > > > >> the ability to generate an End-to-End at an intermediate > > > >> node is essential. > > > >> This allows the client (or client application) to > > > >> initiate the request to a > > > >> single element management system. > > > >> > > > >> PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > > > > > > > >Thanks Jack, > > > > > > > >1) Is it important that every layer be able to do a > > > >segment OAM on every segment, or just the segments > > > >that logically belong to that layer (i.e. as > > > >delineated by access points of that layer)? For > > > >example, in the following network: > > > > > > > > 1 2 3 4 5 6 7 > > > >CE----ATM_SW-----PE----P----PE----ATM_SW----CE > > > > > > > >From the perspective of the ATM layer (assume VCC, no > > > >VPC), Is a segment between 2 and 6 or are 2-3, 3-4, > > > >4-5, and 5-6 also considered segments (from the > > > >perspective of your requirements as an operator). > > > > > > > >2) When an end-to-end OAM is initiated from an > > > >intermediate node, what is considered end-to-end? For > > example, in the > > > >following network: > > > > > > > > > > > > 1 2 3 4 5 6 7 > > > >CE----FR_SW-----PE----P----PE----ATM_SW----CE > > > > > > > >If an end-to-end OAM is initiated at "6" towards the > direction of > > > >"1", where would you expect the OAM to terminate/take action? > > > > > > > >Thanks, > > > >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 > > > > > _______________________________________________ > 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: PWE Service interworking Date: Sat, 7 Jun 2003 16:50:03 -0700 Lines: 90 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Sun Jun 08 01:50:22 2003 Return-path: To: "Lin, Zhi-Wei" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: 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 Hi Zhi, Imagine a network: |----------------------------| |----|-----|-----| TE COS = Gold CE1----PE1----P1----P2----P3----P4----PE1----CE2 There are two end-to-end OAMs that may be desireable in this network: 1) PE1--PE2 (the user plane for the LDP-LDP connection between PE1 and PE2) 2) P1-P4 If you take the layer between P1 and P4 and add a label, you do not reveal the segments you obfiscate them by creating another "layer". The segments P1-P2, P2-P3, and P3-P4 would ideally be treated via special segment OAMs, and the end-to-end OAM between P1 and P4 would be handled by a different type of OAM, and end-to-end OAM. With PW, labels are used to represent attachment circuits (essentially as a mux field), creating another Label push: |--------------------------------| |----------------------------| |----|-----|-----| CE1----PE1----P1----P2----P3----P4----PE1----CE2 Creating another End-to-End OAM, the discussion then becomes what is the termination points of this "layer". If you view PW as just a mux function, and you create a mux field rather than pushing another label, then the network looks like this: |---------------------------------------------| |----------------------------| |----|-----|-----| TE COS = Gold CE1----PE1----P1----P2----P3----P4----PE1----CE2 However, I suspect that the label push was used as automating the way a mux indication is assigned to an attachment circuit. Perhaps an alternative solution may have been to use signaling to indicate the relationship between mux numbers and attachment circuits, and then use a mux field and not push a label. if you believe the OAM needs to flow to a different point in the PE system because the PW logic is implemented in a different part of the system, then you are back to this: |--------------------------------| |----------------------------| |----|-----|-----| CE1----PE1----P1----P2----P3----P4----PE1----CE2 Which brings us back to the old conversations (described previously as "useless" and "in-bred") about what is a layer. Mark -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Lin, Zhi-Wei Sent: Friday, June 06, 2003 5:52 AM To: 'Shahram Davari'; 'Mark Seery'; Jack Pugaczewski Cc: pwe3@ietf.org Subject: RE: [PWE3] PWE Service interworking Hi all, Sorry to interrupt your very informative discussions, but I have a question. In the case of the MPLS (which is our topic?) my understanding is that OAMs are always end-to-end? "Segment" OAMs similar to ATM can be created for MPLS simply by stacking a new MPLS header? Thanks for any clarification Zhi From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Akiva Sadovski Subject: RE: PWE Service interworking Date: Sun, 8 Jun 2003 17:44:08 +0200 Lines: 120 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 Sun Jun 08 16:49:26 2003 Return-path: To: "'Jack Pugaczewski'" X-Mailer: Internet Mail Service (5.5.2653.19) X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h58EmcB03450 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h58EpnB03544 Status: O Jack, sorry to interrupt you, but - few questions inline ... > -----Original Message----- > From: Jack Pugaczewski [mailto:jtpugac@qwest.com] > Sent: Thursday, June 05, 2003 10:27 PM > To: Shahram Davari; 'Mark Seery' > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking=20 >=20 >=20 > Agreed. However, for OAM fault management interworking is=20 > required. For > example, a Frame Relay PVC being marked as inactive should=20 > map to an F5 VCC > ATM OAM AIS condition. In the case of OAM for loopback testing the > interworking entity in conjunction with the element=20 > management system is > responsible for the relationship between layers. =20 Can you elaborate ? What is done by interworking entity and what by management system ? Therefore,=20 > it is possible > to initiate Layer n OAM in one direction and Layer n+1 in the other > direction. ... with the translation done by SIWF at the edge ? What are the benefi= ts ? >=20 > PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > =A0 >=20 >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, June 05, 2003 2:56 PM > > To: 'Mark Seery'; Jack Pugaczewski > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] PWE Service interworking > > > > > > Mark, > > > > 1) Each layer should have segment OAM mechanism that applies only > > to that layer. > > 2) End-to-end OAM at each layer corresponds to the terminating > > points of that layer. > > > > -Shahram > > > > >-----Original Message----- > > >From: Mark Seery [mailto:mark@mseery.com] > > >Sent: Thursday, June 05, 2003 3:48 PM > > >To: Jack Pugaczewski > > >Cc: pwe3@ietf.org > > >Subject: RE: [PWE3] PWE Service interworking > > > > > > > > >--- Jack Pugaczewski wrote: > > >> Segment and End-to-End OAM are utilized on an every > > >> day basis and a > > >> strategic part of the fault isolation process. More > > >> specifically, the > > >> ability to generate an End-to-End at an intermediate > > >> node is essential. > > >> This allows the client (or client application) to > > >> initiate the request to a > > >> single element management system. > > >> > > >> PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY > > > > > >Thanks Jack, > > > > > >1) Is it important that every layer be able to do a > > >segment OAM on every segment, or just the segments > > >that logically belong to that layer (i.e. as > > >delineated by access points of that layer)? For > > >example, in the following network: > > > > > > 1 2 3 4 5 6 7 > > >CE----ATM_SW-----PE----P----PE----ATM_SW----CE > > > > > >From the perspective of the ATM layer (assume VCC, no > > >VPC), Is a segment between 2 and 6 or are 2-3, 3-4, > > >4-5, and 5-6 also considered segments (from the > > >perspective of your requirements as an operator). > > > > > >2) When an end-to-end OAM is initiated from an > > >intermediate node, what is considered end-to-end? For > > >example, in the following network: > > > > > > > > > 1 2 3 4 5 6 7 > > >CE----FR_SW-----PE----P----PE----ATM_SW----CE > > > > > >If an end-to-end OAM is initiated at "6" towards the > > >direction of "1", where would you expect the OAM to > > >terminate/take action? > > > > > >Thanks, > > >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: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-arch-03.txt Date: Mon, 09 Jun 2003 07:46:04 -0400 Lines: 83 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 09 14:00:22 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Architecture Author(s) : S. Bryant, P. Pate Filename : draft-ietf-pwe3-arch-03.txt Pages : 46 Date : 2003-6-6 This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services (such as Frame Relay, ATM, Ethernet TDM and SONET/SDH) over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, specifies the various protocol elements and their functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-arch-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-arch-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Lin, Zhi-Wei" Subject: RE: PWE Service interworking Date: Mon, 9 Jun 2003 08:40:42 -0400 Lines: 135 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 Jun 09 14:49:36 2003 Return-path: To: "'Mark Seery'" , "Lin, Zhi-Wei" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Mark, Thanks for the info! I wasn't concentrating on the use of PW but more on the MPLS functions. My view has always been that PW is simply an encapsulation just like GFP ;-) I was confused with your statement that it is ideal to have a segment OAM. What would drive this? Also your point about how to identify OAM termination points is interesting. How would you do this? Would this simply be done during the setup of the LSP, i.e., the end-points of the LSP is by definition the trail termination? And as such the OAM CV would use the ID of the endpoints as its source TTI? Thanks Zhi > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: Saturday, June 07, 2003 7:50 PM > To: Lin, Zhi-Wei > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Hi Zhi, > > Imagine a network: > > |----------------------------| > > |----|-----|-----| TE COS = Gold > > > CE1----PE1----P1----P2----P3----P4----PE1----CE2 > > There are two end-to-end OAMs that may be desireable in this network: > > 1) PE1--PE2 (the user plane for the LDP-LDP connection > between PE1 and PE2) > 2) P1-P4 > > If you take the layer between P1 and P4 and add a label, you > do not reveal > the segments you obfiscate them by creating another "layer". > The segments > P1-P2, P2-P3, and P3-P4 would ideally be treated via special > segment OAMs, > and the end-to-end OAM between P1 and P4 would be handled by > a different > type of OAM, and end-to-end OAM. > > With PW, labels are used to represent attachment circuits > (essentially as a > mux field), creating another Label push: > > |--------------------------------| > > |----------------------------| > > |----|-----|-----| > > > CE1----PE1----P1----P2----P3----P4----PE1----CE2 > > Creating another End-to-End OAM, the discussion then becomes > what is the > termination points of this "layer". If you view PW as just a > mux function, > and you create a mux field rather than pushing another label, then the > network looks like this: > > |---------------------------------------------| > > |----------------------------| > > |----|-----|-----| TE COS = Gold > > > CE1----PE1----P1----P2----P3----P4----PE1----CE2 > > However, I suspect that the label push was used as automating > the way a mux > indication is assigned to an attachment circuit. Perhaps an > alternative > solution may have been to use signaling to indicate the > relationship between > mux numbers and attachment circuits, and then use a mux field > and not push a > label. > > if you believe the OAM needs to flow to a different point in > the PE system > because the PW logic is implemented in a different part of > the system, then > you are back to this: > > |--------------------------------| > > |----------------------------| > > |----|-----|-----| > > > CE1----PE1----P1----P2----P3----P4----PE1----CE2 > > Which brings us back to the old conversations (described previously as > "useless" and "in-bred") about what is a layer. > > Mark > > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On > Behalf Of Lin, > Zhi-Wei > Sent: Friday, June 06, 2003 5:52 AM > To: 'Shahram Davari'; 'Mark Seery'; Jack Pugaczewski > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Hi all, > > Sorry to interrupt your very informative discussions, but I > have a question. > In the case of the MPLS (which is our topic?) my > understanding is that OAMs > are always end-to-end? "Segment" OAMs similar to ATM can be > created for MPLS > simply by stacking a new MPLS header? > > Thanks for any clarification > Zhi > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Keith Knightson Subject: RE: PWE Service interworking Date: Mon, 9 Jun 2003 09:35:13 -0400 Lines: 103 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A35389025D69A2@i2km07-ukbr.domain1.systemhost.n et> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 09 15:40:38 2003 Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: <0536FC9B908BEC4597EE721BE6A35389025D69A2@i2km07-ukbr.domain1.systemhost.n et> To: pwe3@ietf.org X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.75.37] using ID at Mon, 9 Jun 2003 09:33:16 -0400 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 11:39 PM +0100 7/6/03, neil.2.harrison@bt.com wrote: >Tom, > >If you understand G.805/809 (and therein lies the major problem) the meaning >of 'end-end' is obvious, ie it's between the trail termination points in >whatever layer network is considered. Forget the wrong/misleading OSI >model......there is more to networking than 'one' network layer. > >regards, Neil > Neil, Oh, please.....now you are going too far....even for your high horses....... :-) And, if you were to understand IS 8648 and IS 7498 (and therein lies the major problem), you would know about "sub-layers" and "relays"..... and how more than two entities can be distributed within a given layer/sub-layer to overcome the discontinuities due to protocol differences. You said "There is more to networking than 'one' network layer". Yes, and they were called sub-layers, within the named layer in question. Any layer can be sub-divided into sub-layers, this is clear from IS 7498/X.200 and is particularly described in IS 8648. You are confusing the general concept of layering (which includes sub-layering) with specific religious labelling and packaging of a stack for a particular open system design formulated in a bygone era of X.25. You say the meaning of 'end-end' is obvious.. This is clearly not the case....particularly since G.805 is actually wrong in this respect. For example, with service interworking, the "end" points are not coincident with your so-called trails or protocol termination points. Service mapping implies conveying the *semantics* across a relaying point, i,e. beyond the point of protocol termination. Let's just suppose for argument's sake that some effect is common to both the protocols being interworked and can be mapped to provide an "end-to-end" effect. It is clear that the intermediate points simply convey this effect by mapping. Therefore the trail termination points of the protocols on each side of the relay cannot be considered to be ends for the communication in that layer, despite the fact that each of the protocol is terminated at some intermediate point. There are a number of peer entitities operating at the same "level" operating co-operatively and in tandem to provide ends beyond themselves. Nor can you consider that there is higher layer trail to rperesent the e2e because there is no addtional protocol layer to terminate such a trail. I.e. G.805 simply does not work in this case. The whole point about services is defining their semantics, i.e beyond the one dimensional issue of what's on the wire, that's just syntax. Origination and/or Termination points do not necessarily dictate the end point for all communication at that particular peer level. They only indicate the presence of generators and receivers of a particular format/syntax processing. The real question to be asked if whether the user be aware that the so-called service interworking is taking place as opposed to the so-called network interworking for any given protocol he uses between him (the CE) and the PE? Suppose both SIW and NIW are involved for for two different paths from given CE with the same CE-PE protocol stack at one end, but with NIW at end and SIw at another, because conditions at each of the destinations are different. All this should be hidden from the user, but the semantics should be the same. Users cannot be expected to know how the semantics might differ for every conceivable concoction that might be applied deep in the bowels of core networks or at remote access networks. BTW, it is possible to map OAM imperatives/notifications across a service interworking unit for and within a given peering arrangement. The use of the term "layer network"in G.805/809 is also erroneous and not useful in this respect. Trail end-points are clearly not always indicative of "networks" nor "ends". A protocol does not automatically beget a network. The term network also has no useful universal or absolute definition is also best avoided. Addtionally, G.805 ignores the three party semantics between user-provider-user, a vital ingredient in building relays which deploy service interworking and understanding of the service being provided. I will ignore the issue about the usefulness or otherwise of the term "layer" for the moment. In actuality, protocols have roles. Protocols play a role according to context in which they are applied. They also operate between peer entities. That's about all that can be said in terms of useful basic principles in the general context (i.e.not OSI context). I suggest avoiding these "my-architecture/your-architecture" rat-holes, and simply discuss how protocols are to be stacked, and where, and the semantic effects required between any /all of designated points that can be identified. Of course, in this case, I agree it would be much simpler if the IETF could join the 21st century and allow the use of something sensible to draw proper pictures to illustrate all these cases and issues more precisely, pictures being worth thousands of disageable and ambiguous words. Regards Keith BTW it is really simple to define the difference between network interworking and service interworking without using the terms layer or network or G.805 or any other inappropriate model. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: PWE Service interworking Date: Mon, 9 Jun 2003 09:33:53 -0700 (PDT) Lines: 43 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 Mon Jun 09 18:34:18 2003 Return-path: To: "Lin, Zhi-Wei" 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 Zhi, --- "Lin, Zhi-Wei" wrote: [SNIP] > I was confused with your statement that it is ideal > to have a segment OAM. > What would drive this? Well, anyone who has spent any time in an operations role will know that the fundamental element of diagnosis is isolation. Whether you are doing break-fix, continuity checks, or performance management, you want to know where and when things are/are not happening. Segmentation is a form of element isolation. > Also your point about how to identify OAM > termination points is interesting. > How would you do this? Would this simply be done > during the setup of the > LSP, i.e., the end-points of the LSP is by > definition the trail termination? > And as such the OAM CV would use the ID of the > endpoints as its source TTI? So worth noting obviously that "termination points" is not a term used by this organization do perhaps not construction to spend too much time dwelling on that term, but in essence you want to know where in the network the action is being formed, and you want to be able to verify that where you think it is happening, it is actually happening. One method of verification would be to use an address. As to where it should happen, well some organizations would suggest that it should happen at layer end points, and they support this notion by defining what a layer is. In this group, I think we are trending in the direction of it happens where the PW code is implemented. Is this just a semantic difference? An exercise for the reader. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: PWE Service interworking Date: Mon, 9 Jun 2003 12:48:47 -0400 Lines: 188 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32EA6.D65DBE64" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 09 18:51:45 2003 Return-path: To: "'Mark Seery'" , "Lin, Zhi-Wei" 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_01C32EA6.D65DBE64 Content-Type: text/plain; charset="iso-8859-1" Mark/Zhi: One other aspect of segmentation is ability to provide arbitrary OAM demarcation boundaries. Very useful when considering multiple organizations providing a service. Dave > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com] > Sent: Monday, June 09, 2003 12:34 PM > To: Lin, Zhi-Wei > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Zhi, > > --- "Lin, Zhi-Wei" wrote: > [SNIP] > > > I was confused with your statement that it is ideal > > to have a segment OAM. > > What would drive this? > > Well, anyone who has spent any time in an operations > role will know that the fundamental element of > diagnosis is isolation. Whether you are doing > break-fix, continuity checks, or performance > management, you want to know where and when things > are/are not happening. Segmentation is a form of > element isolation. > > > > Also your point about how to identify OAM > > termination points is interesting. > > How would you do this? Would this simply be done > > during the setup of the > > LSP, i.e., the end-points of the LSP is by > > definition the trail termination? > > And as such the OAM CV would use the ID of the > > endpoints as its source TTI? > > So worth noting obviously that "termination points" is > not a term used by this organization do perhaps not > construction to spend too much time dwelling on that term, > but in essence you want to know where in the network the > action is being formed, and you want to be able to verify > that where you think it is happening, it is actually > happening. One method of verification would be to use an > address. As to where it should happen, well some > organizations would suggest that it should happen at layer > end points, and they support this notion by defining what a > layer is. In this group, I think we are trending in the > direction of it happens where the PW code is implemented. Is > this just a semantic difference? An exercise for the reader. > > Mark > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C32EA6.D65DBE64 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE Service interworking

Mark/Zhi:

One other aspect of segmentation is ability to = provide arbitrary OAM demarcation boundaries. Very useful when = considering multiple organizations providing a service.

Dave

> -----Original Message-----
> From: Mark Seery [mailto:mark@mseery.com]
> Sent: Monday, June 09, 2003 12:34 PM
> To: Lin, Zhi-Wei
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PWE Service interworking =
>
>
> Zhi,
>
> --- "Lin, Zhi-Wei" = <Zhiwlin@nyct.com> wrote:
> [SNIP]
> 
> > I was confused with your statement that it = is ideal
> > to have a segment OAM.
> > What would drive this?
>
> Well, anyone who has spent any time in an = operations
> role will know that the fundamental element = of
> diagnosis is isolation. Whether you are = doing
> break-fix, continuity checks, or = performance
> management, you want to know where and when = things
> are/are not happening. Segmentation is a form = of
> element isolation.
>
>
> > Also your point about how to identify = OAM
> > termination points is interesting.
> > How would you do this? Would this simply = be done
> > during the setup of the
> > LSP, i.e., the end-points of the LSP is = by
> > definition the trail termination?
> > And as such the OAM CV would use the ID of = the
> > endpoints as its source TTI?
>
> So worth noting obviously that = "termination points" is
> not a term used by this organization do perhaps = not
> construction to spend too much time dwelling on = that term,
> but in essence you want to know where in the = network the
> action is being formed, and you want to be able = to verify
> that where you think it is happening, it is = actually
> happening. One method of verification would be = to use an
> address. As to where it should happen, well = some
> organizations would suggest that it should = happen at layer
> end points, and they support this notion by = defining what a
> layer is. In this group, I think we are = trending in the
> direction of it happens where the PW code is = implemented. Is
> this just a semantic difference? An exercise = for the reader.
>
> Mark
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C32EA6.D65DBE64-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Lin, Zhi-Wei" Subject: RE: PWE Service interworking Date: Mon, 9 Jun 2003 14:35:19 -0400 Lines: 183 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32EB5.E106BFA0" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 09 20:48:51 2003 Return-path: To: "'David Allan'" , "'Mark Seery'" , "Lin, Zhi-Wei" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32EB5.E106BFA0 Content-Type: text/plain; charset="iso-8859-1" Hi Mark, David, Thanks. But I guess my confusion is that in the MPLS, when end-to-end OAM segments can be created on the fly, why would you need another "mode" for segment OAM? Isn't ATM's segment OAM equivalent in the MPLS by simply creating a new end-to-end OAM? Zhi -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Monday, June 09, 2003 12:49 PM To: 'Mark Seery'; Lin, Zhi-Wei Cc: pwe3@ietf.org Subject: RE: [PWE3] PWE Service interworking Mark/Zhi: One other aspect of segmentation is ability to provide arbitrary OAM demarcation boundaries. Very useful when considering multiple organizations providing a service. Dave > -----Original Message----- > From: Mark Seery [ mailto:mark@mseery.com ] > Sent: Monday, June 09, 2003 12:34 PM > To: Lin, Zhi-Wei > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Zhi, > > --- "Lin, Zhi-Wei" wrote: > [SNIP] > > > I was confused with your statement that it is ideal > > to have a segment OAM. > > What would drive this? > > Well, anyone who has spent any time in an operations > role will know that the fundamental element of > diagnosis is isolation. Whether you are doing > break-fix, continuity checks, or performance > management, you want to know where and when things > are/are not happening. Segmentation is a form of > element isolation. > > > > Also your point about how to identify OAM > > termination points is interesting. > > How would you do this? Would this simply be done > > during the setup of the > > LSP, i.e., the end-points of the LSP is by > > definition the trail termination? > > And as such the OAM CV would use the ID of the > > endpoints as its source TTI? > > So worth noting obviously that "termination points" is > not a term used by this organization do perhaps not > construction to spend too much time dwelling on that term, > but in essence you want to know where in the network the > action is being formed, and you want to be able to verify > that where you think it is happening, it is actually > happening. One method of verification would be to use an > address. As to where it should happen, well some > organizations would suggest that it should happen at layer > end points, and they support this notion by defining what a > layer is. In this group, I think we are trending in the > direction of it happens where the PW code is implemented. Is > this just a semantic difference? An exercise for the reader. > > Mark > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C32EB5.E106BFA0 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] PWE Service interworking
Hi Mark, David,
 
Thanks. But I guess my confusion is that in the MPLS, when end-to-end OAM segments can be created on the fly, why would you need another "mode" for segment OAM? Isn't ATM's segment OAM equivalent in the MPLS by simply creating a new end-to-end OAM?
 
Zhi
 
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Monday, June 09, 2003 12:49 PM
To: 'Mark Seery'; Lin, Zhi-Wei
Cc: pwe3@ietf.org
Subject: RE: [PWE3] PWE Service interworking

Mark/Zhi:

One other aspect of segmentation is ability to provide arbitrary OAM demarcation boundaries. Very useful when considering multiple organizations providing a service.

Dave

> -----Original Message-----
> From: Mark Seery [mailto:mark@mseery.com]
> Sent: Monday, June 09, 2003 12:34 PM
> To: Lin, Zhi-Wei
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PWE Service interworking
>
>
> Zhi,
>
> --- "Lin, Zhi-Wei" <Zhiwlin@nyct.com> wrote:
> [SNIP]
> 
> > I was confused with your statement that it is ideal
> > to have a segment OAM.
> > What would drive this?
>
> Well, anyone who has spent any time in an operations
> role will know that the fundamental element of
> diagnosis is isolation. Whether you are doing
> break-fix, continuity checks, or performance
> management, you want to know where and when things
> are/are not happening. Segmentation is a form of
> element isolation.
>
>
> > Also your point about how to identify OAM
> > termination points is interesting.
> > How would you do this? Would this simply be done
> > during the setup of the
> > LSP, i.e., the end-points of the LSP is by
> > definition the trail termination?
> > And as such the OAM CV would use the ID of the
> > endpoints as its source TTI?
>
> So worth noting obviously that "termination points" is
> not a term used by this organization do perhaps not
> construction to spend too much time dwelling on that term,
> but in essence you want to know where in the network the
> action is being formed, and you want to be able to verify
> that where you think it is happening, it is actually
> happening. One method of verification would be to use an
> address. As to where it should happen, well some
> organizations would suggest that it should happen at layer
> end points, and they support this notion by defining what a
> layer is. In this group, I think we are trending in the
> direction of it happens where the PW code is implemented. Is
> this just a semantic difference? An exercise for the reader.
>
> Mark
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>

------_=_NextPart_001_01C32EB5.E106BFA0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: [Fwd: Re: RE: Is PWE a layer?] Date: Mon, 09 Jun 2003 12:46:42 -0600 Organization: Level3 Communications LLC. Lines: 39 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Mon Jun 09 21:04:08 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 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 -------- Subject: Re: [PWE3] RE: Is PWE a layer? Date: Mon, 09 Jun 2003 12:45:53 -0600 From: Luca Martini Organization: Level3 Communications LLC. To: "Busschbach, Peter B (Peter)" References: > Luca, > > Do you carry Frame Relay and ATM over your MPLS network? I can see that Ping is sufficient for VPLS and VPWS, but I know carriers who are offering > Frame Relay service today and who want to extend those across an MPLS core, who need OAM functions similar to what they get today from an ATM core network. > > The problem with regular (bi-directional) Ping is that it is a poor mechanism to localize failures. If a PE doesn't receive a reply, it doesn't know > whether the forward or backward PW is down. In fact, it could even be that neither the forward nor backward PW is down, but that there is a problem in the > control plane. Uni-directional Ping would solve that problem. > > Peter > > Yes, we carry both frame, and ATM, and we already have operational experience with failures ( even very strange ones ) in the MPLS network. In general ping is the first step, if it fails , then s traceroute along the MPLS LSP works very well to find out where the failure is. This is unidirectional debugging, and seems to work quite well today. Luca From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: status signalling of MPLS PW state Date: Mon, 09 Jun 2003 13:00:38 -0600 Organization: Level3 Communications LLC. Lines: 149 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Mon Jun 09 21:07:47 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 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 WG, The text below was sent to me by Toby Smith as a proposal to resolve some shortcomings of the label withdraw signaling method currently in the control WG document. I do not agree with the negotiation part, but I think that the status TLV has merit, and we should use the ignore bit for backward compatibility, in addition to a setting that would use the old label withdraw method. (but this is an implementation detail). I would like to keep this thread concise to this status TLV problem , and actually conclude it quickly. Thanks. Luca ---------------------- 6. Signaling of Pseudo Wire Link Errors The signaling mechanisms described in the sections above provide at most a coarse-grained notion of the remote PW's forwarding state (via withdrawal of the PW label). However, the use of PW label withdrawal to connote interface state has two shortcomings: first, its use is inconsistent among interface types; for example, Ethernet VLAN PWs use label withdrawal to indicate CE interface operStatus events, whereas ATM VCC PWs do not. Second, when label withdrawal is used, it often conveys insufficient information about the type of event that instigated the label withdrawal; it may be due to an unexpected PE-CE interface failure event, for example, or due to a planned operator change to the PE's configuration. This section details an optional signaling mechanism which augments the mechanisms described in the sections above and conveys more detailed information about pseudo wire link errors. 6.1 Negotiation of Signaling Method To maintain backward compatibility with baseline PW signaling implementations, use of pseudo wire link error (PWLE) signaling is negotiated between the two PW peers. If either peer does not support the use of PWLE signaling then baseline signaling behavior, as described in the above sections, MUST be utilized. Martini, et al. [Page 13] Internet Draft draft-ietf-pwe3-control-protocol-02.txt December 2002 A PE indicates its desire to utilize PWLE signaling by setting the P bit in the VC Type field to 1, and immediately signaling its PW label to its peer, regardless of the CE-facing interface's operational status. The negotiation procedure detailed in Appendix A MUST be followed to determine the state of the P bit for the PW. Once negotiation of the value of the P bit is complete, the PE determines its signaling behavior. If the P bit is not set after negotiation, the baseline signaling behavior described in the sections above MUST be used. If the P bit is set after negotiation, the signaling mechanisms described below MUST be used. 6.2 Use of Label Mappings in PWLE Mode When both peers signal their willingness to participate in PWLE mode, the use of label mappings and label withdraws differs slightly from the baseline signaling. When in PWLE mode, PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the CE interface state. The PW label MUST NOT be withdrawn unless the user administratively configures the CE interface down (or the PW configuration is deleted entirely). 6.3 Signaling PW Link Errors in PWLE Mode When PWLE mode is in use, the PE devices use a new LDP TLV to indicate status to their remote peers, instead of withdrawing their PW FEC labels. This Link Status TLV contains more information than the simple Label Withdraw message used in the baseline signaling. The format of the Link Status TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Link Status (0x0700) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where status is a 2 octet bit field: 0x0001 - Pseudo Wire Not Forwarding 0x0002 - Local Customer-facing Interface Receive Error 0x0004 - Local Customer-facing Interface Transmit Error 0x0008 - Local Core-facing Interface Receive Error 0x0010 - Local Core-facing Interface Transmit Error The presence of the lowest bit (PW Not Forwarding) acts only as a summary of the other bit fields, or to convey a link-down event for which none of the other bits apply. The Link Status TLV is transported to the remote PW peer via a new LDP message, the PW Link Status Message. Martini, et al. [Page 14] Internet Draft draft-ietf-pwe3-control-protocol-02.txt December 2002 The format of the PW Link Status Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| PW Link Status (0x0700) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The rationale for using a new LDP message type instead of resending the PW FEC label mapping with an enclosed Link Status TLV is twofold: first, when updating PW link status, there is no need to convey actual label mapping information, and use of the Label Mapping message requires the inclusion of a Label TLV. Second, and more importantly, when a PE's CE-facing interface encounters an error, use of the new message allows the PE to send a single Link Status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. The use of a PW FEC TLV with only group ID set is undefined for use in Label Mapping messages. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: PWE Service interworking Date: Mon, 9 Jun 2003 15:13:20 -0400 Lines: 268 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32EBB.3057CE6E" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 09 21:21:47 2003 Return-path: To: "'Lin, Zhi-Wei'" , "'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_01C32EBB.3057CE6E Content-Type: text/plain; charset="iso-8859-1" HI Zhi: Did not get the comparitive aspects of your previous post.... You are correct in nothing that you can get similar semantics (scoping the boundaries of an OAM flow and create subnet specific behaviors) via using label stacking, and in many multi-provider cases you would want to do so (depending on layer isolation to impart a degree of security as your security within a given layer is limited). Downside being you are trading 4 bytes of overhead per packet to get this (additional stack entry) as well as creating additional control adjacencies (to effectively instantiate a new layer). The other issue is that adding a layer at the top of the stack, and then using OAM on that layer is not the same as testing as close to the payload as possible (you can postulate that the coverage is usefully close until you get into ECMP; we are figuring out how to get stuff to fate share with the bottom label, but its a different story for the top label). IMHO segment OAM on the bottom label would be more chatty but more authoritative in the presence of ECMP vs. adding layers. cheers Dave -----Original Message----- From: Lin, Zhi-Wei [mailto:Zhiwlin@NYCT.com] Sent: Monday, June 09, 2003 2:35 PM To: Allan, David [CAR:NS00:EXCH]; 'Mark Seery'; Lin, Zhi-Wei Cc: pwe3@ietf.org Subject: RE: [PWE3] PWE Service interworking Hi Mark, David, Thanks. But I guess my confusion is that in the MPLS, when end-to-end OAM segments can be created on the fly, why would you need another "mode" for segment OAM? Isn't ATM's segment OAM equivalent in the MPLS by simply creating a new end-to-end OAM? Zhi -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Monday, June 09, 2003 12:49 PM To: 'Mark Seery'; Lin, Zhi-Wei Cc: pwe3@ietf.org Subject: RE: [PWE3] PWE Service interworking Mark/Zhi: One other aspect of segmentation is ability to provide arbitrary OAM demarcation boundaries. Very useful when considering multiple organizations providing a service. Dave > -----Original Message----- > From: Mark Seery [mailto:mark@mseery.com ] > Sent: Monday, June 09, 2003 12:34 PM > To: Lin, Zhi-Wei > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Zhi, > > --- "Lin, Zhi-Wei" wrote: > [SNIP] > > > I was confused with your statement that it is ideal > > to have a segment OAM. > > What would drive this? > > Well, anyone who has spent any time in an operations > role will know that the fundamental element of > diagnosis is isolation. Whether you are doing > break-fix, continuity checks, or performance > management, you want to know where and when things > are/are not happening. Segmentation is a form of > element isolation. > > > > Also your point about how to identify OAM > > termination points is interesting. > > How would you do this? Would this simply be done > > during the setup of the > > LSP, i.e., the end-points of the LSP is by > > definition the trail termination? > > And as such the OAM CV would use the ID of the > > endpoints as its source TTI? > > So worth noting obviously that "termination points" is > not a term used by this organization do perhaps not > construction to spend too much time dwelling on that term, > but in essence you want to know where in the network the > action is being formed, and you want to be able to verify > that where you think it is happening, it is actually > happening. One method of verification would be to use an > address. As to where it should happen, well some > organizations would suggest that it should happen at layer > end points, and they support this notion by defining what a > layer is. In this group, I think we are trending in the > direction of it happens where the PW code is implemented. Is > this just a semantic difference? An exercise for the reader. > > Mark > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C32EBB.3057CE6E Content-Type: text/html; charset="iso-8859-1" Message
HI Zhi:
 
Did not get the comparitive aspects of your previous post....
 
You are correct in nothing that you can get similar semantics (scoping the boundaries of an OAM flow and create subnet specific behaviors) via using label stacking, and in many multi-provider cases you would want to do so (depending on layer isolation to impart a degree of security as your security within a given layer is limited). Downside being you are trading 4 bytes of overhead per packet to get this (additional stack entry) as well as creating additional control adjacencies (to effectively instantiate a new layer).
 
The other issue is that adding a layer at the top of the stack, and then using OAM on that layer is not the same as testing as close to the payload as possible (you can postulate that the coverage is usefully close until you get into ECMP; we are figuring out how to get stuff to fate share with the bottom label, but its a different story for the top label). IMHO segment OAM on the bottom label would be more chatty but more authoritative in the presence of ECMP vs. adding layers.
 
cheers
Dave
 
 
 
-----Original Message-----
From: Lin, Zhi-Wei [mailto:Zhiwlin@NYCT.com]
Sent: Monday, June 09, 2003 2:35 PM
To: Allan, David [CAR:NS00:EXCH]; 'Mark Seery'; Lin, Zhi-Wei
Cc: pwe3@ietf.org
Subject: RE: [PWE3] PWE Service interworking

Hi Mark, David,
 
Thanks. But I guess my confusion is that in the MPLS, when end-to-end OAM segments can be created on the fly, why would you need another "mode" for segment OAM? Isn't ATM's segment OAM equivalent in the MPLS by simply creating a new end-to-end OAM?
 
Zhi
 
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Monday, June 09, 2003 12:49 PM
To: 'Mark Seery'; Lin, Zhi-Wei
Cc: pwe3@ietf.org
Subject: RE: [PWE3] PWE Service interworking

Mark/Zhi:

One other aspect of segmentation is ability to provide arbitrary OAM demarcation boundaries. Very useful when considering multiple organizations providing a service.

Dave

> -----Original Message-----
> From: Mark Seery [mailto:mark@mseery.com]
> Sent: Monday, June 09, 2003 12:34 PM
> To: Lin, Zhi-Wei
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PWE Service interworking
>
>
> Zhi,
>
> --- "Lin, Zhi-Wei" <Zhiwlin@nyct.com> wrote:
> [SNIP]
> 
> > I was confused with your statement that it is ideal
> > to have a segment OAM.
> > What would drive this?
>
> Well, anyone who has spent any time in an operations
> role will know that the fundamental element of
> diagnosis is isolation. Whether you are doing
> break-fix, continuity checks, or performance
> management, you want to know where and when things
> are/are not happening. Segmentation is a form of
> element isolation.
>
>
> > Also your point about how to identify OAM
> > termination points is interesting.
> > How would you do this? Would this simply be done
> > during the setup of the
> > LSP, i.e., the end-points of the LSP is by
> > definition the trail termination?
> > And as such the OAM CV would use the ID of the
> > endpoints as its source TTI?
>
> So worth noting obviously that "termination points" is
> not a term used by this organization do perhaps not
> construction to spend too much time dwelling on that term,
> but in essence you want to know where in the network the
> action is being formed, and you want to be able to verify
> that where you think it is happening, it is actually
> happening. One method of verification would be to use an
> address. As to where it should happen, well some
> organizations would suggest that it should happen at layer
> end points, and they support this notion by defining what a
> layer is. In this group, I think we are trending in the
> direction of it happens where the PW code is implemented. Is
> this just a semantic difference? An exercise for the reader.
>
> Mark
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>

------_=_NextPart_001_01C32EBB.3057CE6E-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Thomas D. Nadeau" Subject: RE: PWE OAM Resolution / MPLS PID Date: Mon, 9 Jun 2003 15:45:58 -0400 Organization: Cisco Systems Lines: 57 Sender: pwe3-admin@ietf.org References: <20030603161549.44373.qmail@web13504.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 Mon Jun 09 21:47:18 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: <20030603161549.44373.qmail@web13504.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:m_seery@yahoo.com] > Sent: Tuesday, June 03, 2003 12:16 PM > To: tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: Re: PWE OAM Resolution / MPLS PID > > > > > 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 don't think that we need to define > more than one mechanism for the reasons I have > explained my my prior posting. My customers certainly > > don't want more than one mechanism. Also, before any > conclusion is drawn, I suggest asking the WG for consensus on > such a decision. > > --Tom > > MS=> So now we get in to the old what is a major > problem. Dave has asserted that Y.1711 requires > meaningful less processing than PW VCCV. This is > considered important in the mode where OAM is being > run x/sec on every LSP in order to identify defects > and suppress alarm storms. I would ask Dave if he ask implemented Y.1711 or if his customers are actually using it. I have an implementation of both VCCV and LSP ping that seem to work fine. There have been SPs on this list too that have also pointed out that this approach is ok for them. --Tom > Tom, Can you please comment on how you see the > processing difference and whether you think it > would/would not make a difference if running OAM in > this way. > > More generally, do you assert that PW VCCV has > equivalent functionality to Y.1711 including the > generation of FDI etc. > > Thanks, > Mark > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: PWE Service interworking Date: Mon, 9 Jun 2003 22:00:24 +0100 Lines: 176 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32ECA.2468E7C1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 09 23:02:04 2003 Return-path: To: dallan@nortelnetworks.com, mark@mseery.com, Zhiwlin@nyct.com X-Mailer: Internet Mail Service (5.5.2654.89) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32ECA.2468E7C1 Content-Type: text/plain; charset="iso-8859-1" Dave, And this is a powerful potential feature of MPLS.....fixed heirarchy models don't easily allow this. regards, Neil -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: 09 June 2003 17:49 To: 'Mark Seery'; Lin, Zhi-Wei Cc: pwe3@ietf.org Subject: RE: [PWE3] PWE Service interworking Mark/Zhi: One other aspect of segmentation is ability to provide arbitrary OAM demarcation boundaries. Very useful when considering multiple organizations providing a service. Dave > -----Original Message----- > From: Mark Seery [ mailto:mark@mseery.com ] > Sent: Monday, June 09, 2003 12:34 PM > To: Lin, Zhi-Wei > Cc: pwe3@ietf.org > Subject: RE: [PWE3] PWE Service interworking > > > Zhi, > > --- "Lin, Zhi-Wei" wrote: > [SNIP] > > > I was confused with your statement that it is ideal > > to have a segment OAM. > > What would drive this? > > Well, anyone who has spent any time in an operations > role will know that the fundamental element of > diagnosis is isolation. Whether you are doing > break-fix, continuity checks, or performance > management, you want to know where and when things > are/are not happening. Segmentation is a form of > element isolation. > > > > Also your point about how to identify OAM > > termination points is interesting. > > How would you do this? Would this simply be done > > during the setup of the > > LSP, i.e., the end-points of the LSP is by > > definition the trail termination? > > And as such the OAM CV would use the ID of the > > endpoints as its source TTI? > > So worth noting obviously that "termination points" is > not a term used by this organization do perhaps not > construction to spend too much time dwelling on that term, > but in essence you want to know where in the network the > action is being formed, and you want to be able to verify > that where you think it is happening, it is actually > happening. One method of verification would be to use an > address. As to where it should happen, well some > organizations would suggest that it should happen at layer > end points, and they support this notion by defining what a > layer is. In this group, I think we are trending in the > direction of it happens where the PW code is implemented. Is > this just a semantic difference? An exercise for the reader. > > Mark > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C32ECA.2468E7C1 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] PWE Service interworking
Dave,
 
And this is a powerful potential feature of MPLS.....fixed heirarchy models don't easily allow this.
 
regards, Neil
-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: 09 June 2003 17:49
To: 'Mark Seery'; Lin, Zhi-Wei
Cc: pwe3@ietf.org
Subject: RE: [PWE3] PWE Service interworking

Mark/Zhi:

One other aspect of segmentation is ability to provide arbitrary OAM demarcation boundaries. Very useful when considering multiple organizations providing a service.

Dave

> -----Original Message-----
> From: Mark Seery [mailto:mark@mseery.com]
> Sent: Monday, June 09, 2003 12:34 PM
> To: Lin, Zhi-Wei
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] PWE Service interworking
>
>
> Zhi,
>
> --- "Lin, Zhi-Wei" <Zhiwlin@nyct.com> wrote:
> [SNIP]
> 
> > I was confused with your statement that it is ideal
> > to have a segment OAM.
> > What would drive this?
>
> Well, anyone who has spent any time in an operations
> role will know that the fundamental element of
> diagnosis is isolation. Whether you are doing
> break-fix, continuity checks, or performance
> management, you want to know where and when things
> are/are not happening. Segmentation is a form of
> element isolation.
>
>
> > Also your point about how to identify OAM
> > termination points is interesting.
> > How would you do this? Would this simply be done
> > during the setup of the
> > LSP, i.e., the end-points of the LSP is by
> > definition the trail termination?
> > And as such the OAM CV would use the ID of the
> > endpoints as its source TTI?
>
> So worth noting obviously that "termination points" is
> not a term used by this organization do perhaps not
> construction to spend too much time dwelling on that term,
> but in essence you want to know where in the network the
> action is being formed, and you want to be able to verify
> that where you think it is happening, it is actually
> happening. One method of verification would be to use an
> address. As to where it should happen, well some
> organizations would suggest that it should happen at layer
> end points, and they support this notion by defining what a
> layer is. In this group, I think we are trending in the
> direction of it happens where the PW code is implemented. Is
> this just a semantic difference? An exercise for the reader.
>
> Mark
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>

------_=_NextPart_001_01C32ECA.2468E7C1-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Mark Seery" Subject: RE: status signalling of MPLS PW state Date: Mon, 9 Jun 2003 22:15:17 -0700 Lines: 48 Sender: pwe3-admin@ietf.org References: <3EE4D956.6060902@level3.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Tue Jun 10 07:16:14 2003 Return-path: To: "Luca Martini" 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: <3EE4D956.6060902@level3.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 Hi Luca, >> Luca: I do not agree with the negotiation part, but I think that the status TLV has merit, and we should use the ignore bit for backward compatibility, in addition to a setting that would use the old label withdraw method. (but this is an implementation detail)....<< Not sure I understand your comment. The following specifies a way to indicate that the old label withdraw method is indicated (though could be more explicit I suppose) "If the P bit is not set after negotiation, the baseline signaling behavior described in the sections above MUST be used. If the P bit is set after negotiation, the signaling mechanisms described below MUST be used. " So is your comment simply that you agree with this, but "ignore bit" should be used in addition? ======== In addition.... Not sure if you were looking for feed back on status codes, but........for the sake of those that come after us, I find the terms a little confusing. Clearly by the title of the section there is an intent to signal PW link errors, but also an indication to signal link status, as denoted by the TLV name. So maybe two different concepts got mixed up in one mechanism or perhaps I am just being pedantic, but it would seem that a link error and a link status are not the same thing. For example, one might expect a link status to be: up, down, initializing, quiescing (sp?), forwarding, blocked, whatever.....whereas "Local Customer-facing Interface Receive Error" seems more like an event, a counter, or a reason code for a status code. Now I suppose the setting of the lowest bit is a "status code" of types (the summary comment not withstanding), and if forwarding/not forwarding are the only two states a link can be in, then that is fine. If a link can be in other states, seems like a more generalized format might be useful for the long term/or the TLV should be called something like "Link Error TLV" instead. In addition, I would be interested to know if operators would like information on the type of link error, and if yes, maybe a field where vendors can place a description code. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: David Zelig Subject: RE: status signalling of MPLS PW state Date: Tue, 10 Jun 2003 09:18:07 +0200 Lines: 41 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-From: pwe3-admin@ietf.org Tue Jun 10 08:16:59 2003 Return-path: To: "'Luca Martini'" , 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 Luca, > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Monday, June 09, 2003 9:01 PM > To: pwe3@ietf.org > Subject: [PWE3] status signalling of MPLS PW state > > -+-+-+ > > Where status is a 2 octet bit field: > > 0x0001 - Pseudo Wire Not Forwarding > 0x0002 - Local Customer-facing Interface Receive Error > 0x0004 - Local Customer-facing Interface Transmit Error > 0x0008 - Local Core-facing Interface Receive Error > 0x0010 - Local Core-facing Interface Transmit Error > > The presence of the lowest bit (PW Not Forwarding) acts only as a > summary of the other bit fields, or to convey a link-down > event for > which none of the other bits apply. > I think additional status of "Local Customer-facing Interface Administratively Down" is required: While the peer should not send traffic, it is preferred not to report a red alarm in this case. In addition to Local Core-facing Errors, a more general error would be the inability to send/receive traffic due to a failure of the outer tunnel (it may fail also due to mid-network conditions and has the same effect as core facing interface failure). Maybe an indication of "Core side Receive Error" and "Core side Transmit Error" instead (or in addition) are required. For terminology, I believe the term "failure" is more suitable than "error", since an error on physical interface is usually related to a temporary event while failure is declared after an error is persisted for pre-defined time window. David From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: status signalling of MPLS PW state Date: Tue, 10 Jun 2003 09:22:56 -0400 Lines: 226 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 Tue Jun 10 15:37:49 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] status signalling of MPLS PW state Thread-Index: AcMuvOjSSkBag8eJRPuQ5dA5ocF/CAAkqCMg To: "Luca Martini" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5ADNVB21014 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca, I am glad that you have recognized the need for conveying the link status as compared to withdrawing the VC-LABEL for the same and Toby has good proposal. However, I would like PWE3 to approach this slightly differently as described in draft-shah-pwe3-control-protocol-extension-00.txt. We need a +generic mechanism+ to relay "dynamic attributes" of the PW, including the status of the AC (and yes, it should be AC or PW status as compared to link status). The generic mechanism can then be used to extend control signaling without having to constantly change the base draft. The extension draft proposes that such PW attributes be included in "optional parameter" field of the Label mapping message. The advantage of this approach is, 1) conveying of one or more dynamic attributes in a single label mapping message. Extension draft describes IP addr (needed for ARP-mediation) , IP+MAC addr (needed for IPLS), QOS, tunnel mechanisms used, etc TLVs. 2) a way to include these attributes in first mapping msg as compared to a follow-on status msgs (for example, PE does not know the status of the remote AC until link status msg follows the initial label mapping msg) 3) allows update of the attributes. When dynamic attribute changes, an update is sent without withdrawing the VC-FEC 4 ) allows definitions of new attributes without modifying base LDP or martini signaling draft I would like PWE3 to consider this approach. /himanshu wavesmith networks > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Monday, June 09, 2003 3:01 PM > To: pwe3@ietf.org > Subject: [PWE3] status signalling of MPLS PW state > > > WG, > > The text below was sent to me by Toby Smith as a proposal to > resolve some > shortcomings of the label withdraw signaling method > currently in the control > WG document. > > I do not agree with the negotiation part, but I think that > the status TLV has > merit, and we should use the ignore bit for backward > compatibility, in addition > to a setting that would use the old label withdraw method. > (but this is an > implementation detail). > > > I would like to keep this thread concise to this status TLV > problem , and > actually conclude it quickly. > > Thanks. > Luca > > > > ---------------------- > 6. Signaling of Pseudo Wire Link Errors > > The signaling mechanisms described in the sections above provide > at most a coarse-grained notion of the remote PW's forwarding > state (via withdrawal of the PW label). However, the use of PW > label withdrawal to connote interface state has two shortcomings: > first, its use is inconsistent among interface types; for example, > Ethernet VLAN PWs use label withdrawal to indicate CE interface > operStatus events, whereas ATM VCC PWs do not. Second, when label > withdrawal is used, it often conveys insufficient > information about > the type of event that instigated the label withdrawal; it may be > due to an unexpected PE-CE interface failure event, for > example, or > due to a planned operator change to the PE's configuration. > > > This section details an optional signaling mechanism > which augments > the mechanisms described in the sections above and conveys more > detailed information about pseudo wire link errors. > > > 6.1 Negotiation of Signaling Method > > To maintain backward compatibility with baseline PW signaling > implementations, use of pseudo wire link error (PWLE) signaling > is negotiated between the two PW peers. If either peer does > not support the use of PWLE signaling then baseline signaling > behavior, as described in the above sections, MUST be utilized. > > > > > Martini, et al. > [Page 13] > > > Internet Draft draft-ietf-pwe3-control-protocol-02.txt > December 2002 > > > A PE indicates its desire to utilize PWLE signaling by setting the > P bit in the VC Type field to 1, and immediately signaling its PW > label to its peer, regardless of the CE-facing interface's > operational status. The negotiation procedure detailed > in Appendix > A MUST be followed to determine the state of the P bit for the PW. > > Once negotiation of the value of the P bit is complete, the PE > determines its signaling behavior. If the P bit is not set after > negotiation, the baseline signaling behavior described in the > sections above MUST be used. If the P bit is set after > negotiation, the signaling mechanisms described below MUST be > used. > > > 6.2 Use of Label Mappings in PWLE Mode > > When both peers signal their willingness to participate in PWLE > mode, the use of label mappings and label withdraws differs > slightly from the baseline signaling. When in PWLE mode, PEs MUST > send PW label mapping messages to their peers as soon as the PW is > configured and administratively enabled, regardless of the CE > interface state. The PW label MUST NOT be withdrawn unless the > user administratively configures the CE interface down (or the PW > configuration is deleted entirely). > > > 6.3 Signaling PW Link Errors in PWLE Mode > > When PWLE mode is in use, the PE devices use a new LDP TLV to > indicate status to their remote peers, instead of > withdrawing their > PW FEC labels. This Link Status TLV contains more > information than > the simple Label Withdraw message used in the baseline signaling. > > The format of the Link Status TLV is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| Link Status (0x0700) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Where status is a 2 octet bit field: > > 0x0001 - Pseudo Wire Not Forwarding > 0x0002 - Local Customer-facing Interface Receive Error > 0x0004 - Local Customer-facing Interface Transmit Error > 0x0008 - Local Core-facing Interface Receive Error > 0x0010 - Local Core-facing Interface Transmit Error > > The presence of the lowest bit (PW Not Forwarding) acts only as a > summary of the other bit fields, or to convey a link-down > event for > which none of the other bits apply. > > The Link Status TLV is transported to the remote PW peer via a new > LDP message, the PW Link Status Message. > > > Martini, et al. > [Page 14] > > > Internet Draft draft-ietf-pwe3-control-protocol-02.txt > December 2002 > > > The format of the PW Link Status Message is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| PW Link Status (0x0700) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW FEC TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Link Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional Parameters | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The rationale for using a new LDP message type instead of > resending > the PW FEC label mapping with an enclosed Link Status TLV is > twofold: first, when updating PW link status, there is no need to > convey actual label mapping information, and use of the Label > Mapping message requires the inclusion of a Label TLV. > Second, and > more importantly, when a PE's CE-facing interface encounters an > error, use of the new message allows the PE to send a single Link > Status message, using a PW FEC TLV with only the group ID set, to > denote this change in status for all affected PW connections. The > use of a PW FEC TLV with only group ID set is undefined for use in > Label Mapping messages. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: status signalling of MPLS PW state Date: Tue, 10 Jun 2003 09:59:16 -0400 Lines: 837 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F58.7B58F1C0" X-From: pwe3-admin@ietf.org Tue Jun 10 16:07:20 2003 Return-path: To: "'Himanshu Shah'" , Luca Martini , 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_01C32F58.7B58F1C0 Content-Type: text/plain; charset="iso-8859-1" Hi: I think there is a few things not being considered. 1) Not clear that it is useful to negotiate support on a per-PW basis. Presumably peers learn node behavior and carry it forward for subsequent transactions. So what is learned from the first PW mapping attempt should be sticky. 2) Upon a restart of a peer, it may be due to a software upgrade, so behavior needs to be re-learned. 3) If negotation is part of a label transaction, and it occurs regardless of the status of the attachement circuit, some unlucky PW may get to be set up, discover the far end does not support status signalling, and get promptly torn down again. If during a restart, you are trying to do multiple mappings, this can be very messy esp if somthing like an ATM OC3 is down with thousands of VCCs mapping to PWs and that is the first mapping communicated between peers. 4) Although status signalling is a unique requirement of PWs (IP uses routing), I do not quite undestand the prohibition from negotiating support at LDP session establishment. Seems to avoid a lot of race condition. The only wrinkle being some ACs for which status may not apply at the present time. 5) The reason code needs some extensions: - administratively down - loss of peer control plane - phy down - virtual interface (e.g. VCC/DLCI) down cheers Dave > -----Original Message----- > From: Himanshu Shah [mailto:hshah@wavesmithnetworks.com] > Sent: Tuesday, June 10, 2003 9:23 AM > To: Luca Martini; pwe3@ietf.org > Subject: RE: [PWE3] status signalling of MPLS PW state > > > Luca, > > I am glad that you have recognized the need for > conveying the link status as compared to withdrawing > the VC-LABEL for the same and Toby has good > proposal. > > However, I would like PWE3 to approach this slightly > differently as described in > draft-shah-pwe3-control-protocol-extension-00.txt. > > We need a +generic mechanism+ to relay "dynamic > attributes" of the PW, including the status of the AC (and > yes, it should be AC or PW status as compared to link > status). The generic mechanism can then be used to extend > control signaling without having to constantly change the base draft. > > The extension draft proposes that such PW attributes > be included in "optional parameter" field of the Label > mapping message. The advantage of this approach is, > > 1) conveying of one or more dynamic attributes in a > single label mapping message. Extension draft describes > IP addr (needed for ARP-mediation) , IP+MAC addr (needed > for IPLS), QOS, tunnel mechanisms used, etc TLVs. > 2) a way to include these attributes in first mapping msg > as compared to a follow-on status msgs (for example, > PE does not know the status of the remote AC until > link status msg follows the initial label mapping msg) > 3) allows update of the attributes. When dynamic attribute > changes, an update is sent without withdrawing the VC-FEC > 4 ) allows definitions of new attributes without > modifying base LDP or martini signaling draft > > I would like PWE3 to consider this approach. > > /himanshu > wavesmith networks > > > > > > -----Original Message----- > > From: Luca Martini [mailto:luca@level3.net] > > Sent: Monday, June 09, 2003 3:01 PM > > To: pwe3@ietf.org > > Subject: [PWE3] status signalling of MPLS PW state > > > > > > WG, > > > > The text below was sent to me by Toby Smith as a proposal to > > resolve some > > shortcomings of the label withdraw signaling method > > currently in the control > > WG document. > > > > I do not agree with the negotiation part, but I think that > > the status TLV has > > merit, and we should use the ignore bit for backward > > compatibility, in addition > > to a setting that would use the old label withdraw method. > > (but this is an > > implementation detail). > > > > > > I would like to keep this thread concise to this status TLV > > problem , and > > actually conclude it quickly. > > > > Thanks. > > Luca > > > > > > > > ---------------------- > > 6. Signaling of Pseudo Wire Link Errors > > > > The signaling mechanisms described in the sections above provide > > at most a coarse-grained notion of the remote PW's forwarding > > state (via withdrawal of the PW label). However, the use of PW > > label withdrawal to connote interface state has two > shortcomings: > > first, its use is inconsistent among interface types; > for example, > > Ethernet VLAN PWs use label withdrawal to indicate CE interface > > operStatus events, whereas ATM VCC PWs do not. Second, > when label > > withdrawal is used, it often conveys insufficient > > information about > > the type of event that instigated the label withdrawal; > it may be > > due to an unexpected PE-CE interface failure event, for > > example, or > > due to a planned operator change to the PE's configuration. > > > > > > This section details an optional signaling mechanism > > which augments > > the mechanisms described in the sections above and conveys more > > detailed information about pseudo wire link errors. > > > > > > 6.1 Negotiation of Signaling Method > > > > To maintain backward compatibility with baseline PW signaling > > implementations, use of pseudo wire link error (PWLE) signaling > > is negotiated between the two PW peers. If either peer does > > not support the use of PWLE signaling then baseline signaling > > behavior, as described in the above sections, MUST be utilized. > > > > > > > > > > Martini, et al. > > [Page 13] > > > > > > Internet Draft draft-ietf-pwe3-control-protocol-02.txt > > December 2002 > > > > > > A PE indicates its desire to utilize PWLE signaling by > setting the > > P bit in the VC Type field to 1, and immediately > signaling its PW > > label to its peer, regardless of the CE-facing interface's > > operational status. The negotiation procedure detailed > > in Appendix > > A MUST be followed to determine the state of the P bit > for the PW. > > > > Once negotiation of the value of the P bit is complete, the PE > > determines its signaling behavior. If the P bit is not > set after > > negotiation, the baseline signaling behavior described in the > > sections above MUST be used. If the P bit is set after > > negotiation, the signaling mechanisms described below MUST be > > used. > > > > > > 6.2 Use of Label Mappings in PWLE Mode > > > > When both peers signal their willingness to participate in PWLE > > mode, the use of label mappings and label withdraws differs > > slightly from the baseline signaling. When in PWLE > mode, PEs MUST > > send PW label mapping messages to their peers as soon > as the PW is > > configured and administratively enabled, regardless of the CE > > interface state. The PW label MUST NOT be withdrawn unless the > > user administratively configures the CE interface down > (or the PW > > configuration is deleted entirely). > > > > > > 6.3 Signaling PW Link Errors in PWLE Mode > > > > When PWLE mode is in use, the PE devices use a new LDP TLV to > > indicate status to their remote peers, instead of > > withdrawing their > > PW FEC labels. This Link Status TLV contains more > > information than > > the simple Label Withdraw message used in the baseline > signaling. > > > > The format of the Link Status TLV is: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1|0| Link Status (0x0700) | Length > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Status Code | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Where status is a 2 octet bit field: > > > > 0x0001 - Pseudo Wire Not Forwarding > > 0x0002 - Local Customer-facing Interface Receive Error > > 0x0004 - Local Customer-facing Interface Transmit Error > > 0x0008 - Local Core-facing Interface Receive Error > > 0x0010 - Local Core-facing Interface Transmit Error > > > > The presence of the lowest bit (PW Not Forwarding) acts > only as a > > summary of the other bit fields, or to convey a link-down > > event for > > which none of the other bits apply. > > > > The Link Status TLV is transported to the remote PW > peer via a new > > LDP message, the PW Link Status Message. > > > > > > Martini, et al. > > [Page 14] > > > > > > Internet Draft draft-ietf-pwe3-control-protocol-02.txt > > December 2002 > > > > > > The format of the PW Link Status Message is: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| PW Link Status (0x0700) | Message Length > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Message ID > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PW FEC TLV > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Link Status TLV > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Optional Parameters > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The rationale for using a new LDP message type instead of > > resending > > the PW FEC label mapping with an enclosed Link Status TLV is > > twofold: first, when updating PW link status, there is > no need to > > convey actual label mapping information, and use of the Label > > Mapping message requires the inclusion of a Label TLV. > > Second, and > > more importantly, when a PE's CE-facing interface encounters an > > error, use of the new message allows the PE to send a > single Link > > Status message, using a PW FEC TLV with only the group > ID set, to > > denote this change in status for all affected PW > connections. The > > use of a PW FEC TLV with only group ID set is undefined > for use in > > Label Mapping messages. > > > > > > > > _______________________________________________ > > 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_01C32F58.7B58F1C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] status signalling of MPLS PW state

Hi:

I think there is a few things not being = considered.

1) Not clear that it is useful to negotiate support = on a per-PW basis. Presumably peers learn node behavior and carry it = forward for subsequent transactions. So what is learned from the first = PW mapping attempt should be sticky.

2) Upon a restart of a peer, it may be due to a = software upgrade, so behavior needs to be re-learned.

3) If negotation is part of a label transaction, and = it occurs regardless of the status of the attachement circuit, some = unlucky PW may get to be set up, discover the far end does not support = status signalling, and get promptly torn down again. If during a = restart, you are trying to do multiple mappings, this can be very messy = esp if somthing like an ATM OC3 is down with thousands of VCCs mapping = to PWs and that is the first mapping communicated between peers. =

4) Although status signalling is a unique requirement = of PWs (IP uses routing), I do not quite undestand the prohibition from = negotiating support at LDP session establishment. Seems to avoid a lot = of race condition. The only wrinkle being some ACs for which status may = not apply at the present time.

5) The reason code needs some extensions:
        - = administratively down
        - loss of = peer control plane
        - phy = down
        - virtual = interface (e.g. VCC/DLCI) down

cheers
Dave

> -----Original Message-----
> From: Himanshu Shah [mailto:hshah@wavesmithnetwor= ks.com]
> Sent: Tuesday, June 10, 2003 9:23 AM
> To: Luca Martini; pwe3@ietf.org
> Subject: RE: [PWE3] status signalling of MPLS = PW state
>
>
> Luca,
>
> I am glad that you have recognized the need for =
> conveying the link status as compared to = withdrawing
> the VC-LABEL for the same and Toby has good =
> proposal.
>
> However, I would like PWE3 to approach this = slightly
> differently as described in
> = draft-shah-pwe3-control-protocol-extension-00.txt.
>
> We need a +generic mechanism+ to relay = "dynamic
> attributes" of the PW, including the = status of the AC (and
> yes, it should be AC or PW status as compared = to link
> status). The generic mechanism can then be used = to extend
> control signaling without having to constantly = change the base draft.
>
> The extension draft proposes that such PW = attributes
> be included in "optional parameter" = field of the Label
> mapping message. The advantage of this approach = is,
>
> 1) conveying of one or more dynamic attributes = in a
>      single label = mapping message. Extension draft describes
>      IP addr (needed = for ARP-mediation) , IP+MAC addr (needed
>      for IPLS), QOS, = tunnel mechanisms used, etc TLVs.
> 2) a way to include these attributes in first = mapping msg
>      as compared to a = follow-on status msgs (for example,
>      PE does not know = the status of the remote AC until
>     link status msg follows = the initial label mapping msg)
> 3) allows update of the attributes. When = dynamic attribute
>     changes, an update is = sent without withdrawing the VC-FEC
> 4 ) allows definitions of new attributes = without
>       modifying = base LDP or martini signaling draft
>
> I would like PWE3 to consider this = approach.
>
> /himanshu
> wavesmith networks
>     
>
>
>
> > -----Original Message-----
> > From: Luca Martini [mailto:luca@level3.net]
> > Sent: Monday, June 09, 2003 3:01 PM
> > To: pwe3@ietf.org
> > Subject: [PWE3] status signalling of MPLS = PW state
> >
> >
> > WG,
> >
> > The text below was sent to me by Toby = Smith as a proposal to
> > resolve some
> > shortcomings of the  label withdraw = signaling method
> > currently in the control
> > WG document.
> >
> > I do not agree with the negotiation part, = but I think that
> > the status TLV has
> > merit, and we should use the ignore bit = for backward
> > compatibility, in addition
> > to a setting that would use the old label = withdraw method.
> > (but this is an
> > implementation detail).
> >
> >
> > I would like to keep this thread concise = to this status TLV
> > problem , and
> > actually conclude it quickly.
> >
> > Thanks.
> > Luca
> >
> >
> >
> > ----------------------
> > 6. Signaling of Pseudo Wire Link = Errors
> >
> >     The signaling = mechanisms described in the sections above provide
> >     at most a = coarse-grained notion of the remote PW's forwarding
> >     state (via = withdrawal of the PW label).  However, the use of PW
> >     label withdrawal = to connote interface state has two
> shortcomings:
> >     first, its use is = inconsistent among interface types;
> for example,
> >     Ethernet VLAN PWs = use label withdrawal to indicate CE interface
> >     operStatus events, = whereas ATM VCC PWs do not.  Second,
> when label
> >     withdrawal is = used, it often conveys insufficient
> > information about
> >     the type of event = that instigated the label withdrawal;
> it may be
> >     due to an = unexpected PE-CE interface failure event, for
> > example, or
> >     due to a planned = operator change to the PE's configuration.
> >
> >
> >     This section = details an optional signaling mechanism
> > which augments
> >     the mechanisms = described in the sections above and conveys more
> >     detailed = information about pseudo wire link errors.
> >
> >
> > 6.1 Negotiation of Signaling Method
> >
> >     To maintain = backward compatibility with baseline PW signaling
> >     implementations, = use of pseudo wire link error (PWLE) signaling
> >     is negotiated = between the two PW peers.  If either peer does
> >     not support the = use of PWLE signaling then baseline signaling
> >     behavior, as = described in the above sections, MUST be utilized.
> >
> >
> >
> >
> > Martini, et = al.           &nb= sp;           &nb= sp;           &nb= sp;          
> >  [Page 13]
> > =0C> >
> > Internet Draft  = draft-ietf-pwe3-control-protocol-02.txt   
> > December 2002
> >
> >
> >     A PE indicates its = desire to utilize PWLE signaling by
> setting the
> >     P bit in the VC = Type field to 1, and immediately
> signaling its PW
> >     label to its peer, = regardless of the CE-facing interface's
> >     operational = status.  The negotiation procedure detailed
> > in Appendix
> >     A MUST be followed = to determine the state of the P bit
> for the PW.
> >
> >     Once negotiation = of the value of the P bit is complete, the PE
> >     determines its = signaling behavior.  If the P bit is not
> set after
> >     negotiation, the = baseline signaling behavior described in the
> >     sections above = MUST be used.  If the P bit is set after
> >     negotiation, the = signaling mechanisms described below MUST be
> >     used.
> >
> >
> > 6.2 Use of Label Mappings in PWLE = Mode
> >
> >     When both peers = signal their willingness to participate in PWLE
> >     mode, the use of = label mappings and label withdraws differs
> >     slightly from the = baseline signaling.  When in PWLE
> mode, PEs MUST
> >     send PW label = mapping messages to their peers as soon
> as the PW is
> >     configured and = administratively enabled, regardless of the CE
> >     interface = state.  The PW label MUST NOT be withdrawn unless the
> >     user = administratively configures the CE interface down
> (or the PW
> >     configuration is = deleted entirely).
> >
> >
> > 6.3 Signaling PW Link Errors in PWLE = Mode
> >
> >     When PWLE mode is = in use, the PE devices use a new LDP TLV to
> >     indicate status to = their remote peers, instead of
> > withdrawing their
> >     PW FEC = labels.  This Link Status TLV contains more
> > information than
> >     the simple Label = Withdraw message used in the baseline
> signaling.
> >
> >     The format of the = Link Status TLV is:
> >
> >      = 0            = ;       = 1            = ;       = 2            = ;       3
> >      0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >     |1|0|   = Link Status (0x0700)    |      = Length           =
>         = |
> >    
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >     = |         Status = Code           = |
> >     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >     Where status is a = 2 octet bit field:
> >
> >      0x0001 - = Pseudo Wire Not Forwarding
> >      0x0002 - = Local Customer-facing Interface Receive Error
> >      0x0004 - = Local Customer-facing Interface Transmit Error
> >      0x0008 - = Local Core-facing Interface Receive Error
> >      0x0010 - = Local Core-facing Interface Transmit Error
> >
> >     The presence of = the lowest bit (PW Not Forwarding) acts
> only as a
> >     summary of the = other bit fields, or to convey a link-down
> > event for
> >     which none of the = other bits apply.
> >
> >     The Link Status = TLV is transported to the remote PW
> peer via a new
> >     LDP message, the = PW Link Status Message.
> >
> >
> > Martini, et = al.           &nb= sp;           &nb= sp;           &nb= sp;          
> >  [Page 14]
> > =0C> >
> > Internet Draft  = draft-ietf-pwe3-control-protocol-02.txt   
> > December 2002
> >
> >
> >     The format of the = PW Link Status Message is:
> >
> >      = 0            = ;       = 1            = ;       = 2            = ;       3
> >      0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >     |1|   PW = Link Status (0x0700)   |      = Message Length  
>         = |
> >    
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >     = |            = ;            = ;   Message = ID           &nbs= p;     
>         = |
> >    
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >     = |            = ;            = ;   PW FEC = TLV           &nb= sp;     
>         = |
> >    
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >     = |            = ;            = ; Link Status = TLV           &nb= sp;  
>         = |
> >    
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >     = |            = ;          Optional = Parameters          &n= bsp;  
>         = |
> >    
> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >
> >
> >     The rationale for = using a new LDP message type instead of
> > resending
> >     the PW FEC label = mapping with an enclosed Link Status TLV is
> >     twofold: first, = when updating PW link status, there is
> no need to
> >     convey actual = label mapping information, and use of the Label
> >     Mapping message = requires the inclusion of a Label TLV. 
> > Second, and
> >     more importantly, = when a PE's CE-facing interface encounters an
> >     error, use of the = new message allows the PE to send a
> single Link
> >     Status message, = using a PW FEC TLV with only the group
> ID set, to
> >     denote this change = in status for all affected PW
> connections.  The
> >     use of a PW FEC = TLV with only group ID set is undefined
> for use in
> >     Label Mapping = messages.
> >
> >
> >
> > = _______________________________________________
> > 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_01C32F58.7B58F1C0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 10 Jun 2003 18:12:37 +0200 Lines: 151 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Israel Sasson , Akiva Sadovski , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Tue Jun 10 17:25:37 2003 Return-path: To: "Stewart Bryant (E-mail)" , "Danny McPherson (E-mail)" , "PWE3 WG (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart, Danny and all, As (some of) you have probably noticed I have posted an updated (-06) revision of the CESoPSN draft. I would like to ask the WG to adopt this draft as a WG item, and this message is intended to initiate a TECHNICAL discussion on this subject. Allow me to present my major points wrt the -06 revision: Compatibility with the Requirements and Architecture Documents ============================================================== The -06 revision of the draft explicitly answers the following requirements: 1. The requirements stated in the WG Charter 2. Common PWE3 requirements as stated in draft-ietf-pwe3-requirements-05.txt 3. Specific requirements for emulation of TDM services as stated in draft-ietf-pwe3-tdm-requirements-00.txt 4. The PWE3 architectural principles as presented in draft-ietf-pwe3-arch-03.txt. 5. Additional requirements that have been identified during discussions in the WG and in the (unpublished) disucssions of the TDM design team, including ability to preserve packetization latency regardless of the bit rate of the emulated Nx64 kbit/s service Formerly Raised Technical Issues ================================ The -06 revision of the draft addresses all the technical isssue that have ever been raised with the previous revisions. In particular: 1. It allows BW-saving suppression of RTP headers when the information carried in these headers cannot contribute to the truthfulness of the emulation 2. It defines a new mode for carrying trunk-specific Nx64 kbit/s services with CAS which: a) Does not mandate usage of RTP for synchronization between TDM data and telephony application signaling b) Does not break the principle of fixed packetization time for emulation of TDM services 3. It defines, as mandatory, raw encapsulation of unstructured T1 without any intermediate adaptation. Independent Interoperable Implementations ========================================= A series of successful interoperability tests between independent CESoPSN implementations has been completed lately. The following ones have been publicly announced: 1. http://www.rad.com/Article/0,6583,13305,00.html 2. http://www.axerra.com/pr15.html 3. http://www.axerra.com/pr16.html 4. http://www.reduxcom.com/News/Issues/030527_WiMark/index.html I would like to ask the WG participants to break their silence and to provide the input that is required to advance the subject of TDM emulation over PSN in the WG. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) 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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, June 09, 2003 1:45 PM > Cc: midcom@ietf.org > Subject: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : TDM Circuit Emulation Service over > Packet Switched > Network (CESoPSN) > Author(s) : S. Vainshtein et al. > Filename : draft-vainshtein-cesopsn-06.txt > Pages : 38 > Date : 2003-6-6 > > This document describes a method for encapsulating unstructured (T1, > E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over > packet-switching networks (PSN). In this regard, it > complements similar > work for SONET/SDH. > > Proposed PW encapsulation uses RTP for clock recovery and leverages > RTP-based mixing capabilities for application state signaling between > Customer Edge (CE) devices. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-vainshtein-cesopsn-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-vainshtein-cesopsn-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: status signalling of MPLS PW state Date: Tue, 10 Jun 2003 11:28:34 -0400 Lines: 994 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F64.F4F3EC08" X-From: pwe3-admin@ietf.org Tue Jun 10 17:34:05 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] status signalling of MPLS PW state Thread-Index: AcMvWH1keOXyF+yNRwmH6Xa/NbNhQQADBxEA To: "David Allan" , "Luca Martini" , Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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_01C32F64.F4F3EC08 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree. The capability negotiation should be nodal. The shah-extension draft is backward-compatible with base signaling draft and does not require any capability exchange. =20 /himanshu -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Tuesday, June 10, 2003 9:59 AM To: Himanshu Shah; Luca Martini; pwe3@ietf.org Subject: RE: [PWE3] status signalling of MPLS PW state Hi:=20 I think there is a few things not being considered.=20 1) Not clear that it is useful to negotiate support on a per-PW basis. = Presumably peers learn node behavior and carry it forward for subsequent = transactions. So what is learned from the first PW mapping attempt = should be sticky. 2) Upon a restart of a peer, it may be due to a software upgrade, so = behavior needs to be re-learned.=20 3) If negotation is part of a label transaction, and it occurs = regardless of the status of the attachement circuit, some unlucky PW may = get to be set up, discover the far end does not support status = signalling, and get promptly torn down again. If during a restart, you = are trying to do multiple mappings, this can be very messy esp if = somthing like an ATM OC3 is down with thousands of VCCs mapping to PWs = and that is the first mapping communicated between peers.=20 4) Although status signalling is a unique requirement of PWs (IP uses = routing), I do not quite undestand the prohibition from negotiating = support at LDP session establishment. Seems to avoid a lot of race = condition. The only wrinkle being some ACs for which status may not = apply at the present time. 5) The reason code needs some extensions:=20 - administratively down=20 - loss of peer control plane=20 - phy down=20 - virtual interface (e.g. VCC/DLCI) down=20 cheers=20 Dave=20 > -----Original Message-----=20 > From: Himanshu Shah [ mailto:hshah@wavesmithnetworks.com]=20 > Sent: Tuesday, June 10, 2003 9:23 AM=20 > To: Luca Martini; pwe3@ietf.org=20 > Subject: RE: [PWE3] status signalling of MPLS PW state=20 >=20 >=20 > Luca,=20 >=20 > I am glad that you have recognized the need for=20 > conveying the link status as compared to withdrawing=20 > the VC-LABEL for the same and Toby has good=20 > proposal.=20 >=20 > However, I would like PWE3 to approach this slightly=20 > differently as described in=20 > draft-shah-pwe3-control-protocol-extension-00.txt.=20 >=20 > We need a +generic mechanism+ to relay "dynamic=20 > attributes" of the PW, including the status of the AC (and=20 > yes, it should be AC or PW status as compared to link=20 > status). The generic mechanism can then be used to extend=20 > control signaling without having to constantly change the base draft.=20 >=20 > The extension draft proposes that such PW attributes=20 > be included in "optional parameter" field of the Label=20 > mapping message. The advantage of this approach is,=20 >=20 > 1) conveying of one or more dynamic attributes in a=20 > single label mapping message. Extension draft describes=20 > IP addr (needed for ARP-mediation) , IP+MAC addr (needed=20 > for IPLS), QOS, tunnel mechanisms used, etc TLVs.=20 > 2) a way to include these attributes in first mapping msg=20 > as compared to a follow-on status msgs (for example,=20 > PE does not know the status of the remote AC until=20 > link status msg follows the initial label mapping msg)=20 > 3) allows update of the attributes. When dynamic attribute=20 > changes, an update is sent without withdrawing the VC-FEC=20 > 4 ) allows definitions of new attributes without=20 > modifying base LDP or martini signaling draft=20 >=20 > I would like PWE3 to consider this approach.=20 >=20 > /himanshu=20 > wavesmith networks=20 > =20 >=20 >=20 >=20 > > -----Original Message-----=20 > > From: Luca Martini [ mailto:luca@level3.net]=20 > > Sent: Monday, June 09, 2003 3:01 PM=20 > > To: pwe3@ietf.org=20 > > Subject: [PWE3] status signalling of MPLS PW state=20 > >=20 > >=20 > > WG,=20 > >=20 > > The text below was sent to me by Toby Smith as a proposal to=20 > > resolve some=20 > > shortcomings of the label withdraw signaling method=20 > > currently in the control=20 > > WG document.=20 > >=20 > > I do not agree with the negotiation part, but I think that=20 > > the status TLV has=20 > > merit, and we should use the ignore bit for backward=20 > > compatibility, in addition=20 > > to a setting that would use the old label withdraw method.=20 > > (but this is an=20 > > implementation detail).=20 > >=20 > >=20 > > I would like to keep this thread concise to this status TLV=20 > > problem , and=20 > > actually conclude it quickly.=20 > >=20 > > Thanks.=20 > > Luca=20 > >=20 > >=20 > >=20 > > ----------------------=20 > > 6. Signaling of Pseudo Wire Link Errors=20 > >=20 > > The signaling mechanisms described in the sections above provide = > > at most a coarse-grained notion of the remote PW's forwarding=20 > > state (via withdrawal of the PW label). However, the use of PW=20 > > label withdrawal to connote interface state has two=20 > shortcomings:=20 > > first, its use is inconsistent among interface types;=20 > for example,=20 > > Ethernet VLAN PWs use label withdrawal to indicate CE interface=20 > > operStatus events, whereas ATM VCC PWs do not. Second,=20 > when label=20 > > withdrawal is used, it often conveys insufficient=20 > > information about=20 > > the type of event that instigated the label withdrawal;=20 > it may be=20 > > due to an unexpected PE-CE interface failure event, for=20 > > example, or=20 > > due to a planned operator change to the PE's configuration.=20 > >=20 > >=20 > > This section details an optional signaling mechanism=20 > > which augments=20 > > the mechanisms described in the sections above and conveys more=20 > > detailed information about pseudo wire link errors.=20 > >=20 > >=20 > > 6.1 Negotiation of Signaling Method=20 > >=20 > > To maintain backward compatibility with baseline PW signaling=20 > > implementations, use of pseudo wire link error (PWLE) signaling=20 > > is negotiated between the two PW peers. If either peer does=20 > > not support the use of PWLE signaling then baseline signaling=20 > > behavior, as described in the above sections, MUST be utilized.=20 > >=20 > >=20 > >=20 > >=20 > > Martini, et al. =20 > > [Page 13]=20 > > > >=20 > > Internet Draft draft-ietf-pwe3-control-protocol-02.txt =20 > > December 2002=20 > >=20 > >=20 > > A PE indicates its desire to utilize PWLE signaling by=20 > setting the=20 > > P bit in the VC Type field to 1, and immediately=20 > signaling its PW=20 > > label to its peer, regardless of the CE-facing interface's=20 > > operational status. The negotiation procedure detailed=20 > > in Appendix=20 > > A MUST be followed to determine the state of the P bit=20 > for the PW.=20 > >=20 > > Once negotiation of the value of the P bit is complete, the PE=20 > > determines its signaling behavior. If the P bit is not=20 > set after=20 > > negotiation, the baseline signaling behavior described in the=20 > > sections above MUST be used. If the P bit is set after=20 > > negotiation, the signaling mechanisms described below MUST be=20 > > used.=20 > >=20 > >=20 > > 6.2 Use of Label Mappings in PWLE Mode=20 > >=20 > > When both peers signal their willingness to participate in PWLE=20 > > mode, the use of label mappings and label withdraws differs=20 > > slightly from the baseline signaling. When in PWLE=20 > mode, PEs MUST=20 > > send PW label mapping messages to their peers as soon=20 > as the PW is=20 > > configured and administratively enabled, regardless of the CE=20 > > interface state. The PW label MUST NOT be withdrawn unless the=20 > > user administratively configures the CE interface down=20 > (or the PW=20 > > configuration is deleted entirely).=20 > >=20 > >=20 > > 6.3 Signaling PW Link Errors in PWLE Mode=20 > >=20 > > When PWLE mode is in use, the PE devices use a new LDP TLV to=20 > > indicate status to their remote peers, instead of=20 > > withdrawing their=20 > > PW FEC labels. This Link Status TLV contains more=20 > > information than=20 > > the simple Label Withdraw message used in the baseline=20 > signaling.=20 > >=20 > > The format of the Link Status TLV is:=20 > >=20 > > 0 1 2 3=20 > > 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 = > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > |1|0| Link Status (0x0700) | Length =20 > |=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > | Status Code |=20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >=20 > > Where status is a 2 octet bit field:=20 > >=20 > > 0x0001 - Pseudo Wire Not Forwarding=20 > > 0x0002 - Local Customer-facing Interface Receive Error=20 > > 0x0004 - Local Customer-facing Interface Transmit Error=20 > > 0x0008 - Local Core-facing Interface Receive Error=20 > > 0x0010 - Local Core-facing Interface Transmit Error=20 > >=20 > > The presence of the lowest bit (PW Not Forwarding) acts=20 > only as a=20 > > summary of the other bit fields, or to convey a link-down=20 > > event for=20 > > which none of the other bits apply.=20 > >=20 > > The Link Status TLV is transported to the remote PW=20 > peer via a new=20 > > LDP message, the PW Link Status Message.=20 > >=20 > >=20 > > Martini, et al. =20 > > [Page 14]=20 > > > >=20 > > Internet Draft draft-ietf-pwe3-control-protocol-02.txt =20 > > December 2002=20 > >=20 > >=20 > > The format of the PW Link Status Message is:=20 > >=20 > > 0 1 2 3=20 > > 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 = > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > |1| PW Link Status (0x0700) | Message Length =20 > |=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > | Message ID =20 > |=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > | PW FEC TLV =20 > |=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > | Link Status TLV =20 > |=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > | Optional Parameters =20 > |=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >=20 > >=20 > > The rationale for using a new LDP message type instead of=20 > > resending=20 > > the PW FEC label mapping with an enclosed Link Status TLV is=20 > > twofold: first, when updating PW link status, there is=20 > no need to=20 > > convey actual label mapping information, and use of the Label=20 > > Mapping message requires the inclusion of a Label TLV. =20 > > Second, and=20 > > more importantly, when a PE's CE-facing interface encounters an=20 > > error, use of the new message allows the PE to send a=20 > single Link=20 > > Status message, using a PW FEC TLV with only the group=20 > ID set, to=20 > > denote this change in status for all affected PW=20 > connections. The=20 > > use of a PW FEC TLV with only group ID set is undefined=20 > for use in=20 > > Label Mapping messages.=20 > >=20 > >=20 > >=20 > > _______________________________________________=20 > > pwe3 mailing list=20 > > pwe3@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/pwe3=20 > >=20 > _______________________________________________=20 > pwe3 mailing list=20 > pwe3@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/pwe3=20 >=20 ------_=_NextPart_001_01C32F64.F4F3EC08 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] status signalling of MPLS PW state
I agree. The capability negotiation should be = nodal.
The shah-extension draft is = backward-compatible=20 with
base signaling draft and does not require any = capability
exchange.
 
/himanshu
-----Original Message-----
From: David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Tuesday, June 10, = 2003 9:59=20 AM
To: Himanshu Shah; Luca Martini; = pwe3@ietf.org
Subject:=20 RE: [PWE3] status signalling of MPLS PW state

Hi:

I think there is a few things not being = considered.=20

1) Not clear that it is useful to negotiate support = on a=20 per-PW basis. Presumably peers learn node behavior and carry it = forward for=20 subsequent transactions. So what is learned from the first PW mapping = attempt=20 should be sticky.

2) Upon a restart of a peer, it may be due to a = software=20 upgrade, so behavior needs to be re-learned.

3) If negotation is part of a label transaction, and = it occurs=20 regardless of the status of the attachement circuit, some unlucky PW = may get=20 to be set up, discover the far end does not support status signalling, = and get=20 promptly torn down again. If during a restart, you are trying to do = multiple=20 mappings, this can be very messy esp if somthing like an ATM OC3 is = down with=20 thousands of VCCs mapping to PWs and that is the first mapping = communicated=20 between peers.

4) Although status signalling is a unique = requirement of PWs=20 (IP uses routing), I do not quite undestand the prohibition from = negotiating=20 support at LDP session establishment. Seems to avoid a lot of race = condition.=20 The only wrinkle being some ACs for which status may not apply at the = present=20 time.

5) The reason code needs some extensions:=20
        - = administratively=20 down
        - loss=20 of peer control plane =
       =20 - phy down =
       =20 - virtual interface (e.g. VCC/DLCI) down

cheers
Dave

> -----Original Message-----
>=20 From: Himanshu Shah [mailto:hshah@wavesmithnetwork= s.com]=20
> Sent: Tuesday, June 10, 2003 9:23 = AM=20
> To: Luca Martini; pwe3@ietf.org =
> Subject: RE: [PWE3] status signalling of MPLS PW = state=20
>
> =
> Luca,
>
> I=20 am glad that you have recognized the need for
>=20 conveying the link status as compared to withdrawing
> the VC-LABEL for the same and Toby has good =
> proposal.
> =
> However, I would like PWE3 to approach this slightly=20
> differently as described in =
> = draft-shah-pwe3-control-protocol-extension-00.txt.=20
>
> We need a = +generic=20 mechanism+ to relay "dynamic
> = attributes" of the=20 PW, including the status of the AC (and
> = yes, it=20 should be AC or PW status as compared to link
>=20 status). The generic mechanism can then be used to extend =
> control signaling without having to constantly change = the base=20 draft.
>
> = The extension=20 draft proposes that such PW attributes
> = be=20 included in "optional parameter" field of the Label
> mapping message. The advantage of this approach = is,=20
>
> 1) conveying of = one or more=20 dynamic attributes in a
>      single label mapping = message.=20 Extension draft describes
>      IP addr (needed for = ARP-mediation) ,=20 IP+MAC addr (needed
>     =20 for IPLS), QOS, tunnel mechanisms used, etc TLVs.
>=20 2) a way to include these attributes in first mapping msg =
>      as compared to a follow-on = status=20 msgs (for example,
>     =20 PE does not know the status of the remote AC until
>     link status msg follows the = initial label=20 mapping msg)
> 3) allows update of the = attributes.=20 When dynamic attribute
>    =20 changes, an update is sent without withdrawing the VC-FEC =
> 4 ) allows definitions of new attributes without =
>       modifying base LDP = or martini=20 signaling draft
>
> I=20 would like PWE3 to consider this approach.
>=20
> /himanshu
> wavesmith=20 networks
>     =20
>
> =
>
> > -----Original=20 Message-----
> > From: Luca Martini = [mailto:luca@level3.net] =
> > Sent: Monday, June 09, 2003 3:01 PM =
> > To: pwe3@ietf.org
> = > Subject:=20 [PWE3] status signalling of MPLS PW state
> >=20
> >
> = > WG,=20
> >
> > The = text below=20 was sent to me by Toby Smith as a proposal to
>=20 > resolve some
> > shortcomings of = the =20 label withdraw signaling method
> > = currently in=20 the control
> > WG document. =
> >
> > I do not agree = with the=20 negotiation part, but I think that
> > = the=20 status TLV has
> > merit, and we = should use the=20 ignore bit for backward
> > = compatibility, in=20 addition
> > to a setting that would = use the old=20 label withdraw method.
> > (but this = is an=20
> > implementation detail). =
> >
> > =
> > I would like to keep this thread concise to this = status=20 TLV
> > problem , and
> > actually conclude it quickly.
>=20 >
> > Thanks.
>=20 > Luca
> >
> >=20
> >
> = >=20 ----------------------
> > 6. = Signaling of=20 Pseudo Wire Link Errors
> > =
> >     The signaling mechanisms = described in=20 the sections above provide
>=20 >     at most a coarse-grained notion of the = remote=20 PW's forwarding
> = >    =20 state (via withdrawal of the PW label).  However, the use of = PW=20
> >     label withdrawal = to connote=20 interface state has two
> = shortcomings:=20
> >     first, its use is = inconsistent among interface types;
> for = example,
> >     = Ethernet=20 VLAN PWs use label withdrawal to indicate CE interface =
> >     operStatus events, whereas = ATM VCC=20 PWs do not.  Second,
> when = label=20
> >     withdrawal is = used, it=20 often conveys insufficient
> > = information=20 about
> >     the = type of=20 event that instigated the label withdrawal;
> it=20 may be
> >     due = to an=20 unexpected PE-CE interface failure event, for
>=20 > example, or
> = >     due=20 to a planned operator change to the PE's configuration. =
> >
> > =
> >     This section details an = optional=20 signaling mechanism
> > which = augments=20
> >     the mechanisms = described in=20 the sections above and conveys more
>=20 >     detailed information about pseudo wire = link=20 errors.
> >
> >=20
> > 6.1 Negotiation of Signaling = Method=20
> >
>=20 >     To maintain backward compatibility with = baseline=20 PW signaling
> = >    =20 implementations, use of pseudo wire link error (PWLE) signaling =
> >     is negotiated = between the=20 two PW peers.  If either peer does
> = >     not support the use of PWLE signaling = then=20 baseline signaling
> = >    =20 behavior, as described in the above sections, MUST be utilized. =
> >
> > =
> >
> > =
> > Martini, et=20 = al.           &nbs= p;            = ;            =           =20
> >  [Page 13]
>=20 > > >
> > Internet = Draft =20 draft-ietf-pwe3-control-protocol-02.txt    =
> > December 2002
> >=20
> >
>=20 >     A PE indicates its desire to utilize PWLE = signaling by
> setting the =
> >     P bit in the VC Type field = to 1, and=20 immediately
> signaling its PW =
> >     label to its peer, = regardless of the=20 CE-facing interface's
>=20 >     operational status.  The negotiation = procedure detailed
> > in = Appendix=20
> >     A MUST be = followed to=20 determine the state of the P bit
> for = the=20 PW.
> >
> = >     Once negotiation of the value of the P = bit is=20 complete, the PE
> = >    =20 determines its signaling behavior.  If the P bit is not =
> set after
>=20 >     negotiation, the baseline signaling = behavior=20 described in the
> = >    =20 sections above MUST be used.  If the P bit is set after =
> >     negotiation, the signaling = mechanisms=20 described below MUST be
>=20 >     used.
> > =
> >
> = > 6.2 Use of=20 Label Mappings in PWLE Mode
> > =
> >     When both peers signal = their=20 willingness to participate in PWLE
>=20 >     mode, the use of label mappings and label = withdraws differs
> = >    =20 slightly from the baseline signaling.  When in PWLE =
> mode, PEs MUST
>=20 >     send PW label mapping messages to their = peers as=20 soon
> as the PW is
>=20 >     configured and administratively enabled,=20 regardless of the CE
> = >    =20 interface state.  The PW label MUST NOT be withdrawn unless = the=20
> >     user = administratively=20 configures the CE interface down
> (or = the=20 PW
> >     = configuration is=20 deleted entirely).
> > =
> >
> > 6.3 Signaling = PW Link=20 Errors in PWLE Mode
> > =
> >     When PWLE mode is in use, = the PE=20 devices use a new LDP TLV to
>=20 >     indicate status to their remote peers, = instead=20 of
> > withdrawing their =
> >     PW FEC labels.  This = Link Status=20 TLV contains more
> > information = than=20
> >     the simple Label = Withdraw=20 message used in the baseline
> = signaling.=20
> >
>=20 >     The format of the Link Status TLV = is:=20
> >
>=20 >     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
> >      0 = 1 2 3 4 5=20 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
> >    
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >     |1|0|   = Link=20 Status (0x0700)    |     =20 Length          =20
>        =20 |
> >     =
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >    =20 |         Status=20 Code           = |=20
> >    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >=20
> >     Where = status is a 2=20 octet bit field:
> >
> >      0x0001 - Pseudo Wire = Not=20 Forwarding
> = >     =20 0x0002 - Local Customer-facing Interface Receive Error =
> >      0x0004 - Local = Customer-facing=20 Interface Transmit Error
>=20 >      0x0008 - Local Core-facing = Interface=20 Receive Error
> = >     =20 0x0010 - Local Core-facing Interface Transmit Error
> >
> = >     The=20 presence of the lowest bit (PW Not Forwarding) acts
> only as a
>=20 >     summary of the other bit fields, or to = convey a=20 link-down
> > event for =
> >     which none of the other = bits=20 apply.
> >
>=20 >     The Link Status TLV is transported to the = remote=20 PW
> peer via a new
>=20 >     LDP message, the PW Link Status = Message.=20
> >
> > =
> > Martini, et=20 = al.           &nbs= p;            = ;            =           =20
> >  [Page 14]
>=20 > > >
> > Internet = Draft =20 draft-ietf-pwe3-control-protocol-02.txt    =
> > December 2002
> >=20
> >
>=20 >     The format of the PW Link Status Message=20 is:
> >
> = >     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
> >      0 = 1 2 3 4 5=20 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
> >    
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >     |1|   = PW Link=20 Status (0x0700)   |      Message=20 Length  
>         | =
> >    
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >    =20 = |            =             &= nbsp; =20 Message=20 = ID            = ;     =20
>        =20 |
> >     =
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >    =20 = |            =             &= nbsp; =20 PW FEC=20 = TLV           &nbs= p;     =20
>        =20 |
> >     =
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >    =20 = |            =              = Link Status=20 = TLV           &nbs= p;  =20
>        =20 |
> >     =
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >    =20 = |            =          =20 Optional=20 = Parameters          &nb= sp;  =20
>        =20 |
> >     =
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
> >
> > =
> >     The rationale for using a = new LDP=20 message type instead of
> > = resending=20
> >     the PW FEC label = mapping=20 with an enclosed Link Status TLV is
>=20 >     twofold: first, when updating PW link = status,=20 there is
> no need to
>=20 >     convey actual label mapping information, = and use=20 of the Label
> = >     Mapping=20 message requires the inclusion of a Label TLV. 
> > Second, and
>=20 >     more importantly, when a PE's CE-facing = interface=20 encounters an
> = >     error,=20 use of the new message allows the PE to send a
>=20 single Link
> = >     Status=20 message, using a PW FEC TLV with only the group
>=20 ID set, to
> >     = denote=20 this change in status for all affected PW
>=20 connections.  The
>=20 >     use of a PW FEC TLV with only group ID = set is=20 undefined
> for use in
>=20 >     Label Mapping messages.
> >
> > =
> >
> >=20 _______________________________________________
>=20 > pwe3 mailing list
> > = pwe3@ietf.org=20
> > https://www1.ietf.org/mailman/listinfo/pwe3 =
> >
>=20 _______________________________________________
>=20 pwe3 mailing list
> pwe3@ietf.org =
> https://www1.ietf.org/mailman/listinfo/pwe3 =
>

------_=_NextPart_001_01C32F64.F4F3EC08-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Tue, 10 Jun 2003 11:29:48 -0400 Lines: 53 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F65.20B7BAA0" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 10 17:38:02 2003 Return-path: To: Mark Seery , Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C32F65.20B7BAA0 Content-Type: text/plain; charset="iso-8859-1" Mark, > > In addition, I would be interested to know if operators would like > information on the type of link error, and if yes, maybe a field where > vendors can place a description code. > I agree. It is beneficial to know the nature of the error. Something like diagnostic code-description needs to be supported. Hamid. ------_=_NextPart_001_01C32F65.20B7BAA0 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] status signalling of MPLS PW state

Mark,

>
> In addition, I would be interested to know if operators would like
> information on the type of link error, and if yes, maybe a field where
> vendors can place a description code.
>

I agree. It is beneficial to know the nature of the error. Something
like diagnostic code-description needs to be supported.

Hamid.

------_=_NextPart_001_01C32F65.20B7BAA0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: PWE Service interworking Date: Tue, 10 Jun 2003 15:19:35 -0400 Lines: 78 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F85.3A6AC03A" Cc: erosen@cisco.com, Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 10 21:23:57 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 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_01C32F85.3A6AC03A Content-Type: text/plain; charset="iso-8859-1" Mustapha, > > > > b) For the case where the provider has upgraded his l2 network > > to MPLS/IP and the native l2 services are replaced with PWs, > > can the provider guarantee/assume in all cases that the traffic > > is always IP, or can he assumes that on any given PW there is > > no case where both IP and non IP traffic are being sent (since > > the upgraded service initially didn't make that assumption, > > or maybe the provider can't tell whether it is always > > IP since it doesn't control customer devices)? > > This is the case that requires the most attention. One of my > customer's customers runs IPX and IP over the same FR connection. > Also, some ISPs buy leased line service from a SP to connect their > POPs. Today, they use FR and ATM. That one connection can carry IP > and CLNP (for IS-IS). > Although IP might be the dominant protocol in volume, many of the > existing L2 VPN services have a small amount of other protocols. > That is why if one terminates each L2 locally at a PE in service > interworking between different link layers (e.g., FR-MPLS-Ethernet), > then there is a need to identify multiple protocols in the same PW > or LSP. > Agreed. For these cases a multiprotocol approach is required. Hamid. ------_=_NextPart_001_01C32F85.3A6AC03A Content-Type: text/html; charset="iso-8859-1"

Mustapha,

> >
> > b) For the case where the provider has upgraded his l2 network
> >    to MPLS/IP and the native l2 services are replaced with PWs,
> >    can the provider guarantee/assume in all cases that the traffic
> >    is always IP, or can he assumes that on any given PW there is
> >    no case where both IP and non IP traffic are being sent (since
> >    the upgraded service initially didn't make that assumption,
> >    or maybe the provider can't tell whether it is always
> >    IP since it doesn't control customer devices)?
>
> This is the case that requires the most attention. One of my
> customer's customers runs IPX and IP over the same FR connection.
> Also, some ISPs buy leased line service from a SP to connect their
> POPs. Today, they use FR and ATM. That one connection can carry IP
> and CLNP (for IS-IS).
> Although IP might be the dominant protocol in volume, many of the
> existing L2 VPN services have a small amount of other protocols.
> That is why if one terminates each L2 locally at a PE in service
> interworking between different link layers (e.g., FR-MPLS-Ethernet),
> then there is a need to identify multiple protocols in the same PW
> or LSP.
>

Agreed. For these cases a multiprotocol approach is required.

Hamid.



 ------_=_NextPart_001_01C32F85.3A6AC03A-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Tue, 10 Jun 2003 18:03:49 -0600 Organization: Level3 Communications LLC. Lines: 78 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 11 02:14:25 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: Mark Seery 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 Mark Seery wrote: > Hi Luca, > > >>>Luca: I do not agree with the negotiation part, but I think that the >> > status TLV has merit, and we should use the ignore bit for backward > compatibility, in addition to a setting that would use the old label > withdraw method. (but this is > an implementation detail)....<< > > Not sure I understand your comment. > not having a label mapping means that the PW has not yet been configured , which is almost equivalent to saying it is down. I think that we can say that if the label mapping is withdrawn , the PW is down for backward compatibility. So should new implementations not be required to do a label withdraw ? I think yes. and an optional feature could be to also support configuration of the old method. > The following specifies a way to indicate that the old label withdraw method > is indicated (though could be more explicit I suppose) "If the P bit is not > set after negotiation, the baseline signaling behavior described in the > sections above MUST be used. If the P bit is set after negotiation, the > signaling mechanisms described below MUST be used. " > > So is your comment simply that you agree with this, but "ignore bit" should > be used in addition? > I was not clear. I think that the negotiation is an unnecessary complication. I think that the ignore bit should be set so that we remain compatible with old martini implementations ( save for the status signaling ). > ======== > > In addition.... > > Not sure if you were looking for feed back on status codes, but........for > the sake of those that come after us, I find the terms a little confusing. > Clearly by the title of the section there is an intent to signal PW link > errors, but also an indication to signal link status, as denoted by the TLV > name. So maybe two different concepts got mixed up in one mechanism or > perhaps I am just being pedantic, but it would seem that a link error and a > link status are not the same thing. > yes I think that I might have to reword this somewhat. let us call this link failure, and remove the error references. I still think that this is a status message as in the LDP status message definition (rfc3036). > For example, one might expect a link status to be: up, down, initializing, > quiescing (sp?), forwarding, blocked, whatever.....whereas "Local > Customer-facing Interface Receive Error" seems more like an event, a > counter, or a reason code for a status code. > > Now I suppose the setting of the lowest bit is a "status code" of types (the > summary comment not withstanding), and if forwarding/not forwarding are the > only two states a link can be in, then that is fine. If a link can be in > other states, seems like a more generalized format might be useful for the > long term/or the TLV should be called something like "Link Error TLV" > instead. > > In addition, I would be interested to know if operators would like > information on the type of link error, and if yes, maybe a field where > vendors can place a description code. > > Mark > I'll think about it. Luca From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mark Seery Subject: RE: status signalling of MPLS PW state Date: Tue, 10 Jun 2003 18:02:35 -0700 (PDT) Lines: 50 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, Luca Martini X-From: pwe3-admin@ietf.org Wed Jun 11 03:05:21 2003 Return-path: To: Hamid Ould-Brahim 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 Hamid. I agree as a general principle it is good to know why an error has occurred. But in mulling this over since I first wrote it, it occurs to me that it might depend on where/why the error is communicated. For example, the full link error information could be communicated via the management plane - if an operator really needs to know. I guess the real question is why is the control plane being asked to communicate this information from one LDP peer to the other. Is it because it expects the LDP peer to take some action? If so, then simply knowing there has been an error+forwarding status might be enough. If the extra information can not be used by the control plane, then it probably doesn't make sense to carry it around, we are just complicating the implemenation. Bottom line is I am not sure I understand what the intended consequences/actions are of the LDP peer receiving this information, so now not sure what is sufficient information or not. Perhaps Luca could give some background, or perhaps it is simply an implementation decision what to do with the new knowledge that the other end of a PW has experienced a failure. mark --- Hamid Ould-Brahim wrote: > Mark, > > > > > In addition, I would be interested to know if > operators would like > > information on the type of link error, and if yes, > maybe a field where > > vendors can place a description code. > > > > I agree. It is beneficial to know the nature of the > error. Something > like diagnostic code-description needs to be > supported. > > Hamid. > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Mark Seery" Subject: RE: status signalling of MPLS PW state Date: Tue, 10 Jun 2003 21:38:42 -0700 Lines: 20 Sender: pwe3-admin@ietf.org References: <3EE671E5.1020700@level3.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Wed Jun 11 06:43:41 2003 Return-path: To: "Luca Martini" 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: <3EE671E5.1020700@level3.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 Hi Luca, [snip] >>> I still think that this is a status message as in the LDP status message definition (rfc3036). << If this is an advisory notification associated with a previous message/notification, then I agree it meets the definition specified in the LDP spec. (3036). So in the context of say a previous link error notification, then calling it a link status TLV makes sense, WRT to 3036 definition. However, the question I would ask is if sometime in the future (if not already in existance) we wanted to create a "status" message in response to a link state change event/notification, what would that TLV be called. Perhaps it can be the same thing. So understand you are operating within the context of 3036, and the terminology it uses. Best, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 08:16:48 -0700 Lines: 178 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Wed Jun 11 17:29:13 2003 Return-path: To: "'Luca Martini'" , 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 Where is the P-bit defined? -Shahram >-----Original Message----- >From: Luca Martini [mailto:luca@level3.net] >Sent: Monday, June 09, 2003 3:01 PM >To: pwe3@ietf.org >Subject: [PWE3] status signalling of MPLS PW state > > >WG, > >The text below was sent to me by Toby Smith as a proposal to >resolve some >shortcomings of the label withdraw signaling method currently >in the control >WG document. > >I do not agree with the negotiation part, but I think that the >status TLV has >merit, and we should use the ignore bit for backward >compatibility, in addition >to a setting that would use the old label withdraw method. >(but this is an >implementation detail). > > >I would like to keep this thread concise to this status TLV >problem , and >actually conclude it quickly. > >Thanks. >Luca > > > >---------------------- >6. Signaling of Pseudo Wire Link Errors > > The signaling mechanisms described in the sections above provide > at most a coarse-grained notion of the remote PW's forwarding > state (via withdrawal of the PW label). However, the use of PW > label withdrawal to connote interface state has two shortcomings: > first, its use is inconsistent among interface types; for example, > Ethernet VLAN PWs use label withdrawal to indicate CE interface > operStatus events, whereas ATM VCC PWs do not. Second, when label > withdrawal is used, it often conveys insufficient information about > the type of event that instigated the label withdrawal; it may be > due to an unexpected PE-CE interface failure event, for example, or > due to a planned operator change to the PE's configuration. > > > This section details an optional signaling mechanism which augments > the mechanisms described in the sections above and conveys more > detailed information about pseudo wire link errors. > > >6.1 Negotiation of Signaling Method > > To maintain backward compatibility with baseline PW signaling > implementations, use of pseudo wire link error (PWLE) signaling > is negotiated between the two PW peers. If either peer does > not support the use of PWLE signaling then baseline signaling > behavior, as described in the above sections, MUST be utilized. > > > > >Martini, et al. >[Page 13] > > >Internet Draft draft-ietf-pwe3-control-protocol-02.txt >December 2002 > > > A PE indicates its desire to utilize PWLE signaling by setting the > P bit in the VC Type field to 1, and immediately signaling its PW > label to its peer, regardless of the CE-facing interface's > operational status. The negotiation procedure detailed in Appendix > A MUST be followed to determine the state of the P bit for the PW. > > Once negotiation of the value of the P bit is complete, the PE > determines its signaling behavior. If the P bit is not set after > negotiation, the baseline signaling behavior described in the > sections above MUST be used. If the P bit is set after > negotiation, the signaling mechanisms described below MUST be > used. > > >6.2 Use of Label Mappings in PWLE Mode > > When both peers signal their willingness to participate in PWLE > mode, the use of label mappings and label withdraws differs > slightly from the baseline signaling. When in PWLE mode, PEs MUST > send PW label mapping messages to their peers as soon as the PW is > configured and administratively enabled, regardless of the CE > interface state. The PW label MUST NOT be withdrawn unless the > user administratively configures the CE interface down (or the PW > configuration is deleted entirely). > > >6.3 Signaling PW Link Errors in PWLE Mode > > When PWLE mode is in use, the PE devices use a new LDP TLV to > indicate status to their remote peers, instead of withdrawing their > PW FEC labels. This Link Status TLV contains more information than > the simple Label Withdraw message used in the baseline signaling. > > The format of the Link Status TLV is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| Link Status (0x0700) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Where status is a 2 octet bit field: > > 0x0001 - Pseudo Wire Not Forwarding > 0x0002 - Local Customer-facing Interface Receive Error > 0x0004 - Local Customer-facing Interface Transmit Error > 0x0008 - Local Core-facing Interface Receive Error > 0x0010 - Local Core-facing Interface Transmit Error > > The presence of the lowest bit (PW Not Forwarding) acts only as a > summary of the other bit fields, or to convey a link-down event for > which none of the other bits apply. > > The Link Status TLV is transported to the remote PW peer via a new > LDP message, the PW Link Status Message. > > >Martini, et al. >[Page 14] > > >Internet Draft draft-ietf-pwe3-control-protocol-02.txt >December 2002 > > > The format of the PW Link Status Message is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| PW Link Status (0x0700) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW FEC TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Link Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional Parameters | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The rationale for using a new LDP message type instead of resending > the PW FEC label mapping with an enclosed Link Status TLV is > twofold: first, when updating PW link status, there is no need to > convey actual label mapping information, and use of the Label > Mapping message requires the inclusion of a Label TLV. Second, and > more importantly, when a PE's CE-facing interface encounters an > error, use of the new message allows the PE to send a single Link > Status message, using a PW FEC TLV with only the group ID set, to > denote this change in status for all affected PW connections. The > use of a PW FEC TLV with only group ID set is undefined for use in > Label Mapping messages. > > > >_______________________________________________ >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: Shahram Davari Subject: RE: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 11 Jun 2003 08:32:02 -0700 Lines: 177 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Israel Sasson , Akiva Sadovski , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Wed Jun 11 17:40:56 2003 Return-path: To: "'Sasha Vainshtein'" , "Stewart Bryant (E-mail)" , "Danny McPherson (E-mail)" , "PWE3 WG (E-mail)" 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, Could you please explain the setup used fo the first interop bullet. Did you interoperate with TDMoIP? -Shahram >-----Original Message----- >From: Sasha Vainshtein [mailto:Sasha@axerra.com] >Sent: Tuesday, June 10, 2003 12:13 PM >To: Stewart Bryant (E-mail); Danny McPherson (E-mail); PWE3 WG (E-mail) >Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim >Frost (E-mail); Prayson Pate (E-mail) >Subject: [PWE3] FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > >Stewart, Danny and all, >As (some of) you have probably noticed I have posted an >updated (-06) revision of the CESoPSN draft. > >I would like to ask the WG to adopt this draft as a WG item, >and this message is intended to initiate a TECHNICAL discussion >on this subject. > > >Allow me to present my major points wrt the -06 revision: > >Compatibility with the Requirements and Architecture Documents >============================================================== > >The -06 revision of the draft explicitly answers the following >requirements: > >1. The requirements stated in the WG Charter >2. Common PWE3 requirements as stated in >draft-ietf-pwe3-requirements-05.txt >3. Specific requirements for emulation of TDM services as stated in > draft-ietf-pwe3-tdm-requirements-00.txt >4. The PWE3 architectural principles as presented in >draft-ietf-pwe3-arch-03.txt. >5. Additional requirements that have been identified during discussions > in the WG and in the (unpublished) disucssions of the TDM >design team, > including ability to preserve packetization latency regardless of > the bit rate of the emulated Nx64 kbit/s service > >Formerly Raised Technical Issues >================================ > >The -06 revision of the draft addresses all the technical isssue >that have ever been raised with the previous revisions. In particular: > >1. It allows BW-saving suppression of RTP headers when the > information carried in these headers cannot contribute > to the truthfulness of the emulation >2. It defines a new mode for carrying trunk-specific Nx64 > kbit/s services with CAS which: > a) Does not mandate usage of RTP for synchronization between > TDM data and telephony application signaling > b) Does not break the principle of fixed packetization time > for emulation of TDM services >3. It defines, as mandatory, raw encapsulation of unstructured T1 > without any intermediate adaptation. > >Independent Interoperable Implementations >========================================= > >A series of successful interoperability tests between >independent CESoPSN implementations has been completed lately. >The following ones have been publicly announced: > >1. http://www.rad.com/Article/0,6583,13305,00.html >2. http://www.axerra.com/pr15.html >3. http://www.axerra.com/pr16.html >4. http://www.reduxcom.com/News/Issues/030527_WiMark/index.html > > >I would like to ask the WG participants to break their silence and >to provide the input that is required to advance the subject of >TDM emulation over PSN in the WG. > >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > >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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Monday, June 09, 2003 1:45 PM >> Cc: midcom@ietf.org >> Subject: I-D ACTION:draft-vainshtein-cesopsn-06.txt >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> >> Title : TDM Circuit Emulation Service over >> Packet Switched >> Network (CESoPSN) >> Author(s) : S. Vainshtein et al. >> Filename : draft-vainshtein-cesopsn-06.txt >> Pages : 38 >> Date : 2003-6-6 >> >> This document describes a method for encapsulating >unstructured (T1, >> E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over >> packet-switching networks (PSN). In this regard, it >> complements similar >> work for SONET/SDH. >> >> Proposed PW encapsulation uses RTP for clock recovery and leverages >> RTP-based mixing capabilities for application state >signaling between >> Customer Edge (CE) devices. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt >> >> To remove yourself from the IETF Announcement list, send a >message to >> ietf-announce-request with the word unsubscribe in the body >> of the message. >> >> Internet-Drafts are also available by anonymous FTP. Login >> with the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-vainshtein-cesopsn-06.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-vainshtein-cesopsn-06.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >_______________________________________________ >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: Shahram Davari Subject: Control draft comments Date: Wed, 11 Jun 2003 08:50:31 -0700 Lines: 60 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33030.E216A366" X-From: pwe3-admin@ietf.org Wed Jun 11 17:57:17 2003 Return-path: To: "PWE3 WG (E-mail)" X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33030.E216A366 Content-Type: text/plain; charset="iso-8859-1" Hi, The following sentences need correction in the control draft: - SAII, encoded as a one byte length field followed by the SAI. - TAII, encoded as a one byte length field followed by the TAI. SAI and TAI need to be changed to SAII and TAII. Thanks, -Shahram ------_=_NextPart_001_01C33030.E216A366 Content-Type: text/html; charset="iso-8859-1"
Hi,
 
The following sentences need correction in the control draft:
 
     - SAII, encoded as a one byte length field followed by the SAI.

     - TAII, encoded as a one byte length field followed by the TAI.
 
SAI and TAI need to be changed to SAII and TAII.
 
Thanks,
 
-Shahram


 ------_=_NextPart_001_01C33030.E216A366-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 10:57:45 -0600 Organization: Level3 Communications LLC. Lines: 32 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 11 19:11:02 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: Hamid Ould-Brahim Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hamid Ould-Brahim wrote: > Mark, > > > > > In addition, I would be interested to know if operators would like > > information on the type of link error, and if yes, maybe a field where > > vendors can place a description code. > > > > I agree. It is beneficial to know the nature of the error. Something > like diagnostic code-description needs to be supported. > > Hamid. > Let's make the distinction between reporting an error to the operator , and the need to send the specific cause in the protocol. There is no doubt that the nature of the error has to be reported to the operator, but the specifics need only be reported by the PE that is experiencing the problem. So for example , as PW might be down because the local PE is out of buffer memory. The message to the remote PE can simply be 0x0001 - Pseudo Wire Not Forwarding. Yet the message sent, by the local PE, as a SNMP trap or to syslog, can be "Pseudo Wire Not Forwarding out of buffer memory". There is an assumption here that some operator will monitor both sides. Luca From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 11:02:29 -0600 Organization: Level3 Communications LLC. Lines: 192 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C9C7@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 11 19:13:57 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: 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, It is not, this is just a starting point. P means "i want to use the status TLV" I don't think it is necessary. I'll send revised text soon. Luca Shahram Davari wrote: > Where is the P-bit defined? > > -Shahram > > >>-----Original Message----- >>From: Luca Martini [mailto:luca@level3.net] >>Sent: Monday, June 09, 2003 3:01 PM >>To: pwe3@ietf.org >>Subject: [PWE3] status signalling of MPLS PW state >> >> >>WG, >> >>The text below was sent to me by Toby Smith as a proposal to >>resolve some >>shortcomings of the label withdraw signaling method currently >>in the control >>WG document. >> >>I do not agree with the negotiation part, but I think that the >>status TLV has >>merit, and we should use the ignore bit for backward >>compatibility, in addition >>to a setting that would use the old label withdraw method. >>(but this is an >>implementation detail). >> >> >>I would like to keep this thread concise to this status TLV >>problem , and >>actually conclude it quickly. >> >>Thanks. >>Luca >> >> >> >>---------------------- >>6. Signaling of Pseudo Wire Link Errors >> >> The signaling mechanisms described in the sections above provide >> at most a coarse-grained notion of the remote PW's forwarding >> state (via withdrawal of the PW label). However, the use of PW >> label withdrawal to connote interface state has two shortcomings: >> first, its use is inconsistent among interface types; for example, >> Ethernet VLAN PWs use label withdrawal to indicate CE interface >> operStatus events, whereas ATM VCC PWs do not. Second, when label >> withdrawal is used, it often conveys insufficient information about >> the type of event that instigated the label withdrawal; it may be >> due to an unexpected PE-CE interface failure event, for example, or >> due to a planned operator change to the PE's configuration. >> >> >> This section details an optional signaling mechanism which augments >> the mechanisms described in the sections above and conveys more >> detailed information about pseudo wire link errors. >> >> >>6.1 Negotiation of Signaling Method >> >> To maintain backward compatibility with baseline PW signaling >> implementations, use of pseudo wire link error (PWLE) signaling >> is negotiated between the two PW peers. If either peer does >> not support the use of PWLE signaling then baseline signaling >> behavior, as described in the above sections, MUST be utilized. >> >> >> >> >>Martini, et al. >>[Page 13] >> > >>Internet Draft draft-ietf-pwe3-control-protocol-02.txt >>December 2002 >> >> >> A PE indicates its desire to utilize PWLE signaling by setting the >> P bit in the VC Type field to 1, and immediately signaling its PW >> label to its peer, regardless of the CE-facing interface's >> operational status. The negotiation procedure detailed in Appendix >> A MUST be followed to determine the state of the P bit for the PW. >> >> Once negotiation of the value of the P bit is complete, the PE >> determines its signaling behavior. If the P bit is not set after >> negotiation, the baseline signaling behavior described in the >> sections above MUST be used. If the P bit is set after >> negotiation, the signaling mechanisms described below MUST be >> used. >> >> >>6.2 Use of Label Mappings in PWLE Mode >> >> When both peers signal their willingness to participate in PWLE >> mode, the use of label mappings and label withdraws differs >> slightly from the baseline signaling. When in PWLE mode, PEs MUST >> send PW label mapping messages to their peers as soon as the PW is >> configured and administratively enabled, regardless of the CE >> interface state. The PW label MUST NOT be withdrawn unless the >> user administratively configures the CE interface down (or the PW >> configuration is deleted entirely). >> >> >>6.3 Signaling PW Link Errors in PWLE Mode >> >> When PWLE mode is in use, the PE devices use a new LDP TLV to >> indicate status to their remote peers, instead of withdrawing their >> PW FEC labels. This Link Status TLV contains more information than >> the simple Label Withdraw message used in the baseline signaling. >> >> The format of the Link Status TLV is: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1|0| Link Status (0x0700) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status Code | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Where status is a 2 octet bit field: >> >> 0x0001 - Pseudo Wire Not Forwarding >> 0x0002 - Local Customer-facing Interface Receive Error >> 0x0004 - Local Customer-facing Interface Transmit Error >> 0x0008 - Local Core-facing Interface Receive Error >> 0x0010 - Local Core-facing Interface Transmit Error >> >> The presence of the lowest bit (PW Not Forwarding) acts only as a >> summary of the other bit fields, or to convey a link-down event for >> which none of the other bits apply. >> >> The Link Status TLV is transported to the remote PW peer via a new >> LDP message, the PW Link Status Message. >> >> >>Martini, et al. >>[Page 14] >> > >>Internet Draft draft-ietf-pwe3-control-protocol-02.txt >>December 2002 >> >> >> The format of the PW Link Status Message is: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1| PW Link Status (0x0700) | Message Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PW FEC TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Link Status TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Optional Parameters | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> The rationale for using a new LDP message type instead of resending >> the PW FEC label mapping with an enclosed Link Status TLV is >> twofold: first, when updating PW link status, there is no need to >> convey actual label mapping information, and use of the Label >> Mapping message requires the inclusion of a Label TLV. Second, and >> more importantly, when a PE's CE-facing interface encounters an >> error, use of the new message allows the PE to send a single Link >> Status message, using a PW FEC TLV with only the group ID set, to >> denote this change in status for all affected PW connections. The >> use of a PW FEC TLV with only group ID set is undefined for use in >> Label Mapping messages. >> >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 11:07:54 -0600 Organization: Level3 Communications LLC. Lines: 71 Sender: pwe3-admin@ietf.org References: <20030611010235.95243.qmail@web13504.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Hamid Ould-Brahim , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 11 19:19:26 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: Mark Seery 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 Mark, There are a couple of reasons: the remote PE probably want to take action to notify the attached CE that the PW is broken.( Frame ILMI in the NNI case, or ATM OAM if the PW is broken , but the control plane still works ) the PE might want to take such action as attempting to bypass the issue maybe by using an alternate route or PW. Also the remote PE might want to keep track of how long the PW is in the down state. Luca Mark Seery wrote: > Thanks Hamid. > > I agree as a general principle it is good to know why > an error has occurred. But in mulling this over since > I first wrote it, it occurs to me that it might depend > on where/why the error is communicated. > > For example, the full link error information could be > communicated via the management plane - if an operator > really needs to know. I guess the real question is why > is the control plane being asked to communicate this > information from one LDP peer to the other. Is it > because it expects the LDP peer to take some action? > If so, then simply knowing there has been an > error+forwarding status might be enough. If the extra > information can not be used by the control plane, then > it probably doesn't make sense to carry it around, we > are just complicating the implemenation. > > Bottom line is I am not sure I understand what the > intended consequences/actions are of the LDP peer > receiving this information, so now not sure what is > sufficient information or not. > > Perhaps Luca could give some background, or perhaps it > is simply an implementation decision what to do with > the new knowledge that the other end of a PW has > experienced a failure. > > mark > > --- Hamid Ould-Brahim > wrote: > >>Mark, >> >> >>>In addition, I would be interested to know if >> >>operators would like >> >>>information on the type of link error, and if yes, >> >>maybe a field where >> >>>vendors can place a description code. >>> >> >>I agree. It is beneficial to know the nature of the >>error. Something >>like diagnostic code-description needs to be >>supported. >> >>Hamid. >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: Control draft comments Date: Wed, 11 Jun 2003 11:09:26 -0600 Organization: Level3 Communications LLC. Lines: 14 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115C9C9@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Wed Jun 11 19:22:23 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: 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 thanks! I'm editing this draft this week, and plan to send it to the list for comments before publishing the revision. Luca Shahram Davari wrote: > Hi, The following sentences need correction in the control draft: > - SAII, encoded as a one byte length field followed by the SAI. > > - TAII, encoded as a one byte length field followed by the TAI. > SAI and TAI need to be changed to SAII and TAII. Thanks, -Shahram > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 13:20:24 -0400 Lines: 108 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3303D.BE656922" Cc: Mark Seery , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 11 19:26:39 2003 Return-path: To: Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C3303D.BE656922 Content-Type: text/plain; charset="iso-8859-1" Luca, > Let's make the distinction between reporting an error to the > operator , and > the need to send the specific cause in the protocol. > There is no doubt that the nature of the error has to be > reported to the > operator, but the specifics need only be reported by the PE that is > experiencing the problem. > > So for example , as PW might be down because the local PE is > out of buffer > memory. The message to the remote PE can simply be 0x0001 > - Pseudo Wire Not > Forwarding. > Yet the message sent, by the local PE, as a SNMP trap or to > syslog, can be > "Pseudo Wire Not Forwarding out of buffer memory". > Yes. But I think there may be other reasons that can help the remote PE to make some policy decisions. For example ability to trigger a backup scenario for some type of reasons compared to others (for resiliency purposes). Reasons can be link/port failure, administrative operation, protocol down (if any is used between ce-pe), etc. Besides, although not explictely mentioned in the draft, there were some additions to the control draft before that were motivated by the ability to support SVC (dynamic PW) case (among other reasons). I assume for these types as well a reason maybe required by the protocol used in signaling. Hamid. > There is an assumption here that some operator will monitor > both sides. > > > Luca > > > ------_=_NextPart_001_01C3303D.BE656922 Content-Type: text/html; charset="iso-8859-1" Luca,

> Let's make the distinction between reporting an error  to the
> operator , and
> the need to send the specific cause in the protocol.
> There is no doubt that the nature of the error has to be
> reported to the
> operator, but the specifics need only be reported by the PE that is
> experiencing the problem.
>
> So for example , as PW might be down because the local PE is
> out of buffer
> memory. The message to the remote PE can simply be     0x0001
> - Pseudo Wire Not
> Forwarding.
> Yet the message sent, by the local PE, as a SNMP trap or to
> syslog, can be
> "Pseudo Wire Not Forwarding out of buffer memory".
>

Yes. But I think there may be other reasons that can help the
remote PE to make some policy decisions. For example ability to
trigger a backup scenario for some type of reasons compared to others
(for resiliency purposes). Reasons can be link/port failure,
administrative operation, protocol down (if any is used between ce-pe),
etc.
 
Besides, although not explictely mentioned in the draft, there were some
additions to the control draft before that were motivated by the
ability to support SVC (dynamic PW) case (among other reasons).
I assume for these types as well a reason maybe required by the
protocol used in signaling.
 
Hamid.

> There is an assumption here that some operator will monitor
> both sides.
>
>
> Luca
>
>
>
------_=_NextPart_001_01C3303D.BE656922-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 13:22:23 -0400 Lines: 145 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3303E.055A85B0" Cc: pwe3@ietf.org, Luca Martini X-From: pwe3-admin@ietf.org Wed Jun 11 19:30:16 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_01C3303E.055A85B0 Content-Type: text/plain; charset="iso-8859-1" Mark, > > I agree as a general principle it is good to know why > an error has occurred. But in mulling this over since > I first wrote it, it occurs to me that it might depend > on where/why the error is communicated. > Yes. > For example, the full link error information could be > communicated via the management plane - if an operator > really needs to know. I guess the real question is why > is the control plane being asked to communicate this > information from one LDP peer to the other. Is it > because it expects the LDP peer to take some action? > If so, then simply knowing there has been an > error+forwarding status might be enough. If the extra > information can not be used by the control plane, then > it probably doesn't make sense to carry it around, we > are just complicating the implemenation. > But if there is another way to make a PE communicate with remote PE then other information can as well be communicated outside the signaling scheme (such as encaps, etc). It looks to me that since status is conveyed through the signaling then maybe it is preferable/logical to convey the reason for that particular status report using the same vehicle. Not sure it really complicates that much the implementation besides indicating the nature of the error. In general it looks to me it is beneficial to have such description now while we are discussing the status tlvs.... but I join your call for operators to indicate their opinion/preference on this item... Hamid. > Bottom line is I am not sure I understand what the > intended consequences/actions are of the LDP peer > receiving this information, so now not sure what is > sufficient information or not. > > Perhaps Luca could give some background, or perhaps it > is simply an implementation decision what to do with > the new knowledge that the other end of a PW has > experienced a failure. > > > --- Hamid Ould-Brahim > wrote: > > Mark, > > > > > > > > In addition, I would be interested to know if > > operators would like > > > information on the type of link error, and if yes, > > maybe a field where > > > vendors can place a description code. > > > > > > > I agree. It is beneficial to know the nature of the > > error. Something > > like diagnostic code-description needs to be > > supported. > > > > Hamid. > > > > ------_=_NextPart_001_01C3303E.055A85B0 Content-Type: text/html; charset="iso-8859-1"

Mark,

>
> I agree as a general principle it is good to know why
> an error has occurred. But in mulling this over since
> I first wrote it, it occurs to me that it might depend
> on where/why the error is communicated.
>

Yes.

> For example, the full link error information could be
> communicated via the management plane - if an operator
> really needs to know. I guess the real question is why
> is the control plane being asked to communicate this
> information from one LDP peer to the other. Is it
> because it expects the LDP peer to take some action?
> If so, then simply knowing there has been an
> error+forwarding status might be enough. If the extra
> information can not be used by the control plane, then
> it probably doesn't make sense to carry it around, we
> are just complicating the implemenation.
>
 
But if there is another way to make a PE communicate
with remote PE then other information can as well be
communicated outside the signaling scheme (such as encaps,
etc). It looks to me that since status is conveyed through
the signaling then maybe it is preferable/logical to convey the
reason for that particular status report using the same vehicle.
 
Not sure it really complicates that much the implementation
besides indicating the nature of the error.
 
In general it looks to me it is beneficial to have such
description now while we are discussing the status tlvs....
but I join your call for operators to indicate their
opinion/preference on this item...
 
Hamid.

> Bottom line is I am not sure I understand what the
> intended consequences/actions are of the LDP peer
> receiving this information, so now not sure what is
> sufficient information or not.
>
> Perhaps Luca could give some background, or perhaps it
> is simply an implementation decision what to do with
> the new knowledge that the other end of a PW has
> experienced a failure.
>
>
> --- Hamid Ould-Brahim <hbrahim@nortelnetworks.com>
> wrote:
> > Mark,
> >
> > >
> > > In addition, I would be interested to know if
> > operators would like
> > > information on the type of link error, and if yes,
> > maybe a field where
> > > vendors can place a description code.
> > >
> >
> > I agree. It is beneficial to know the nature of the
> > error. Something
> > like diagnostic code-description needs to be
> > supported.
> >
> > Hamid.
> >
>
>
------_=_NextPart_001_01C3303E.055A85B0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 10:37:49 -0700 Lines: 195 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33040.2D2CF1CA" Cc: pwe3@ietf.org, Luca Martini X-From: pwe3-admin@ietf.org Wed Jun 11 19:53:30 2003 Return-path: To: "'Hamid Ould-Brahim'" , 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 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_01C33040.2D2CF1CA Content-Type: text/plain; charset="iso-8859-1" Hamid, It is the operator not the PEs that needs to know the reason for failure. The NMS is the proper place to communicate such information. All a PE wants to know is whether the other PE could receive and forward the traffic or not. -Shahram -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Wednesday, June 11, 2003 1:22 PM To: Mark Seery Cc: pwe3@ietf.org; Luca Martini Subject: RE: [PWE3] status signalling of MPLS PW state Mark, > > I agree as a general principle it is good to know why > an error has occurred. But in mulling this over since > I first wrote it, it occurs to me that it might depend > on where/why the error is communicated. > Yes. > For example, the full link error information could be > communicated via the management plane - if an operator > really needs to know. I guess the real question is why > is the control plane being asked to communicate this > information from one LDP peer to the other. Is it > because it expects the LDP peer to take some action? > If so, then simply knowing there has been an > error+forwarding status might be enough. If the extra > information can not be used by the control plane, then > it probably doesn't make sense to carry it around, we > are just complicating the implemenation. > But if there is another way to make a PE communicate with remote PE then other information can as well be communicated outside the signaling scheme (such as encaps, etc). It looks to me that since status is conveyed through the signaling then maybe it is preferable/logical to convey the reason for that particular status report using the same vehicle. Not sure it really complicates that much the implementation besides indicating the nature of the error. In general it looks to me it is beneficial to have such description now while we are discussing the status tlvs.... but I join your call for operators to indicate their opinion/preference on this item... Hamid. > Bottom line is I am not sure I understand what the > intended consequences/actions are of the LDP peer > receiving this information, so now not sure what is > sufficient information or not. > > Perhaps Luca could give some background, or perhaps it > is simply an implementation decision what to do with > the new knowledge that the other end of a PW has > experienced a failure. > > > --- Hamid Ould-Brahim > wrote: > > Mark, > > > > > > > > In addition, I would be interested to know if > > operators would like > > > information on the type of link error, and if yes, > > maybe a field where > > > vendors can place a description code. > > > > > > > I agree. It is beneficial to know the nature of the > > error. Something > > like diagnostic code-description needs to be > > supported. > > > > Hamid. > > > > ------_=_NextPart_001_01C33040.2D2CF1CA Content-Type: text/html; charset="iso-8859-1"
Hamid,
 
It is the operator not the PEs that needs to know the reason for failure.
The NMS is the proper place to communicate such information. All a PE
wants to know is whether the other PE could receive and forward the
traffic or not.
 
-Shahram
 
-----Original Message-----
From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com]
Sent: Wednesday, June 11, 2003 1:22 PM
To: Mark Seery
Cc: pwe3@ietf.org; Luca Martini
Subject: RE: [PWE3] status signalling of MPLS PW state

Mark,

>
> I agree as a general principle it is good to know why
> an error has occurred. But in mulling this over since
> I first wrote it, it occurs to me that it might depend
> on where/why the error is communicated.
>

Yes.

> For example, the full link error information could be
> communicated via the management plane - if an operator
> really needs to know. I guess the real question is why
> is the control plane being asked to communicate this
> information from one LDP peer to the other. Is it
> because it expects the LDP peer to take some action?
> If so, then simply knowing there has been an
> error+forwarding status might be enough. If the extra
> information can not be used by the control plane, then
> it probably doesn't make sense to carry it around, we
> are just complicating the implemenation.
>
 
But if there is another way to make a PE communicate
with remote PE then other information can as well be
communicated outside the signaling scheme (such as encaps,
etc). It looks to me that since status is conveyed through
the signaling then maybe it is preferable/logical to convey the
reason for that particular status report using the same vehicle.
 
Not sure it really complicates that much the implementation
besides indicating the nature of the error.
 
In general it looks to me it is beneficial to have such
description now while we are discussing the status tlvs....
but I join your call for operators to indicate their
opinion/preference on this item...
 
Hamid.

> Bottom line is I am not sure I understand what the
> intended consequences/actions are of the LDP peer
> receiving this information, so now not sure what is
> sufficient information or not.
>
> Perhaps Luca could give some background, or perhaps it
> is simply an implementation decision what to do with
> the new knowledge that the other end of a PW has
> experienced a failure.
>
>
> --- Hamid Ould-Brahim <hbrahim@nortelnetworks.com>
> wrote:
> > Mark,
> >
> > >
> > > In addition, I would be interested to know if
> > operators would like
> > > information on the type of link error, and if yes,
> > maybe a field where
> > > vendors can place a description code.
> > >
> >
> > I agree. It is beneficial to know the nature of the
> > error. Something
> > like diagnostic code-description needs to be
> > supported.
> >
> > Hamid.
> >
>
>
------_=_NextPart_001_01C33040.2D2CF1CA-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Lin, Zhi-Wei" Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 13:59:28 -0400 Lines: 181 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33043.33A9BD50" Cc: pwe3@ietf.org, Luca Martini X-From: pwe3-admin@ietf.org Wed Jun 11 20:02:34 2003 Return-path: To: "'Hamid Ould-Brahim'" , 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 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_01C33043.33A9BD50 Content-Type: text/plain; charset="iso-8859-1" So in the case of a failure, how much information are you envisioning need to be carried (e.g., details per LSP?), and how often would this information be propagated (periodically, event driven?)? Zhi -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Wednesday, June 11, 2003 1:22 PM To: Mark Seery Cc: pwe3@ietf.org; Luca Martini Subject: RE: [PWE3] status signalling of MPLS PW state Mark, > > I agree as a general principle it is good to know why > an error has occurred. But in mulling this over since > I first wrote it, it occurs to me that it might depend > on where/why the error is communicated. > Yes. > For example, the full link error information could be > communicated via the management plane - if an operator > really needs to know. I guess the real question is why > is the control plane being asked to communicate this > information from one LDP peer to the other. Is it > because it expects the LDP peer to take some action? > If so, then simply knowing there has been an > error+forwarding status might be enough. If the extra > information can not be used by the control plane, then > it probably doesn't make sense to carry it around, we > are just complicating the implemenation. > But if there is another way to make a PE communicate with remote PE then other information can as well be communicated outside the signaling scheme (such as encaps, etc). It looks to me that since status is conveyed through the signaling then maybe it is preferable/logical to convey the reason for that particular status report using the same vehicle. Not sure it really complicates that much the implementation besides indicating the nature of the error. In general it looks to me it is beneficial to have such description now while we are discussing the status tlvs.... but I join your call for operators to indicate their opinion/preference on this item... Hamid. > Bottom line is I am not sure I understand what the > intended consequences/actions are of the LDP peer > receiving this information, so now not sure what is > sufficient information or not. > > Perhaps Luca could give some background, or perhaps it > is simply an implementation decision what to do with > the new knowledge that the other end of a PW has > experienced a failure. > > > --- Hamid Ould-Brahim > wrote: > > Mark, > > > > > > > > In addition, I would be interested to know if > > operators would like > > > information on the type of link error, and if yes, > > maybe a field where > > > vendors can place a description code. > > > > > > > I agree. It is beneficial to know the nature of the > > error. Something > > like diagnostic code-description needs to be > > supported. > > > > Hamid. > > > > ------_=_NextPart_001_01C33043.33A9BD50 Content-Type: text/html; charset="iso-8859-1"
So in the case of a failure, how much information are you envisioning need to be carried (e.g., details per LSP?), and how often would this information be propagated (periodically, event driven?)?
 
Zhi
 
-----Original Message-----
From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com]
Sent: Wednesday, June 11, 2003 1:22 PM
To: Mark Seery
Cc: pwe3@ietf.org; Luca Martini
Subject: RE: [PWE3] status signalling of MPLS PW state

Mark,

>
> I agree as a general principle it is good to know why
> an error has occurred. But in mulling this over since
> I first wrote it, it occurs to me that it might depend
> on where/why the error is communicated.
>

Yes.

> For example, the full link error information could be
> communicated via the management plane - if an operator
> really needs to know. I guess the real question is why
> is the control plane being asked to communicate this
> information from one LDP peer to the other. Is it
> because it expects the LDP peer to take some action?
> If so, then simply knowing there has been an
> error+forwarding status might be enough. If the extra
> information can not be used by the control plane, then
> it probably doesn't make sense to carry it around, we
> are just complicating the implemenation.
>
 
But if there is another way to make a PE communicate
with remote PE then other information can as well be
communicated outside the signaling scheme (such as encaps,
etc). It looks to me that since status is conveyed through
the signaling then maybe it is preferable/logical to convey the
reason for that particular status report using the same vehicle.
 
Not sure it really complicates that much the implementation
besides indicating the nature of the error.
 
In general it looks to me it is beneficial to have such
description now while we are discussing the status tlvs....
but I join your call for operators to indicate their
opinion/preference on this item...
 
Hamid.

> Bottom line is I am not sure I understand what the
> intended consequences/actions are of the LDP peer
> receiving this information, so now not sure what is
> sufficient information or not.
>
> Perhaps Luca could give some background, or perhaps it
> is simply an implementation decision what to do with
> the new knowledge that the other end of a PW has
> experienced a failure.
>
>
> --- Hamid Ould-Brahim <hbrahim@nortelnetworks.com>
> wrote:
> > Mark,
> >
> > >
> > > In addition, I would be interested to know if
> > operators would like
> > > information on the type of link error, and if yes,
> > maybe a field where
> > > vendors can place a description code.
> > >
> >
> > I agree. It is beneficial to know the nature of the
> > error. Something
> > like diagnostic code-description needs to be
> > supported.
> >
> > Hamid.
> >
>
>
------_=_NextPart_001_01C33043.33A9BD50-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Andrew G. Malis" Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 13:59:19 -0400 Lines: 72 Sender: pwe3-admin@ietf.org References: <049AAFED91851244B9FF74D0D9D0EB720215263F@WHISTLER.WaveSmit hNet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: X-From: pwe3-admin@ietf.org Wed Jun 11 20:19:20 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: "Luca Martini" In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB720215263F@WHISTLER.WaveSmit hNet.com> X-OriginalArrivalTime: 11 Jun 2003 18:01:39.0261 (UTC) FILETIME=[81A656D0:01C33043] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca, I would like to agree with Himanshu's message. To tell you the truth, I was a bit surprised to your message proposing Toby's text for status signaling. I was under the impression (perhaps mistaken?) that WG consensus had already been determined to accept draft-shah-pwe3-control-protocol-extension-00.txt and that it was in the process of being incorporated into the main control signaling draft. I certainly agree that one or the other is needed, and if I had to choose between them, the Operational Status TLV is certainly easier to implement and less disruptive to existing LDP implementations than the PW Link Status Message. Is there a really good reason why the Operational Status TLV can't work? I saw Toby's comment about only using the group ID to reflect interface outages, but that's only useful if you have multiple parallel PWs between the same two logical interfaces at the edge of the network (they have to share the same LDP session), which isn't going to be all that common. I can tell you from experience in large FR and ATM networks that end-to-end status signaling on a per-VC (per-PW in our case) basis works just fine, even when you have interface outages. Are there any other reasons? Thanks, Andy --------- At 6/10/2003 09:22 AM -0400, Himanshu Shah wrote: >Luca, > >I am glad that you have recognized the need for >conveying the link status as compared to withdrawing >the VC-LABEL for the same and Toby has good >proposal. > >However, I would like PWE3 to approach this slightly >differently as described in >draft-shah-pwe3-control-protocol-extension-00.txt. > >We need a +generic mechanism+ to relay "dynamic >attributes" of the PW, including the status of the AC (and >yes, it should be AC or PW status as compared to link status). >The generic mechanism can then be used to extend >control signaling without having to constantly change >the base draft. > >The extension draft proposes that such PW attributes >be included in "optional parameter" field of the Label >mapping message. The advantage of this approach is, > >1) conveying of one or more dynamic attributes in a > single label mapping message. Extension draft describes > IP addr (needed for ARP-mediation) , IP+MAC addr (needed > for IPLS), QOS, tunnel mechanisms used, etc TLVs. >2) a way to include these attributes in first mapping msg > as compared to a follow-on status msgs (for example, > PE does not know the status of the remote AC until > link status msg follows the initial label mapping msg) >3) allows update of the attributes. When dynamic attribute > changes, an update is sent without withdrawing the VC-FEC >4 ) allows definitions of new attributes without > modifying base LDP or martini signaling draft > >I would like PWE3 to consider this approach. > >/himanshu >wavesmith networks > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Keith Knightson Subject: RE: PWE Service interworking Date: Wed, 11 Jun 2003 16:13:24 -0400 Lines: 33 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 Wed Jun 11 22:15:36 2003 Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: To: "David Allan" , "'Mark Seery'" , Shahram Davari X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.75.37] using ID at Wed, 11 Jun 2003 16:11:44 -0400 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 4:33 PM -0400 5/6/03, David Allan wrote: If you're concatenating technologies together for SWIF, then yes the layers terminate. Its also a pain to interwork OAM protocols as the semantics may not match. The 17iw stuff assume we're interworking states of separate entities to get an overall view. NIWF does have a better e2e story but as a pure overlay, you're just keeping the old game alive. Deploying old edge and new core. Didn't quite get your third comment? cheers Dave Dave, How can any customer know whether his path at the "layer" in question ends on a SIWF or a NIWF? It seems probable me that a given customer may have several paths from his CE using exactly the same protocol stack to the PE, and depending on where and who provides the last PE, may in fact have some paths terminating on a SIF and some on a NIF, depending a variety of intervening networks and access networks. What should he expect the semantics of his OAM to be? I do not think it reasonable for the customer to know all the technical components in any or all paths from him to anywhere/everywhere. Agreed all semantics may not map or be available. That's the price of SIFs. Cheers Keith From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 16:33:45 -0400 Lines: 216 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33058.C1707E7A" Cc: pwe3@ietf.org, Luca Martini X-From: pwe3-admin@ietf.org Wed Jun 11 22:38:53 2003 Return-path: To: "Lin, Zhi-Wei" , 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_01C33058.C1707E7A Content-Type: text/plain; charset="iso-8859-1" Zhi, So in the case of a failure, how much information are you envisioning need to be carried (e.g., details per LSP?), and how often would this information be propagated (periodically, event driven?)? Propagated when operational status changes. Not that much information either a code indicated the reason or fine grained status codes (up to operators to indicate their preference)... Hamid. Zhi -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Wednesday, June 11, 2003 1:22 PM To: Mark Seery Cc: pwe3@ietf.org; Luca Martini Subject: RE: [PWE3] status signalling of MPLS PW state Mark, > > I agree as a general principle it is good to know why > an error has occurred. But in mulling this over since > I first wrote it, it occurs to me that it might depend > on where/why the error is communicated. > Yes. > For example, the full link error information could be > communicated via the management plane - if an operator > really needs to know. I guess the real question is why > is the control plane being asked to communicate this > information from one LDP peer to the other. Is it > because it expects the LDP peer to take some action? > If so, then simply knowing there has been an > error+forwarding status might be enough. If the extra > information can not be used by the control plane, then > it probably doesn't make sense to carry it around, we > are just complicating the implemenation. > But if there is another way to make a PE communicate with remote PE then other information can as well be communicated outside the signaling scheme (such as encaps, etc). It looks to me that since status is conveyed through the signaling then maybe it is preferable/logical to convey the reason for that particular status report using the same vehicle. Not sure it really complicates that much the implementation besides indicating the nature of the error. In general it looks to me it is beneficial to have such description now while we are discussing the status tlvs.... but I join your call for operators to indicate their opinion/preference on this item... Hamid. > Bottom line is I am not sure I understand what the > intended consequences/actions are of the LDP peer > receiving this information, so now not sure what is > sufficient information or not. > > Perhaps Luca could give some background, or perhaps it > is simply an implementation decision what to do with > the new knowledge that the other end of a PW has > experienced a failure. > > > --- Hamid Ould-Brahim > wrote: > > Mark, > > > > > > > > In addition, I would be interested to know if > > operators would like > > > information on the type of link error, and if yes, > > maybe a field where > > > vendors can place a description code. > > > > > > > I agree. It is beneficial to know the nature of the > > error. Something > > like diagnostic code-description needs to be > > supported. > > > > Hamid. > > > > ------_=_NextPart_001_01C33058.C1707E7A Content-Type: text/html; charset="iso-8859-1"
Zhi,
So in the case of a failure, how much information are you envisioning need to be carried (e.g., details per LSP?), and how often would this information be propagated (periodically, event driven?)?
 
Propagated when operational status changes. Not that much information
either a code indicated the reason or fine grained status codes (up to
operators to indicate their preference)...
 
Hamid.
 
 Zhi
 
-----Original Message-----
From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com]
Sent: Wednesday, June 11, 2003 1:22 PM
To: Mark Seery
Cc: pwe3@ietf.org; Luca Martini
Subject: RE: [PWE3] status signalling of MPLS PW state

Mark,

>
> I agree as a general principle it is good to know why
> an error has occurred. But in mulling this over since
> I first wrote it, it occurs to me that it might depend
> on where/why the error is communicated.
>

Yes.

> For example, the full link error information could be
> communicated via the management plane - if an operator
> really needs to know. I guess the real question is why
> is the control plane being asked to communicate this
> information from one LDP peer to the other. Is it
> because it expects the LDP peer to take some action?
> If so, then simply knowing there has been an
> error+forwarding status might be enough. If the extra
> information can not be used by the control plane, then
> it probably doesn't make sense to carry it around, we
> are just complicating the implemenation.
>
 
But if there is another way to make a PE communicate
with remote PE then other information can as well be
communicated outside the signaling scheme (such as encaps,
etc). It looks to me that since status is conveyed through
the signaling then maybe it is preferable/logical to convey the
reason for that particular status report using the same vehicle.
 
Not sure it really complicates that much the implementation
besides indicating the nature of the error.
 
In general it looks to me it is beneficial to have such
description now while we are discussing the status tlvs....
but I join your call for operators to indicate their
opinion/preference on this item...
 
Hamid.

> Bottom line is I am not sure I understand what the
> intended consequences/actions are of the LDP peer
> receiving this information, so now not sure what is
> sufficient information or not.
>
> Perhaps Luca could give some background, or perhaps it
> is simply an implementation decision what to do with
> the new knowledge that the other end of a PW has
> experienced a failure.
>
>
> --- Hamid Ould-Brahim <hbrahim@nortelnetworks.com>
> wrote:
> > Mark,
> >
> > >
> > > In addition, I would be interested to know if
> > operators would like
> > > information on the type of link error, and if yes,
> > maybe a field where
> > > vendors can place a description code.
> > >
> >
> > I agree. It is beneficial to know the nature of the
> > error. Something
> > like diagnostic code-description needs to be
> > supported.
> >
> > Hamid.
> >
>
>
------_=_NextPart_001_01C33058.C1707E7A-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 16:39:31 -0400 Lines: 279 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33059.8F61FE94" Cc: pwe3@ietf.org, Luca Martini X-From: pwe3-admin@ietf.org Wed Jun 11 22:43:09 2003 Return-path: To: Shahram Davari , 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_01C33059.8F61FE94 Content-Type: text/plain; charset="iso-8859-1" Shahram, It is the operator not the PEs that needs to know the reason for failure. The NMS is the proper place to communicate such information. NMS is fine (particularly reporting the reason for the PE experiencing the problem). All a PE wants to know is whether the other PE could receive and forward the traffic or not. My question/suggestion for operators is whether it is desirable to indicate to the remote PE the reason of the failure in case the operator had previously put some policies for taking specific actions depending on the reason for a particular status type (an example I can think of is the case where a backup pw is/is not triggered). Hamid. -Shahram -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Wednesday, June 11, 2003 1:22 PM To: Mark Seery Cc: pwe3@ietf.org; Luca Martini Subject: RE: [PWE3] status signalling of MPLS PW state Mark, > > I agree as a general principle it is good to know why > an error has occurred. But in mulling this over since > I first wrote it, it occurs to me that it might depend > on where/why the error is communicated. > Yes. > For example, the full link error information could be > communicated via the management plane - if an operator > really needs to know. I guess the real question is why > is the control plane being asked to communicate this > information from one LDP peer to the other. Is it > because it expects the LDP peer to take some action? > If so, then simply knowing there has been an > error+forwarding status might be enough. If the extra > information can not be used by the control plane, then > it probably doesn't make sense to carry it around, we > are just complicating the implemenation. > But if there is another way to make a PE communicate with remote PE then other information can as well be communicated outside the signaling scheme (such as encaps, etc). It looks to me that since status is conveyed through the signaling then maybe it is preferable/logical to convey the reason for that particular status report using the same vehicle. Not sure it really complicates that much the implementation besides indicating the nature of the error. In general it looks to me it is beneficial to have such description now while we are discussing the status tlvs.... but I join your call for operators to indicate their opinion/preference on this item... Hamid. > Bottom line is I am not sure I understand what the > intended consequences/actions are of the LDP peer > receiving this information, so now not sure what is > sufficient information or not. > > Perhaps Luca could give some background, or perhaps it > is simply an implementation decision what to do with > the new knowledge that the other end of a PW has > experienced a failure. > > > --- Hamid Ould-Brahim > wrote: > > Mark, > > > > > > > > In addition, I would be interested to know if > > operators would like > > > information on the type of link error, and if yes, > > maybe a field where > > > vendors can place a description code. > > > > > > > I agree. It is beneficial to know the nature of the > > error. Something > > like diagnostic code-description needs to be > > supported. > > > > Hamid. > > > > ------_=_NextPart_001_01C33059.8F61FE94 Content-Type: text/html; charset="iso-8859-1"
Shahram,
It is the operator not the PEs that needs to know the reason for failure.   
 The NMS is the proper place to communicate such information.  
 
NMS is fine (particularly reporting the reason
for the PE experiencing the problem).
 
 All a PE wants to know is whether the other PE could receive and forward the
traffic or not. 
 
My question/suggestion for operators is whether it is desirable
to indicate to the remote PE the reason of the failure in
case the operator had previously put some policies for
taking specific actions  depending on the reason for
a particular status type (an example I can think of is the case
where a backup pw is/is not triggered).
 
Hamid.
 
 
 
-Shahram
 
-----Original Message-----
From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com]
Sent: Wednesday, June 11, 2003 1:22 PM
To: Mark Seery
Cc: pwe3@ietf.org; Luca Martini
Subject: RE: [PWE3] status signalling of MPLS PW state

Mark,

>
> I agree as a general principle it is good to know why
> an error has occurred. But in mulling this over since
> I first wrote it, it occurs to me that it might depend
> on where/why the error is communicated.
>

Yes.

> For example, the full link error information could be
> communicated via the management plane - if an operator
> really needs to know. I guess the real question is why
> is the control plane being asked to communicate this
> information from one LDP peer to the other. Is it
> because it expects the LDP peer to take some action?
> If so, then simply knowing there has been an
> error+forwarding status might be enough. If the extra
> information can not be used by the control plane, then
> it probably doesn't make sense to carry it around, we
> are just complicating the implemenation.
>
 
But if there is another way to make a PE communicate
with remote PE then other information can as well be
communicated outside the signaling scheme (such as encaps,
etc). It looks to me that since status is conveyed through
the signaling then maybe it is preferable/logical to convey the
reason for that particular status report using the same vehicle.
 
Not sure it really complicates that much the implementation
besides indicating the nature of the error.
 
In general it looks to me it is beneficial to have such
description now while we are discussing the status tlvs....
but I join your call for operators to indicate their
opinion/preference on this item...
 
Hamid.

> Bottom line is I am not sure I understand what the
> intended consequences/actions are of the LDP peer
> receiving this information, so now not sure what is
> sufficient information or not.
>
> Perhaps Luca could give some background, or perhaps it
> is simply an implementation decision what to do with
> the new knowledge that the other end of a PW has
> experienced a failure.
>
>
> --- Hamid Ould-Brahim <hbrahim@nortelnetworks.com>
> wrote:
> > Mark,
> >
> > >
> > > In addition, I would be interested to know if
> > operators would like
> > > information on the type of link error, and if yes,
> > maybe a field where
> > > vendors can place a description code.
> > >
> >
> > I agree. It is beneficial to know the nature of the
> > error. Something
> > like diagnostic code-description needs to be
> > supported.
> >
> > Hamid.
> >
>
>
------_=_NextPart_001_01C33059.8F61FE94-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: PWE Service interworking Date: Wed, 11 Jun 2003 16:48:05 -0400 Lines: 122 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3305A.C201D71A" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 11 22:53:39 2003 Return-path: To: "'Keith Knightson'" , "'Mark Seery'" , 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 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_01C3305A.C201D71A Content-Type: text/plain; charset="iso-8859-1" Hi Keith: > > How can any customer know whether his path at the "layer" in question > ends on a SIWF or a NIWF? They don't. > > It seems probable me that a given customer may have several paths > from his CE using exactly the same protocol stack to the PE, and > depending on where and who provides the last PE, may in fact have > some paths terminating on a SIF and some on a NIF, depending a > variety of intervening networks and access networks. Yes. > What should he > expect the semantics of his OAM to be? I do not think it > reasonable for the customer to know all the technical components in > any or all paths from him to anywhere/everywhere. Definitely not. IMHO depending on the techology mix, you may be able to propagate knowledge of problems but progressing further usually means using tools local to the failed subnetwork. > > Agreed all semantics may not map or be available. That's the > price of SIFs. Yep. I've seen proposals suggesting tools can interwork at the protocol level between SIFs such that e2e diagnostics can be performed from anywhere in the served area. Wasn't pretty and motivated my comments. rgds Dave ------_=_NextPart_001_01C3305A.C201D71A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] PWE Service interworking

Hi Keith:

<snipped>
>
> How can any customer know whether his path at = the "layer" in question
> ends on a SIWF or a NIWF?

They don't.

>
> It seems probable me that a given customer may = have several paths
> from his CE using exactly the same protocol = stack to the PE, and
> depending on where and who provides the last = PE, may in fact have
> some paths terminating on  a SIF and some = on a NIF, depending a
> variety of intervening networks and access = networks.

Yes.

> What should he
> expect the semantics of his OAM to = be?     I do not think it
> reasonable for the customer to know all the = technical components in
> any or all paths from him to = anywhere/everywhere.

Definitely not. IMHO depending on the techology mix, = you may be able to propagate knowledge of problems but progressing = further usually means using tools local to the failed = subnetwork.

>
> Agreed all semantics may not map or be = available.  That's the
> price of SIFs.

Yep. I've seen proposals suggesting tools can = interwork at the protocol level between SIFs such that e2e diagnostics = can be performed from anywhere in the served area. Wasn't pretty and = motivated my comments.

rgds
Dave

------_=_NextPart_001_01C3305A.C201D71A-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 16:48:40 -0400 Lines: 123 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3305A.D6A183C8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 11 22:57:02 2003 Return-path: To: "Andrew G. Malis" , Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C3305A.D6A183C8 Content-Type: text/plain; charset="iso-8859-1" Andy, [clipped]... > > I certainly agree that one or the other is needed, How about both proposals to be merged (when possible/applicable)? Hamid. > --------- > > At 6/10/2003 09:22 AM -0400, Himanshu Shah wrote: > >Luca, > > > >I am glad that you have recognized the need for > >conveying the link status as compared to withdrawing > >the VC-LABEL for the same and Toby has good > >proposal. > > > >However, I would like PWE3 to approach this slightly > >differently as described in > >draft-shah-pwe3-control-protocol-extension-00.txt. > > > >We need a +generic mechanism+ to relay "dynamic > >attributes" of the PW, including the status of the AC (and > >yes, it should be AC or PW status as compared to link status). > >The generic mechanism can then be used to extend > >control signaling without having to constantly change > >the base draft. > > > >The extension draft proposes that such PW attributes > >be included in "optional parameter" field of the Label > >mapping message. The advantage of this approach is, > > > >1) conveying of one or more dynamic attributes in a > > single label mapping message. Extension draft describes > > IP addr (needed for ARP-mediation) , IP+MAC addr (needed > > for IPLS), QOS, tunnel mechanisms used, etc TLVs. > >2) a way to include these attributes in first mapping msg > > as compared to a follow-on status msgs (for example, > > PE does not know the status of the remote AC until > > link status msg follows the initial label mapping msg) > >3) allows update of the attributes. When dynamic attribute > > changes, an update is sent without withdrawing the VC-FEC > >4 ) allows definitions of new attributes without > > modifying base LDP or martini signaling draft > > > >I would like PWE3 to consider this approach. > > > >/himanshu > >wavesmith networks > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C3305A.D6A183C8 Content-Type: text/html; charset="iso-8859-1"

Andy,

[clipped]...

>
> I certainly agree that one or the other is needed,

How about both proposals to be merged (when possible/applicable)?

Hamid.

> ---------
>
> At 6/10/2003 09:22 AM -0400, Himanshu Shah wrote:
> >Luca,
> >
> >I am glad that you have recognized the need for
> >conveying the link status as compared to withdrawing
> >the VC-LABEL for the same and Toby has good
> >proposal.
> >
> >However, I would like PWE3 to approach this slightly
> >differently as described in
> >draft-shah-pwe3-control-protocol-extension-00.txt.
> >
> >We need a +generic mechanism+ to relay "dynamic
> >attributes" of the PW, including the status of the AC (and
> >yes, it should be AC or PW status as compared to link status).
> >The generic mechanism can then be used to extend
> >control signaling without having to constantly change
> >the base draft.
> >
> >The extension draft proposes that such PW attributes
> >be included in "optional parameter" field of the Label
> >mapping message. The advantage of this approach is,
> >
> >1) conveying of one or more dynamic attributes in a
> >      single label mapping message. Extension draft describes
> >      IP addr (needed for ARP-mediation) , IP+MAC addr (needed
> >      for IPLS), QOS, tunnel mechanisms used, etc TLVs.
> >2) a way to include these attributes in first mapping msg
> >      as compared to a follow-on status msgs (for example,
> >      PE does not know the status of the remote AC until
> >     link status msg follows the initial label mapping msg)
> >3) allows update of the attributes. When dynamic attribute
> >     changes, an update is sent without withdrawing the VC-FEC
> >4 ) allows definitions of new attributes without
> >       modifying base LDP or martini signaling draft
> >
> >I would like PWE3 to consider this approach.
> >
> >/himanshu
> >wavesmith networks
> >
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>

------_=_NextPart_001_01C3305A.D6A183C8-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Andrew G. Malis" Subject: RE: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 17:22:30 -0400 Lines: 50 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_88511352==.ALT" Cc: "Andrew G. Malis" , Luca Martini , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 11 23:26:00 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: "Hamid Ould-Brahim" In-Reply-To: X-OriginalArrivalTime: 11 Jun 2003 21:23:12.0713 (UTC) FILETIME=[A9E8AB90:01C3305F] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --=====================_88511352==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hamid, Well, they're really two alternative ways to extend LDP to convey the same information. The only way to really merge them would be to support them both .... Thanks, Andy --------- At 6/11/2003 04:48 PM -0400, Hamid Ould-Brahim wrote: >Andy, > >[clipped]... > > > > > I certainly agree that one or the other is needed, > >How about both proposals to be merged (when possible/applicable)? > >Hamid. --=====================_88511352==.ALT Content-Type: text/html; charset="us-ascii" Hamid,

Well, they're really two alternative ways to extend LDP to convey the same information.  The only way to really merge them would be to support them both ....

Thanks,
Andy

---------

At 6/11/2003 04:48 PM -0400, Hamid Ould-Brahim wrote:

Andy,

[clipped]...

>
> I certainly agree that one or the other is needed,

How about both proposals to be merged (when possible/applicable)?

Hamid.
--=====================_88511352==.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 17:03:27 -0600 Organization: Level3 Communications LLC. Lines: 45 Sender: pwe3-admin@ietf.org References: <5.2.1.1.0.20030611172035.032a91b0@mail.attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Hamid Ould-Brahim , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 12 01:13:10 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: "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 I read the following TLVs in the draft-shah-pwe3-control-protocol-extension-00.txt : Operational Status TLV IP Address TLV IP+MAC Address TLV Pseudowire QOS TLV I think most of these are needed , but they need not all be part of the FEC. There are several bits available in the status TLV proposal, can you please specify what the use should be, and I can add it. ( please note that the draft-shah does not propose much in the area of status ) Thanks. Luca Andrew G. Malis wrote: > Hamid, > > Well, they're really two alternative ways to extend LDP to convey the > same information. The only way to really merge them would be to support > them both .... > > Thanks, > Andy > > --------- > > At 6/11/2003 04:48 PM -0400, Hamid Ould-Brahim wrote: > >> Andy, >> >> [clipped]... >> >> > >> > I certainly agree that one or the other is needed, >> >> How about both proposals to be merged (when possible/applicable)? >> >> Hamid. > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 17:06:18 -0600 Organization: Level3 Communications LLC. Lines: 96 Sender: pwe3-admin@ietf.org References: <5.2.1.1.0.20030611135400.02f182d8@mail.attbi.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 Thu Jun 12 01:16:31 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: "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: > Luca, > > I would like to agree with Himanshu's message. > > To tell you the truth, I was a bit surprised to your message proposing > Toby's text for status signaling. I was under the impression (perhaps > mistaken?) that WG consensus had already been determined to accept > draft-shah-pwe3-control-protocol-extension-00.txt and that it was in the > process of being incorporated into the main control signaling draft. > actually most of that draft belongs in PPVPN. I had only agreed to consider it , and WG feed back was that it is a good idea to have such mechanisms. lot's of reasons where in the text that I posted earlier. > I certainly agree that one or the other is needed, and if I had to > choose between them, the Operational Status TLV is certainly easier to > implement and less disruptive to existing LDP implementations than the > PW Link Status Message. Is there a really good reason why the > Operational Status TLV can't work? > > I saw Toby's comment about only using the group ID to reflect interface > outages, but that's only useful if you have multiple parallel PWs > between the same two logical interfaces at the edge of the network (they > have to share the same LDP session), which isn't going to be all that > common. I can tell you from experience in large FR and ATM networks > that end-to-end status signaling on a per-VC (per-PW in our case) basis > works just fine, even when you have interface outages. > Actually back in the san diego IETF there was a strong request for the group ID mechanisms for large NNI to NNI applications. the down notification had to be immediate for 10000 PWs. One other issue is that we would like to limit what goes into this message. There is a very limited set of useful failures at the PW abstraction layer. The TLVs proposed in draft-shah-pwe3-control-protocol-extension-00 are useful and need to be included where most appropriate. Operational state in not a FEC, this is why I did not put this in the interface parameters.. Thanks. Luca > Are there any other reasons? > > Thanks, > Andy > > --------- > > At 6/10/2003 09:22 AM -0400, Himanshu Shah wrote: > >> Luca, >> >> I am glad that you have recognized the need for >> conveying the link status as compared to withdrawing >> the VC-LABEL for the same and Toby has good >> proposal. >> >> However, I would like PWE3 to approach this slightly >> differently as described in >> draft-shah-pwe3-control-protocol-extension-00.txt. >> >> We need a +generic mechanism+ to relay "dynamic >> attributes" of the PW, including the status of the AC (and >> yes, it should be AC or PW status as compared to link status). >> The generic mechanism can then be used to extend >> control signaling without having to constantly change >> the base draft. >> >> The extension draft proposes that such PW attributes >> be included in "optional parameter" field of the Label >> mapping message. The advantage of this approach is, >> >> 1) conveying of one or more dynamic attributes in a >> single label mapping message. Extension draft describes >> IP addr (needed for ARP-mediation) , IP+MAC addr (needed >> for IPLS), QOS, tunnel mechanisms used, etc TLVs. >> 2) a way to include these attributes in first mapping msg >> as compared to a follow-on status msgs (for example, >> PE does not know the status of the remote AC until >> link status msg follows the initial label mapping msg) >> 3) allows update of the attributes. When dynamic attribute >> changes, an update is sent without withdrawing the VC-FEC >> 4 ) allows definitions of new attributes without >> modifying base LDP or martini signaling draft >> >> I would like PWE3 to consider this approach. >> >> /himanshu >> wavesmith networks >> > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Wed, 11 Jun 2003 17:06:41 -0600 Organization: Level3 Communications LLC. Lines: 72 Sender: pwe3-admin@ietf.org References: <5.2.1.1.0.20030611172035.032a91b0@mail.attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Jun 12 01:21:02 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 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 Latest text, including some of the feedback. .Pb "Signaling of Pseudo Wire Link Status" .Pc "Use of Label Mappings." The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the CE interface state. The PW label should not be withdrawn unless the user administratively configures the CE interface down (or the PW configuration is deleted entirely). A simple label withdraw method SHOULD also be supported as an alternative. .Pc "Signaling PW Link status." When PWLE mode is in use, the PE devices use a new LDP TLV to indicate status to their remote peers, instead of withdrawing their PW FEC labels. This Link Status TLV contains more information than the simple Label Withdraw message used in the baseline signaling. The format of the Link Status TLV is: .DS 0 0 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Link Status (0x0700) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .DE Where status is a 2 octet bit field: .nf 0x0000 - Pseudo Wire forwarding ( clear all failures ) 0x0001 - Pseudo Wire Not Forwarding 0x0002 - Local Customer-facing Interface Receive Fault 0x0004 - Local Customer-facing Interface Transmit Fault 0x0008 - Local Core-facing Interface Receive Fault 0x0010 - Local Core-facing Interface Transmit Fault .En The above status codes can be logically combined to indicate more then a single failure at once. The presence of the lowest bit (PW Not Forwarding) acts only as a generic failure indication when there is a link-down event for which none of the other bits apply. The Link Status TLV is transported to the remote PW peer via a new LDP message, the PW Link Status Message. The format of the PW Link Status Message is: .DS 0 0 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| PW Link Status (0x0700) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .DE When a PE's CE-facing interface encounters an error, use of the new message allows the PE to send a single Link Status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 10:36:03 +0200 Lines: 122 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 Thu Jun 12 09:42:58 2003 Return-path: To: "'Andrew G. Malis'" , Luca Martini , "Himanshu Shah (E-mail 2)" 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 Andy and Luca, I support Andy's position. Please see also additional 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: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Wednesday, June 11, 2003 7:59 PM > To: Luca Martini > Cc: pwe3@ietf.org > Subject: RE: [PWE3] status signalling of MPLS PW state > > > Luca, > > I would like to agree with Himanshu's message. > > To tell you the truth, I was a bit surprised to your message > proposing > Toby's text for status signaling. I was under the impression > (perhaps > mistaken?) that WG consensus had already been determined to accept > draft-shah-pwe3-control-protocol-extension-00.txt and that it > was in the > process of being incorporated into the main control signaling draft. > > I certainly agree that one or the other is needed, and if I > had to choose > between them, the Operational Status TLV is certainly easier > to implement > and less disruptive to existing LDP implementations than the > PW Link Status > Message. > IMHO, adding a new message to LDP would require involvement of the MPLS WG. > > Is there a really good reason why the Operational Status TLV > can't work? > I think that the Operational Status TLV in LDP and the Circuit Status AVP in L2TPv3 serve exactly the same purpose and hence should carry the same information. Currently there are some minor differences. I also agree with Himanshu that ability to signal the attachment circuit status at the PW establishment is important. > > I saw Toby's comment about only using the group ID to reflect > interface outages, but that's only useful if you have multiple parallel > PWs between the same two logical interfaces at the edge of the network > (they have to share the same LDP session), which isn't going to be all that > common. I can tell you from experience in large FR and ATM networks > that end-to-end status signaling on a per-VC (per-PW in our case) basis works > just fine, even when you have interface outages. > Does not the same logic apply to "wild card withdrawal" of PW labels based on Group ID as presented in Section 5.1 of draft-ietf-pwe3-control-protocol-02.txt? > > Are there any other reasons? > > Thanks, > Andy > > --------- > > At 6/10/2003 09:22 AM -0400, Himanshu Shah wrote: > >Luca, > > > >I am glad that you have recognized the need for > >conveying the link status as compared to withdrawing > >the VC-LABEL for the same and Toby has good > >proposal. > > > >However, I would like PWE3 to approach this slightly > >differently as described in > >draft-shah-pwe3-control-protocol-extension-00.txt. > > > >We need a +generic mechanism+ to relay "dynamic > >attributes" of the PW, including the status of the AC (and > >yes, it should be AC or PW status as compared to link status). > >The generic mechanism can then be used to extend > >control signaling without having to constantly change > >the base draft. > > > >The extension draft proposes that such PW attributes > >be included in "optional parameter" field of the Label > >mapping message. The advantage of this approach is, > > > >1) conveying of one or more dynamic attributes in a > > single label mapping message. Extension draft describes > > IP addr (needed for ARP-mediation) , IP+MAC addr (needed > > for IPLS), QOS, tunnel mechanisms used, etc TLVs. > >2) a way to include these attributes in first mapping msg > > as compared to a follow-on status msgs (for example, > > PE does not know the status of the remote AC until > > link status msg follows the initial label mapping msg) > >3) allows update of the attributes. When dynamic attribute > > changes, an update is sent without withdrawing the VC-FEC > >4 ) allows definitions of new attributes without > > modifying base LDP or martini signaling draft > > > >I would like PWE3 to consider this approach. > > > >/himanshu > >wavesmith networks > > > > _______________________________________________ > 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: Sasha Vainshtein Subject: RE: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 12 Jun 2003 11:22:33 +0200 Lines: 17 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Israel Sasson , Akiva Sadovski , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Thu Jun 12 10:30:28 2003 Return-path: To: "'Shahram Davari'" , "Stewart Bryant (E-mail)" , "Danny McPherson (E-mail)" , "PWE3 WG (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram and all, 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] ... snipped ... > Did you interoperate with TDMoIP? NO. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: David Zelig Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 11:38:06 +0200 Lines: 37 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-From: pwe3-admin@ietf.org Thu Jun 12 10:38:48 2003 Return-path: To: "'Luca Martini'" , 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 Luca, > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Thursday, June 12, 2003 1:07 AM > To: pwe3@ietf.org > Subject: Re: [PWE3] status signalling of MPLS PW state > > > Latest text, including some of the feedback. > > .Pb "Signaling of Pseudo Wire Link Status" > > .Pc "Use of Label Mappings." > The PEs MUST send PW label mapping messages to their peers as > soon as the PW > is configured and administratively enabled, regardless of the > CE interface > state. The PW label should not be withdrawn unless the user > administratively > configures the CE interface down (or the PW configuration is deleted > entirely). > A simple label withdraw method SHOULD also be supported as an > alternative. > Can you elaborate why CE facing user admin down you make a withdraw and not a status report? The PW has it's own admin status so if you want to force withdraw (without deleting the configuration) you can do it directly at the PW level. I believe it is good to separate the PW and CE admin status since you may want to administratively close the physical port while keeping the resources at the PW level. If there is operational need a combined administrative status to make both operations at once we can easily add it to the PW-MIB. David From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 12 Jun 2003 12:58:42 +0300 Lines: 21 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="WINDOWS-1255" Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Thu Jun 12 12:02:14 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcMwvsPobos8eWxoRyqwtIo67OSa4AAAgr9A To: "Alexander Vainshtein" , "Shahram Davari" , "PWE3 WG (E-mail)" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5C9xOm04719 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > Did you interoperate with TDMoIP? > NO. I was afraid that Sasha's email this would lead to this type of misunderstanding. As a favor to our friends at Axerra, RAD implemented CESoIP on a version of our low-end (software only) box by a software modification (i.e. removing the adaptation and changing the control word). This was a one-time effort on our part, and is not part of our standard product line. This cooperation between our two companies does NOT imply any that RAD has accepted CESoIP, nor that Axerra has adopted TDMoIP. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Michel Khouderchah Subject: Re: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 12 Jun 2003 03:06:12 -0700 Lines: 212 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 12 12:09:04 2003 Return-path: X-Sender: khouder@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Sasha Vainshtein In-Reply-To: X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CA6nm04998 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.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 h5CABCm06021 Status: O Saha, I have the following minor corrections/comments on your latest draft (BTW, the new additions are very useful!): 1. Section 6.2.3: =93 2. The packet payload size is: a) 16*n + floor((n+1)/2) for E1-Nx64 kbit/s b) 24*n + floor((n+1)/2) for T1/ESF-Nx64 kbit/s and T1/SF-Nx64 kbit/s=94 The above is Correct if n is odd, but when n is even floor((n+1)/2) should be changed to floor (n/2). 2. The following sentences in section 6.2.3 and 4.1.2 are inconsistent: Section 6.2.3 =93CESoPSN implementations supporting trunk-specific Nx64 kbit/s services with CAS MUST NOT carry more TDM data per packet than is contained in a single trunk multiframe=94 =85 =93All CESoPSN implementations supporting trunk-specific Nx64 kbit/s with CAS MUST support the default mode where a single CESoPSN packet carries exactly one trunk multiframe aligned with the packet payload. =93 Section 4.1.2. =93Note: For T1 trunks using SF format (12 frames per multiframe), CESoPSN preserves the structure comprising two consecutive trunk multiframes. This consideration is aligned with [ATM-CES].=94 The description in section 6.2.3 is true in the case of T1/ESF ( multiframe =3D 24 frames); However, in the case of T1/SF (multiframe =3D 12 frames) a single packet is actually carrying exactly two multiframes not one. The proposed structure is certainly aligned with [ATM-CES], but the phrases =93exactly one trunk multiframe=94 or =93single trunk multiframe=94 are a bit misleading in the case of T1/SF. I would suggest rewording of the statements in section 6.2.3. Regards, Michel At 09:12 AM 6/10/2003, Sasha Vainshtein wrote: >Stewart, Danny and all, >As (some of) you have probably noticed I have posted an >updated (-06) revision of the CESoPSN draft. > >I would like to ask the WG to adopt this draft as a WG item, >and this message is intended to initiate a TECHNICAL discussion >on this subject. > > >Allow me to present my major points wrt the -06 revision: > >Compatibility with the Requirements and Architecture Documents >=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 > >The -06 revision of the draft explicitly answers the following requireme= nts: > >1. The requirements stated in the WG Charter >2. Common PWE3 requirements as stated in draft-ietf-pwe3-requirements-05= .txt >3. Specific requirements for emulation of TDM services as stated in > draft-ietf-pwe3-tdm-requirements-00.txt >4. The PWE3 architectural principles as presented in >draft-ietf-pwe3-arch-03.txt. >5. Additional requirements that have been identified during discussions > in the WG and in the (unpublished) disucssions of the TDM design tea= m, > including ability to preserve packetization latency regardless of > the bit rate of the emulated Nx64 kbit/s service > >Formerly Raised Technical Issues >=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 > >The -06 revision of the draft addresses all the technical isssue >that have ever been raised with the previous revisions. In particular: > >1. It allows BW-saving suppression of RTP headers when the > information carried in these headers cannot contribute > to the truthfulness of the emulation >2. It defines a new mode for carrying trunk-specific Nx64 > kbit/s services with CAS which: > a) Does not mandate usage of RTP for synchronization between > TDM data and telephony application signaling > b) Does not break the principle of fixed packetization time > for emulation of TDM services >3. It defines, as mandatory, raw encapsulation of unstructured T1 > without any intermediate adaptation. > >Independent Interoperable Implementations >=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 > >A series of successful interoperability tests between >independent CESoPSN implementations has been completed lately. >The following ones have been publicly announced: > >1. http://www.rad.com/Article/0,6583,13305,00.html >2. http://www.axerra.com/pr15.html >3. http://www.axerra.com/pr16.html >4. http://www.reduxcom.com/News/Issues/030527_WiMark/index.html > > >I would like to ask the WG participants to break their silence and >to provide the input that is required to advance the subject of >TDM emulation over PSN in the WG. > >With best regards, > Sasha Vainshtein >email: sasha@axerra.com >tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > >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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Monday, June 09, 2003 1:45 PM > > Cc: midcom@ietf.org > > Subject: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : TDM Circuit Emulation Service over > > Packet Switched > > Network (CESoPSN) > > Author(s) : S. Vainshtein et al. > > Filename : draft-vainshtein-cesopsn-06.txt > > Pages : 38 > > Date : 2003-6-6 > > > > This document describes a method for encapsulating unstructured (T1, > > E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over > > packet-switching networks (PSN). In this regard, it > > complements similar > > work for SONET/SDH. > > > > Proposed PW encapsulation uses RTP for clock recovery and leverages > > RTP-based mixing capabilities for application state signaling between > > Customer Edge (CE) devices. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-vainshtein-cesopsn-06.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-vainshtein-cesopsn-06.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation o= n > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Michel Khouderchah Subject: Fwd: Re: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 12 Jun 2003 03:38:57 -0700 Lines: 568 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_68248295==_.ALT" Cc: stbryant@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 12 12:41:49 2003 Return-path: X-Sender: khouder@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Sasha@axerra.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 --=====================_68248295==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sasha, Correction to my previous comments. Please ignore the first comment. Your formula is correct. The second comment is still valid. Regards, Michel >Date: Thu, 12 Jun 2003 03:06:12 -0700 >To: Sasha Vainshtein >From: Michel Khouderchah >Subject: Re: [PWE3] FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt >Cc: stbryant@cisco.com, pwe3@ietf.org > >Saha, > >I have the following minor corrections/comments on your latest draft > (BTW, the new additions are very useful!): > >1. Section 6.2.3: > =93 2. The packet payload size is: > a) 16*n + floor((n+1)/2) for E1-Nx64 kbit/s > b) 24*n + floor((n+1)/2) for T1/ESF-Nx64 kbit/s and T1/SF-Nx64 > kbit/s=94 > >The above is Correct if n is odd, but when n is even floor((n+1)/2) > should be changed to floor (n/2). > > > >2. The following sentences in section 6.2.3 and 4.1.2 are inconsistent: > >Section 6.2.3 >=93CESoPSN implementations supporting trunk-specific Nx64 kbit/s services >with CAS MUST NOT carry more TDM data per packet than is contained in a >single trunk multiframe=94 =85 =93All CESoPSN implementations supporting >trunk-specific Nx64 kbit/s with CAS MUST support the default mode where > a single CESoPSN packet carries exactly one trunk multiframe aligned >with the packet payload. =93 > > >Section 4.1.2. >=93Note: For T1 trunks using SF format (12 frames per multiframe), >CESoPSN preserves the structure comprising two consecutive trunk >multiframes. This consideration is aligned with [ATM-CES].=94 > >The description in section 6.2.3 is true in the case of T1/ESF >( multiframe =3D 24 frames); However, in the case of T1/SF >(multiframe =3D 12 frames) a single packet is actually carrying >exactly two multiframes not one. The proposed structure >is certainly aligned with [ATM-CES], but the phrases =93exactly >one trunk multiframe=94 or =93single trunk multiframe=94 are a bit >misleading in the case of T1/SF. I would suggest rewording >of the statements in section 6.2.3. > >Regards, > >Michel > > > > >At 09:12 AM 6/10/2003, Sasha Vainshtein wrote: >>Stewart, Danny and all, >>As (some of) you have probably noticed I have posted an >>updated (-06) revision of the CESoPSN draft. >> >>I would like to ask the WG to adopt this draft as a WG item, >>and this message is intended to initiate a TECHNICAL discussion >>on this subject. >> >> >>Allow me to present my major points wrt the -06 revision: >> >>Compatibility with the Requirements and Architecture Documents >>=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 >> >>The -06 revision of the draft explicitly answers the following= requirements: >> >>1. The requirements stated in the WG Charter >>2. Common PWE3 requirements as stated in= draft-ietf-pwe3-requirements-05.txt >>3. Specific requirements for emulation of TDM services as stated in >> draft-ietf-pwe3-tdm-requirements-00.txt >>4. The PWE3 architectural principles as presented in >>draft-ietf-pwe3-arch-03.txt. >>5. Additional requirements that have been identified during discussions >> in the WG and in the (unpublished) disucssions of the TDM design team, >> including ability to preserve packetization latency regardless of >> the bit rate of the emulated Nx64 kbit/s service >> >>Formerly Raised Technical Issues >>=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 >> >>The -06 revision of the draft addresses all the technical isssue >>that have ever been raised with the previous revisions. In particular: >> >>1. It allows BW-saving suppression of RTP headers when the >> information carried in these headers cannot contribute >> to the truthfulness of the emulation >>2. It defines a new mode for carrying trunk-specific Nx64 >> kbit/s services with CAS which: >> a) Does not mandate usage of RTP for synchronization between >> TDM data and telephony application signaling >> b) Does not break the principle of fixed packetization time >> for emulation of TDM services >>3. It defines, as mandatory, raw encapsulation of unstructured T1 >> without any intermediate adaptation. >> >>Independent Interoperable Implementations >>=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 >> >>A series of successful interoperability tests between >>independent CESoPSN implementations has been completed lately. >>The following ones have been publicly announced: >> >>1. http://www.rad.com/Article/0,6583,13305,00.html >>2. http://www.axerra.com/pr15.html >>3. http://www.axerra.com/pr16.html >>4. http://www.reduxcom.com/News/Issues/030527_WiMark/index.html >> >> >>I would like to ask the WG participants to break their silence and >>to provide the input that is required to advance the subject of >>TDM emulation over PSN in the WG. >> >>With best regards, >> Sasha Vainshtein >>email: sasha@axerra.com >>tel: +972-3-7659993 (office) >> +972-8-9254948 (res.) >> +972-58-674833 (cell.) >> >> >> >> >>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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> > Sent: Monday, June 09, 2003 1:45 PM >> > Cc: midcom@ietf.org >> > Subject: I-D ACTION:draft-vainshtein-cesopsn-06.txt >> > >> > >> > A New Internet-Draft is available from the on-line >> > Internet-Drafts directories. >> > >> > >> > Title : TDM Circuit Emulation Service over >> > Packet Switched >> > Network (CESoPSN) >> > Author(s) : S. Vainshtein et al. >> > Filename : draft-vainshtein-cesopsn-06.txt >> > Pages : 38 >> > Date : 2003-6-6 >> > >> > This document describes a method for encapsulating unstructured (T1, >> > E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over >> > packet-switching networks (PSN). In this regard, it >> > complements similar >> > work for SONET/SDH. >> > >> > Proposed PW encapsulation uses RTP for clock recovery and leverages >> > RTP-based mixing capabilities for application state signaling between >> > Customer Edge (CE) devices. >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-06.txt >> > >> > To remove yourself from the IETF Announcement list, send a message to >> > ietf-announce-request with the word unsubscribe in the body >> > of the message. >> > >> > Internet-Drafts are also available by anonymous FTP. Login >> > with the username >> > "anonymous" and a password of your e-mail address. After logging in, >> > type "cd internet-drafts" and then >> > "get draft-vainshtein-cesopsn-06.txt". >> > >> > A list of Internet-Drafts directories can be found in >> > http://www.ietf.org/shadow.html >> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >> > >> > Internet-Drafts can also be obtained by e-mail. >> > >> > Send a message to: >> > mailserv@ietf.org. >> > In the body type: >> > "FILE /internet-drafts/draft-vainshtein-cesopsn-06.txt". >> > >> > NOTE: The mail server at ietf.org can return the document in >> > MIME-encoded form by using the "mpack" utility. To use this >> > feature, insert the command "ENCODING mime" before the "FILE" >> > command. To decode the response(s), you will need "munpack" or >> > a MIME-compliant mail reader. Different MIME-compliant >> > mail readers >> > exhibit different behavior, especially when dealing with >> > "multipart" MIME messages (i.e. documents which have been split >> > up into multiple messages), so check your local documentation on >> > how to manipulate these messages. >> > >> > >> > Below is the data which will enable a MIME compliant mail reader >> > implementation to automatically retrieve the ASCII version of the >> > Internet-Draft. >> > >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 --=====================_68248295==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sasha,

Correction to my previous comments.

Please ignore the first comment. Your formula is correct.
The second comment is still valid.

Regards,

Michel

Date: Thu, 12 Jun 2003 03:06:12 -0700
To: Sasha Vainshtein <Sasha@axerra.com>
From: Michel Khouderchah <khouder@cisco.com>
Subject: Re: [PWE3] FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt
Cc: stbryant@cisco.com, pwe3@ietf.org

Saha,

I have the following minor corrections/comments on your latest=20 draft
 (BTW, the new additions are very useful!):

1. Section      6.2.3:   
        =93 2. The packet payload size is:
         a) 16*n + floor((n+1)/2) for E1-Nx64 kbit/s
         b) 24*n + floor((n+1)/2) for T1/ESF-Nx64 kbit/s and T1/SF-Nx64
            kbit/s=94

The above is Correct if n is odd, but when n is even floor((n+1)/2)
 should be changed to floor (n/2).



2. The following sentences in section 6.2.3 and 4.1.2 are inconsistent:

Section      6.2.3
=93CESoPSN implementations supporting trunk-specific Nx64 kbit/s services
with CAS MUST NOT carry more TDM data per packet than is contained in a
single trunk multiframe=94  =85 =93All CESoPSN implementations supporti= ng
trunk-specific Nx64 kbit/s with CAS MUST support the default mode where
 a single CESoPSN packet carries exactly one trunk multiframe aligned
with the packet payload. =93


Section  4.1.2.
=93Note: For T1 trunks using SF format (12 frames per multiframe),
CESoPSN preserves the structure comprising two consecutive trunk
multiframes. This consideration is aligned with [ATM-CES].=94

The description in section 6.2.3  is true in the case of T1/ESF
( multiframe =3D 24 frames); However, in the case of T1/SF
(multiframe =3D 12 frames) a single packet is actually carrying
exactly two multiframes not one. The proposed structure 
is certainly aligned with [ATM-CES], but the phrases =93exactly
one trunk multiframe=94 or =93single trunk multiframe=94 are a bit
misleading in the case of T1/SF.  I would suggest rewording
of the statements in section 6.2.3.

Regards,

Michel




At 09:12 AM 6/10/2003, Sasha Vainshtein wrote:
Stewart, Danny and all,
As (some of) you have probably noticed I have posted an
updated (-06) revision of the CESoPSN draft.

I would like to ask the WG to adopt this draft as a WG item,
and this message is intended to initiate a TECHNICAL discussion
on this subject.


Allow me to present my major points wrt the -06 revision:

Compatibility with the Requirements and Architecture Documents
=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

The -06 revision of the draft explicitly answers the following requirements:

1. The requirements stated in the WG Charter
2. Common PWE3 requirements as stated in draft-ietf-pwe3-requirements-05.txt
3. Specific requirements for emulation of TDM services as stated in
   draft-ietf-pwe3-tdm-requirements-00.txt
4. The PWE3 architectural principles as presented in
draft-ietf-pwe3-arch-03.txt.
5. Additional requirements that have been identified during discussions
   in the WG and in the (unpublished) disucssions of the TDM design team,
   including ability to preserve packetization latency regardless of
   the bit rate of the emulated Nx64 kbit/s service

Formerly Raised Technical Issues
=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

The -06 revision of the draft addresses all the technical isssue
that have ever been raised with the previous revisions. In particular:

1. It allows BW-saving suppression of RTP headers when the
   information carried in these headers cannot contribute
   to the truthfulness of the emulation
2. It defines a new mode for carrying trunk-specific Nx64
   kbit/s services with CAS which:
   a) Does not mandate usage of RTP for synchronization between
      TDM data and telephony application signaling
   b) Does not break the principle of fixed packetization time
      for emulation of TDM services
3. It defines, as mandatory, raw encapsulation of unstructured T1
   without any intermediate adaptation.
 
Independent Interoperable Implementations
=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

A series of successful interoperability tests between
independent CESoPSN implementations has been completed lately.
The following ones have been publicly announced:

1.  http://www.rad.com/Article/0,6583,13305,00.html
2.  http://www.axerra.com/pr15.html
3.  http://www.axerra.com/pr16.html
4.  http://www.reduxcom.com/News/Issues/030527_WiMark/index.= html


I would like to ask the WG participants to break their silence and
to provide the input that is required to advance the subject of
TDM emulation over PSN in the WG.

With best regards,
            &nbs= p;            &n= bsp;         Sasha Vainshtein
email:     sasha@axerra.com <mailto:sasha@axer= ra.com>
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
 



With best regards,
            &nbs= p;            &n= bsp;         Sasha Vainshtein
email:     sasha@axerra.com <mailto:sasha@axer= ra.com>
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
 


> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Monday, June 09, 2003 1:45 PM
> Cc: midcom@ietf.org
> Subject: I-D ACTION:draft-vainshtein-cesopsn-06.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
>       Title  &= nbsp;        = : TDM Circuit Emulation Service over
> Packet Switched
>            =             &nbs= p;  Network (CESoPSN)
>       Author(s) &nb= sp;     : S. Vainshtein et al.
>       Filename &nbs= p;      : draft-vainshtein-cesopsn-06.txt
>       Pages  &= nbsp;        = : 38
>       Date  &n= bsp;         : 2003-6-6
>       
> This document describes a method for encapsulating unstructured  (T1,
> E1, T3, E3) and structured (n*DS0) TDM signals as pseudo-wires over
> packet-switching networks (PSN). In this regard, it
> complements similar
> work for SONET/SDH.
> 
> Proposed PW encapsulation uses RTP for clock recovery and leverages
> RTP-based mixing capabilities for application state signaling between
> Customer Edge (CE) devices.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-vainshtein-ces= opsn-06.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body
> of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>       "get draft-vainshtein-cesopsn-06.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ie= tf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>=       mailserv@ietf.org.
> In the body type:
>       "FILE= /internet-drafts/draft-vainshtein-cesopsn-06.txt".
>       
> NOTE: The mail server at ietf.org can return the= document in
>       MIME-encoded form by= using the "mpack" utility.  To use this
>       feature, insert the= command "ENCODING mime" before the "FILE"
>       command.  To= decode the response(s), you will need "munpack" or
>       a MIME-compliant= mail reader.  Different MIME-compliant
> mail readers
>       exhibit different= behavior, especially when dealing with
>=       "multipart"= MIME messages (i.e. documents which have been split
>       up into multiple= messages), so check your local documentation on
>       how to manipulate= these messages.
>=          = ;     
>=          = ;     
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
--=====================_68248295==_.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 09:40:57 -0400 Lines: 332 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C330E8.40FDD50E" X-From: pwe3-admin@ietf.org Thu Jun 12 15:48:11 2003 Return-path: To: Luca Martini , 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_01C330E8.40FDD50E Content-Type: text/plain; charset="iso-8859-1" Luca, Additional comments inline... > > The format of the Link Status TLV is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| Link Status (0x0700) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Where status is a 2 octet bit field: > > 0x0001 - Pseudo Wire Not Forwarding > 0x0002 - Local Customer-facing Interface Receive Error > 0x0004 - Local Customer-facing Interface Transmit Error > 0x0008 - Local Core-facing Interface Receive Error > 0x0010 - Local Core-facing Interface Transmit Error > I think it should be clarified that initially the PW should not forward packets until the link status message is received. The way I read the above (particularly the semantics for code points) is initially the PW is enabled and forwarding (just by receiving the label mapping) and an operational change can happen upon receiving a link status (could you clarify that. Thxs). I would have assumed that the logical behavior is initially the PW should be up (by keeping the label) but not in forwarding state *until* it receives a favorable status. In Himanshu's proposal the "not favorable status" can be communicated initially while the label is sent giving time for the pw to react well before receiving the link status message. I think it is important for the pw/pe to know the operational status *before* forwarding packets (this is valid for when pw is configured). A different comment requiring clarification, it seems the codepoint are just indicating problems. I think the remote end should as well receive codepoints that clear the problems (or some of the problems). I assume this is done through clearing the bit fields. > The presence of the lowest bit (PW Not Forwarding) acts only as a > summary of the other bit fields, or to convey a link-down > event for > which none of the other bits apply. > > The Link Status TLV is transported to the remote PW peer via a new > LDP message, the PW Link Status Message. > In fact the only case where the link status is effectively conveyed is when a group id is used (associated to that link). I suggest to rename that Link Status TLV to something reflecting both the pw/ac/interface/links/groups (maybe something along the lines of "PW status TLV", or "PE-side-PW status tlv", etc). > > Martini, et al. > [Page 14] > > > Internet Draft draft-ietf-pwe3-control-protocol-02.txt > December 2002 > > > The format of the PW Link Status Message is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| PW Link Status (0x0700) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW FEC TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Link Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional Parameters | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Why include the whole PW FEC TLV with its interface parameters, PW type, etc... > The rationale for using a new LDP message type instead of > resending > the PW FEC label mapping with an enclosed Link Status TLV is > twofold: first, when updating PW link status, there is no need to > convey actual label mapping information, and use of the Label > Mapping message requires the inclusion of a Label TLV. > Second, and > more importantly, when a PE's CE-facing interface encounters an > error, use of the new message allows the PE to send a single Link > Status message, using a PW FEC TLV with only the group ID set, to > denote this change in status for all affected PW connections. The > use of a PW FEC TLV with only group ID set is undefined for use in > Label Mapping messages. > > The other issue is we know there are two FEC TLVs (exclusive). I assume the case described here relates to the PWid FEC (with its PW ID field). In the case of Generalized ID FEC, there is no group_id field (unless the AGI field is used and is associated to the link)...but if it is an l2vpn, the most likely use of AGI will be to include a VPN-ID or global unique id representing the VPN membership of all the CEs (participating in that VPN). In that case, the link status TLV used for the group ID (style) won't work (unless the Generalized ID FEC will include another group_id field and a given vpn configured on a PE will be associated with one or many group-ids/ports...). This will require changing the generalized id fec...if not then the value of a separate status message is diminished in l2vpn case. I would like to see the status tlvs to work for both generalized id fec and PWid fec, and obviously should work for l2vpn cases. Aside: Why not have a separate draft for addressing operational status/link errors since this is optional for pw... Is it because the P bits (which we still are waiting to see it) is used in the vc type... Hamid. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C330E8.40FDD50E Content-Type: text/html; charset="iso-8859-1"
Luca,
 
Additional comments inline...

>
>     The format of the Link Status TLV is:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1|0|   Link Status (0x0700)    |      Length                   |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |         Status Code           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Where status is a 2 octet bit field:
>
>      0x0001 - Pseudo Wire Not Forwarding
>      0x0002 - Local Customer-facing Interface Receive Error
>      0x0004 - Local Customer-facing Interface Transmit Error
>      0x0008 - Local Core-facing Interface Receive Error
>      0x0010 - Local Core-facing Interface Transmit Error
>

I think it should be clarified that initially the PW should not forward
packets until the link status message is received. The way I read the
above (particularly the semantics for code points) is initially the PW
is enabled and forwarding (just by receiving the label mapping) and an
operational change can happen upon receiving a link status (could you clarify
that. Thxs).
 
I would have assumed that the logical behavior is initially the PW
should be up (by keeping the label) but not in forwarding state
*until* it receives a favorable status. In Himanshu's proposal
the "not favorable status" can be communicated initially while the label is
sent giving time for the pw to react well before receiving the
link status message.
 
I think it is important for the pw/pe to know the operational
status *before* forwarding packets (this is valid for when pw is configured).
 
A different comment requiring clarification, it seems the codepoint
are just indicating problems. I think the remote end should as well
receive codepoints that clear the problems (or some of
the problems). I assume this is done through clearing the bit fields.

>     The presence of the lowest bit (PW Not Forwarding) acts only as a
>     summary of the other bit fields, or to convey a link-down
> event for
>     which none of the other bits apply.
>
>     The Link Status TLV is transported to the remote PW peer via a new
>     LDP message, the PW Link Status Message.
>
 
In fact the only case where the link status is effectively conveyed
is when a group id is used (associated to that link). I suggest
to rename that Link Status TLV to something reflecting both
the pw/ac/interface/links/groups (maybe something along
the lines of "PW status TLV", or "PE-side-PW status tlv", etc).

>
> Martini, et al.                                              
>  [Page 14]
> >
> Internet Draft  draft-ietf-pwe3-control-protocol-02.txt   
> December 2002
>
>
>     The format of the PW Link Status Message is:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1|   PW Link Status (0x0700)   |      Message Length           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                           Message ID                          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                           PW FEC TLV                          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Link Status TLV                       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                      Optional Parameters                      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
 
Why include the whole PW FEC TLV with its interface parameters, PW type,
etc...
 

>     The rationale for using a new LDP message type instead of
> resending
>     the PW FEC label mapping with an enclosed Link Status TLV is
>     twofold: first, when updating PW link status, there is no need to
>     convey actual label mapping information, and use of the Label
>     Mapping message requires the inclusion of a Label TLV. 
> Second, and
>     more importantly, when a PE's CE-facing interface encounters an
>     error, use of the new message allows the PE to send a single Link
>     Status message, using a PW FEC TLV with only the group ID set, to
>     denote this change in status for all affected PW connections.  The
>     use of a PW FEC TLV with only group ID set is undefined for use in
>     Label Mapping messages.
>
>
 
The other issue is we know there are two FEC TLVs (exclusive). I assume
the case described here relates to the PWid FEC (with its PW ID field).
 
In the case of Generalized ID FEC, there is no group_id field
(unless the AGI  field is used and is associated to the link)...but if
it is an l2vpn, the most likely use of AGI will be to include a VPN-ID or
global unique id representing the VPN membership of all the CEs (participating
in that VPN). In that case, the link status TLV used for the
group ID (style) won't work (unless the Generalized ID
FEC will include another group_id field and a given vpn configured
on a PE will be associated with one or many group-ids/ports...).
This will require changing the generalized id fec...if not then the value
of a separate status message is diminished in l2vpn case.
 
I would like to see the status tlvs to work for both generalized id
fec and PWid fec, and obviously should work for l2vpn cases.
 
Aside: Why not have a separate draft for addressing operational
status/link errors since this is optional for pw...
Is it because the P bits (which we still are waiting to
see it) is used in the vc type...
 
Hamid.

>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>
------_=_NextPart_001_01C330E8.40FDD50E-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 12 Jun 2003 06:46:52 -0700 Lines: 34 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Israel Sasson , Akiva Sadovski , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Thu Jun 12 15:54:38 2003 Return-path: To: "'Sasha Vainshtein'" , "Stewart Bryant (E-mail)" , "Danny McPherson (E-mail)" , "PWE3 WG (E-mail)" 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, Did RAD's box implement CESoPSN? -Shahram >-----Original Message----- >From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] >Sent: Thursday, June 12, 2003 5:23 AM >To: Shahram Davari; Stewart Bryant (E-mail); Danny McPherson >(E-mail); PWE3 WG (E-mail) >Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim >Frost (E-mail); Prayson Pate (E-mail) >Subject: RE: [PWE3] FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > >Shahram and all, >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] >... snipped ... >> Did you interoperate with TDMoIP? >NO. > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 11:00:51 -0400 Lines: 139 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C330F3.6A58568A" Cc: "Andrew G. Malis" , Luca Martini , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 12 17:04:50 2003 Return-path: To: "Andrew G. Malis" 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_01C330F3.6A58568A Content-Type: text/plain; charset="iso-8859-1" Andy, I meant given that now we have two solutions addressing the status problem from a different angle, and clearly there are issues/areas of discussions in both proposals. My suggestion is instead of selecting and incorporating one solution in the pw control draft, and then debating in the mailing list whether we agree on the problem and how are we solving it, why not first take these two proposals, work out a new draft (separate from the current control draft), state the problem, address the requirements and then describe a solution that meets these requirements taking into account items in both proposals. If at the end of the day we end up with exactly Luca/Toby's or Himanshu's proposal or something in between that is fine but at least the wg will have the confidence the proposal actually satisfies the requirements, and addresses most of the issues raised (and the whole wg will be winning at the end...). Hamid. Hamid, Well, they're really two alternative ways to extend LDP to convey the same information. The only way to really merge them would be to support them both .... Thanks, Andy --------- At 6/11/2003 04:48 PM -0400, Hamid Ould-Brahim wrote: Andy, [clipped]... > > I certainly agree that one or the other is needed, How about both proposals to be merged (when possible/applicable)? Hamid. ------_=_NextPart_001_01C330F3.6A58568A Content-Type: text/html; charset="iso-8859-1"
Andy,
 
I meant given that now we have two solutions addressing
the status problem from a different angle, and clearly there
are issues/areas of discussions in both proposals.
 
My suggestion is instead of selecting and incorporating one
solution in the pw control draft, and then debating in the
mailing list whether we agree on the problem
and how are we solving it, why not first take these two proposals,
work out a new draft (separate from the current control draft),
state the problem, address the requirements and then describe a
solution that meets these requirements taking into account
items in both proposals.
 
If at the end of the day we end up with exactly Luca/Toby's or
Himanshu's proposal or something in between that is fine but at least
the wg will have the confidence the proposal actually satisfies the
requirements, and addresses most of the issues raised (and
the whole wg will be winning at the end...).
 
Hamid.
 
Hamid,

Well, they're really two alternative ways to extend LDP to convey the same 
information.  The only way to really merge them would be to support them both ....

Thanks,
Andy

---------

At 6/11/2003 04:48 PM -0400, Hamid Ould-Brahim wrote:
Andy,

[clipped]...

>
> I certainly agree that one or the other is needed,

How about both proposals to be merged (when possible/applicable)?

Hamid.
------_=_NextPart_001_01C330F3.6A58568A-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 11:12:43 -0400 Lines: 86 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "Hamid Ould-Brahim" , X-From: pwe3-admin@ietf.org Thu Jun 12 17:18:19 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] status signalling of MPLS PW state Thread-Index: AcMwcQJHdLTz6i/aTCOQs+ezBFk/EQAgQ16Q To: "Luca Martini" , "Andrew G. Malis" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CFDKm31091 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 will furnish the text for use of each TLV. Note that not all TLVs are suitable for "update" mechanism. For example, QOS TLV. It is best that these parameters are provided at the time XC is programmed in the FIB and not after. We need a +generic+ mechanism to allow extensions without requesting changes in the base draft. Also, I am not convinced if it is necessary to convey the the reasons for "link down" to remote PE. I don't believe it is useful information as such. The problem is, for instance, if the link and/or PW is down, and notified, but the reasons have changed, should PE keep notifying the change of these reasons? /himanshu wavesmith networks > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Wednesday, June 11, 2003 7:03 PM > To: Andrew G. Malis > Cc: Hamid Ould-Brahim; pwe3@ietf.org > Subject: Re: [PWE3] status signalling of MPLS PW state > > > I read the following TLVs in the > draft-shah-pwe3-control-protocol-extension-00.txt : > > Operational Status TLV > IP Address TLV > IP+MAC Address TLV > Pseudowire QOS TLV > > > I think most of these are needed , but they need not all be > part of the FEC. > There are several bits available in the status TLV proposal, > can you please > specify what the use should be, and I can add it. > ( please note that the draft-shah does not propose much in > the area of status ) > > Thanks. > Luca > > > > > Andrew G. Malis wrote: > > Hamid, > > > > Well, they're really two alternative ways to extend LDP to > convey the > > same information. The only way to really merge them would > be to support > > them both .... > > > > Thanks, > > Andy > > > > --------- > > > > At 6/11/2003 04:48 PM -0400, Hamid Ould-Brahim wrote: > > > >> Andy, > >> > >> [clipped]... > >> > >> > > >> > I certainly agree that one or the other is needed, > >> > >> How about both proposals to be merged (when possible/applicable)? > >> > >> Hamid. > > > > > _______________________________________________ > 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: "Himanshu Shah" Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 11:26:17 -0400 Lines: 154 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 Jun 12 17:37:16 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] status signalling of MPLS PW state Thread-Index: AcMwcZsYvdKkyQHwSlajDO8x0CK1tAAg5/vg To: "Luca Martini" , "Andrew G. Malis" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CFQom31889 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O comments in line... > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Wednesday, June 11, 2003 7:06 PM > To: Andrew G. Malis > Cc: pwe3@ietf.org > Subject: Re: [PWE3] status signalling of MPLS PW state > > > > > Andrew G. Malis wrote: > > Luca, > > > > I would like to agree with Himanshu's message. > > > > To tell you the truth, I was a bit surprised to your > message proposing > > Toby's text for status signaling. I was under the > impression (perhaps > > mistaken?) that WG consensus had already been determined to accept > > draft-shah-pwe3-control-protocol-extension-00.txt and that > it was in the > > process of being incorporated into the main control signaling draft. > > > actually most of that draft belongs in PPVPN. I had only > agreed to consider it > , and WG feed back was that it is a good idea to have such mechanisms. > > lot's of reasons where in the text that I posted earlier. Himanshu> Actually none of the draft-shah-pwe3-control-protocol-extension-00.txt belongs to PPVPN. It is all related to signaling attributes of the PW. The main purpose of the draft is also to propose a mechanism which allows future extensions in backward compatible fashion without having anybody to keep requesting the changes in the base draft. > > > I certainly agree that one or the other is needed, and if I had to > > choose between them, the Operational Status TLV is > certainly easier to > > implement and less disruptive to existing LDP > implementations than the > > PW Link Status Message. Is there a really good reason why the > > Operational Status TLV can't work? > > > > I saw Toby's comment about only using the group ID to > reflect interface > > outages, but that's only useful if you have multiple parallel PWs > > between the same two logical interfaces at the edge of the > network (they > > have to share the same LDP session), which isn't going to > be all that > > common. I can tell you from experience in large FR and ATM > networks > > that end-to-end status signaling on a per-VC (per-PW in our > case) basis > > works just fine, even when you have interface outages. > > > Actually back in the san diego IETF there was a strong > request for the group ID > mechanisms for large NNI to NNI applications. > the down notification had to be immediate for 10000 PWs. > One other issue is that we would like to limit what goes into > this message. > There is a very limited set of useful failures at the PW > abstraction layer. > The TLVs proposed in > draft-shah-pwe3-control-protocol-extension-00 are useful > and need to be included where most appropriate. > Operational state in not a FEC, this is why I did not put > this in the interface > parameters.. > Himanshu> If group ID is important, operational status TLV of draft-shah can be extended to include group ID with a group ID present bit. When present, the status is applied to the whole group. regards, himanshu > Thanks. > Luca > > > > Are there any other reasons? > > > > Thanks, > > Andy > > > > --------- > > > > At 6/10/2003 09:22 AM -0400, Himanshu Shah wrote: > > > >> Luca, > >> > >> I am glad that you have recognized the need for > >> conveying the link status as compared to withdrawing > >> the VC-LABEL for the same and Toby has good > >> proposal. > >> > >> However, I would like PWE3 to approach this slightly > >> differently as described in > >> draft-shah-pwe3-control-protocol-extension-00.txt. > >> > >> We need a +generic mechanism+ to relay "dynamic > >> attributes" of the PW, including the status of the AC (and > >> yes, it should be AC or PW status as compared to link status). > >> The generic mechanism can then be used to extend > >> control signaling without having to constantly change > >> the base draft. > >> > >> The extension draft proposes that such PW attributes > >> be included in "optional parameter" field of the Label > >> mapping message. The advantage of this approach is, > >> > >> 1) conveying of one or more dynamic attributes in a > >> single label mapping message. Extension draft describes > >> IP addr (needed for ARP-mediation) , IP+MAC addr (needed > >> for IPLS), QOS, tunnel mechanisms used, etc TLVs. > >> 2) a way to include these attributes in first mapping msg > >> as compared to a follow-on status msgs (for example, > >> PE does not know the status of the remote AC until > >> link status msg follows the initial label mapping msg) > >> 3) allows update of the attributes. When dynamic attribute > >> changes, an update is sent without withdrawing the VC-FEC > >> 4 ) allows definitions of new attributes without > >> modifying base LDP or martini signaling draft > >> > >> I would like PWE3 to consider this approach. > >> > >> /himanshu > >> wavesmith networks > >> > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 11:41:15 -0400 Lines: 121 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C330F9.0F3C755A" X-From: pwe3-admin@ietf.org Thu Jun 12 18:14:38 2003 Return-path: To: David Zelig , "'Luca Martini'" , 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_01C330F9.0F3C755A Content-Type: text/plain; charset="iso-8859-1" David, [clipped]... > > > > Can you elaborate why CE facing user admin down you make a > withdraw and not > a status report? > I am as well interested to know why a user admin down/change implies withdrawing the label. > The PW has it's own admin status so if you want to force > withdraw (without > deleting the configuration) you can do it directly at the PW level. I > believe it is good to separate the PW and CE admin status > since you may want > to administratively close the physical port while keeping the > resources at > the PW level. Agreed. Hamid. >If there is operational need a combined > administrative status > to make both operations at once we can easily add it to the PW-MIB. > > David > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C330F9.0F3C755A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] status signalling of MPLS PW state

David,

[clipped]...

> >
>
> Can you elaborate why CE facing user admin down = you make a
> withdraw and not
> a status report?
>

I am as well interested to know why a user admin = down/change
implies withdrawing the label.

> The PW has it's own admin status so if you want = to force
> withdraw (without
> deleting the configuration) you can do it = directly at the PW level. I
> believe it is good to separate the PW and CE = admin status
> since you may want
> to administratively close the physical port = while keeping the
> resources at
> the PW level.

Agreed.

Hamid.

>If there is operational need a combined
> administrative status
> to make both operations at once we can easily = add it to the PW-MIB.
>
> David
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C330F9.0F3C755A-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 11:54:47 -0400 Lines: 107 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "Hamid Ould-Brahim" , X-From: pwe3-admin@ietf.org Thu Jun 12 18:24:13 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] status signalling of MPLS PW state Thread-Index: AcMwcQJHdLTz6i/aTCOQs+ezBFk/EQAgQ16QAAIjZoA= To: "Himanshu Shah" , "Luca Martini" , "Andrew G. Malis" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CFtOm01394 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Also, note that draft-shah is backward compatible where capability of the remote peer is auto-learned based on presence/absence of operational status TLV in the initial label mapping message. /himanshu wavesmith networks > -----Original Message----- > From: Himanshu Shah > Sent: Thursday, June 12, 2003 11:13 AM > To: Luca Martini; Andrew G. Malis > Cc: Hamid Ould-Brahim; pwe3@ietf.org > Subject: RE: [PWE3] status signalling of MPLS PW state > > > I will furnish the text for use of each TLV. > > Note that not all TLVs are suitable for "update" > mechanism. For example, QOS TLV. It is best > that these parameters are provided at the time > XC is programmed in the FIB and not after. > > We need a +generic+ mechanism to allow > extensions without requesting changes in the base draft. > > Also, I am not convinced if it is necessary to convey the > the reasons for "link down" to remote PE. I don't > believe it is useful information as such. > > The problem is, for instance, if the link and/or PW is down, > and notified, but the reasons have changed, should PE keep > notifying the change of these reasons? > > /himanshu > wavesmith networks > > > -----Original Message----- > > From: Luca Martini [mailto:luca@level3.net] > > Sent: Wednesday, June 11, 2003 7:03 PM > > To: Andrew G. Malis > > Cc: Hamid Ould-Brahim; pwe3@ietf.org > > Subject: Re: [PWE3] status signalling of MPLS PW state > > > > > > I read the following TLVs in the > > draft-shah-pwe3-control-protocol-extension-00.txt : > > > > Operational Status TLV > > IP Address TLV > > IP+MAC Address TLV > > Pseudowire QOS TLV > > > > > > I think most of these are needed , but they need not all be > > part of the FEC. > > There are several bits available in the status TLV proposal, > > can you please > > specify what the use should be, and I can add it. > > ( please note that the draft-shah does not propose much in > > the area of status ) > > > > Thanks. > > Luca > > > > > > > > > > Andrew G. Malis wrote: > > > Hamid, > > > > > > Well, they're really two alternative ways to extend LDP to > > convey the > > > same information. The only way to really merge them would > > be to support > > > them both .... > > > > > > Thanks, > > > Andy > > > > > > --------- > > > > > > At 6/11/2003 04:48 PM -0400, Hamid Ould-Brahim wrote: > > > > > >> Andy, > > >> > > >> [clipped]... > > >> > > >> > > > >> > I certainly agree that one or the other is needed, > > >> > > >> How about both proposals to be merged (when possible/applicable)? > > >> > > >> Hamid. > > > > > > > > > _______________________________________________ > > 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: Sasha Vainshtein Subject: RE: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 12 Jun 2003 19:40:03 +0200 Lines: 20 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Israel Sasson , Akiva Sadovski , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Thu Jun 12 19:10:45 2003 Return-path: To: "'Shahram Davari'" , "Stewart Bryant (E-mail)" , "Danny McPherson (E-mail)" , "PWE3 WG (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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] > Sasha, > > Did RAD's box implement CESoPSN? YES. > > -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 12 Jun 2003 10:57:08 -0600 Lines: 14 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: Israel Sasson , Akiva Sadovski , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Thu Jun 12 19:45:15 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: Sasha Vainshtein , "Stewart Bryant (E-mail)" , "PWE3 WG (E-mail)" 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 If there are other folks that would like to see this document become a WG item please speak up now. -danny On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: > Stewart, Danny and all, > As (some of) you have probably noticed I have posted an > updated (-06) revision of the CESoPSN draft. > > I would like to ask the WG to adopt this draft as a WG item, > and this message is intended to initiate a TECHNICAL discussion > on this subject. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 16:09:21 -0600 Organization: Level3 Communications LLC. Lines: 52 Sender: pwe3-admin@ietf.org References: <8FA6CEF9A4E42B48A5F8DC038655B35301045842@mxtlv1.corrigent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 13 05:42: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: 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 ooops. this is a typo. it should say PE. the text "the CE interface down" should read "the CE facing interface down" This is equivalent to removing the configuration. We could remove this text , it was just here for clarification. Luca David Zelig wrote: > Luca, > > >>-----Original Message----- >>From: Luca Martini [mailto:luca@level3.net] >>Sent: Thursday, June 12, 2003 1:07 AM >>To: pwe3@ietf.org >>Subject: Re: [PWE3] status signalling of MPLS PW state >> >> >>Latest text, including some of the feedback. >> >>.Pb "Signaling of Pseudo Wire Link Status" >> >>.Pc "Use of Label Mappings." >>The PEs MUST send PW label mapping messages to their peers as >>soon as the PW >>is configured and administratively enabled, regardless of the >>CE interface >>state. The PW label should not be withdrawn unless the user >>administratively >>configures the CE interface down (or the PW configuration is deleted >>entirely). >>A simple label withdraw method SHOULD also be supported as an >>alternative. >> > > > Can you elaborate why CE facing user admin down you make a withdraw and not > a status report? > > The PW has it's own admin status so if you want to force withdraw (without > deleting the configuration) you can do it directly at the PW level. I > believe it is good to separate the PW and CE admin status since you may want > to administratively close the physical port while keeping the resources at > the PW level. If there is operational need a combined administrative status > to make both operations at once we can easily add it to the PW-MIB. > > David > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 12 Jun 2003 11:12:54 -0700 Lines: 39 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: Israel Sasson , Akiva Sadovski , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Fri Jun 13 07:58:19 2003 Return-path: To: "'Danny McPherson'" , Sasha Vainshtein , "Stewart Bryant (E-mail)" , "PWE3 WG (E-mail)" 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 Danny, I think my view is known. I prefer the Anavi draft (aka TDMoIP), due to its usage of a known and proven technology (i.e, AAL1) and its ease of interworking with ATM CES. Yours, -Shahram >-----Original Message----- >From: Danny McPherson [mailto:danny@tcb.net] >Sent: Thursday, June 12, 2003 12:57 PM >To: Sasha Vainshtein; Stewart Bryant (E-mail); PWE3 WG (E-mail) >Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim Frost >(E-mail); Prayson Pate (E-mail) >Subject: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > >If there are other folks that would like to see this document >become a WG >item please speak up now. > >-danny > >On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: > >> Stewart, Danny and all, >> As (some of) you have probably noticed I have posted an >> updated (-06) revision of the CESoPSN draft. >> >> I would like to ask the WG to adopt this draft as a WG item, >> and this message is intended to initiate a TECHNICAL discussion >> on this subject. > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Fri, 13 Jun 2003 09:00:24 +0300 Lines: 19 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 Fri Jun 13 11:45:32 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcMxDGvItMIECVp3S3ONU0jBvju2iwAY9VEg To: "Danny McPherson" , "Alexander Vainshtein" , "Stewart Bryant (E-mail)" , "PWE3 WG (E-mail)" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5D61gm28183 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 there are other folks that would like to see this document > become a WG item please speak up now. Other than Sasha finally making RTP optional, I don't see anything new in this revision that could influence our decision. Hence, I am very much AGAINST adopting this draft in any form. If, however, we go back to draft-johnson and make the pointer mechanism mandatory (so that the structured mode is not an "unstructured structured" mode) and fix up a few other minor errors, then I would be willing to support that becoming a WG draft. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Andrew G. Malis" Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 15:01:47 -0400 Lines: 123 Sender: pwe3-admin@ietf.org References: <049AAFED91851244B9FF74D0D9D0EB7202150109@WHISTLER.WaveSmit hNet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Himanshu Shah" , "Luca Martini" , "Andrew G. Malis" , "Hamid Ould-Brahim" , X-From: pwe3-admin@ietf.org Fri Jun 13 12:02:49 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: "Himanshu Shah" In-Reply-To: <049AAFED91851244B9FF74D0D9D0EB7202150109@WHISTLER.WaveSmit hNet.com> X-OriginalArrivalTime: 12 Jun 2003 19:01:56.0230 (UTC) FILETIME=[17F1C260:01C33115] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Having caught up on this email thread, I'm ready to agree that both mechanisms are necessary - the Operational Status TLV to carry end-to-end status signaling from and to LMI/ILMI/PVC status signaling at the endpoints, and the PW Link Status Message to reflect interface and PW outages. I also agree with David that in a "PVC" environment labels should only be withdrawn when the PW is administratively destroyed (the LERs/PEs have been instructed to release the resources associated with the PW). In an "SVC" environment, labels would be withdrawn as a result of a signaled CLEAR from the CE. Thanks, Andy -------- At 6/12/2003 11:54 AM -0400, Himanshu Shah wrote: >Also, note that draft-shah is backward compatible >where capability of the remote peer is auto-learned >based on presence/absence of operational status TLV >in the initial label mapping message. > >/himanshu >wavesmith networks > > > -----Original Message----- > > From: Himanshu Shah > > Sent: Thursday, June 12, 2003 11:13 AM > > To: Luca Martini; Andrew G. Malis > > Cc: Hamid Ould-Brahim; pwe3@ietf.org > > Subject: RE: [PWE3] status signalling of MPLS PW state > > > > > > I will furnish the text for use of each TLV. > > > > Note that not all TLVs are suitable for "update" > > mechanism. For example, QOS TLV. It is best > > that these parameters are provided at the time > > XC is programmed in the FIB and not after. > > > > We need a +generic+ mechanism to allow > > extensions without requesting changes in the base draft. > > > > Also, I am not convinced if it is necessary to convey the > > the reasons for "link down" to remote PE. I don't > > believe it is useful information as such. > > > > The problem is, for instance, if the link and/or PW is down, > > and notified, but the reasons have changed, should PE keep > > notifying the change of these reasons? > > > > /himanshu > > wavesmith networks > > > > > -----Original Message----- > > > From: Luca Martini [mailto:luca@level3.net] > > > Sent: Wednesday, June 11, 2003 7:03 PM > > > To: Andrew G. Malis > > > Cc: Hamid Ould-Brahim; pwe3@ietf.org > > > Subject: Re: [PWE3] status signalling of MPLS PW state > > > > > > > > > I read the following TLVs in the > > > draft-shah-pwe3-control-protocol-extension-00.txt : > > > > > > Operational Status TLV > > > IP Address TLV > > > IP+MAC Address TLV > > > Pseudowire QOS TLV > > > > > > > > > I think most of these are needed , but they need not all be > > > part of the FEC. > > > There are several bits available in the status TLV proposal, > > > can you please > > > specify what the use should be, and I can add it. > > > ( please note that the draft-shah does not propose much in > > > the area of status ) > > > > > > Thanks. > > > Luca > > > > > > > > > > > > > > > Andrew G. Malis wrote: > > > > Hamid, > > > > > > > > Well, they're really two alternative ways to extend LDP to > > > convey the > > > > same information. The only way to really merge them would > > > be to support > > > > them both .... > > > > > > > > Thanks, > > > > Andy > > > > > > > > --------- > > > > > > > > At 6/11/2003 04:48 PM -0400, Hamid Ould-Brahim wrote: > > > > > > > >> Andy, > > > >> > > > >> [clipped]... > > > >> > > > >> > > > > >> > I certainly agree that one or the other is needed, > > > >> > > > >> How about both proposals to be merged (when possible/applicable)? > > > >> > > > >> Hamid. > > > > > > > > > > > > > _______________________________________________ > > > 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: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 17:47:19 -0600 Organization: Level3 Communications LLC. Lines: 118 Sender: pwe3-admin@ietf.org References: <049AAFED91851244B9FF74D0D9D0EB720215010E@WHISTLER.WaveSmithNet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 13 15:18:31 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- 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 Today's revision has the following fixes: - replaced CE with CE-Facing - PW FEC should not contain interface parameters - faults can be cleared by clearing respective bits. Outstanding issues: - TLV value needs coordination/lookup appropriate one. - how to make this work better with label withdraw mode. - Ignore Bit: should it be set ? Other points : - I really would like not to have this be flexible to allow an infinite amount of status messages allocated without WG study and RFC update and proper documentation. - the "let's split it because we can't agree" method has been exhausted. I do not believe that there is much support for creating any more drafts from splits. - can somebody enumerate any faults that are not included here , that a PW can experience ? In general we initially reserved the PW FEC, and interface parameters, for PW specific information , that would not change, and if incompatible it would cause an error and the PW would not be enabled. Special information such as IP addresses, and QoS congestion messages, Qos requests ..etc that CAN change once the PW is operational need to be in a different message. NOT a label mapping message ! We could call this message a PW dynamic parameter ( or some better name, below called the PW link status message ) and this is mostly what is in draft-shah. The status of the PW should be a TLV in this message. OTher TLVs will specify other proprieties of the PW. we then spec the status TLV, and message in this draft , and the other TLVs elsewhere. This thread is very constructive , thanks for all the reading and comments. Luca this is today's version, tomorrow will definitely be different ..... .Pb "Signaling of Pseudo Wire Link Status" .Pc "Use of Label Mappings." The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the CE-facing interface state. The PW label should not be withdrawn unless the user administratively configures the CE-facing interface down (or the PW configuration is deleted entirely). A simple label withdraw method SHOULD also be supported as an alternative. .Pc "Signaling PW Link status." When PWLE mode is in use, the PE devices use a new LDP TLV to indicate status to their remote peers, instead of withdrawing their PW FEC labels. This Link Status TLV contains more information than the simple Label Withdraw message used in the baseline signaling. The format of the Link Status TLV is: .DS 0 0 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Link Status (0x0700) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .DE Where status is a 2 octet bit field: .nf 0x0000 - Pseudo Wire forwarding ( clear all failures ) 0x0001 - Pseudo Wire Not Forwarding 0x0002 - Local Customer-facing Interface Receive Fault 0x0004 - Local Customer-facing Interface Transmit Fault 0x0008 - Local Core-facing Interface Receive Fault 0x0010 - Local Core-facing Interface Transmit Fault .En The above status codes can be logically combined to indicate more then a single failure at once. Each fault can be cleared by sending an appropriate status message with the respective bit cleared. The presence of the lowest bit (PW Not Forwarding) acts only as a generic failure indication when there is a link-down event for which none of the other bits apply. The Link Status TLV is transported to the remote PW peer via a new LDP message, the PW Link Status Message. The format of the PW Link Status Message is: .DS 0 0 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| PW Link Status (0x0700) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .DE The PW FEC TLV SHOULD not include the interface parameters as they are ignored in the context of this message. When a PE's CE-facing interface encounters an error, use of the new message allows the PE to send a single Link Status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-fragmentation-01.txt Date: Fri, 13 Jun 2003 07:51:19 -0400 Lines: 79 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 13 15:57:05 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Fragmentation and Reassembly Author(s) : A. Malis, W. Townsley Filename : draft-ietf-pwe3-fragmentation-01.txt Pages : 11 Date : 2003-6-12 This document defines a generalized method of performing fragmentation for use by PWE3 protocols and services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-fragmentation-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-fragmentation-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 15:34:38 -0400 Lines: 291 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33119.A9CFC93A" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 13 16:17:18 2003 Return-path: To: Himanshu Shah , Luca Martini , "Andrew G. Malis" 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_01C33119.A9CFC93A Content-Type: text/plain; charset="iso-8859-1" Himanshu, > > > Also, note that draft-shah is backward compatible > where capability of the remote peer is auto-learned > based on presence/absence of operational status TLV > in the initial label mapping message. > Since we are debating this topic here are some comments as well on your draft. >"4.1 Operational Status TLV > > The Operational Status TLV is used to notify the remote PE peer > about the change in operational status of the attached circuit or > the tunnel carrying the PW. The exchange of this information is an > alternative to the current practice of withdrawing the PW label for > such circumstances. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| Status TLV (TBD) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | type | status | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > If a given PE doesn't understand status TLV and receives the status TLV from another PE mentioning "down", given that the U bit is set to 1 that PE will ignore the status TLV. The question is what should the sender PE do: - Assume that the remote PE doesn't intend to use Status TLV (by virtue of receiving a reverse label mapping with no status TLV included) and decides to accept the label, and follow normal PW procedure with no status TLV. I have assumed this the case for your draft. or - keep the label and wait for the remote PE to send the status TLV... or just - withdraw the label It looks to me if a PE sends the status "down" it expects the receiver to react to that...Why not give the choice for the PE to impose whether the Status TLV is mandatory or not. Now assume the other case, a PE understands status TLV but it received a normal label mapping (with no status tlv) from a given PE. It concluded that the remote PE doesn't understand status TLV while in fact the remote PE didn't include it. Should the draft impose that if a PE supports status TLV therefore it MUST include it in the label mapping (basically that is the default behavior). If it is not a must, what will be the behavior for both sender and receiver when a given PW is up through normal procedures and then the operator configures that status TLV needs to be sent? I think sending the status per label mapping (pw) basis (initially) for each PW even when the remote PE doesn't support the status TLV has an impact on cpu cycles for the sender (the status TLVs will end up being ignored anyway). I think in that case negotiation or capability advertisement can be useful done at the PE/session levels. > 16-bit value is used to identify the interface type. A value of 1 > means operational status is for the attachment circuit. A value of > 2 means that operational status is for the unidirectional portion > of the PW that spans from advertising PE to the receiving PE. If I have more than one status to convey I assume the label mapping will carry multiple status TLVs. Since the above text indicates two types, why not have in a single status TLV both types and values conveyed. > Status > 16-bit value specifies the operational status. A value of 0 means > that AC or PW is down or inactive while a value of 1 means that AC > or PW is up or active. Why 16 bits are needed while only 0 and 1 values have effective meanings (up/down)? > > The absence of status TLV in optional parameter of Label Mapping > message for the VC-FEC must not be interpreted as status down. Does the absence of status TLV interpreted as the remote PE doesn't support/intend to use status TLV? >In > fact, PEs should assume operational status of the remote attachment > circuit and incoming PW as operational unless notified otherwise. > The operational status down must then be followed by operational > status up in order for remote PE to resume traffic. > The sender has the responsibility to coordinate the status > notifications. The receiver may or may not react to these > notifications. Could you clarify what it means the receiver may or may not react. In what scenario (as examples) the receiver may not react. Hamid. ------_=_NextPart_001_01C33119.A9CFC93A Content-Type: text/html; charset="iso-8859-1" Himanshu,

>
>
> Also, note that draft-shah is backward compatible
> where capability of the remote peer is auto-learned
> based on presence/absence of operational status TLV
> in the initial label mapping message.
>

Since we are debating this topic here are some comments
as well on your draft.
 
 
>"4.1 Operational Status TLV
>   
>   The Operational Status TLV is used to notify the remote PE peer
>   about the change in operational status of the attached circuit or
>   the tunnel carrying the PW. The exchange of this information is an
>   alternative to the current practice of withdrawing the PW label for
>   such circumstances. 
>   
>       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
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |1|0| Status TLV  (TBD)         |      Length                   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |        type                   |           status              |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>    
If a given PE doesn't understand status TLV and receives the status TLV
from another PE mentioning "down", given that the U bit is set to 1 that
PE will ignore the status TLV. The question is what should the sender PE do:
 
- Assume that the remote PE doesn't intend to use Status TLV 
  (by virtue of receiving a reverse label mapping with no
  status TLV included) and decides to accept the label, and follow
  normal PW procedure with no status TLV. I have assumed this
  the case for your draft. or
 
- keep the label and wait for the remote PE to send the status TLV...
 
or just
 
- withdraw the label
 
It looks to me if a PE sends the status "down" it expects
the receiver to react to that...Why not give the choice for the PE
to impose whether the Status TLV is mandatory or not.
 
Now assume the other case, a PE understands status TLV but it
received a normal label mapping (with no status tlv) from a given PE.
It concluded that the remote PE doesn't understand status TLV while
in fact the remote PE didn't include it. Should the draft impose that
if a PE supports status TLV therefore it MUST include it in
the label mapping (basically that is the default behavior).
If it is not a must, what will be the behavior
for both sender and receiver when a given PW is up through normal
procedures and then the operator configures that status TLV needs
to be sent?
 
I think sending the status per label mapping
(pw) basis (initially) for each PW even when the remote PE
doesn't support the status TLV has an impact on cpu cycles
for the sender (the status TLVs will end up being ignored
anyway). I think in that case negotiation or capability advertisement 
can be useful done at the PE/session levels.
 
>     16-bit value is used to identify the interface type. A value of 1 
>    means operational status is for the attachment circuit. A value of
>     2 means that operational status is for the unidirectional portion
>     of the PW that spans from advertising PE to the receiving PE. 
 
If I have more than one status to convey I assume the label mapping will
carry multiple status TLVs. Since the above text indicates two types,
why not have in a single status TLV both types and values
conveyed. 

      
>   Status
>     16-bit value specifies the operational status. A value of 0 means
>     that AC or PW is down or inactive while a value of 1 means that AC
>     or PW is up or active.
 
Why 16 bits are needed while only 0 and 1 values have effective meanings
(up/down)?

>     
>   The absence of status TLV in optional parameter of Label Mapping
>   message for the VC-FEC must not be interpreted as status down.
 
Does the absence of status TLV interpreted as the remote
PE doesn't support/intend to use status TLV?
 
>In
>   fact, PEs should assume operational status of the remote attachment
>   circuit and incoming PW as operational unless notified otherwise.
>   The operational status down must then be followed by operational
>   status up in order for remote PE to resume traffic. 
        
>  The sender has the responsibility to coordinate the status
>   notifications. The receiver may or may not react to these
>   notifications. 
 
Could you clarify what it means the receiver may or may not
react. In what scenario (as examples) the receiver may not react.   
 
Hamid.
------_=_NextPart_001_01C33119.A9CFC93A-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Himanshu Shah" Subject: RE: status signalling of MPLS PW state Date: Thu, 12 Jun 2003 17:41:50 -0400 Lines: 667 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3312B.6EB6D90C" Cc: X-From: pwe3-admin@ietf.org Fri Jun 13 17:38:27 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] status signalling of MPLS PW state Thread-Index: AcMxGbFsxV7S8kUDQDC4nDb0fR+LVQACATBw To: "Hamid Ould-Brahim" , "Luca Martini" , "Andrew G. Malis" Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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_01C3312B.6EB6D90C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] Sent: Thursday, June 12, 2003 3:35 PM To: Himanshu Shah; Luca Martini; Andrew G. Malis Cc: pwe3@ietf.org Subject: RE: [PWE3] status signalling of MPLS PW state Himanshu, > > > Also, note that draft-shah is backward compatible > where capability of the remote peer is auto-learned > based on presence/absence of operational status TLV > in the initial label mapping message. > Since we are debating this topic here are some comments as well on your draft. =20 =20 >"4.1 Operational Status TLV=20 > =20 > The Operational Status TLV is used to notify the remote PE peer=20 > about the change in operational status of the attached circuit or=20 > the tunnel carrying the PW. The exchange of this information is an=20 > alternative to the current practice of withdrawing the PW label for=20 > such circumstances. =20 > =20 > 0 1 2 3=20 > 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=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = > |1|0| Status TLV (TBD) | Length | = > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = > | type | status | = > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = > =20 If a given PE doesn't understand status TLV and receives the status TLV from another PE mentioning "down", given that the U bit is set to 1 that = PE will ignore the status TLV. The question is what should the sender PE = do: =20 - Assume that the remote PE doesn't intend to use Status TLV=20 (by virtue of receiving a reverse label mapping with no status TLV included) and decides to accept the label, and follow=20 normal PW procedure with no status TLV. I have assumed this the case for your draft. or [Himanshu>] Correct. At the end of initial label exchange both PEs = should know what other is capable of and revert to default if either one is not capable of = status TLV. This assumes that both PE must include operational status TLV if they are capable of = and intend to use it in the initial label mapping msg. It determines the behaviour and = remains in force until labels are withdrawn and re-advertised which is when = behaviour mode is set based on each others capability.=20 =20 - keep the label and wait for the remote PE to send the status TLV... =20 or just =20 - withdraw the label =20 It looks to me if a PE sends the status "down" it expects the receiver to react to that...Why not give the choice for the PE=20 to impose whether the Status TLV is mandatory or not.=20 [Himanshu>] see above. Only when both PEs have exchanged status TLV,=20 status TLVs are used subsequetly. If one is capable and other is not, = they both revert to traditional "label withdraw" mechanism.=20 =20 Now assume the other case, a PE understands status TLV but it received a normal label mapping (with no status tlv) from a given PE. It concluded that the remote PE doesn't understand status TLV while in fact the remote PE didn't include it. Should the draft impose that if a PE supports status TLV therefore it MUST include it in the label mapping (basically that is the default behavior). If it is not a must, what will be the behavior=20 for both sender and receiver when a given PW is up through normal=20 procedures and then the operator configures that status TLV needs=20 to be sent? [Himanshu>] Yes. It MUST include if he is capable and intends to use it. = If he is capable but does not intend to use, both must revert to label-withdraw = method.=20 =20 =20 I think sending the status per label mapping (pw) basis (initially) for each PW even when the remote PE doesn't support the status TLV has an impact on cpu cycles for the sender (the status TLVs will end up being ignored=20 anyway). I think in that case negotiation or capability advertisement=20 can be useful done at the PE/session levels. [Himanshu>] I don't believe the impact is significant. Nodal capa nego = is useful but it would be new and not backward compatible=20 =20 > 16-bit value is used to identify the interface type. A value of 1=20 > means operational status is for the attachment circuit. A value of=20 > 2 means that operational status is for the unidirectional portion=20 > of the PW that spans from advertising PE to the receiving PE.=20 =20 If I have more than one status to convey I assume the label mapping will carry multiple status TLVs. Since the above text indicates two types, why not have in a single status TLV both types and values conveyed.=20 =20 > Status=20 > 16-bit value specifies the operational status. A value of 0 means=20 > that AC or PW is down or inactive while a value of 1 means that AC = > or PW is up or active.=20 =20 Why 16 bits are needed while only 0 and 1 values have effective meanings (up/down)?=20 [Himanshu>] You are correct. They should be combined and perhaps if = there is no value to classify, there should be then only one indication up or = down irrespective of it being AC or PW.=20 > =20 > The absence of status TLV in optional parameter of Label Mapping=20 > message for the VC-FEC must not be interpreted as status down.=20 =20 Does the absence of status TLV interpreted as the remote PE doesn't support/intend to use status TLV?=20 =20 [Himanshu>] You are correct that this section needs to be clarified with = respect=20 to capability learning. My thinking is following, 1) PEs must exchange status in the XC building label mapping msg = (initial or the one after the withdrawal) 2) Subsequently, PEs practice status exchange only when both are capable 3) Absence of status TLV (for that matter any other optional TLVs) in = non-XC building=20 label mapping msg indicate no change in status (or other TLVs). This = allows label=20 mapping msgs to be exchanged for updates of other TLVs without = having to=20 include full set all the time. =20 >In=20 > fact, PEs should assume operational status of the remote attachment=20 > circuit and incoming PW as operational unless notified otherwise.=20 > The operational status down must then be followed by operational=20 > status up in order for remote PE to resume traffic.=20 =20 > The sender has the responsibility to coordinate the status=20 > notifications. The receiver may or may not react to these=20 > notifications.=20 =20 Could you clarify what it means the receiver may or may not react. In what scenario (as examples) the receiver may not react. =20 [Himanshu>] this needs clarification too. What I mean is that sender = should not expect that remote PE will definitely stop the incoming the traffic (in = contrast to to the case if you were to use "label withdraw" method). If this was = VLAN, sender PE might be capable of GVRP (?right acronym) and receiver may not. This = is fundamental=20 difference between status msg exchange vs label withdraw method. =20 Thanks for the input. Himanshu=20 =20 =20 Hamid. ------_=_NextPart_001_01C3312B.6EB6D90C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
-----Original Message-----
From: Hamid Ould-Brahim=20 [mailto:hbrahim@nortelnetworks.com]
Sent: Thursday, June 12, = 2003=20 3:35 PM
To: Himanshu Shah; Luca Martini; Andrew G.=20 Malis
Cc: pwe3@ietf.org
Subject: RE: [PWE3] status = signalling of MPLS PW state

Himanshu,

>
>
> = Also, note that=20 draft-shah is backward compatible
> where capability of the = remote peer=20 is auto-learned
> based on presence/absence of operational = status=20 TLV
> in the initial label mapping = message.
>

Since we are debating = this topic=20 here are some comments
as well on your = draft.
 
 
>"4.1 Operational Status = TLV=20
>   
>   The Operational Status = TLV is=20 used to notify the remote PE peer
>   about the = change in=20 operational status of the attached circuit or
>   the = tunnel=20 carrying the PW. The exchange of this information is an =
>  =20 alternative to the current practice of withdrawing the PW label for=20
>   such circumstances.  =
>   =20
>      =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
>       0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5=20 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>      |1|0| Status TLV =20 (TBD)        =20 |     =20 = Length           &= nbsp;      =20 |
>     =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
>     =20 |       =20 = type           &nb= sp;      =20 |          =20 = status           &= nbsp; =20 |
>     =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >    
If a given PE doesn't = understand status=20 TLV and receives the status TLV
from another PE mentioning = "down",=20 given that the U bit is set = to 1 that=20
PE will ignore the status TLV. The question is what should the sender PE do:
 
- Assume that the remote = PE doesn't intend to use Status=20 TLV 
  (by virtue of = receiving a reverse=20 label mapping with no
  status TLV included) = and=20 decides to accept the = label, and follow=20
  normal PW procedure = with no status TLV. I have assumed = this
  the case for your = draft.=20 or
[Himanshu>] Correct. At the end = of initial label=20 exchange both PEs should know what=20 other
is capable=20 of and revert to default if either one is not capable of status = TLV.=20 This assumes
that=20 both PE must include operational status TLV if they are = capable of=20 and intend to
use it in=20 the initial label mapping msg. It determines the behaviour and remains=20 in
force until labels are withdrawn and = re-advertised=20 which is when behaviour mode
is set based on each others capability.=20
 
- keep the label and wait for = the remote=20 PE to send the status TLV...
 
or just
 
- withdraw the = label
 
It looks to me if a PE sends = the status=20 "down" it expects
the receiver to react to=20 that...Why not give the = choice for the=20 PE
to impose whether the = Status TLV is mandatory or not.
[Himanshu>] see above. = Only when=20 both PEs have exchanged status = TLV, 
status TLVs are used subsequetly. If one is = capable=20 and other is not, they
both revert to traditional "label = withdraw"=20 mechanism. 
 
Now assume the other = case, a PE=20 understands status TLV but it
received a normal label = mapping (with no=20 status tlv) from a given PE.
It concluded that the remote = PE doesn't=20 understand status TLV while
in fact the remote PE didn't = include it.=20 Should the draft impose that
if a PE supports status TLV = therefore it=20 MUST include it in
the label mapping (basically = that is the=20 default behavior).
If it is not a must, what = will be the=20 behavior
for both sender and receiver = when=20 a given PW is up through = normal=20
procedures and then the = operator=20 configures that status TLV = needs
to be sent?
[Himanshu>] Yes. It MUST include if he is = capable and=20 intends to use it. If he is
capable but=20 does not intend to use, both must revert to label-withdraw=20 method. 
 
 
I think sending the status = per label=20 mapping
(pw) basis (initially) for = each PW even=20 when the remote PE
doesn't support the status = TLV has an=20 impact on cpu cycles
for the sender (the status = TLVs will end=20 up being ignored
anyway). I think in that = case=20 negotiation or capability=20 advertisement 
can be useful done at the = PE/session=20 levels.
[Himanshu>] I don't believe the impact is = significant. Nodal capa nego is = useful
but it=20 would be new and not backward=20 compatible 
 
>     16-bit value is used to identify the = interface=20 type. A value of 1 
>    means operational = status is=20 for the attachment circuit. A value of =
>     2=20 means that operational status is for the unidirectional portion=20
>     of the PW that spans from advertising = PE to=20 the receiving PE. 
 
If I have more than one = status to convey=20 I assume the label mapping will
carry multiple status TLVs. = Since the=20 above text indicates two types,
why not have in a = single status TLV=20 both types and values
conveyed. 

      
>  =20 Status
>     16-bit value specifies the = operational=20 status. A value of 0 means
>     that AC or = PW is=20 down or inactive while a value of 1 means that AC=20
>     or PW is up or active.
 
Why 16 bits are needed while only 0 and 1 = values have=20 effective meanings
(up/down)?
[Himanshu>] You are = correct. They=20 should be combined and perhaps if there
is no value to classify, there should be then = only one=20 indication up or down
irrespective of it being AC or=20 PW. 

>     
>   The = absence of=20 status TLV in optional parameter of Label Mapping
>   = message=20 for the VC-FEC must not be interpreted as status down.
 
Does the absence of status TLV interpreted as the=20 remote
PE doesn't support/intend to use status = TLV? 
 
[Himanshu>] You are correct that this section = needs to=20 be clarified with respect=20
to capability learning. My thinking is=20 following,
1) PEs must=20 exchange status in the XC building label mapping msg (initial or = the=20 one
    after the=20 withdrawal)
2) Subsequently, PEs practice status=20 exchange only when both=20 are capable
3) Absence of status TLV (for that matter = any other=20 optional TLVs) in non-XC building
    label mapping msg = indicate no=20 change in status = (or other TLVs).=20 This allows label
    mapping msgs to be = exchanged for=20 updates of other TLVs without having to
    include full set all the = time.
 
=
>In
>   fact, PEs should = assume=20 operational status of the remote attachment
>   = circuit and=20 incoming PW as operational unless notified otherwise.
>   The operational status down must = then be=20 followed by operational
>   status up in order for = remote PE=20 to resume = traffic. 
        
>  The=20 sender has the responsibility to coordinate the status =
>  =20 notifications. The receiver may or may not react to these =
>  =20 notifications. 
 
Could you clarify what it = means the=20 receiver may or may not
react. In what scenario (as = examples) the=20 receiver may not react.   
[Himanshu>] this needs clarification too. What = I mean is=20 that sender should not
expect that remote PE will = definitely stop=20 the incoming the traffic (in contrast = to
to the case if you were to use = "label=20 withdraw" method). If=20 this was VLAN, sender
PE might be capable=20 of GVRP (?right acronym) and receiver may not. This is=20 fundamental 
difference between status msg exchange vs = label=20 withdraw method.
 
Thanks for the=20 input.
Himanshu 
<= /FONT>
 
 
Hamid.
------_=_NextPart_001_01C3312B.6EB6D90C-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Michel Khouderchah Subject: Re: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Fri, 13 Jun 2003 09:05:44 -0700 Lines: 31 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Sasha Vainshtein , "Stewart Bryant (E-mail)" , "PWE3 WG (E-mail)" , Israel Sasson , Akiva Sadovski , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Fri Jun 13 19:02:31 2003 Return-path: X-Sender: khouder@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Danny McPherson 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 Danny, I would like to see this draft become a WG item. The latest enhancements offer a good compromise to achieve convergence of Anavi and Johnson drafts. Regards, Michel At 09:57 AM 6/12/2003, Danny McPherson wrote: >If there are other folks that would like to see this document become a WG >item please speak up now. > >-danny > >On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: > > > Stewart, Danny and all, > > As (some of) you have probably noticed I have posted an > > updated (-06) revision of the CESoPSN draft. > > > > I would like to ask the WG to adopt this draft as a WG item, > > and this message is intended to initiate a TECHNICAL discussion > > on this subject. > >_______________________________________________ >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: "Andrew G. Malis" Subject: Fwd: I-D ACTION:draft-ietf-pwe3-fragmentation-01.txt Date: Fri, 13 Jun 2003 09:52:29 -0400 Lines: 75 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Fri Jun 13 19:11:59 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: pwe3@ietf.org X-OriginalArrivalTime: 13 Jun 2003 13:52:36.0992 (UTC) FILETIME=[0C308800:01C331B3] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 was resubmitted to keep it from expiring. The only change is an update on the references. Andy ------- Begin of Forwarded Message ------- To: IETF-Announce: ; Cc: pwe3@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-fragmentation-01.txt Date: Fri, 13 Jun 2003 07:51:19 -0400 Sender: owner-ietf-announce@ietf.org X-OriginalArrivalTime: 13 Jun 2003 13:27:55.0051 (UTC) FILETIME=[98E247B0:01C331AF] A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Fragmentation and Reassembly Author(s) : A. Malis, W. Townsley Filename : draft-ietf-pwe3-fragmentation-01.txt Pages : 11 Date : 2003-6-12 This document defines a generalized method of performing fragmentation for use by PWE3 protocols and services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-fragmentation-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-fragmentation-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2003-6-12132322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-fragmentation-01.txt ------- End of Forwarded Message ------- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Gregory Wright" Subject: RE: status signalling of MPLS PW state Date: Fri, 13 Jun 2003 08:01:44 -0400 Lines: 211 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C331A3.8F3CDFEC" Cc: "'pwe3@ietf.org'" X-From: pwe3-admin@ietf.org Fri Jun 13 19:26:24 2003 Return-path: To: "'Luca Martini'" , "'David Zelig'" 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_01C331A3.8F3CDFEC Content-Type: text/plain which means it should also release the label it received from the remote PE since the port has been "removed from the configuration"? > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Thursday, June 12, 2003 6:09 PM > To: David Zelig > Cc: pwe3@ietf.org > Subject: Re: [PWE3] status signalling of MPLS PW state > > > ooops. > this is a typo. it should say PE. > the text "the CE interface down" should read "the CE facing > interface down" > > This is equivalent to removing the configuration. > We could remove this text , it was just here for clarification. > > Luca > > > > David Zelig wrote: > > Luca, > > > > > >>-----Original Message----- > >>From: Luca Martini [mailto:luca@level3.net] > >>Sent: Thursday, June 12, 2003 1:07 AM > >>To: pwe3@ietf.org > >>Subject: Re: [PWE3] status signalling of MPLS PW state > >> > >> > >>Latest text, including some of the feedback. > >> > >>.Pb "Signaling of Pseudo Wire Link Status" > >> > >>.Pc "Use of Label Mappings." > >>The PEs MUST send PW label mapping messages to their peers as > >>soon as the PW > >>is configured and administratively enabled, regardless of the > >>CE interface > >>state. The PW label should not be withdrawn unless the user > >>administratively > >>configures the CE interface down (or the PW configuration is deleted > >>entirely). > >>A simple label withdraw method SHOULD also be supported as an > >>alternative. > >> > > > > > > Can you elaborate why CE facing user admin down you make a withdraw > > and not a status report? > > > > The PW has it's own admin status so if you want to force withdraw > > (without deleting the configuration) you can do it directly > at the PW > > level. I believe it is good to separate the PW and CE admin status > > since you may want to administratively close the physical > port while > > keeping the resources at the PW level. If there is > operational need a > > combined administrative status to make both operations at > once we can > > easily add it to the PW-MIB. > > > > David > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C331A3.8F3CDFEC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [PWE3] status signalling of MPLS PW state

which means it should also release the label it = received from the remote PE since the port has been "removed from = the configuration"?



> -----Original Message-----
> From: Luca Martini [mailto:luca@level3.net]
> Sent: Thursday, June 12, 2003 6:09 PM
> To: David Zelig
> Cc: pwe3@ietf.org
> Subject: Re: [PWE3] status signalling of MPLS = PW state
>
>
> ooops.
> this is a typo. it should say PE.
> the text "the CE interface down" = should read "the CE facing
> interface down"
>
> This is equivalent to removing the = configuration.
> We could remove this text , it was just here = for clarification.
>
> Luca
>
>
>
> David Zelig wrote:
> > Luca,
> >
> >
> >>-----Original Message-----
> >>From: Luca Martini [mailto:luca@level3.net]
> >>Sent: Thursday, June 12, 2003 1:07 = AM
> >>To: pwe3@ietf.org
> >>Subject: Re: [PWE3] status signalling = of MPLS PW state
> >>
> >>
> >>Latest text, including some of the = feedback.
> >>
> >>.Pb "Signaling of Pseudo Wire Link = Status"
> >>
> >>.Pc "Use of Label = Mappings."
> >>The PEs MUST send PW label mapping = messages to their peers as
> >>soon as the PW
> >>is configured and administratively = enabled, regardless of the
> >>CE interface
> >>state. The PW label should not be = withdrawn unless the user
> >>administratively
> >>configures the CE interface down (or = the PW configuration is deleted
> >>entirely).
> >>A simple label withdraw method SHOULD = also be supported as an
> >>alternative.
> >>
> >
> >
> > Can you elaborate why CE facing user admin = down you make a withdraw
> > and not a status report?
> >
> > The PW has it's own admin status so if you = want to force withdraw
> > (without deleting the configuration) you = can do it directly
> at the PW
> > level. I believe it is good to separate = the PW and CE admin status
> > since you may want to administratively = close the physical
> port while
> > keeping the resources at the PW level. If = there is
> operational need a
> > combined administrative status to make = both operations at
> once we can
> > easily add it to the PW-MIB.
> >
> > David
> >
>
>
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C331A3.8F3CDFEC-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: status signalling of MPLS PW state Date: Fri, 13 Jun 2003 09:00:24 -0400 Lines: 400 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C331AB.C0F9A742" Cc: Luca Martini , "Hamid Ould-Brahim" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 13 19:31:51 2003 Return-path: To: "'Andrew G. Malis'" , Himanshu Shah 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_01C331AB.C0F9A742 Content-Type: text/plain; charset="iso-8859-1" Andy: I also agree with this comment. cheers Dave > -----Original Message----- > From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Thursday, June 12, 2003 3:02 PM > To: Himanshu Shah > Cc: Himanshu Shah; Luca Martini; Andrew G. Malis; > Ould-Brahim, Hamid [CAR:1A00:EXCH]; pwe3@ietf.org > Subject: RE: [PWE3] status signalling of MPLS PW state > > > Having caught up on this email thread, I'm ready to agree that both > mechanisms are necessary - the Operational Status TLV to > carry end-to-end > status signaling from and to LMI/ILMI/PVC status signaling at the > endpoints, and the PW Link Status Message to reflect interface and PW > outages. I also agree with David that in a "PVC" environment > labels should > only be withdrawn when the PW is administratively destroyed > (the LERs/PEs > have been instructed to release the resources associated with > the PW). In > an "SVC" environment, labels would be withdrawn as a result > of a signaled > CLEAR from the CE. > > Thanks, > Andy > > -------- > > At 6/12/2003 11:54 AM -0400, Himanshu Shah wrote: > >Also, note that draft-shah is backward compatible > >where capability of the remote peer is auto-learned > >based on presence/absence of operational status TLV > >in the initial label mapping message. > > > >/himanshu > >wavesmith networks > > > > > -----Original Message----- > > > From: Himanshu Shah > > > Sent: Thursday, June 12, 2003 11:13 AM > > > To: Luca Martini; Andrew G. Malis > > > Cc: Hamid Ould-Brahim; pwe3@ietf.org > > > Subject: RE: [PWE3] status signalling of MPLS PW state > > > > > > > > > I will furnish the text for use of each TLV. > > > > > > Note that not all TLVs are suitable for "update" > > > mechanism. For example, QOS TLV. It is best > > > that these parameters are provided at the time > > > XC is programmed in the FIB and not after. > > > > > > We need a +generic+ mechanism to allow > > > extensions without requesting changes in the base draft. > > > > > > Also, I am not convinced if it is necessary to convey the the > > > reasons for "link down" to remote PE. I don't believe it > is useful > > > information as such. > > > > > > The problem is, for instance, if the link and/or PW is down, and > > > notified, but the reasons have changed, should PE keep > notifying the > > > change of these reasons? > > > > > > /himanshu > > > wavesmith networks > > > > > > > -----Original Message----- > > > > From: Luca Martini [mailto:luca@level3.net] > > > > Sent: Wednesday, June 11, 2003 7:03 PM > > > > To: Andrew G. Malis > > > > Cc: Hamid Ould-Brahim; pwe3@ietf.org > > > > Subject: Re: [PWE3] status signalling of MPLS PW state > > > > > > > > > > > > I read the following TLVs in the > > > > draft-shah-pwe3-control-protocol-extension-00.txt : > > > > > > > > Operational Status TLV > > > > IP Address TLV > > > > IP+MAC Address TLV > > > > Pseudowire QOS TLV > > > > > > > > > > > > I think most of these are needed , but they need not > all be part > > > > of the FEC. There are several bits available in the status TLV > > > > proposal, can you please > > > > specify what the use should be, and I can add it. > > > > ( please note that the draft-shah does not propose much in > > > > the area of status ) > > > > > > > > Thanks. > > > > Luca > > > > > > > > > > > > > > > > > > > > Andrew G. Malis wrote: > > > > > Hamid, > > > > > > > > > > Well, they're really two alternative ways to extend LDP to > > > > convey the > > > > > same information. The only way to really merge them would > > > > be to support > > > > > them both .... > > > > > > > > > > Thanks, > > > > > Andy > > > > > > > > > > --------- > > > > > > > > > > At 6/11/2003 04:48 PM -0400, Hamid Ould-Brahim wrote: > > > > > > > > > >> Andy, > > > > >> > > > > >> [clipped]... > > > > >> > > > > >> > > > > > >> > I certainly agree that one or the other is needed, > > > > >> > > > > >> How about both proposals to be merged (when > > > > >> possible/applicable)? > > > > >> > > > > >> Hamid. > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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_01C331AB.C0F9A742 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] status signalling of MPLS PW state

Andy:

I also agree with this comment.

cheers
Dave

> -----Original Message-----
> From: Andrew G. Malis [mailto:Andy.Malis@vivacene= tworks.com]
> Sent: Thursday, June 12, 2003 3:02 PM
> To: Himanshu Shah
> Cc: Himanshu Shah; Luca Martini; Andrew G. = Malis;
> Ould-Brahim, Hamid [CAR:1A00:EXCH]; = pwe3@ietf.org
> Subject: RE: [PWE3] status signalling of MPLS = PW state
>
>
> Having caught up on this email thread, I'm = ready to agree that both
> mechanisms are necessary - the Operational = Status TLV to
> carry end-to-end
> status signaling from and to LMI/ILMI/PVC = status signaling at the
> endpoints, and the PW Link Status Message to = reflect interface and PW
> outages.  I also agree with David that in = a "PVC" environment
> labels should
> only be withdrawn when the PW is = administratively destroyed
> (the LERs/PEs
> have been instructed to release the resources = associated with
> the PW).  In
> an "SVC" environment, labels would be = withdrawn as a result
> of a signaled
> CLEAR from the CE.
>
> Thanks,
> Andy
>
> --------
>
> At 6/12/2003 11:54 AM -0400, Himanshu Shah = wrote:
> >Also, note that draft-shah is backward = compatible
> >where capability of the remote peer is = auto-learned
> >based on presence/absence of operational = status TLV
> >in the initial label mapping = message.
> >
> >/himanshu
> >wavesmith networks
> >
> > > -----Original Message-----
> > > From: Himanshu Shah
> > > Sent: Thursday, June 12, 2003 11:13 = AM
> > > To: Luca Martini; Andrew G. = Malis
> > > Cc: Hamid Ould-Brahim; = pwe3@ietf.org
> > > Subject: RE: [PWE3] status signalling = of MPLS PW state
> > >
> > >
> > > I will furnish the text for use of = each TLV.
> > >
> > > Note that not all TLVs are suitable = for "update"
> > > mechanism. For example, QOS = TLV.  It is best
> > > that these parameters are provided at = the time
> > > XC is programmed in the FIB and not = after.
> > >
> > > We need a +generic+ mechanism to = allow
> > > extensions without requesting changes = in the base draft.
> > >
> > > Also, I am not convinced if it is = necessary to convey the the
> > > reasons for "link down" to = remote PE. I don't believe it
> is useful
> > > information as such.
> > >
> > > The problem is, for instance, if the = link and/or PW is down, and
> > > notified, but the reasons have = changed, should PE keep
> notifying the
> > > change of these reasons?
> > >
> > > /himanshu
> > > wavesmith networks
> > >
> > > > -----Original = Message-----
> > > > From: Luca Martini [mailto:luca@level3.net]
> > > > Sent: Wednesday, June 11, 2003 = 7:03 PM
> > > > To: Andrew G. Malis
> > > > Cc: Hamid Ould-Brahim; = pwe3@ietf.org
> > > > Subject: Re: [PWE3] status = signalling of MPLS PW state
> > > >
> > > >
> > > > I read the following TLVs in the =
> > > > = draft-shah-pwe3-control-protocol-extension-00.txt :
> > > >
> > > > Operational Status TLV
> > > > IP Address TLV
> > > > IP+MAC Address TLV
> > > > Pseudowire QOS TLV
> > > >
> > > >
> > > > I think most of these are needed = , but they need not
> all be part
> > > > of the FEC. There are several = bits available in the status TLV
> > > > proposal, can you please
> > > > specify what the use should be, = and I can add it.
> > > > ( please note that the = draft-shah does not propose much in
> > > > the area of status )
> > > >
> > > > Thanks.
> > > > Luca
> > > >
> > > >
> > > >
> > > >
> > > > Andrew G. Malis wrote:
> > > > > Hamid,
> > > > >
> > > > > Well, they're really two = alternative ways to extend LDP to
> > > > convey the
> > > > > same information.  The = only way to really merge them would
> > > > be to support
> > > > > them both ....
> > > > >
> > > > > Thanks,
> > > > > Andy
> > > > >
> > > > > ---------
> > > > >
> > > > > At 6/11/2003 04:48 PM = -0400, Hamid Ould-Brahim wrote:
> > > > >
> > > > >> Andy,
> > > > >>
> > > > >> [clipped]...
> > > > >>
> > > > >> >
> > > > >> > I certainly agree = that one or the other is needed,
> > > > >>
> > > > >> How about both = proposals to be merged (when
> > > > >> = possible/applicable)?
> > > > >>
> > > > >> Hamid.
> > > > >
> > > >
> > > >
> > > > = _______________________________________________
> > > > 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_01C331AB.C0F9A742-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Andrew G. Malis" Subject: Interface Parameter ID conflict (VPLS and fragmentation) Date: Fri, 13 Jun 2003 14:21:03 -0400 Lines: 8 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andy Malis" X-From: pwe3-admin@ietf.org Fri Jun 13 20:36:11 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: pwe3@ietf.org X-OriginalArrivalTime: 13 Jun 2003 18:21:41.0270 (UTC) FILETIME=[A2EDDB60:01C331D8] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca is in the process of updating the PWE3 IANA allocations and control signaling drafts and found that interface parameter ID 0x06 was defined for two different interface parameters, one for VPLS and the other for fragmentation. I've agreed to renumber the fragmentation interface parameter to 0x09. Please reply if you think this presents a problem. Thanks, Andy From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-arch-04.txt Date: Fri, 13 Jun 2003 18:43:24 +0100 Organization: Cisco Systems, Inc. Lines: 39 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri Jun 13 20:40:09 2003 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en To: "pwe3@ietf.org" , Prayson Pate , Danny McPherson Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I just rev'd the arch draft to correct an omission in section 5.4.4. In draft-ietf-pwe3-arch-04.txt we now define the reserved bits in the MPLS Payload Type Indentifier to be zero. There are no other changes. The revised section is shown below Stewart ------------------------------------------------------------------------ 5.4.4. MPLS Payload Identifier If technical considerations result in a PW control word that may alias an IP packet, the control word SHOULD be preceeded by an MPLS payload type identifier. The MPLS payload type is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved = 0 | PPP DLL Protocol Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PPP DLL protocol definition | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: MPLS Payload Type Identifier PPP DLL Protocol Number [16:31]: These numbers are assigned by IANA. Bits 4 to 15 inclusive are reserved for future use and must be zero. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Fri, 13 Jun 2003 11:52:41 -0600 Organization: Level3 Communications LLC. Lines: 9 Sender: pwe3-admin@ietf.org References: <0D7FC1D8D861D511AEA70002A52CE5E606B6AA05@zcard0ke.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'David Zelig'" , "'pwe3@ietf.org'" X-From: pwe3-admin@ietf.org Fri Jun 13 20:40:16 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: Gregory Wright 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 Gregory Wright wrote: > which means it should also release the label it received from the remote > PE since the port has been "removed from the configuration"? > yes, of course. Luca From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Fri, 13 Jun 2003 12:17:38 -0600 Organization: Level3 Communications LLC. Lines: 77 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Andrew G. Malis'" , Himanshu Shah , Hamid Ould-Brahim , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 13 20:42:13 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 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 Andy helped me get to the version below. I changed to a PW status TLV , that is used in the LDP notification message. ( it makes coding a little harder , but it's difficult to justify another message type. ) Also changed the definitions of the PW faults. Now there are 32 bits of PW status. I still need to finish a iana section to allocate more bits. any more comments ? Luca .Pb "Signaling of Pseudo Wire Status" .Pc "Use of Label Mappings." The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the CE-facing interface state. The PW label should not be withdrawn unless the user administratively configures the CE-facing interface down (or the PW configuration is deleted entirely). A simple label withdraw method SHOULD also be supported as an alternative. .Pc "Signaling PW status." The PE devices use an LDP TLV to indicate status to their remote peers. This PW Status TLV contains more information than the alternative simple Label Withdraw message. The format of the PW Status TLV is: .DS 0 0 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x0???) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .DE Where status is a 4 octet bit field: .nf 0x00000000 - Pseudo Wire forwarding ( clear all failures ) 0x00000001 - Pseudo Wire Not Forwarding 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault .En The above status codes can be logically combined to indicate more then a single failure at once. Each fault can be cleared by sending an appropriate status message with the respective bit cleared. The presence of the lowest bit (PW Not Forwarding) acts only as a generic failure indication when there is a link-down event for which none of the other bits apply. The Status TLV is transported to the remote PW peer via the LDP notification message. The format of the Notification Message is: .DS 0 0 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .DE The PW FEC TLV SHOULD not include the interface parameters as they are ignored in the context of this message. When a PE's CE-facing interface encounters an error, use of the new message allows the PE to send a single Status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Fri, 13 Jun 2003 14:40:22 -0600 Organization: Level3 Communications LLC. Lines: 51 Sender: pwe3-admin@ietf.org References: <8FA6CEF9A4E42B48A5F8DC038655B353012AF25F@mxtlv1.corrigent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Andrew G. Malis'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Sat Jun 14 04:41:06 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 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 Zelig wrote: > Luca, > > The problem with setting the CE facing administrative status to down as a > way to tear down the PW is that in case of logical attachments circuits > (like VLAN as example) you may do not have one. I'm not sure I understand this clearly. Are you talking about the case when there are many VCs inside a single PW ? that is never the case in the control draft. > Another reason as I stated > earlier is that the physical interface administrative status may be used > separately from the PW administrative status. > one thing that is clear is that if the interface is admined down the PW will not be forwarding. Two things can happen: 1) a PW status TLV is sent out with the PW CE-facing tx and rx faults. 2) the PW is torn down, and this is looked at as an configuration event. In either case the remote PE should take the same action. > An EMS application has a separate admin can be used for tearing the PW. If > an implementation want to tie it together to the physical port admin it is > OK, but should be left for the implementer decision. > I can see that port admin down == tear down is probably not a great idea. but why do we need a separate status bit ? What different PE-CE protocol action will the remote PE take in the case of admin down , as opposed to the Pw tx/rx CE-facing fault ? > If there is an agreement on that, than there is a need in the status to > inform about the physical port administrative status. > > David > I have no problem in allocating the bit , just need some arguments to defend it. :-) Thanks. Luca From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Andrew G. Malis" Subject: Re: status signalling of MPLS PW state Date: Fri, 13 Jun 2003 14:39:24 -0400 Lines: 90 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: David Allan , "'Andrew G. Malis'" , Himanshu Shah , Hamid Ould-Brahim , pwe3@ietf.org X-From: pwe3-admin@ietf.org Sat Jun 14 06:29:41 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Luca Martini In-Reply-To: <3EEA1542.400@level3.net> X-OriginalArrivalTime: 13 Jun 2003 18:50:49.0074 (UTC) FILETIME=[B4B39520:01C331DC] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca and I worked this out on the phone. It's a nice way to get both of the functions we were discussing earlier (being able to signal both individual PW state and group ID failure) and it takes advantage of the existing LDP Notification message (and architecturally cleaner than using the Label Mapping message). Andy -------- At 6/13/2003 12:17 PM -0600, Luca Martini wrote: >Andy helped me get to the version below. > >I changed to a PW status TLV , that is used in the LDP notification message. >( it makes coding a little harder , but it's difficult to justify another >message type. ) >Also changed the definitions of the PW faults. >Now there are 32 bits of PW status. >I still need to finish a iana section to allocate more bits. > >any more comments ? > >Luca >.Pb "Signaling of Pseudo Wire Status" > >.Pc "Use of Label Mappings." >The PEs MUST send PW label mapping messages to their peers as soon as the PW >is configured and administratively enabled, regardless of the CE-facing >interface state. The PW label should not be withdrawn unless the user >administratively configures the CE-facing interface down (or the PW >configuration is deleted entirely). A simple label withdraw method SHOULD >also be supported as an alternative. > >.Pc "Signaling PW status." >The PE devices use an LDP TLV to indicate status to their remote peers. This >PW Status TLV contains more information than the alternative simple Label >Withdraw message. > >The format of the PW Status TLV is: >.DS 0 0 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|1|0| PW Status (0x0???) | Length | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Status Code | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >.DE > >Where status is a 4 octet bit field: > >.nf >0x00000000 - Pseudo Wire forwarding ( clear all failures ) >0x00000001 - Pseudo Wire Not Forwarding >0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault >0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault >0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault >0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault >.En > >The above status codes can be logically combined to indicate more then a >single failure at once. Each fault can be cleared by sending an appropriate >status message with the respective bit cleared. The presence of the lowest >bit (PW Not Forwarding) acts only as a generic failure indication when there >is a link-down event for which none of the other bits apply. > >The Status TLV is transported to the remote PW peer via the LDP notification >message. The format of the Notification Message is: > >.DS 0 0 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|1| Notification (0x0001) | Message Length | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| Message ID | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| PW FEC TLV | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| PW Status TLV | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >.DE > >The PW FEC TLV SHOULD not include the interface parameters as they are >ignored in the context of this message. When a PE's CE-facing interface >encounters an error, use of the new message allows the PE to send a single >Status message, using a PW FEC TLV with only the group ID set, to denote >this change in status for all affected PW connections. > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: David Zelig Subject: RE: status signalling of MPLS PW state Date: Fri, 13 Jun 2003 23:15:14 +0200 Lines: 125 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: "'Andrew G. Malis'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Sat Jun 14 07:39:43 2003 Return-path: To: Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca, The problem with setting the CE facing administrative status to down as a way to tear down the PW is that in case of logical attachments circuits (like VLAN as example) you may do not have one. Another reason as I stated earlier is that the physical interface administrative status may be used separately from the PW administrative status. An EMS application has a separate admin can be used for tearing the PW. If an implementation want to tie it together to the physical port admin it is OK, but should be left for the implementer decision. If there is an agreement on that, than there is a need in the status to inform about the physical port administrative status. David > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Friday, June 13, 2003 8:18 PM > To: David Allan > Cc: 'Andrew G. Malis'; Himanshu Shah; Hamid Ould-Brahim; pwe3@ietf.org > Subject: Re: [PWE3] status signalling of MPLS PW state > > > Andy helped me get to the version below. > > I changed to a PW status TLV , that is used in the LDP > notification message. > ( it makes coding a little harder , but it's difficult to > justify another > message type. ) > Also changed the definitions of the PW faults. > Now there are 32 bits of PW status. > I still need to finish a iana section to allocate more bits. > > any more comments ? > > Luca > .Pb "Signaling of Pseudo Wire Status" > > .Pc "Use of Label Mappings." > The PEs MUST send PW label mapping messages to their peers as > soon as the PW > is configured and administratively enabled, regardless of the > CE-facing > interface state. The PW label should not be withdrawn unless the user > administratively configures the CE-facing interface down (or the PW > configuration is deleted entirely). A simple label withdraw > method SHOULD > also be supported as an alternative. > > .Pc "Signaling PW status." > The PE devices use an LDP TLV to indicate status to their > remote peers. This > PW Status TLV contains more information than the alternative > simple Label > Withdraw message. > > The format of the PW Status TLV is: > .DS 0 0 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| PW Status (0x0???) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > .DE > > Where status is a 4 octet bit field: > > .nf > 0x00000000 - Pseudo Wire forwarding ( clear all failures ) > 0x00000001 - Pseudo Wire Not Forwarding > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault > .En > > The above status codes can be logically combined to indicate > more then a > single failure at once. Each fault can be cleared by sending > an appropriate > status message with the respective bit cleared. The presence > of the lowest > bit (PW Not Forwarding) acts only as a generic failure > indication when there > is a link-down event for which none of the other bits apply. > > The Status TLV is transported to the remote PW peer via the > LDP notification > message. The format of the Notification Message is: > > .DS 0 0 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW FEC TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > .DE > > The PW FEC TLV SHOULD not include the interface parameters as they are > ignored in the context of this message. When a PE's CE-facing > interface > encounters an error, use of the new message allows the PE to > send a single > Status message, using a PW FEC TLV with only the group ID > set, to denote > this change in status for all affected PW connections. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Ron Cohen" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Sun, 15 Jun 2003 10:19:02 +0200 Lines: 42 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B5ECC3F@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: "'Israel Sasson'" , "'Akiva Sadovski'" , "'Eduard Metz \(E-mail\)'" , "'Tim Frost \(E-mail\)'" , "'Prayson Pate \(E-mail\)'" X-From: pwe3-admin@ietf.org Sun Jun 15 11:22:19 2003 Return-path: To: "'Danny McPherson'" , "'Sasha Vainshtein'" , "'Stewart Bryant \(E-mail\)'" , "'PWE3 WG \(E-mail\)'" 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: <89D0584BBFBFE74F9057A389BA3F239B5ECC3F@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 Danny, I support adopting this draft as a WG item. Regards Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Danny McPherson > Sent: Thursday, June 12, 2003 6:57 PM > To: Sasha Vainshtein; Stewart Bryant (E-mail); PWE3 WG (E-mail) > Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim > Frost (E-mail); Prayson Pate (E-mail) > Subject: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > If there are other folks that would like to see this document > become a WG item please speak up now. > > -danny > > On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: > > > Stewart, Danny and all, > > As (some of) you have probably noticed I have posted an > updated (-06) > > revision of the CESoPSN draft. > > > > I would like to ask the WG to adopt this draft as a WG > item, and this > > message is intended to initiate a TECHNICAL discussion on this > > subject. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Sun, 15 Jun 2003 09:17:46 +0300 Lines: 53 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "Alexander Vainshtein" , "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Sun Jun 15 12:19:01 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcMxzp+xel9mBSmXRjqQOeKceM1oxgBM6IeA To: "Michel Khouderchah" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5F6IOm02991 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 like to see this draft become a WG item. The latest > enhancements offer a good compromise to achieve convergence of Anavi and > Johnson drafts. Michel, Can you elaborate on this convergence that you see? I hope you are not being fooled by the new draft's frequent references to ATM-CES --- these references are either to general descriptive material in that standard, or to CAS functions, and in no way imply that this new draft has become any closer to draft-anavi. Indded, the only major updates to CESoPSN that I see actually make it LESS like TDMoIP. 1) There is a new default mode for CAS wherein the packet MUST contain a full multiframe. This is a major DIVERGENCE from draft-anavi, the entire philosophy of which is to break the locking between TDM structures and packets in order to enable flexible selection of packet size and latency. 2) The partial awakening of the CESoPSN authors to the fact that they were the only strong promoters of RTP. So they decided top promote RTP header compression as well. This is also a divergence from draft-anavi which for political reasons has a vague reference to RTP, but certainly does not promote investing in complex (and expensive from the IPR viewpoint) header compression schemes in order to ameliorate its ill effects. 3) The elevation of the following statement to "requirement" level: Fixed end-to-end delay: CESoPSN implementations SHOULD provide the same end-to-end delay between any given pair of PEs regardless of the bit-rate of the emulated service. I have commented in the past at great length about the total artificiality of requiring two different links to have the same delay, only in order to force a given implementation which happens to have this "feature". This un-natural requirement is of course entirely alien to draft-anavi. 4) Optional "ECMP Prevention" Word This is of course not needed in draft-anavi, as it uses the standard PWE control word. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: David Zelig Subject: RE: status signalling of MPLS PW state Date: Sun, 15 Jun 2003 16:44:56 +0200 Lines: 95 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: "'Andrew G. Malis'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Sun Jun 15 19:51:44 2003 Return-path: To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca, > > David Zelig wrote: > > Luca, > > > > The problem with setting the CE facing administrative > status to down as a > > way to tear down the PW is that in case of logical > attachments circuits > > (like VLAN as example) you may do not have one. > > I'm not sure I understand this clearly. > Are you talking about the case when there are many VCs inside > a single PW ? > that is never the case in the control draft. Maybe I wasn't clear enough. In PW type EthernetVLAN for example, many PWs may be associated with a single physical Ethernet interface. If the interface table (in the ifMib) has no knowledge on each individual VLAN, there is only one Administrative Status available at the physical port without per VLAN granularity. In this case tearing an individual PW must be done using the PW administrative status. > > > > Another reason as I stated > > earlier is that the physical interface administrative > status may be used > > separately from the PW administrative status. > > > one thing that is clear is that if the interface is admined > down the PW will > not be forwarding. Agree. > Two things can happen: > > 1) a PW status TLV is sent out with the PW CE-facing tx and rx faults. > > 2) the PW is torn down, and this is looked at as an > configuration event. > > In either case the remote PE should take the same action. > > > An EMS application has a separate admin can be used for > tearing the PW. If > > an implementation want to tie it together to the physical > port admin it is > > OK, but should be left for the implementer decision. > > > > I can see that port admin down == tear down is probably not a > great idea. That's my observation too. For tearing down we have the PW administrative status. > but why do we need a separate status bit ? > In case of a fault indication, there might be some red alarms, automatic fault correlation and debugging procedure that would start. With another bit for administrative operation, no need for these processes. > What different PE-CE protocol action will the remote PE take > in the case of > admin down , as opposed to the Pw tx/rx CE-facing fault ? > > The same forwarding action, only different level of reporting. > > > If there is an agreement on that, than there is a need in > the status to > > inform about the physical port administrative status. > > > > David > > > I have no problem in allocating the bit , just need some > arguments to defend it. > :-) > > Thanks. > Luca > > > > > _______________________________________________ > 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: Max Riegel Subject: Re: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 16 Jun 2003 11:06:59 +0200 Organization: -- Lines: 28 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Sasha Vainshtein , PWE3 WG X-From: pwe3-admin@ietf.org Mon Jun 16 11:55:16 2003 Return-path: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en To: Danny McPherson 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 Danny, I would support that the WG is adopting this document as a base for further discussions in the working group towards a WG solution. Bye Max Danny McPherson wrote: > If there are other folks that would like to see this document become a WG > item please speak up now. > > -danny > > On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: >>Stewart, Danny and all, >>As (some of) you have probably noticed I have posted an >>updated (-06) revision of the CESoPSN draft. >> >>I would like to ask the WG to adopt this draft as a WG item, >>and this message is intended to initiate a TECHNICAL discussion >>on this subject. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: FW: REMINDER Internet-Draft Cutoff Dates for Vienna, Austria Date: Mon, 16 Jun 2003 06:54:50 -0600 Lines: 53 Sender: pwe3-admin@ietf.org References: <200306131711.NAA13427@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Mon Jun 16 17:14:15 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: In-Reply-To: <200306131711.NAA13427@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 FYI... -danny ------ Forwarded Message From: Internet-Drafts Administrator Date: Fri, 13 Jun 2003 13:11:45 -0400 To: IETF-Announce: ; Subject: REMINDER Internet-Draft Cutoff Dates for Vienna, Austria NOTE: There are two (2) Internet-Draft Cutoff dates June 23rd: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 23rd, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 16th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 23rd will NOT be accepted. June 30st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, June 30st, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_57.html ------ End of Forwarded Message From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Amnon Ilan" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 16 Jun 2003 10:30:42 +0200 Lines: 62 Sender: pwe3-admin@ietf.org Reply-To: X-From: pwe3-admin@ietf.org Mon Jun 16 19:19:27 2003 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Danny, I'm against adopting the CESoPSN draft. I also prefer the TDMoIP draft. Mainly because it is based on VoATM standards: 1. proven technology. 2. easier market acceptance. 3. easier acceptance by other bodies (ITU, MPLS-Forum) and higher chance for compatible standards. To add on Shahram's view: I think the support for AAL2 is also very important for future acceptence and interworking with VoATM, 3G etc. Regards, Amnon. >--------------------------------------------------------------------------- ----- > >Danny, > >I think my view is known. I prefer the Anavi draft (aka TDMoIP), due to its usage >of a known and proven technology (i.e, AAL1) and its ease of interworking with >ATM CES. > >Yours, >-Shahram > >-----Original Message----- >From: Danny McPherson [mailto:danny@tcb.net] >Sent: Thursday, June 12, 2003 12:57 PM >To: Sasha Vainshtein; Stewart Bryant (E-mail); PWE3 WG (E-mail) >Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim Frost >(E-mail); Prayson Pate (E-mail) >Subject: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > >If there are other folks that would like to see this document >become a WG >item please speak up now. > >-danny > >On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: > >> Stewart, Danny and all, >> As (some of) you have probably noticed I have posted an >> updated (-06) revision of the CESoPSN draft. >> >> I would like to ask the WG to adopt this draft as a WG item, >> and this message is intended to initiate a TECHNICAL discussion >> on this subject. > >_______________________________________________ >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: "Amnon Ilan" Subject: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 16 Jun 2003 18:08:40 +0200 Lines: 63 Sender: pwe3-admin@ietf.org Reply-To: X-From: pwe3-admin@ietf.org Tue Jun 17 02:12:26 2003 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Danny, I'm against adopting the CESoPSN draft. I support the TDMoIP draft Mainly because it is based on VoATM standards: 1. proven technology (AAL1, AAl2 and TDMoIP itself). 2. easier market acceptance. 3. easier acceptance by other bodies (ITU, MPLS-Forum) and higher chance for compatible standards. To add on Shahram's view: I think the support for AAL2 is also very important for future acceptence and interworking with VoATM, 3G etc. Regards, Amnon. >--------------------------------------------------------------------------- ----- > >Danny, > >I think my view is known. I prefer the Anavi draft (aka TDMoIP), due to its usage >of a known and proven technology (i.e, AAL1) and its ease of interworking with >ATM CES. > >Yours, >-Shahram > >-----Original Message----- >From: Danny McPherson [mailto:danny@tcb.net] >Sent: Thursday, June 12, 2003 12:57 PM >To: Sasha Vainshtein; Stewart Bryant (E-mail); PWE3 WG (E-mail) >Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim Frost >(E-mail); Prayson Pate (E-mail) >Subject: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > >If there are other folks that would like to see this document >become a WG >item please speak up now. > >-danny > >On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: > >> Stewart, Danny and all, >> As (some of) you have probably noticed I have posted an >> updated (-06) revision of the CESoPSN draft. >> >> I would like to ask the WG to adopt this draft as a WG item, >> and this message is intended to initiate a TECHNICAL discussion >> on this subject. > >_______________________________________________ >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: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 16 Jun 2003 18:57:22 +0100 Lines: 91 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Tue Jun 17 03:21:17 2003 Return-path: To: ailan@mrv.com, pwe3@ietf.org, 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 I support this view. However, I do draw a distinction between a cnls server layer of IP and co pkt-sw server layer of MPLS. I see no point in elaborating on this further, save to point out the rather obvious fact that if they had not the potential to provide different capabilities then one would not need both would one? regards, Neil > -----Original Message----- > From: Amnon Ilan [mailto:ailan@mrv.com] > Sent: 16 June 2003 09:31 > To: pwe3@ietf.org; danny@tcb.net > Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > Danny, > > I'm against adopting the CESoPSN draft. I also prefer the > TDMoIP draft. > Mainly because it is based on VoATM standards: > 1. proven technology. > 2. easier market acceptance. > 3. easier acceptance by other bodies (ITU, MPLS-Forum) and higher > chance for compatible standards. > To add on Shahram's view: I think the support for AAL2 is also very > important for future acceptence and interworking with VoATM, 3G etc. > > Regards, > Amnon. > > >------------------------------------------------------------- > -------------- > ----- > > > >Danny, > > > >I think my view is known. I prefer the Anavi draft (aka > TDMoIP), due to its > usage > >of a known and proven technology (i.e, AAL1) and its ease of > interworking > with > >ATM CES. > > > >Yours, > >-Shahram > > > >-----Original Message----- > >From: Danny McPherson [mailto:danny@tcb.net] > >Sent: Thursday, June 12, 2003 12:57 PM > >To: Sasha Vainshtein; Stewart Bryant (E-mail); PWE3 WG (E-mail) > >Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim Frost > >(E-mail); Prayson Pate (E-mail) > >Subject: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > > > >If there are other folks that would like to see this document > >become a WG > >item please speak up now. > > > >-danny > > > >On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: > > > >> Stewart, Danny and all, > >> As (some of) you have probably noticed I have posted an > >> updated (-06) revision of the CESoPSN draft. > >> > >> I would like to ask the WG to adopt this draft as a WG item, > >> and this message is intended to initiate a TECHNICAL discussion > >> on this subject. > > > >_______________________________________________ > >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: "Uri Rotshtein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 16 Jun 2003 18:15:53 +0300 Lines: 70 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "Alexander Vainshtein" X-From: pwe3-admin@ietf.org Tue Jun 17 03:24:30 2003 Return-path: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcMxzp+xel9mBSmXRjqQOeKceM1oxgBM6IeAAEWnCgA= To: "PWE3 WG (E-mail)" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5GFG5m10732 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 also recommend adopting this draft as WG item. For all this CES market we should close the standard ASAP. Uri. -----Original Message----- From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Sunday, June 15, 2003 9:18 AM To: Michel Khouderchah Cc: Alexander Vainshtein; PWE3 WG (E-mail) Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > I would like to see this draft become a WG item. The latest > enhancements offer a good compromise to achieve convergence of Anavi and > Johnson drafts. Michel, Can you elaborate on this convergence that you see? I hope you are not being fooled by the new draft's frequent references to ATM-CES --- these references are either to general descriptive material in that standard, or to CAS functions, and in no way imply that this new draft has become any closer to draft-anavi. Indded, the only major updates to CESoPSN that I see actually make it LESS like TDMoIP. 1) There is a new default mode for CAS wherein the packet MUST contain a full multiframe. This is a major DIVERGENCE from draft-anavi, the entire philosophy of which is to break the locking between TDM structures and packets in order to enable flexible selection of packet size and latency. 2) The partial awakening of the CESoPSN authors to the fact that they were the only strong promoters of RTP. So they decided top promote RTP header compression as well. This is also a divergence from draft-anavi which for political reasons has a vague reference to RTP, but certainly does not promote investing in complex (and expensive from the IPR viewpoint) header compression schemes in order to ameliorate its ill effects. 3) The elevation of the following statement to "requirement" level: Fixed end-to-end delay: CESoPSN implementations SHOULD provide the same end-to-end delay between any given pair of PEs regardless of the bit-rate of the emulated service. I have commented in the past at great length about the total artificiality of requiring two different links to have the same delay, only in order to force a given implementation which happens to have this "feature". This un-natural requirement is of course entirely alien to draft-anavi. 4) Optional "ECMP Prevention" Word This is of course not needed in draft-anavi, as it uses the standard PWE control word. 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: Alex Conta Subject: Re: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 16 Jun 2003 11:20:40 -0400 Lines: 92 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1D7CAE4D0D0C0E31FA179C32" Cc: Sasha Vainshtein , "Stewart Bryant (E-mail)" , "PWE3 WG (E-mail)" , Israel Sasson , Akiva Sadovski , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Tue Jun 17 06:27:50 2003 Return-path: X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en To: Danny McPherson Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 cryptographically signed message in MIME format. --------------ms1D7CAE4D0D0C0E31FA179C32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit No. At this point, I am against. Is there a newer version of the "anavi" draft as well? (Yaakov?) Is that addressing the issues raised earlier? Thanks, Alex Danny McPherson wrote: > > If there are other folks that would like to see this document become a WG > item please speak up now. > > -danny > > On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: > > > Stewart, Danny and all, > > As (some of) you have probably noticed I have posted an > > updated (-06) revision of the CESoPSN draft. > > > > I would like to ask the WG to adopt this draft as a WG item, > > and this message is intended to initiate a TECHNICAL discussion > > on this subject. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 --------------ms1D7CAE4D0D0C0E31FA179C32 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhAwgIjt1LtpV2AM64D0R8bCMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkyMDAwMDAw MFoXDTAzMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFIjccjs9g z0DiQcpTsg+mbY5L+R2YaTNN6k2fRGSLMLitaA2YwdeN3goXG45bXCP8DldBS38EWHFT2/5Q cy9HnNQaS1GnG2xzngdev5HpVm/oAy1M9YPt96Zp2W5MKGIb87vxyXvb1KqRMA9paf/6xZ2C B4tH127oHyF1xT4k8wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQBUOS83AALNc8pTZDApKndtQBiFQLPTu5ZL pE1TDsyd4y75K3gXUvqlprCFY8HgKwodqs9wTltqYRlvhZVlMXu1y0g8Z3MJ9KSddePYuuli jop+PplaAHS7DHXDJNNQt+n2i2K4j4uJFokE2JnvaEyBEHjtTmIt+JjS2Dygm57mwzCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDCAiO3Uu2lXYAzrgPRHxsIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA2MTYxNTIwNDFaMCMGCSqGSIb3DQEJ BDEWBBSFkvvDDlnkGw+DfcpsRq60AMwQAzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgA+PVSbHnGvLqUzHXte52o6H7OGlIK04NZ5/CfXKM8wptkz7 LBQNEwvujP6skGinfRkNe4MmRIsj3RQg339XckVEYdOtERdiWGva9xDgXkTxS7C8HGtOLibf zf2kgvoaFQMx2p8mrylauImtA9+sHnDcITcIHs9Wa3cqfJl58s++ --------------ms1D7CAE4D0D0C0E31FA179C32-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Mon, 16 Jun 2003 14:01:13 -0600 Organization: Level3 Communications LLC. Lines: 153 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 08:05:22 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: Hamid Ould-Brahim Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hamid Ould-Brahim wrote: > Didn't notice the change from 16 bits to 4 octets for pw status (ignore > the Hex comment) for status. Though I think a 4 octets is a large field > for a status, why not reserve some octets in that field (something like > vendor specifics, etc)... Hamid. > yes , i did that , look in the iana draft, it's in there. I left it in this thread for discussion only. Luca > -----Original Message----- > From: Ould-Brahim, Hamid [CAR:1A00:EXCH] > Sent: Monday, June 16, 2003 11:41 AM > To: 'Andrew G. Malis'; Luca Martini > Cc: pwe3@ietf.org > Subject: RE: [PWE3] status signalling of MPLS PW state > > [Catching up on my emails...] Nice to see we are making progress > on an integrated approach. Some comments on the proposal... > > > > > > >The format of the PW Status TLV is: > > >.DS 0 0 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1|0| PW Status (0x0???) | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Status Code | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > .DE > > Since the U bit in LDP notification message is set to 1 then > the U bit in Status TLV MUST be set to 0. In other words an LDP > notify message having a U bit set to 1 MUST include the status > message. Maybe this is not desirable for all notify messages having > U bit set. The problem is the notification message includes the PW > FEC TLV and that TLV is always present (no U bit) in notification > message below. In other words there is no point in including the PW > FEC in notify message without including the status TLV (therefore > the status TLV U bit must be set to 0). If we want to keep the > Status TLV optional, then we need to fix PW FEC (I don't expect that > is acceptable...). More on this item, see the end of this email... > > Where status is a 4 octet bit field: > > > > .nf > > 0x00000000 - Pseudo Wire forwarding ( clear all failures ) > > 0x00000001 - Pseudo Wire Not Forwarding > > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault > > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault > > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault > > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault > > .En > > Since these are codepoints in Hex the above should be > rewritten to: 0x0000 - Pseudo Wire forwarding ( clear all > failures ) > 0x0001 - Pseudo Wire Not Forwarding > 0x0002 - Local Customer-facing PW ( ingress ) Receive Fault > 0x0004 - Local Customer-facing PW ( egress ) Transmit Fault > 0x0008 - Local PSN-facing PW ( ingress ) Receive Fault > 0x0010 - Local PSN-facing PW ( egress ) Transmit Fault > > > >The above status codes can be logically combined to indicate > > more then a > > >single failure at once. Each fault can be cleared by sending > > an appropriate > > >status message with the respective bit cleared. The presence > > of the lowest > > >bit (PW Not Forwarding) acts only as a generic failure > > indication when there > > >is a link-down event for which none of the other bits apply. > The status should always be combined when multiple errors > happen in an incremental way. For example at a given time a PE > sends local Customer-facing ingress fault and later on the > transmit fails, the sender PE should then update the previous > status sent and not sent a separate status with only the latter > problem reported. This is to avoid that a new status for another > problem clears the problem for the previous status. Same thing > when new problems happen and other problems are cleared. The > receiving PE should screen *ALL* the status bits (for updating > the status of already reported problems), except for 0x001. It > is important to note that when this codepoint is sent the > receiving PE should *ignore* all the other bit (and not treat > them as clear). Since this is bitfield style approach, > depending what new status will be added, it may happen that not > all combinations are meaningful. I am not as well clear on > 0x001/not forwarding status. 0x0002 and 0x0010 means the PE not > forwarding as well. Reading from the above, 0x001 is only > applicable to these two codepoints (it is really a summary of > these two codepoints). If we want it to be a summary of all the > codepoints then we should call it something like > "Down/Disabled/General problem". > > > > > >The Status TLV is transported to the remote PW peer via the > > LDP notification > > >message. The format of the Notification Message is: > > > > > >.DS 0 0 > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >|1| Notification (0x0001) | Message Length | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >| Message ID | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >| PW FEC TLV | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >| PW Status TLV | > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >.DE > > > The LDP spec says that when U bit is set to 1 in the LDP > notification message: "U bit > Should be 0 when the Status TLV is sent in a Notification message. > Should be 1 when the Status TLV is sent in some other message." > In the PW status case, the normal notification for basic LDP is not > carried in some other message (still carried within the LDP > notification message). I assume this needs clarification with MPLS > WG such that LDP implementations that have U bit set will not > interpret that status will be received in some other messages (maybe > this is not an issue, a clarification/checking is always good in > case of ambiguity...). > Now if a PE doesn't understand status TLV and that PE receives a > notification message with U bit set and PW FEC& status included, > should that PE ignores the LDP notification? Note that I expect > basic LDP implementation to understand notify message but they may > not understand the status TLV. In that case, the status TLV and PW > FEC must always be present together, if a status TLV is ignored then > PW FEC is as well ignored. This area needs clarification. > > >The PW FEC TLV SHOULD not include the interface parameters > > as they are > > >ignored in the context of this message. When a PE's > > CE-facing interface > > >encounters an error, use of the new message allows the PE to > > send a single > > >Status message, using a PW FEC TLV with only the group ID > > set, to denote > > >this change in status for all affected PW connections. > > > As I indicated in my previous emails, this solution works > only with PWid FEC not with generalized ID FEC (at least for the > Group ID). I suggest we have either: a) status TLV/Notify > specified for both PW FECs, or b) a different one for Generalized ID > FEC... In either case, the text should clarify this... Note that > for l2vpn, only VPLS service (vkompella proposal) is using the PWid > FEC, the other proposals will not take advantage of this change > (until this proposal works with generalized ID FEC)... Hamid. > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Mon, 16 Jun 2003 11:41:55 -0400 Lines: 550 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3341D.D0B9BBF8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 08:35:39 2003 Return-path: To: "Andrew G. Malis" , Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C3341D.D0B9BBF8 Content-Type: text/plain; charset="iso-8859-1" [Catching up on my emails...] Nice to see we are making progress on an integrated approach. Some comments on the proposal... > > > >The format of the PW Status TLV is: > >.DS 0 0 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| PW Status (0x0???) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > .DE > Since the U bit in LDP notification message is set to 1 then the U bit in Status TLV MUST be set to 0. In other words an LDP notify message having a U bit set to 1 MUST include the status message. Maybe this is not desirable for all notify messages having U bit set. The problem is the notification message includes the PW FEC TLV and that TLV is always present (no U bit) in notification message below. In other words there is no point in including the PW FEC in notify message without including the status TLV (therefore the status TLV U bit must be set to 0). If we want to keep the Status TLV optional, then we need to fix PW FEC (I don't expect that is acceptable...). More on this item, see the end of this email... > Where status is a 4 octet bit field: > > .nf > 0x00000000 - Pseudo Wire forwarding ( clear all failures ) > 0x00000001 - Pseudo Wire Not Forwarding > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault > .En > Since these are codepoints in Hex the above should be rewritten to: 0x0000 - Pseudo Wire forwarding ( clear all failures ) 0x0001 - Pseudo Wire Not Forwarding 0x0002 - Local Customer-facing PW ( ingress ) Receive Fault 0x0004 - Local Customer-facing PW ( egress ) Transmit Fault 0x0008 - Local PSN-facing PW ( ingress ) Receive Fault 0x0010 - Local PSN-facing PW ( egress ) Transmit Fault > >The above status codes can be logically combined to indicate > more then a > >single failure at once. Each fault can be cleared by sending > an appropriate > >status message with the respective bit cleared. The presence > of the lowest > >bit (PW Not Forwarding) acts only as a generic failure > indication when there > >is a link-down event for which none of the other bits apply. The status should always be combined when multiple errors happen in an incremental way. For example at a given time a PE sends local Customer-facing ingress fault and later on the transmit fails, the sender PE should then update the previous status sent and not sent a separate status with only the latter problem reported. This is to avoid that a new status for another problem clears the problem for the previous status. Same thing when new problems happen and other problems are cleared. The receiving PE should screen *ALL* the status bits (for updating the status of already reported problems), except for 0x001. It is important to note that when this codepoint is sent the receiving PE should *ignore* all the other bit (and not treat them as clear). Since this is bitfield style approach, depending what new status will be added, it may happen that not all combinations are meaningful. I am not as well clear on 0x001/not forwarding status. 0x0002 and 0x0010 means the PE not forwarding as well. Reading from the above, 0x001 is only applicable to these two codepoints (it is really a summary of these two codepoints). If we want it to be a summary of all the codepoints then we should call it something like "Down/Disabled/General problem". > > > >The Status TLV is transported to the remote PW peer via the > LDP notification > >message. The format of the Notification Message is: > > > >.DS 0 0 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >|1| Notification (0x0001) | Message Length | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Message ID | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| PW FEC TLV | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| PW Status TLV | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >.DE > > The LDP spec says that when U bit is set to 1 in the LDP notification message: "U bit Should be 0 when the Status TLV is sent in a Notification message. Should be 1 when the Status TLV is sent in some other message." In the PW status case, the normal notification for basic LDP is not carried in some other message (still carried within the LDP notification message). I assume this needs clarification with MPLS WG such that LDP implementations that have U bit set will not interpret that status will be received in some other messages (maybe this is not an issue, a clarification/checking is always good in case of ambiguity...). Now if a PE doesn't understand status TLV and that PE receives a notification message with U bit set and PW FEC& status included, should that PE ignores the LDP notification? Note that I expect basic LDP implementation to understand notify message but they may not understand the status TLV. In that case, the status TLV and PW FEC must always be present together, if a status TLV is ignored then PW FEC is as well ignored. This area needs clarification. > >The PW FEC TLV SHOULD not include the interface parameters > as they are > >ignored in the context of this message. When a PE's > CE-facing interface > >encounters an error, use of the new message allows the PE to > send a single > >Status message, using a PW FEC TLV with only the group ID > set, to denote > >this change in status for all affected PW connections. > > As I indicated in my previous emails, this solution works only with PWid FEC not with generalized ID FEC (at least for the Group ID). I suggest we have either: a) status TLV/Notify specified for both PW FECs, or b) a different one for Generalized ID FEC... In either case, the text should clarify this... Note that for l2vpn, only VPLS service (vkompella proposal) is using the PWid FEC, the other proposals will not take advantage of this change (until this proposal works with generalized ID FEC)... Hamid. > > > > ------_=_NextPart_001_01C3341D.D0B9BBF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[Catching up on my = emails...]
 
Nice to see we are making = progress on an=20 integrated
approach. Some comments on the = proposal...

>=20 >
> >The format of the PW Status TLV is:
> >.DS 0=20 0
>  =20 0            = ;      =20 1            = ;      =20 2            = ;      =20 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=20 9 0 1
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= ;=20 |1|0|     PW Status (0x0???)   =20 |           =20 Length           =  =20 |
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= ;=20 |            = ;            = ;=20 Status=20 Code           &n= bsp;           &n= bsp;  =20 |
>=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= ;=20 .DE
>
 
Since the U bit in LDP = notification=20 message is set
to 1 then the U bit in Status = TLV MUST be=20 set to 0. In other
words an LDP notify message = having a U=20 bit set to 1
MUST include the status = message. Maybe this=20 is
not desirable for
all notify messages having U = bit=20 set. The problem is the notification
message includes the PW FEC = TLV and that=20 TLV is always
present (no U bit) in = notification message below.
In other words there is = no point in including the PW FEC in = notify=20
message without including the status TLV (therefore the = status TLV U=20 bit
must be set to 0). If we want = to keep the=20 Status TLV
optional, then we need to fix = PW FEC (I=20 don't expect that
is acceptable...). More on = this item,=20  see the end of this
email...

> Where = status is a 4 octet=20 bit field:
>
> .nf
> 0x00000000 - Pseudo Wire = forwarding (=20 clear all failures )
> 0x00000001 - Pseudo Wire Not = Forwarding
>=20 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
> = 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
> = 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
> = 0x00000010 -=20 Local PSN-facing PW ( egress ) Transmit Fault
> .En
> =
 
  Since these are = codepoints in Hex=20 the above should be
  rewritten = to:
 
  0x0000 - Pseudo = Wire forwarding=20 ( clear all failures )
  0x0001 - Pseudo Wire Not=20 Forwarding
  0x0002 - Local Customer-facing PW ( ingress ) = Receive=20 Fault
  0x0004 - Local Customer-facing PW ( egress ) = Transmit=20 Fault
  0x0008 - Local PSN-facing PW ( ingress ) Receive=20 Fault
  0x0010 - Local PSN-facing PW ( egress ) Transmit=20 Fault
  
> >The above status codes can be = logically=20 combined to indicate
> more then a
> >single failure at = once.=20 Each fault can be cleared by sending
> an appropriate
> = >status=20 message with the respective bit cleared. The presence
> of the=20 lowest
> >bit (PW Not Forwarding) acts only as a generic=20 failure
> indication when there
> >is a link-down event = for which=20 none of the other bits apply.
 
   The status should = always be=20 combined when multiple
   errors happen in = an=20 incremental way. For example at a given
   time a PE sends = local=20 Customer-facing ingress fault and later on
   the transmit = fails, the sender=20 PE should then update the previous
   status sent and = not sent a=20 separate status with only the latter
   problem = reported.
   This is to avoid = that a new=20 status for another problem
   clears the = problem for the=20 previous status. Same thing when
   new problems = happen and other=20 problems are cleared. The receiving
   PE should screen = *ALL* the=20 status bits (for updating the
   status of already = reported=20 problems), except for 0x001.
   It is important = to note that=20 when this codepoint is sent
   the = receiving PE should=20 *ignore* all the other bit (and not
   treat them = as clear).=20
 
   Since this is = bitfield style=20 approach, depending what new status
   will be added, it = may happen=20 that not all combinations
   are meaningful. =
 
   I am not as well = clear on=20 0x001/not forwarding status.
   0x0002 and 0x0010 = means the PE=20 not forwarding as well. Reading
   from the = above, 0x001 is=20 only applicable to these two
   codepoints (it is = really a=20 summary of these two codepoints).
   If we want it to = be a summary=20 of all the codepoints
   then we should = call it=20 something like "Down/Disabled/General
   = problem".  

> >
> >The = Status TLV is=20 transported to the remote PW peer via the
> LDP = notification
>=20 >message. The format of the Notification Message is:
> = >
>=20 >.DS 0 0
> > =20 0            = ;      =20 1            = ;      =20 2            = ;      =20 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=20 0 1
>=20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 >|1|   Notification   (0x0001)  =20 |      Message=20 Length           = |
>=20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 >|           &= nbsp;           &= nbsp;  =20 Message=20 ID           &nbs= p;           &nbs= p; =20 |
>=20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 >|           &= nbsp;           &= nbsp;  =20 PW FEC=20 TLV           &nb= sp;           &nb= sp; =20 |
>=20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 >|           &= nbsp;           &= nbsp;=20 PW Status=20 TLV           &nb= sp;           &nb= sp;=20 |
>=20 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 >.DE
> >
 
The LDP spec says that when U = bit is set to=20 1 in the LDP
notification = message:
 
"U = bit
   Should be 0=20 when the Status TLV is sent in a Notification=20 message.
   Should be 1 when the Status TLV is sent = in some=20 other message."
 
In the PW status case, the = normal=20 notification for basic LDP is not carried
in some other message (still = carried within=20 the LDP notification message).
I assume this needs = clarification with MPLS=20 WG such that LDP implementations
that have U bit set will not = interpret that=20 status will be received
in some other messages (maybe = this is not=20 an issue, a clarification/checking
is always good in case of=20 ambiguity...).
Now if a PE doesn't understand = status TLV=20 and that PE receives
a notification message with U = bit set and=20 PW FEC& status
included, should that PE = ignores=20 the LDP notification? Note=20 that
I expect basic LDP = implementation to=20 understand notify message
but they may not understand = the status TLV.=20 In that case, the
status TLV and PW FEC must = always be=20 present together, if
a status TLV is ignored then = PW FEC is as=20 well ignored. This
area needs clarification.

> >The PW FEC TLV = SHOULD not=20 include the interface parameters
> as they are
> = >ignored in the=20 context of this message. When a PE's
> CE-facing = interface
>=20 >encounters an error, use of the new message allows the PE = to
> send a=20 single
> >Status message, using a PW FEC TLV with only the = group=20 ID
> set, to denote
> >this change in status for all = affected PW=20 connections.
> >
 
As I indicated in my previous = emails, this=20 solution works only
with PWid FEC not with = generalized ID FEC=20 (at least for the
Group ID). I suggest we have=20 either:
 
a) status TLV/Notify specified = for both PW=20 FECs, or
b) a different one for = Generalized ID=20 FEC...
 
In either case, the text = should clarify=20 this...
Note that for l2vpn, only VPLS = service=20 (vkompella proposal) is = using=20
the PWid FEC, the other proposals will not take = advantage=20
of this change (until this = proposal works=20 with generalized
ID FEC)...
 
Hamid.

> >
>
>
------_=_NextPart_001_01C3341D.D0B9BBF8-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Mon, 16 Jun 2003 12:04:27 -0400 Lines: 634 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33420.F6948FF8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 08:59:45 2003 Return-path: To: "Hamid Ould-Brahim" , "Andrew G. Malis" , Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C33420.F6948FF8 Content-Type: text/plain; charset="iso-8859-1" Didn't notice the change from 16 bits to 4 octets for pw status (ignore the Hex comment) for status. Though I think a 4 octets is a large field for a status, why not reserve some octets in that field (something like vendor specifics, etc)... Hamid. -----Original Message----- From: Ould-Brahim, Hamid [CAR:1A00:EXCH] Sent: Monday, June 16, 2003 11:41 AM To: 'Andrew G. Malis'; Luca Martini Cc: pwe3@ietf.org Subject: RE: [PWE3] status signalling of MPLS PW state [Catching up on my emails...] Nice to see we are making progress on an integrated approach. Some comments on the proposal... > > > >The format of the PW Status TLV is: > >.DS 0 0 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| PW Status (0x0???) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > .DE > Since the U bit in LDP notification message is set to 1 then the U bit in Status TLV MUST be set to 0. In other words an LDP notify message having a U bit set to 1 MUST include the status message. Maybe this is not desirable for all notify messages having U bit set. The problem is the notification message includes the PW FEC TLV and that TLV is always present (no U bit) in notification message below. In other words there is no point in including the PW FEC in notify message without including the status TLV (therefore the status TLV U bit must be set to 0). If we want to keep the Status TLV optional, then we need to fix PW FEC (I don't expect that is acceptable...). More on this item, see the end of this email... > Where status is a 4 octet bit field: > > .nf > 0x00000000 - Pseudo Wire forwarding ( clear all failures ) > 0x00000001 - Pseudo Wire Not Forwarding > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault > .En > Since these are codepoints in Hex the above should be rewritten to: 0x0000 - Pseudo Wire forwarding ( clear all failures ) 0x0001 - Pseudo Wire Not Forwarding 0x0002 - Local Customer-facing PW ( ingress ) Receive Fault 0x0004 - Local Customer-facing PW ( egress ) Transmit Fault 0x0008 - Local PSN-facing PW ( ingress ) Receive Fault 0x0010 - Local PSN-facing PW ( egress ) Transmit Fault > >The above status codes can be logically combined to indicate > more then a > >single failure at once. Each fault can be cleared by sending > an appropriate > >status message with the respective bit cleared. The presence > of the lowest > >bit (PW Not Forwarding) acts only as a generic failure > indication when there > >is a link-down event for which none of the other bits apply. The status should always be combined when multiple errors happen in an incremental way. For example at a given time a PE sends local Customer-facing ingress fault and later on the transmit fails, the sender PE should then update the previous status sent and not sent a separate status with only the latter problem reported. This is to avoid that a new status for another problem clears the problem for the previous status. Same thing when new problems happen and other problems are cleared. The receiving PE should screen *ALL* the status bits (for updating the status of already reported problems), except for 0x001. It is important to note that when this codepoint is sent the receiving PE should *ignore* all the other bit (and not treat them as clear). Since this is bitfield style approach, depending what new status will be added, it may happen that not all combinations are meaningful. I am not as well clear on 0x001/not forwarding status. 0x0002 and 0x0010 means the PE not forwarding as well. Reading from the above, 0x001 is only applicable to these two codepoints (it is really a summary of these two codepoints). If we want it to be a summary of all the codepoints then we should call it something like "Down/Disabled/General problem". > > > >The Status TLV is transported to the remote PW peer via the > LDP notification > >message. The format of the Notification Message is: > > > >.DS 0 0 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >|1| Notification (0x0001) | Message Length | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| Message ID | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| PW FEC TLV | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >| PW Status TLV | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >.DE > > The LDP spec says that when U bit is set to 1 in the LDP notification message: "U bit Should be 0 when the Status TLV is sent in a Notification message. Should be 1 when the Status TLV is sent in some other message." In the PW status case, the normal notification for basic LDP is not carried in some other message (still carried within the LDP notification message). I assume this needs clarification with MPLS WG such that LDP implementations that have U bit set will not interpret that status will be received in some other messages (maybe this is not an issue, a clarification/checking is always good in case of ambiguity...). Now if a PE doesn't understand status TLV and that PE receives a notification message with U bit set and PW FEC& status included, should that PE ignores the LDP notification? Note that I expect basic LDP implementation to understand notify message but they may not understand the status TLV. In that case, the status TLV and PW FEC must always be present together, if a status TLV is ignored then PW FEC is as well ignored. This area needs clarification. > >The PW FEC TLV SHOULD not include the interface parameters > as they are > >ignored in the context of this message. When a PE's > CE-facing interface > >encounters an error, use of the new message allows the PE to > send a single > >Status message, using a PW FEC TLV with only the group ID > set, to denote > >this change in status for all affected PW connections. > > As I indicated in my previous emails, this solution works only with PWid FEC not with generalized ID FEC (at least for the Group ID). I suggest we have either: a) status TLV/Notify specified for both PW FECs, or b) a different one for Generalized ID FEC... In either case, the text should clarify this... Note that for l2vpn, only VPLS service (vkompella proposal) is using the PWid FEC, the other proposals will not take advantage of this change (until this proposal works with generalized ID FEC)... Hamid. > > > > ------_=_NextPart_001_01C33420.F6948FF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Didn't=20 notice the change from 16 bits to 4 octets for
pw status=20 (ignore the Hex comment) for
status. Though I think a 4 = octets is a=20 large field for a status,
why not=20 reserve some octets in that field=20 (something
like vendor=20 specifics, etc)...
 
Hamid.
-----Original Message-----
From: Ould-Brahim, = Hamid=20 [CAR:1A00:EXCH]
Sent: Monday, June 16, 2003 11:41 = AM
To:=20 'Andrew G. Malis'; Luca Martini
Cc: = pwe3@ietf.org
Subject:=20 RE: [PWE3] status signalling of MPLS PW state

[Catching up on my=20 emails...]
 
Nice to see we are making = progress on an=20 integrated
approach. Some comments on = the=20 proposal...

>=20 >
> >The format of the PW Status TLV is:
> >.DS = 0=20 0
>  =20 = 0            = ;      =20 = 1            = ;      =20 = 2            = ;      =20 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=20 8 9 0 1
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= ;=20 |1|0|     PW Status (0x0???)   =20 |           =20 = Length           =  =20 |
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= ;=20 = |            = ;            = ;=20 Status=20 = Code           &n= bsp;           &n= bsp;  =20 |
>=20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>= ;=20 .DE
>
 
Since the U bit in LDP = notification=20 message is set
to 1 then the U bit in = Status TLV MUST be=20 set to 0. In other
words an LDP notify message = having=20 a U bit set to 1
MUST include the status = message. Maybe=20 this is
not desirable = for
all notify messages having U = bit=20 set. The problem is the notification
message includes the PW FEC = TLV and that=20 TLV is always
present (no U bit) in = notification message below. =
In other words there is = no point in including the PW FEC in = notify=20
message without including the status TLV (therefore the = status TLV U=20 bit
must be set to 0). If we = want to keep the=20 Status TLV
optional, then we need to = fix PW FEC (I=20 don't expect that
is acceptable...). More on = this item,=20  see the end of this
email...

> Where = status is a 4=20 octet bit field:
>
> .nf
> 0x00000000 - Pseudo = Wire=20 forwarding ( clear all failures )
> 0x00000001 - Pseudo Wire = Not=20 Forwarding
> 0x00000002 - Local Customer-facing PW ( ingress ) = Receive=20 Fault
> 0x00000004 - Local Customer-facing PW ( egress ) = Transmit=20 Fault
> 0x00000008 - Local PSN-facing PW ( ingress ) Receive=20 Fault
> 0x00000010 - Local PSN-facing PW ( egress ) Transmit=20 Fault
> .En
>
  Since these are = codepoints in Hex=20 the above should be
  rewritten = to:
 
  0x0000 - Pseudo = Wire=20 forwarding ( clear all failures )
  0x0001 - Pseudo Wire = Not=20 Forwarding
  0x0002 - Local Customer-facing PW ( ingress = )=20 Receive Fault
  0x0004 - Local Customer-facing PW ( = egress )=20 Transmit Fault
  0x0008 - Local PSN-facing PW ( ingress = ) Receive=20 Fault
  0x0010 - Local PSN-facing PW ( egress ) Transmit = Fault
  
> >The above status codes can be = logically=20 combined to indicate
> more then a
> >single failure = at once.=20 Each fault can be cleared by sending
> an appropriate
> = >status=20 message with the respective bit cleared. The presence
> of the=20 lowest
> >bit (PW Not Forwarding) acts only as a generic=20 failure
> indication when there
> >is a link-down = event for=20 which none of the other bits apply.
 
   The status = should always be=20 combined when multiple
   errors happen = in an=20 incremental way. For example at a given
   time a PE sends = local=20 Customer-facing ingress fault and later on
   the transmit = fails, the=20 sender PE should then update the previous
   status sent and = not sent a=20 separate status with only the latter
   problem=20 reported.
   This is to = avoid that a new=20 status for another problem
   clears the = problem for the=20 previous status. Same thing when
   new problems = happen and=20 other problems are cleared. The receiving
   PE should = screen *ALL* the=20 status bits (for updating the
   status of = already reported=20 problems), except for 0x001.
   It is important = to note that=20 when this codepoint is sent=20
   the = receiving PE should=20 *ignore* all the other bit (and not
   treat them = as clear).=20
 
   Since this is = bitfield style=20 approach, depending what new status
   will be added, = it may happen=20 that not all combinations
   are meaningful. =
 
   I am not as = well clear on=20 0x001/not forwarding status.
   0x0002 and = 0x0010 means the=20 PE not forwarding as well. Reading
   from the = above, 0x001=20 is only applicable to these two
   codepoints (it = is really a=20 summary of these two codepoints).
   If we want it = to be a=20 summary of all the codepoints
   then we should = call it=20 something like "Down/Disabled/General
   = problem".  

> >
> = >The Status TLV=20 is transported to the remote PW peer via the
> LDP = notification
>=20 >message. The format of the Notification Message is:
> = >
>=20 >.DS 0 0
> > =20 = 0            = ;      =20 = 1            = ;      =20 = 2            = ;      =20 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=20 9 0 1
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 >|1|   Notification   (0x0001)  =20 |      Message=20 Length           = |
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 = >|           &= nbsp;           &= nbsp;  =20 Message=20 = ID           &nbs= p;           &nbs= p; =20 |
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 = >|           &= nbsp;           &= nbsp;  =20 PW FEC=20 = TLV           &nb= sp;           &nb= sp; =20 |
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 = >|           &= nbsp;           &= nbsp;=20 PW Status=20 = TLV           &nb= sp;           &nb= sp;=20 |
>=20 = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>=20 >.DE
> >
 
The LDP spec says that when = U bit is set=20 to 1 in the LDP
notification = message:
 
"U = bit
   Should be 0=20 when the Status TLV is sent in a Notification=20 message.
   Should be 1 when the Status TLV is sent = in some=20 other message."
 
In the PW status case, the = normal=20 notification for basic LDP is not carried
in some other message (still = carried=20 within the LDP notification message).
I assume this needs = clarification with=20 MPLS WG such that LDP implementations
that have U bit set will not = interpret=20 that status will be received
in some other messages = (maybe this is not=20 an issue, a clarification/checking
is always good in case of=20 ambiguity...).
Now if a PE doesn't = understand status TLV=20 and that PE receives
a notification message with = U bit set and=20 PW FEC& status
included, should that PE = ignores=20 the LDP notification? Note = that
I expect basic LDP = implementation to=20 understand notify message
but they may not understand = the status=20 TLV. In that case, the
status TLV and PW FEC must = always be=20 present together, if
a status TLV is ignored then = PW FEC is as=20 well ignored. This
area needs clarification.

> >The PW FEC TLV = SHOULD not=20 include the interface parameters
> as they are
> = >ignored in=20 the context of this message. When a PE's
> CE-facing = interface
>=20 >encounters an error, use of the new message allows the PE = to
> send=20 a single
> >Status message, using a PW FEC TLV with only the = group=20 ID
> set, to denote
> >this change in status for all = affected=20 PW connections.
> >
 
As I indicated in my previous= emails,=20 this solution works only
with PWid FEC not with = generalized ID FEC=20 (at least for the
Group ID). I suggest we have = either:
 
a) status TLV/Notify = specified for both=20 PW FECs, or
b) a different one for = Generalized ID=20 FEC...
 
In either case, the text = should clarify=20 this...
Note that for l2vpn, only = VPLS service=20 (vkompella proposal) is using=20
the PWid FEC, the other proposals will not take = advantage=20
of this change (until this = proposal works=20 with generalized
ID FEC)...
 
Hamid.

> >
>
> =
------_=_NextPart_001_01C33420.F6948FF8-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Romascanu, Dan (Dan)" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 17 Jun 2003 09:29:20 +0300 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "Israel Sasson" , "Akiva Sadovski" , "Eduard Metz (E-mail)" , "Tim Frost (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Tue Jun 17 11:45:34 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcMxDKQ8FN28AGNTQdmN62Gg7qliGgDjDq9A To: "Danny McPherson" , "Sasha Vainshtein" , "Stewart Bryant (E-mail)" , "PWE3 WG (E-mail)" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H6TQm24666 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 in favor this draft becoming a WG item. This standard is needed, and this approach seems to be the one that comes closer to catching significant support. The number of participants in the process supporting the standard seems to exceed by far the threshold that would ensure interoperable implementations and further advancement of the standard. Further work as WG item, and the quality review that standards track I-Ds go through will only help in refining the details and clearing up possible problems. Dan > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net] > Sent: Thursday, June 12, 2003 7:57 PM > To: Sasha Vainshtein; Stewart Bryant (E-mail); PWE3 WG (E-mail) > Cc: Israel Sasson; Akiva Sadovski; Eduard Metz (E-mail); Tim > Frost (E-mail); Prayson Pate (E-mail) > Subject: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > If there are other folks that would like to see this document > become a WG > item please speak up now. > > -danny > > On 6/10/03 10:12 AM, "Sasha Vainshtein" wrote: > > > Stewart, Danny and all, > > As (some of) you have probably noticed I have posted an > > updated (-06) revision of the CESoPSN draft. > > > > I would like to ask the WG to adopt this draft as a WG item, > > and this message is intended to initiate a TECHNICAL discussion > > on this subject. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Re: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 17 Jun 2003 07:52:47 -0600 Lines: 14 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Tue Jun 17 17:33:40 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: "Romascanu, Dan (Dan)" 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 On 6/17/03 12:29 AM, "Romascanu, Dan (Dan)" wrote: > I am in favor this draft becoming a WG item. This standard is needed, and this > approach seems to be the one that comes closer to catching significant > support. The number of participants in the process supporting the standard > seems to exceed by far the threshold that would ensure interoperable > implementations and further advancement of the standard. Really? Can you elaborate on this (i.e., how many other folks have/are implementing this)? Thanks! -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt Date: Tue, 17 Jun 2003 07:57:26 -0400 Lines: 83 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 20:03:02 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Encapsulation Methods for Transport of PPP/HDLC Frames Over IP and MPLS Networks Author(s) : L. Martini et al. Filename : draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt Pages : 10 Date : 2003-6-16 A Pseudowire (PW) can be used to carry PPP, or HDLC Protocol Data Units over an IP or MPLS network without terminating the PPP/HDLC protocol. This enables service providers to offer 'emulated' HDLC, or PPP link services over existing IP or MPLS networks. This document specifies the encapsulation of PPP/HDLC PDUs within a pseudowire. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Romascanu, Dan (Dan)" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 17 Jun 2003 17:17:00 +0300 Lines: 39 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 Jun 17 20:03:39 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcM019ERNrG1lXXcSXe6zMD74epRXwAAhgnA To: "Danny McPherson" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HEI7m32058 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 am seeing the messages that you are seeing - maybe less :-) Assuming that people who declared their support are doing it on a responsible manner, it looks that there are more than two independent implementations on the way. Dan > -----Original Message----- > From: Danny McPherson [mailto:danny@tcb.net] > Sent: Tuesday, June 17, 2003 4:53 PM > To: Romascanu, Dan (Dan) > Cc: pwe3@ietf.org > Subject: Re: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > On 6/17/03 12:29 AM, "Romascanu, Dan (Dan)" > wrote: > > > I am in favor this draft becoming a WG item. This standard > is needed, and this > > approach seems to be the one that comes closer to catching > significant > > support. The number of participants in the process > supporting the standard > > seems to exceed by far the threshold that would ensure interoperable > > implementations and further advancement of the standard. > > Really? Can you elaborate on this (i.e., how many other > folks have/are > implementing this)? > > Thanks! > > -danny > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 07:57:31 -0400 Lines: 83 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 20:08:48 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) Author(s) : L. Martini, W. Townsley Filename : draft-ietf-pwe3-iana-allocation-01.txt Pages : 5 Date : 2003-6-16 The Control and maintenance protocol for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [2]. This document pre-allocates the fixed Pseudo-wire identifier , and other fixed protocol values that are to be assigned by IANA using the 'IETF Consensus' policy defined in RFC2434 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-iana-allocation-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-arch-04.txt Date: Tue, 17 Jun 2003 07:57:35 -0400 Lines: 83 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 20:16:22 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Architecture Author(s) : S. Bryant, P. Pate Filename : draft-ietf-pwe3-arch-04.txt Pages : 46 Date : 2003-6-16 This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services (such as Frame Relay, ATM, Ethernet TDM and SONET/SDH) over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, specifies the various protocol elements and their functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-arch-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-arch-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 16:42:34 +0200 Lines: 83 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: pwe3@ietf.org, "Andrew G. Malis (E-mail)" X-From: pwe3-admin@ietf.org Tue Jun 17 20:31:11 2003 Return-path: To: "Mark Townsley (E-mail)" , "Luca (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mark and Luca, Can you (or Andy) explain why it is necessary to maintain separate PW types for CEP and CEM? And, BTW, CEM description includes a reference [8] which is simply lacking in the document. If a reference to draft-malis has been intended, this draft seem to be expired (no such at the IETF site)... 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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, June 17, 2003 1:58 PM > Cc: pwe3@ietf.org > Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Pseudo Wire Emulation Edge > to Edge Working Group of the IETF. > > Title : IANA Allocations for pseudo Wire Edge to Edge > Emulation (PWE3) > Author(s) : L. Martini, W. Townsley > Filename : draft-ietf-pwe3-iana-allocation-01.txt > Pages : 5 > Date : 2003-6-16 > > The Control and maintenance protocol for providing various Layer 1 > and Layer 2 services over a Packet Switched Network has been > described in [2]. This document pre-allocates the fixed Pseudo-wire > identifier , and other fixed protocol values that are to be assigned > by IANA using the 'IETF Consensus' policy defined in RFC2434 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc > ation-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pwe3-iana-allocation-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 10:05:10 -0600 Organization: Level3 Communications LLC. Lines: 94 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: "Mark Townsley (E-mail)" , pwe3@ietf.org, "Andrew G. Malis (E-mail)" X-From: pwe3-admin@ietf.org Tue Jun 17 20:41:15 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: Sasha Vainshtein Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O ok, i'll fix the reference. Andy can you send me the correct one ? Luca Sasha Vainshtein wrote: > Mark and Luca, > Can you (or Andy) explain why it is necessary to maintain > separate PW types for CEP and CEM? > And, BTW, CEM description includes a reference [8] which is > simply lacking in the document. If a reference to draft-malis has > been intended, this draft seem to be expired (no such at the IETF site)... > > 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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Sent: Tuesday, June 17, 2003 1:58 PM >>Cc: pwe3@ietf.org >>Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt >> >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >>This draft is a work item of the Pseudo Wire Emulation Edge >>to Edge Working Group of the IETF. >> >> Title : IANA Allocations for pseudo Wire Edge to Edge >> Emulation (PWE3) >> Author(s) : L. Martini, W. Townsley >> Filename : draft-ietf-pwe3-iana-allocation-01.txt >> Pages : 5 >> Date : 2003-6-16 >> >>The Control and maintenance protocol for providing various Layer 1 >>and Layer 2 services over a Packet Switched Network has been >>described in [2]. This document pre-allocates the fixed Pseudo-wire >>identifier , and other fixed protocol values that are to be assigned >>by IANA using the 'IETF Consensus' policy defined in RFC2434 >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc >>ation-01.txt >> >>To remove yourself from the IETF Announcement list, send a message to >>ietf-announce-request with the word unsubscribe in the body >>of the message. >> >>Internet-Drafts are also available by anonymous FTP. Login >>with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-pwe3-iana-allocation-01.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >>mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Andrew G. Malis" Subject: Re: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 10:41:02 -0400 Lines: 109 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Mark Townsley (E-mail)" , "Luca (E-mail)" , pwe3@ietf.org, "Andrew G. Malis (E-mail)" X-From: pwe3-admin@ietf.org Tue Jun 17 20:43:15 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Sasha Vainshtein In-Reply-To: X-OriginalArrivalTime: 17 Jun 2003 14:41:09.0463 (UTC) FILETIME=[7DCF5670:01C334DE] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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, CEP is, as we know, going to be the standards track specification. However, it is still a bit of a moving target, and I can't speak for other companies, but Vivace intends to hold off on completing our implementation until we're in the final stages of publishing the RFC, since it's being implemented in silicon. Meanwhile, there are several existing implementations of CEM, including Vivace's. Once CEP is ready to replace CEM in the field, we need a new PW type for it since the bits on the wire will be different - otherwise it will be impossible to gracefully upgrade. It's not like we're running out of PW types. Finally, once CEP has been published as the standards track document, we intend to publish CEM as an informational/historical RFC to document the original implementations for posterity. Thanks for pointing out the broken reference. I'll fix it. Cheers, Andy ------- At 6/17/2003 04:42 PM +0200, Sasha Vainshtein wrote: >Mark and Luca, >Can you (or Andy) explain why it is necessary to maintain >separate PW types for CEP and CEM? >And, BTW, CEM description includes a reference [8] which is >simply lacking in the document. If a reference to draft-malis has >been intended, this draft seem to be expired (no such at the IETF site)... > >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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, June 17, 2003 1:58 PM > > Cc: pwe3@ietf.org > > Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Pseudo Wire Emulation Edge > > to Edge Working Group of the IETF. > > > > Title : IANA Allocations for pseudo Wire Edge to Edge > > Emulation (PWE3) > > Author(s) : L. Martini, W. Townsley > > Filename : draft-ietf-pwe3-iana-allocation-01.txt > > Pages : 5 > > Date : 2003-6-16 > > > > The Control and maintenance protocol for providing various Layer 1 > > and Layer 2 services over a Packet Switched Network has been > > described in [2]. This document pre-allocates the fixed Pseudo-wire > > identifier , and other fixed protocol values that are to be assigned > > by IANA using the 'IETF Consensus' policy defined in RFC2434 > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc > > ation-01.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-pwe3-iana-allocation-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 17:48:27 +0200 Lines: 153 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "Mark Townsley (E-mail)" , "Luca (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 20:44:11 2003 Return-path: To: "'Andrew G. Malis'" 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 Andy, Thank you for a clarification. The situation is well understood. However, since CEM is NOT going to be a standard, I would suggest assigning it a value in the vendror-specific range. 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: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Tuesday, June 17, 2003 4:41 PM > To: Sasha Vainshtein > Cc: Mark Townsley (E-mail); Luca (E-mail); pwe3@ietf.org; > Andrew G. Malis (E-mail) > Subject: Re: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt > > > Sasha, > > CEP is, as we know, going to be the standards track > specification. However, it is still a bit of a moving > target, and I can't > speak for other companies, but Vivace intends to hold off on > completing our > implementation until we're in the final stages of publishing > the RFC, since > it's being implemented in silicon. > > Meanwhile, there are several existing implementations of CEM, > including > Vivace's. Once CEP is ready to replace CEM in the field, we > need a new PW > type for it since the bits on the wire will be different - > otherwise it > will be impossible to gracefully upgrade. It's not like > we're running out > of PW types. > > Finally, once CEP has been published as the standards track > document, we > intend to publish CEM as an informational/historical RFC to > document the > original implementations for posterity. > > Thanks for pointing out the broken reference. I'll fix it. > > Cheers, > Andy > > ------- > > At 6/17/2003 04:42 PM +0200, Sasha Vainshtein wrote: > >Mark and Luca, > >Can you (or Andy) explain why it is necessary to maintain > >separate PW types for CEP and CEM? > >And, BTW, CEM description includes a reference [8] which is > >simply lacking in the document. If a reference to draft-malis has > >been intended, this draft seem to be expired (no such at the > IETF site)... > > > >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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: Tuesday, June 17, 2003 1:58 PM > > > Cc: pwe3@ietf.org > > > Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > This draft is a work item of the Pseudo Wire Emulation Edge > > > to Edge Working Group of the IETF. > > > > > > Title : IANA Allocations for pseudo Wire > Edge to Edge > > > Emulation (PWE3) > > > Author(s) : L. Martini, W. Townsley > > > Filename : draft-ietf-pwe3-iana-allocation-01.txt > > > Pages : 5 > > > Date : 2003-6-16 > > > > > > The Control and maintenance protocol for providing various Layer 1 > > > and Layer 2 services over a Packet Switched Network has been > > > described in [2]. This document pre-allocates the fixed > Pseudo-wire > > > identifier , and other fixed protocol values that are to > be assigned > > > by IANA using the 'IETF Consensus' policy defined in RFC2434 > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc > > > ation-01.txt > > > > > > To remove yourself from the IETF Announcement list, send > a message to > > > ietf-announce-request with the word unsubscribe in the body > > > of the message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > with the username > > > "anonymous" and a password of your e-mail address. After > logging in, > > > type "cd internet-drafts" and then > > > "get draft-ietf-pwe3-iana-allocation-01.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before > the "FILE" > > > command. To decode the response(s), you will need > "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant > > > mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which > have been split > > > up into multiple messages), so check your local > documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Last Call: draft-ietf-pwe3-arch-04.txt Date: Tue, 17 Jun 2003 08:16:41 -0600 Lines: 103 Sender: pwe3-admin@ietf.org References: <200306171157.HAA08508@ietf.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="B_3138682605_128852" X-From: pwe3-admin@ietf.org Tue Jun 17 20:44:13 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: In-Reply-To: <200306171157.HAA08508@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 > 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. --B_3138682605_128852 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Folks, Consider this a two week Last Call for the PWE3 Architecture document. Last Call ends on July 1, 2003. Please note that issues recently discussed on the WG mailing list have been incorporated into this version of the draft. -danny ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Tue, 17 Jun 2003 07:57:35 -0400 To: IETF-Announce: ; Cc: pwe3@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-arch-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Architecture Author(s) : S. Bryant, P. Pate Filename : draft-ietf-pwe3-arch-04.txt Pages : 46 Date : 2003-6-16 This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services (such as Frame Relay, ATM, Ethernet TDM and SONET/SDH) over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, specifies the various protocol elements and their functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-arch-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-arch-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------ End of Forwarded Message --B_3138682605_128852 Content-type: message/external-body; name="Attachment (Anarchie document)"; x-mac-type="4155524C" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6CTwyMDAzLTYtMTcwNzU0NTYu SS1EQGlldGYub3JnPg0NRU5DT0RJTkcgbWltZQ1GSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1wd2UzLWFyY2gtMDQudHh0DQ0= --B_3138682605_128852 Content-type: application/octet-stream; name="draft-ietf-pwe3-arch-04.txt" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6CTwyMDAzLTYtMTcwNzU0NTYu SS1EQGlldGYub3JnPg0N --B_3138682605_128852-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 18:07:44 +0200 Lines: 196 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "Mark Townsley (E-mail)" , "Luca (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 20:46:01 2003 Return-path: To: "'Andrew G. Malis'" 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 Andy, Understood. IMO, worth an explanation in the draft (since you are fixing the broken reference). 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: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Tuesday, June 17, 2003 5:06 PM > To: Sasha Vainshtein > Cc: 'Andrew G. Malis'; Mark Townsley (E-mail); Luca (E-mail); > pwe3@ietf.org > Subject: RE: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt > > > Sasha, > > Except that shipping implementations are using the current > value - I would > like to grandfather it in. That's certainly been done in the > past and it's > not a tight resource. > > Thanks, > Andy > > --------- > > At 6/17/2003 05:48 PM +0200, Sasha Vainshtein wrote: > >Andy, > >Thank you for a clarification. The situation is well understood. > >However, since CEM is NOT going to be a standard, I would > >suggest assigning it a value in the vendror-specific range. > > > >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: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > > > Sent: Tuesday, June 17, 2003 4:41 PM > > > To: Sasha Vainshtein > > > Cc: Mark Townsley (E-mail); Luca (E-mail); pwe3@ietf.org; > > > Andrew G. Malis (E-mail) > > > Subject: Re: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt > > > > > > > > > Sasha, > > > > > > CEP is, as we know, going to be the standards track > > > specification. However, it is still a bit of a moving > > > target, and I can't > > > speak for other companies, but Vivace intends to hold off on > > > completing our > > > implementation until we're in the final stages of publishing > > > the RFC, since > > > it's being implemented in silicon. > > > > > > Meanwhile, there are several existing implementations of CEM, > > > including > > > Vivace's. Once CEP is ready to replace CEM in the field, we > > > need a new PW > > > type for it since the bits on the wire will be different - > > > otherwise it > > > will be impossible to gracefully upgrade. It's not like > > > we're running out > > > of PW types. > > > > > > Finally, once CEP has been published as the standards track > > > document, we > > > intend to publish CEM as an informational/historical RFC to > > > document the > > > original implementations for posterity. > > > > > > Thanks for pointing out the broken reference. I'll fix it. > > > > > > Cheers, > > > Andy > > > > > > ------- > > > > > > At 6/17/2003 04:42 PM +0200, Sasha Vainshtein wrote: > > > >Mark and Luca, > > > >Can you (or Andy) explain why it is necessary to maintain > > > >separate PW types for CEP and CEM? > > > >And, BTW, CEM description includes a reference [8] which is > > > >simply lacking in the document. If a reference to draft-malis has > > > >been intended, this draft seem to be expired (no such at the > > > IETF site)... > > > > > > > >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: Internet-Drafts@ietf.org > [mailto:Internet-Drafts@ietf.org] > > > > > Sent: Tuesday, June 17, 2003 1:58 PM > > > > > Cc: pwe3@ietf.org > > > > > Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > Internet-Drafts directories. > > > > > This draft is a work item of the Pseudo Wire Emulation Edge > > > > > to Edge Working Group of the IETF. > > > > > > > > > > Title : IANA Allocations for pseudo Wire > > > Edge to Edge > > > > > Emulation (PWE3) > > > > > Author(s) : L. Martini, W. Townsley > > > > > Filename : draft-ietf-pwe3-iana-allocation-01.txt > > > > > Pages : 5 > > > > > Date : 2003-6-16 > > > > > > > > > > The Control and maintenance protocol for providing > various Layer 1 > > > > > and Layer 2 services over a Packet Switched Network has been > > > > > described in [2]. This document pre-allocates the fixed > > > Pseudo-wire > > > > > identifier , and other fixed protocol values that are to > > > be assigned > > > > > by IANA using the 'IETF Consensus' policy defined in RFC2434 > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc > > > > > ation-01.txt > > > > > > > > > > To remove yourself from the IETF Announcement list, send > > > a message to > > > > > ietf-announce-request with the word unsubscribe in the body > > > > > of the message. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > > > with the username > > > > > "anonymous" and a password of your e-mail address. After > > > logging in, > > > > > type "cd internet-drafts" and then > > > > > "get draft-ietf-pwe3-iana-allocation-01.txt". > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > http://www.ietf.org/shadow.html > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > Send a message to: > > > > > mailserv@ietf.org. > > > > > In the body type: > > > > > "FILE > > > /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > MIME-encoded form by using the "mpack" utility. > To use this > > > > > feature, insert the command "ENCODING mime" before > > > the "FILE" > > > > > command. To decode the response(s), you will need > > > "munpack" or > > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > > mail readers > > > > > exhibit different behavior, especially when dealing with > > > > > "multipart" MIME messages (i.e. documents which > > > have been split > > > > > up into multiple messages), so check your local > > > documentation on > > > > > how to manipulate these messages. > > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant > mail reader > > > > > implementation to automatically retrieve the ASCII > version of the > > > > > Internet-Draft. > > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Andrew G. Malis" Subject: RE: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 11:05:43 -0400 Lines: 165 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Andrew G. Malis'" , "Mark Townsley (E-mail)" , "Luca (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 20:47:36 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Sasha Vainshtein In-Reply-To: X-OriginalArrivalTime: 17 Jun 2003 15:05:50.0091 (UTC) FILETIME=[F0553DB0:01C334E1] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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, Except that shipping implementations are using the current value - I would like to grandfather it in. That's certainly been done in the past and it's not a tight resource. Thanks, Andy --------- At 6/17/2003 05:48 PM +0200, Sasha Vainshtein wrote: >Andy, >Thank you for a clarification. The situation is well understood. >However, since CEM is NOT going to be a standard, I would >suggest assigning it a value in the vendror-specific range. > >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: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > > Sent: Tuesday, June 17, 2003 4:41 PM > > To: Sasha Vainshtein > > Cc: Mark Townsley (E-mail); Luca (E-mail); pwe3@ietf.org; > > Andrew G. Malis (E-mail) > > Subject: Re: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt > > > > > > Sasha, > > > > CEP is, as we know, going to be the standards track > > specification. However, it is still a bit of a moving > > target, and I can't > > speak for other companies, but Vivace intends to hold off on > > completing our > > implementation until we're in the final stages of publishing > > the RFC, since > > it's being implemented in silicon. > > > > Meanwhile, there are several existing implementations of CEM, > > including > > Vivace's. Once CEP is ready to replace CEM in the field, we > > need a new PW > > type for it since the bits on the wire will be different - > > otherwise it > > will be impossible to gracefully upgrade. It's not like > > we're running out > > of PW types. > > > > Finally, once CEP has been published as the standards track > > document, we > > intend to publish CEM as an informational/historical RFC to > > document the > > original implementations for posterity. > > > > Thanks for pointing out the broken reference. I'll fix it. > > > > Cheers, > > Andy > > > > ------- > > > > At 6/17/2003 04:42 PM +0200, Sasha Vainshtein wrote: > > >Mark and Luca, > > >Can you (or Andy) explain why it is necessary to maintain > > >separate PW types for CEP and CEM? > > >And, BTW, CEM description includes a reference [8] which is > > >simply lacking in the document. If a reference to draft-malis has > > >been intended, this draft seem to be expired (no such at the > > IETF site)... > > > > > >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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > > Sent: Tuesday, June 17, 2003 1:58 PM > > > > Cc: pwe3@ietf.org > > > > Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts directories. > > > > This draft is a work item of the Pseudo Wire Emulation Edge > > > > to Edge Working Group of the IETF. > > > > > > > > Title : IANA Allocations for pseudo Wire > > Edge to Edge > > > > Emulation (PWE3) > > > > Author(s) : L. Martini, W. Townsley > > > > Filename : draft-ietf-pwe3-iana-allocation-01.txt > > > > Pages : 5 > > > > Date : 2003-6-16 > > > > > > > > The Control and maintenance protocol for providing various Layer 1 > > > > and Layer 2 services over a Packet Switched Network has been > > > > described in [2]. This document pre-allocates the fixed > > Pseudo-wire > > > > identifier , and other fixed protocol values that are to > > be assigned > > > > by IANA using the 'IETF Consensus' policy defined in RFC2434 > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc > > > > ation-01.txt > > > > > > > > To remove yourself from the IETF Announcement list, send > > a message to > > > > ietf-announce-request with the word unsubscribe in the body > > > > of the message. > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > > with the username > > > > "anonymous" and a password of your e-mail address. After > > logging in, > > > > type "cd internet-drafts" and then > > > > "get draft-ietf-pwe3-iana-allocation-01.txt". > > > > > > > > A list of Internet-Drafts directories can be found in > > > > http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > Send a message to: > > > > mailserv@ietf.org. > > > > In the body type: > > > > "FILE > > /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > MIME-encoded form by using the "mpack" utility. To use this > > > > feature, insert the command "ENCODING mime" before > > the "FILE" > > > > command. To decode the response(s), you will need > > "munpack" or > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > mail readers > > > > exhibit different behavior, especially when dealing with > > > > "multipart" MIME messages (i.e. documents which > > have been split > > > > up into multiple messages), so check your local > > documentation on > > > > how to manipulate these messages. > > > > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > > implementation to automatically retrieve the ASCII version of the > > > > Internet-Draft. > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Andrew G. Malis" Subject: RE: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 11:12:24 -0400 Lines: 206 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'Andrew G. Malis'" , "Mark Townsley (E-mail)" , "Luca (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 20:53:17 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Sasha Vainshtein In-Reply-To: X-OriginalArrivalTime: 17 Jun 2003 15:12:30.0956 (UTC) FILETIME=[DF4462C0:01C334E2] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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, OK, sounds good. Cheers, Andy ------ At 6/17/2003 06:07 PM +0200, Sasha Vainshtein wrote: >Andy, >Understood. >IMO, worth an explanation in the draft (since you >are fixing the broken reference). > >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: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > > Sent: Tuesday, June 17, 2003 5:06 PM > > To: Sasha Vainshtein > > Cc: 'Andrew G. Malis'; Mark Townsley (E-mail); Luca (E-mail); > > pwe3@ietf.org > > Subject: RE: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt > > > > > > Sasha, > > > > Except that shipping implementations are using the current > > value - I would > > like to grandfather it in. That's certainly been done in the > > past and it's > > not a tight resource. > > > > Thanks, > > Andy > > > > --------- > > > > At 6/17/2003 05:48 PM +0200, Sasha Vainshtein wrote: > > >Andy, > > >Thank you for a clarification. The situation is well understood. > > >However, since CEM is NOT going to be a standard, I would > > >suggest assigning it a value in the vendror-specific range. > > > > > >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: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > > > > Sent: Tuesday, June 17, 2003 4:41 PM > > > > To: Sasha Vainshtein > > > > Cc: Mark Townsley (E-mail); Luca (E-mail); pwe3@ietf.org; > > > > Andrew G. Malis (E-mail) > > > > Subject: Re: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt > > > > > > > > > > > > Sasha, > > > > > > > > CEP is, as we know, going to be the standards track > > > > specification. However, it is still a bit of a moving > > > > target, and I can't > > > > speak for other companies, but Vivace intends to hold off on > > > > completing our > > > > implementation until we're in the final stages of publishing > > > > the RFC, since > > > > it's being implemented in silicon. > > > > > > > > Meanwhile, there are several existing implementations of CEM, > > > > including > > > > Vivace's. Once CEP is ready to replace CEM in the field, we > > > > need a new PW > > > > type for it since the bits on the wire will be different - > > > > otherwise it > > > > will be impossible to gracefully upgrade. It's not like > > > > we're running out > > > > of PW types. > > > > > > > > Finally, once CEP has been published as the standards track > > > > document, we > > > > intend to publish CEM as an informational/historical RFC to > > > > document the > > > > original implementations for posterity. > > > > > > > > Thanks for pointing out the broken reference. I'll fix it. > > > > > > > > Cheers, > > > > Andy > > > > > > > > ------- > > > > > > > > At 6/17/2003 04:42 PM +0200, Sasha Vainshtein wrote: > > > > >Mark and Luca, > > > > >Can you (or Andy) explain why it is necessary to maintain > > > > >separate PW types for CEP and CEM? > > > > >And, BTW, CEM description includes a reference [8] which is > > > > >simply lacking in the document. If a reference to draft-malis has > > > > >been intended, this draft seem to be expired (no such at the > > > > IETF site)... > > > > > > > > > >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: Internet-Drafts@ietf.org > > [mailto:Internet-Drafts@ietf.org] > > > > > > Sent: Tuesday, June 17, 2003 1:58 PM > > > > > > Cc: pwe3@ietf.org > > > > > > Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > > > Internet-Drafts directories. > > > > > > This draft is a work item of the Pseudo Wire Emulation Edge > > > > > > to Edge Working Group of the IETF. > > > > > > > > > > > > Title : IANA Allocations for pseudo Wire > > > > Edge to Edge > > > > > > Emulation (PWE3) > > > > > > Author(s) : L. Martini, W. Townsley > > > > > > Filename : draft-ietf-pwe3-iana-allocation-01.txt > > > > > > Pages : 5 > > > > > > Date : 2003-6-16 > > > > > > > > > > > > The Control and maintenance protocol for providing > > various Layer 1 > > > > > > and Layer 2 services over a Packet Switched Network has been > > > > > > described in [2]. This document pre-allocates the fixed > > > > Pseudo-wire > > > > > > identifier , and other fixed protocol values that are to > > > > be assigned > > > > > > by IANA using the 'IETF Consensus' policy defined in RFC2434 > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc > > > > > > ation-01.txt > > > > > > > > > > > > To remove yourself from the IETF Announcement list, send > > > > a message to > > > > > > ietf-announce-request with the word unsubscribe in the body > > > > > > of the message. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > > > > with the username > > > > > > "anonymous" and a password of your e-mail address. After > > > > logging in, > > > > > > type "cd internet-drafts" and then > > > > > > "get draft-ietf-pwe3-iana-allocation-01.txt". > > > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > > http://www.ietf.org/shadow.html > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > > > Send a message to: > > > > > > mailserv@ietf.org. > > > > > > In the body type: > > > > > > "FILE > > > > /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > > MIME-encoded form by using the "mpack" utility. > > To use this > > > > > > feature, insert the command "ENCODING mime" before > > > > the "FILE" > > > > > > command. To decode the response(s), you will need > > > > "munpack" or > > > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > > > mail readers > > > > > > exhibit different behavior, especially when dealing with > > > > > > "multipart" MIME messages (i.e. documents which > > > > have been split > > > > > > up into multiple messages), so check your local > > > > documentation on > > > > > > how to manipulate these messages. > > > > > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant > > mail reader > > > > > > implementation to automatically retrieve the ASCII > > version of the > > > > > > Internet-Draft. > > > > > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "David Allan" Subject: RE: status signalling of MPLS PW state Date: Tue, 17 Jun 2003 12:51:59 -0400 Lines: 112 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C334F0.C4B325FA" Cc: "'Andrew G. Malis'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 21:14:16 2003 Return-path: To: "'Luca Martini'" , David Zelig 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_01C334F0.C4B325FA Content-Type: text/plain; charset="iso-8859-1" I think there is still a few outstanding issues with the current description. 1) Ideally the status TLV should be able to be carried in both the label mapping and notification messages. IMHO there is a lot of reasons for this: - minimal messaging during both initial provisioning (if ducks are aligned right off the bat) and during a graceful restart - minimal state machine changes as we are not reusing label mapping as a notification mechanism for subsequent status changes arising after the initial label mapping. - simpler backwards compatibility (see #2 below) 2) Setting U=0 in status TLV carried in a label mapping message sorts out backwards compatibility support issues relatively quickly. We can provision PWs even if the attachment circuit is down where status TLV is supported. If the far end does not support status TLV, then the label mapping is rejected (net effect being the same as the semantics associated with the use of label withdraw to communicate status, aka as non-supporting far end rejects the mapping, net result is the same as not having offered it). Even if we devise a per-session capability negotiation, I'd presume we'd still want u=0 as a safety mechanism. IMHO per session capability is useful (particularly w.r.t. graceful restart) where we do not want to blow off a lot of time up front negotiating what works on an PW by PW basis. 3) We need to sort out the precedence semantics of the use of group ID along with the status of individual components. Superficially it would appear that any group status change trumps any previously communicated individual statuses (w.r.t. the same class of error). cheers Dave ------_=_NextPart_001_01C334F0.C4B325FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] status signalling of MPLS PW state

I think there is still a few outstanding issues with = the current description.

1) Ideally the status TLV should be able to be = carried in both the label mapping and notification messages. IMHO there = is a lot of reasons for this:

        - minimal = messaging during both initial provisioning (if ducks are aligned right = off the bat) and during a graceful

        restart
        - minimal = state machine changes as we are not reusing label mapping as a = notification mechanism for subsequent status

        changes = arising after the initial label mapping.
        - simpler = backwards compatibility (see #2 below)

2) Setting U=3D0 in status TLV carried in a label = mapping message sorts out backwards compatibility support issues = relatively quickly. We can provision PWs even if the attachment circuit = is down where status TLV is supported. If the far end does not support = status TLV, then the label mapping is rejected (net effect being the = same as the semantics associated with the use of label withdraw to = communicate status, aka as non-supporting far end rejects the mapping, = net result is the same as not having offered it).

Even if we devise a per-session capability = negotiation, I'd presume we'd still want u=3D0 as a safety mechanism. = IMHO per session capability is useful (particularly w.r.t. graceful = restart) where we do not want to blow off a lot of time up front = negotiating what works on an PW by PW basis.

3) We need to sort out the precedence semantics of = the use of group ID along with the status of individual components. = Superficially it would appear that any group status change trumps any = previously communicated individual statuses (w.r.t. the same class of = error).

cheers
Dave


------_=_NextPart_001_01C334F0.C4B325FA-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Andrew G. Malis" Subject: Re: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 13:12:51 -0400 Lines: 125 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Sasha Vainshtein , "Mark Townsley (E-mail)" , pwe3@ietf.org, "Andrew G. Malis (E-mail)" X-From: pwe3-admin@ietf.org Tue Jun 17 21:16:55 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Luca Martini In-Reply-To: <3EEF3C36.4050907@level3.net> X-OriginalArrivalTime: 17 Jun 2003 17:12:56.0642 (UTC) FILETIME=[B21C9220:01C334F3] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca, Actually, there are two reference [8]s in the text. The first one is in the PW type: 0x0008 SONET/SDH Circuit Emulation Service Over MPLS (CEM) [8] Seeing as none of the other PW types have document references, we should remove this one as well. Either that, or add references to all of them. However, Sasha did ask for an explanation, so let's change this to: 0x0008 SONET/SDH Circuit Emulation Service Over MPLS (CEM) [Note 1] At the end of the table, add: Note 1: This PW type is grandfathered for a historical protocol. The recommended standards-track protocol to use is CEP {PW type 0x0010). The second [8] is on the interface parameter ID: 0x04 4 CEP [8] Payload Bytes. A better case can be made for keeping this reference, since the definition of the parameter contents is in the referenced document. This can be renumbered to [2], and the reference is: [2] Malis, A., et al, "SONET/SDH Circuit Emulation over Packet (CEP)", draft-ietf-pwe3-sonet-01.txt, January 2003, work in progress. Cheers, Andy ------- At 6/17/2003 10:05 AM -0600, Luca Martini wrote: >ok, i'll fix the reference. > >Andy can you send me the correct one ? > >Luca > > >Sasha Vainshtein wrote: >>Mark and Luca, >>Can you (or Andy) explain why it is necessary to maintain separate PW >>types for CEP and CEM? >>And, BTW, CEM description includes a reference [8] which is >>simply lacking in the document. If a reference to draft-malis has >>been intended, this draft seem to be expired (no such at the IETF site)... >>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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>Sent: Tuesday, June 17, 2003 1:58 PM >>>Cc: pwe3@ietf.org >>>Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>>This draft is a work item of the Pseudo Wire Emulation Edge to Edge >>>Working Group of the IETF. >>> >>> Title : IANA Allocations for pseudo Wire Edge to >>> Edge Emulation (PWE3) >>> Author(s) : L. Martini, W. Townsley >>> Filename : draft-ietf-pwe3-iana-allocation-01.txt >>> Pages : 5 >>> Date : 2003-6-16 >>> >>>The Control and maintenance protocol for providing various Layer 1 >>>and Layer 2 services over a Packet Switched Network has been >>>described in [2]. This document pre-allocates the fixed Pseudo-wire >>>identifier , and other fixed protocol values that are to be assigned >>>by IANA using the 'IETF Consensus' policy defined in RFC2434 >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc >>>ation-01.txt >>> >>>To remove yourself from the IETF Announcement list, send a message to >>>ietf-announce-request with the word unsubscribe in the body of the message. >>> >>>Internet-Drafts are also available by anonymous FTP. Login with the username >>>"anonymous" and a password of your e-mail address. After logging in, >>>type "cd internet-drafts" and then >>> "get draft-ietf-pwe3-iana-allocation-01.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". >>> >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >>> readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Tue, 17 Jun 2003 13:42:38 -0400 Lines: 722 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C334F7.D834C2EE" Cc: "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 21:17:07 2003 Return-path: To: Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C334F7.D834C2EE Content-Type: text/plain; charset="iso-8859-1" Luca, all, Since we may end up with an extra message anyway for carrying information other than status (for example IP address, QoS, the stuff in Himanshu's draft). If I recall as well, you proposed in one of your previous emails to use a new message (called PW dynamic parameters) for carrying such information. Why not then adopt the following proposal. a) Instead of having a separate message for just status why not define a new message for carrying PW dynamic parameters this can be sent after label mapping (or PW operational). That message carries the: - Status TLV - IP address TLV, - QoS, - etc (these are all optional TLVs with U bit set to 1). b) and use initially within a label mapping the status TLV to convey the initial status to the remote end before traffic is sent. In that case, the new message is not just for status, it is about "things" that the remote end needs to know during the lifetime of the PW and status TLV can be carried in both the PW dynamic parameters and label mapping events. This approach avoids the notify message U bit problems, and is more or less a combination between the two proposals. Comments? Hamid. > > comments in line. > > Luca > > > Hamid Ould-Brahim wrote: > > [Catching up on my emails...] Nice to see we are making > progress on an > > integrated approach. Some comments on the proposal... > > > > > > > > > >The format of the PW Status TLV is: > > > >.DS 0 0 > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |1|0| PW Status (0x0???) | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Status Code | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > .DE > > > Since the U bit in LDP notification message is set to > 1 then the U > > bit in Status TLV MUST be set to 0. In other words an LDP > notify message > > having a U bit set to 1 MUST include the status message. > Maybe this is > > not desirable for all notify messages having U bit set. The problem > > is the notification message includes the PW FEC TLV and that TLV is > > always present (no U bit) in notification message below. In > other words > > there is no point in including the PW FEC in notify message without > > including the status TLV (therefore the status TLV U bit > must be set to > > 0). If we want to keep the Status TLV optional, then we > need to fix PW > > FEC (I don't expect that is acceptable...). More on this > item, see the > > end of this email... > > You have a good point. > I'm checking around to see what the behavior would be. > > I was also thinking that maybe we should not set this U bit at all. > After all this is the standard , and maybe we should just > mention that for > backward compatibility implementations might want to set it. > > > > > > > Where status is a 4 octet bit field: > > > > > > .nf > > > 0x00000000 - Pseudo Wire forwarding ( clear all failures ) > > > 0x00000001 - Pseudo Wire Not Forwarding > > > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault > > > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault > > > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault > > > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault > > > .En > > > Since these are codepoints in Hex the above should > be rewritten > > to: 0x0000 - Pseudo Wire forwarding ( clear all failures ) > > 0x0001 - Pseudo Wire Not Forwarding > > 0x0002 - Local Customer-facing PW ( ingress ) Receive Fault > > 0x0004 - Local Customer-facing PW ( egress ) Transmit Fault > > 0x0008 - Local PSN-facing PW ( ingress ) Receive Fault > > 0x0010 - Local PSN-facing PW ( egress ) Transmit Fault > > > > > >The above status codes can be logically combined to indicate > > > more then a > > > >single failure at once. Each fault can be cleared by sending > > > an appropriate > > > >status message with the respective bit cleared. The presence > > > of the lowest > > > >bit (PW Not Forwarding) acts only as a generic failure > > > indication when there > > > >is a link-down event for which none of the other bits > apply. > > The status should always be combined when multiple > errors happen in > > an incremental way. For example at a given time a PE sends local > > Customer-facing ingress fault and later on the transmit > fails, the > > sender PE should then update the previous status sent > and not sent a > > separate status with only the latter problem reported. > This is to > > avoid that a new status for another problem clears the > problem for > > the previous status. Same thing when new problems happen > and other > > problems are cleared. The receiving PE should screen > *ALL* the status > > bits (for updating the status of already reported > problems), except > > for 0x001. It is important to note that when this > codepoint is sent > > the receiving PE should *ignore* all the other bit (and > not treat > > them as clear). Since this is bitfield style approach, > depending > > what new status will be added, it may happen that not all > > combinations are meaningful. I am not as well clear > on 0x001/not > > forwarding status. 0x0002 and 0x0010 means the PE not > forwarding as > > well. Reading from the above, 0x001 is only applicable > to these two > > codepoints (it is really a summary of these two > codepoints). If we > > want it to be a summary of all the codepoints then we > should call it > > something like "Down/Disabled/General problem". > > yes , this is the intended behavior , but I see that it needs > more explanation. > > > > > > > > > >The Status TLV is transported to the remote PW peer via the > > > LDP notification > > > >message. The format of the Notification Message is: > > > > > > > >.DS 0 0 > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >|1| Notification (0x0001) | Message Length > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >| Message ID > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >| PW FEC TLV > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >| PW Status TLV > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >.DE > > > > The LDP spec says that when U bit is set to 1 in the LDP > > notification message: "U bit > > Should be 0 when the Status TLV is sent in a > Notification message. > > Should be 1 when the Status TLV is sent in some other > message." In > > the PW status case, the normal notification for basic LDP > is not carried > > in some other message (still carried within the LDP notification > > message). I assume this needs clarification with MPLS WG > such that LDP > > implementations that have U bit set will not interpret that > status will > > be received in some other messages (maybe this is not an issue, a > > clarification/checking is always good in case of ambiguity...). > > Now if a PE doesn't understand status TLV and that PE receives a > > notification message with U bit set and PW FEC& status > included, should > > that PE ignores the LDP notification? Note that I expect basic LDP > > implementation to understand notify message but they may > not understand > > the status TLV. In that case, the status TLV and PW FEC > must always be > > present together, if a status TLV is ignored then PW FEC is as well > > ignored. This area needs clarification. > > so the PW FEC is here to identify to which PW this status > message applies. > Yes, if the message is ignored because it is not understood , > then status > signaling will not work. This might be ok in some deployments. > > > > >The PW FEC TLV SHOULD not include the interface parameters > > > as they are > > > >ignored in the context of this message. When a PE's > > > CE-facing interface > > > >encounters an error, use of the new message allows the PE to > > > send a single > > > >Status message, using a PW FEC TLV with only the group ID > > > set, to denote > > > >this change in status for all affected PW connections. > > > > As I indicated in my previous emails, this solution > works only > > with PWid FEC not with generalized ID FEC (at least for the > Group ID). I > > suggest we have either: a) status TLV/Notify specified > for both PW > > FECs, or b) a different one for Generalized ID FEC... In > either case, > > the text should clarify this... Note that for l2vpn, only > VPLS service > > (vkompella proposal) is using the PWid FEC, the other > proposals will not > > take advantage of this change (until this proposal works with > > generalized ID FEC)... Hamid. > > > > > > I see. Yes , this needs fixing. It was my intention to make > it apply to both. > > > > > > > > > > Luca > > ------_=_NextPart_001_01C334F7.D834C2EE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] status signalling of MPLS PW state

Luca, all,

Since we may end up with an extra message anyway = for
carrying information other than status (for = example
IP address, QoS, the stuff in Himanshu's = draft).
If I recall as well, you proposed in one of your = previous emails
to use a new message (called PW dynamic parameters) = for carrying
such information. Why not then adopt the following = proposal.

a) Instead of having a separate message
   for just status why not define a new = message for carrying PW
   dynamic parameters this can be sent = after label mapping
   (or PW operational).

   That message carries the:

   - Status TLV
   - IP address TLV,
   - QoS,
   - etc

(these are all optional TLVs with U bit set to = 1).

b) and use initially within a label mapping the = status TLV to
   convey the initial status to the remote = end
   before traffic is sent.

In that case, the new message is not just for status, = it is
about "things" that the remote end needs = to know during the
lifetime of the PW and status TLV can be carried in = both
the PW dynamic parameters and label mapping = events.

This approach avoids the notify message U bit = problems, and is
more or less a combination between the two = proposals.

Comments?

Hamid.

>
> comments in line.
>
> Luca
>
>
> Hamid Ould-Brahim wrote:
> > [Catching up on my emails...]   = Nice to see we are making
> progress on an
> > integrated approach. Some comments on the = proposal...
> >
> >  > >
> >  > >The format of the PW Status = TLV is:
> >  > >.DS 0 0
> >  >   = 0            = ;       = 1            = ;       = 2            = ;       3
> >  >   0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >  > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >  > |1|0|     = PW Status (0x0???)    = |            = Length           =   |
> >  > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >  > = |            = ;            = ; Status = Code           &n= bsp;           &n= bsp;   |
> >  > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >  > .DE
> >  >   Since the U bit in = LDP notification message is set to
> 1 then the U
> > bit in Status TLV MUST be set to 0. In = other words an LDP
> notify message
> > having a U bit set to 1 MUST include the = status message.
> Maybe this is
> > not desirable for all notify messages = having U bit set. The problem
> > is the notification message includes the = PW FEC TLV and that TLV is
> > always present (no U bit) in notification = message below. In
> other words
> > there is no point in including the PW FEC = in notify message without
> > including the status TLV (therefore the = status TLV U bit
> must be set to
> > 0). If we want to keep the Status TLV = optional, then we
> need to fix PW
> > FEC (I don't expect that is = acceptable...). More on this
> item,  see the
> > end of this email...
>
> You have a good point.
> I'm checking around to see what the behavior = would be.
>
> I was also thinking that maybe we should not = set this U bit at all.
> After all this is the standard , and maybe we = should just
> mention that for
> backward compatibility implementations might = want to set it.
>
>
>
>
> >  > Where status is a 4 octet bit = field:
> >  >
> >  > .nf
> >  > 0x00000000 - Pseudo Wire = forwarding ( clear all failures )
> >  > 0x00000001 - Pseudo Wire Not = Forwarding
> >  > 0x00000002 - Local = Customer-facing PW ( ingress ) Receive Fault
> >  > 0x00000004 - Local = Customer-facing PW ( egress ) Transmit Fault
> >  > 0x00000008 - Local PSN-facing = PW ( ingress ) Receive Fault
> >  > 0x00000010 - Local PSN-facing = PW ( egress ) Transmit Fault
> >  > .En
> >  >     Since = these are codepoints in Hex the above should
> be   rewritten
> > to:     0x0000 - = Pseudo Wire forwarding ( clear all failures )
> >   0x0001 - Pseudo Wire Not = Forwarding
> >   0x0002 - Local Customer-facing = PW ( ingress ) Receive Fault
> >   0x0004 - Local Customer-facing = PW ( egress ) Transmit Fault
> >   0x0008 - Local PSN-facing PW ( = ingress ) Receive Fault
> >   0x0010 - Local PSN-facing PW ( = egress ) Transmit Fault
> >  
> >  > >The above status codes can = be logically combined to indicate
> >  > more then a
> >  > >single failure at once. = Each fault can be cleared by sending
> >  > an appropriate
> >  > >status message with the = respective bit cleared. The presence
> >  > of the lowest
> >  > >bit (PW Not Forwarding) = acts only as a generic failure
> >  > indication when there
> >  > >is a link-down event for = which none of the other bits
> apply.     
> > The status should always be combined when = multiple   
> errors happen in
> > an incremental way. For example at a = given    time a PE sends local
> > Customer-facing ingress fault and later = on    the transmit
> fails, the
> > sender PE should then update the = previous    status sent
> and not sent a
> > separate status with only the = latter    problem reported.  
>  This is to
> > avoid that a new status for another = problem    clears the
> problem for
> > the previous status. Same thing = when    new problems happen
> and other
> > problems are cleared. The = receiving    PE should screen
> *ALL* the status
> > bits (for updating the    = status of already reported
> problems), except
> > for 0x001.    It is = important to note that when this
> codepoint is sent
> >    the receiving PE should = *ignore* all the other bit (and
> not    treat
> > them as = clear).      Since this is bitfield style = approach,
> depending
> > what new status    will be = added, it may happen that not all
> > combinations    are = meaningful.      I am not as well clear =
> on 0x001/not
> > forwarding status.    = 0x0002 and 0x0010 means the PE not
> forwarding as
> > well. Reading    from the = above, 0x001 is only applicable
> to these two
> >    codepoints (it is really = a summary of these two
> codepoints).    If we
> > want it to be a summary of all the = codepoints    then we
> should call it
> > something like "Down/Disabled/General&= nbsp;   problem". 
>
> yes , this is the intended behavior , but I see = that it needs
> more explanation.
>
>
> >  > >
> >  > >The Status TLV is = transported to the remote PW peer via the
> >  > LDP notification
> >  > >message. The format of the = Notification Message is:
> >  > >
> >  > >.DS 0 0
> >  > >  = 0            = ;       = 1            = ;       = 2            = ;       3
> >  > >  0 1 2 3 4 5 6 7 8 9 = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> 7 8 9 0 1
> >  >
> = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > >|1|   = Notification   (0x0001)   = |      Message Length  
>         = |
> >  >
> = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > = >|           &= nbsp;           &= nbsp;   Message = ID           &nbs= p;     
>         = |
> >  >
> = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > = >|           &= nbsp;           &= nbsp;   PW FEC = TLV           &nb= sp;     
>         = |
> >  >
> = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > = >|           &= nbsp;           &= nbsp; PW Status = TLV           &nb= sp;    
>         = |
> >  >
> = >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > >.DE
> >  > >   The LDP spec = says that when U bit is set to 1 in the LDP
> > notification message:   "U = bit
> >    Should be 0 when the = Status TLV is sent in a
> Notification message.
> >    Should be 1 when the = Status TLV is sent in some other
> message."   In
> > the PW status case, the normal = notification for basic LDP
> is not carried
> > in some other message (still carried = within the LDP notification
> > message). I assume this needs = clarification with MPLS WG
> such that LDP
> > implementations that have U bit set will = not interpret that
> status will
> > be received in some other messages (maybe = this is not an issue, a
> > clarification/checking is always good in = case of ambiguity...).
> > Now if a PE doesn't understand status TLV = and that PE receives a
> > notification message with U bit set and PW = FEC& status
> included, should
> > that PE ignores the LDP notification? Note = that I expect basic LDP
> > implementation to understand notify = message but they may
> not understand
> > the status TLV. In that case, the status = TLV and PW FEC
> must always be
> > present together, if a status TLV is = ignored then PW FEC is as well
> > ignored. This area needs = clarification.
>
> so the PW FEC is here to identify to which PW = this status
> message applies.
> Yes, if the message is ignored because it is = not understood ,
> then status
> signaling will not work. This might be ok in = some deployments.
>
> >  > >The PW FEC TLV SHOULD not = include the interface parameters
> >  > as they are
> >  > >ignored in the context of = this message. When a PE's
> >  > CE-facing interface
> >  > >encounters an error, use of = the new message allows the PE to
> >  > send a single
> >  > >Status message, using a PW = FEC TLV with only the group ID
> >  > set, to denote
> >  > >this change in status for = all affected PW connections.
> >  > >   As I indicated = in my previous emails, this solution
> works only
> > with PWid FEC not with generalized ID FEC = (at least for the
> Group ID). I
> > suggest we have either:   a) = status TLV/Notify specified
> for both PW
> > FECs, or b) a different one for = Generalized ID FEC...   In
> either case,
> > the text should clarify this... Note that = for l2vpn, only
> VPLS service
> > (vkompella proposal) is using the PWid = FEC, the other
> proposals will not
> > take advantage of this change (until this = proposal works with
> > generalized ID FEC)...   = Hamid.
> >  > >
>
> I see. Yes , this needs fixing. It was my = intention to make
> it apply to both.
>
>
> >  >
> >  >
>
> Luca
>
>

------_=_NextPart_001_01C334F7.D834C2EE-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt Date: Tue, 17 Jun 2003 21:03:17 +0200 Lines: 175 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "Mark Townsley (E-mail)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 21:21:56 2003 Return-path: To: "'Andrew G. Malis'" , Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Andy and Luca, 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: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com] > Sent: Tuesday, June 17, 2003 7:13 PM > To: Luca Martini > Cc: Sasha Vainshtein; Mark Townsley (E-mail); pwe3@ietf.org; > Andrew G. Malis (E-mail) > Subject: Re: CEM vs CEP in draft-ietf-pwe3-iana-allocation-01.txt > > > Luca, > > Actually, there are two reference [8]s in the text. The > first one is in > the PW type: > > 0x0008 SONET/SDH Circuit Emulation Service Over > MPLS (CEM) [8] > > Seeing as none of the other PW types have document > references, we should > remove this one as well. Either that, or add references to > all of them. > I would definitely prefer that (wherever possible) to avoid any ambiguities. I understand the limitations you have to work under. > > However, Sasha did ask for an explanation, so let's change this to: > > 0x0008 SONET/SDH Circuit Emulation Service Over > MPLS (CEM) > [Note 1] > > At the end of the table, add: > > Note 1: This PW type is grandfathered for a historical protocol. The > recommended standards-track protocol to use is CEP {PW type 0x0010). > This is OK with me. > > The second [8] is on the interface parameter ID: > > 0x04 4 CEP [8] Payload Bytes. > > A better case can be made for keeping this reference, since > the definition > of the parameter contents is in the referenced document. This can be > renumbered to [2], and the reference is: > > [2] Malis, A., et al, "SONET/SDH Circuit Emulation over > Packet (CEP)", > draft-ietf-pwe3-sonet-01.txt, January 2003, work in progress. > > Cheers, > Andy > > ------- > > At 6/17/2003 10:05 AM -0600, Luca Martini wrote: > >ok, i'll fix the reference. > > > >Andy can you send me the correct one ? > > > >Luca > > > > > >Sasha Vainshtein wrote: > >>Mark and Luca, > >>Can you (or Andy) explain why it is necessary to maintain > separate PW > >>types for CEP and CEM? > >>And, BTW, CEM description includes a reference [8] which is > >>simply lacking in the document. If a reference to draft-malis has > >>been intended, this draft seem to be expired (no such at > the IETF site)... > >>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: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >>>Sent: Tuesday, June 17, 2003 1:58 PM > >>>Cc: pwe3@ietf.org > >>>Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-01.txt > >>> > >>> > >>>A New Internet-Draft is available from the on-line Internet-Drafts > >>>directories. > >>>This draft is a work item of the Pseudo Wire Emulation > Edge to Edge > >>>Working Group of the IETF. > >>> > >>> Title : IANA Allocations for pseudo > Wire Edge to > >>> Edge Emulation (PWE3) > >>> Author(s) : L. Martini, W. Townsley > >>> Filename : draft-ietf-pwe3-iana-allocation-01.txt > >>> Pages : 5 > >>> Date : 2003-6-16 > >>> > >>>The Control and maintenance protocol for providing various Layer 1 > >>>and Layer 2 services over a Packet Switched Network has been > >>>described in [2]. This document pre-allocates the fixed Pseudo-wire > >>>identifier , and other fixed protocol values that are to > be assigned > >>>by IANA using the 'IETF Consensus' policy defined in RFC2434 > >>> > >>>A URL for this Internet-Draft is: > >>>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-alloc > >>>ation-01.txt > >>> > >>>To remove yourself from the IETF Announcement list, send a > message to > >>>ietf-announce-request with the word unsubscribe in the > body of the message. > >>> > >>>Internet-Drafts are also available by anonymous FTP. Login > with the username > >>>"anonymous" and a password of your e-mail address. After > logging in, > >>>type "cd internet-drafts" and then > >>> "get draft-ietf-pwe3-iana-allocation-01.txt". > >>> > >>>A list of Internet-Drafts directories can be found in > >>>http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >>> > >>>Internet-Drafts can also be obtained by e-mail. > >>> > >>>Send a message to: > >>> mailserv@ietf.org. > >>>In the body type: > >>> "FILE > /internet-drafts/draft-ietf-pwe3-iana-allocation-01.txt". > >>> > >>>NOTE: The mail server at ietf.org can return the document in > >>> MIME-encoded form by using the "mpack" utility. > To use this > >>> feature, insert the command "ENCODING mime" > before the "FILE" > >>> command. To decode the response(s), you will > need "munpack" or > >>> a MIME-compliant mail reader. Different > MIME-compliant mail > >>> readers > >>> exhibit different behavior, especially when dealing with > >>> "multipart" MIME messages (i.e. documents which > have been split > >>> up into multiple messages), so check your local > documentation on > >>> how to manipulate these messages. > >>> > >>> > >>>Below is the data which will enable a MIME compliant mail reader > >>>implementation to automatically retrieve the ASCII version of the > >>>Internet-Draft. > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 17 Jun 2003 21:33:07 +0300 Lines: 65 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Tue Jun 17 21:41:25 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcM05Xr5fcDmSfcITRWuWdKuPVAXGgAFi8Yg To: "Danny McPherson" , "Romascanu, Dan (Dan)" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Really? Can you elaborate on this (i.e., how many other=20 > folks have/are implementing this)? Sasha quotes 4 interoperable implementations, RAD, Redux, Ericsson, and Engage. As I have said in previous emails RAD does NOT support CESoPSN in our standard product line. This "interop" was a one-time effort to supply small remote boxes to interoperate with CESoPSN central site for a given sales opportunity. >From their latest spec sheets, Redux only supports unframed raw bit transport, and thus could only possibly support draft-vainshtein in unstructured E1 mode. Unless they have something new and unpublished, they can't possibly support draft-vainshtein for T1 or in structured modes. I don't know what modes Engage and Ericsson support, but it would be interesting to hear. I am guessing that the Engage implementation (being software on a small processor) is also unstructured, but perhaps Sasha could enlighten us. Incidentally, draft-anavi presently has several interoperable implementations that support unstructured and structured modes, and at least two commercial chip-sets are coming out in the near future. = Perhaps Dan is refering to verbal support, rather than actual implementations. So far I see 6:5 in favor of CESoPSN: FOR CESoPSN: 1. Sasha - Axerra 2. Ron Cohen - Lycium 3. Michel Khouderchah - Cisco 4. Uri Rotshtein - Redux 5. Max Riegel - Siemens 6. Dan Romascanu - Avaya AGAINST (i.e. for TDMoIP) 1. Yaakov - RAD 2. Shahram - PMC 3. Alex Conta - TranSwitch 4. Amnon Ilan - Nbase 5. Neil Harrison - BT which is pretty close to 50-50. Since I am going to be issuing an update of draft-anavi, we can go through this again and see what support draft-anavi has -=20 the answer will probably be about the same. Finally, perhaps Dan is refering to deployments. draft-anavi has well over 10,000 deployed ports, many of which have been functioning for several years already. Can we get some figures on active deployments (not betas) from the CESoPSN implementations ? =20 I know that this sounds terribly crass,=20 but don't we deserve to hear if this stuff=20 has really been tested in the field?=20 Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: xiaozhen.zhong@mindspeed.com Subject: draft-ietf-pwe3-atm-encap-01.txt Date: Tue, 17 Jun 2003 14:28:10 -0400 Lines: 245 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0065635E85256D48_=" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 21:43:20 2003 Return-path: To: luca@level3.net X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 X-MIMETrack: Serialize by Router on MALNMAIL2/Server/Conexant(Release 5.0.12 |February 13, 2003) at 06/17/2003 02:28:33 PM, Serialize complete at 06/17/2003 02:28:33 PM, Itemize by SMTP Server on NPBLNH1/Server/Conexant(Release 5.0.12 |February 13, 2003) at 06/17/2003 11:28:33 AM, Serialize by Router on NPBLNH1/Server/Conexant(Release 5.0.12 |February 13, 2003) at 06/17/2003 11:28:35 AM, Serialize complete at 06/17/2003 11:28:35 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 This is a multipart message in MIME format. --=_alternative 0065635E85256D48_= Content-Type: text/plain; charset="us-ascii" Hi, Luca, This is Joey Zhong from Mindspeed System Inc (My site was known as Maker systems before it's aquired by Mindspeed). We are implementing draft-ietf-pwe3-atm-encap-01.txt on our OC-48 network processor. The engineering group here found couple of potential enhancement for the draft during implementation. Please see following proposal for the details. We've been reviewing draft-ietf-pwe3-atm-encap-01.txt. As it seems this document is settling down for overall functionality, it might be time to look at advantages of different codings and positions of fields in the frames. The draft shows several different positions and orders of the Length, Sequence Number, and Flags fields partially copied herein: in section 4.1 (general): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | Flags |Res| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in section 6.6 (VCC service): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN Transport Header (As Required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pseudo Wire Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Length and Sequence Number |M|V|Res| PTI |C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in section 6.7.1 (VPC service): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN Transport Header (As Required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pseudo Wire Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Length and Sequence Number |M|V|Res| PTI |C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in section 7.1 (N-to-1 service): implied usage of the section 4.1 control word. in section 8.2 (SDU service): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res |T|E|C|U|Res| Length | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in section 9.2 (PDU service): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Length and Sequence Number |M|V| Res |U|E|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Looking at them all together, you can see there are several locations for the length, sequence, and flags fields. It would make more sense to have these fields have a normal position or at least relative ordering across all of the service modes while some fields would vary. Notice in the "Optional Length and Sequence Number" field (assuming this states order of the two), the Sequence number is not on a half word boundary. Notice the major differences for the SDU and PDU mode which are otherwise very similar by function. As we consider moving the fields and bits around, we should do so in a way that simplifies the bit and byte banging needed by both hardware and software solutions. I would recommend something like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This construct has the 16 bit sequence number aligned on a half word, the length aligned on a byte boundary, and has the flags in the least significant byte to allow the best availability of bit manipulation instructions. Not also that in the VPC and VCC modes, the flag field of the first cell in the packet has to follow the Sequence and Length fields allowing the offered ordering to be similar throughout the PWE3 ATM modes. I understand that this doesn't take into account the possibility of cramming a PID into the control word. Then looking at the flags, it make little sense to have a different ordering of the E, C, and U bits in each encoding and there is an ideal order. I would recommend: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Length |M|V|Res|O|E|U|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I've swapped the E and U bits from the PDU service mode as the E, U, C ordering aligns with the corresponding meaning from the ATM cell header. Even though work needs to be done across many cells to determine the ATM control word setting of E and C, the alignment will help with calculations. Other possibilities shown in the encoding is to have a bit 'O' to indicate OAM cells. For the 'T' bit meaning in the SDU service mode, the 'O' bit could be used for that meaning. Note the alignment with the ATM cell header and now a perfect match between the VCC/VPC service flags (PTI/C) and the O, E, U, and C ordering. The M and V bits are not required in all modes as presently defined, but their meaning could be carried throughout. Interesting that the SDU mode currently defined doesn't indicate "packet" or "cell". This is one service where carrying the meaning through would help. The U bit has different meanings that are non-overlapping. In the SDU mode, U is the CPCS-UU bit while in PDU mode it is the ATM user-to-user bit. One limitation is that the SDU mode cannot indicate a continuation or end of a fragmented SDU. This wasn't presently specified anyway. comments? Joey Zhong ------------------------------------------------ Joey Zhong Firmware Engineer Mindspeed Technologies (TM), a Conexant business 8 Technology Drive 508-621-0794 desk Westborough, MA 01581-1756 508-621-0605 fax ------------------------------------------------ --=_alternative 0065635E85256D48_= Content-Type: text/html; charset="us-ascii"
Hi, Luca,

This is Joey Zhong from Mindspeed System Inc (My site was known as Maker systems before it's aquired by Mindspeed). We are implementing draft-ietf-pwe3-atm-encap-01.txt on our OC-48 network processor. The engineering group here found couple of potential enhancement for the draft during implementation. Please see following proposal for the details.

We've been reviewing draft-ietf-pwe3-atm-encap-01.txt. As it seems this document is settling down for overall functionality, it might be time to look at advantages of different codings and positions of fields in the frames.

The draft shows several different positions and orders of the Length, Sequence Number, and Flags fields partially copied herein:

in section 4.1 (general):
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsvd  | Flags |Res|   Length  |     Sequence Number           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in section 6.6 (VCC service):
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pseudo Wire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Optional Length and Sequence Number        |M|V|Res| PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in section 6.7.1 (VPC service):
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pseudo Wire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Optional Length and Sequence Number        |M|V|Res| PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in section 7.1 (N-to-1 service):
   implied usage of the section 4.1 control word.

in section 8.2 (SDU service):

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |T|E|C|U|Res|  Length   |   Sequence Number (Optional)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

in section 9.2 (PDU service):
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Optional Length and Sequence Number        |M|V| Res |U|E|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Looking at them all together, you can see there are several locations for the length, sequence, and flags fields. It would make more sense to have these fields have a normal position or at least relative ordering across all of the service modes while some fields would vary. Notice in the "Optional Length and Sequence Number" field (assuming this states order of the two), the Sequence number is not on a half word boundary. Notice the major differences for the SDU and PDU mode which are otherwise very similar by function. As we consider moving the fields and bits around, we should do so in a way that simplifies the bit and byte banging needed by both hardware and software solutions.

I would recommend something like:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Sequence Number         |    Length     |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This construct has the 16 bit sequence number aligned on a half word, the length aligned on a byte boundary, and has the flags in the least significant byte to allow the best availability of bit manipulation instructions. Not also that in the VPC and VCC modes, the flag field of the first cell in the packet has to follow the Sequence and Length fields allowing the offered ordering to be similar throughout the PWE3 ATM modes. I understand that this doesn't take into account the possibility of cramming a PID into the control word.

Then looking at the flags, it make little sense to have a different ordering of the E, C, and U bits in each encoding and there is an ideal order.

I would recommend:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Sequence Number         |    Length     |M|V|Res|O|E|U|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I've swapped the E and U bits from the PDU service mode as the E, U, C ordering aligns with the corresponding meaning from the ATM cell header. Even though work needs to be done across many cells to determine the ATM control word setting of E and C, the alignment will help with calculations.

Other possibilities shown in the encoding is to have a bit 'O' to indicate OAM cells. For the 'T' bit meaning in the SDU service mode, the 'O' bit could be used for that meaning. Note the alignment with the ATM cell header and now a perfect match between the VCC/VPC service flags (PTI/C) and the O, E, U, and C ordering.

The M and V bits are not required in all modes as presently defined, but their meaning could be carried throughout. Interesting that the SDU mode currently defined doesn't indicate "packet" or "cell". This is one service where carrying the meaning through would help.

The U bit has different meanings that are non-overlapping. In the SDU mode, U is the CPCS-UU bit while in PDU mode it is the ATM user-to-user bit. One limitation is that the SDU mode cannot indicate a continuation or end of a fragmented SDU. This wasn't presently specified anyway.

comments?


Joey Zhong

------------------------------------------------
Joey Zhong
Firmware Engineer
Mindspeed Technologies (TM), a Conexant business
8 Technology Drive             508-621-0794 desk
Westborough, MA  01581-1756    508-621-0605 fax
------------------------------------------------ --=_alternative 0065635E85256D48_=-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Tue, 17 Jun 2003 16:09:18 -0400 Lines: 685 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3350C.55A259EE" Cc: "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 17 23:01:25 2003 Return-path: To: "Hamid Ould-Brahim" , Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C3350C.55A259EE Content-Type: text/plain; charset="iso-8859-1" Adding further clarifications to this proposal. The TLV status is exactly what is in Luca's final proposal. The behavior would be a) The initial label mapping exchange includes the Status TLV (U bit set to 1). If the receiving PE doesn't understand the status TLV it will just ignore this TLV and will follow normal procedures. The sender PE when receiving the reverse label mapping checks if status TLV is included. If it is included it concludes that the remote PE understands the Pseudo-wire Dynamic Parameter message (let's just call it the PDP message). From there, when problems happen, the PDP message is sent. If the label mapping doesn't contain status TLV, the sender PE concludes that the remote PE doesn't understand status TLV. In that case normal behavior should be followed (this is the backward compatibility rule, PEs that do not understand PDP message will not receive it). b) The status TLV will then be conveyed within the PDP message. The PDP message as indicated before may convey other TLVs (IP address, etc). c) An initial indication of "PW not forwarding/down, etc" in the label mapping indicates to the remote end not to send traffic until the PDP message is sent with a clear code point. It will be advisable to have per session cap negotiation however the above works without it with the understanding that it works per PW. Hamid. -----Original Message----- From: Ould-Brahim, Hamid [CAR:1A00:EXCH] Sent: Tuesday, June 17, 2003 1:43 PM To: Luca Martini Cc: Andrew G. Malis; pwe3@ietf.org Subject: RE: [PWE3] status signalling of MPLS PW state Luca, all, Since we may end up with an extra message anyway for carrying information other than status (for example IP address, QoS, the stuff in Himanshu's draft). If I recall as well, you proposed in one of your previous emails to use a new message (called PW dynamic parameters) for carrying such information. Why not then adopt the following proposal. a) Instead of having a separate message for just status why not define a new message for carrying PW dynamic parameters this can be sent after label mapping (or PW operational). That message carries the: - Status TLV - IP address TLV, - QoS, - etc (these are all optional TLVs with U bit set to 1). b) and use initially within a label mapping the status TLV to convey the initial status to the remote end before traffic is sent. In that case, the new message is not just for status, it is about "things" that the remote end needs to know during the lifetime of the PW and status TLV can be carried in both the PW dynamic parameters and label mapping events. This approach avoids the notify message U bit problems, and is more or less a combination between the two proposals. Comments? Hamid. > > comments in line. > > Luca > > > Hamid Ould-Brahim wrote: > > [Catching up on my emails...] Nice to see we are making > progress on an > > integrated approach. Some comments on the proposal... > > > > > > > > > >The format of the PW Status TLV is: > > > >.DS 0 0 > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |1|0| PW Status (0x0???) | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Status Code | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > .DE > > > Since the U bit in LDP notification message is set to > 1 then the U > > bit in Status TLV MUST be set to 0. In other words an LDP > notify message > > having a U bit set to 1 MUST include the status message. > Maybe this is > > not desirable for all notify messages having U bit set. The problem > > is the notification message includes the PW FEC TLV and that TLV is > > always present (no U bit) in notification message below. In > other words > > there is no point in including the PW FEC in notify message without > > including the status TLV (therefore the status TLV U bit > must be set to > > 0). If we want to keep the Status TLV optional, then we > need to fix PW > > FEC (I don't expect that is acceptable...). More on this > item, see the > > end of this email... > > You have a good point. > I'm checking around to see what the behavior would be. > > I was also thinking that maybe we should not set this U bit at all. > After all this is the standard , and maybe we should just > mention that for > backward compatibility implementations might want to set it. > > > > > > > Where status is a 4 octet bit field: > > > > > > .nf > > > 0x00000000 - Pseudo Wire forwarding ( clear all failures ) > > > 0x00000001 - Pseudo Wire Not Forwarding > > > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault > > > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault > > > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault > > > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault > > > .En > > > Since these are codepoints in Hex the above should > be rewritten > > to: 0x0000 - Pseudo Wire forwarding ( clear all failures ) > > 0x0001 - Pseudo Wire Not Forwarding > > 0x0002 - Local Customer-facing PW ( ingress ) Receive Fault > > 0x0004 - Local Customer-facing PW ( egress ) Transmit Fault > > 0x0008 - Local PSN-facing PW ( ingress ) Receive Fault > > 0x0010 - Local PSN-facing PW ( egress ) Transmit Fault > > > > > >The above status codes can be logically combined to indicate > > > more then a > > > >single failure at once. Each fault can be cleared by sending > > > an appropriate > > > >status message with the respective bit cleared. The presence > > > of the lowest > > > >bit (PW Not Forwarding) acts only as a generic failure > > > indication when there > > > >is a link-down event for which none of the other bits > apply. > > The status should always be combined when multiple > errors happen in > > an incremental way. For example at a given time a PE sends local > > Customer-facing ingress fault and later on the transmit > fails, the > > sender PE should then update the previous status sent > and not sent a > > separate status with only the latter problem reported. > This is to > > avoid that a new status for another problem clears the > problem for > > the previous status. Same thing when new problems happen > and other > > problems are cleared. The receiving PE should screen > *ALL* the status > > bits (for updating the status of already reported > problems), except > > for 0x001. It is important to note that when this > codepoint is sent > > the receiving PE should *ignore* all the other bit (and > not treat > > them as clear). Since this is bitfield style approach, > depending > > what new status will be added, it may happen that not all > > combinations are meaningful. I am not as well clear > on 0x001/not > > forwarding status. 0x0002 and 0x0010 means the PE not > forwarding as > > well. Reading from the above, 0x001 is only applicable > to these two > > codepoints (it is really a summary of these two > codepoints). If we > > want it to be a summary of all the codepoints then we > should call it > > something like "Down/Disabled/General problem". > > yes , this is the intended behavior , but I see that it needs > more explanation. > > > > > > > > > >The Status TLV is transported to the remote PW peer via the > > > LDP notification > > > >message. The format of the Notification Message is: > > > > > > > >.DS 0 0 > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >|1| Notification (0x0001) | Message Length > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >| Message ID > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >| PW FEC TLV > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >| PW Status TLV > | > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >.DE > > > > The LDP spec says that when U bit is set to 1 in the LDP > > notification message: "U bit > > Should be 0 when the Status TLV is sent in a > Notification message. > > Should be 1 when the Status TLV is sent in some other > message." In > > the PW status case, the normal notification for basic LDP > is not carried > > in some other message (still carried within the LDP notification > > message). I assume this needs clarification with MPLS WG > such that LDP > > implementations that have U bit set will not interpret that > status will > > be received in some other messages (maybe this is not an issue, a > > clarification/checking is always good in case of ambiguity...). > > Now if a PE doesn't understand status TLV and that PE receives a > > notification message with U bit set and PW FEC& status > included, should > > that PE ignores the LDP notification? Note that I expect basic LDP > > implementation to understand notify message but they may > not understand > > the status TLV. In that case, the status TLV and PW FEC > must always be > > present together, if a status TLV is ignored then PW FEC is as well > > ignored. This area needs clarification. > > so the PW FEC is here to identify to which PW this status > message applies. > Yes, if the message is ignored because it is not understood , > then status > signaling will not work. This might be ok in some deployments. > > > > >The PW FEC TLV SHOULD not include the interface parameters > > > as they are > > > >ignored in the context of this message. When a PE's > > > CE-facing interface > > > >encounters an error, use of the new message allows the PE to > > > send a single > > > >Status message, using a PW FEC TLV with only the group ID > > > set, to denote > > > >this change in status for all affected PW connections. > > > > As I indicated in my previous emails, this solution > works only > > with PWid FEC not with generalized ID FEC (at least for the > Group ID). I > > suggest we have either: a) status TLV/Notify specified > for both PW > > FECs, or b) a different one for Generalized ID FEC... In > either case, > > the text should clarify this... Note that for l2vpn, only > VPLS service > > (vkompella proposal) is using the PWid FEC, the other > proposals will not > > take advantage of this change (until this proposal works with > > generalized ID FEC)... Hamid. > > > > > > I see. Yes , this needs fixing. It was my intention to make > it apply to both. > > > > > > > > > > Luca > > ------_=_NextPart_001_01C3350C.55A259EE Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] status signalling of MPLS PW state
Adding further clarifications to this proposal. The TLV status is
exactly what is in Luca's final proposal. The behavior would be
 
a) The initial label mapping exchange includes the
   Status TLV (U bit set to 1).
 
   If the receiving PE doesn't understand the status TLV
   it will just ignore this TLV and will follow normal
   procedures.
 
   The sender PE when receiving the reverse label mapping
   checks if status TLV is included. If it is included it concludes
   that the remote PE understands the Pseudo-wire Dynamic
   Parameter message (let's just call it the PDP message).
 
   From there, when problems happen, the PDP message is sent.
   If the label mapping doesn't contain status TLV, the
   sender PE concludes that the remote PE doesn't understand
   status TLV. In that case normal behavior should
   be followed (this is the backward compatibility rule,
   PEs that do not understand PDP message will not receive it).
 
b) The status TLV will then be conveyed within the PDP
   message. The PDP message as indicated before may convey
   other TLVs (IP address, etc).
 
c) An initial indication of "PW not forwarding/down, etc" in the
   label mapping indicates to the remote end not to send
   traffic until the PDP message is sent with a clear code point.
 
It will be advisable to have per session cap negotiation however
the above works without it with the understanding that it works
per PW.
 
Hamid.
 
 
 -----Original Message-----
From: Ould-Brahim, Hamid [CAR:1A00:EXCH]
Sent: Tuesday, June 17, 2003 1:43 PM
To: Luca Martini
Cc: Andrew G. Malis; pwe3@ietf.org
Subject: RE: [PWE3] status signalling of MPLS PW state

Luca, all,

Since we may end up with an extra message anyway for
carrying information other than status (for example
IP address, QoS, the stuff in Himanshu's draft).
If I recall as well, you proposed in one of your previous emails
to use a new message (called PW dynamic parameters) for carrying
such information. Why not then adopt the following proposal.

a) Instead of having a separate message
   for just status why not define a new message for carrying PW
   dynamic parameters this can be sent after label mapping
   (or PW operational).

   That message carries the:

   - Status TLV
   - IP address TLV,
   - QoS,
   - etc

(these are all optional TLVs with U bit set to 1).

b) and use initially within a label mapping the status TLV to
   convey the initial status to the remote end
   before traffic is sent.

In that case, the new message is not just for status, it is
about "things" that the remote end needs to know during the
lifetime of the PW and status TLV can be carried in both
the PW dynamic parameters and label mapping events.

This approach avoids the notify message U bit problems, and is
more or less a combination between the two proposals.

Comments?

Hamid.

>
> comments in line.
>
> Luca
>
>
> Hamid Ould-Brahim wrote:
> > [Catching up on my emails...]   Nice to see we are making
> progress on an
> > integrated approach. Some comments on the proposal...
> >
> >  > >
> >  > >The format of the PW Status TLV is:
> >  > >.DS 0 0
> >  >   0                   1                   2                   3
> >  >   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >  > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > |1|0|     PW Status (0x0???)    |            Length             |
> >  > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > |                         Status Code                           |
> >  > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > .DE
> >  >   Since the U bit in LDP notification message is set to
> 1 then the U
> > bit in Status TLV MUST be set to 0. In other words an LDP
> notify message
> > having a U bit set to 1 MUST include the status message.
> Maybe this is
> > not desirable for all notify messages having U bit set. The problem
> > is the notification message includes the PW FEC TLV and that TLV is
> > always present (no U bit) in notification message below. In
> other words
> > there is no point in including the PW FEC in notify message without
> > including the status TLV (therefore the status TLV U bit
> must be set to
> > 0). If we want to keep the Status TLV optional, then we
> need to fix PW
> > FEC (I don't expect that is acceptable...). More on this
> item,  see the
> > end of this email...
>
> You have a good point.
> I'm checking around to see what the behavior would be.
>
> I was also thinking that maybe we should not set this U bit at all.
> After all this is the standard , and maybe we should just
> mention that for
> backward compatibility implementations might want to set it.
>
>
>
>
> >  > Where status is a 4 octet bit field:
> >  >
> >  > .nf
> >  > 0x00000000 - Pseudo Wire forwarding ( clear all failures )
> >  > 0x00000001 - Pseudo Wire Not Forwarding
> >  > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
> >  > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
> >  > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
> >  > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault
> >  > .En
> >  >     Since these are codepoints in Hex the above should
> be   rewritten
> > to:     0x0000 - Pseudo Wire forwarding ( clear all failures )
> >   0x0001 - Pseudo Wire Not Forwarding
> >   0x0002 - Local Customer-facing PW ( ingress ) Receive Fault
> >   0x0004 - Local Customer-facing PW ( egress ) Transmit Fault
> >   0x0008 - Local PSN-facing PW ( ingress ) Receive Fault
> >   0x0010 - Local PSN-facing PW ( egress ) Transmit Fault
> >  
> >  > >The above status codes can be logically combined to indicate
> >  > more then a
> >  > >single failure at once. Each fault can be cleared by sending
> >  > an appropriate
> >  > >status message with the respective bit cleared. The presence
> >  > of the lowest
> >  > >bit (PW Not Forwarding) acts only as a generic failure
> >  > indication when there
> >  > >is a link-down event for which none of the other bits
> apply.     
> > The status should always be combined when multiple   
> errors happen in
> > an incremental way. For example at a given    time a PE sends local
> > Customer-facing ingress fault and later on    the transmit
> fails, the
> > sender PE should then update the previous    status sent
> and not sent a
> > separate status with only the latter    problem reported.  
>  This is to
> > avoid that a new status for another problem    clears the
> problem for
> > the previous status. Same thing when    new problems happen
> and other
> > problems are cleared. The receiving    PE should screen
> *ALL* the status
> > bits (for updating the    status of already reported
> problems), except
> > for 0x001.    It is important to note that when this
> codepoint is sent
> >    the receiving PE should *ignore* all the other bit (and
> not    treat
> > them as clear).      Since this is bitfield style approach,
> depending
> > what new status    will be added, it may happen that not all
> > combinations    are meaningful.      I am not as well clear
> on 0x001/not
> > forwarding status.    0x0002 and 0x0010 means the PE not
> forwarding as
> > well. Reading    from the above, 0x001 is only applicable
> to these two
> >    codepoints (it is really a summary of these two
> codepoints).    If we
> > want it to be a summary of all the codepoints    then we
> should call it
> > something like "Down/Disabled/General    problem". 
>
> yes , this is the intended behavior , but I see that it needs
> more explanation.
>
>
> >  > >
> >  > >The Status TLV is transported to the remote PW peer via the
> >  > LDP notification
> >  > >message. The format of the Notification Message is:
> >  > >
> >  > >.DS 0 0
> >  > >  0                   1                   2                   3
> >  > >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> 7 8 9 0 1
> >  >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > >|1|   Notification   (0x0001)   |      Message Length  
>         |
> >  >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > >|                           Message ID                 
>         |
> >  >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > >|                           PW FEC TLV                 
>         |
> >  >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > >|                         PW Status TLV                
>         |
> >  >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  > >.DE
> >  > >   The LDP spec says that when U bit is set to 1 in the LDP
> > notification message:   "U bit
> >    Should be 0 when the Status TLV is sent in a
> Notification message.
> >    Should be 1 when the Status TLV is sent in some other
> message."   In
> > the PW status case, the normal notification for basic LDP
> is not carried
> > in some other message (still carried within the LDP notification
> > message). I assume this needs clarification with MPLS WG
> such that LDP
> > implementations that have U bit set will not interpret that
> status will
> > be received in some other messages (maybe this is not an issue, a
> > clarification/checking is always good in case of ambiguity...).
> > Now if a PE doesn't understand status TLV and that PE receives a
> > notification message with U bit set and PW FEC& status
> included, should
> > that PE ignores the LDP notification? Note that I expect basic LDP
> > implementation to understand notify message but they may
> not understand
> > the status TLV. In that case, the status TLV and PW FEC
> must always be
> > present together, if a status TLV is ignored then PW FEC is as well
> > ignored. This area needs clarification.
>
> so the PW FEC is here to identify to which PW this status
> message applies.
> Yes, if the message is ignored because it is not understood ,
> then status
> signaling will not work. This might be ok in some deployments.
>
> >  > >The PW FEC TLV SHOULD not include the interface parameters
> >  > as they are
> >  > >ignored in the context of this message. When a PE's
> >  > CE-facing interface
> >  > >encounters an error, use of the new message allows the PE to
> >  > send a single
> >  > >Status message, using a PW FEC TLV with only the group ID
> >  > set, to denote
> >  > >this change in status for all affected PW connections.
> >  > >   As I indicated in my previous emails, this solution
> works only
> > with PWid FEC not with generalized ID FEC (at least for the
> Group ID). I
> > suggest we have either:   a) status TLV/Notify specified
> for both PW
> > FECs, or b) a different one for Generalized ID FEC...   In
> either case,
> > the text should clarify this... Note that for l2vpn, only
> VPLS service
> > (vkompella proposal) is using the PWid FEC, the other
> proposals will not
> > take advantage of this change (until this proposal works with
> > generalized ID FEC)...   Hamid.
> >  > >
>
> I see. Yes , this needs fixing. It was my intention to make
> it apply to both.
>
>
> >  >
> >  >
>
> Luca
>
>

------_=_NextPart_001_01C3350C.55A259EE-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Tue, 17 Jun 2003 16:31:27 -0600 Organization: Level3 Communications LLC. Lines: 318 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 18 00:39:40 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: Hamid Ould-Brahim Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O no, please there is no need to make life this complicated. this is very similar to where we started out. There is no need to negotiate, if this is not implemented status does not work. ( that seems to be ok for things such as draft-kompella ) There is no need to define here what PPVPN might sometime do. A status notification is not an IP address , or a MAC address. Hamid Ould-Brahim wrote: > Adding further clarifications to this proposal. The TLV status is > exactly what is in Luca's final proposal. The behavior would be a) The > initial label mapping exchange includes the Status TLV (U bit set to > 1). If the receiving PE doesn't understand the status TLV it > will just ignore this TLV and will follow normal procedures. The > sender PE when receiving the reverse label mapping checks if status > TLV is included. If it is included it concludes that the remote PE > understands the Pseudo-wire Dynamic Parameter message (let's just > call it the PDP message). From there, when problems happen, the PDP > message is sent. If the label mapping doesn't contain status TLV, the > sender PE concludes that the remote PE doesn't understand status > TLV. In that case normal behavior should be followed (this is the > backward compatibility rule, PEs that do not understand PDP message > will not receive it). this is not a bad idea , except that now we have to define 2 places to send the status TLV in. b) The status TLV will then be conveyed within > the PDP message. The PDP message as indicated before may convey > other TLVs (IP address, etc). PDP = notification :-) c) An initial indication of "PW not > forwarding/down, etc" in the label mapping indicates to the remote > end not to send traffic until the PDP message is sent with a clear > code point. It will be advisable to have per session cap negotiation > however the above works without it with the understanding that it works > per PW. not sure what you meant here. Hamid. -----Original Message----- > From: Ould-Brahim, Hamid [CAR:1A00:EXCH] > Sent: Tuesday, June 17, 2003 1:43 PM > To: Luca Martini > Cc: Andrew G. Malis; pwe3@ietf.org > Subject: RE: [PWE3] status signalling of MPLS PW state > > Luca, all, > > Since we may end up with an extra message anyway for > carrying information other than status (for example > IP address, QoS, the stuff in Himanshu's draft). > If I recall as well, you proposed in one of your previous emails > to use a new message (called PW dynamic parameters) for carrying > such information. Why not then adopt the following proposal. > > a) Instead of having a separate message > for just status why not define a new message for carrying PW > dynamic parameters this can be sent after label mapping > (or PW operational). > > That message carries the: > > - Status TLV > - IP address TLV, > - QoS, > - etc > > (these are all optional TLVs with U bit set to 1). > > b) and use initially within a label mapping the status TLV to > convey the initial status to the remote end > before traffic is sent. > > In that case, the new message is not just for status, it is > about "things" that the remote end needs to know during the > lifetime of the PW and status TLV can be carried in both > the PW dynamic parameters and label mapping events. > > This approach avoids the notify message U bit problems, and is > more or less a combination between the two proposals. > > Comments? > > Hamid. > > > > > comments in line. > > > > Luca > > > > > > Hamid Ould-Brahim wrote: > > > [Catching up on my emails...] Nice to see we are making > > progress on an > > > integrated approach. Some comments on the proposal... > > > > > > > > > > > > >The format of the PW Status TLV is: > > > > >.DS 0 0 > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 > 9 0 1 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > |1|0| PW Status (0x0???) | > Length | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Status > Code | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > .DE > > > > Since the U bit in LDP notification message is set to > > 1 then the U > > > bit in Status TLV MUST be set to 0. In other words an LDP > > notify message > > > having a U bit set to 1 MUST include the status message. > > Maybe this is > > > not desirable for all notify messages having U bit set. The > problem > > > is the notification message includes the PW FEC TLV and that > TLV is > > > always present (no U bit) in notification message below. In > > other words > > > there is no point in including the PW FEC in notify message > without > > > including the status TLV (therefore the status TLV U bit > > must be set to > > > 0). If we want to keep the Status TLV optional, then we > > need to fix PW > > > FEC (I don't expect that is acceptable...). More on this > > item, see the > > > end of this email... > > > > You have a good point. > > I'm checking around to see what the behavior would be. > > > > I was also thinking that maybe we should not set this U bit at all. > > After all this is the standard , and maybe we should just > > mention that for > > backward compatibility implementations might want to set it. > > > > > > > > > > > > Where status is a 4 octet bit field: > > > > > > > > .nf > > > > 0x00000000 - Pseudo Wire forwarding ( clear all failures ) > > > > 0x00000001 - Pseudo Wire Not Forwarding > > > > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault > > > > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault > > > > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault > > > > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault > > > > .En > > > > Since these are codepoints in Hex the above should > > be rewritten > > > to: 0x0000 - Pseudo Wire forwarding ( clear all failures ) > > > 0x0001 - Pseudo Wire Not Forwarding > > > 0x0002 - Local Customer-facing PW ( ingress ) Receive Fault > > > 0x0004 - Local Customer-facing PW ( egress ) Transmit Fault > > > 0x0008 - Local PSN-facing PW ( ingress ) Receive Fault > > > 0x0010 - Local PSN-facing PW ( egress ) Transmit Fault > > > > > > > >The above status codes can be logically combined to indicate > > > > more then a > > > > >single failure at once. Each fault can be cleared by sending > > > > an appropriate > > > > >status message with the respective bit cleared. The presence > > > > of the lowest > > > > >bit (PW Not Forwarding) acts only as a generic failure > > > > indication when there > > > > >is a link-down event for which none of the other bits > > apply. > > > The status should always be combined when multiple > > errors happen in > > > an incremental way. For example at a given time a PE sends > local > > > Customer-facing ingress fault and later on the transmit > > fails, the > > > sender PE should then update the previous status sent > > and not sent a > > > separate status with only the latter problem reported. > > This is to > > > avoid that a new status for another problem clears the > > problem for > > > the previous status. Same thing when new problems happen > > and other > > > problems are cleared. The receiving PE should screen > > *ALL* the status > > > bits (for updating the status of already reported > > problems), except > > > for 0x001. It is important to note that when this > > codepoint is sent > > > the receiving PE should *ignore* all the other bit (and > > not treat > > > them as clear). Since this is bitfield style approach, > > depending > > > what new status will be added, it may happen that not all > > > combinations are meaningful. I am not as well clear > > on 0x001/not > > > forwarding status. 0x0002 and 0x0010 means the PE not > > forwarding as > > > well. Reading from the above, 0x001 is only applicable > > to these two > > > codepoints (it is really a summary of these two > > codepoints). If we > > > want it to be a summary of all the codepoints then we > > should call it > > > something like "Down/Disabled/General problem". > > > > yes , this is the intended behavior , but I see that it needs > > more explanation. > > > > > > > > > > > > > >The Status TLV is transported to the remote PW peer via the > > > > LDP notification > > > > >message. The format of the Notification Message is: > > > > > > > > > >.DS 0 0 > > > > > 0 1 > 2 3 > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > 7 8 9 0 1 > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >|1| Notification (0x0001) | Message Length > > | > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >| Message ID > > | > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >| PW FEC TLV > > | > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >| PW Status TLV > > | > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > >.DE > > > > > The LDP spec says that when U bit is set to 1 in the LDP > > > notification message: "U bit > > > Should be 0 when the Status TLV is sent in a > > Notification message. > > > Should be 1 when the Status TLV is sent in some other > > message." In > > > the PW status case, the normal notification for basic LDP > > is not carried > > > in some other message (still carried within the LDP notification > > > message). I assume this needs clarification with MPLS WG > > such that LDP > > > implementations that have U bit set will not interpret that > > status will > > > be received in some other messages (maybe this is not an issue, a > > > clarification/checking is always good in case of ambiguity...). > > > Now if a PE doesn't understand status TLV and that PE receives a > > > notification message with U bit set and PW FEC& status > > included, should > > > that PE ignores the LDP notification? Note that I expect basic LDP > > > implementation to understand notify message but they may > > not understand > > > the status TLV. In that case, the status TLV and PW FEC > > must always be > > > present together, if a status TLV is ignored then PW FEC is as > well > > > ignored. This area needs clarification. > > > > so the PW FEC is here to identify to which PW this status > > message applies. > > Yes, if the message is ignored because it is not understood , > > then status > > signaling will not work. This might be ok in some deployments. > > > > > > >The PW FEC TLV SHOULD not include the interface parameters > > > > as they are > > > > >ignored in the context of this message. When a PE's > > > > CE-facing interface > > > > >encounters an error, use of the new message allows the PE to > > > > send a single > > > > >Status message, using a PW FEC TLV with only the group ID > > > > set, to denote > > > > >this change in status for all affected PW connections. > > > > > As I indicated in my previous emails, this solution > > works only > > > with PWid FEC not with generalized ID FEC (at least for the > > Group ID). I > > > suggest we have either: a) status TLV/Notify specified > > for both PW > > > FECs, or b) a different one for Generalized ID FEC... In > > either case, > > > the text should clarify this... Note that for l2vpn, only > > VPLS service > > > (vkompella proposal) is using the PWid FEC, the other > > proposals will not > > > take advantage of this change (until this proposal works with > > > generalized ID FEC)... Hamid. > > > > > > > > > I see. Yes , this needs fixing. It was my intention to make > > it apply to both. > > > > > > > > > > > > > > > > Luca > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Alik Shimelmits Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 09:08:57 +0200 Lines: 91 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 Jun 18 08:14:38 2003 Return-path: To: Yaakov Stein , Danny McPherson , "Romascanu, Dan (Dan)" 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, just for being accurate you should not forget that draft-vainshtein has the following co-authors: Tim Frost (Zarlink) - the company provides CESoPSN chip demonstrated at the last Supercomm, Prayson Pate (Overture) - the company has working system (also demonstrated at the last Supercomm), Edward Metz (Thrupoint) With best regards Alik -----Original Message----- From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Tuesday, June 17, 2003 8:33 PM To: Danny McPherson; Romascanu, Dan (Dan) Cc: pwe3@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > Really? Can you elaborate on this (i.e., how many other > folks have/are implementing this)? Sasha quotes 4 interoperable implementations, RAD, Redux, Ericsson, and Engage. As I have said in previous emails RAD does NOT support CESoPSN in our standard product line. This "interop" was a one-time effort to supply small remote boxes to interoperate with CESoPSN central site for a given sales opportunity. >From their latest spec sheets, Redux only supports unframed raw bit transport, and thus could only possibly support draft-vainshtein in unstructured E1 mode. Unless they have something new and unpublished, they can't possibly support draft-vainshtein for T1 or in structured modes. I don't know what modes Engage and Ericsson support, but it would be interesting to hear. I am guessing that the Engage implementation (being software on a small processor) is also unstructured, but perhaps Sasha could enlighten us. Incidentally, draft-anavi presently has several interoperable implementations that support unstructured and structured modes, and at least two commercial chip-sets are coming out in the near future. Perhaps Dan is refering to verbal support, rather than actual implementations. So far I see 6:5 in favor of CESoPSN: FOR CESoPSN: 1. Sasha - Axerra 2. Ron Cohen - Lycium 3. Michel Khouderchah - Cisco 4. Uri Rotshtein - Redux 5. Max Riegel - Siemens 6. Dan Romascanu - Avaya AGAINST (i.e. for TDMoIP) 1. Yaakov - RAD 2. Shahram - PMC 3. Alex Conta - TranSwitch 4. Amnon Ilan - Nbase 5. Neil Harrison - BT which is pretty close to 50-50. Since I am going to be issuing an update of draft-anavi, we can go through this again and see what support draft-anavi has - the answer will probably be about the same. Finally, perhaps Dan is refering to deployments. draft-anavi has well over 10,000 deployed ports, many of which have been functioning for several years already. Can we get some figures on active deployments (not betas) from the CESoPSN implementations ? I know that this sounds terribly crass, but don't we deserve to hear if this stuff has really been tested in the field? 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: Michel Khouderchah Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 17 Jun 2003 23:59:47 -0700 Lines: 279 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5283B43B@exrad2.ad.rad.co.il > Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_56395632==_.ALT" Cc: "Alexander Vainshtein" , "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Wed Jun 18 09:01:37 2003 Return-path: X-Sender: khouder@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Yaakov Stein" In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5283B43B@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 --=====================_56395632==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Yaakov, No I'm not fooled by the references to ATM-CES, nor am I fooled by draft-Anavi as the only way to salvation! The fact is that the authors of draft-Vainshtein have adopted most of Johnson's formats with the exception of the structure pointer, which remains to be a steamy issue with this WG . IMO, this is a step in the right direction and similar compromise is required from draft-Anavi camp to reach convergence on the basic format. Let us face it, unless comprises are made from both sides (Vainshtein and Anavi authors) this WG will most likely end up with more than one draft. Even the interworking between these two drafts is unlikely if there is no agreement on a basic format. That is not going to serve anyone on this WG! Thus, the first step toward convergence is to reach an agreement on the basic format knowing that it is a compromise (i.e. does solve all the problems, but the limitations it introduces are acceptable). The next step is to introduce other optional formats, which can be adopted from both Vainshtein and Anavi drafts, that are more efficient and appropriate for certain deployment scenarios. The basic format must be supported by all implementations, but not all the optional formats need to be supported by all. I think that all the drafts have pros and cons depending on the assumed deployment scenarios, and that the never-ending disagreements on the convergence to a single format is unlikely to bear fruit any time soon. This is due to the following basic premises, from which all the disagreement seem to stem from. 1. In camp Anavi the main thrust is based on adapting existing ATM-CES structures and the associated advantages (using existing AAL1 SARs, proven technology, ease of interworking with ATM-CES,..). The disadvantage of this approach is that CES over IP/MPLS will be limited by the existing ATM-CES structures and AAL1 SARs. Therefore, any future feature or service must be artificially made to fit into ATM-CES structures. BTW, if interworking with existing ATM-CES is to be addressed fully, then SRTS clock recovery should be addressed in draft-Anavi. SRTS is the recommend approach by ITU, for obvious reasons, and constitute the majority of deployed unstructured ATM-CES . 2. In camp Vainshtein the main thrust is based on supporting flexible and native CES over IP/MPLS without restriction to existing ATM-CES structures. The basic argument here is why carry the baggage and restrictions of ATM-CES in all CES over IP/MPLS deployments even when interworking with ATM is not required? We can keep on arguing the issues till the cows come home, but sooner or later we need to work on convergence and make compromises. Are you ready to make a compromise? Regards, Michel At 11:17 PM 6/14/2003, Yaakov Stein wrote: > > I would like to see this draft become a WG item. The latest > > enhancements offer a good compromise to achieve convergence of Anavi and > > Johnson drafts. > >Michel, > >Can you elaborate on this convergence that you see? > >I hope you are not being fooled by the new draft's >frequent references to ATM-CES --- these references >are either to general descriptive material in that standard, >or to CAS functions, and in no way imply that this new >draft has become any closer to draft-anavi. > >Indded, the only major updates to CESoPSN that I see >actually make it LESS like TDMoIP. > >1) There is a new default mode for CAS >wherein the packet MUST contain a full multiframe. > >This is a major DIVERGENCE from draft-anavi, >the entire philosophy of which is to break the locking >between TDM structures and packets >in order to enable flexible selection of packet size and latency. > >2) The partial awakening of the CESoPSN authors to the >fact that they were the only strong promoters of RTP. >So they decided top promote RTP header compression >as well. > >This is also a divergence from draft-anavi >which for political reasons has a vague reference to RTP, >but certainly does not promote investing in complex >(and expensive from the IPR viewpoint) header compression >schemes in order to ameliorate its ill effects. > >3) The elevation of the following statement to "requirement" level: > Fixed end-to-end delay: CESoPSN implementations SHOULD provide > the same end-to-end delay between any given pair of PEs > regardless of the bit-rate of the emulated service. > >I have commented in the past at great length about the total artificiality >of requiring two different links to have the same delay, >only in order to force a given implementation which happens >to have this "feature". >This un-natural requirement is of course entirely alien to draft-anavi. > >4) Optional "ECMP Prevention" Word >This is of course not needed in draft-anavi, as it uses >the standard PWE control word. > > >Y(J)S --=====================_56395632==_.ALT Content-Type: text/html; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by sj-core-1.cisco.com id h5I6xkTb008681 Content-Transfer-Encoding: quoted-printable Yaakov,

No I=92m not fooled by the references to ATM-CES, nor am I fooled
by draft-Anavi as the only way to salvation! The fact is that the authors
of draft-Vainshtein have adopted most of Johnson=92s formats with
the exception of the structure pointer, which remains to be a steamy issue
with this WG . IMO, this is a step in the right direction and similar
compromise is required from draft-Anavi camp to reach convergence on the
basic format.  Let us face it, unless comprises are made from both sides
(Vainshtein and Anavi authors) this WG will most likely end up with more
than one draft. Even the  interworking between these two drafts is
unlikely if there is no agreement on a basic format. That
is not going to serve anyone on this WG!

Thus, the first step toward convergence is to reach an agreement on=20
the basic format knowing that it is a compromise (i.e. does solve all the
problems, but the limitations it introduces are acceptable). The next step
is to introduce other optional formats, which can be adopted from both
Vainshtein and Anavi drafts, that are more efficient and appropriate for certain
deployment scenarios.  The basic format must be supported by all
implementations, but not all the optional formats need to be supported by all.

I think that all the drafts have pros and cons depending on the  assumed
deployment scenarios, and that the never-ending disagreements on the
convergence to a single format is unlikely to bear fruit any time soon. This
is due to the following basic premises, from which all the disagreement
seem to stem from.

1.      In camp Anavi the main thrust is based on adapting  existing
  ATM-CES structures and the associated advantages (using existing AAL1 SARs,
proven technology, ease of  interworking with ATM-CES,..). The disadvantage
of this approach is that CES over IP/MPLS will be limited by the existing
ATM-CES structures and AAL1 SARs. Therefore, any future feature or service
must be artificially made to fit into ATM-CES structures. BTW, if interworking
with existing ATM-CES is to be addressed fully, then SRTS clock recovery
should be addressed in draft-Anavi.  SRTS is the recommend approach by ITU,
for obvious reasons, and constitute the majority of deployed  unstructured ATM-CES .
2.      In camp Vainshtein the main thrust is based on supporting flexible and native CES
 over IP/MPLS without restriction to existing ATM-CES structures. The basic argument
 here is why carry the baggage and restrictions of ATM-CES in all CES over IP/MPLS
 deployments even when interworking with ATM is not required?



We can keep on arguing the issues till the cows come home, but sooner or
later we need to work on convergence and make compromises. Are you ready
to make a compromise?


Regards,
Michel




At 11:17 PM 6/14/2003, Yaakov Stein wrote:
> I would like to see this draft become a WG item. The latest
> enhancements offer a good compromise to achieve convergence of Anavi and
> Johnson drafts.

Michel,

Can you elaborate on this convergence that you see?

I hope you are not being fooled by the new draft's
frequent references to ATM-CES --- these references
are either to general descriptive material in that standard,
or to CAS functions, and in no way imply that this new
draft has become any closer to draft-anavi.

Indded, the only major updates to CESoPSN that I see
actually make it LESS like TDMoIP.

1) There is a new default mode for CAS
wherein the packet MUST contain a full multiframe.

This is a major DIVERGENCE from draft-anavi,
the entire philosophy of which is to break the locking
between TDM structures and packets
in order to enable flexible selection of packet size and latency.

2) The partial awakening of the CESoPSN authors to the
fact that they were the only strong promoters of RTP.
So they decided top promote RTP header compression
as well.

This is also a divergence from draft-anavi
which for political reasons has a vague reference to RTP,
but certainly does not promote investing in complex
(and expensive from the IPR viewpoint) header compression
schemes in order to ameliorate its ill effects.

3) The elevation of the following statement to "requirement" level:
   Fixed end-to-end delay: CESoPSN implementations SHOULD provide
   the same end-to-end delay between any given pair of PEs
   regardless of the bit-rate of the emulated service.

I have commented in the past at great length about the total artificiality
of requiring two different links to have the same delay,
only in order to force a given implementation which happens
to have this "feature".
This un-natural requirement is of course entirely alien to draft-anavi.

4) Optional "ECMP Prevention" Word
This is of course not needed in draft-anavi, as it uses
the standard PWE control word.


Y(J)S
--=====================_56395632==_.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Tim.Frost@Zarlink.Com Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 09:48:18 +0100 Lines: 130 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Danny McPherson , "Romascanu, Dan (Dan)" , pwe3@ietf.org, pwe3-admin@ietf.org, Yaakov Stein X-From: pwe3-admin@ietf.org Wed Jun 18 10:51:47 2003 Return-path: To: Alik Shimelmits X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.12 |February 13, 2003) at 06/18/2003 04:49:40 AM, Serialize complete at 06/18/2003 04:49:40 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 Alik took the words out of my mouth! Yes we do have a CESoPSN implementation that we demonstrated at Supercomm this year, running across the MEF core network. This implementation is completely separate to any of the implementations mentioned so far in this thread. So there are many separate implementations of this standard. We have not run interoperability trials yet, but these are being planned to happen soon. Just for the record, I support this draft going through as a WG standard. As I understand it , independent co-authors should be counted separately. Regards, Tim Alik Shimelmits Sent by: pwe3-admin@ietf.org 18-Jun-2003 08:08 AM To: Yaakov Stein , Danny McPherson , "Romascanu, Dan (Dan)" cc: pwe3@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Yaakov, just for being accurate you should not forget that draft-vainshtein has the following co-authors: Tim Frost (Zarlink) - the company provides CESoPSN chip demonstrated at the last Supercomm, Prayson Pate (Overture) - the company has working system (also demonstrated at the last Supercomm), Edward Metz (Thrupoint) With best regards Alik -----Original Message----- From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Tuesday, June 17, 2003 8:33 PM To: Danny McPherson; Romascanu, Dan (Dan) Cc: pwe3@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > Really? Can you elaborate on this (i.e., how many other > folks have/are implementing this)? Sasha quotes 4 interoperable implementations, RAD, Redux, Ericsson, and Engage. As I have said in previous emails RAD does NOT support CESoPSN in our standard product line. This "interop" was a one-time effort to supply small remote boxes to interoperate with CESoPSN central site for a given sales opportunity. >From their latest spec sheets, Redux only supports unframed raw bit transport, and thus could only possibly support draft-vainshtein in unstructured E1 mode. Unless they have something new and unpublished, they can't possibly support draft-vainshtein for T1 or in structured modes. I don't know what modes Engage and Ericsson support, but it would be interesting to hear. I am guessing that the Engage implementation (being software on a small processor) is also unstructured, but perhaps Sasha could enlighten us. Incidentally, draft-anavi presently has several interoperable implementations that support unstructured and structured modes, and at least two commercial chip-sets are coming out in the near future. Perhaps Dan is refering to verbal support, rather than actual implementations. So far I see 6:5 in favor of CESoPSN: FOR CESoPSN: 1. Sasha - Axerra 2. Ron Cohen - Lycium 3. Michel Khouderchah - Cisco 4. Uri Rotshtein - Redux 5. Max Riegel - Siemens 6. Dan Romascanu - Avaya AGAINST (i.e. for TDMoIP) 1. Yaakov - RAD 2. Shahram - PMC 3. Alex Conta - TranSwitch 4. Amnon Ilan - Nbase 5. Neil Harrison - BT which is pretty close to 50-50. Since I am going to be issuing an update of draft-anavi, we can go through this again and see what support draft-anavi has - the answer will probably be about the same. Finally, perhaps Dan is refering to deployments. draft-anavi has well over 10,000 deployed ports, many of which have been functioning for several years already. Can we get some figures on active deployments (not betas) from the CESoPSN implementations ? I know that this sounds terribly crass, but don't we deserve to hear if this stuff has really been tested in the field? Y(J)S _______________________________________________ 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: "Yaakov Stein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 12:15:10 +0300 Lines: 23 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "Danny McPherson" , X-From: pwe3-admin@ietf.org Wed Jun 18 11:16:35 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcM1dqrwDyrGr+wUTaa/zJzqrACggwAAy0Rg To: Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Yes we do have a CESoPSN implementation that we demonstrated=20 > at Supercomm this year, running across the MEF core network. This=20 > implementation is completely separate to any of the implementations = mentioned=20 > so far in this thread.=20 Great news. Actually I heard from some people who saw your demo that it looked impressive. > So there are many separate implementations of this=20 > standard. We have not run interoperability trials yet, but these are = being=20 > planned to happen soon. >=20 > Just for the record, I support this draft going through as a=20 > WG standard. As I understand it , independent co-authors should be = counted=20 > separately. As far as I understand, support means non-authors. (One would assume that draft authors support their own draft) Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Tim.Frost@Zarlink.Com Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 10:53:35 +0100 Lines: 57 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "Danny McPherson" , pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 18 11:56:35 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.12 |February 13, 2003) at 06/18/2003 05:54:57 AM, Serialize complete at 06/18/2003 05:54:57 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 So if I were to take my name off the draft, I could then support it, while with my name on the draft I'm not counted? OK, but you'd better take Sasha off your list of supporters, since he is an author - makes it 5-5. Whatever, you all know I support the draft... By the way, thanks for the compliment, we were pleased with the demo. And to return the favour, I understand you had a implementation of draft-anavi there too, running on the MPLS Forum stand. We both have technologies that work. That doesn't make it any easier to choose between them :-) Tim "Yaakov Stein" Sent by: pwe3-admin@ietf.org 18-Jun-2003 10:15 AM To: cc: "Danny McPherson" , Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > Yes we do have a CESoPSN implementation that we demonstrated > at Supercomm this year, running across the MEF core network. This > implementation is completely separate to any of the implementations mentioned > so far in this thread. Great news. Actually I heard from some people who saw your demo that it looked impressive. > So there are many separate implementations of this > standard. We have not run interoperability trials yet, but these are being > planned to happen soon. > > Just for the record, I support this draft going through as a > WG standard. As I understand it , independent co-authors should be counted > separately. As far as I understand, support means non-authors. (One would assume that draft authors support their own draft) Y(J)S _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 14:15:50 +0300 Lines: 158 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Wed Jun 18 13:17:37 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcM1Z1M/yFjmZ8BgQlS/Yz81mJry5gAG0YMQ To: "Michel Khouderchah" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I'm not fooled by the references to ATM-CES, nor am I fooled > by draft-Anavi as the only way to salvation! The fact is that the = authors=20 > of draft-Vainshtein have adopted most of Johnson's formats with=20 > the exception of the structure pointer, which remains to be a steamy = issue > with this WG. I see that you are new to this subject. It wasn't that draft-vainshtein adopted most of draft-johnson, it was simply that Johnson adopted almost all of CESoPSN. If you see anything in the newer versions that were taken from draft-johnson that didn't exist in earlier versions of draft-vainshtein, I am interested in hearing about it. > IMO, this is a step in the right direction and similar > compromise is required from draft-Anavi camp to reach convergence on = the > basic format. Let us face it, unless comprises are made from both = sides=20 > (Vainshtein and Anavi authors) this WG will most likely end up with = more > than one draft.=20 The compromise was PRECISELY the structure pointer. I WAS willing to give up everything, throwing out all of=20 draft-anavi, except the requirement for a structure pointer=20 (which is an absolute necessity for my applications). =20 draft-johnson started off as exactly draft-vainshtein=20 EXCEPT for the structure pointer, and I reluctantly WAS willing to accept that. But then the CESoPSN camp insisited that the structure pointer=20 be removed (or become an unused option), leaving me without functionality that I required. In other words, first I compromised by throwing out all of draft-anavi and accepting draft-vainshtein, except for one small improvement that would allow me to function, and NOW you say that I should compromise and forget about that as well. To come to me now and say that CESoPSN supporters compromised=20 but I am intransigent demonstrates total ignorance of what transpired. I would suggest going back and reading the drafts before making baseless statements to the list. > Even the interworking between these two drafts is=20 > unlikely if there is no agreement on a basic format.=20 > That is not going to serve anyone on this WG!=20 What do you mean by interworking between the two drafts? In earlier versions of draft-anavi I put in a CESoPSN mode for the unstructured case - as a suggested compromise. I also co-authored with Sasha a draft (uCESoPSN) that suggested precisely that mode as the commonality. We then reached a full compromise in Atlanta, but the other camp backed down after 2 weeks. > Thus, the first step toward convergence is to reach an agreement on=20 > the basic format knowing that it is a compromise (i.e. does solve all = the > problems, but the limitations it introduces are acceptable).=20 Why should I make compromises that leave problems unsolved when I have a method that solves all my problems? Purely political compromises that produce deficient standards are not in anyone's interest.=20 > The next step is to introduce other optional formats,=20 > which can be adopted from both Vainshtein and Anavi drafts,=20 > that are more efficient and appropriate for certain > deployment scenarios. The basic format must be supported by all=20 > implementations, but not all the optional formats need to be supported = by all.=20 This is just what was agreed in Atlanta, and I am still willing to go back to that agreement. > I think that all the drafts have pros and cons depending on the = assumed=20 > deployment scenarios, and that the never-ending disagreements on the=20 > convergence to a single format is unlikely to bear fruit any time = soon. This > is due to the following basic premises, from which all the = disagreement > seem to stem from. > 1. In camp Anavi the main thrust is based on adapting existing > ATM-CES structures and the associated advantages (using existing = AAL1 SARs,=20 > proven technology, ease of interworking with ATM-CES,..). The = disadvantage > of this approach is that CES over IP/MPLS will be limited by the = existing=20 > ATM-CES structures and AAL1 SARs. Therefore, any future feature or = service > must be artificially made to fit into ATM-CES structures.=20 Can you give an example of what future feature in your opinion can not be handled by TDMoIP? > BTW, if interworking > with existing ATM-CES is to be addressed fully, then SRTS clock = recovery > should be addressed in draft-Anavi. SRTS is the recommend approach by = ITU,=20 > for obvious reasons, and constitute the majority of deployed = unstructured ATM-CES .=20 SRTS can certainly be used in any draft-anavi implementations that have a physical layer clock to reference. Unfortunately, few IP or MPLS networks have end-to-end physical clock integrity. If there is no consistent physical layer clock, then SRTS (which encodes the difference between the source=20 clock and the physical layer clock) can not work, no matter what I write in a draft. But if it makes you happy I will let you use SRTS. > 2. In camp Vainshtein the main thrust is based on supporting flexible = and native CES > over IP/MPLS without restriction to existing ATM-CES = structures. The basic argument=20 > here is why carry the baggage and restrictions of ATM-CES in all CES = over IP/MPLS=20 > deployments even when interworking with ATM is not required?=20 What baggage do you think TDMoIP has? If you read the draft you will see that we do NOT have ATM baggage (e.g. we do NOT carry the ATM header). Also I suggest comparing the two drafts to see which has more "baggage" - you will find that TDMoIP has less baggage. For example, why does CESoPSN use the CEP header rather than the standard PWE control word, when it doesn't use the structure pointer? Just baggage. > We can keep on arguing the issues till the cows come home, but sooner = or > later we need to work on convergence and make compromises. Are you = ready=20 > to make a compromise? draft-anavi supporters made the compromises sooner -=20 too bad you came into the picture later.=20 I am still willing to return to the previously agreed=20 upon compromises - in all of which I gave up practically=20 everything in my draft and adopted essentially CESoPSN but with the required additions to solve practical problems. I am also more than willing to hear about new compromises, but in order not to fall into the same trap as last time I want first to hear what compromise the other side is willing=20 to make.=20 Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-pw-tc-mib-01.txt Date: Wed, 18 Jun 2003 07:54:01 -0400 Lines: 82 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 18 13:55:36 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Definitions for Textual Conventions and OBJECT-IDENTITIES for Pseudo-Wires Management Author(s) : T. Nadeau, D. Danenberg, D. Zelig, A. Malis Filename : draft-ietf-pwe3-pw-tc-mib-01.txt Pages : 10 Date : 2003-6-17 This memo defines an experimental portion of the Management information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the textual conventions to be used in the various Pseudo Wire (PW) MIB modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-tc-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-tc-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-pw-mib-01.txt Date: Wed, 18 Jun 2003 07:54:11 -0400 Lines: 82 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 18 13:55:37 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, T. Nadeau, D. Danenberg, S. Mantin Filename : draft-ietf-pwe3-pw-mib-01.txt Pages : 37 Date : 2003-6-17 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire (PW) services on a general Packet Switched Net (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-enet-mib-01.txt Date: Wed, 18 Jun 2003 07:54:06 -0400 Lines: 81 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 18 13:55:38 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Ethernet Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, T. Nadeau Filename : draft-ietf-pwe3-enet-mib-01.txt Pages : 20 Date : 2003-6-17 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet Pseudo Wire (PW) services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-enet-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-enet-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-enet-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-pw-mpls-mib-01.txt Date: Wed, 18 Jun 2003 07:54:16 -0400 Lines: 83 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 18 13:55:39 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire (PW) over MPLS PSN Management Information Base Author(s) : D. Zelig, T. Nadeau, D. Danenberg Filename : draft-ietf-pwe3-pw-mpls-mib-01.txt Pages : 32 Date : 2003-6-17 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes MIB module for PW operation over Multi-Protocol Label Switching (MPLS) Label Switch Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mpls-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-mpls-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mpls-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Rina Nathaniel Subject: RE: FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 08:50:06 +0300 Lines: 13 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-From: pwe3-admin@ietf.org Wed Jun 18 14:25:36 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 I support adopting this draft as a WG item. Rina Nathaniel This mail was sent via mail.alvarion.com ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Re: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 07:05:25 -0600 Lines: 12 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 Wed Jun 18 15:37:20 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: 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 On 6/18/03 3:53 AM, "Tim.Frost@Zarlink.Com" wrote: > So if I were to take my name off the draft, I could then support it, while > with my name on the draft I'm not counted? > OK, but you'd better take Sasha off your list of supporters, since he is > an author - makes it 5-5. > Whatever, you all know I support the draft... While an exorbitant number of authors on many IDs in the past has indeed marginalized the value of their "support", it clearly still carries weight. -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: John Fischer Subject: Re: draft-ietf-pwe3-atm-encap-01.txt Date: Wed, 18 Jun 2003 09:48:24 -0400 Organization: Alcatel Canada Lines: 173 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: luca@level3.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 18 16:47:43 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: xiaozhen.zhong@mindspeed.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 Hi Hoey, There is a long history behind the bits/bytes and positioning within the ATM information. The ATM Forum and ITU worked on this problem in parallel with the IETF and came to different outcomes based on somewhat different design goals. This draft is a merger of the two approaches. I believe the draft will shortly be updated. I added some comments below. John xiaozhen.zhong@mindspeed.com wrote: > > Hi, Luca, > > This is Joey Zhong from Mindspeed System Inc (My site was known as > Maker systems before it's aquired by Mindspeed). We are implementing > draft-ietf-pwe3-atm-encap-01.txt on our OC-48 network processor. The > engineering group here found couple of potential enhancement for the > draft during implementation. Please see following proposal for the > details. > > We've been reviewing draft-ietf-pwe3-atm-encap-01.txt. As it seems > this document is settling down for overall functionality, it might be > time to look at advantages of different codings and positions of > fields in the frames. > > The draft shows several different positions and orders of the Length, > Sequence Number, and Flags fields partially copied herein: > > in section 4.1 (general): > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Rsvd | Flags |Res| Length | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > in section 6.6 (VCC service): > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PSN Transport Header (As Required) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Pseudo Wire Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional Length and Sequence Number |M|V|Res| PTI |C| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > in section 6.7.1 (VPC service): > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PSN Transport Header (As Required) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Pseudo Wire Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional Length and Sequence Number |M|V|Res| PTI |C| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > in section 7.1 (N-to-1 service): > implied usage of the section 4.1 control word. > > in section 8.2 (SDU service): > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Res |T|E|C|U|Res| Length | Sequence Number (Optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > in section 9.2 (PDU service): > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional Length and Sequence Number |M|V| Res |U|E|C| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Looking at them all together, you can see there are several locations > for the length, sequence, and flags fields. It would make more sense > to have these fields have a normal position or at least relative > ordering across all of the service modes while some fields would vary. > Notice in the "Optional Length and Sequence Number" field (assuming > this states order of the two), the Sequence number is not on a half > word boundary. Notice the major differences for the SDU and PDU mode > which are otherwise very similar by function. As we consider moving > the fields and bits around, we should do so in a way that simplifies > the bit and byte banging needed by both hardware and software > solutions. The soon to be uploaded ATM draft should show this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Resvd | Optional Sequence Number | ATM Specific | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This format was chosen to ensue that the first nibble following the VC label cannot alias IPv4 or IPv6 (core ECMP issue). > I would recommend something like: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | Length | Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This construct has the 16 bit sequence number aligned on a half word, > the length aligned on a byte boundary, and has the flags in the least > significant byte to allow the best availability of bit manipulation > instructions. Not also that in the VPC and VCC modes, the flag field > of the first cell in the packet has to follow the Sequence and Length > fields allowing the offered ordering to be similar throughout the PWE3 > ATM modes. I understand that this doesn't take into account the > possibility of cramming a PID into the control word. > > Then looking at the flags, it make little sense to have a different > ordering of the E, C, and U bits in each encoding and there is an > ideal order. > > I would recommend: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | Length |M|V|Res|O|E|U|C| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I've swapped the E and U bits from the PDU service mode as the E, U, C > ordering aligns with the corresponding meaning from the ATM cell > header. Even though work needs to be done across many cells to > determine the ATM control word setting of E and C, the alignment will > help with calculations. > > Other possibilities shown in the encoding is to have a bit 'O' to > indicate OAM cells. For the 'T' bit meaning in the SDU service mode, > the 'O' bit could be used for that meaning. Note the alignment with > the ATM cell header and now a perfect match between the VCC/VPC > service flags (PTI/C) and the O, E, U, and C ordering. > > The M and V bits are not required in all modes as presently defined, > but their meaning could be carried throughout. Interesting that the > SDU mode currently defined doesn't indicate "packet" or "cell". This > is one service where carrying the meaning through would help. In the 1:1 modes, the meaning is carried throughout. In the N:1 modes, the T bits is similar to the M bits. > The U bit has different meanings that are non-overlapping. In the SDU > mode, U is the CPCS-UU bit while in PDU mode it is the ATM > user-to-user bit. One limitation is that the SDU mode cannot indicate > a continuation or end of a fragmented SDU. This wasn't presently > specified anyway. The PDU mode transports the whole AAL5 PDU - thats the SDU, the padding and the AAL5 trailer. The trailer contains the CPCS-UU bit already so it is not copied to the flag bits. PDU mode supports fragmentation. At the egress LER, the device needs to know when to terminate the AAL5 PDU. For fragments not containing EOP, the bit is 0, for fragments containing EOP, the bit is 1. In SDU mode, fragmentation is not supported. > > comments? > > Joey Zhong > > ------------------------------------------------ > Joey Zhong > Firmware Engineer > Mindspeed Technologies (TM), a Conexant business > 8 Technology Drive 508-621-0794 desk > Westborough, MA 01581-1756 508-621-0605 fax > ------------------------------------------------ From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 16:54:51 +0200 Lines: 192 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "PWE3 WG (E-mail)" , Michel Khouderchah X-From: pwe3-admin@ietf.org Wed Jun 18 16:51:24 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, In case you have missed this item while reading CESoPSN-06: CESoPSN-06 now supports trunk-specific Nx64 kbit/s with CAS and that the default payload format for these services coinsides with the default payload format for these services in draft-johnson. As far as I remember, you have strongly emphasized the need to support trunk-specific Nx64 kbit/s services with CAS in the past. 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: Wednesday, June 18, 2003 1:16 PM > To: Michel Khouderchah > Cc: PWE3 WG (E-mail) > Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > > > I'm not fooled by the references to ATM-CES, nor am I fooled > > by draft-Anavi as the only way to salvation! The fact is > that the authors > > of draft-Vainshtein have adopted most of Johnson's formats with > > the exception of the structure pointer, which remains to be > a steamy issue > > with this WG. > > I see that you are new to this subject. > It wasn't that draft-vainshtein adopted most of draft-johnson, > it was simply that Johnson adopted almost all of CESoPSN. > > If you see anything in the newer versions that were taken > from draft-johnson that didn't exist in earlier versions > of draft-vainshtein, I am interested in hearing about it. > > > IMO, this is a step in the right direction and similar > > compromise is required from draft-Anavi camp to reach > convergence on the > > basic format. Let us face it, unless comprises are made > from both sides > > (Vainshtein and Anavi authors) this WG will most likely end > up with more > > than one draft. > > The compromise was PRECISELY the structure pointer. > I WAS willing to give up everything, throwing out all of > draft-anavi, except the requirement for a structure pointer > (which is an absolute necessity for my applications). > draft-johnson started off as exactly draft-vainshtein > EXCEPT for the structure pointer, > and I reluctantly WAS willing to accept that. > But then the CESoPSN camp insisited that the structure pointer > be removed (or become an unused option), > leaving me without functionality that I required. > > In other words, first I compromised by throwing out all > of draft-anavi and accepting draft-vainshtein, > except for one small improvement that would allow > me to function, and NOW you say that I should > compromise and forget about that as well. > > To come to me now and say that CESoPSN supporters compromised > but I am intransigent demonstrates total ignorance of what transpired. > I would suggest going back and reading the drafts before > making baseless statements to the list. > > > Even the interworking between these two drafts is > > unlikely if there is no agreement on a basic format. > > That is not going to serve anyone on this WG! > > What do you mean by interworking between the two drafts? > In earlier versions of draft-anavi I put in a CESoPSN mode > for the unstructured case - as a suggested compromise. > I also co-authored with Sasha a draft (uCESoPSN) > that suggested precisely that mode as the commonality. > We then reached a full compromise in Atlanta, > but the other camp backed down after 2 weeks. > > > Thus, the first step toward convergence is to reach an agreement on > > the basic format knowing that it is a compromise (i.e. does > solve all the > > problems, but the limitations it introduces are acceptable). > > Why should I make compromises that leave problems unsolved > when I have a method that solves all my problems? > > Purely political compromises that produce deficient standards > are not in anyone's interest. > > > The next step is to introduce other optional formats, > > which can be adopted from both Vainshtein and Anavi drafts, > > that are more efficient and appropriate for certain > > deployment scenarios. The basic format must be supported by all > > implementations, but not all the optional formats need to > be supported by all. > > This is just what was agreed in Atlanta, > and I am still willing to go back to that agreement. > > > I think that all the drafts have pros and cons depending on > the assumed > > deployment scenarios, and that the never-ending > disagreements on the > > convergence to a single format is unlikely to bear fruit > any time soon. This > > is due to the following basic premises, from which all the > disagreement > > seem to stem from. > > > 1. In camp Anavi the main thrust is based on adapting existing > > ATM-CES structures and the associated advantages (using > existing AAL1 SARs, > > proven technology, ease of interworking with ATM-CES,..). > The disadvantage > > of this approach is that CES over IP/MPLS will be limited > by the existing > > ATM-CES structures and AAL1 SARs. Therefore, any future > feature or service > > must be artificially made to fit into ATM-CES structures. > > Can you give an example of what future feature > in your opinion can not be handled by TDMoIP? > > > BTW, if interworking > > with existing ATM-CES is to be addressed fully, then SRTS > clock recovery > > should be addressed in draft-Anavi. SRTS is the recommend > approach by ITU, > > for obvious reasons, and constitute the majority of > deployed unstructured ATM-CES . > > SRTS can certainly be used in any draft-anavi implementations > that have a physical layer clock to reference. > Unfortunately, few IP or MPLS networks have end-to-end > physical clock integrity. > If there is no consistent physical layer clock, > then SRTS (which encodes the difference between the source > clock and the physical layer clock) can not work, > no matter what I write in a draft. > But if it makes you happy I will let you use SRTS. > > > 2. In camp Vainshtein the main thrust is based on > supporting flexible and native CES > over IP/MPLS without > restriction to existing ATM-CES structures. The basic argument > > here is why carry the baggage and restrictions of ATM-CES > in all CES over IP/MPLS > > deployments even when interworking with ATM is not required? > > What baggage do you think TDMoIP has? > If you read the draft you will see that we do NOT have ATM baggage > (e.g. we do NOT carry the ATM header). > Also I suggest comparing the two drafts to see which > has more "baggage" - you will find that TDMoIP has less baggage. > For example, why does CESoPSN use the CEP header rather than > the standard PWE control word, when it doesn't use the structure > pointer? Just baggage. > > > We can keep on arguing the issues till the cows come home, > but sooner or > > later we need to work on convergence and make compromises. > Are you ready > > to make a compromise? > > draft-anavi supporters made the compromises sooner - > too bad you came into the picture later. > > I am still willing to return to the previously agreed > upon compromises - in all of which I gave up practically > everything in my draft and adopted essentially CESoPSN > but with the required additions to solve practical problems. > > I am also more than willing to hear about new compromises, > but in order not to fall into the same trap as last time > I want first to hear what compromise the other side is willing > to make. > > 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: Shahram Davari Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 07:09:23 -0700 Lines: 184 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Wed Jun 18 17:25:49 2003 Return-path: To: "'Yaakov Stein'" , Michel Khouderchah X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, As I recall the first compromise reached was in Atlanta, where the design team agreed that the unstructured mode be done according to CESoPSN and the structured mode be done according to TDMoIP. Later on the CESoPSN camp backed off from their compromise. The second compromise was initiated by Johnson, which was essentially CESoPSN with a structure pointer, which was accepted by TDMoIP camp (although it didn't preserve anything from TDMoIP), but was soon rejected by CESoPSN camp, because they didn't like the structure pointer. So As far as I can see, it is the CESoPSN camp that is unwilling to compromise not the TDMoIP camp. Yours, -Shahram >-----Original Message----- >From: Yaakov Stein [mailto:yaakov_s@rad.com] >Sent: Wednesday, June 18, 2003 7:16 AM >To: Michel Khouderchah >Cc: PWE3 WG (E-mail) >Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > >> I'm not fooled by the references to ATM-CES, nor am I fooled >> by draft-Anavi as the only way to salvation! The fact is >that the authors >> of draft-Vainshtein have adopted most of Johnson's formats with >> the exception of the structure pointer, which remains to be >a steamy issue >> with this WG. > >I see that you are new to this subject. >It wasn't that draft-vainshtein adopted most of draft-johnson, >it was simply that Johnson adopted almost all of CESoPSN. > >If you see anything in the newer versions that were taken >from draft-johnson that didn't exist in earlier versions >of draft-vainshtein, I am interested in hearing about it. > >> IMO, this is a step in the right direction and similar >> compromise is required from draft-Anavi camp to reach >convergence on the >> basic format. Let us face it, unless comprises are made >from both sides >> (Vainshtein and Anavi authors) this WG will most likely end >up with more >> than one draft. > >The compromise was PRECISELY the structure pointer. >I WAS willing to give up everything, throwing out all of >draft-anavi, except the requirement for a structure pointer >(which is an absolute necessity for my applications). >draft-johnson started off as exactly draft-vainshtein >EXCEPT for the structure pointer, >and I reluctantly WAS willing to accept that. >But then the CESoPSN camp insisited that the structure pointer >be removed (or become an unused option), >leaving me without functionality that I required. > >In other words, first I compromised by throwing out all >of draft-anavi and accepting draft-vainshtein, >except for one small improvement that would allow >me to function, and NOW you say that I should >compromise and forget about that as well. > >To come to me now and say that CESoPSN supporters compromised >but I am intransigent demonstrates total ignorance of what transpired. >I would suggest going back and reading the drafts before >making baseless statements to the list. > >> Even the interworking between these two drafts is >> unlikely if there is no agreement on a basic format. >> That is not going to serve anyone on this WG! > >What do you mean by interworking between the two drafts? >In earlier versions of draft-anavi I put in a CESoPSN mode >for the unstructured case - as a suggested compromise. >I also co-authored with Sasha a draft (uCESoPSN) >that suggested precisely that mode as the commonality. >We then reached a full compromise in Atlanta, >but the other camp backed down after 2 weeks. > >> Thus, the first step toward convergence is to reach an agreement on >> the basic format knowing that it is a compromise (i.e. does >solve all the >> problems, but the limitations it introduces are acceptable). > >Why should I make compromises that leave problems unsolved >when I have a method that solves all my problems? > >Purely political compromises that produce deficient standards >are not in anyone's interest. > >> The next step is to introduce other optional formats, >> which can be adopted from both Vainshtein and Anavi drafts, >> that are more efficient and appropriate for certain >> deployment scenarios. The basic format must be supported by all >> implementations, but not all the optional formats need to be >supported by all. > >This is just what was agreed in Atlanta, >and I am still willing to go back to that agreement. > >> I think that all the drafts have pros and cons depending on >the assumed >> deployment scenarios, and that the never-ending disagreements on the >> convergence to a single format is unlikely to bear fruit any >time soon. This >> is due to the following basic premises, from which all the >disagreement >> seem to stem from. > >> 1. In camp Anavi the main thrust is based on adapting existing >> ATM-CES structures and the associated advantages (using >existing AAL1 SARs, >> proven technology, ease of interworking with ATM-CES,..). >The disadvantage >> of this approach is that CES over IP/MPLS will be limited by >the existing >> ATM-CES structures and AAL1 SARs. Therefore, any future >feature or service >> must be artificially made to fit into ATM-CES structures. > >Can you give an example of what future feature >in your opinion can not be handled by TDMoIP? > >> BTW, if interworking >> with existing ATM-CES is to be addressed fully, then SRTS >clock recovery >> should be addressed in draft-Anavi. SRTS is the recommend >approach by ITU, >> for obvious reasons, and constitute the majority of deployed > unstructured ATM-CES . > >SRTS can certainly be used in any draft-anavi implementations >that have a physical layer clock to reference. >Unfortunately, few IP or MPLS networks have end-to-end >physical clock integrity. >If there is no consistent physical layer clock, >then SRTS (which encodes the difference between the source >clock and the physical layer clock) can not work, >no matter what I write in a draft. >But if it makes you happy I will let you use SRTS. > >> 2. In camp Vainshtein the main thrust is based on >supporting flexible and native CES > over IP/MPLS without >restriction to existing ATM-CES structures. The basic argument >> here is why carry the baggage and restrictions of ATM-CES in >all CES over IP/MPLS >> deployments even when interworking with ATM is not required? > >What baggage do you think TDMoIP has? >If you read the draft you will see that we do NOT have ATM baggage >(e.g. we do NOT carry the ATM header). >Also I suggest comparing the two drafts to see which >has more "baggage" - you will find that TDMoIP has less baggage. >For example, why does CESoPSN use the CEP header rather than >the standard PWE control word, when it doesn't use the structure >pointer? Just baggage. > >> We can keep on arguing the issues till the cows come home, >but sooner or >> later we need to work on convergence and make compromises. >Are you ready >> to make a compromise? > >draft-anavi supporters made the compromises sooner - >too bad you came into the picture later. > >I am still willing to return to the previously agreed >upon compromises - in all of which I gave up practically >everything in my draft and adopted essentially CESoPSN >but with the required additions to solve practical problems. > >I am also more than willing to hear about new compromises, >but in order not to fall into the same trap as last time >I want first to hear what compromise the other side is willing >to make. > >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: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Wed, 18 Jun 2003 10:22:33 -0400 Lines: 475 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C335A5.0F05A9F2" Cc: "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Jun 18 17:42:29 2003 Return-path: To: Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C335A5.0F05A9F2 Content-Type: text/plain; charset="iso-8859-1" Luca, > > > no, please there is no need to make life this complicated. > this is very similar to where we started out. > There is no need to negotiate, if this is not implemented > status does not work. > ( that seems to be ok for things such as draft-kompella ) > There is no need to define here what PPVPN might sometime do. > A status notification is not an IP address , or a MAC address. > I think I sense some misunderstanding here. I am perfectly fine with Notify message if we can make it work (at least no major issue) and clarify the behavior ;-). The motivation for this suggestion is not to start from scratch but to accommodate status signaling with providing the framework for signaling items needed during the lifetime of PW and at the same time address some points raised before (sooner or later when there is a need -and there will be- to signal additional stuff to PW, folks will at least find the framework already established and not just overload the label mapping). In fact this suggestion doesn't require any negotiation or P bit support, etc (and looks to me less complex than resolving the U bit items in notify message). But anyway no matter what approach is taken, let's look at items that I think are important to consider (some have already been covered and addressed): a) Backward compatibility rule: A PE that doesn't understand status TLV should be able to establish a PW to another PE (supporting Status TLV) using normal procedures. In this case both PEs will not advertise (signal) status TLV. That rule requires that the sender PE (supporting status TLV) needs to find out implicitly or explicitly the intentions/capabilities of the receiving PE. The notify message (including the use of a new message in that regard) cannot provide such information. There are two options for that: - Either include in the label mapping the status (or capability) for just the initial setup (no need to send the label mapping each time status has changed). The behavior is what is indicated in my previous email which pretty much reused Himanshu's status TLV behavior, or - Have some capability advertisement between PEs or session negotiation. I realize there is some resistance to that and may require some work on the session hand shake... For simplicity I picked the first option. Yes the status will appear in two messages. But this is okay since the status TLV needs to appear for events that require status notification. b) Initial PW status Notification It is desirable that two PEs establishing a PW and both supporting status TLV need to be able to find out upfront the status of PW such that they take appropriate actions before even accepting and forwarding traffic. For this requirement, either we assume that initially the PW is not forwarding until the notification is received or we just indicate in the label mapping the status. Given a) I prefer to use label mapping. I think Dave mentioned as well the benefit of using status TLV in label mapping during graceful restart... Some other comments below as well: > > Hamid Ould-Brahim wrote: > > Adding further clarifications to this proposal. The TLV status is > > exactly what is in Luca's final proposal. The behavior > would be a) The > > initial label mapping exchange includes the Status TLV > (U bit set to > > > > 1). If the receiving PE doesn't understand the status > TLV it > > will just ignore this TLV and will follow normal > procedures. The > > sender PE when receiving the reverse label mapping > checks if status > > TLV is included. If it is included it concludes that the > remote PE > > understands the Pseudo-wire Dynamic Parameter message > (let's just > > call it the PDP message). From there, when problems > happen, the PDP > > message is sent. If the label mapping doesn't contain > status TLV, the > > sender PE concludes that the remote PE doesn't > understand status > > TLV. In that case normal behavior should be followed > (this is the > > backward compatibility rule, PEs that do not understand > PDP message > > will not receive it). > this is not a bad idea , except that now we have to define 2 > places to send the > status TLV in. > Yes. I don't see problem with that. There are events where sending status is important: a) During the initial PW establishment. b) When operational status changes. To meet a) we include it in label mapping, and to meet b) use notify or new message or the preferred mode. > b) The status TLV will then be conveyed within > > the PDP message. The PDP message as indicated before may > convey > > other TLVs (IP address, etc). > > PDP = notification :-) > Yes, with the understanding that we clarify the issues with respect to basic LDP functionality and with the understanding that this approach may motivate other folks to add new stuff to notify message later on. This may not be a desirable approach....but don't get me wrong I am just trying to be clear on that (not asking for perfection ;-)). As I said I can live with notify message given we can reach agreement on its usage and how best it meets most of the requirements. > c) An initial indication of "PW not > > forwarding/down, etc" in the label mapping indicates to > the remote > > end not to send traffic until the PDP message is sent > with a clear > > code point. It will be advisable to have per session cap > negotiation > > however the above works without it with the understanding > that it works > > per PW. > > not sure what you meant here. I meant the negotiation is in fact "implicit" through normal PW label mapping exchange...no need to add P bit, session nego, etc... Hamid. > > Hamid. -----Original Message----- > > From: Ould-Brahim, Hamid [CAR:1A00:EXCH] > > Sent: Tuesday, June 17, 2003 1:43 PM > > To: Luca Martini > > Cc: Andrew G. Malis; pwe3@ietf.org > > Subject: RE: [PWE3] status signalling of MPLS PW state > > > > Luca, all, > > > > Since we may end up with an extra message anyway for > > carrying information other than status (for example > > IP address, QoS, the stuff in Himanshu's draft). > > If I recall as well, you proposed in one of your previous emails > > to use a new message (called PW dynamic parameters) for carrying > > such information. Why not then adopt the following proposal. > > > > a) Instead of having a separate message > > for just status why not define a new message for carrying PW > > dynamic parameters this can be sent after label mapping > > (or PW operational). > > > > That message carries the: > > > > - Status TLV > > - IP address TLV, > > - QoS, > > - etc > > > > (these are all optional TLVs with U bit set to 1). > > > > b) and use initially within a label mapping the status TLV to > > convey the initial status to the remote end > > before traffic is sent. > > > > In that case, the new message is not just for status, it is > > about "things" that the remote end needs to know during the > > lifetime of the PW and status TLV can be carried in both > > the PW dynamic parameters and label mapping events. > > > > This approach avoids the notify message U bit problems, and is > > more or less a combination between the two proposals. > > > > Comments? > > > > Hamid. > > ------_=_NextPart_001_01C335A5.0F05A9F2 Content-Type: text/html; charset="iso-8859-1" Luca,

>
>
> no, please there is no need to make life this complicated.
> this is very similar to where we started out.
> There is no need to negotiate, if this is not implemented
> status does not work.
> ( that seems to be ok for things such as draft-kompella )
> There is no need to define here what PPVPN might sometime do.
> A status notification is not an IP address , or a MAC address.
>

I think I sense some misunderstanding here. I am perfectly
fine with Notify message if we can make it work (at least no major
issue) and clarify the behavior ;-).
 
The motivation for this suggestion is not
to start from scratch but to accommodate status signaling with
providing the framework for signaling items needed during
the lifetime of PW and at the same time address some points
raised before (sooner or later when there is a need -and there will be-
to signal additional stuff to PW, folks will at least find the
framework already established and not just overload the label mapping).
In fact this suggestion doesn't require any negotiation or P bit support,
etc (and looks to me less complex than resolving the U bit items
in notify message).
 
But anyway no matter what approach is taken,
let's look at items that I think are important to consider
(some have already been covered and addressed):
 
a) Backward compatibility rule:
 
   A PE that doesn't understand status TLV should be able to establish
   a PW to another PE (supporting Status TLV) using normal
   procedures. In this case both PEs will not advertise (signal)
   status TLV.
 
   That rule requires that the sender PE (supporting status TLV)
   needs to find out implicitly or explicitly the intentions/capabilities
   of the receiving PE.
   The notify message (including the use of a new message in that regard)
   cannot provide such information.
 
   There are two options for that:
 
   - Either include in the label mapping the status (or capability)
     for just the initial setup (no need to send the label mapping each time
     status has changed). The behavior is what is indicated in my
     previous email which pretty much reused Himanshu's status TLV
     behavior, or
     
   - Have some capability advertisement between PEs or session
     negotiation. I realize there is some resistance to that and may
     require some work on the session hand shake...
 
    For simplicity I picked the first option. Yes the status will
    appear in two messages. But this is okay since the status TLV needs
    to appear for events that require status notification. 
 
 
b) Initial PW status Notification
 
   It is desirable that two PEs establishing a PW and both
   supporting status TLV need to be able to find out upfront the status
   of PW such that they take appropriate actions before even accepting
   and forwarding traffic.
 
   For this requirement, either we assume that initially the
   PW is not forwarding until the notification is received or
   we just indicate in the label mapping the status. Given a) I prefer
   to use label mapping.
 
I think Dave mentioned as well the benefit of using status
TLV in label mapping during graceful restart...
 
Some other comments below as well:

>
> Hamid Ould-Brahim wrote:
> > Adding further clarifications to this proposal. The TLV status is
> > exactly what is in Luca's final proposal. The behavior
> would be   a) The
> > initial label mapping exchange includes the    Status TLV
> (U bit set to
>
>
> > 1).      If the receiving PE doesn't understand the status
> TLV    it
> > will just ignore this TLV and will follow normal   
> procedures.      The
> > sender PE when receiving the reverse label mapping   
> checks if status
> > TLV is included. If it is included it concludes    that the
> remote PE
> > understands the Pseudo-wire Dynamic    Parameter message
> (let's just
> > call it the PDP message).      From there, when problems
> happen, the PDP
> > message is sent.    If the label mapping doesn't contain
> status TLV, the
> >    sender PE concludes that the remote PE doesn't
> understand    status
> > TLV. In that case normal behavior should    be followed
> (this is the
> > backward compatibility rule,    PEs that do not understand
> PDP message
> > will not receive it).  
> this is not a bad idea , except that now we have to define 2
> places to send the
> status TLV in.
>
 
Yes. I don't see problem with that. There are events where
sending status is important:
 
a) During the initial PW establishment.
b) When operational status changes.
 
To meet a) we include it in label mapping, and to meet
b) use notify or new message or the preferred mode.
 

> b) The status TLV will then be conveyed within
> > the PDP    message. The PDP message as indicated before may
> convey   
> > other TLVs (IP address, etc).  
>
> PDP = notification :-)
>
 
Yes, with the understanding that we clarify the issues with
respect to basic LDP functionality and with the understanding
that this approach may motivate other folks
to add new stuff to notify message later on. This may not
be a desirable approach....but don't get me wrong I am just
trying to be clear on that (not asking for perfection ;-)).
As I said I can live with notify message given we can reach
agreement on its usage and how best it meets most of the
requirements.

> c) An initial indication of "PW not
> > forwarding/down, etc" in the    label mapping indicates to
> the remote
> > end not to send    traffic until the PDP message is sent
> with a clear
> > code point.   It will be advisable to have per session cap
> negotiation
> > however the above works without it with the understanding
> that it works
> > per PW.
>
> not sure what you meant here.
 
I meant the negotiation is in fact "implicit" through normal
PW label mapping exchange...no need to add P bit, session nego,
etc...
 
Hamid.
 

>
>     Hamid.      -----Original Message-----
> > From: Ould-Brahim, Hamid [CAR:1A00:EXCH]
> > Sent: Tuesday, June 17, 2003 1:43 PM
> > To: Luca Martini
> > Cc: Andrew G. Malis; pwe3@ietf.org
> > Subject: RE: [PWE3] status signalling of MPLS PW state
> >
> >     Luca, all,
> >
> >     Since we may end up with an extra message anyway for
> >     carrying information other than status (for example
> >     IP address, QoS, the stuff in Himanshu's draft).
> >     If I recall as well, you proposed in one of your previous emails
> >     to use a new message (called PW dynamic parameters) for carrying
> >     such information. Why not then adopt the following proposal.
> >
> >     a) Instead of having a separate message
> >        for just status why not define a new message for carrying PW
> >        dynamic parameters this can be sent after label mapping
> >        (or PW operational).
> >
> >        That message carries the:
> >
> >        - Status TLV
> >        - IP address TLV,
> >        - QoS,
> >        - etc
> >
> >     (these are all optional TLVs with U bit set to 1).
> >
> >     b) and use initially within a label mapping the status TLV to
> >        convey the initial status to the remote end
> >        before traffic is sent.
> >
> >     In that case, the new message is not just for status, it is
> >     about "things" that the remote end needs to know during the
> >     lifetime of the PW and status TLV can be carried in both
> >     the PW dynamic parameters and label mapping events.
> >
> >     This approach avoids the notify message U bit problems, and is
> >     more or less a combination between the two proposals.
> >
> >     Comments?
> >
> >     Hamid.
> >
 ------_=_NextPart_001_01C335A5.0F05A9F2-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Prayson Pate" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 10:41:24 -0400 Lines: 86 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Danny McPherson" , , X-From: pwe3-admin@ietf.org Wed Jun 18 17:55:40 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.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh3.wired-hub.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - overturenetworks.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 Just for the record, I want to reiterate my support for draft-vainshtein-cesopsn-06.txt and CESoPSN. Also, as shown at Supercomm, Overture Networks has a working implementation that is deployed in live networks. Prayson > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Tim.Frost@Zarlink.Com > Sent: Wednesday, June 18, 2003 5:54 AM > To: Yaakov Stein > Cc: Danny McPherson; pwe3@ietf.org; pwe3-admin@ietf.org > Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > So if I were to take my name off the draft, I could then support > it, while > with my name on the draft I'm not counted? > OK, but you'd better take Sasha off your list of supporters, since he is > an author - makes it 5-5. > Whatever, you all know I support the draft... > > By the way, thanks for the compliment, we were pleased with the demo. And > to return the favour, I understand you had a implementation of > draft-anavi > there too, running on the MPLS Forum stand. > > We both have technologies that work. That doesn't make it any easier to > choose between them :-) > > Tim > > > > > > "Yaakov Stein" > Sent by: pwe3-admin@ietf.org > 18-Jun-2003 10:15 AM > > > To: > cc: "Danny McPherson" , > Subject: RE: [PWE3] Re: I-D > ACTION:draft-vainshtein-cesopsn-06.txt > > > > Yes we do have a CESoPSN implementation that we demonstrated > > at Supercomm this year, running across the MEF core network. This > > implementation is completely separate to any of the implementations > mentioned > > so far in this thread. > > Great news. Actually I heard from some people > who saw your demo that it looked impressive. > > > So there are many separate implementations of this > > standard. We have not run interoperability trials yet, but these are > being > > planned to happen soon. > > > > Just for the record, I support this draft going through as a > > WG standard. As I understand it , independent co-authors should be > counted > > separately. > > As far as I understand, support means non-authors. > (One would assume that draft authors support their own draft) > > Y(J)S > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: FW: REMINDER Internet-Draft Cutoff Dates for Vienna, Austria Date: Wed, 18 Jun 2003 09:17:52 -0600 Lines: 59 Sender: pwe3-admin@ietf.org References: <200306181446.KAA10343@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Jun 18 18:30:56 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: In-Reply-To: <200306181446.KAA10343@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 If you've got a document you're planning to submit in preparation for the Vienna meeting please let Stewart and I know ASAP, even if it's not fully baked yet. Also, consider this another call for slot requests.. If you want to talk at the meeting please let us know ASAP. -danny ------ Forwarded Message From: Internet-Drafts Administrator Date: Wed, 18 Jun 2003 10:46:02 -0400 To: IETF-Announce: ; Subject: REMINDER Internet-Draft Cutoff Dates for Vienna, Austria NOTE: There are two (2) Internet-Draft Cutoff dates June 23rd: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 23rd, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 16th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 23rd will NOT be accepted. June 30st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, June 30st, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_57.html ------ End of Forwarded Message From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: neil.2.harrison@bt.com Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 22:40:33 +0100 Lines: 175 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Cc: danny@tcb.net, dromasca@avaya.com, pwe3@ietf.org, pwe3-admin@ietf.org, yaakov_s@rad.com X-From: pwe3-admin@ietf.org Thu Jun 19 00:08:02 2003 Return-path: To: Tim.Frost@Zarlink.Com, alik@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 Tim, Can you please clarify *who* this draft aimed at? Is it's usage in: Internet? ISPs? Enterprises? Carriers? I must admit I find it really hard to understand just who lots of CCAMPs stuff is aimed at in the general case. I just re-read it and IMO its awful from a large carriers perspective (but then we have many problems with much of the PWE stuff from a functional architecture perspective.....hopefully I don't have to explain why!). However, I would not want to stop anyone using this, just so long as its target audience is clear and its not being sold as the solution for everyone. regards, Neil > -----Original Message----- > From: Tim.Frost@Zarlink.Com [mailto:Tim.Frost@Zarlink.Com] > Sent: 18 June 2003 09:48 > To: Alik Shimelmits > Cc: Danny McPherson; Romascanu, Dan (Dan); pwe3@ietf.org; > pwe3-admin@ietf.org; Yaakov Stein > Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > Alik took the words out of my mouth! > > Yes we do have a CESoPSN implementation that we demonstrated > at Supercomm > this year, running across the MEF core network. This > implementation is > completely separate to any of the implementations mentioned > so far in this > thread. So there are many separate implementations of this > standard. We > have not run interoperability trials yet, but these are being > planned to > happen soon. > > Just for the record, I support this draft going through as a > WG standard. > As I understand it , independent co-authors should be counted > separately. > > Regards, > Tim > > > > > > > Alik Shimelmits > Sent by: pwe3-admin@ietf.org > 18-Jun-2003 08:08 AM > > > To: Yaakov Stein , Danny > McPherson , > "Romascanu, Dan (Dan)" > cc: pwe3@ietf.org > Subject: RE: [PWE3] Re: I-D > ACTION:draft-vainshtein-cesopsn-06.txt > > > Yaakov, > just for being accurate you should not forget that > draft-vainshtein has > the > following co-authors: > > Tim Frost (Zarlink) - the company provides CESoPSN chip > demonstrated at > the > last Supercomm, > Prayson Pate (Overture) - the company has working system (also > demonstrated > at the last Supercomm), > Edward Metz (Thrupoint) > > With best regards > Alik > > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Tuesday, June 17, 2003 8:33 PM > To: Danny McPherson; Romascanu, Dan (Dan) > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > > Really? Can you elaborate on this (i.e., how many other > > folks have/are implementing this)? > > Sasha quotes 4 interoperable implementations, > RAD, Redux, Ericsson, and Engage. > > As I have said in previous emails RAD does NOT > support CESoPSN in our standard product line. > This "interop" was a one-time effort to supply small > remote boxes to interoperate with CESoPSN central site > for a given sales opportunity. > > From their latest spec sheets, Redux only supports unframed > raw bit transport, and thus could only possibly support > draft-vainshtein > in unstructured E1 mode. Unless they have something new > and unpublished, they can't possibly support draft-vainshtein > for T1 or in structured modes. > > I don't know what modes Engage and Ericsson support, > but it would be interesting to hear. I am guessing that > the Engage implementation (being software on a small > processor) is also unstructured, > but perhaps Sasha could enlighten us. > > Incidentally, draft-anavi presently has several interoperable > implementations that support unstructured and structured modes, > and at least two commercial chip-sets are coming out in the > near future. > > Perhaps Dan is refering to verbal support, > rather than actual implementations. > So far I see 6:5 in favor of CESoPSN: > > FOR CESoPSN: > 1. Sasha - Axerra > 2. Ron Cohen - Lycium > 3. Michel Khouderchah - Cisco > 4. Uri Rotshtein - Redux > 5. Max Riegel - Siemens > 6. Dan Romascanu - Avaya > > AGAINST (i.e. for TDMoIP) > 1. Yaakov - RAD > 2. Shahram - PMC > 3. Alex Conta - TranSwitch > 4. Amnon Ilan - Nbase > 5. Neil Harrison - BT > > which is pretty close to 50-50. > Since I am going to be issuing an update > of draft-anavi, we can go through this > again and see what support draft-anavi has - > the answer will probably be about the same. > > Finally, perhaps Dan is refering to deployments. > draft-anavi has well over 10,000 deployed ports, > many of which have been functioning for several > years already. Can we get some figures on > active deployments (not betas) from the CESoPSN > implementations ? > I know that this sounds terribly crass, > but don't we deserve to hear if this stuff > has really been tested in the field? > > Y(J)S > > > _______________________________________________ > 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: "Shah, Himanshu" Subject: RE: status signalling of MPLS PW state Date: Wed, 18 Jun 2003 10:04:45 -0400 Lines: 874 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C335A2.923A6360" Cc: "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 19 06:02:32 2003 Return-path: To: "'Luca Martini'" , Hamid Ould-Brahim X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C335A2.923A6360 Content-Type: text/plain; charset="iso-8859-1" comments in line.. > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Tuesday, June 17, 2003 6:31 PM > To: Hamid Ould-Brahim > Cc: Andrew G. Malis; pwe3@ietf.org > Subject: Re: [PWE3] status signalling of MPLS PW state > > > no, please there is no need to make life this complicated. > this is very similar to where we started out. I fail to see what part is complicated. > There is no need to negotiate, if this is not implemented > status does not work. There is no negotiation here. It is exactly same as P bit in VC type field but better. It follows the base LDP spec's STATUS TLV mechanisms (which allows status to be passed in optional parameter field of label mapping msg as well as in notification msg). > ( that seems to be ok for things such as draft-kompella ) I am not sure what you are referring to here > There is no need to define here what PPVPN might sometime do. There is no need to define it within status spec but there needs to exist a hook for future extensions in a backward compatible fashion. > A status notification is not an IP address , or a MAC address. No it is not but it is in the same category as IP address or MAC address called "dynamic attributes" and there should be one mechanism to exchange dynamic attributes in a manner such that exchange of one attribute does not interfere with other. /himanshu > > > Hamid Ould-Brahim wrote: > > Adding further clarifications to this proposal. The TLV status is > > exactly what is in Luca's final proposal. The behavior > would be a) The > > initial label mapping exchange includes the Status TLV > (U bit set to > > > > 1). If the receiving PE doesn't understand the status > TLV it > > will just ignore this TLV and will follow normal > procedures. The > > sender PE when receiving the reverse label mapping > checks if status > > TLV is included. If it is included it concludes that the > remote PE > > understands the Pseudo-wire Dynamic Parameter message > (let's just > > call it the PDP message). From there, when problems > happen, the PDP > > message is sent. If the label mapping doesn't contain > status TLV, the > > sender PE concludes that the remote PE doesn't > understand status > > TLV. In that case normal behavior should be followed > (this is the > > backward compatibility rule, PEs that do not understand > PDP message > > will not receive it). > this is not a bad idea , except that now we have to define 2 > places to send the > status TLV in. > > b) The status TLV will then be conveyed within > > the PDP message. The PDP message as indicated before may > convey > > other TLVs (IP address, etc). > > PDP = notification :-) > > c) An initial indication of "PW not > > forwarding/down, etc" in the label mapping indicates to > the remote > > end not to send traffic until the PDP message is sent > with a clear > > code point. It will be advisable to have per session cap > negotiation > > however the above works without it with the understanding > that it works > > per PW. > > not sure what you meant here. > > Hamid. -----Original Message----- > > From: Ould-Brahim, Hamid [CAR:1A00:EXCH] > > Sent: Tuesday, June 17, 2003 1:43 PM > > To: Luca Martini > > Cc: Andrew G. Malis; pwe3@ietf.org > > Subject: RE: [PWE3] status signalling of MPLS PW state > > > > Luca, all, > > > > Since we may end up with an extra message anyway for > > carrying information other than status (for example > > IP address, QoS, the stuff in Himanshu's draft). > > If I recall as well, you proposed in one of your previous emails > > to use a new message (called PW dynamic parameters) for carrying > > such information. Why not then adopt the following proposal. > > > > a) Instead of having a separate message > > for just status why not define a new message for carrying PW > > dynamic parameters this can be sent after label mapping > > (or PW operational). > > > > That message carries the: > > > > - Status TLV > > - IP address TLV, > > - QoS, > > - etc > > > > (these are all optional TLVs with U bit set to 1). > > > > b) and use initially within a label mapping the status TLV to > > convey the initial status to the remote end > > before traffic is sent. > > > > In that case, the new message is not just for status, it is > > about "things" that the remote end needs to know during the > > lifetime of the PW and status TLV can be carried in both > > the PW dynamic parameters and label mapping events. > > > > This approach avoids the notify message U bit problems, and is > > more or less a combination between the two proposals. > > > > Comments? > > > > Hamid. > > > > > > > > comments in line. > > > > > > Luca > > > > > > > > > Hamid Ould-Brahim wrote: > > > > [Catching up on my emails...] Nice to see we are making > > > progress on an > > > > integrated approach. Some comments on the proposal... > > > > > > > > > > > > > > > >The format of the PW Status TLV is: > > > > > >.DS 0 0 > > > > > 0 1 2 > 3 > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 > 3 4 5 6 7 8 > > 9 0 1 > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > |1|0| PW Status (0x0???) | > > Length | > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > | Status > > Code | > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > .DE > > > > > Since the U bit in LDP notification message is set to > > > 1 then the U > > > > bit in Status TLV MUST be set to 0. In other words an LDP > > > notify message > > > > having a U bit set to 1 MUST include the status message. > > > Maybe this is > > > > not desirable for all notify messages having U bit set. The > > problem > > > > is the notification message includes the PW FEC > TLV and that > > TLV is > > > > always present (no U bit) in notification message below. In > > > other words > > > > there is no point in including the PW FEC in notify message > > without > > > > including the status TLV (therefore the status TLV U bit > > > must be set to > > > > 0). If we want to keep the Status TLV optional, then we > > > need to fix PW > > > > FEC (I don't expect that is acceptable...). More on this > > > item, see the > > > > end of this email... > > > > > > You have a good point. > > > I'm checking around to see what the behavior would be. > > > > > > I was also thinking that maybe we should not set > this U bit at all. > > > After all this is the standard , and maybe we should just > > > mention that for > > > backward compatibility implementations might want to set it. > > > > > > > > > > > > > > > > > Where status is a 4 octet bit field: > > > > > > > > > > .nf > > > > > 0x00000000 - Pseudo Wire forwarding ( clear all > failures ) > > > > > 0x00000001 - Pseudo Wire Not Forwarding > > > > > 0x00000002 - Local Customer-facing PW ( ingress > ) Receive Fault > > > > > 0x00000004 - Local Customer-facing PW ( egress > ) Transmit Fault > > > > > 0x00000008 - Local PSN-facing PW ( ingress ) > Receive Fault > > > > > 0x00000010 - Local PSN-facing PW ( egress ) > Transmit Fault > > > > > .En > > > > > Since these are codepoints in Hex the above should > > > be rewritten > > > > to: 0x0000 - Pseudo Wire forwarding ( clear > all failures ) > > > > 0x0001 - Pseudo Wire Not Forwarding > > > > 0x0002 - Local Customer-facing PW ( ingress ) > Receive Fault > > > > 0x0004 - Local Customer-facing PW ( egress ) > Transmit Fault > > > > 0x0008 - Local PSN-facing PW ( ingress ) Receive Fault > > > > 0x0010 - Local PSN-facing PW ( egress ) Transmit Fault > > > > > > > > > >The above status codes can be logically > combined to indicate > > > > > more then a > > > > > >single failure at once. Each fault can be > cleared by sending > > > > > an appropriate > > > > > >status message with the respective bit > cleared. The presence > > > > > of the lowest > > > > > >bit (PW Not Forwarding) acts only as a generic failure > > > > > indication when there > > > > > >is a link-down event for which none of the other bits > > > apply. > > > > The status should always be combined when multiple > > > errors happen in > > > > an incremental way. For example at a given time > a PE sends > > local > > > > Customer-facing ingress fault and later on the transmit > > > fails, the > > > > sender PE should then update the previous status sent > > > and not sent a > > > > separate status with only the latter problem reported. > > > This is to > > > > avoid that a new status for another problem clears the > > > problem for > > > > the previous status. Same thing when new problems happen > > > and other > > > > problems are cleared. The receiving PE should screen > > > *ALL* the status > > > > bits (for updating the status of already reported > > > problems), except > > > > for 0x001. It is important to note that when this > > > codepoint is sent > > > > the receiving PE should *ignore* all the other bit (and > > > not treat > > > > them as clear). Since this is bitfield style approach, > > > depending > > > > what new status will be added, it may happen > that not all > > > > combinations are meaningful. I am not as well clear > > > on 0x001/not > > > > forwarding status. 0x0002 and 0x0010 means the PE not > > > forwarding as > > > > well. Reading from the above, 0x001 is only applicable > > > to these two > > > > codepoints (it is really a summary of these two > > > codepoints). If we > > > > want it to be a summary of all the codepoints then we > > > should call it > > > > something like "Down/Disabled/General problem". > > > > > > yes , this is the intended behavior , but I see that it needs > > > more explanation. > > > > > > > > > > > > > > > > > >The Status TLV is transported to the remote PW > peer via the > > > > > LDP notification > > > > > >message. The format of the Notification Message is: > > > > > > > > > > > >.DS 0 0 > > > > > > 0 1 > > 2 3 > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > > > 7 8 9 0 1 > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >|1| Notification (0x0001) | Message Length > > > | > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >| Message ID > > > | > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >| PW FEC TLV > > > | > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >| PW Status TLV > > > | > > > > > > > > > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > >.DE > > > > > > The LDP spec says that when U bit is set to > 1 in the LDP > > > > notification message: "U bit > > > > Should be 0 when the Status TLV is sent in a > > > Notification message. > > > > Should be 1 when the Status TLV is sent in some other > > > message." In > > > > the PW status case, the normal notification for basic LDP > > > is not carried > > > > in some other message (still carried within the > LDP notification > > > > message). I assume this needs clarification with MPLS WG > > > such that LDP > > > > implementations that have U bit set will not interpret that > > > status will > > > > be received in some other messages (maybe this is > not an issue, a > > > > clarification/checking is always good in case of > ambiguity...). > > > > Now if a PE doesn't understand status TLV and that > PE receives a > > > > notification message with U bit set and PW FEC& status > > > included, should > > > > that PE ignores the LDP notification? Note that I > expect basic LDP > > > > implementation to understand notify message but they may > > > not understand > > > > the status TLV. In that case, the status TLV and PW FEC > > > must always be > > > > present together, if a status TLV is ignored then > PW FEC is as > > well > > > > ignored. This area needs clarification. > > > > > > so the PW FEC is here to identify to which PW this status > > > message applies. > > > Yes, if the message is ignored because it is not understood , > > > then status > > > signaling will not work. This might be ok in some > deployments. > > > > > > > > >The PW FEC TLV SHOULD not include the > interface parameters > > > > > as they are > > > > > >ignored in the context of this message. When a PE's > > > > > CE-facing interface > > > > > >encounters an error, use of the new message > allows the PE to > > > > > send a single > > > > > >Status message, using a PW FEC TLV with only > the group ID > > > > > set, to denote > > > > > >this change in status for all affected PW connections. > > > > > > As I indicated in my previous emails, this solution > > > works only > > > > with PWid FEC not with generalized ID FEC (at least for the > > > Group ID). I > > > > suggest we have either: a) status TLV/Notify specified > > > for both PW > > > > FECs, or b) a different one for Generalized ID FEC... In > > > either case, > > > > the text should clarify this... Note that for l2vpn, only > > > VPLS service > > > > (vkompella proposal) is using the PWid FEC, the other > > > proposals will not > > > > take advantage of this change (until this proposal > works with > > > > generalized ID FEC)... Hamid. > > > > > > > > > > > > I see. Yes , this needs fixing. It was my intention to make > > > it apply to both. > > > > > > > > > > > > > > > > > > > > > > Luca > > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C335A2.923A6360 Content-Type: text/html; charset="iso-8859-1" RE: [PWE3] status signalling of MPLS PW state

comments in line..

> -----Original Message-----
> From: Luca Martini [mailto:luca@level3.net]
> Sent: Tuesday, June 17, 2003 6:31 PM
> To: Hamid Ould-Brahim
> Cc: Andrew G. Malis; pwe3@ietf.org
> Subject: Re: [PWE3] status signalling of MPLS PW state
>
>
> no, please there is no need to make life this complicated.
> this is very similar to where we started out.

I fail to see what part is complicated.

> There is no need to negotiate, if this is not implemented
> status does not work.

There is no negotiation here. It is exactly same as P bit in
VC type field but better. It follows the base LDP spec's
STATUS TLV mechanisms (which allows status to be passed
in optional parameter field of label mapping msg as well as
in notification msg).

> ( that seems to be ok for things such as draft-kompella )

I am not sure what you are referring to here

> There is no need to define here what PPVPN might sometime do.

There is no need to define it within status spec but there needs to exist
a hook for future extensions in a backward compatible fashion.

> A status notification is not an IP address , or a MAC address.

No it is not but it is in the same category as IP address or MAC address
called "dynamic attributes" and there should be one mechanism to
exchange dynamic attributes in a manner such that exchange of one attribute
does not interfere with other.

/himanshu

>
>
> Hamid Ould-Brahim wrote:
> > Adding further clarifications to this proposal. The TLV status is
> > exactly what is in Luca's final proposal. The behavior
> would be   a) The
> > initial label mapping exchange includes the    Status TLV
> (U bit set to
>
>
> > 1).      If the receiving PE doesn't understand the status
> TLV    it
> > will just ignore this TLV and will follow normal   
> procedures.      The
> > sender PE when receiving the reverse label mapping   
> checks if status
> > TLV is included. If it is included it concludes    that the
> remote PE
> > understands the Pseudo-wire Dynamic    Parameter message
> (let's just
> > call it the PDP message).      From there, when problems
> happen, the PDP
> > message is sent.    If the label mapping doesn't contain
> status TLV, the
> >    sender PE concludes that the remote PE doesn't
> understand    status
> > TLV. In that case normal behavior should    be followed
> (this is the
> > backward compatibility rule,    PEs that do not understand
> PDP message
> > will not receive it).  
> this is not a bad idea , except that now we have to define 2
> places to send the
> status TLV in.
>
> b) The status TLV will then be conveyed within
> > the PDP    message. The PDP message as indicated before may
> convey   
> > other TLVs (IP address, etc).  
>
> PDP = notification :-)
>
> c) An initial indication of "PW not
> > forwarding/down, etc" in the    label mapping indicates to
> the remote
> > end not to send    traffic until the PDP message is sent
> with a clear
> > code point.   It will be advisable to have per session cap
> negotiation
> > however the above works without it with the understanding
> that it works
> > per PW.
>
> not sure what you meant here.
>
>     Hamid.      -----Original Message-----
> > From: Ould-Brahim, Hamid [CAR:1A00:EXCH]
> > Sent: Tuesday, June 17, 2003 1:43 PM
> > To: Luca Martini
> > Cc: Andrew G. Malis; pwe3@ietf.org
> > Subject: RE: [PWE3] status signalling of MPLS PW state
> >
> >     Luca, all,
> >
> >     Since we may end up with an extra message anyway for
> >     carrying information other than status (for example
> >     IP address, QoS, the stuff in Himanshu's draft).
> >     If I recall as well, you proposed in one of your previous emails
> >     to use a new message (called PW dynamic parameters) for carrying
> >     such information. Why not then adopt the following proposal.
> >
> >     a) Instead of having a separate message
> >        for just status why not define a new message for carrying PW
> >        dynamic parameters this can be sent after label mapping
> >        (or PW operational).
> >
> >        That message carries the:
> >
> >        - Status TLV
> >        - IP address TLV,
> >        - QoS,
> >        - etc
> >
> >     (these are all optional TLVs with U bit set to 1).
> >
> >     b) and use initially within a label mapping the status TLV to
> >        convey the initial status to the remote end
> >        before traffic is sent.
> >
> >     In that case, the new message is not just for status, it is
> >     about "things" that the remote end needs to know during the
> >     lifetime of the PW and status TLV can be carried in both
> >     the PW dynamic parameters and label mapping events.
> >
> >     This approach avoids the notify message U bit problems, and is
> >     more or less a combination between the two proposals.
> >
> >     Comments?
> >
> >     Hamid.
> >
> >      >
> >      > comments in line.
> >      >
> >      > Luca
> >      >
> >      >
> >      > Hamid Ould-Brahim wrote:
> >      > > [Catching up on my emails...]   Nice to see we are making
> >      > progress on an
> >      > > integrated approach. Some comments on the proposal...
> >      > >
> >      > >  > >
> >      > >  > >The format of the PW Status TLV is:
> >      > >  > >.DS 0 0
> >      > >  >   0                   1                   2    
>               3
> >      > >  >   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
> 3 4 5 6 7 8
> >     9 0 1
> >      > >  >
> >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      > >  > |1|0|     PW Status (0x0???)    |          
> >     Length             |
> >      > >  >
> >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      > >  > |                         Status
> >     Code                           |
> >      > >  >
> >    
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      > >  > .DE
> >      > >  >   Since the U bit in LDP notification message is set to
> >      > 1 then the U
> >      > > bit in Status TLV MUST be set to 0. In other words an LDP
> >      > notify message
> >      > > having a U bit set to 1 MUST include the status message.
> >      > Maybe this is
> >      > > not desirable for all notify messages having U bit set. The
> >     problem
> >      > > is the notification message includes the PW FEC
> TLV and that
> >     TLV is
> >      > > always present (no U bit) in notification message below. In
> >      > other words
> >      > > there is no point in including the PW FEC in notify message
> >     without
> >      > > including the status TLV (therefore the status TLV U bit
> >      > must be set to
> >      > > 0). If we want to keep the Status TLV optional, then we
> >      > need to fix PW
> >      > > FEC (I don't expect that is acceptable...). More on this
> >      > item,  see the
> >      > > end of this email...
> >      >
> >      > You have a good point.
> >      > I'm checking around to see what the behavior would be.
> >      >
> >      > I was also thinking that maybe we should not set
> this U bit at all.
> >      > After all this is the standard , and maybe we should just
> >      > mention that for
> >      > backward compatibility implementations might want to set it.
> >      >
> >      >
> >      >
> >      >
> >      > >  > Where status is a 4 octet bit field:
> >      > >  >
> >      > >  > .nf
> >      > >  > 0x00000000 - Pseudo Wire forwarding ( clear all
> failures )
> >      > >  > 0x00000001 - Pseudo Wire Not Forwarding
> >      > >  > 0x00000002 - Local Customer-facing PW ( ingress
> ) Receive Fault
> >      > >  > 0x00000004 - Local Customer-facing PW ( egress
> ) Transmit Fault
> >      > >  > 0x00000008 - Local PSN-facing PW ( ingress )
> Receive Fault
> >      > >  > 0x00000010 - Local PSN-facing PW ( egress )
> Transmit Fault
> >      > >  > .En
> >      > >  >     Since these are codepoints in Hex the above should
> >      > be   rewritten
> >      > > to:     0x0000 - Pseudo Wire forwarding ( clear
> all failures )
> >      > >   0x0001 - Pseudo Wire Not Forwarding
> >      > >   0x0002 - Local Customer-facing PW ( ingress )
> Receive Fault
> >      > >   0x0004 - Local Customer-facing PW ( egress )
> Transmit Fault
> >      > >   0x0008 - Local PSN-facing PW ( ingress ) Receive Fault
> >      > >   0x0010 - Local PSN-facing PW ( egress ) Transmit Fault
> >      > > 
> >      > >  > >The above status codes can be logically
> combined to indicate
> >      > >  > more then a
> >      > >  > >single failure at once. Each fault can be
> cleared by sending
> >      > >  > an appropriate
> >      > >  > >status message with the respective bit
> cleared. The presence
> >      > >  > of the lowest
> >      > >  > >bit (PW Not Forwarding) acts only as a generic failure
> >      > >  > indication when there
> >      > >  > >is a link-down event for which none of the other bits
> >      > apply.    
> >      > > The status should always be combined when multiple  
> >      > errors happen in
> >      > > an incremental way. For example at a given    time
> a PE sends
> >     local
> >      > > Customer-facing ingress fault and later on    the transmit
> >      > fails, the
> >      > > sender PE should then update the previous    status sent
> >      > and not sent a
> >      > > separate status with only the latter    problem reported. 
> >      >  This is to
> >      > > avoid that a new status for another problem    clears the
> >      > problem for
> >      > > the previous status. Same thing when    new problems happen
> >      > and other
> >      > > problems are cleared. The receiving    PE should screen
> >      > *ALL* the status
> >      > > bits (for updating the    status of already reported
> >      > problems), except
> >      > > for 0x001.    It is important to note that when this
> >      > codepoint is sent
> >      > >    the receiving PE should *ignore* all the other bit (and
> >      > not    treat
> >      > > them as clear).      Since this is bitfield style approach,
> >      > depending
> >      > > what new status    will be added, it may happen
> that not all
> >      > > combinations    are meaningful.      I am not as well clear
> >      > on 0x001/not
> >      > > forwarding status.    0x0002 and 0x0010 means the PE not
> >      > forwarding as
> >      > > well. Reading    from the above, 0x001 is only applicable
> >      > to these two
> >      > >    codepoints (it is really a summary of these two
> >      > codepoints).    If we
> >      > > want it to be a summary of all the codepoints    then we
> >      > should call it
> >      > > something like "Down/Disabled/General    problem".
> >      >
> >      > yes , this is the intended behavior , but I see that it needs
> >      > more explanation.
> >      >
> >      >
> >      > >  > >
> >      > >  > >The Status TLV is transported to the remote PW
> peer via the
> >      > >  > LDP notification
> >      > >  > >message. The format of the Notification Message is:
> >      > >  > >
> >      > >  > >.DS 0 0
> >      > >  > >  0                   1                 
> >     2                   3
> >      > >  > >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
> >      > 7 8 9 0 1
> >      > >  >
> >      >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      > >  > >|1|   Notification   (0x0001)   |      Message Length 
> >      >         |
> >      > >  >
> >      >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      > >  > >|                           Message ID                
> >      >         |
> >      > >  >
> >      >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      > >  > >|                           PW FEC TLV                
> >      >         |
> >      > >  >
> >      >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      > >  > >|                         PW Status TLV               
> >      >         |
> >      > >  >
> >      >
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      > >  > >.DE
> >      > >  > >   The LDP spec says that when U bit is set to
> 1 in the LDP
> >      > > notification message:   "U bit
> >      > >    Should be 0 when the Status TLV is sent in a
> >      > Notification message.
> >      > >    Should be 1 when the Status TLV is sent in some other
> >      > message."   In
> >      > > the PW status case, the normal notification for basic LDP
> >      > is not carried
> >      > > in some other message (still carried within the
> LDP notification
> >      > > message). I assume this needs clarification with MPLS WG
> >      > such that LDP
> >      > > implementations that have U bit set will not interpret that
> >      > status will
> >      > > be received in some other messages (maybe this is
> not an issue, a
> >      > > clarification/checking is always good in case of
> ambiguity...).
> >      > > Now if a PE doesn't understand status TLV and that
> PE receives a
> >      > > notification message with U bit set and PW FEC& status
> >      > included, should
> >      > > that PE ignores the LDP notification? Note that I
> expect basic LDP
> >      > > implementation to understand notify message but they may
> >      > not understand
> >      > > the status TLV. In that case, the status TLV and PW FEC
> >      > must always be
> >      > > present together, if a status TLV is ignored then
> PW FEC is as
> >     well
> >      > > ignored. This area needs clarification.
> >      >
> >      > so the PW FEC is here to identify to which PW this status
> >      > message applies.
> >      > Yes, if the message is ignored because it is not understood ,
> >      > then status
> >      > signaling will not work. This might be ok in some
> deployments.
> >      >
> >      > >  > >The PW FEC TLV SHOULD not include the
> interface parameters
> >      > >  > as they are
> >      > >  > >ignored in the context of this message. When a PE's
> >      > >  > CE-facing interface
> >      > >  > >encounters an error, use of the new message
> allows the PE to
> >      > >  > send a single
> >      > >  > >Status message, using a PW FEC TLV with only
> the group ID
> >      > >  > set, to denote
> >      > >  > >this change in status for all affected PW connections.
> >      > >  > >   As I indicated in my previous emails, this solution
> >      > works only
> >      > > with PWid FEC not with generalized ID FEC (at least for the
> >      > Group ID). I
> >      > > suggest we have either:   a) status TLV/Notify specified
> >      > for both PW
> >      > > FECs, or b) a different one for Generalized ID FEC...   In
> >      > either case,
> >      > > the text should clarify this... Note that for l2vpn, only
> >      > VPLS service
> >      > > (vkompella proposal) is using the PWid FEC, the other
> >      > proposals will not
> >      > > take advantage of this change (until this proposal
> works with
> >      > > generalized ID FEC)...   Hamid.
> >      > >  > >
> >      >
> >      > I see. Yes , this needs fixing. It was my intention to make
> >      > it apply to both.
> >      >
> >      >
> >      > >  >
> >      > >  >
> >      >
> >      > Luca
> >      >
> >      >
> >
>
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>

------_=_NextPart_001_01C335A2.923A6360-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Rotshtein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Wed, 18 Jun 2003 19:12:44 +0300 Lines: 94 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5283B44B@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 Thu Jun 19 06:03:11 2003 Return-path: To: "'Yaakov Stein'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5283B44B@exrad2.ad.rad.co.il> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Yaakov, Regarding your claims: a) Cisco, Avaya and Siemens support CESoPSN - that's a big industry statement b) Deployment of 5k links is miniscule compared to what the market will be - the OEMs cannot bind themselves to a messy technical solution and a monopolistic silicon source because of 5k links. c) The interop of Axerra, Redux, Engage, Ericsson shows that this is a working technology d) Just to set thing straight, Redux supports structured and unstructured E1/T1 in working silicon (not as you stated) Uri. -----Original Message----- From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Tuesday, June 17, 2003 9:33 PM To: Danny McPherson; Romascanu, Dan (Dan) Cc: pwe3@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > Really? Can you elaborate on this (i.e., how many other > folks have/are implementing this)? Sasha quotes 4 interoperable implementations, RAD, Redux, Ericsson, and Engage. As I have said in previous emails RAD does NOT support CESoPSN in our standard product line. This "interop" was a one-time effort to supply small remote boxes to interoperate with CESoPSN central site for a given sales opportunity. >From their latest spec sheets, Redux only supports unframed raw bit transport, and thus could only possibly support draft-vainshtein in unstructured E1 mode. Unless they have something new and unpublished, they can't possibly support draft-vainshtein for T1 or in structured modes. I don't know what modes Engage and Ericsson support, but it would be interesting to hear. I am guessing that the Engage implementation (being software on a small processor) is also unstructured, but perhaps Sasha could enlighten us. Incidentally, draft-anavi presently has several interoperable implementations that support unstructured and structured modes, and at least two commercial chip-sets are coming out in the near future. Perhaps Dan is refering to verbal support, rather than actual implementations. So far I see 6:5 in favor of CESoPSN: FOR CESoPSN: 1. Sasha - Axerra 2. Ron Cohen - Lycium 3. Michel Khouderchah - Cisco 4. Uri Rotshtein - Redux 5. Max Riegel - Siemens 6. Dan Romascanu - Avaya AGAINST (i.e. for TDMoIP) 1. Yaakov - RAD 2. Shahram - PMC 3. Alex Conta - TranSwitch 4. Amnon Ilan - Nbase 5. Neil Harrison - BT which is pretty close to 50-50. Since I am going to be issuing an update of draft-anavi, we can go through this again and see what support draft-anavi has - the answer will probably be about the same. Finally, perhaps Dan is refering to deployments. draft-anavi has well over 10,000 deployed ports, many of which have been functioning for several years already. Can we get some figures on active deployments (not betas) from the CESoPSN implementations ? I know that this sounds terribly crass, but don't we deserve to hear if this stuff has really been tested in the field? Y(J)S _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 19 Jun 2003 08:23:21 +0300 Lines: 40 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Thu Jun 19 07:51:34 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcM2F8f/jBLU32e7RQ+Qwjf6qmO1zQACgzNw To: "Rotshtein" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Uri,=20 > Regarding your claims: >=20 > a) Cisco, Avaya and Siemens support CESoPSN - that's a big industry > statement As Max has said to the list several times, Siemens also uses TDMoIP. Regarding Cisco, their business units are independent, and so while one may chose CESoPSN, another may chose TDMoIP. In fact, we too have units being evaluated at Cisco. =20 > b) Deployment of 5k links is miniscule compared to what the=20 > market will be - > the OEMs cannot bind themselves to a messy technical solution and a > monopolistic silicon source because of 5k links. I just checked my calendar, and the year is no longer 2000. We have been hearing about this fantastically large market potential for several years now, I think the time has come for you to prove it. In the meantime, only TDMoIP seems to be selling. > c) The interop of Axerra, Redux, Engage, Ericsson shows that this is a > working technology As I asked before, what modes were tested? If you are talking about simple unstructured, then they will interop with TDMoIP in raw mode as well. > d) Just to set thing straight, Redux supports structured and=20 > unstructured E1/T1 in working silicon (not as you stated). In that case I suggest that you update your marketing literature. Can you send me a new spec sheet? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 19 Jun 2003 09:18:58 +0300 Lines: 20 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Thu Jun 19 08:38:32 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcM2F8f/jBLU32e7RQ+Qwjf6qmO1zQAEWxmQ To: , "Rotshtein" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi everyone,=20 Redux has asked to me to clarify that my information about their chip's capabilities was derived from a "product announcement" and not from a "spec sheet". They have further informed me that the information=20 that I gleaned from their web site,=20 and in their news flashes sent by email, is partial, and therefore potentially misleading. In plain English - I don't have any inside information about their chip. All I know is what they publish. Y(J)S =20 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-fragmentation-02.txt Date: Thu, 19 Jun 2003 07:31:31 -0400 Lines: 79 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 19 14:26:49 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Fragmentation and Reassembly Author(s) : A. Malis, W. Townsley Filename : draft-ietf-pwe3-fragmentation-02.txt Pages : 11 Date : 2003-6-18 This document defines a generalized method of performing fragmentation for use by PWE3 protocols and services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-fragmentation-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-fragmentation-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 19 Jun 2003 06:52:39 -0700 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 Thu Jun 19 15:56:49 2003 Return-path: To: "'Rotshtein'" , "'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 Uri, >d) Just to set thing straight, Redux supports structured and >unstructured >E1/T1 in working silicon (not as you stated) Redux website says: http://www.metroethernetforum.net/apps/org/workgroup/technical "The StelaGate RS-160 is a single chip solution for point-to-point tunneling of unstructured E1/T1/J1 over Ethernet-based and HDLCbased packet links." So obviously this needs correction. BTW is the structured T1/E1 transported in structured mode or unstructured mode? If the former have you tested it in the Interop? Thanks, -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Hamid Ould-Brahim" Subject: RE: status signalling of MPLS PW state Date: Thu, 19 Jun 2003 13:17:58 -0400 Lines: 178 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33686.BB026FC4" Cc: "Andrew G. Malis" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 19 19:21:20 2003 Return-path: To: Luca Martini X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C33686.BB026FC4 Content-Type: text/plain; charset="iso-8859-1" Luca, > yes , i did that , look in the iana draft, it's in there. I > left it in this > thread for discussion only. Okay. I looked at the PW-IANA draft. I think that part needs to be reworked in order to reflect exactly the usage of the status field. In pw-iana draft: " As specified in [1], a new PW status TLV contains a 32 bit field, PW status value 0 is reserved to clear all failures. PW Status Bits 0 through 4 are defined in this document. PW Status Bits 6 through 15 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC2434. PW Status Bits 16 through 23 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC2434. PW Status Bits 24 through 31 are vendor-specific, and values in this range are not to be assigned by IANA. PW status is a 4 octet bit field as follows: 0x00000000 - Pseudo Wire forwarding ( clear all failures ) 0x00000001 - Pseudo Wire Not Forwarding 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault" Since the structure is a bit field and since in that structure some bits/set of bits are reserved. The above codepoints do not exactly reflect the intent. For example, it is not that 0x00000002 that makes the local customer-facing PW receive fault but it is the setting of bit number 1 that indicates this problem is happening. I suggest to layout the bit structure with each bit having its own description. Using the pw-IANA description above (btw I think there is a typo with respect to bit number 5 which appears as 6 in the iana draft), my suggestion is to rewrite the above to: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|I|E|R|T| IANA ASSIGNED | IANA FCFS | VENDOR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N: The "not forwarding bit". When this bit is set, it indicates the PE sending the status is in "not forwarding" state. I: Local Customer-facing PW ( ingress ) Receive Fault E: Local Customer-facing PW ( egress ) Transmit Fault R: Local PSN-facing PW ( ingress ) Receive Fault T: Local PSN-facing PW ( egress ) Transmit Fault A value of 0x00000000 is reserved and indicates that the status of the Pseudo-wire is forwarding. Obviously the NIERT bits can be set independently (and that makes status combination). Hamid. ------_=_NextPart_001_01C33686.BB026FC4 Content-Type: text/html; charset="iso-8859-1"
Luca,
 
> yes , i did that , look in the iana draft, it's in there. I
> left it in this
> thread for discussion only.
Okay. I looked at the PW-IANA draft. I think that part needs
to be reworked in order to reflect exactly the usage of the
status field.
 
In pw-iana draft:
 
"   As specified in [1], a new PW status TLV contains a 32 bit field, PW
   status value 0 is reserved to clear all failures. PW Status Bits 0
   through 4 are defined in this document. PW Status Bits 6 through 15
   are to be assigned by IANA using the "IETF Consensus" policy defined
   in RFC2434. PW Status Bits 16 through 23 are to be assigned by IANA,
   using the "First Come First Served" policy defined in RFC2434. PW
   Status Bits 24 through 31 are vendor-specific, and values in this
   range are not to be assigned by IANA.

   PW status is a 4 octet bit field as follows:

           0x00000000 - Pseudo Wire forwarding ( clear all failures )
           0x00000001 - Pseudo Wire Not Forwarding
           0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
           0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
           0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
           0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault"
 
Since the structure is a bit field and since in that
structure some bits/set of bits are reserved. The above codepoints
do not exactly reflect the intent. For example,
it is not that 0x00000002 that makes the local customer-facing PW
receive fault but it is the setting of bit number 1 that indicates
this problem is happening.
 
I suggest to layout the bit structure with each bit having its own
description. Using the pw-IANA description above (btw I think there is
a typo with respect to bit number 5 which appears as 6 in the iana draft),
my suggestion is to rewrite the above to:
 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|I|E|R|T|  IANA ASSIGNED      |   IANA FCFS   |     VENDOR    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   N: The "not forwarding bit". When this bit is set, it indicates the
      PE sending the status is in "not forwarding" state.
   I: Local Customer-facing PW ( ingress ) Receive Fault
   E: Local Customer-facing PW ( egress ) Transmit Fault
   R: Local PSN-facing PW ( ingress ) Receive Fault
   T: Local PSN-facing PW ( egress ) Transmit Fault

   A value of 0x00000000 is reserved and indicates that the status
   of the Pseudo-wire is forwarding.
 
   Obviously the NIERT bits can be set independently (and that
   makes status combination).
Hamid.

 
------_=_NextPart_001_01C33686.BB026FC4-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: FW: Engage Communication comment on CESoPSN Date: Fri, 20 Jun 2003 11:22:41 -0600 Lines: 35 Sender: pwe3-admin@ietf.org References: <200306201707.h5KH7e630509@mmm2638.sbc-webhosting.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Fri Jun 20 19:24:34 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: In-Reply-To: <200306201707.h5KH7e630509@mmm2638.sbc-webhosting.com> Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O FYI... -danny ------ Forwarded Message From: "Tom Ver Ploeg" Reply-To: "Tom Ver Ploeg" Date: Fri, 20 Jun 2003 13:07:37 -0400 To: danny@tcb.net Cc: mark@engagecom.com Subject: Engage Communication comment on CESoPSN To Danny and the PWE3 WG, Engage Communication has implemented CESoPSN, has proven interoperability with other vendor=B9s equipment and is currently testing at customer locations. We feel it is appropriate that CESoPSN become a PWE3 working group item. I would it appreciate it if you could forward this message to the PWE3 emai= l list. Regards, Tom Ver Ploeg Vice President, Operations Engage Communication, Inc. tverploeg@engagecom.com dir: 831-688-1021 cel: 831-818-5539 ------ End of Forwarded Message From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: RE: FW: Engage Communication comment on CESoPSN Date: Fri, 20 Jun 2003 11:29:48 -0700 Lines: 57 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Fri Jun 20 20:31:40 2003 Return-path: To: "'Danny McPherson'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Danny, I think Sasha mentioned this in his email. -Shahram >-----Original Message----- >From: Danny McPherson [mailto:danny@tcb.net] >Sent: Friday, June 20, 2003 1:23 PM >To: pwe3@ietf.org >Subject: [PWE3] FW: Engage Communication comment on CESoPSN > > > >FYI... > >-danny > >------ Forwarded Message >From: "Tom Ver Ploeg" >Reply-To: "Tom Ver Ploeg" >Date: Fri, 20 Jun 2003 13:07:37 -0400 >To: danny@tcb.net >Cc: mark@engagecom.com >Subject: Engage Communication comment on CESoPSN > >To Danny and the PWE3 WG, > >Engage Communication has implemented CESoPSN, has proven=20 >interoperability >with other vendor=B9s equipment and is currently testing at customer >locations. We feel it is appropriate that CESoPSN become a PWE3 = working >group item. > >I would it appreciate it if you could forward this message to=20 >the PWE3 email >list. > >Regards, >Tom Ver Ploeg > >Vice President, Operations >Engage Communication, Inc. >tverploeg@engagecom.com >dir: 831-688-1021 >cel: 831-818-5539 > > >------ End of Forwarded Message > > >_______________________________________________ >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: "Richard Bell" Subject: Support For Axerra FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Fri, 20 Jun 2003 11:47:51 +0300 Lines: 24 Sender: pwe3-admin@ietf.org Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Sun Jun 22 05:37: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) 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 Dear Danny, I run a large Data Network in Kenya. Our African markets are only just beginning to liberalize. We are confronted with a dilemma of whether to build Broadband Ethernet or Legacy networks. Obviously it makes sense to use Broadband, but many of our customers want legacy services such as Frame Relay and TDM. We have adopted Axerra's technology to overcome the dilemma. We have built a layer 2 Ethernet network, which is cheap and robust and then use Axerra to run legacy services ontop. We have been doing this for some time in Nairobi and it has proved extremely effective. We are now rolling out the technology countrywide. We strongly support Axerra's technology and what they are planning with ietf for CESoIP (under CESoPSN) and hope that you will move into a working document phase with all haste. Once the standard is achieved and chip sets are available our costs will begin to come tumbling down and the technology will then be affordable even in rural areas of Africa. This will have tremendous social and economic benefits on rural communities. Best Regards Richard Bell Managing Director Swift Global Kenya Limited & Kenya Data Networks Limited From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: Support For Axerra FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Sun, 22 Jun 2003 08:05:38 +0300 Lines: 52 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Sun Jun 22 07:08:34 2003 Return-path: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [PWE3] Support For Axerra FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcM4b+n2bBZrfWwrTeqRwjAtI2JAjgAC23+w To: Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Dear Danny, >=20 > I run a large Data Network in Kenya. Our African markets are only just > beginning to liberalize. We are confronted with a dilemma of=20 > whether to build Broadband Ethernet or Legacy networks. Obviously it = > makes sense to use Broadband, but many of our customers want legacy = services=20 > such as Frame Relay and TDM. We have adopted Axerra's technology to=20 > overcome the dilemma. > We have built a layer 2 Ethernet network, which is cheap and=20 > robust and then use Axerra to run legacy services ontop. We have been = doing=20 > this for some time in Nairobi and it has proved extremely effective. = We=20 > are now rolling out the technology countrywide. We strongly support = Axerra's=20 > technology and what they are planning with ietf for CESoIP (under = CESoPSN)=20 > and hope that you will move into a working document phase with all = haste. Once the > standard is achieved and chip sets are available our costs=20 > will begin to come tumbling down and the technology will then be = affordable=20 > even in rural areas of Africa. This will have tremendous social and=20 > economic benefits on rural communities. >=20 > Best Regards > Richard Bell > Managing Director > Swift Global Kenya Limited > & > Kenya Data Networks Limited Danny and PWE'ers, I think this is getting out of hand. I understand our friends in Axerra are interested in showing that they have support, but is generating mail from one-timers the way to show "rough consensus" ? If everyone is realy impressed by forwarded emails and people who show up once and don't answer questions afterwards, I can get each of our several hundred TDMoIP customers to send an email or two. Y(J)S =20 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: richard.spencer@bt.com Subject: RE: Support For Axerra FW: I-D ACTION:draft-vainshtein-ces opsn-06.txt Date: Sun, 22 Jun 2003 10:31:49 +0100 Lines: 92 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 Jun 22 11:33:53 2003 Return-path: To: richard@swiftkenya.com, danny@tcb.net X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Richard, Thank you for the background information into your network and the African economic/social climate. However, I think you may have sent this email to the wrong address. This is an IETF WG mailing list for discussing technical arguments for/against PWE3 protocols/solutions. If your looking for help to improve the social and economic climate in rural areas of Africa, you might try: http://www.oxfam.org.uk/atwork/where/africa/kenya.htm I believe they have had more experience than the IETF in this area, and have already set up a working group to address the issues you have identified. If you did intend to send your email to the PWE3 WG, then the word "legacy" has no place on a technical mailing list. Using the word legacy to describe ATM/FR is just marketing hype. A few years ago when vendors were pushing LANE and ATM to the desktop, they were calling Ethernet legacy, now they are calling ATM/FR legacy! So which is really the legacy protocol: (i) A LAN technology that's over 20 years old *without any* inherent management/OAM functionality, scalable address structure (i.e. routable addresses) or the ability to provide hard QoS guarantees/customer traffic isolation - that's in the process of being retrofitted for the WAN? (ii) A newer WAN technology that *already has* well defined OAM/management/addressing/routing, and provides hard QoS guarantees/customer traffic isolation? I wish you success in helping the rural communities in Africa, and have utmost respect for all individuals committed to work of this nature. Best Regards, Richard > -----Original Message----- > From: Richard Bell [mailto:richard@swiftkenya.com] > Sent: 20 June 2003 09:48 > To: danny@tcb.net > Cc: pwe3@ietf.org > Subject: [PWE3] Support For Axerra FW: I-D > ACTION:draft-vainshtein-cesopsn-06.txt > > > Dear Danny, > > I run a large Data Network in Kenya. Our African markets are > only just > beginning to liberalize. We are confronted with a dilemma > of whether to > build Broadband Ethernet or Legacy networks. Obviously it > makes sense to > use Broadband, but many of our customers want legacy > services such as Frame > Relay and TDM. We have adopted Axerra's technology to > overcome the dilemma. > We have built a layer 2 Ethernet network, which is cheap and > robust and then > use Axerra to run legacy services ontop. We have been doing > this for some > time in Nairobi and it has proved extremely effective. We > are now rolling > out the technology countrywide. We strongly support > Axerra's technology and > what they are planning with ietf for CESoIP (under CESoPSN) > and hope that > you will move into a working document phase with all haste. Once the > standard is achieved and chip sets are available our costs > will begin to > come tumbling down and the technology will then be > affordable even in rural > areas of Africa. This will have tremendous social and > economic benefits on > rural communities. > > Best Regards > Richard Bell > Managing Director > Swift Global Kenya Limited > & > Kenya Data Networks Limited > > > _______________________________________________ > 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: "Andrew G. Malis" Subject: Re: Last Call: draft-ietf-pwe3-arch-04.txt Date: Sun, 22 Jun 2003 09:26:08 -0400 Lines: 53 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_343634720==.ALT" Cc: X-From: pwe3-admin@ietf.org Sun Jun 22 15:27:53 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Danny McPherson X-OriginalArrivalTime: 22 Jun 2003 13:26:21.0211 (UTC) FILETIME=[DEAB2EB0:01C338C1] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --=====================_343634720==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Danny, Section 5.4.4 is premature at this time - see draft-aissaoui-extended-pid-00.txt, which was submitted yesterday and will be coming soon to an Internet Drafts server near you, for a discussion of the issues and a suggested replacement for that text. To speed the architecture draft, it might be better to just remove that section and have a separate document on the topic. Thanks, Andy --------- At 6/17/2003 08:16 AM -0600, Danny McPherson wrote: >Folks, >Consider this a two week Last Call for the PWE3 Architecture document. Last >Call ends on July 1, 2003. Please note that issues recently discussed on >the WG mailing list have been incorporated into this version of the draft. > >-danny --=====================_343634720==.ALT Content-Type: text/html; charset="us-ascii" Danny,

Section 5.4.4 is premature at this time - see draft-aissaoui-extended-pid-00.txt, which was submitted yesterday and will be coming soon to an Internet Drafts server near you, for a discussion of the issues and a suggested replacement for that text.  To speed the architecture draft, it might be better to just remove that section and have a separate document on the topic.

Thanks,
Andy

---------

At 6/17/2003 08:16 AM -0600, Danny McPherson wrote:

Folks,
Consider this a two week Last Call for the PWE3 Architecture document.  Last
Call ends on July 1, 2003.  Please note that issues recently discussed on
the WG mailing list have been incorporated into this version of the draft.

-danny
--=====================_343634720==.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: richard.spencer@bt.com Subject: RE: Support For Axerra FW: I-D ACTION:draft-vainshtein-ces opsn-06.txt Date: Sun, 22 Jun 2003 14:50:52 +0100 Lines: 20 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: richard@swiftkenya.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Sun Jun 22 15:52:52 2003 Return-path: To: L.Wood@eim.surrey.ac.uk X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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) A LAN technology that's over 20 years old *without > > any* inherent management/OAM functionality, scalable > > address structure (i.e. routable addresses) or the > > ability to provide hard QoS guarantees/customer traffic > > isolation - that's in the process of being retrofitted > > for the WAN? > > > > (ii) A newer WAN technology that *already has* well defined > > OAM/management/addressing/routing, and provides hard QoS > > guarantees/customer traffic isolation? > >...which are all lost once layered over PWE3? > >L. Exactly!... Which is something other operators may wish to consider when they start thinking about how they are going to migrate their existing ATM/FR customers over to an MPLS network using a PWE3 solution. Richard From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Re: Support For Axerra FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Sun, 22 Jun 2003 21:45:02 -0600 Lines: 32 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A52DDE013@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Mon Jun 23 05:46:57 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: In-Reply-To: <27A0F290348F8E45AEF79889DDE65A52DDE013@exrad2.ad.rad.co.il> 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 6/21/03 11:05 PM, "Yaakov Stein" wrote: > Danny and PWE'ers, > > I think this is getting out of hand. > > I understand our friends in Axerra are interested in showing > that they have support, but is generating mail from one-timers > the way to show "rough consensus" ? > > If everyone is realy impressed by forwarded emails > and people who show up once and don't answer questions > afterwards, I can get each of our several hundred TDMoIP > customers to send an email or two. I don't recall seeing any posts from frequenters of PWE3 suggesting they're impressed". I also don't think anyone has gauged WG rough consensus at this point. As you well know, this is an open mailing list and if folks have something to post they're welcome to do so (minus the tens of obvious spam messages manually nuked every day) -- it's up to the subscribers to filter as they see fit. If I'm asked to forward something to the list, I'll do so. Personally, yes, I'm well aware of what you're referring to. However, I find the uptick no more pestering than the constant bickering (years now!) on the list between certain parties with vested interests in a particular solution -- you've just got to be capable of taking each message for what it's worth. That said, I'm still very interested in hearing from folks that support a particular solution, for implementation OR deployment reasons. Thanks! -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: richard.spencer@bt.com Subject: RE: Support For Axerra FW: I-D ACTION:draft-vainshtein-ces opsn-06.txt Date: Mon, 23 Jun 2003 09:01:01 +0100 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 Mon Jun 23 10:27:53 2003 Return-path: To: richard@swiftkenya.com, danny@tcb.net X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Apologies for my previous post... English sarcasm at its worst. Richard > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: 22 June 2003 10:32 > To: richard@swiftkenya.com; danny@tcb.net > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Support For Axerra FW: I-D > ACTION:draft-vainshtein-cesopsn-06.txt > > > Richard, > > Thank you for the background information into your network > and the African > economic/social climate. However, I think you may have sent > this email to > the wrong address. This is an IETF WG mailing list for > discussing technical > arguments for/against PWE3 protocols/solutions. > > If your looking for help to improve the social and economic > climate in rural > areas of Africa, you might try: > > http://www.oxfam.org.uk/atwork/where/africa/kenya.htm > > I believe they have had more experience than the IETF in > this area, and have > already set up a working group to address the issues you > have identified. > > If you did intend to send your email to the PWE3 WG, then > the word "legacy" > has no place on a technical mailing list. Using the word > legacy to describe > ATM/FR is just marketing hype. A few years ago when vendors > were pushing > LANE and ATM to the desktop, they were calling Ethernet > legacy, now they are > calling ATM/FR legacy! > > So which is really the legacy protocol: > > (i) A LAN technology that's over 20 years old *without any* inherent > management/OAM functionality, scalable address structure > (i.e. routable > addresses) or the ability to provide hard QoS > guarantees/customer traffic > isolation - that's in the process of being retrofitted for the WAN? > > (ii) A newer WAN technology that *already has* well defined > OAM/management/addressing/routing, and provides hard QoS > guarantees/customer > traffic isolation? > > I wish you success in helping the rural communities in > Africa, and have > utmost respect for all individuals committed to work of this nature. > > Best Regards, > > Richard > > > -----Original Message----- > > From: Richard Bell [mailto:richard@swiftkenya.com] > > Sent: 20 June 2003 09:48 > > To: danny@tcb.net > > Cc: pwe3@ietf.org > > Subject: [PWE3] Support For Axerra FW: I-D > > ACTION:draft-vainshtein-cesopsn-06.txt > > > > > > Dear Danny, > > > > I run a large Data Network in Kenya. Our African markets are > > only just > > beginning to liberalize. We are confronted with a dilemma > > of whether to > > build Broadband Ethernet or Legacy networks. Obviously it > > makes sense to > > use Broadband, but many of our customers want legacy > > services such as Frame > > Relay and TDM. We have adopted Axerra's technology to > > overcome the dilemma. > > We have built a layer 2 Ethernet network, which is cheap and > > robust and then > > use Axerra to run legacy services ontop. We have been doing > > this for some > > time in Nairobi and it has proved extremely effective. We > > are now rolling > > out the technology countrywide. We strongly support > > Axerra's technology and > > what they are planning with ietf for CESoIP (under CESoPSN) > > and hope that > > you will move into a working document phase with all > haste. Once the > > standard is achieved and chip sets are available our costs > > will begin to > > come tumbling down and the technology will then be > > affordable even in rural > > areas of Africa. This will have tremendous social and > > economic benefits on > > rural communities. > > > > Best Regards > > Richard Bell > > Managing Director > > Swift Global Kenya Limited > > & > > Kenya Data Networks Limited > > > > > > _______________________________________________ > > 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: "Andrew G. Malis" Subject: Re: Last Call: draft-ietf-pwe3-arch-04.txt Date: Sun, 22 Jun 2003 07:17:49 -0400 Lines: 53 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_335938644==.ALT" Cc: X-From: pwe3-admin@ietf.org Mon Jun 23 12:02:51 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Danny McPherson X-OriginalArrivalTime: 22 Jun 2003 11:18:01.0357 (UTC) FILETIME=[F132B3D0:01C338AF] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --=====================_335938644==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Danny, Section 5.4.4 is premature at this time - see draft-aissaoui-extended-pid-00.txt, which was submitted yesterday and will be coming soon to an Internet Drafts server near you, for a discussion of the issues and a suggested replacement for that text. To speed the architecture draft, it might be better to just remove that section and have a separate document on the topic. Thanks, Andy --------- At 6/17/2003 08:16 AM -0600, Danny McPherson wrote: >Folks, >Consider this a two week Last Call for the PWE3 Architecture document. Last >Call ends on July 1, 2003. Please note that issues recently discussed on >the WG mailing list have been incorporated into this version of the draft. > >-danny --=====================_335938644==.ALT Content-Type: text/html; charset="us-ascii" Danny,

Section 5.4.4 is premature at this time - see draft-aissaoui-extended-pid-00.txt, which was submitted yesterday and will be coming soon to an Internet Drafts server near you, for a discussion of the issues and a suggested replacement for that text.  To speed the architecture draft, it might be better to just remove that section and have a separate document on the topic.

Thanks,
Andy

---------

At 6/17/2003 08:16 AM -0600, Danny McPherson wrote:

Folks,
Consider this a two week Last Call for the PWE3 Architecture document.  Last
Call ends on July 1, 2003.  Please note that issues recently discussed on
the WG mailing list have been incorporated into this version of the draft.

-danny
--=====================_335938644==.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Nurit Sprecher Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Sun, 22 Jun 2003 10:18:51 +0200 Lines: 20 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-From: pwe3-admin@ietf.org Mon Jun 23 12:02:52 2003 Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, I have been passively following the debate over draft-vainshtein vs. draft-anavi for some time, and still don't understand one thing. draft-anavi uses techniques borrowed from ATM, in order to maintain compatibility to existing CES systems. It thus a pointer to maintains frame alignment. draft-vainshtein maintains TDM frame alignment by always sending an integral number of frames in a packet. Why do we need to maintain frame alignment at all? >From the TDM reconstruction point of view, all we need is to play out the bits that are in the receive buffer, and the TDM switch will take care of all the rest. If a packet is lost, all we need to know is how many bits it contained - so all we need is to have a constant size packet!1 I vote against accepting draft-vainshtein. For the unstructured case we need a simpler method - just constant size packets! For those complex cases where we need structured (especially with CAS) we might as well use draft-anavi. Nurit. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Amihay Shamay Subject: IETF support Date: Sun, 22 Jun 2003 12:23:51 +0200 Lines: 27 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: "'pwe3@ietf.org'" X-From: pwe3-admin@ietf.org Mon Jun 23 12:02:53 2003 Return-path: To: "'danny@tcb.net'" 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 Dear College, Barak has tested the structured and unstructured E1 circuit emulation service (CESoPSN based on draft-vainshtein) in its international IP network. We were very pleased with the results and the performance achieved. One of the advantages of CESoPSN we found important is the ability to design circuits while keeping packetization delay independent from the number of DS0s in the bundle. Following our experience, with AXERRA's products we would like to support the acceptance of draft-vainshtein as WG document as a basis to further discussions in the working group towards a WG solution. Best Regards, Amihay Shamay Manager, Transmission Barak ITC Tel.:+972 3 9001077 Fax.:+972 3 9001090 Mobile:+972 54 841077 e-mail:ashamay@barak013.net.il Web site:www.Barak.net.il From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: richard.spencer@bt.com Subject: RE: Africa's Renaissance is coming so stop patronizing me [PWE3] Support For Axerra FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 23 Jun 2003 11:45:01 +0100 Lines: 193 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 23 12:46:49 2003 Return-path: To: richard@swiftkenya.com, danny@tcb.net X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Richard, Please accept my sincere apologies for my previous post as it was not intended to be patronising. It was simply a sarcastic email (written in haste) to state that comments for/against drafts should be technical not social. Your reasons for supporting the draft based on standardisation lowering costs apply to any standard. It is well known and widely accepted that standardisation helps to drive down costs, this is true whichever part of the world you are from and therefore IMHO has no relevance. Richard > -----Original Message----- > From: Richard Bell [mailto:richard@swiftkenya.com] > Sent: 23 June 2003 11:11 > To: Spencer,R,Richard,XGH5 R; danny@tcb.net > Cc: pwe3@ietf.org > Subject: Africa's Renaissance is coming so stop patronizing > me [PWE3] Support For Axerra FW: I-D > ACTION:draft-vainshtein-cesopsn-06.txt > > > I'm a businessman not a techy. Inevitably there will be times when > terminologies I use will be incorrect, however the substance > of my mail is > that decisions made by technical working groups inevitably > impact on the > ability of businesses to rollout networks cost effectively. > My input to > your mailing list is that we strongly support what Axerra > are doing and are > eager to see this technology become a standard for the > following reasons: > > 1. If it becomes a standard it will drive down production costs and > therefore end user prices for purchasing this equipment. > > 2. The combination of using this technology together with native IP > wireless technologies will allow us to deliver a full range of data > connectivity solutions into rural areas of Africa where > otherwise it would > not be commercially viable to do so. > > Your rather patronizing references to Oxfams activities > clearly implies that > you are from the school of thought that believes that "you > Africans should > continue herding goats, while today's real technologies and > standards should > be geared towards the needs of Europe and North America". I > sincerely hope > that the same attitude is not shared by the rest of your > colleagues on the > list, since it is just that attitude which is deepening the > digital divide > between north and south. > > You can argue semantics and technologies all day long. I > could equally give > you 20 pages (non patronizing) about the commercial > realities of building > data communications networks in rural Africa. My message to > the rest of the > ietf list is that standards should be developed for > everyone, including > developing countries, and this particular technology can > really help us > rollout digital data communications networks into rural > areas of Africa. > > Richard Bell > > > -----Original Message----- > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > Sent: 22 June 2003 12:32 > To: richard@swiftkenya.com; danny@tcb.net > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Support For Axerra FW: I-D > ACTION:draft-vainshtein-cesopsn-06.txt > > > Richard, > > Thank you for the background information into your network > and the African > economic/social climate. However, I think you may have sent > this email to > the wrong address. This is an IETF WG mailing list for > discussing technical > arguments for/against PWE3 protocols/solutions. > > If your looking for help to improve the social and economic > climate in rural > areas of Africa, you might try: > > http://www.oxfam.org.uk/atwork/where/africa/kenya.htm > > I believe they have had more experience than the IETF in > this area, and have > already set up a working group to address the issues you > have identified. > > If you did intend to send your email to the PWE3 WG, then > the word "legacy" > has no place on a technical mailing list. Using the word > legacy to describe > ATM/FR is just marketing hype. A few years ago when vendors > were pushing > LANE and ATM to the desktop, they were calling Ethernet > legacy, now they are > calling ATM/FR legacy! > > So which is really the legacy protocol: > > (i) A LAN technology that's over 20 years old *without any* inherent > management/OAM functionality, scalable address structure > (i.e. routable > addresses) or the ability to provide hard QoS > guarantees/customer traffic > isolation - that's in the process of being retrofitted for the WAN? > > (ii) A newer WAN technology that *already has* well defined > OAM/management/addressing/routing, and provides hard QoS > guarantees/customer > traffic isolation? > > I wish you success in helping the rural communities in > Africa, and have > utmost respect for all individuals committed to work of this nature. > > Best Regards, > > Richard > > > -----Original Message----- > > From: Richard Bell [mailto:richard@swiftkenya.com] > > Sent: 20 June 2003 09:48 > > To: danny@tcb.net > > Cc: pwe3@ietf.org > > Subject: [PWE3] Support For Axerra FW: I-D > > ACTION:draft-vainshtein-cesopsn-06.txt > > > > > > Dear Danny, > > > > I run a large Data Network in Kenya. Our African markets are > > only just > > beginning to liberalize. We are confronted with a dilemma > > of whether to > > build Broadband Ethernet or Legacy networks. Obviously it > > makes sense to > > use Broadband, but many of our customers want legacy > > services such as Frame > > Relay and TDM. We have adopted Axerra's technology to > > overcome the dilemma. > > We have built a layer 2 Ethernet network, which is cheap and > > robust and then > > use Axerra to run legacy services ontop. We have been doing > > this for some > > time in Nairobi and it has proved extremely effective. We > > are now rolling > > out the technology countrywide. We strongly support > > Axerra's technology and > > what they are planning with ietf for CESoIP (under CESoPSN) > > and hope that > > you will move into a working document phase with all > haste. Once the > > standard is achieved and chip sets are available our costs > > will begin to > > come tumbling down and the technology will then be > > affordable even in rural > > areas of Africa. This will have tremendous social and > > economic benefits on > > rural communities. > > > > Best Regards > > Richard Bell > > Managing Director > > Swift Global Kenya Limited > > & > > Kenya Data Networks Limited > > > > > > _______________________________________________ > > 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: Sasha Vainshtein Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 23 Jun 2003 14:59:02 +0200 Lines: 41 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: "'pwe3@ietf.org'" X-From: pwe3-admin@ietf.org Mon Jun 23 14:22:14 2003 Return-path: To: "'Nurit Sprecher'" 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 Nurit and all, ... snipped ... > > Why do we need to maintain frame alignment at all? > draft-vainshtein DOES NOT maintain "frame alignment for UNSTRUCTURED services - pease see Section 6.3.1. "Frame alignment" across the PW MUST be provided for STRUCTURED (Nx64 kbit/s with and without CAS) services. The reason: once the PW has been terminated at the egress PE, separate 64 kbit/s channels in the bundle may go to different destinations in the access TDM network. This happens even if the "access TDM network" is represented by a single P2P CE<-->PE TDM trunk. > ... snipped ... > > If a packet is lost, all we need to know is how many bits it > contained - so all we need is to have a constant size packet! > This is EXACTLY what draft-vainshtein (Section 3.2.3) specifies as an explicit requirement. And this requirement is satisfied by the solution proposed in the draft. ... snipped ... > > For the unstructured case we need a simpler method - just > constant size packets! > This is EXACTLY what draft-vainsthein says (please read Section 6.3.1). I suggest you re-read draft-vainshtein. I will be happy to answer your specific questions/suggestions after that. > ... snipped ... > > Nurit. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 23 Jun 2003 15:33:22 +0300 Lines: 76 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Mon Jun 23 14:34:49 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcM5gldrfisqiwg2Rqu7Z8kmkd6TjgAAOHvw To: "Alexander Vainshtein" , "Nurit Sprecher" Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha,=20 I think that Nurit has a point. Can you explain in simple terms why=20 you need to have packet payload's of=20 multiples of 125 microseconds? If there is no packet loss any number of bytes per packet is properly reproduced. If there is packet loss, as long as I know=20 how many bytes are sent in each packet I can send the proper amount of interpolation data, and the TDM interface is happy. Y(J)S > -----Original Message----- > From: Alexander Vainshtein=20 > Sent: Monday, June 23, 2003 3:59 PM > To: 'Nurit Sprecher' > Cc: 'pwe3@ietf.org' > Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt >=20 >=20 > Nurit and all, > ... snipped ... > > > > Why do we need to maintain frame alignment at all? > > > draft-vainshtein DOES NOT maintain "frame alignment for=20 > UNSTRUCTURED services - pease see Section 6.3.1. > "Frame alignment" across the PW MUST be provided for STRUCTURED > (Nx64 kbit/s with and without CAS) services. The reason:=20 > once the PW has been terminated at the egress PE, separate > 64 kbit/s channels in the bundle may go to different destinations=20 > in the access TDM network. This happens even if the "access=20 > TDM network"=20 > is represented by a single P2P CE<-->PE TDM trunk.=20 > > > ... snipped ... > > > > If a packet is lost, all we need to know is how many bits it=20 > > contained - so all we need is to have a constant size packet! > > > This is EXACTLY what draft-vainshtein (Section 3.2.3) specifies > as an explicit requirement. And this requirement is satisfied=20 > by the solution proposed in the draft. > ... snipped ... > >=20 > > For the unstructured case we need a simpler method - just=20 > > constant size packets! > > > This is EXACTLY what draft-vainsthein says (please read=20 > Section 6.3.1). >=20 > I suggest you re-read draft-vainshtein. I will be happy to=20 > answer your specific questions/suggestions after that. > > > ... snipped ... > > > > Nurit. > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: IETF support Date: Mon, 23 Jun 2003 15:39:27 +0300 Lines: 25 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Mon Jun 23 14:41:22 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] IETF support Thread-Index: AcM5bwnRNZg9IxYkQAKFMaBNhD9oUAAFP66w To: "Amihay Shamay" , Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Dear College, (I know we are smart, but wasn't aware that we had the academic = credentials) >=20 > Barak has tested the structured and unstructured E1 circuit emulation > service (CESoPSN based on draft-vainshtein)=20 > in its international IP network. >=20 > We were very pleased with the results and the performance achieved. Great - real world data! Can you give us some information on the timing scenario? Can you tell us what packet loss and PDV you had? > One of the advantages of CESoPSN we found important is the=20 > ability to design circuits while keeping packetization delay=20 > independent from the number of DS0s in the bundle. Can you explain this ? Why do you care what the packetization delay is? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Richard Bell" Subject: Africa's Renaissance is coming so stop patronizing me Support For Axerra FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 23 Jun 2003 13:10:30 +0300 Lines: 134 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-8" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Mon Jun 23 15:09:53 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: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I'm a businessman not a techy. Inevitably there will be times when terminologies I use will be incorrect, however the substance of my mail is that decisions made by technical working groups inevitably impact on the ability of businesses to rollout networks cost effectively. My input to your mailing list is that we strongly support what Axerra are doing and are eager to see this technology become a standard for the following reasons: 1. If it becomes a standard it will drive down production costs and therefore end user prices for purchasing this equipment. 2. The combination of using this technology together with native IP wireless technologies will allow us to deliver a full range of data connectivity solutions into rural areas of Africa where otherwise it would not be commercially viable to do so. Your rather patronizing references to Oxfams activities clearly implies that you are from the school of thought that believes that "you Africans should continue herding goats, while today's real technologies and standards should be geared towards the needs of Europe and North America". I sincerely hope that the same attitude is not shared by the rest of your colleagues on the list, since it is just that attitude which is deepening the digital divide between north and south. You can argue semantics and technologies all day long. I could equally give you 20 pages (non patronizing) about the commercial realities of building data communications networks in rural Africa. My message to the rest of the ietf list is that standards should be developed for everyone, including developing countries, and this particular technology can really help us rollout digital data communications networks into rural areas of Africa. Richard Bell -----Original Message----- From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] Sent: 22 June 2003 12:32 To: richard@swiftkenya.com; danny@tcb.net Cc: pwe3@ietf.org Subject: RE: [PWE3] Support For Axerra FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Richard, Thank you for the background information into your network and the African economic/social climate. However, I think you may have sent this email to the wrong address. This is an IETF WG mailing list for discussing technical arguments for/against PWE3 protocols/solutions. If your looking for help to improve the social and economic climate in rural areas of Africa, you might try: http://www.oxfam.org.uk/atwork/where/africa/kenya.htm I believe they have had more experience than the IETF in this area, and have already set up a working group to address the issues you have identified. If you did intend to send your email to the PWE3 WG, then the word "legacy" has no place on a technical mailing list. Using the word legacy to describe ATM/FR is just marketing hype. A few years ago when vendors were pushing LANE and ATM to the desktop, they were calling Ethernet legacy, now they are calling ATM/FR legacy! So which is really the legacy protocol: (i) A LAN technology that's over 20 years old *without any* inherent management/OAM functionality, scalable address structure (i.e. routable addresses) or the ability to provide hard QoS guarantees/customer traffic isolation - that's in the process of being retrofitted for the WAN? (ii) A newer WAN technology that *already has* well defined OAM/management/addressing/routing, and provides hard QoS guarantees/customer traffic isolation? I wish you success in helping the rural communities in Africa, and have utmost respect for all individuals committed to work of this nature. Best Regards, Richard > -----Original Message----- > From: Richard Bell [mailto:richard@swiftkenya.com] > Sent: 20 June 2003 09:48 > To: danny@tcb.net > Cc: pwe3@ietf.org > Subject: [PWE3] Support For Axerra FW: I-D > ACTION:draft-vainshtein-cesopsn-06.txt > > > Dear Danny, > > I run a large Data Network in Kenya. Our African markets are > only just > beginning to liberalize. We are confronted with a dilemma > of whether to > build Broadband Ethernet or Legacy networks. Obviously it > makes sense to > use Broadband, but many of our customers want legacy > services such as Frame > Relay and TDM. We have adopted Axerra's technology to > overcome the dilemma. > We have built a layer 2 Ethernet network, which is cheap and > robust and then > use Axerra to run legacy services ontop. We have been doing > this for some > time in Nairobi and it has proved extremely effective. We > are now rolling > out the technology countrywide. We strongly support > Axerra's technology and > what they are planning with ietf for CESoIP (under CESoPSN) > and hope that > you will move into a working document phase with all haste. Once the > standard is achieved and chip sets are available our costs > will begin to > come tumbling down and the technology will then be > affordable even in rural > areas of Africa. This will have tremendous social and > economic benefits on > rural communities. > > Best Regards > Richard Bell > Managing Director > Swift Global Kenya Limited > & > Kenya Data Networks Limited > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Stewart Bryant Subject: Re: RE: Africa's Renaissance is coming so stop patronizing me [PWE3] Support For Axerra FW: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 23 Jun 2003 14:19:37 +0100 Organization: Cisco Systems, Inc. Lines: 210 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-8; format=flowed Content-Transfer-Encoding: 7bit Cc: richard@swiftkenya.com, danny@tcb.net, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 23 15:23:11 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: richard.spencer@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 Our mandate as part of the IETF is to generate the pseudo-wire solution that is best for the Internet Please can we stop this political/business thread, focus on the relative technical merits of the proposed solutions. Stewart richard.spencer@bt.com wrote: > Richard, > > Please accept my sincere apologies for my previous post as it was not > intended to be patronising. It was simply a sarcastic email (written in > haste) to state that comments for/against drafts should be technical not > social. > > Your reasons for supporting the draft based on standardisation lowering > costs apply to any standard. It is well known and widely accepted that > standardisation helps to drive down costs, this is true whichever part of > the world you are from and therefore IMHO has no relevance. > > Richard > > > -----Original Message----- > > From: Richard Bell [mailto:richard@swiftkenya.com] > > Sent: 23 June 2003 11:11 > > To: Spencer,R,Richard,XGH5 R; danny@tcb.net > > Cc: pwe3@ietf.org > > Subject: Africa's Renaissance is coming so stop patronizing > > me [PWE3] Support For Axerra FW: I-D > > ACTION:draft-vainshtein-cesopsn-06.txt > > > > > > I'm a businessman not a techy. Inevitably there will be times when > > terminologies I use will be incorrect, however the substance > > of my mail is > > that decisions made by technical working groups inevitably > > impact on the > > ability of businesses to rollout networks cost effectively. > > My input to > > your mailing list is that we strongly support what Axerra > > are doing and are > > eager to see this technology become a standard for the > > following reasons: > > > > 1. If it becomes a standard it will drive down production costs and > > therefore end user prices for purchasing this equipment. > > > > 2. The combination of using this technology together with native IP > > wireless technologies will allow us to deliver a full range of data > > connectivity solutions into rural areas of Africa where > > otherwise it would > > not be commercially viable to do so. > > > > Your rather patronizing references to Oxfams activities > > clearly implies that > > you are from the school of thought that believes that "you > > Africans should > > continue herding goats, while today's real technologies and > > standards should > > be geared towards the needs of Europe and North America". I > > sincerely hope > > that the same attitude is not shared by the rest of your > > colleagues on the > > list, since it is just that attitude which is deepening the > > digital divide > > between north and south. > > > > You can argue semantics and technologies all day long. I > > could equally give > > you 20 pages (non patronizing) about the commercial > > realities of building > > data communications networks in rural Africa. My message to > > the rest of the > > ietf list is that standards should be developed for > > everyone, including > > developing countries, and this particular technology can > > really help us > > rollout digital data communications networks into rural > > areas of Africa. > > > > Richard Bell > > > > > > -----Original Message----- > > From: richard.spencer@bt.com [mailto:richard.spencer@bt.com] > > Sent: 22 June 2003 12:32 > > To: richard@swiftkenya.com; danny@tcb.net > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] Support For Axerra FW: I-D > > ACTION:draft-vainshtein-cesopsn-06.txt > > > > > > Richard, > > > > Thank you for the background information into your network > > and the African > > economic/social climate. However, I think you may have sent > > this email to > > the wrong address. This is an IETF WG mailing list for > > discussing technical > > arguments for/against PWE3 protocols/solutions. > > > > If your looking for help to improve the social and economic > > climate in rural > > areas of Africa, you might try: > > > > http://www.oxfam.org.uk/atwork/where/africa/kenya.htm > > > > I believe they have had more experience than the IETF in > > this area, and have > > already set up a working group to address the issues you > > have identified. > > > > If you did intend to send your email to the PWE3 WG, then > > the word "legacy" > > has no place on a technical mailing list. Using the word > > legacy to describe > > ATM/FR is just marketing hype. A few years ago when vendors > > were pushing > > LANE and ATM to the desktop, they were calling Ethernet > > legacy, now they are > > calling ATM/FR legacy! > > > > So which is really the legacy protocol: > > > > (i) A LAN technology that's over 20 years old *without any* inherent > > management/OAM functionality, scalable address structure > > (i.e. routable > > addresses) or the ability to provide hard QoS > > guarantees/customer traffic > > isolation - that's in the process of being retrofitted for the WAN? > > > > (ii) A newer WAN technology that *already has* well defined > > OAM/management/addressing/routing, and provides hard QoS > > guarantees/customer > > traffic isolation? > > > > I wish you success in helping the rural communities in > > Africa, and have > > utmost respect for all individuals committed to work of this nature. > > > > Best Regards, > > > > Richard > > > > > -----Original Message----- > > > From: Richard Bell [mailto:richard@swiftkenya.com] > > > Sent: 20 June 2003 09:48 > > > To: danny@tcb.net > > > Cc: pwe3@ietf.org > > > Subject: [PWE3] Support For Axerra FW: I-D > > > ACTION:draft-vainshtein-cesopsn-06.txt > > > > > > > > > Dear Danny, > > > > > > I run a large Data Network in Kenya. Our African markets are > > > only just > > > beginning to liberalize. We are confronted with a dilemma > > > of whether to > > > build Broadband Ethernet or Legacy networks. Obviously it > > > makes sense to > > > use Broadband, but many of our customers want legacy > > > services such as Frame > > > Relay and TDM. We have adopted Axerra's technology to > > > overcome the dilemma. > > > We have built a layer 2 Ethernet network, which is cheap and > > > robust and then > > > use Axerra to run legacy services ontop. We have been doing > > > this for some > > > time in Nairobi and it has proved extremely effective. We > > > are now rolling > > > out the technology countrywide. We strongly support > > > Axerra's technology and > > > what they are planning with ietf for CESoIP (under CESoPSN) > > > and hope that > > > you will move into a working document phase with all > > haste. Once the > > > standard is achieved and chip sets are available our costs > > > will begin to > > > come tumbling down and the technology will then be > > > affordable even in rural > > > areas of Africa. This will have tremendous social and > > > economic benefits on > > > rural communities. > > > > > > Best Regards > > > Richard Bell > > > Managing Director > > > Swift Global Kenya Limited > > > & > > > Kenya Data Networks Limited > > > > > > > > > _______________________________________________ > > > 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: Akiva Sadovski Subject: RE: I-D ACTION:draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt Date: Mon, 23 Jun 2003 16:35:12 +0200 Lines: 87 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 23 15:46:43 2003 Return-path: To: "'luca@level3.net'" , "'Andy.Malis@vivacenetworks.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 Luca and Andy, the draft is OK, but: almost all L2 encapsulations define 2 modes, f.ex. the FR encap: * 1:1 mode that strips FR headers, is mandatory and is the only mode that can be used in conjunction with MPLS PSN * N:1 mode that carries FR headers, and is optional over IP PSN Should we define the same 2 modes for the HDLC-over-MPLS, e.g. to permit address/control/protocol fields stripping at the ingress with possible attachment of a different address(/control/protocol ?) at the egress ? However i doubt there's a need in such functionality, but ... maybe ... to align all L2 drafts... Best, Akiva. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, June 17, 2003 1:57 PM > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Pseudo Wire Emulation Edge > to Edge Working Group of the IETF. > > Title : Encapsulation Methods for Transport > of PPP/HDLC Frames > Over IP and MPLS Networks > Author(s) : L. Martini et al. > Filename : draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt > Pages : 10 > Date : 2003-6-16 > > A Pseudowire (PW) can be used to carry PPP, or HDLC Protocol Data > Units over an IP or MPLS network without terminating the PPP/HDLC > protocol. This enables service providers to offer 'emulated' HDLC, or > PPP link services over existing IP or MPLS networks. This document > specifies the encapsulation of PPP/HDLC PDUs within a pseudowire. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-e > ncap-mpls-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Amnon Ilan" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 23 Jun 2003 17:23:57 +0200 Lines: 65 Sender: pwe3-admin@ietf.org References: Reply-To: X-From: pwe3-admin@ietf.org Mon Jun 23 16:26:29 2003 Return-path: To: "'Nurit Sprecher'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, I agree with Nurit that there is no need for the CESoPSN draft. We can have only two basic solutions: 1. The simple (simplistic) one: unstructured bitstream. 2. The more sophisticated one: TDMoIP. The simple approach is limited since it requires a very good PSN (very low packet loss and PDV): small frame loss may cause the loss of frame alignment (and many E1\T1 applications are not robust enough to minimize the effect of such a problem). This approach is also very sensitive to loss of timing synchronization. However, it is simple, easy to implement, and may be used on cases where the PSN is good enough, or when the E1\T1 line itself is unstructured. The more sophisticated approach is much more robust: having framers at the edge prevents loss of frame alignment (the effect of corrupted data inside some of the time-slots is much less severe then the one caused by loss of frame alignment). The structured modes of both TDMoIP and CESoPSN address these issues. However, IMO, TDMoIP is much more comprehensive: for example see the issue of silence suppression. Most of E1\T1 lines are voice trunks and for such trunks silence suppression may save more then 50% of network traffic. The only way to support silence suppression is by using the AAL2 mode of TDMoIP. That is to add on the issues of market acceptance and chances for compatible standards (ITU, MPLS-Forum) mentioned in my previous email. Amnon. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Nurit Sprecher Sent: Sun 22 June 2003 10:19 To: 'pwe3@ietf.org' Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I have been passively following the debate over draft-vainshtein vs. draft-anavi for some time, and still don't understand one thing. draft-anavi uses techniques borrowed from ATM, in order to maintain compatibility to existing CES systems. It thus a pointer to maintains frame alignment. draft-vainshtein maintains TDM frame alignment by always sending an integral number of frames in a packet. Why do we need to maintain frame alignment at all? >From the TDM reconstruction point of view, all we need is to play out the bits that are in the receive buffer, and the TDM switch will take care of all the rest. If a packet is lost, all we need to know is how many bits it contained - so all we need is to have a constant size packet!1 I vote against accepting draft-vainshtein. For the unstructured case we need a simpler method - just constant size packets! For those complex cases where we need structured (especially with CAS) we might as well use draft-anavi. Nurit. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: What I like about draft-vainshtein-cesopsn-06 Date: Mon, 23 Jun 2003 17:34:02 +0300 Lines: 53 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Mon Jun 23 16:36:08 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Thread-Index: AcM5gldrfisqiwg2Rqu7Z8kmkd6TjgADtFcw To: "Alexander Vainshtein" , Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I bet that subject line really got your attention! Seriously now, I think that the latest version has some very good features. We have the option to send T1s without padding (although we have to minor the minor price of 1 milli delay) We finally have the option of suppressing RTP when it is not needed (e.g. when both sides have good clocking). I have thinking about this development for the past few days, and believe we now have enough overlap between CESoPSN, TDMoIP and simple raw bit-stream implementations, to make a mode that everyone can accept. I call this mode STPP for "Simple TDM Pseudowire Protocol". Its basic definition is simple : 1) no RTP (it's only for simple cases where clock is available) 2) unstructured (no bit or byte alignment implied) 3) default packet size T1: 8 frames (193 bytes) E1: 4 frames (128 bytes) E3: 1 frame (537 bytes) T3: 1 frame (699 bytes) MUST be supported, but ANY length may be used if both sides agree.=20 In particular, for interworking with existing=20 CES networks n*47 MAY be used. This may not solve all TDM problems, but it solves a good fraction of them -=20 at least all those where we can assume loop-back timing at the ends=20 and very low packet loss and packet delay variation. I haven't had much time to discuss this with the sword of the IETF draft-xxx-00 deadline over my head, but Amnon from MRV was kind enough to help me with writing up a draft, and several others, notably Alex from TranSwitch, have contributed as well. Until it makes it to the IETF site you can see the STPP draft at=20 http://www.dspcsp.com/tdmoip/draft-stein-pwe3-stpp-00.txt (Technical) comments are welcome. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Shahram Davari Subject: STPP draft Date: Mon, 23 Jun 2003 08:33:28 -0700 Lines: 7 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-From: pwe3-admin@ietf.org Mon Jun 23 17:38:52 2003 Return-path: To: "'Yaakov Stein'" , 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 Yaakov, STPP looks like a very simple and yet powerfull mechanism that would satisfy majority of the applications, and is compatible with Martini CW too. Yours, -Shahram From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 23 Jun 2003 19:30:35 +0200 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Jun 23 18:36:59 2003 Return-path: To: "'Yaakov Stein'" , Nurit Sprecher 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, ... snipped ... > > Sasha, > > Can you explain in simple terms why > you need to have packet payload's of > multiples of 125 microseconds? > For UNSTRUCTURED services, the draft explicitly allows ANY(!) packet latency. Since the WG has decided that a mandatory default MUST be defined, the draft specifies such a default on a per service basis. The default chosen in the draft carries, IMO, some added value. As YOU have taught the WG some time ago, the egress IWF of an unstructured TDM PW must preserve correct FAS to avoid the TDM CE interface to declare an OOF (or AIS) condition due to loss of a single PW packet. (Low-end E1 framers are more sensitive in this regard). Since FAS is periodic, packet latency that is a multiple of the FAS period, makes this task TRIVIAL while using other packet latencies makes this task DIFFICULT. For STRUCTURED services the answer is different - please see Section 6.2 of the draft. Let's try not to mix these two cases (structured vs unstructured). They are different. ... snipped to the end ... Regards, Sasha From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Sasha Vainshtein Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Mon, 23 Jun 2003 19:37:10 +0200 Lines: 20 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Mon Jun 23 18:46:14 2003 Return-path: To: "'ailan@mrv.com'" , "'Nurit Sprecher'" , 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 Ilan, > ... snipped ... > We can have only two basic solutions: > 1. The simple (simplistic) one: unstructured bitstream. > The CESoPSN draft does exactly that for unstructured services. In addition it solves the problem of packet loss and facilitates high-quality clock recovery when necessary. > > 2. The more sophisticated one: TDMoIP. > The idea to have two absolutely different approaches for structured and unstructured services has been discussed by the WG and rejected in the past. > ... snipped to the end ... > With best regards, Sasha Vainshtein From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Alik Shimelmits Subject: RE: What I like about draft-vainshtein-cesopsn-06 Date: Mon, 23 Jun 2003 20:47:46 +0200 Lines: 39 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-From: pwe3-admin@ietf.org Mon Jun 23 19:53:21 2003 Return-path: To: Yaakov Stein , Sasha Vainshtein , 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 Yaakov, I understand that you are OK with the CESoPSN approach with regard to emulation of unstructured services and your objections are limited to emulation of structured services. Thanks for clarifying your position. Somehow I am not surprised since you are one of the co-editors of the old draft-vainshtein-pwe3-ucesopsn-00.txt (still available at the IETF Web site) that is almost identical to the STTP proposal and has been incorporated with minimal changes into CESoPSN-06. To the best of my understanding the technical differences between CESoPSN-06 and STTP drafts are limited to the following: 1. The STTP draft does not allow RTP header, while the CESoPSN one introduces it but allows to suppress it if both sides agree. Functionally this means that the CESoPSN draft supports more synchronization scenarios at no cost. 2. The CW of the two drafts differs wrt bit positions and the size of the sequence number. 3. CESoPSN defines the mandatory packet delay for E1 as 1 ms, STTP reduces it to 0.5 ms. It also makes the defaults mandatory All these points can be easily addressed during the discussions in the working group towards a WG solution. 4. CESoPSN covers structured services, STTP does not. With best regards Alik _______________________________________________ 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: Shahram Davari Subject: RE: What I like about draft-vainshtein-cesopsn-06 Date: Mon, 23 Jun 2003 11:27:35 -0700 Lines: 51 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-From: pwe3-admin@ietf.org Mon Jun 23 20:35:50 2003 Return-path: To: "'Alik Shimelmits'" , Yaakov Stein , Sasha Vainshtein , 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 Alik, >1. The STTP draft does not allow RTP header, while the CESoPSN one >introduces it but allows to suppress it if both sides agree. >Functionally this means that the CESoPSN draft supports more >synchronization scenarios at no cost. Are you saying that RTP processing is free? > >2. The CW of the two drafts differs wrt bit positions and the >size of the sequence number. But the STPP uses the same format as Martini, while CESoPSN doesn't. To me having the same format as Martini is a positive factor. > >3. CESoPSN defines the mandatory packet delay for E1 as 1 ms, > STTP reduces it to 0.5 ms. It also makes the defaults mandatory Off course the default should be mandatory to support, otherwise what is the point of any default value? > >All these points can be easily addressed during the discussions in >the working group towards a WG solution. > >4. CESoPSN covers structured services, STTP does not. I think that is the MAIN idea. Yaakov and many others think there is consensus on the unstructured service, while such consensus does not exist for structured service. So why holdup the implementers that want to implement unstructured service (some say it is the majority of service). Yours, Shahram > >With best regards > Alik > >_______________________________________________ >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: Luca Martini Subject: Re: status signalling of MPLS PW state Date: Mon, 23 Jun 2003 15:47:12 -0600 Organization: Level3 Communications LLC. Lines: 57 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Andrew G. Malis" , pwe3@ietf.org, "Mark Townsley (E-mail)" X-From: pwe3-admin@ietf.org Mon Jun 23 23:54:50 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: Italian [it],French/Canada [fr- To: Hamid Ould-Brahim Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Does anybody else agree with this different way of writing this ? I think that pretty much either way works. Luca Hamid Ould-Brahim wrote: > Luca, > yes , i did that , look in the iana draft, it's in there. I > > left it in this > > thread for discussion only. > Okay. I looked at the PW-IANA draft. I think that part needs to be > reworked in order to reflect exactly the usage of the status field. In > pw-iana draft: " As specified in [1], a new PW status TLV contains a > 32 bit field, PW > status value 0 is reserved to clear all failures. PW Status Bits 0 > through 4 are defined in this document. PW Status Bits 6 through 15 > are to be assigned by IANA using the "IETF Consensus" policy defined > in RFC2434. PW Status Bits 16 through 23 are to be assigned by IANA, > using the "First Come First Served" policy defined in RFC2434. PW > Status Bits 24 through 31 are vendor-specific, and values in this > range are not to be assigned by IANA. > > PW status is a 4 octet bit field as follows: > > 0x00000000 - Pseudo Wire forwarding ( clear all failures ) > 0x00000001 - Pseudo Wire Not Forwarding > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault" > Since the structure is a bit field and since in that structure some > bits/set of bits are reserved. The above codepoints do not exactly > reflect the intent. For example, it is not that 0x00000002 that makes > the local customer-facing PW receive fault but it is the setting of bit > number 1 that indicates this problem is happening. I suggest to layout > the bit structure with each bit having its own description. Using the > pw-IANA description above (btw I think there is a typo with respect to > bit number 5 which appears as 6 in the iana draft), my suggestion is to > rewrite the above to: 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |N|I|E|R|T| IANA ASSIGNED | IANA FCFS | VENDOR | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > N: The "not forwarding bit". When this bit is set, it indicates the > PE sending the status is in "not forwarding" state. > I: Local Customer-facing PW ( ingress ) Receive Fault > E: Local Customer-facing PW ( egress ) Transmit Fault > R: Local PSN-facing PW ( ingress ) Receive Fault > T: Local PSN-facing PW ( egress ) Transmit Fault > > A value of 0x00000000 is reserved and indicates that the status > of the Pseudo-wire is forwarding. Obviously the NIERT bits can > be set independently (and that makes status combination). > Hamid. > From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Wei Luo Subject: Re: status signalling of MPLS PW state Date: Mon, 23 Jun 2003 15:52:01 -0700 Lines: 76 Sender: pwe3-admin@ietf.org References: <3EF77560.1030909@level3.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Hamid Ould-Brahim , "Andrew G. Malis" , pwe3@ietf.org, "Mark Townsley (E-mail)" X-From: pwe3-admin@ietf.org Tue Jun 24 00:52:48 2003 Return-path: X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en,zh-CN To: Luca Martini Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O The way written in the draft is fine, no ambiguity for implementation. I do have a couple of comments and questions regarding this draft. 1. This draft makes reference to draft-ietf-pwe3-control-protocol-03.txt which is not available online yet. Maybe providing that would help clarify how the new PW status TLV is used. Especially, whether it's possible to encode it in the LDP notification message and corresponding actions need to perform upon receiving this TLV. 2. What is the difference between Frame Relay Port mode and HDLC mode? ---Wei Luca Martini wrote: > > Does anybody else agree with this different way of writing this ? > I think that pretty much either way works. > > Luca > > Hamid Ould-Brahim wrote: > > Luca, > yes , i did that , look in the iana draft, it's in there. I > > > left it in this > > > thread for discussion only. > > Okay. I looked at the PW-IANA draft. I think that part needs to be > > reworked in order to reflect exactly the usage of the status field. In > > pw-iana draft: " As specified in [1], a new PW status TLV contains a > > 32 bit field, PW > > status value 0 is reserved to clear all failures. PW Status Bits 0 > > through 4 are defined in this document. PW Status Bits 6 through 15 > > are to be assigned by IANA using the "IETF Consensus" policy defined > > in RFC2434. PW Status Bits 16 through 23 are to be assigned by IANA, > > using the "First Come First Served" policy defined in RFC2434. PW > > Status Bits 24 through 31 are vendor-specific, and values in this > > range are not to be assigned by IANA. > > > > PW status is a 4 octet bit field as follows: > > > > 0x00000000 - Pseudo Wire forwarding ( clear all failures ) > > 0x00000001 - Pseudo Wire Not Forwarding > > 0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault > > 0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault > > 0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault > > 0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault" > > Since the structure is a bit field and since in that structure some > > bits/set of bits are reserved. The above codepoints do not exactly > > reflect the intent. For example, it is not that 0x00000002 that makes > > the local customer-facing PW receive fault but it is the setting of bit > > number 1 that indicates this problem is happening. I suggest to layout > > the bit structure with each bit having its own description. Using the > > pw-IANA description above (btw I think there is a typo with respect to > > bit number 5 which appears as 6 in the iana draft), my suggestion is to > > rewrite the above to: 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |N|I|E|R|T| IANA ASSIGNED | IANA FCFS | VENDOR | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > N: The "not forwarding bit". When this bit is set, it indicates the > > PE sending the status is in "not forwarding" state. > > I: Local Customer-facing PW ( ingress ) Receive Fault > > E: Local Customer-facing PW ( egress ) Transmit Fault > > R: Local PSN-facing PW ( ingress ) Receive Fault > > T: Local PSN-facing PW ( egress ) Transmit Fault > > > > A value of 0x00000000 is reserved and indicates that the status > > of the Pseudo-wire is forwarding. Obviously the NIERT bits can > > be set independently (and that makes status combination). > > Hamid. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: What I like about draft-vainshtein-cesopsn-06 Date: Tue, 24 Jun 2003 08:22:48 +0300 Lines: 97 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Tue Jun 24 07:25:51 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] What I like about draft-vainshtein-cesopsn-06 Thread-Index: AcM5sBRk7bJWBhKFSmy8w2XWxDJKXwAXhbgw To: "Alik Shimelmits" , "Alexander Vainshtein" , Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Alik,=20 > I understand that you are OK with the CESoPSN approach=20 > with regard to emulation of unstructured services and your > objections are limited to emulation of structured services. > Thanks for clarifying your position. >=20 > Somehow I am not surprised since you are one of the co-editors=20 > of the old draft-vainshtein-pwe3-ucesopsn-00.txt (still available=20 > at the IETF Web site) that is almost identical to > the STTP proposal and has been incorporated with minimal changes=20 > into CESoPSN-06.=20 Exactly so. =20 But uCESoPSN did not gain support for various reasons.=20 I still think the basic ideas were right,=20 but perhaps the details and presentation weren't. =20 > To the best of my understanding the technical differences between > CESoPSN-06 and STTP drafts are limited to the following: >=20 > 1. The STTP draft does not allow RTP header, while the CESoPSN one > introduces it but allows to suppress it if both sides agree. > Functionally this means that the CESoPSN draft supports more > synchronization scenarios at no cost. Allowing RTP and then allowing it to be suppressed just adds more baggage, and when this advances the RFC 2026 process will require interoperable=20 implementations to either support RTP or to have it removed from the draft. I chose the former. As I have said on numerous occassions, RTP does not help attain G.823/824 timing compliance in the absence of loop-back timing, and when there is loop-back timing it is certainly not required. So let's leave excess baggage out. > 2. The CW of the two drafts differs wrt bit positions and the > size of the sequence number. I chose the standard PWE CW. I understand that the SONET draft needs the extra room in the CW for a structure pointer and has been given indulgence on this matter. Likewise, I went along with the nonstandard word for the early stages of Johnson's draft, since at the time he too used a structure poionter. But when no pointer is needed, we should keep to the standard CW. > 3. CESoPSN defines the mandatory packet delay for E1 as 1 ms, > STTP reduces it to 0.5 ms. It also makes the defaults mandatory Using 1 ms is a reasonable compromise for T1,=20 since less than that won't allow one to sync bytes (for those who need to). E1 is always bytes and there is no need for so long a delay. >=20 > 4. CESoPSN covers structured services, STTP does not. That is the MAIN difference, and an important one. At this point I avoid the word unstructured since it causes too much confusion - uCESoPSN and STTP can transport structured TDM streams - in fact it doesn't know what the streams are. The difference is only whether the protocol exploits the structure. Too many people have misunderstood this issue. Let's call what uCESoPSN and STTP do, BASIC TDM service. As you will recall we had reached agreement a while ago, that we would let people who only needed basic service to do something simple. I have simply taken this to the extreme. Let people push raw bits (which is what most implementations do anyway). In order to try to get Axerra's support, I put in the defaults that make you happy (from my point of view I would have prefered defaulting to a constant 128 bytes). > All these points can be easily addressed during the discussions in=20 > the working group towards a WG solution. As long as we realize that this is ONLY a basic mode, and not a complete solution, then I am sure we can come up with a simple solution that will satisfy most of the people. We will still need the full solution for the harder cases. Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Tim.Frost@Zarlink.Com Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 24 Jun 2003 10:44:51 +0100 Lines: 109 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 Tue Jun 24 11:48:49 2003 Return-path: To: Nurit Sprecher X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.12 |February 13, 2003) at 06/24/2003 05:46:32 AM, Serialize complete at 06/24/2003 05:46:32 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 Nurit, Thank you for your email. I will try and address some of the points you raise. Firstly you point out that for unstructured emulation, we simply need constant size packets. Thank you for your vote of confidence, this is exactly what CESoPSN does in the unstructured case. Secondly, you have posed the question "why do we need frame aligment?". This is only maintained in the structured (N x 64kbit/s) case, and these are some of the reasons why. In AAL1, the cell size is fixed, therefore a pointer system is required to indicate the start of any structure within the cell stream. The pointer here is a necessary element to get around the fixed cell size. In an IP or MPLS network, the packet size is free to vary. This can be exploited to simplify the encapsulation method. The basic structure in a TDM trunk is the 125us frame. Therefore the approach in CESoPSN is to carry a whole number of such structures in the packet. Hence it is exploting the nature of an IP or MPLS network to carry the stuctures already present in the data Frame alignment is not required for its own sake, but it does convey a number of advantages: - eliminates the need for a pointer, since the pointer is implicit (always 0) - operators can set up PWs with different values of N to the same latency, simplifying network management and QoS - using a fixed cell size, the granularity of packetization delay may be very high for small values of N - with CESoPSN it can always be adjusted in 125 us units One more point - you mention the advantages of a constant size packet. We should not confuse a constant size packet for a given PW with the use of the same size packet across all PWs (e.g. the fixed cell size of ATM). CESoPSN does maintain a constant size packet for a given pseudo-wire. Once the PW has been set up with a given latency, the packet size does not vary. So as you state below, when a packet is lost, we know exactly how many bits have been lost and need reconstructing. The reconstruction itself can use any of the techniques suggested in Yaakov's draft on the effects of packet loss, should it be desired - these are not restricted to AAL1. In fact AAL1 actually makes this issue harder than CESoPSN. The cells in AAL1, while of fixed size, contain varying amounts of _timeslot_ data, depending on the position of the CAS sub-structure. CESoPSN always contains the same amount of timeslot data, regardless of whether the CAS sub-structure is present or not. Therefore the amount of data to replay is known directly, without having to compute from the position of the pointer the amount of CAS data that may be present in the packet. This simplifies reconstruction of the timeslot data. It also makes it much easier to identify and process the CAS data, since it is always in the same, regular location. Therefore I contend that the frame alignment system in CESoPSN, and especially the use of a constant amount of timeslot data in each packet regardless of the presence of CAS is an important property of the method. You are right to say it is not necessary for its own sake, but its use conveys significant advantages, and exploits the nature of an IP or MPLS network in a way that a method based on a fixed cell size cannot. Tim Nurit Sprecher Sent by: pwe3-admin@ietf.org 22-Jun-2003 09:18 AM To: "'pwe3@ietf.org'" cc: Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I have been passively following the debate over draft-vainshtein vs. draft-anavi for some time, and still don't understand one thing. draft-anavi uses techniques borrowed from ATM, in order to maintain compatibility to existing CES systems. It thus a pointer to maintains frame alignment. draft-vainshtein maintains TDM frame alignment by always sending an integral number of frames in a packet. Why do we need to maintain frame alignment at all? >From the TDM reconstruction point of view, all we need is to play out the bits that are in the receive buffer, and the TDM switch will take care of all the rest. If a packet is lost, all we need to know is how many bits it contained - so all we need is to have a constant size packet!1 I vote against accepting draft-vainshtein. For the unstructured case we need a simpler method - just constant size packets! For those complex cases where we need structured (especially with CAS) we might as well use draft-anavi. Nurit. _______________________________________________ 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: Tim.Frost@Zarlink.Com Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 24 Jun 2003 10:59:11 +0100 Lines: 219 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: alik@AXERRA.com, danny@tcb.net, dromasca@avaya.com, pwe3@ietf.org, pwe3-admin@ietf.org, yaakov_s@rad.com X-From: pwe3-admin@ietf.org Tue Jun 24 12:02:47 2003 Return-path: To: neil.2.harrison@bt.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.12 |February 13, 2003) at 06/24/2003 06:00:52 AM, Serialize complete at 06/24/2003 06:00:52 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 Neil, Apologies for the late reply. Who is the draft aimed at? We are seeing adoption in a number of applications. Clearly for an incumbent carrier with a pre-existing and comprehensive TDM network such as yourselves, this is not going to be appropriate. Where we are seeing more traction is: - for use across packet access networks (e.g. metro ethernet networks), allowing an operator with a packet network to service TDM-based customers - the competitive play, allowing data operators to "steal" voice customers from the incumbents - use in greenfield areas, where packet networks are being installed, but still need to support voice applications (e.g. PBXs) - enterprise use in a "toll bypass" scenario (something RAD have been very successfully exploiting recently) I'm sure we could debate the relative merits or demerits of these applications, but it gives a flavour. You are right that it is not the panacea for everyone, but then what is? Cheers, Tim neil.2.harrison@bt.com 18-Jun-2003 10:40 PM To: Tim.Frost@Zarlink.Com, alik@AXERRA.com cc: danny@tcb.net, dromasca@avaya.com, pwe3@ietf.org, pwe3-admin@ietf.org, yaakov_s@rad.com Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Tim, Can you please clarify *who* this draft aimed at? Is it's usage in: Internet? ISPs? Enterprises? Carriers? I must admit I find it really hard to understand just who lots of CCAMPs stuff is aimed at in the general case. I just re-read it and IMO its awful from a large carriers perspective (but then we have many problems with much of the PWE stuff from a functional architecture perspective.....hopefully I don't have to explain why!). However, I would not want to stop anyone using this, just so long as its target audience is clear and its not being sold as the solution for everyone. regards, Neil > -----Original Message----- > From: Tim.Frost@Zarlink.Com [mailto:Tim.Frost@Zarlink.Com] > Sent: 18 June 2003 09:48 > To: Alik Shimelmits > Cc: Danny McPherson; Romascanu, Dan (Dan); pwe3@ietf.org; > pwe3-admin@ietf.org; Yaakov Stein > Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > Alik took the words out of my mouth! > > Yes we do have a CESoPSN implementation that we demonstrated > at Supercomm > this year, running across the MEF core network. This > implementation is > completely separate to any of the implementations mentioned > so far in this > thread. So there are many separate implementations of this > standard. We > have not run interoperability trials yet, but these are being > planned to > happen soon. > > Just for the record, I support this draft going through as a > WG standard. > As I understand it , independent co-authors should be counted > separately. > > Regards, > Tim > > > > > > > Alik Shimelmits > Sent by: pwe3-admin@ietf.org > 18-Jun-2003 08:08 AM > > > To: Yaakov Stein , Danny > McPherson , > "Romascanu, Dan (Dan)" > cc: pwe3@ietf.org > Subject: RE: [PWE3] Re: I-D > ACTION:draft-vainshtein-cesopsn-06.txt > > > Yaakov, > just for being accurate you should not forget that > draft-vainshtein has > the > following co-authors: > > Tim Frost (Zarlink) - the company provides CESoPSN chip > demonstrated at > the > last Supercomm, > Prayson Pate (Overture) - the company has working system (also > demonstrated > at the last Supercomm), > Edward Metz (Thrupoint) > > With best regards > Alik > > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Tuesday, June 17, 2003 8:33 PM > To: Danny McPherson; Romascanu, Dan (Dan) > Cc: pwe3@ietf.org > Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt > > > > Really? Can you elaborate on this (i.e., how many other > > folks have/are implementing this)? > > Sasha quotes 4 interoperable implementations, > RAD, Redux, Ericsson, and Engage. > > As I have said in previous emails RAD does NOT > support CESoPSN in our standard product line. > This "interop" was a one-time effort to supply small > remote boxes to interoperate with CESoPSN central site > for a given sales opportunity. > > From their latest spec sheets, Redux only supports unframed > raw bit transport, and thus could only possibly support > draft-vainshtein > in unstructured E1 mode. Unless they have something new > and unpublished, they can't possibly support draft-vainshtein > for T1 or in structured modes. > > I don't know what modes Engage and Ericsson support, > but it would be interesting to hear. I am guessing that > the Engage implementation (being software on a small > processor) is also unstructured, > but perhaps Sasha could enlighten us. > > Incidentally, draft-anavi presently has several interoperable > implementations that support unstructured and structured modes, > and at least two commercial chip-sets are coming out in the > near future. > > Perhaps Dan is refering to verbal support, > rather than actual implementations. > So far I see 6:5 in favor of CESoPSN: > > FOR CESoPSN: > 1. Sasha - Axerra > 2. Ron Cohen - Lycium > 3. Michel Khouderchah - Cisco > 4. Uri Rotshtein - Redux > 5. Max Riegel - Siemens > 6. Dan Romascanu - Avaya > > AGAINST (i.e. for TDMoIP) > 1. Yaakov - RAD > 2. Shahram - PMC > 3. Alex Conta - TranSwitch > 4. Amnon Ilan - Nbase > 5. Neil Harrison - BT > > which is pretty close to 50-50. > Since I am going to be issuing an update > of draft-anavi, we can go through this > again and see what support draft-anavi has - > the answer will probably be about the same. > > Finally, perhaps Dan is refering to deployments. > draft-anavi has well over 10,000 deployed ports, > many of which have been functioning for several > years already. Can we get some figures on > active deployments (not betas) from the CESoPSN > implementations ? > I know that this sounds terribly crass, > but don't we deserve to hear if this stuff > has really been tested in the field? > > Y(J)S > > > _______________________________________________ > 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: Tim.Frost@Zarlink.Com Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 24 Jun 2003 11:55:34 +0100 Lines: 110 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "'Nurit Sprecher'" , pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 24 12:55:52 2003 Return-path: To: X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.12 |February 13, 2003) at 06/24/2003 06:53:28 AM, Serialize complete at 06/24/2003 06:53:28 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 Amnon, I'm curious about your assertion here "The only way to support silence suppression is by using the AAL2 mode of TDMoIP". That is a very bold statement! There are several ways to support silence suppression, of which AAL2 is one. What about VoIP, for example? AAL2 may be a good method, however, it is not the _only_ way. Clearly CESoPSN does not have a mode for silence suppression. However, it does not compete with the AAL2 mode from TDMoIP. There may be an argument why we shouldn't support both TDMoIP's AAL1 mode and CESoPSN, since both do basically the same thing, but AAL2 has a clear differentiating reason for its existence, as you have pointed out. Therefore the presence of an AAL2 mode in TDMoIP is not an argument against adopting CESoPSN. Regards, Tim "Amnon Ilan" Sent by: pwe3-admin@ietf.org 23-Jun-2003 04:23 PM Please respond to ailan To: "'Nurit Sprecher'" , cc: Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I agree with Nurit that there is no need for the CESoPSN draft. We can have only two basic solutions: 1. The simple (simplistic) one: unstructured bitstream. 2. The more sophisticated one: TDMoIP. The simple approach is limited since it requires a very good PSN (very low packet loss and PDV): small frame loss may cause the loss of frame alignment (and many E1\T1 applications are not robust enough to minimize the effect of such a problem). This approach is also very sensitive to loss of timing synchronization. However, it is simple, easy to implement, and may be used on cases where the PSN is good enough, or when the E1\T1 line itself is unstructured. The more sophisticated approach is much more robust: having framers at the edge prevents loss of frame alignment (the effect of corrupted data inside some of the time-slots is much less severe then the one caused by loss of frame alignment). The structured modes of both TDMoIP and CESoPSN address these issues. However, IMO, TDMoIP is much more comprehensive: for example see the issue of silence suppression. Most of E1\T1 lines are voice trunks and for such trunks silence suppression may save more then 50% of network traffic. The only way to support silence suppression is by using the AAL2 mode of TDMoIP. That is to add on the issues of market acceptance and chances for compatible standards (ITU, MPLS-Forum) mentioned in my previous email. Amnon. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Nurit Sprecher Sent: Sun 22 June 2003 10:19 To: 'pwe3@ietf.org' Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I have been passively following the debate over draft-vainshtein vs. draft-anavi for some time, and still don't understand one thing. draft-anavi uses techniques borrowed from ATM, in order to maintain compatibility to existing CES systems. It thus a pointer to maintains frame alignment. draft-vainshtein maintains TDM frame alignment by always sending an integral number of frames in a packet. Why do we need to maintain frame alignment at all? >From the TDM reconstruction point of view, all we need is to play out the bits that are in the receive buffer, and the TDM switch will take care of all the rest. If a packet is lost, all we need to know is how many bits it contained - so all we need is to have a constant size packet!1 I vote against accepting draft-vainshtein. For the unstructured case we need a simpler method - just constant size packets! For those complex cases where we need structured (especially with CAS) we might as well use draft-anavi. Nurit. _______________________________________________ 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: "Andrew G. Malis" Subject: RE: I-D ACTION:draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt Date: Tue, 24 Jun 2003 06:54:04 -0400 Lines: 233 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_507438878==.ALT" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 24 12:58:08 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Akiva Sadovski In-Reply-To: X-OriginalArrivalTime: 24 Jun 2003 10:56:27.0583 (UTC) FILETIME=[42DFF4F0:01C33A3F] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --=====================_507438878==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Akiva, Including such functionality would be completely gratuitous (unless you know of a real-word need). Port-to-port is all that is needed for HDLC and PPP carriage. Cheers, Andy ------- At 6/23/2003 04:35 PM +0200, Akiva Sadovski wrote: >Luca and Andy, > the draft is OK, but: > > almost all L2 encapsulations define 2 modes, f.ex. the FR encap: > * 1:1 mode that strips FR headers, is mandatory and is the > only mode that can be used in conjunction with MPLS PSN > * N:1 mode that carries FR headers, and is optional over IP PSN > > Should we define the same 2 modes for the HDLC-over-MPLS, e.g. to permit >address/control/protocol fields stripping at the ingress with possible >attachment of a different address(/control/protocol ?) at the egress ? > However i doubt there's a need in such functionality, but ... maybe ... >to align all L2 drafts... > >Best, > Akiva. > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, June 17, 2003 1:57 PM > > Cc: pwe3@ietf.org > > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Pseudo Wire Emulation Edge > > to Edge Working Group of the IETF. > > > > Title : Encapsulation Methods for Transport > > of PPP/HDLC Frames > > Over IP and MPLS Networks > > Author(s) : L. Martini et al. > > Filename : draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt > > Pages : 10 > > Date : 2003-6-16 > > > > A Pseudowire (PW) can be used to carry PPP, or HDLC Protocol Data > > Units over an IP or MPLS network without terminating the PPP/HDLC > > protocol. This enables service providers to offer 'emulated' HDLC, or > > PPP link services over existing IP or MPLS networks. This document > > specifies the encapsulation of PPP/HDLC PDUs within a pseudowire. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-e > > ncap-mpls-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > > /internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > --=====================_507438878==.ALT Content-Type: text/html; charset="us-ascii" Akiva,

Including such functionality would be completely gratuitous (unless you know of a real-word need).  Port-to-port is all that is needed for HDLC and PPP carriage.

Cheers,
Andy

-------

At 6/23/2003 04:35 PM +0200, Akiva Sadovski wrote:

Luca and Andy,
  the draft is OK, but:

   almost all L2 encapsulations define 2 modes, f.ex. the FR encap:
     * 1:1 mode that strips FR headers, is mandatory and is the
       only mode that can be used in conjunction with MPLS PSN
     * N:1 mode that carries FR headers, and is optional over IP PSN

   Should we define the same 2 modes for the HDLC-over-MPLS, e.g. to permit
address/control/protocol fields stripping at the ingress with possible
attachment of a different address(/control/protocol ?) at the egress ?
   However i doubt there's a need in such functionality, but ... maybe ...
to align all L2 drafts...

Best,
  Akiva.

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Tuesday, June 17, 2003 1:57 PM
> Cc: pwe3@ietf.org
> Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Pseudo Wire Emulation Edge
> to Edge Working Group of the IETF.
>
>       Title           : Encapsulation Methods for Transport
> of PPP/HDLC Frames
>                           Over IP and MPLS Networks
>       Author(s)       : L. Martini et al.
>       Filename        : draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt
>       Pages           : 10
>       Date            : 2003-6-16
>       
> A Pseudowire (PW) can be used to carry PPP, or HDLC Protocol Data
> Units over an IP or MPLS network without terminating the PPP/HDLC
> protocol. This enables service providers to offer 'emulated' HDLC, or
> PPP link services over existing IP or MPLS networks. This document
> specifies the encapsulation of PPP/HDLC PDUs within a pseudowire.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-e
> ncap-mpls-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body
> of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>       "get draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>       mailserv@ietf.org.
> In the body type:
>       "FILE
> /internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt".
>       
> NOTE: The mail server at ietf.org can return the document in
>       MIME-encoded form by using the "mpack" utility.  To use this
>       feature, insert the command "ENCODING mime" before the "FILE"
>       command.  To decode the response(s), you will need "munpack" or
>       a MIME-compliant mail reader.  Different MIME-compliant
> mail readers
>       exhibit different behavior, especially when dealing with
>       "multipart" MIME messages (i.e. documents which have been split
>       up into multiple messages), so check your local documentation on
>       how to manipulate these messages.
>               
>               
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
--=====================_507438878==.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Amnon Ilan" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 24 Jun 2003 14:37:32 +0200 Lines: 145 Sender: pwe3-admin@ietf.org References: Reply-To: Cc: "'Nurit Sprecher'" , , X-From: pwe3-admin@ietf.org Tue Jun 24 13:41:07 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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, Please see my comments inline. Regards, Amnon. -----Original Message----- From: Tim.Frost@Zarlink.Com [mailto:Tim.Frost@Zarlink.Com] Sent: Tue 24 June 2003 12:56 To: ailan@mrv.com Cc: 'Nurit Sprecher'; pwe3@ietf.org; pwe3-admin@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Amnon, I'm curious about your assertion here "The only way to support silence suppression is by using the AAL2 mode of TDMoIP". That is a very bold statement! There are several ways to support silence suppression, of which AAL2 is one. What about VoIP, for example? AAL2 may be a good method, however, it is not the _only_ way. [Amnon Ilan] My wording was not so good. By the word 'only' I meant within the scope of E1/T1 over PSN current suggestions (i.e. CESoPSN and TDMoIP). Clearly CESoPSN does not have a mode for silence suppression. However, it does not compete with the AAL2 mode from TDMoIP. There may be an argument why we shouldn't support both TDMoIP's AAL1 mode and CESoPSN, since both do basically the same thing, but AAL2 has a clear differentiating reason for its existence, as you have pointed out. Therefore the presence of an AAL2 mode in TDMoIP is not an argument against adopting CESoPSN. [Amnon Ilan] IMHO it is an argument, and even a good one. If you go with the concept of adopting VoATM to PSNs why break it in the middle? (the basic reason for adopting VoATM was that VoIP is not designed for trunking and CES). There should be some very clear and dramatic technical advantage in favor of CESoPSN in order to do it (and by doing it loose the market acceptance advantages of VoATM which I've mentioned before). IMHO there is no such an advantage for CESoPSN (TDMoIP and CESoPSN are more or less the same on the AAL1 level). Regards, Tim "Amnon Ilan" Sent by: pwe3-admin@ietf.org 23-Jun-2003 04:23 PM Please respond to ailan To: "'Nurit Sprecher'" , cc: Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I agree with Nurit that there is no need for the CESoPSN draft. We can have only two basic solutions: 1. The simple (simplistic) one: unstructured bitstream. 2. The more sophisticated one: TDMoIP. The simple approach is limited since it requires a very good PSN (very low packet loss and PDV): small frame loss may cause the loss of frame alignment (and many E1\T1 applications are not robust enough to minimize the effect of such a problem). This approach is also very sensitive to loss of timing synchronization. However, it is simple, easy to implement, and may be used on cases where the PSN is good enough, or when the E1\T1 line itself is unstructured. The more sophisticated approach is much more robust: having framers at the edge prevents loss of frame alignment (the effect of corrupted data inside some of the time-slots is much less severe then the one caused by loss of frame alignment). The structured modes of both TDMoIP and CESoPSN address these issues. However, IMO, TDMoIP is much more comprehensive: for example see the issue of silence suppression. Most of E1\T1 lines are voice trunks and for such trunks silence suppression may save more then 50% of network traffic. The only way to support silence suppression is by using the AAL2 mode of TDMoIP. That is to add on the issues of market acceptance and chances for compatible standards (ITU, MPLS-Forum) mentioned in my previous email. Amnon. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Nurit Sprecher Sent: Sun 22 June 2003 10:19 To: 'pwe3@ietf.org' Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I have been passively following the debate over draft-vainshtein vs. draft-anavi for some time, and still don't understand one thing. draft-anavi uses techniques borrowed from ATM, in order to maintain compatibility to existing CES systems. It thus a pointer to maintains frame alignment. draft-vainshtein maintains TDM frame alignment by always sending an integral number of frames in a packet. Why do we need to maintain frame alignment at all? >From the TDM reconstruction point of view, all we need is to play out the bits that are in the receive buffer, and the TDM switch will take care of all the rest. If a packet is lost, all we need to know is how many bits it contained - so all we need is to have a constant size packet!1 I vote against accepting draft-vainshtein. For the unstructured case we need a simpler method - just constant size packets! For those complex cases where we need structured (especially with CAS) we might as well use draft-anavi. Nurit. _______________________________________________ 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: Tim.Frost@Zarlink.Com Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 24 Jun 2003 13:59:54 +0100 Lines: 180 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "'Nurit Sprecher'" , pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 24 15:01:42 2003 Return-path: To: X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.12 |February 13, 2003) at 06/24/2003 08:57:46 AM, Serialize complete at 06/24/2003 08:57:46 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 So what you are actually saying is that we shouldn't use either CESoPSN or TDMoIP's AAL1 mode. The logical conclusion from your argument appears to be that the only mode worth having is the AAL2 mode of TDMoIP. Perhaps you could also explain the "market acceptance" argument. There may be acceptance of AAL1 and AAL2 in the ATM market. Why do you think that this will be maintained when translated into the IP/MPLS market? I've heard the opposite view put forward by several vendors along the lines of "the network is starting to migrate away from ATM, so why on earth should I go and stick it back in there again". Regards, Tim "Amnon Ilan" 24-Jun-2003 01:37 PM Please respond to ailan To: cc: "'Nurit Sprecher'" , , Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Tim, Please see my comments inline. Regards, Amnon. -----Original Message----- From: Tim.Frost@Zarlink.Com [mailto:Tim.Frost@Zarlink.Com] Sent: Tue 24 June 2003 12:56 To: ailan@mrv.com Cc: 'Nurit Sprecher'; pwe3@ietf.org; pwe3-admin@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Amnon, I'm curious about your assertion here "The only way to support silence suppression is by using the AAL2 mode of TDMoIP". That is a very bold statement! There are several ways to support silence suppression, of which AAL2 is one. What about VoIP, for example? AAL2 may be a good method, however, it is not the _only_ way. [Amnon Ilan] My wording was not so good. By the word 'only' I meant within the scope of E1/T1 over PSN current suggestions (i.e. CESoPSN and TDMoIP). Clearly CESoPSN does not have a mode for silence suppression. However, it does not compete with the AAL2 mode from TDMoIP. There may be an argument why we shouldn't support both TDMoIP's AAL1 mode and CESoPSN, since both do basically the same thing, but AAL2 has a clear differentiating reason for its existence, as you have pointed out. Therefore the presence of an AAL2 mode in TDMoIP is not an argument against adopting CESoPSN. [Amnon Ilan] IMHO it is an argument, and even a good one. If you go with the concept of adopting VoATM to PSNs why break it in the middle? (the basic reason for adopting VoATM was that VoIP is not designed for trunking and CES). There should be some very clear and dramatic technical advantage in favor of CESoPSN in order to do it (and by doing it loose the market acceptance advantages of VoATM which I've mentioned before). IMHO there is no such an advantage for CESoPSN (TDMoIP and CESoPSN are more or less the same on the AAL1 level). Regards, Tim "Amnon Ilan" Sent by: pwe3-admin@ietf.org 23-Jun-2003 04:23 PM Please respond to ailan To: "'Nurit Sprecher'" , cc: Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I agree with Nurit that there is no need for the CESoPSN draft. We can have only two basic solutions: 1. The simple (simplistic) one: unstructured bitstream. 2. The more sophisticated one: TDMoIP. The simple approach is limited since it requires a very good PSN (very low packet loss and PDV): small frame loss may cause the loss of frame alignment (and many E1\T1 applications are not robust enough to minimize the effect of such a problem). This approach is also very sensitive to loss of timing synchronization. However, it is simple, easy to implement, and may be used on cases where the PSN is good enough, or when the E1\T1 line itself is unstructured. The more sophisticated approach is much more robust: having framers at the edge prevents loss of frame alignment (the effect of corrupted data inside some of the time-slots is much less severe then the one caused by loss of frame alignment). The structured modes of both TDMoIP and CESoPSN address these issues. However, IMO, TDMoIP is much more comprehensive: for example see the issue of silence suppression. Most of E1\T1 lines are voice trunks and for such trunks silence suppression may save more then 50% of network traffic. The only way to support silence suppression is by using the AAL2 mode of TDMoIP. That is to add on the issues of market acceptance and chances for compatible standards (ITU, MPLS-Forum) mentioned in my previous email. Amnon. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Nurit Sprecher Sent: Sun 22 June 2003 10:19 To: 'pwe3@ietf.org' Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I have been passively following the debate over draft-vainshtein vs. draft-anavi for some time, and still don't understand one thing. draft-anavi uses techniques borrowed from ATM, in order to maintain compatibility to existing CES systems. It thus a pointer to maintains frame alignment. draft-vainshtein maintains TDM frame alignment by always sending an integral number of frames in a packet. Why do we need to maintain frame alignment at all? >From the TDM reconstruction point of view, all we need is to play out the bits that are in the receive buffer, and the TDM switch will take care of all the rest. If a packet is lost, all we need to know is how many bits it contained - so all we need is to have a constant size packet!1 I vote against accepting draft-vainshtein. For the unstructured case we need a simpler method - just constant size packets! For those complex cases where we need structured (especially with CAS) we might as well use draft-anavi. Nurit. _______________________________________________ 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: "Amnon Ilan" Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 24 Jun 2003 16:32:04 +0200 Lines: 205 Sender: pwe3-admin@ietf.org References: Reply-To: Cc: "'Nurit Sprecher'" , , X-From: pwe3-admin@ietf.org Tue Jun 24 15:32:47 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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 do not recall writing we should use only AAL2. My point is: since TDMoIP has both AAL1 and AAL2, we have all the options inside. There are cases where AAL1 should be used. AAL2 is mainly for voice trunks while AAL1 is better for N*64k data applications. Regarding the "market acceptance" issue: 1. If we can have the ATM market on our side then why shouldn't we? (and, IMO, it includes many ILECs, ITU etc.). 2. Even the "religious" guys wouldn't mind borrowing some good technologies from ATM in order to push IP\MPLS forward. Regards, Amnon. -----Original Message----- From: Tim.Frost@Zarlink.Com [mailto:Tim.Frost@Zarlink.Com] Sent: Tue 24 June 2003 15:00 To: ailan@mrv.com Cc: 'Nurit Sprecher'; pwe3@ietf.org; pwe3-admin@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt So what you are actually saying is that we shouldn't use either CESoPSN or TDMoIP's AAL1 mode. The logical conclusion from your argument appears to be that the only mode worth having is the AAL2 mode of TDMoIP. Perhaps you could also explain the "market acceptance" argument. There may be acceptance of AAL1 and AAL2 in the ATM market. Why do you think that this will be maintained when translated into the IP/MPLS market? I've heard the opposite view put forward by several vendors along the lines of "the network is starting to migrate away from ATM, so why on earth should I go and stick it back in there again". Regards, Tim "Amnon Ilan" 24-Jun-2003 01:37 PM Please respond to ailan To: cc: "'Nurit Sprecher'" , , Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Tim, Please see my comments inline. Regards, Amnon. -----Original Message----- From: Tim.Frost@Zarlink.Com [mailto:Tim.Frost@Zarlink.Com] Sent: Tue 24 June 2003 12:56 To: ailan@mrv.com Cc: 'Nurit Sprecher'; pwe3@ietf.org; pwe3-admin@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Amnon, I'm curious about your assertion here "The only way to support silence suppression is by using the AAL2 mode of TDMoIP". That is a very bold statement! There are several ways to support silence suppression, of which AAL2 is one. What about VoIP, for example? AAL2 may be a good method, however, it is not the _only_ way. [Amnon Ilan] My wording was not so good. By the word 'only' I meant within the scope of E1/T1 over PSN current suggestions (i.e. CESoPSN and TDMoIP). Clearly CESoPSN does not have a mode for silence suppression. However, it does not compete with the AAL2 mode from TDMoIP. There may be an argument why we shouldn't support both TDMoIP's AAL1 mode and CESoPSN, since both do basically the same thing, but AAL2 has a clear differentiating reason for its existence, as you have pointed out. Therefore the presence of an AAL2 mode in TDMoIP is not an argument against adopting CESoPSN. [Amnon Ilan] IMHO it is an argument, and even a good one. If you go with the concept of adopting VoATM to PSNs why break it in the middle? (the basic reason for adopting VoATM was that VoIP is not designed for trunking and CES). There should be some very clear and dramatic technical advantage in favor of CESoPSN in order to do it (and by doing it loose the market acceptance advantages of VoATM which I've mentioned before). IMHO there is no such an advantage for CESoPSN (TDMoIP and CESoPSN are more or less the same on the AAL1 level). Regards, Tim "Amnon Ilan" Sent by: pwe3-admin@ietf.org 23-Jun-2003 04:23 PM Please respond to ailan To: "'Nurit Sprecher'" , cc: Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I agree with Nurit that there is no need for the CESoPSN draft. We can have only two basic solutions: 1. The simple (simplistic) one: unstructured bitstream. 2. The more sophisticated one: TDMoIP. The simple approach is limited since it requires a very good PSN (very low packet loss and PDV): small frame loss may cause the loss of frame alignment (and many E1\T1 applications are not robust enough to minimize the effect of such a problem). This approach is also very sensitive to loss of timing synchronization. However, it is simple, easy to implement, and may be used on cases where the PSN is good enough, or when the E1\T1 line itself is unstructured. The more sophisticated approach is much more robust: having framers at the edge prevents loss of frame alignment (the effect of corrupted data inside some of the time-slots is much less severe then the one caused by loss of frame alignment). The structured modes of both TDMoIP and CESoPSN address these issues. However, IMO, TDMoIP is much more comprehensive: for example see the issue of silence suppression. Most of E1\T1 lines are voice trunks and for such trunks silence suppression may save more then 50% of network traffic. The only way to support silence suppression is by using the AAL2 mode of TDMoIP. That is to add on the issues of market acceptance and chances for compatible standards (ITU, MPLS-Forum) mentioned in my previous email. Amnon. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Nurit Sprecher Sent: Sun 22 June 2003 10:19 To: 'pwe3@ietf.org' Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I have been passively following the debate over draft-vainshtein vs. draft-anavi for some time, and still don't understand one thing. draft-anavi uses techniques borrowed from ATM, in order to maintain compatibility to existing CES systems. It thus a pointer to maintains frame alignment. draft-vainshtein maintains TDM frame alignment by always sending an integral number of frames in a packet. Why do we need to maintain frame alignment at all? >From the TDM reconstruction point of view, all we need is to play out the bits that are in the receive buffer, and the TDM switch will take care of all the rest. If a packet is lost, all we need to know is how many bits it contained - so all we need is to have a constant size packet!1 I vote against accepting draft-vainshtein. For the unstructured case we need a simpler method - just constant size packets! For those complex cases where we need structured (especially with CAS) we might as well use draft-anavi. Nurit. _______________________________________________ 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: Alik Shimelmits Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Tue, 24 Jun 2003 16:46:10 +0200 Lines: 233 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'Nurit Sprecher'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Jun 24 15:52:12 2003 Return-path: To: ailan@mrv.com, Tim.Frost@Zarlink.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 Ilan and all, I propose to keep discussion in the scope of draft-ietf-pwe3-tdm-requirements-00.txt that specifies requirements for emulation of tdm services over PSN. Regards Alik -----Original Message----- From: Amnon Ilan [mailto:ailan@mrv.com] Sent: Tuesday, June 24, 2003 4:32 PM To: Tim.Frost@Zarlink.Com Cc: 'Nurit Sprecher'; pwe3@ietf.org; pwe3-admin@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Tim, I do not recall writing we should use only AAL2. My point is: since TDMoIP has both AAL1 and AAL2, we have all the options inside. There are cases where AAL1 should be used. AAL2 is mainly for voice trunks while AAL1 is better for N*64k data applications. Regarding the "market acceptance" issue: 1. If we can have the ATM market on our side then why shouldn't we? (and, IMO, it includes many ILECs, ITU etc.). 2. Even the "religious" guys wouldn't mind borrowing some good technologies from ATM in order to push IP\MPLS forward. Regards, Amnon. -----Original Message----- From: Tim.Frost@Zarlink.Com [mailto:Tim.Frost@Zarlink.Com] Sent: Tue 24 June 2003 15:00 To: ailan@mrv.com Cc: 'Nurit Sprecher'; pwe3@ietf.org; pwe3-admin@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt So what you are actually saying is that we shouldn't use either CESoPSN or TDMoIP's AAL1 mode. The logical conclusion from your argument appears to be that the only mode worth having is the AAL2 mode of TDMoIP. Perhaps you could also explain the "market acceptance" argument. There may be acceptance of AAL1 and AAL2 in the ATM market. Why do you think that this will be maintained when translated into the IP/MPLS market? I've heard the opposite view put forward by several vendors along the lines of "the network is starting to migrate away from ATM, so why on earth should I go and stick it back in there again". Regards, Tim "Amnon Ilan" 24-Jun-2003 01:37 PM Please respond to ailan To: cc: "'Nurit Sprecher'" , , Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Tim, Please see my comments inline. Regards, Amnon. -----Original Message----- From: Tim.Frost@Zarlink.Com [mailto:Tim.Frost@Zarlink.Com] Sent: Tue 24 June 2003 12:56 To: ailan@mrv.com Cc: 'Nurit Sprecher'; pwe3@ietf.org; pwe3-admin@ietf.org Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Amnon, I'm curious about your assertion here "The only way to support silence suppression is by using the AAL2 mode of TDMoIP". That is a very bold statement! There are several ways to support silence suppression, of which AAL2 is one. What about VoIP, for example? AAL2 may be a good method, however, it is not the _only_ way. [Amnon Ilan] My wording was not so good. By the word 'only' I meant within the scope of E1/T1 over PSN current suggestions (i.e. CESoPSN and TDMoIP). Clearly CESoPSN does not have a mode for silence suppression. However, it does not compete with the AAL2 mode from TDMoIP. There may be an argument why we shouldn't support both TDMoIP's AAL1 mode and CESoPSN, since both do basically the same thing, but AAL2 has a clear differentiating reason for its existence, as you have pointed out. Therefore the presence of an AAL2 mode in TDMoIP is not an argument against adopting CESoPSN. [Amnon Ilan] IMHO it is an argument, and even a good one. If you go with the concept of adopting VoATM to PSNs why break it in the middle? (the basic reason for adopting VoATM was that VoIP is not designed for trunking and CES). There should be some very clear and dramatic technical advantage in favor of CESoPSN in order to do it (and by doing it loose the market acceptance advantages of VoATM which I've mentioned before). IMHO there is no such an advantage for CESoPSN (TDMoIP and CESoPSN are more or less the same on the AAL1 level). Regards, Tim "Amnon Ilan" Sent by: pwe3-admin@ietf.org 23-Jun-2003 04:23 PM Please respond to ailan To: "'Nurit Sprecher'" , cc: Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I agree with Nurit that there is no need for the CESoPSN draft. We can have only two basic solutions: 1. The simple (simplistic) one: unstructured bitstream. 2. The more sophisticated one: TDMoIP. The simple approach is limited since it requires a very good PSN (very low packet loss and PDV): small frame loss may cause the loss of frame alignment (and many E1\T1 applications are not robust enough to minimize the effect of such a problem). This approach is also very sensitive to loss of timing synchronization. However, it is simple, easy to implement, and may be used on cases where the PSN is good enough, or when the E1\T1 line itself is unstructured. The more sophisticated approach is much more robust: having framers at the edge prevents loss of frame alignment (the effect of corrupted data inside some of the time-slots is much less severe then the one caused by loss of frame alignment). The structured modes of both TDMoIP and CESoPSN address these issues. However, IMO, TDMoIP is much more comprehensive: for example see the issue of silence suppression. Most of E1\T1 lines are voice trunks and for such trunks silence suppression may save more then 50% of network traffic. The only way to support silence suppression is by using the AAL2 mode of TDMoIP. That is to add on the issues of market acceptance and chances for compatible standards (ITU, MPLS-Forum) mentioned in my previous email. Amnon. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Nurit Sprecher Sent: Sun 22 June 2003 10:19 To: 'pwe3@ietf.org' Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I have been passively following the debate over draft-vainshtein vs. draft-anavi for some time, and still don't understand one thing. draft-anavi uses techniques borrowed from ATM, in order to maintain compatibility to existing CES systems. It thus a pointer to maintains frame alignment. draft-vainshtein maintains TDM frame alignment by always sending an integral number of frames in a packet. Why do we need to maintain frame alignment at all? >From the TDM reconstruction point of view, all we need is to play out the bits that are in the receive buffer, and the TDM switch will take care of all the rest. If a packet is lost, all we need to know is how many bits it contained - so all we need is to have a constant size packet!1 I vote against accepting draft-vainshtein. For the unstructured case we need a simpler method - just constant size packets! For those complex cases where we need structured (especially with CAS) we might as well use draft-anavi. Nurit. _______________________________________________ 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: Carmine Daloia Subject: SONET/SDH Pointers in draft-ietf-pwe3-sonet-01 Date: Tue, 24 Jun 2003 12:26:55 -0700 (PDT) Lines: 42 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0-810892575-1056482815=:37867" X-From: pwe3-admin@ietf.org Tue Jun 24 23:18:52 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 --0-810892575-1056482815=:37867 Content-Type: text/plain; charset=us-ascii Hello, I was reading over draft-ietf-pwe3-sonet-01 and I came across Section 6 which deals with SONET/SDH Pointer Management. I do not understand why CEP needs to deal with SONET/SDH negative and positive pointer adjustments. The SONET/SDH pointer adjustment is needed to compensate for any differences in rates between the SONET/SDH path and the SONET/SDH line rate. At the ingress side of the network, the SONET/SDH line overhead is terminated and the SONET/SDH path is fragmented and carried as packets. At the egress side of the network, the fragments are reassembled into the SONET/SDH path and sent out over a SONET/SDH line interface. It's at the point where the path is mapped into the SONET/SDH line that pointer adjustments may or may not be needed. So I don't see why any pointer adjustment information needs to be relayed across the packet network. Can someone please clarify this point for me? Thanks Carmine --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --0-810892575-1056482815=:37867 Content-Type: text/html; charset=us-ascii
Hello,
 
I was reading over draft-ietf-pwe3-sonet-01 and I came across Section 6 which deals with SONET/SDH Pointer Management.
 
I do not understand why CEP needs to deal with SONET/SDH negative and positive pointer adjustments. The SONET/SDH pointer adjustment is needed to compensate for any differences in rates between the SONET/SDH path and the SONET/SDH line rate.
 
At the ingress side of the network, the SONET/SDH line overhead is terminated and the SONET/SDH path is fragmented and carried as packets.  At the egress side of the network, the fragments are reassembled into the SONET/SDH path and sent out over a SONET/SDH line interface. It's at the point where the path is mapped into the SONET/SDH line that pointer adjustments may or may not be needed.
 
So I don't see why any pointer adjustment information needs to be relayed across the packet network.
 
Can someone please clarify this point for me?
 
Thanks
Carmine

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! --0-810892575-1056482815=:37867-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Shah, Himanshu" Subject: RE: status signalling of MPLS PW state Date: Mon, 23 Jun 2003 18:34:11 -0400 Lines: 304 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C339D7.915DA090" Cc: "Andrew G. Malis" , pwe3@ietf.org, "Mark Townsley (E-mail)" X-From: pwe3-admin@ietf.org Tue Jun 24 23:18:57 2003 Return-path: To: "'Luca Martini'" , Hamid Ould-Brahim X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 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_01C339D7.915DA090 Content-Type: text/plain; charset="iso-8859-1" You need to add more text/clarifications on when PE should/should not send the status signaling and how reciever should process it. The last thing you want is deadlock due to inter dependant status msgs. /himanshu Ciena networks > -----Original Message----- > From: Luca Martini [mailto:luca@level3.net] > Sent: Monday, June 23, 2003 5:47 PM > To: Hamid Ould-Brahim > Cc: Andrew G. Malis; pwe3@ietf.org; Mark Townsley (E-mail) > Subject: Re: [PWE3] status signalling of MPLS PW state > > > Does anybody else agree with this different way of writing this ? > I think that pretty much either way works. > > Luca > > > Hamid Ould-Brahim wrote: > > Luca, > yes , i did that , look in the iana draft, it's > in there. I > > > left it in this > > > thread for discussion only. > > Okay. I looked at the PW-IANA draft. I think that part needs to be > > reworked in order to reflect exactly the usage of the > status field. In > > pw-iana draft: " As specified in [1], a new PW status > TLV contains a > > 32 bit field, PW > > status value 0 is reserved to clear all failures. PW > Status Bits 0 > > through 4 are defined in this document. PW Status Bits 6 > through 15 > > are to be assigned by IANA using the "IETF Consensus" > policy defined > > in RFC2434. PW Status Bits 16 through 23 are to be > assigned by IANA, > > using the "First Come First Served" policy defined in RFC2434. PW > > Status Bits 24 through 31 are vendor-specific, and values in this > > range are not to be assigned by IANA. > > > > PW status is a 4 octet bit field as follows: > > > > 0x00000000 - Pseudo Wire forwarding ( clear all > failures ) > > 0x00000001 - Pseudo Wire Not Forwarding > > 0x00000002 - Local Customer-facing PW ( ingress > ) Receive Fault > > 0x00000004 - Local Customer-facing PW ( egress ) > Transmit Fault > > 0x00000008 - Local PSN-facing PW ( ingress ) > Receive Fault > > 0x00000010 - Local PSN-facing PW ( egress ) > Transmit Fault" > > Since the structure is a bit field and since in that structure some > > bits/set of bits are reserved. The above codepoints do not exactly > > reflect the intent. For example, it is not that 0x00000002 > that makes > > the local customer-facing PW receive fault but it is the > setting of bit > > number 1 that indicates this problem is happening. I > suggest to layout > > the bit structure with each bit having its own description. > Using the > > pw-IANA description above (btw I think there is a typo with > respect to > > bit number 5 which appears as 6 in the iana draft), my > suggestion is to > > rewrite the above to: 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |N|I|E|R|T| IANA ASSIGNED | IANA FCFS | VENDOR | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > N: The "not forwarding bit". When this bit is set, it > indicates the > > PE sending the status is in "not forwarding" state. > > I: Local Customer-facing PW ( ingress ) Receive Fault > > E: Local Customer-facing PW ( egress ) Transmit Fault > > R: Local PSN-facing PW ( ingress ) Receive Fault > > T: Local PSN-facing PW ( egress ) Transmit Fault > > > > A value of 0x00000000 is reserved and indicates that the status > > of the Pseudo-wire is forwarding. Obviously the > NIERT bits can > > be set independently (and that makes status combination). > > Hamid. > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C339D7.915DA090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] status signalling of MPLS PW state

You need to add more text/clarifications on
when PE should/should not send the status
signaling and how reciever should process it.

The last thing you want is deadlock due to
inter dependant status msgs.

/himanshu
Ciena networks

> -----Original Message-----
> From: Luca Martini [mailto:luca@level3.net]
> Sent: Monday, June 23, 2003 5:47 PM
> To: Hamid Ould-Brahim
> Cc: Andrew G. Malis; pwe3@ietf.org; Mark = Townsley (E-mail)
> Subject: Re: [PWE3] status signalling of MPLS = PW state
>
>
> Does anybody else agree with this different way = of writing this ?
> I think that pretty much either way = works.
>
> Luca
>
>
> Hamid Ould-Brahim wrote:
> > Luca,   > yes , i did that , = look in the iana draft, it's
> in there. I
> >  > left it in this
> >  > thread for discussion = only.
> > Okay. I looked at the PW-IANA draft. I = think that part needs to be
> > reworked in order to reflect exactly the = usage of the
> status field.   In
> > pw-iana draft:   = "   As specified in [1], a new PW status
> TLV contains a
> > 32 bit field, PW
> >    status value 0 is = reserved to clear all failures. PW
> Status Bits 0
> >    through 4 are defined in = this document. PW Status Bits 6
> through 15
> >    are to be assigned by = IANA using the "IETF Consensus"
> policy defined
> >    in RFC2434. PW Status = Bits 16 through 23 are to be
> assigned by IANA,
> >    using the "First = Come First Served" policy defined in RFC2434. PW
> >    Status Bits 24 through = 31 are vendor-specific, and values in this
> >    range are not to be = assigned by IANA.
> >
> >    PW status is a 4 octet = bit field as follows:
> >
> = >            = 0x00000000 - Pseudo Wire forwarding ( clear all
> failures )
> = >            = 0x00000001 - Pseudo Wire Not Forwarding
> = >            = 0x00000002 - Local Customer-facing PW ( ingress
> ) Receive Fault
> = >            = 0x00000004 - Local Customer-facing PW ( egress )
> Transmit Fault
> = >            = 0x00000008 - Local PSN-facing PW ( ingress )
> Receive Fault
> = >            = 0x00000010 - Local PSN-facing PW ( egress )
> Transmit Fault"  
> > Since the structure is a bit field and = since in that structure some
> > bits/set of bits are reserved. The above = codepoints do not exactly
> > reflect the intent. For example, it is not = that 0x00000002
> that makes
> > the local customer-facing PW receive fault = but it is the
> setting of bit
> > number 1 that indicates this problem is = happening.   I
> suggest to layout
> > the bit structure with each bit having its = own description.
> Using the
> > pw-IANA description above (btw I think = there is a typo with
> respect to
> > bit number 5 which appears as 6 in the = iana draft), my
> suggestion is to
> > rewrite the above = to:       = 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
> >    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >    |N|I|E|R|T|  IANA = ASSIGNED      |   IANA = FCFS   |     VENDOR    = |
> >    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
> >
> >    N: The "not = forwarding bit". When this bit is set, it
> indicates the
> >       PE = sending the status is in "not forwarding" state.
> >    I: Local Customer-facing = PW ( ingress ) Receive Fault
> >    E: Local Customer-facing = PW ( egress ) Transmit Fault
> >    R: Local PSN-facing PW ( = ingress ) Receive Fault
> >    T: Local PSN-facing PW ( = egress ) Transmit Fault
> >
> >    A value of 0x00000000 is = reserved and indicates that the status
> >    of the Pseudo-wire is = forwarding.      Obviously the
> NIERT bits can
> > be set independently (and = that    makes status combination).
> > Hamid.
> > 
>
>
>
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C339D7.915DA090-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Ron Cohen" Subject: RE: SONET/SDH Pointers in draft-ietf-pwe3-sonet-01 Date: Wed, 25 Jun 2003 08:35:16 +0200 Lines: 62 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B5ECE88@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Jun 25 17:41:37 2003 Return-path: To: "'Carmine Daloia'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <89D0584BBFBFE74F9057A389BA3F239B5ECE88@gaya.lycium.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 Carmine, I think the best way to look at N,P PA indications in the CEP header as indications on the difference between the system clock and the actual SPE clock. CEP carries SONET SPE data. The difference between the SPE and the System clock is mapped by SONET to Pointer adjustments, and this information is carried across. There are several scenarios in which this information is useful. The most notable one is the use of the EPAR mechanism in common clock scenarios: EPAR: Explicit Pointer Adjustment Relay, described in this draft. Assume a common clock scenarios, were two PEs have effectively the same system clock. The SONET SPE rate may differ from this common clock. If the egress PE would be aware of the difference in rate, it would be able to play out the SPE data with this rate and make sure the jitter buffer does not overflow or underflow. The difference in rate is encoded in SONET by pointer adjustments. Therefore, if the ingress PE encode the SPE pointer adjustment and the egress PE replay the pointer adjustment on the egress SONET line, we are done, and the jitter buffer remains fixed. Hope this helps Ron -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Carmine Daloia Sent: Tuesday, June 24, 2003 9:27 PM To: pwe3@ietf.org Subject: [PWE3] SONET/SDH Pointers in draft-ietf-pwe3-sonet-01 Hello, I was reading over draft-ietf-pwe3-sonet-01 and I came across Section 6 which deals with SONET/SDH Pointer Management. I do not understand why CEP needs to deal with SONET/SDH negative and positive pointer adjustments. The SONET/SDH pointer adjustment is needed to compensate for any differences in rates between the SONET/SDH path and the SONET/SDH line rate. At the ingress side of the network, the SONET/SDH line overhead is terminated and the SONET/SDH path is fragmented and carried as packets. At the egress side of the network, the fragments are reassembled into the SONET/SDH path and sent out over a SONET/SDH line interface. It's at the point where the path is mapped into the SONET/SDH line that pointer adjustments may or may not be needed. So I don't see why any pointer adjustment information needs to be relayed across the packet network. Can someone please clarify this point for me? Thanks Carmine Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Ron Cohen" Subject: RE: Last Call: draft-ietf-pwe3-arch-04.txt Date: Wed, 25 Jun 2003 09:31:58 +0200 Lines: 94 Sender: pwe3-admin@ietf.org References: <89D0584BBFBFE74F9057A389BA3F239B5ECD4D@gaya.lycium.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Jun 25 17:46:42 2003 Return-path: To: "'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 Importance: Normal In-Reply-To: <89D0584BBFBFE74F9057A389BA3F239B5ECD4D@gaya.lycium.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 Danny, Please update the L2TPv3 reference from version 05 to 07 as well as the Month. It seems it went up two versions in a month. Thanks Ron > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Danny McPherson > Sent: Tuesday, June 17, 2003 4:17 PM > To: pwe3@ietf.org > Subject: [PWE3] Last Call: draft-ietf-pwe3-arch-04.txt > > > > Folks, > Consider this a two week Last Call for the PWE3 Architecture > document. Last Call ends on July 1, 2003. Please note that > issues recently discussed on the WG mailing list have been > incorporated into this version of the draft. > > -danny > > > ------ Forwarded Message > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > Date: Tue, 17 Jun 2003 07:57:35 -0400 > To: IETF-Announce: ; > Cc: pwe3@ietf.org > Subject: I-D ACTION:draft-ietf-pwe3-arch-04.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > Pseudo Wire Emulation Edge to Edge Working Group of the IETF. > > Title : PWE3 Architecture > Author(s) : S. Bryant, P. Pate > Filename : draft-ietf-pwe3-arch-04.txt > Pages : 46 > Date : 2003-6-16 > > This document describes an architecture for Pseudo Wire > Emulation Edge-to-Edge (PWE3). It discusses the emulation of > services (such as Frame Relay, ATM, Ethernet TDM and > SONET/SDH) over packet switched networks (PSNs) using IP or > MPLS. It presents the architectural framework for pseudo > wires (PWs), defines terminology, specifies the various > protocol elements and their functions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-04.tx t To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-arch-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-arch-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------ End of Forwarded Message From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Max Riegel Subject: Silence compression, a necessary feature for TDM emulation? Date: Thu, 26 Jun 2003 00:47:49 +0200 Lines: 42 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Jun 26 00:52:12 2003 Return-path: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en To: pwe3@ietf.org 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 It seems silence compression is considered an important feature of the TDM emulation. During the discussion on Tom's prposal for TDM emulation we agreed to keep silence compression out of the basic specification for TDM emulation. Is there a reason to add silence compression as an additional requirement in the TDM requirements I-D? Just silence compression, or should we go for some kind of generic data compression with reasonable efficiency for voice signals? Should payload compression be available for all kind of emulated circuits, or is it sufficient to limit it to some particular cases, e.g. n x DS0? What is the opinion of the working group? Bye Max Tim.Frost@Zarlink.Com wrote: > I'm curious about your assertion here "The only way to support silence suppression > is by using the AAL2 mode of TDMoIP". That is a very bold statement! > > There are several ways to support silence suppression, of which AAL2 is > one. What about VoIP, for example? AAL2 may be a good method, however, it > is not the _only_ way. > > Clearly CESoPSN does not have a mode for silence suppression. However, it > does not compete with the AAL2 mode from TDMoIP. There may be an argument > why we shouldn't support both TDMoIP's AAL1 mode and CESoPSN, since both > do basically the same thing, but AAL2 has a clear differentiating reason > for its existence, as you have pointed out. > > Therefore the presence of an AAL2 mode in TDMoIP is not an argument > against adopting CESoPSN. > > Regards, > Tim From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Yaakov Stein" Subject: RE: Silence compression, a necessary feature for TDM emulation? Date: Thu, 26 Jun 2003 08:56:01 +0300 Lines: 38 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Thu Jun 26 07:58:46 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] Silence compression, a necessary feature for TDM emulation? Thread-Index: AcM7bDKshx2XniegRlq0TjLtY+qWIAAOj6RA To: "Max Riegel" , Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Max,=20 > It seems silence compression is considered an important=20 > feature of the TDM emulation. During the discussion on Tom's prposal = for TDM=20 > emulation we agreed to keep silence compression out of the basic=20 > specification for TDM emulation. There are actually two distinct levels here, activity detection and silence compression. Activity detection is more general, and may be based on TDM signaling (on-hook vs. off-hook status) for simple cases. True "silence detection" or Voice Activity Detection (VAD) requires that the computational resources be available. I think leaving out discussion of activity detection based on signaling is a major lacuna. VAD is perhaps more specifically a voice-services issue, and perhaps beyond the scope of the TDM requirements document. > Just silence compression, or should we go for some kind of=20 > generic data compression with reasonable efficiency for voice signals? Silence "compression" is not really compression at all. I don't see the connection with data compression. Data compression is definitely out of scope here, as it is not TDM specific; but perhaps someone would like to write a draft on generic data compression for PWE. Y(J)S =20 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Nurit Sprecher Subject: RE: Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Date: Thu, 26 Jun 2003 09:39:49 +0200 Lines: 50 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Thu Jun 26 08:41:44 2003 Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, In discussions we had at Seabridge following my previous letter = regarding the CESoPSN debate, we decided that Seabridge shall not take a stand in = this matter. Consequently, please disregard my earlier position expressed in = my previous letter (below). Sincerely, Nurit. -----Original Message----- From: Nurit Sprecher [mailto:nurit.sprecher@SeabridgeNetworks.com] =20 Sent: Sunday, June 22, 2003 10:19 AM To: =91pwe3@ietf.org=92 Subject: RE: [PWE3] Re: I-D ACTION:draft-vainshtein-cesopsn-06.txt Hi, I have been passively following the debate over draft-vainshtein vs. draft-anavi for some time, and still don=92t understand one thing. draft-anavi uses techniques borrowed from ATM, in order to maintain compatibility to existing CES systems. It thus a pointer to maintains = frame alignment. draft-vainshtein maintains TDM frame alignment by always = sending an integral number of frames in a packet. Why do we need to maintain frame alignment at all? From the TDM reconstruction point of view, all we need is to play out the bits that = are in the receive buffer, and the TDM switch will take care of all the = rest. If a packet is lost, all we need to know is how many bits it contained = - so all we need is to have a constant size packet!1 I vote against = accepting draft-vainshtein. For the unstructured case we need a simpler method - just constant size packets! For those complex cases where we need structured (especially with CAS) = we might as well use draft-anavi. Nurit. _______________________________________________ pwe3 mailing list pwe3@ietf.org =20 https://www1.ietf.org/mailman/listinfo/pwe3 =20 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Amnon Ilan" Subject: RE: Silence compression, a necessary feature for TDM emulation? Date: Thu, 26 Jun 2003 09:49:23 +0200 Lines: 32 Sender: pwe3-admin@ietf.org References: <3EFA2695.7060304@siemens.com> Reply-To: X-From: pwe3-admin@ietf.org Thu Jun 26 08:49:43 2003 Return-path: To: "'Max Riegel'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3EFA2695.7060304@siemens.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 Max, > Is there a reason to add silence compression as an additional > requirement in the TDM requirements I-D? > IMO TDM requirements should relate to silence compression: it should be an optional feature (not a must). As Yaakov wrote, there are two basic approaches: 1. Adding and tearing-down specific DS0 channels from a trunk\bundle based on the signaling information. The requirement from the TDM-PW in this case is to be able to add and tear-down DS0 in "real-time" (the application should be able to snoop and parse the specific signaling protocol, but this has no implication to the TDM-PW itself). 2. Using VAD (voice activity detection) and CNG (comfort noise generation). The requirement from the TDM-PW in this case is to be able to send the coded CNG information across the PSN. This method is more general than the former, since it is independent of the signaling protocol on the TDM line. > Just silence compression, or should we go for some kind of > generic data > compression with reasonable efficiency for voice signals? > An issue relevant for that question is low-bit-rate coding for voice traffic. There should be an option for both sides of a TDM-PW to signal or have some payload type specifying the coder (with the TDMoIP approach this could be done using AAL2). This should also be an optional feature mentioned in the requirements. Amnon. From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Tim.Frost@Zarlink.Com Subject: RE: Silence compression, a necessary feature for TDM emulation? Date: Thu, 26 Jun 2003 09:50:00 +0100 Lines: 88 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "'Max Riegel'" , pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 26 10:53:45 2003 Return-path: To: X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Semi(Release 5.0.12 |February 13, 2003) at 06/26/2003 04:50:08 AM, Serialize complete at 06/26/2003 04:50:08 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 Max, As Amnon and Yaakov have pointed out, there are actually two issues here, suppressing unused channels and silence suppression. The first, turning off channels when not in use was accounted for in the DB-CES standard for ATM (af-vtoa-0085). However, as far as I am aware, this was not widely deployed. This was due to the fact that in order to obtain the Constant Bit Rate class of service in ATM, the bandwidth had to be provisioned anyway, so saving bandwidth using DB-CES didn't actually free up any bandwidth for anything else. For "carrier class" circuit emulation, I think we will have the same issues. In order to deliver full quality TDM, and meet any service level guarantees, it will be necessary to provision the bandwidth for the peak case. Therefore once again, there is not much point to suppressing unused channels. For "enterprise class" circuit emulation (e.g. across a corporate network or VPN), it may be a useful technique to save bandwidth, while accepting the drop in quality over use of the PSTN. Since a corporate network is usually small relative to the carrier networks, this drop in quality may not necessarily be large. Therefore I would support the suppression of unused channels being an _optional_ requirement. Silence suppression is another topic entirely, due to its intensive DSP requirement. I agree with Yaakov that this is probably outside the scope of PWE3. Similarly with low-bit rate voice coding. Regards, Tim "Amnon Ilan" Sent by: pwe3-admin@ietf.org 26-Jun-2003 08:49 AM Please respond to ailan To: "'Max Riegel'" , cc: Subject: RE: [PWE3] Silence compression, a necessary feature for TDM emulation? Max, > Is there a reason to add silence compression as an additional > requirement in the TDM requirements I-D? > IMO TDM requirements should relate to silence compression: it should be an optional feature (not a must). As Yaakov wrote, there are two basic approaches: 1. Adding and tearing-down specific DS0 channels from a trunk\bundle based on the signaling information. The requirement from the TDM-PW in this case is to be able to add and tear-down DS0 in "real-time" (the application should be able to snoop and parse the specific signaling protocol, but this has no implication to the TDM-PW itself). 2. Using VAD (voice activity detection) and CNG (comfort noise generation). The requirement from the TDM-PW in this case is to be able to send the coded CNG information across the PSN. This method is more general than the former, since it is independent of the signaling protocol on the TDM line. > Just silence compression, or should we go for some kind of > generic data > compression with reasonable efficiency for voice signals? > An issue relevant for that question is low-bit-rate coding for voice traffic. There should be an option for both sides of a TDM-PW to signal or have some payload type specifying the coder (with the TDMoIP approach this could be done using AAL2). This should also be an optional feature mentioned in the requirements. Amnon. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stein-pwe3-stpp-00.txt Date: Thu, 26 Jun 2003 11:09:33 -0400 Lines: 80 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Jun 26 17:11:18 2003 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple TDM Pseudowire Protocol Author(s) : J. Stein, A. Ilan Filename : draft-stein-pwe3-stpp-00.txt Pages : 11 Date : 2003-6-26 This document describe a simple method for transporting time division multiplexed (TDM) digital voice and data signals over Pseudowires. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stein-pwe3-stpp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stein-pwe3-stpp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stein-pwe3-stpp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Max Riegel Subject: Re: Silence compression, a necessary feature for TDM emulation? Date: Thu, 26 Jun 2003 23:39:58 +0200 Lines: 104 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim.Frost@Zarlink.Com, ailan@mrv.com, yaakov_s@rad.com X-From: pwe3-admin@ietf.org Thu Jun 26 23:45:02 2003 Return-path: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en To: pwe3@ietf.org 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 It seems there is consensus, that we should add suppression of unused channels as an optional requirement to the TDM requirements I-D. Thank you Yakovv, Amnon and Tim for your explaination of the issues arising with silence compression. I agree that the voice activity detection requireing voice-service specific signal processing belongs to payload specifics and is outside the scope of wire emulation. We have already mentioned in chapter 7.5: PSN bandwidth utilization 3. The encapsulation layer MAY provide the ability to save the PSN bandwidth for the structured case by not sending sub-circuits that are inactive. This describes the static case of configuring a PW for a fixed number of channels. To extend the ability to dynamically suppress unused channels from transmission I would add: 4. The encapsulation layer MAY enable the dynamic suppression of temporally unused channels from transmission for the structured case. I think that such a kind of function makes only sense for structured circuits. Bye Max Tim.Frost@Zarlink.Com wrote: > As Amnon and Yaakov have pointed out, there are actually two issues here, > suppressing unused channels and silence suppression. > > ... > > Therefore I would support the suppression of unused channels being an > _optional_ requirement. > > Silence suppression is another topic entirely, due to its intensive DSP > requirement. I agree with Yaakov that this is probably outside the scope > of PWE3. Similarly with low-bit rate voice coding. > > Regards, > Tim > > > > > > "Amnon Ilan" > Sent by: pwe3-admin@ietf.org > 26-Jun-2003 08:49 AM > Please respond to ailan > > > To: "'Max Riegel'" , > cc: > Subject: RE: [PWE3] Silence compression, a necessary feature for TDM emulation? > > > Max, > > >>Is there a reason to add silence compression as an additional >>requirement in the TDM requirements I-D? >> > > IMO TDM requirements should relate to silence compression: it > should be an optional feature (not a must). > As Yaakov wrote, there are two basic approaches: > 1. Adding and tearing-down specific DS0 channels from a trunk\bundle > based on the signaling information. > The requirement from the TDM-PW in this case is to be able to add > and tear-down DS0 in "real-time" (the application should be able > to snoop and parse the specific signaling protocol, but this > has no implication to the TDM-PW itself). > 2. Using VAD (voice activity detection) and CNG (comfort noise > generation). The requirement from the TDM-PW in this case is to > be able to send the coded CNG information across the PSN. > This method is more general than the former, since it is > independent of the signaling protocol on the TDM line. > > >>Just silence compression, or should we go for some kind of >>generic data >>compression with reasonable efficiency for voice signals? >> > > An issue relevant for that question is low-bit-rate coding for voice > traffic. There should be an option for both sides of a TDM-PW to > signal or have some payload type specifying the coder (with the > TDMoIP approach this could be done using AAL2). This should also > be an optional feature mentioned in the requirements. > > > Amnon. > > > > _______________________________________________ > 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: Raj Sarkar Subject: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) Date: Thu, 26 Jun 2003 15:59:06 -0700 Organization: N.E.T. http://www.net.com Lines: 190 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------461921DFA54501C9EE16D42C" X-From: pwe3-admin@ietf.org Fri Jun 27 01:03:51 2003 Return-path: X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de 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 This is a multi-part message in MIME format. --------------461921DFA54501C9EE16D42C Content-Type: multipart/alternative; boundary="------------FEF86C6B198C6997404748F2" --------------FEF86C6B198C6997404748F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is still a working document of the pwe3 group. ------- -------- -------- -------- | | | | | | | | ATM a ) O------OOOOOOOOOOOOOOOOOOOOOO---- O ( ATM b lport A VPC Terminatio to PN Tunnel to VPC Term lport B | | | | | | | ------- -------- -------- ------- For simplicity i am assuming that the PN Tunnel is an MPLS LSP which traverses over an MPLS core network. Now i want ATM Network a to talk to ATM Network b even without it being aware that the cells are travelling over an Non - ATM Network. Hypothetically, if we have two logical ports as in the diagram with signalling channels on them, for the ATM Network it would be like lport A -----(logical link) ------- lport B Hence, we can ideally tunnel signalling as well over the MPLS LSP. Why is this not a part of the working draft? It actually makes the signalling interworking with MPLS much simpler in case of an ATM-MPLS -ATM netowrk. The administrator just needs to create two logical ports on the CE. Now the PE adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. Now, following the draft recommendations the ATM cells are transported over the MPLS Network as well as the signalling packets. This will be much simpler if we want to create ATM Networks over MPLS. Also, when TE comes into the picture, we should remember that whenever we use VP Tunnels in actual ATM Network , the individual VC guarantees are lost anyway. For efficiency, the PE can add an LSP with different diffserv codepoints. So, the CE can create CBR Logical ports, VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF Queue or AF Queue in the PE Router. Hence, using the following approach we can do PNNI Tunelling across the MPLS Network and create virtual ATM Networks. Thanks, Raj Sarkar --------------FEF86C6B198C6997404748F2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,

This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is still a working document
of the pwe3 group.

                 -------                    --------                              --------              --------
                 |                 |                   |                     |                              |                     |              |                    |
   ATM a )               O------OOOOOOOOOOOOOOOOOOOOOO---- O                  ( ATM b
                          lport A             VPC Terminatio  to PN Tunnel to VPC Term         lport B
                                   |                   |                     |                              |                      |              |                   |
                 -------                   --------                               --------               -------

For simplicity i am assuming that the PN Tunnel is an MPLS LSP which traverses over an MPLS
core network.

Now i want ATM Network a to talk to ATM Network b even without it being aware that the
cells are travelling over an Non - ATM Network. Hypothetically, if we have two logical ports
as in the diagram with signalling channels on them,  for the ATM Network it would be like

                            lport A  -----(logical link) ------- lport B

Hence, we can ideally tunnel signalling as well over the MPLS LSP. Why is this not a part of the
working draft?

It actually makes the signalling interworking with MPLS much simpler in case of an ATM-MPLS
-ATM netowrk. The administrator just needs to create two logical ports on the CE. Now the PE
adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. Now, following the draft
recommendations the ATM cells are transported over the MPLS Network as well as the signalling packets. This will be much  simpler if we want to create ATM Networks over MPLS.

Also, when TE comes into the picture, we should remember that whenever we use VP Tunnels
in actual ATM Network , the individual VC guarantees are lost anyway. For efficiency, the
PE can add an LSP with different diffserv codepoints. So, the CE can create CBR Logical ports,
VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF Queue or AF Queue
in the PE Router.
 

Hence, using the following approach we can do PNNI Tunelling across the MPLS Network and
create virtual ATM Networks.

Thanks,
Raj Sarkar
 
  --------------FEF86C6B198C6997404748F2-- --------------461921DFA54501C9EE16D42C Content-Type: text/x-vcard; charset=us-ascii; name="raj_sarkar.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Raj Sarkar Content-Disposition: attachment; filename="raj_sarkar.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sarkar;Raj tel;fax:510-5744025 tel;home:510-6619123 tel;work:510-5742303 x-mozilla-html:FALSE org:net.com;ATM Broadband R & D version:2.1 email;internet:raj_sarkar@net.com title:Senior Software Engineer adr;quoted-printable:;;39639 Leslie Street =0D=0AApt 136;Fremont;CA;94538;United States x-mozilla-cpt:;-23232 fn:Raj Sarkar end:vcard --------------461921DFA54501C9EE16D42C-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Mustapha Aissaoui Subject: Re: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) Date: Fri, 27 Jun 2003 09:27:00 -0400 Organization: Alcatel Networks Corporaton Lines: 188 Sender: pwe3-admin@ietf.org References: <3EFB7ABA.9CCFE64F@net.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CC726C4D46DD66B02342BE84" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 27 20:23:37 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Raj Sarkar Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --------------CC726C4D46DD66B02342BE84 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Raj, the ability to model a LSP as a virtual link and to run PNNI routing and signaling control channels is already specified in the ATM Forum for ATM-MPLS network interworking. This specification allows the model below but does not even require VPCs. This document is currently in straw ballot and its title is: str-cs-atmmpls-01.01 Regards, Mustapha. ------------- Raj Sarkar wrote: > Hi All, > > This question is regarding the draft-ietf-pwe3-atm-encap-01.txt > which is still a working document > of the pwe3 group. > > ------- > -------- -------- > -------- > | | > | | > | | | | > ATM a ) O------OOOOOOOOOOOOOOOOOOOOOO---- > O ( ATM b > lport A VPC Terminatio to PN > Tunnel to VPC Term lport B > | > | | > | | | | > ------- > -------- -------- > ------- > > For simplicity i am assuming that the PN Tunnel is an MPLS LSP > which traverses over an MPLS > core network. > > Now i want ATM Network a to talk to ATM Network b even without it > being aware that the > cells are travelling over an Non - ATM Network. Hypothetically, if > we have two logical ports > as in the diagram with signalling channels on them, for the ATM > Network it would be like > > lport A -----(logical link) ------- lport B > > Hence, we can ideally tunnel signalling as well over the MPLS LSP. > Why is this not a part of the > working draft? > > It actually makes the signalling interworking with MPLS much > simpler in case of an ATM-MPLS > -ATM netowrk. The administrator just needs to create two logical > ports on the CE. Now the PE > adds a LSP which maps the logical ports (VP Tunnels) VPI to an > LSP. Now, following the draft > recommendations the ATM cells are transported over the MPLS > Network as well as the signalling packets. This will be much > simpler if we want to create ATM Networks over MPLS. > > Also, when TE comes into the picture, we should remember that > whenever we use VP Tunnels > in actual ATM Network , the individual VC guarantees are lost > anyway. For efficiency, the > PE can add an LSP with different diffserv codepoints. So, the CE > can create CBR Logical ports, > VBR Logical ports with CBR,VBR Traffic respectively and map it to > an EF Queue or AF Queue > in the PE Router. > > > Hence, using the following approach we can do PNNI Tunelling > across the MPLS Network and > create virtual ATM Networks. > > Thanks, > Raj Sarkar > > --------------CC726C4D46DD66B02342BE84 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Raj,
the ability to model a LSP as a virtual link and to run PNNI routing and signaling control channels is already specified in the ATM Forum for ATM-MPLS network interworking. This specification allows the model below but does not even require VPCs.

This document is currently in straw ballot and its title is: str-cs-atmmpls-01.01

Regards,
Mustapha.
-------------
Raj Sarkar wrote:

Hi All,

This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is still a working document
of the pwe3 group.

                 -------                    --------                              --------              --------
                 |                 |                   |                     |                              |                     |              |                    |
   ATM a )               O------OOOOOOOOOOOOOOOOOOOOOO---- O                  ( ATM b
                   lport A             VPC Terminatio  to PN Tunnel to VPC Term         lport B
                                   |                   |                     |                              |                      |              |                   |
                 -------                   --------                               --------               -------

For simplicity i am assuming that the PN Tunnel is an MPLS LSP which traverses over an MPLS
core network.

Now i want ATM Network a to talk to ATM Network b even without it being aware that the
cells are travelling over an Non - ATM Network. Hypothetically, if we have two logical ports
as in the diagram with signalling channels on them,  for the ATM Network it would be like

                     lport A  -----(logical link) ------- lport B

Hence, we can ideally tunnel signalling as well over the MPLS LSP. Why is this not a part of the
working draft?

It actually makes the signalling interworking with MPLS much simpler in case of an ATM-MPLS
-ATM netowrk. The administrator just needs to create two logical ports on the CE. Now the PE
adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. Now, following the draft
recommendations the ATM cells are transported over the MPLS Network as well as the signalling packets. This will be much  simpler if we want to create ATM Networks over MPLS.

Also, when TE comes into the picture, we should remember that whenever we use VP Tunnels
in actual ATM Network , the individual VC guarantees are lost anyway. For efficiency, the
PE can add an LSP with different diffserv codepoints. So, the CE can create CBR Logical ports,
VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF Queue or AF Queue
in the PE Router.
 

Hence, using the following approach we can do PNNI Tunelling across the MPLS Network and
create virtual ATM Networks.

Thanks,
Raj Sarkar
 
 

--------------CC726C4D46DD66B02342BE84-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Matthew.Bocci@alcatel.co.uk Subject: Re: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) Date: Fri, 27 Jun 2003 08:52:45 +0100 Lines: 174 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; Boundary="0__=0FBBE7C1DFBBDDD18f9e8a93df938690918c0FBBE7C1DFBBDDD1" Cc: pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 27 20:31:08 2003 Return-path: To: Raj Sarkar X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/27/2003 09:15:21 Content-Disposition: inline Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --0__=0FBBE7C1DFBBDDD18f9e8a93df938690918c0FBBE7C1DFBBDDD1 Content-type: text/plain; charset=us-ascii Raj, Please see some comments below. Best regards, Matthew ----------------------------------------- Matthew Bocci Office of the CTO Alcatel Fixed Networks Division ----------------------------------------- |---------+---------------------------> | | Raj Sarkar | | | | | | Sent by: | | | pwe3-admin@ietf.| | | org | | | | | | | | | 26/06/2003 23:59| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | To: pwe3@ietf.org | | cc: | | Subject: [PWE3] Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) | >-------------------------------------------------------------------------------------------------------------------------------| Hi All, This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is still a working document of the pwe3 group. ------- -------- -------- -------- | | | | | | | | ATM a ) O------OOOOOOOOOOOOOOOOOOOOOO---- O ( ATM b lport A VPC Terminatio to PN Tunnel to VPC Term lport B | | | | | | | ------- -------- -------- ------- For simplicity i am assuming that the PN Tunnel is an MPLS LSP which traverses over an MPLS core network. Now i want ATM Network a to talk to ATM Network b even without it being aware that the cells are travelling over an Non - ATM Network. Hypothetically, if we have two logical ports as in the diagram with signalling channels on them, for the ATM Network it would be like lport A -----(logical link) ------- lport B Hence, we can ideally tunnel signalling as well over the MPLS LSP. Why is this not a part of the working draft? Matthew> What you describe is the port trunking service, which has been discussed at length on this list in the past, but I think it was decided to separate the encapsulations from the services that you could implement with them. You can implement this service using encapsulations described in the draft, depending on whether the logical link in the above diagram is the PSN tunnel, or the Pseudo-Wire. However, there are a number of issues with this service that make it harder to implement than might at first appear. The first issue is that ATM traffic contracts are defined on a per-ATM connection basis, not per-port. This makes it more difficult to apply traffic management to pseudo-wires to support ATM QoS without over-provisioning. There were also issues raised with regard to OAM and fault management. It actually makes the signalling interworking with MPLS much simpler in case of an ATM-MPLS -ATM netowrk. The administrator just needs to create two logical ports on the CE. Now the PE adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. Now, following the draft recommendations the ATM cells are transported over the MPLS Network as well as the signalling packets. This will be much simpler if we want to create ATM Networks over MPLS. Matthew> Are you descibing tunnelling VPCs across the network (one VPI per logical port)? If so, this can be done with either the one to one or the N to one modes. As you correctly point out, tunnelling PNNI through the PSN is one of the simplest ways of interworking with the ATM control plane. This can be implemented without using a port trunking service and instead simply mapping the PNNI routing control channel and signalling channels to pseudo-wires, to transport the ATM control plane traffic. The ATM Forum has been working on an approach based on this for awhile now. Also, when TE comes into the picture, we should remember that whenever we use VP Tunnels in actual ATM Network , the individual VC guarantees are lost anyway. For efficiency, the PE can add an LSP with different diffserv codepoints. So, the CE can create CBR Logical ports, VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF Queue or AF Queue in the PE Router. Matthew> Put this a different way, if you use VPCs in an ATM network, the traffic contract is on the VPC. You must provision that VPC so that any QoS guarantees made to ATM VCs on it are supported. Hence, using the following approach we can do PNNI Tunelling across the MPLS Network and create virtual ATM Networks. Thanks, Raj Sarkar (See attached file: raj_sarkar.vcf) --0__=0FBBE7C1DFBBDDD18f9e8a93df938690918c0FBBE7C1DFBBDDD1 Content-type: application/octet-stream; name="raj_sarkar.vcf" Content-Disposition: attachment; filename="raj_sarkar.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOlNhcmthcjtSYWoNCnRlbDtmYXg6NTEwLTU3NDQwMjUNCnRlbDtob21l OjUxMC02NjE5MTIzDQp0ZWw7d29yazo1MTAtNTc0MjMwMw0KeC1tb3ppbGxhLWh0bWw6RkFMU0UN Cm9yZzpuZXQuY29tO0FUTSBCcm9hZGJhbmQgUiAmIEQNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRl cm5ldDpyYWpfc2Fya2FyQG5ldC5jb20NCnRpdGxlOlNlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg0K YWRyO3F1b3RlZC1wcmludGFibGU6OzszOTYzOSBMZXNsaWUgU3RyZWV0ID0wRD0wQUFwdCAxMzY7 RnJlbW9udDtDQTs5NDUzODtVbml0ZWQgU3RhdGVzDQp4LW1vemlsbGEtY3B0OjstMjMyMzINCmZu OlJhaiBTYXJrYXINCmVuZDp2Y2FyZA0K --0__=0FBBE7C1DFBBDDD18f9e8a93df938690918c0FBBE7C1DFBBDDD1-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Raj Sarkar Subject: Re: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) Date: Fri, 27 Jun 2003 11:16:05 -0700 Organization: N.E.T. http://www.net.com Lines: 194 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------291EA75EFBE0F34363F64143" Cc: pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Fri Jun 27 20:41:43 2003 Return-path: X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de To: Matthew.Bocci@alcatel.co.uk, mustapha.aissaoui@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 This is a multi-part message in MIME format. --------------291EA75EFBE0F34363F64143 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mustapha/Mathew, I saw the document and the explicit model of network interworking between ATM and MPLS. But the model suggested will work with any overlay network - ATM, Ethernet, FR as long as we use the concept of PN Tunnels. It is much easier for the administrator to just configure a a logical port on the CE and then tunnel the PNNI signalling across the overlay networks with the help of a PN Tunnel ( whatever it may be an LSP, L2TP Tunnel, IP VPN et al). On the PE, you just need to map the cells/PDUs coming on VPI X to PN Tunnel Y and again on the egress PE from PN Tunnel Y to VPI X. To Logical ports A and Logical ports B, it will be as if they are immediate neighbors and talking to each other. Regarding TE as i said it does not matter what the internal guarantees for the VCs are. Anyway , the administrator will ensure that while configuring the tunnel , he/she has enough bw associated with that tunnel.Also, anyway in an ATM Network, when you tunnel VCs through a VP, all the internal guarantees of the VCs are lost. We don't essentially require a one-to-one mapping from a VC to a pseudo-wire as you need thousands of pseudo wires which may be an administrative nightmare , especially if the VCs are signalled. This model is much easier for a Service Provider to understand - especially for those who have access and core ATM Networks and if they are running PNNI/AINI et al. They can simply replace the core with MPLS/IP and use the PNNI Tunneling thro PN Tunnels model to create virtual ATM networks. But i agree to the part that service interworking may not necessarily be a part of this draft but PROBABLY can be a part of the addendum. It will be a good workaround till the specs (both ATM Forum and IETF) are finalized. Thanks, Raj Sarkar Matthew.Bocci@alcatel.co.uk wrote: > > Raj, > > Please see some comments below. > > Best regards, > > Matthew > > ----------------------------------------- > Matthew Bocci > Office of the CTO > Alcatel Fixed Networks Division > ----------------------------------------- > > |---------+---------------------------> > | | Raj Sarkar | > | | | | com> | > | | Sent by: | > | | pwe3-admin@ietf.| > | | org | > | | | > | | | > | | 26/06/2003 23:59| > | | | > |---------+---------------------------> > >-------------------------------------------------------------------------------------------------------------------------------| > | | > | To: pwe3@ietf.org | > | cc: | > | Subject: [PWE3] Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) | > >-------------------------------------------------------------------------------------------------------------------------------| > > Hi All, > > This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is > still a working document > of the pwe3 group. > > ------- -------- > -------- -------- > | | | > | | | | > | > ATM a ) O------OOOOOOOOOOOOOOOOOOOOOO---- O > ( ATM b > lport A VPC Terminatio to PN Tunnel > to VPC Term lport B > | | > | | | | > | > ------- -------- > -------- ------- > > For simplicity i am assuming that the PN Tunnel is an MPLS LSP which > traverses over an MPLS > core network. > > Now i want ATM Network a to talk to ATM Network b even without it being > aware that the > cells are travelling over an Non - ATM Network. Hypothetically, if we have > two logical ports > as in the diagram with signalling channels on them, for the ATM Network it > would be like > > lport A -----(logical link) ------- lport B > > Hence, we can ideally tunnel signalling as well over the MPLS LSP. Why is > this not a part of the > working draft? > > Matthew> What you describe is the port trunking service, which has been > discussed at length on this list in the past, but I think it was decided to > separate the encapsulations from the services that you could implement with > them. You can implement this service using encapsulations described in the > draft, depending on whether the logical link in the above diagram is the > PSN tunnel, or the Pseudo-Wire. However, there are a number of issues with > this service that make it harder to implement than might at first appear. > The first issue is that ATM traffic contracts are defined on a per-ATM > connection basis, not per-port. This makes it more difficult to apply > traffic management to pseudo-wires to support ATM QoS without > over-provisioning. There were also issues raised with regard to OAM and > fault management. > > It actually makes the signalling interworking with MPLS much simpler in > case of an ATM-MPLS > -ATM netowrk. The administrator just needs to create two logical ports on > the CE. Now the PE > adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. Now, > following the draft > recommendations the ATM cells are transported over the MPLS Network as well > as the signalling packets. This will be much simpler if we want to create > ATM Networks over MPLS. > > Matthew> Are you descibing tunnelling VPCs across the network (one VPI per > logical port)? If so, this can be done with either the one to one or the N > to one modes. > As you correctly point out, tunnelling PNNI through the PSN is one of the > simplest ways of interworking with the ATM control plane. This can be > implemented without using a port trunking service and instead simply > mapping the PNNI routing control channel and signalling channels to > pseudo-wires, to transport the ATM control plane traffic. The ATM Forum has > been working on an approach based on this for awhile now. > > Also, when TE comes into the picture, we should remember that whenever we > use VP Tunnels > in actual ATM Network , the individual VC guarantees are lost anyway. For > efficiency, the > PE can add an LSP with different diffserv codepoints. So, the CE can create > CBR Logical ports, > VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF > Queue or AF Queue > in the PE Router. > > Matthew> Put this a different way, if you use VPCs in an ATM network, the > traffic contract is on the VPC. You must provision that VPC so that any QoS > guarantees made to ATM VCs on it are supported. > > Hence, using the following approach we can do PNNI Tunelling across the > MPLS Network and > create virtual ATM Networks. > > Thanks, > Raj Sarkar > > (See attached file: raj_sarkar.vcf) --------------291EA75EFBE0F34363F64143 Content-Type: text/x-vcard; charset=us-ascii; name="raj_sarkar.vcf" Content-Description: Card for Raj Sarkar Content-Disposition: attachment; filename="raj_sarkar.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sarkar;Raj tel;fax:510-5744025 tel;home:510-6619123 tel;work:510-5742303 x-mozilla-html:FALSE org:net.com;ATM Broadband R & D version:2.1 email;internet:raj_sarkar@net.com title:Senior Software Engineer adr;quoted-printable:;;39639 Leslie Street =0D=0AApt 136;Fremont;CA;94538;United States x-mozilla-cpt:;-23232 fn:Raj Sarkar end:vcard --------------291EA75EFBE0F34363F64143-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Akiva Sadovski Subject: RE: Silence compression, a necessary feature for TDM emula tion? Date: Sun, 29 Jun 2003 14:34:40 +0200 Lines: 142 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Sun Jun 29 13:41:02 2003 Return-path: To: "'Max Riegel'" , 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 Max, IMO you may add to chapter 7.5: 4. ... Channel inactivity detection is outside the scope as well as channel inactivity signalling to the remote PE (if smb needs this signalling) My 2c, Akiva > -----Original Message----- > From: Max Riegel [mailto:maximilian.riegel@siemens.com] > Sent: Thursday, June 26, 2003 11:40 PM > To: pwe3@ietf.org > Cc: Tim.Frost@Zarlink.Com; ailan@mrv.com; yaakov_s@rad.com > Subject: Re: [PWE3] Silence compression, a necessary feature > for TDM emulation? > > > It seems there is consensus, that we should add suppression of unused > channels as an optional requirement to the TDM requirements I-D. > > Thank you Yakovv, Amnon and Tim for your explaination of the issues > arising with silence compression. I agree that the voice activity > detection requireing voice-service specific signal processing > belongs to > payload specifics and is outside the scope of wire emulation. > > We have already mentioned in chapter 7.5: PSN bandwidth utilization > > 3. The encapsulation layer MAY provide the ability to > save the PSN > bandwidth for the structured case by not sending sub-circuits > that are inactive. > > This describes the static case of configuring a PW for a > fixed number of > channels. To extend the ability to dynamically suppress > unused channels > from transmission I would add: > > 4. The encapsulation layer MAY enable the dynamic suppression of > temporally unused channels from transmission for the > structured > case. > > I think that such a kind of function makes only sense for structured > circuits. > > Bye > Max > > Tim.Frost@Zarlink.Com wrote: > > As Amnon and Yaakov have pointed out, there are actually > two issues here, > > suppressing unused channels and silence suppression. > > > > ... > > > > Therefore I would support the suppression of unused > channels being an > > _optional_ requirement. > > > > Silence suppression is another topic entirely, due to its > intensive DSP > > requirement. I agree with Yaakov that this is probably > outside the scope > > of PWE3. Similarly with low-bit rate voice coding. > > > > Regards, > > Tim > > > > > > > > > > > > "Amnon Ilan" > > Sent by: pwe3-admin@ietf.org > > 26-Jun-2003 08:49 AM > > Please respond to ailan > > > > > > To: "'Max Riegel'" > , > > cc: > > Subject: RE: [PWE3] Silence compression, a > necessary feature for TDM emulation? > > > > > > Max, > > > > > >>Is there a reason to add silence compression as an additional > >>requirement in the TDM requirements I-D? > >> > > > > IMO TDM requirements should relate to silence compression: it > > should be an optional feature (not a must). > > As Yaakov wrote, there are two basic approaches: > > 1. Adding and tearing-down specific DS0 channels from a trunk\bundle > > based on the signaling information. > > The requirement from the TDM-PW in this case is to be able to add > > and tear-down DS0 in "real-time" (the application should be able > > to snoop and parse the specific signaling protocol, but this > > has no implication to the TDM-PW itself). > > 2. Using VAD (voice activity detection) and CNG (comfort noise > > generation). The requirement from the TDM-PW in this case is to > > be able to send the coded CNG information across the PSN. > > This method is more general than the former, since it is > > independent of the signaling protocol on the TDM line. > > > > > >>Just silence compression, or should we go for some kind of > >>generic data > >>compression with reasonable efficiency for voice signals? > >> > > > > An issue relevant for that question is low-bit-rate coding for voice > > traffic. There should be an option for both sides of a TDM-PW to > > signal or have some payload type specifying the coder (with the > > TDMoIP approach this could be done using AAL2). This should also > > be an optional feature mentioned in the requirements. > > > > > > Amnon. > > > > > > > > _______________________________________________ > > 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: Chris Metz Subject: Re: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) Date: Sun, 29 Jun 2003 09:27:23 -0700 Lines: 223 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Matthew.Bocci@alcatel.co.uk, mustapha.aissaoui@alcatel.com, pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Sun Jun 29 18:30:45 2003 Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Raj Sarkar In-Reply-To: <3EFC89E5.13A06B7@net.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hey Raj- The overlay models you describe come with the advantages (i.e. simplicity, transparency) and the burdens of any classic overlay approach. The burdens may be O(N^2) connection provisioning/managment scale and lack of per-connection QoS precision if we are using port or VP mode tunnels. An alternative approach to solving this problem based on control plane interworking mechanisms is explored in: http://ietf.org/internet-drafts/draft-metz-switched-atm-l2vpn-00.txt In this solution ATM signaling/routing is terminated on the PE and "interworked" into PSN signaling and routing for carriage across the PSN. So MP-BGP propagates ATM prefixes (just like VPNv4 prefixes in 2547) between PEs and PNNI/AINI signaling drives concurrent PWE3 signaling in real-time with the latter bearing the contents of a switched VPC or VCC. Why this approach over an overlay approach? Several reasons: - providers already run (or plan to run) 2547-based services in their networks (i.e. IP VPN). Supporting switched ATM connectivity becomes just another service managed on PE using familiar protocol machinery and operations. - providers can run a uniform set of PSN routing/signaling protocols. No need to extend PNNI adjacencies or create an overlay across the PSN which means you still have multiple networks to manage - PE needs awareness of per-connection attributions for that extra precision in making appropriate connection-to-PW mapping decisions, marking EXP/DSCP bits, performing CAC or maybe even driving PSN resource allocations. - need to work over non-MPLS networks (what if provider is IP-only?) - need to support service interworking between switched ATM end-points and end-points attached to PE via static or non-ATM links. - need to re-use leverage existing IETF PWE3 signaling/encaps (i.e. LDP, L2TPv3) and attendant mechanisms (i.e. LSP ping, VCCV, L2VPN IW) for management and troubleshooting of switched ATM connectivity across the PSN cloud. Cheers ... At 11:16 AM 6/27/2003 -0700, Raj Sarkar wrote: >Hi Mustapha/Mathew, > >I saw the document and the explicit model of network interworking >between ATM and MPLS. But the model suggested will work with any >overlay network - ATM, Ethernet, FR as long as we use the concept of >PN Tunnels. It is much easier for the administrator to just configure a >a logical port on the CE and then tunnel the PNNI signalling across >the overlay networks with the help of a PN Tunnel ( whatever it may be >an LSP, L2TP Tunnel, IP VPN et al). On the PE, you just need to map >the cells/PDUs coming on VPI X to PN Tunnel Y and again on the egress >PE from PN Tunnel Y to VPI X. To Logical ports A and Logical ports B, >it will be as if they are immediate neighbors and talking to each other. > >Regarding TE as i said it does not matter what the internal guarantees >for the VCs are. Anyway , the administrator will ensure that while >configuring the tunnel , he/she has enough bw associated with that >tunnel.Also, anyway in an ATM Network, when you tunnel VCs through a VP, >all the internal guarantees of the VCs are lost. > >We don't essentially require a one-to-one mapping from a VC to a >pseudo-wire as you need thousands of pseudo wires which may be an >administrative nightmare , especially if the VCs are signalled. > >This model is much easier for a Service Provider to understand - >especially for those who have access and core ATM Networks and if they >are running PNNI/AINI et al. They can simply replace the core with >MPLS/IP and use the PNNI Tunneling thro PN Tunnels model to create >virtual ATM networks. > >But i agree to the part that service interworking may not necessarily be >a part of this draft but PROBABLY can be a part of the addendum. It will >be a good workaround till the specs (both ATM Forum and IETF) are >finalized. > >Thanks, >Raj Sarkar > >Matthew.Bocci@alcatel.co.uk wrote: > > > > Raj, > > > > Please see some comments below. > > > > Best regards, > > > > Matthew > > > > ----------------------------------------- > > Matthew Bocci > > Office of the CTO > > Alcatel Fixed Networks Division > > ----------------------------------------- > > > > |---------+---------------------------> > > | | Raj Sarkar | > > | | > | | com> | > > | | Sent by: | > > | | pwe3-admin@ietf.| > > | | org | > > | | | > > | | | > > | | 26/06/2003 23:59| > > | | | > > |---------+---------------------------> > > > >-------------------------------------------------------------------------------------------------------------------------------| > > | > | > > | To: pwe3@ietf.org > | > > | cc: > | > > | Subject: [PWE3] Virtual ATM Networks over > IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) | > > > >-------------------------------------------------------------------------------------------------------------------------------| > > > > Hi All, > > > > This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is > > still a working document > > of the pwe3 group. > > > > ------- -------- > > -------- -------- > > | | | > > | | | | > > | > > ATM a ) O------OOOOOOOOOOOOOOOOOOOOOO---- O > > ( ATM b > > lport A VPC Terminatio to PN Tunnel > > to VPC Term lport B > > | | > > | | | | > > | > > ------- -------- > > -------- ------- > > > > For simplicity i am assuming that the PN Tunnel is an MPLS LSP which > > traverses over an MPLS > > core network. > > > > Now i want ATM Network a to talk to ATM Network b even without it being > > aware that the > > cells are travelling over an Non - ATM Network. Hypothetically, if we have > > two logical ports > > as in the diagram with signalling channels on them, for the ATM Network it > > would be like > > > > lport A -----(logical link) ------- lport B > > > > Hence, we can ideally tunnel signalling as well over the MPLS LSP. Why is > > this not a part of the > > working draft? > > > > Matthew> What you describe is the port trunking service, which has been > > discussed at length on this list in the past, but I think it was decided to > > separate the encapsulations from the services that you could implement with > > them. You can implement this service using encapsulations described in the > > draft, depending on whether the logical link in the above diagram is the > > PSN tunnel, or the Pseudo-Wire. However, there are a number of issues with > > this service that make it harder to implement than might at first appear. > > The first issue is that ATM traffic contracts are defined on a per-ATM > > connection basis, not per-port. This makes it more difficult to apply > > traffic management to pseudo-wires to support ATM QoS without > > over-provisioning. There were also issues raised with regard to OAM and > > fault management. > > > > It actually makes the signalling interworking with MPLS much simpler in > > case of an ATM-MPLS > > -ATM netowrk. The administrator just needs to create two logical ports on > > the CE. Now the PE > > adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. Now, > > following the draft > > recommendations the ATM cells are transported over the MPLS Network as well > > as the signalling packets. This will be much simpler if we want to create > > ATM Networks over MPLS. > > > > Matthew> Are you descibing tunnelling VPCs across the network (one VPI per > > logical port)? If so, this can be done with either the one to one or the N > > to one modes. > > As you correctly point out, tunnelling PNNI through the PSN is one of the > > simplest ways of interworking with the ATM control plane. This can be > > implemented without using a port trunking service and instead simply > > mapping the PNNI routing control channel and signalling channels to > > pseudo-wires, to transport the ATM control plane traffic. The ATM Forum has > > been working on an approach based on this for awhile now. > > > > Also, when TE comes into the picture, we should remember that whenever we > > use VP Tunnels > > in actual ATM Network , the individual VC guarantees are lost anyway. For > > efficiency, the > > PE can add an LSP with different diffserv codepoints. So, the CE can create > > CBR Logical ports, > > VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF > > Queue or AF Queue > > in the PE Router. > > > > Matthew> Put this a different way, if you use VPCs in an ATM network, the > > traffic contract is on the VPC. You must provision that VPC so that any QoS > > guarantees made to ATM VCs on it are supported. > > > > Hence, using the following approach we can do PNNI Tunelling across the > > MPLS Network and > > create virtual ATM Networks. > > > > Thanks, > > Raj Sarkar > > > > (See attached file: raj_sarkar.vcf) From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: "Xipeng Xiao" Subject: requirements draft version 06 Date: Sun, 29 Jun 2003 16:05:34 -0700 Lines: 143 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33E92.F1FDFC68" Cc: "Xipeng Xiao" , "Danny McPherson (E-mail)" , "Prayson Pate (E-mail)" X-From: pwe3-admin@ietf.org Mon Jun 30 01:08:40 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Thread-Topic: requirements draft version 06 Thread-Index: AcM+kvHD+m5XV8TTRb+x4PJiTwhcFg== 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_01C33E92.F1FDFC68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, =20 The requirements draft has been updated. The changes made in this = version are: =20 1. Added a subsection on checksum handling =20 4.1.4. Validation of PW-PDU =20 Most L2 frames have a checksum field to assure frame integrity. Every PWE3 service MUST specify whether the frame's checksum should be preserved across the PW, or should be removed at the ingress PE and then be re-calculated and inserted at the egress PE. For protocols such as ATM and FR, the checksum covers link-local information such as the circuit identifiers (e.g. FR DLCI or ATM VPI/VCI). With PWE3, the two ACs can have different circuit identifiers. Therefore, it would be more efficient to remove and recalculate the checksum. =20 2. Added a subsection on differentiating payload type =20 4.1.5. Conveyance of Payload Type Information =20 Under some circumstances, it is desirable to be able to distinguish PW traffic from other types of traffic such as IPv4 or IPv6 or OAM. For example, if ECMP is employed in a PSN, this additional distinguishability can be used to reduce the chance that PW packets get misordered by the load balancing mechanism. Some mechanism SHOULD provide this distinguishability if needed. Such mechanism MAY be defined in the PWE3 WG or other WGs. =20 3. Section 5.2 and 5.3 are reorganized. There is no change in substance. = All discussions related to handling native maintenance messages (from = the CEs) are now in section 5.2. Section 5.3 is dedicated to discussing = "PE-initiated maintenance messages" that are triggered by fault etc = (without the presence of native maintenance messages from the CEs). =20 =20 The draft can be accessed at the following link before it is officially = posted: = http://www.cse.msu.edu/~xiaoxipe/pwe3/draft-ietf-pwe3-requirements-06.txt= =20 thanks, =20 XiPeng ------_=_NextPart_001_01C33E92.F1FDFC68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi there,
 
The requirements draft has been = updated.  The=20 changes made in this version are:
 
1. Added a subsection on checksum=20 handling
 
4.1.4.  Validation of = PW-PDU
 
   Most L2 frames have a = checksum field=20 to assure frame integrity. Every
   PWE3 service MUST = specify=20 whether the frame's checksum should be
   preserved across = the PW,=20 or should be removed at the ingress PE and
   then be = re-calculated=20 and inserted at the egress PE. For protocols
   such as ATM = and FR,=20 the checksum covers link-local information such
   as the = circuit=20 identifiers (e.g. FR DLCI or ATM VPI/VCI). With PWE3,
   = the two=20 ACs can have different circuit identifiers. Therefore, = it
   would=20 be more efficient to remove and recalculate the checksum.
 
2. Added a subsection on = differentiating payload=20 type
 
4.1.5.  Conveyance of Payload Type = Information
 
   Under some circumstances, = it is=20 desirable to be able to distinguish
   PW traffic from = other types=20 of traffic such as IPv4 or IPv6 or OAM.
   For example, if = ECMP is=20 employed in a PSN, this additional
   distinguishability = can be=20 used to reduce the chance that PW packets
   get misordered = by the=20 load balancing mechanism. Some mechanism SHOULD
   provide = this=20 distinguishability if needed.  Such mechanism MAY = be
  =20 defined in the PWE3 WG or other WGs.
 
3. Section 5.2 and 5.3 are reorganized. = There is no=20 change in substance.  All discussions related to handling native=20 maintenance messages (from the CEs) are now in section 5.2.  = Section 5.3 is=20 dedicated to discussing "PE-initiated maintenance messages" that are = triggered=20 by fault etc (without the presence of native maintenance messages from = the=20 CEs). 
 
The draft can be accessed at the = following link=20 before it is officially posted: http://www.cse.msu.edu/~xiaoxipe/pwe3/draft-ietf-pwe3-requireme= nts-06.txt
 
thanks,
 
XiPeng
------_=_NextPart_001_01C33E92.F1FDFC68-- From pwe3-admin@ietf.org Wed Dec 27 16:41:45 2006 From: Danny McPherson Subject: Re: requirements draft version 06 Date: Mon, 30 Jun 2003 06:18:17 -0600 Lines: 53 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 Mon Jun 30 14:21:38 2003 Return-path: User-Agent: Microsoft-Entourage/10.0.0.1309 To: 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 Folks, Consider today the start of the two week last call *on these changes* to the Requirements document. Last call ends July 14. -danny On 6/29/03 5:05 PM, "Xipeng Xiao" wrote: > Hi there, > > The requirements draft has been updated. The changes made in this version > are: > > 1. Added a subsection on checksum handling > > 4.1.4. Validation of PW-PDU > > Most L2 frames have a checksum field to assure frame integrity. Every > PWE3 service MUST specify whether the frame's checksum should be > preserved across the PW, or should be removed at the ingress PE and > then be re-calculated and inserted at the egress PE. For protocols > such as ATM and FR, the checksum covers link-local information such > as the circuit identifiers (e.g. FR DLCI or ATM VPI/VCI). With PWE3, > the two ACs can have different circuit identifiers. Therefore, it > would be more efficient to remove and recalculate the checksum. > > 2. Added a subsection on differentiating payload type > > 4.1.5. Conveyance of Payload Type Information > > Under some circumstances, it is desirable to be able to distinguish > PW traffic from other types of traffic such as IPv4 or IPv6 or OAM. > For example, if ECMP is employed in a PSN, this additional > distinguishability can be used to reduce the chance that PW packets > get misordered by the load balancing mechanism. Some mechanism SHOULD > provide this distinguishability if needed. Such mechanism MAY be > defined in the PWE3 WG or other WGs. > > 3. Section 5.2 and 5.3 are reorganized. There is no change in substance. All > discussions related to handling native maintenance messages (from the CEs) are > now in section 5.2. Section 5.3 is dedicated to discussing "PE-initiated > maintenance messages" that are triggered by fault etc (without the presence of > native maintenance messages from the CEs). > > The draft can be accessed at the following link before it is officially > posted: > http://www.cse.msu.edu/~xiaoxipe/pwe3/draft-ietf-pwe3-requirements-06.txt > > thanks, > > XiPeng > > From bounce-ppvpn-121950@lyris.nortelnetworks.com Wed Dec 27 16:41:45 2006 From: Dave McDysan Subject: MPLS 2003 Conference - Submission Deadline Extended to July 3rd Date: Mon, 30 Jun 2003 14:03:50 -0400 Lines: 46 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-From: bounce-ppvpn-121950@lyris.nortelnetworks.com Mon Jun 30 20:08:21 2003 Return-path: To: ppvpn@nortelnetworks.com, l2vpn@ietf.org, l3vpn@ietf.org, Mpls , Pwe3 , Ccamp X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-SMTP-HELO: pmesmtp01.wcom.com X-SMTP-MAIL-FROM: dave.mcdysan@mci.com X-SMTP-RCPT-TO: ppvpn@nortelnetworks.com X-SMTP-PEER-INFO: pmesmtp01.wcom.com [199.249.20.1] 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 is 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 proposa= ls 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 a= t TPC@mpls2003.com by July 3, 2003 (this will= be the last extension.) See www.mpls2003.com for m= ore details. The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of coveri= ng 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:45 2006 From: Raj Sarkar Subject: Re: Virtual ATM Networks over IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) Date: Mon, 30 Jun 2003 15:00:54 -0700 Organization: N.E.T. http://www.net.com Lines: 310 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20030629085324.05067ed8@mail1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------4E013ED71B6A413476044D90" Cc: pwe3@ietf.org, pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Tue Jul 01 00:01:35 2003 Return-path: X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de To: Chris Metz Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-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. --------------4E013ED71B6A413476044D90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Chris, I read the document, Interesting... I have a few questions so I thought i will ask you: <1> In Section <1> Page 6 - you have mentioned that we need to have just a single session between the CE and the PE. What do you mean by a single session here? What i understand from the draft document is that if we have three physical links from the CE to the PE - each running PNNI , it will appear as 3 distinct PNNI links to the destination CE . Right? So , one instance of PWE3 Signalling will control these 3 instances of SAAL/PNNI signalling. Inside the PSN, all these distinct links are lost. Actually , i am interested to know how do you tunnel the distinct control traffic across the PSN if you have 3 distinct physical links each running PNNI across the PSN. <2> Do you think it is wise to make BGP more complex by extending support for ATM prefixes (BGP is complex anyway). Don't you think it is becoming the "workaround" protocol for any problem we have in the IP world. Why not use IP based addressing scheme here instead of extending the BGP support for ATM prefixes? [ Assuming that we have an one-to-one mapping between IP and ATM addresses and the Customer has the flexibility of changing its ATM addresses..]. Then the PE needs to convert the ATM prefixes to appropriate IP address and vice versa [Need to think about this ??] . <3> Now, tell me what happens when one of the nodes in the PSN fails and only some of the pseudo-wires travel across that node. Actually, what if the control traffic does not flow through a node , but a different node? In this case the source and dst CE will still be connected while the switched VCs may still get affected.. Actually once you explain <1> , <3> will be clear as well. <4> I saw that you have talked about the model i was proposing in Page 5 Introduction Section.1 . You talked that this approach has 2 drawbacks: (i) A set of PWs and associated PN tunnels must be configured prior in a partial or full mesh. (ii) QOS - per VC QOS. But, nowhere we have addressed this in this draft. So QOS is still a concern or follow the approach as specified in Section 7.1 By the way, just out of curiosity did you read the recent paper on IP QOS in IEEE Communication Magazine - "Scalability and Quality of Service : A Trade-off?" by Michael Welzl and Max Muhlhauser. Then, you will understand why i am saying that do we actually need to keep per flow state in the core , in this case is the PSN network. So, in conclusion, for the small CLECs or small business networks using ATM access, we can still use the VP Tunnel overlay approach, since (ii) is anyway not solved. Thanks, Raj Sarkar Chris Metz wrote: > > Hey Raj- > The overlay models you describe come with the advantages (i.e. simplicity, > transparency) and the burdens of any classic overlay approach. The burdens > may be O(N^2) connection provisioning/managment scale and lack of > per-connection QoS precision if we are using port or VP mode tunnels. > > An alternative approach to solving this problem based on control plane > interworking mechanisms is explored in: > > http://ietf.org/internet-drafts/draft-metz-switched-atm-l2vpn-00.txt > > In this solution ATM signaling/routing is terminated on the PE and > "interworked" into PSN signaling and routing for carriage across the PSN. > So MP-BGP propagates ATM prefixes (just like VPNv4 prefixes in 2547) > between PEs and PNNI/AINI signaling drives concurrent PWE3 signaling in > real-time with the latter bearing the contents of a switched VPC or VCC. > > Why this approach over an overlay approach? Several reasons: > > - providers already run (or plan to run) 2547-based services in their > networks (i.e. IP VPN). Supporting switched ATM connectivity becomes just > another service managed on PE using familiar protocol machinery and > operations. > > - providers can run a uniform set of PSN routing/signaling protocols. No > need to extend PNNI adjacencies or create an overlay across the PSN which > means you still have multiple networks to manage > > - PE needs awareness of per-connection attributions for that extra > precision in making appropriate connection-to-PW mapping decisions, marking > EXP/DSCP bits, performing CAC or maybe even driving PSN resource allocations. > > - need to work over non-MPLS networks (what if provider is IP-only?) > > - need to support service interworking between switched ATM end-points and > end-points attached to PE via static or non-ATM links. > > - need to re-use leverage existing IETF PWE3 signaling/encaps (i.e. LDP, > L2TPv3) and attendant mechanisms (i.e. LSP ping, VCCV, L2VPN IW) for > management and troubleshooting of switched ATM connectivity across the PSN > cloud. > > Cheers ... > > At 11:16 AM 6/27/2003 -0700, Raj Sarkar wrote: > >Hi Mustapha/Mathew, > > > >I saw the document and the explicit model of network interworking > >between ATM and MPLS. But the model suggested will work with any > >overlay network - ATM, Ethernet, FR as long as we use the concept of > >PN Tunnels. It is much easier for the administrator to just configure a > >a logical port on the CE and then tunnel the PNNI signalling across > >the overlay networks with the help of a PN Tunnel ( whatever it may be > >an LSP, L2TP Tunnel, IP VPN et al). On the PE, you just need to map > >the cells/PDUs coming on VPI X to PN Tunnel Y and again on the egress > >PE from PN Tunnel Y to VPI X. To Logical ports A and Logical ports B, > >it will be as if they are immediate neighbors and talking to each other. > > > >Regarding TE as i said it does not matter what the internal guarantees > >for the VCs are. Anyway , the administrator will ensure that while > >configuring the tunnel , he/she has enough bw associated with that > >tunnel.Also, anyway in an ATM Network, when you tunnel VCs through a VP, > >all the internal guarantees of the VCs are lost. > > > >We don't essentially require a one-to-one mapping from a VC to a > >pseudo-wire as you need thousands of pseudo wires which may be an > >administrative nightmare , especially if the VCs are signalled. > > > >This model is much easier for a Service Provider to understand - > >especially for those who have access and core ATM Networks and if they > >are running PNNI/AINI et al. They can simply replace the core with > >MPLS/IP and use the PNNI Tunneling thro PN Tunnels model to create > >virtual ATM networks. > > > >But i agree to the part that service interworking may not necessarily be > >a part of this draft but PROBABLY can be a part of the addendum. It will > >be a good workaround till the specs (both ATM Forum and IETF) are > >finalized. > > > >Thanks, > >Raj Sarkar > > > >Matthew.Bocci@alcatel.co.uk wrote: > > > > > > Raj, > > > > > > Please see some comments below. > > > > > > Best regards, > > > > > > Matthew > > > > > > ----------------------------------------- > > > Matthew Bocci > > > Office of the CTO > > > Alcatel Fixed Networks Division > > > ----------------------------------------- > > > > > > |---------+---------------------------> > > > | | Raj Sarkar | > > > | | > > | | com> | > > > | | Sent by: | > > > | | pwe3-admin@ietf.| > > > | | org | > > > | | | > > > | | | > > > | | 26/06/2003 23:59| > > > | | | > > > |---------+---------------------------> > > > > > >-------------------------------------------------------------------------------------------------------------------------------| > > > | > > | > > > | To: pwe3@ietf.org > > | > > > | cc: > > | > > > | Subject: [PWE3] Virtual ATM Networks over > > IP/MPLS(draft-ietf-pwe3-atm-encap-01.txt) | > > > > > >-------------------------------------------------------------------------------------------------------------------------------| > > > > > > Hi All, > > > > > > This question is regarding the draft-ietf-pwe3-atm-encap-01.txt which is > > > still a working document > > > of the pwe3 group. > > > > > > ------- -------- > > > -------- -------- > > > | | | > > > | | | | > > > | > > > ATM a ) O------OOOOOOOOOOOOOOOOOOOOOO---- O > > > ( ATM b > > > lport A VPC Terminatio to PN Tunnel > > > to VPC Term lport B > > > | | > > > | | | | > > > | > > > ------- -------- > > > -------- ------- > > > > > > For simplicity i am assuming that the PN Tunnel is an MPLS LSP which > > > traverses over an MPLS > > > core network. > > > > > > Now i want ATM Network a to talk to ATM Network b even without it being > > > aware that the > > > cells are travelling over an Non - ATM Network. Hypothetically, if we have > > > two logical ports > > > as in the diagram with signalling channels on them, for the ATM Network it > > > would be like > > > > > > lport A -----(logical link) ------- lport B > > > > > > Hence, we can ideally tunnel signalling as well over the MPLS LSP. Why is > > > this not a part of the > > > working draft? > > > > > > Matthew> What you describe is the port trunking service, which has been > > > discussed at length on this list in the past, but I think it was decided to > > > separate the encapsulations from the services that you could implement with > > > them. You can implement this service using encapsulations described in the > > > draft, depending on whether the logical link in the above diagram is the > > > PSN tunnel, or the Pseudo-Wire. However, there are a number of issues with > > > this service that make it harder to implement than might at first appear. > > > The first issue is that ATM traffic contracts are defined on a per-ATM > > > connection basis, not per-port. This makes it more difficult to apply > > > traffic management to pseudo-wires to support ATM QoS without > > > over-provisioning. There were also issues raised with regard to OAM and > > > fault management. > > > > > > It actually makes the signalling interworking with MPLS much simpler in > > > case of an ATM-MPLS > > > -ATM netowrk. The administrator just needs to create two logical ports on > > > the CE. Now the PE > > > adds a LSP which maps the logical ports (VP Tunnels) VPI to an LSP. Now, > > > following the draft > > > recommendations the ATM cells are transported over the MPLS Network as well > > > as the signalling packets. This will be much simpler if we want to create > > > ATM Networks over MPLS. > > > > > > Matthew> Are you descibing tunnelling VPCs across the network (one VPI per > > > logical port)? If so, this can be done with either the one to one or the N > > > to one modes. > > > As you correctly point out, tunnelling PNNI through the PSN is one of the > > > simplest ways of interworking with the ATM control plane. This can be > > > implemented without using a port trunking service and instead simply > > > mapping the PNNI routing control channel and signalling channels to > > > pseudo-wires, to transport the ATM control plane traffic. The ATM Forum has > > > been working on an approach based on this for awhile now. > > > > > > Also, when TE comes into the picture, we should remember that whenever we > > > use VP Tunnels > > > in actual ATM Network , the individual VC guarantees are lost anyway. For > > > efficiency, the > > > PE can add an LSP with different diffserv codepoints. So, the CE can create > > > CBR Logical ports, > > > VBR Logical ports with CBR,VBR Traffic respectively and map it to an EF > > > Queue or AF Queue > > > in the PE Router. > > > > > > Matthew> Put this a different way, if you use VPCs in an ATM network, the > > > traffic contract is on the VPC. You must provision that VPC so that any QoS > > > guarantees made to ATM VCs on it are supported. > > > > > > Hence, using the following approach we can do PNNI Tunelling across the > > > MPLS Network and > > > create virtual ATM Networks. > > > > > > Thanks, > > > Raj Sarkar > > > > > > (See attached file: raj_sarkar.vcf) > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 --------------4E013ED71B6A413476044D90 Content-Type: text/x-vcard; charset=us-ascii; name="raj_sarkar.vcf" Content-Description: Card for Raj Sarkar Content-Disposition: attachment; filename="raj_sarkar.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Sarkar;Raj tel;fax:510-5744025 tel;home:510-6619123 tel;work:510-5742303 x-mozilla-html:FALSE org:net.com;ATM Broadband R & D version:2.1 email;internet:raj_sarkar@net.com title:Senior Software Engineer adr;quoted-printable:;;39639 Leslie Street =0D=0AApt 136;Fremont;CA;94538;United States x-mozilla-cpt:;-23232 fn:Raj Sarkar end:vcard --------------4E013ED71B6A413476044D90--