From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PW Availability Date: Mon, 5 Apr 2004 13:42:44 -0400 Lines: 404 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Mon Apr 05 20:24:25 2004 Return-path: To: "'neil.2.harrison@bt.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Hi Neil, Continuing on the discussion about the definition of availability. NH> "there is need to aim for harmonisation of NP/availability metrics and objectives across all layer networks" I don't understand what we are harmonizing. It seems that all existing protocols use different ways of fault detection and performance measurements and Y.1711 introduces yet another way of doing things. Particular anomalies will be detected in one technology and not in another. E.g., if I am not mistaken, a four-second break would be detected in Y.1711 as a defect and would lead to a suspension of performance measurements, while the same break would not be registered as a defect in ATM. This is just one example. In earlier emails, you have pointed out other differences between the various technologies. Therefore, in today's world, an operator can not easily compare network performance data obtained in one technology with performance data obtained in another. Furthermore, networks are becoming increasingly divers. With IP VPN or VPLS services, nodes that do connectionless forwarding (i.e. the PEs) can be interconnected through large connection-oriented islands. A single IP VPN instances may have traffic passing through both ATM and Ethernet access networks and an MPLS core network. It seems to me that the only way Service Providers can deal with such a situation is by using sophisticated performance monitoring tools that gather information from the various independent network layers and islands and do the harmonization and sanitization off-line. In other words, the notion that we can create an OAM model in MPLS and turn that into a consistent end-to-end mechanism by proper layering, FDI, etc, does not seem to jibe with (1) the existence of legacy networks; and (2) the nature of tomorrow's services. Another wrinkle: BFD allows the operator to decide how often control messages are sent. The detection time of a defect is a multiple of the specified period. Therefore, if an operator decides to use an interval in the order of minutes, it does not make much sense to define availability with a granularity of seconds. I would conclude that it does not make much sense to define availability as part of a network layer OAM spec. If you have a clear definition of defects - depending on the tools that are used for failure detection - it should be up to an off-line performance monitoring tool to translate information on defects and performance measurements to harmonized indicators that are useful to the operator. Peter > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Tuesday, March 30, 2004 5:46 AM > To: busschbach@lucent.com; pwe3@ietf.org > Subject: RE: PW Availability > > > Thanks Peter.....I have some responses for you > in-line....sorry for the delay. regards, Neil > > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: 25 March 2004 20:49 > > To: Harrison,N,Neil,IKR2 R; pwe3@ietf.org > > Subject: RE: PW Availability > > > > > > Neil, > > > > I would be happy to add to > > draft-nadeau-pwe3-oam-msg-map-04.txt that a PW is declared > > unavailable if a defect persists for more than 10 seconds. > > However, at this point I am not sure what that means since I > > don't know how it affects anything that goes on in the network. > NH=> OK. But please note: > - you will have seen my explanation of the origins of the > definition of availability and how I think it should be > simplified, re how Y.1711 has addressed this. > - there is need to aim for harmonisation of > NP/availability metrics and objectives across all layer > networks.......this becomes even more obvious as a > requirement if there is no control over client/server layer > relationships (though as I have noted before some C/S > relationships between the 3 modes make far more sense than others) > - both availability and NP aspects can be sensibly > associated with trails. Only co-cs and co-ps modes have > trails. So for MPLS these metrics need to be associated with > an LSP. Sure you can try and associate them with a PW but we > don't network PWs, ie we do not switch, nest as > client/server, etc PWs since they are an adaptation function. > I know most folks seem to struggle to grasp this but it > is/will be a real limiting problem for MPLS....that is, a PW > lives in no-mans land between a given client (eg FR, ATM etc) > and either a cl-ps IP server layer or a co-ps MPLS server > layer. I am really puzzled however why folks find this hard > to understand technically? > > > > You have mentioned that it is important to recognize such a > > state, because it determines when Performance Monitoring > > should be started and stopped. However, from your response to > > my last email, it appears that a clear and realistic approach > > to Performance Monitoring does not exist yet. Therefore, I > > wonder what the point is of introducing concepts that may or > > may not be relevant in the future. > NH=> This is not a logical argument. If you don't get the > ordering right then yes for sure you have a self-fulfilling > prophecy that that there is no chance to get the NP aspects > sorted. However, if you do get the ordering right then when > you are ready to measure NP you have the right basis. NP is > 2nd order in importance to defect detection/handling. We > have not discussed NP issues yet. You can also easily end up > specifying way too many complex/unnecessary NP stuff that, in > terms of its real benefit in a network, is an illusion of > efficiency. The 'QoS challenges' are not about having loads > of classes in 1 mode, but they are all about how to deliver a > suite of public/private services that are consistently > meaningful across a large range of network load points, and > thus allow SPs the ability to charge a fair price for doing > so. Real networks run lightly loaded for most of their > working life (for lots of reasons). Having lots of QoS > classes won't help you with this goal if: > - you can't differentiate 'urgency' and > 'importance'......and this is one reason why there is a big > difference between having the co-ps mode trail (eg LSP) or > only the cl-ps mode pkt (eg IP) as the networked entity; > - resource sharing is allowed between traffic > classes....since this kills any sensible notion of 'QoS > differentiation' dead. > > > > Therefore, I propose that we add the following statements to > > draft-nadeau-pwe3-oam-msg-map-04.txt: > > > > a) in general (i.e. for other technologies), operators > > consider a connection unavailable of a defect persists for > > more than 10 seconds > > > > b) the interaction between PW fault management and > > Performance Monitoring is for further study. > NH=> OK, seems this group is hell-bent of defining all the > networking stuff round PWs rather than the LSP and pkt > networked entities of the co-ps and cl-ps modes respectively. > Its wrong of course, but I alone can't stop you. Some > further remarks below. > > > > Further comments in-line. > > > > Peter > > > > > -----Original Message----- > > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > > Sent: Wednesday, March 24, 2004 5:53 PM > > > To: busschbach@lucent.com; pwe3@ietf.org > > > Subject: RE: PW Availability > > > > > > > > > Peter.. > > > > > > > > Neil, > > > > > > > > A while ago we exchanged emails on the availability of Pseudo > > > > Wires. The relevant part is attached to this email. > > > > > > > > I agree with the observations you made, but my main question > > > > was not answered: if you emulate a service over PWs, > > > NH=> Can you define precisely what 'emulate' means here? > > > > > > > I meant "emulate" in the same way as it is used in all WG > > drafts and emails on this mailing list: the encapsulation of > > client traffic so as to transport it over a PSN. > NH=> Oh yes I know, that is why I asked you to flush this > point out. Its imprecise, and is thus a meaningless > statement. This is not a good starting point for operators > who regard MPLS as a key core target technology. I think its > high time folks stopped pretending MPLS is the same as > IP....its wrecking the potential of MPLS IMO. XoverMPLS is > not the same thing as XoverIP. We can manage trails in a > co-ps mode like MPLS, we cannot do that in a cl-ps mode like > IP. That is simply a fact which, for whatever reason, some > folks here seem unable (or more likely 'unwilling') to > comprehend/accept. Speaking as an engineer who has been > brought-up to believe in honesty and accuracy, I find this > 'sticking one's head in the sand' behaviour of ignoring the > truth rather disturbing. {Note - this is not the same as > saying I won't accept compromises....I have no problem with > that *providing* they are recognised as such (eg arch > violations) and we understand the implications of them. I > only have problems when folks tell me they are 'right' and > won't even recognise identified problems.} > > > > > > is it > > > > really necessary to measure Network Performance (NP) of the > > > > PW itself? > > > NH=> Pass. Depends on what the definition of 'emulation' > > > really meens (and I have no idea) and what a PW actually > > > is....to me its some form of adaptation. XoverIP could have > > > different perf to XoverMPLS....the defect behaviour is for > > > sure very different. I think folks really ought to > > > differentiate these 2 cases as they are obviously not the same. > > > > I may be naive, but I would think that Network Performance to > > the extend that it relates to SLAs should be independent of > > the network layers over which the service is carried. > NH=> The whole point of my repeated observations about the 3 > networking modes and client/server inheritance is to show > this is not true. The behaviour of a cl-ps mode network is > different to a that of a co-ps mode network is different to > that of a co-cs mode network. One introduces constraints to > the basic 'broadcast at source, filter at sink' mode (that > ethernet uses) to get these 3 wide-area modes.....and one > does this because they bring benefits in > scaling/design/operation/NP/mtce/etc....in other words the > network becomes simpler as we move towards the co-cs mode. > If not obvious, consider the fact that the co-cs mode has > *no* traffic/QoS classes at all.....and just think how much > simpler > routing/signalling/resource-accounting/fault-management/etc > is therefore. So if a co-cs mode is the server layer then > the client layer cannot get any better *inherited* NP than > this.....remember, each layer network will inherit the NP of > its server layer and this is recursive to the duct. There > are 9 combinations of client/server relationships between the > 3 modes.....some make more sense than others. We cannot be > prescriptive about this (and currently there are no stds that > describe this or control how many times one is allowed to go > up/down a network stack of different modes)....however we can > use common sense ;-) > > > > In fact, you assertion that defect behavior of IP and MPLS > > networks is so different that XoverIP and XoverMPLS should be > > considered as two totally different solutions suggests that > > NP measurements of X would yield completely different results > > in the two cases. I can't see why that would be desirable to > > Service Providers. > NH=> Can't you? Blimey that is of concern then. As a hint > go check real core network utilisations, esp when one has > uncertainty of behaviour under failure. But let me try and > help further: In a cl-ps network you only have one traffic > entity.....the pkt. In a co-ps network you have 2 traffic > entities.....the parent trail and the child pkt. The trail > is the dominant entity here. One can therefore provide > additional constraints to the co-ps mode that don't exist in > the cl-ps mode, eg you can explicitly control the directivity > by signalling, and the survivability of the parent trail > entity can be completely decoupled from the (child pkt) > traffic it carries.....a rather important feature IMO, esp > for VPNs (noting that this can be generalised to include all > client/server cases since these are, if you think about it, a > form of 'VPN'). Now if you really wanted to see the power > the co-ps mode can unlock for you I would need to get into a > discussion of what QoS/NP really means....but that is another > long story however. > > But hang on a minute......this should all be obvious to > network engineers. This is starting to feel like I am giving > some lecture on networking basics. > > > > > > > > > If a Service Provider measures NP on end-to-end > > > > ATM VCs, why is it necessary to obtain additional NP > > > > measurements on one specific segment? > > > NH=> To see where impairments are coming from say. In a more > > > general case if you have some global reference connection > > > with metrics A, B, C that have objectives a, b, c (to be met > > > over some period, eg month), you need some way to fairly > > > apportion these to partitions of the end-end path, eg to > > > countries or operator domains. So each partition need to > > > check its bit is within its apportioned target. > > > > > > > > Now, assuming that a Service Provider wants to measure NP of > > > > PWs, how does that work? > > > NH=> I have no idea....you are starting down the very > > > slippery slope of making a PW a networked entity....and it is > > > not (as yet anyway). > > > > I am not sure who started down the slippery slope. > NH=> I'll tell you then. It was those folks who wanted to > 'do' stuff like FR and ATM without deploying native > technologies. Quite understandable. However, its one thing > doing a cheap/cheerful expedient technology emulation (over > either IP or MPLS), but its quite another thing to then say > PWs are the basis of next gen networks for everybody. AFAI > can tell, the direction here is network convergence on > PWs.......but I think most operators want a convergence on > MPLS. But PWs are not even a layer network, and the real > layer networks of IP and MPLS are not the same.....if there > were the same then why did MPLS come into being in the first > place? Every time I make this observation folks ignore > it....I assume because its something some would rather was > not recognised (though these same folks don't seem to have a > problem recognising that SDH and OTNs are co-cs mode networks > when talking about GMPLS....there are some very strange > double-stds being applied here IMO). This attitude is not > healthy IMO. Its not allowing the full potential of MPLS to > be seen/developed, and IMO its also an attempt to hide (or > maybe justify) some arch violations of MPLS IMO. Now I know > there are religious/commercial factors at play here, but I am > trying to be brutally honest about 'networking truths'.....I > used to think that 'technical honesty/accuracy' was something > that was held in high esteem in IETF, but I have had to > change my views on that. > > > > I did not > > say there was a need for an availability state for PWs. You > > did. > NH=> Yes, but it is now a logical conclusion of what has been > done here. A PW is now a unifying adaptation function above > either an IP server layer network or an MPLS server layer > network.....but it does not exist in its own right as a layer > network interface.....you still have FR, ATM, or whatever > above this. We do not (as yet anyway) 'network' PWs but we > do network IP pkts and MPLS trails.....and pkts and trails > are quite different network entities. However, given the > status of this discussion I fear you either honestly don't > get this (which I find hard to believe in your case) or you > are unwilling to recognise it for some other reason. > > >I am actually arguing for the position that it doesn't > > make sense to measure NP for Pseudo Wires. > NH=> Good, that is something we agree on then. I am actually > arguing for an acceptance by the community that there are 3 > networks modes. SDH and OTNs belong to the co-cs mode. IP > and ethernet belongs to the cl-ps mode (though only IP has > proper addressing/routing). MPLS, ATM and FR belong to the > co-ps mode. These modes have fundamentally different > behaviours....that is why they were created in the first > place for goodness sake. These are simply > facts....pretending they are not true is not helping anyone > in the long-term. Now given your statement above, I > therefore have to assume that you also agree that the NP > needs to be associated with the real network then....so that > is either IP or MPLS. I want to associate *all* the > networked attributes (ie defects, availability, NP) with the > LSP in MPLS as its this that is the networked entity. One > manages trails in a co-ps mode network quite differently to > how one manages pkts in a cl-ps mode network. > > > > > > > > > I assume that it is based on > > > > comparing packet counts both at ingress and egress. Following > > > > the method proposed by Y.1711, performance measurements are > > > > stopped upon detection of a defect and restarted a certain > > > > period after the defects disappears and the connection is > > > > stable again. However, in general a defect exists some time > > > > before a connection end-point finds out. Therefore, a number > > > > of packets will have been dropped already. Rather than trying > > > > to minimize the effect of this time lag by specifying > > > > available/unavailable state, as Y.1711 does, would it not > > > > make more sense to sanitize the data in an off-line > > > > performance monitoring tool that can exclude counts taken > > > > just before the defect occurred? > > > NH=> Y.1711 has not defined any NP collection yet. Its more > > > important to get the basic defects, short-breaks and > > > unavailability bits done 1st. NP stuff can be added later on > > > this firm defect detection/handling basis. I can think of > > > some smart/simple ways of doing NP collection however.....the > > > details are not given in Y.1711 right now. One also has to be > > > aware of 'PDUs in flight'. > > > > > > > > In short: how exactly do Service Prodivers measure Network > > > > Performance? > > > NH=> Badly to date is my view. Why? Because the ordering I > > > mentioned in the mail below has never properly been executed > > > in the past. > > > > I am not sure what point you are trying to make. Service > > Providers (BT being one of them) have large networks in which > > they run ATM over SDH or SONET. I was not asking a rhetorical > > question. I am genuinely interested to learn more about > > operator experiences. > NH=> And the answer I gave is correct. We really do not do a > good job, because whilst I.610 may look superficially OK, > there are several problems with it....and they started > because folks initially focussed on NP/QoS and forgot about > the more basic defect detection/handling first. I can > explain but its yet another long story. > > > > However, if you say that even ATM-over-SDH > > is such a mess > NH=> No, SDH is fine. Its ATM's OAM that is not good in some > respects. The problem with ATM was that folks got far too > interested with NP metrics and defining lots of traffic > classes (we had 5 AALs at one stage).....a complexity that we > can now see was largely unnecessary....and they forgot about > attending to the less sexy basic stuff, like defining defects > and their detection/handling. So ATM's OAM is far from > ideal. I can explain why if you are really interested. > > > that decent Performance Monitoring is not possible, then what > > does that mean for our current work? > NH=> Which current work? Y.1711 is fine. It corrects the > problems in I.610. > > > Existing networks will > > not go away for a long time to come. > NH=> Agreed. That is why if we continue to screw things up > by not facing up to network arch truths early its us > operators who will be left paying for it for many years > hence. This is why I will not let folks off the hook who > continue to violate func arch rules just because it might > suit them right now in selling boxes. > > > We have to work with > > what we have. Especially with regards to PWE, I don't see how > > we can work on Performance Monitoring without taking existing > > protocols and techniques into account. > NH=> I would understand if you you were talking about going > back and trying to redo FR and ATM say. But one should not be > specifying stuff in stds that are still draft and known to be > flawed. We and other operators have not yet built our next > generation networks, ie a converged core on MPLS. PWs are > not a common deployed legacy technology. MPLS is only used > today in niche applications. We are very concerned about the > arch flaws in some types of MPLS and its missing functional > components. Similarly, we are also concerned about PWs that > are then based on these. We therefore do not regard these > technologies as legacy in the same way as FR or ATM. MPLS is > currently not fit for purpose as a future key convergence > technology. You appear to be insisting here that because > someone has made some errors in the past with some types of > MPLS that these must be visited on all future work and > imposed on all operators....why? We have the chance to > correct these. Why is it not possible to get the stds right > now based on respecting the func arch requirements? > > regards Neil > > From pwe3-admin@ietf.org Wed Dec 27 15:58:25 2006 From: neil.2.harrison@bt.com Subject: RE: PW Availability Date: Mon, 5 Apr 2004 22:01:34 +0100 Lines: 157 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 Tue Apr 06 00:03:07 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: PW Availability Thread-Index: AcQbNW44CSC1znkjTv6R2iCx/YO2GAABpWJQ To: , X-OriginalArrivalTime: 05 Apr 2004 21:01:40.0962 (UTC) FILETIME=[317A5C20:01C41B51] 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: , Hi Peter.....please see below. =20 > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: 05 April 2004 18:43 > To: Harrison,N,Neil,IKR2 R; pwe3@ietf.org > Subject: RE: PW Availability >=20 >=20 > Hi Neil, >=20 > Continuing on the discussion about the definition of availability. > =20 > NH> "there is need to aim for harmonisation of=20 > NP/availability metrics and objectives across all layer networks" >=20 > I don't understand what we are harmonizing. NH=3D> Yes, I can understand why it is confusing....esp given there are = (i) no rules to control which layer network can be a client or server to = some other layer network and (ii) how many such transitions could be = allowed in a given instance of some overall HRX across many operator = partitions for some application. Though I can actually see this = argument as being in favour of more harmonisation rather than against = it. > It seems that all=20 > existing protocols use different ways of fault detection and=20 > performance measurements and Y.1711 introduces yet another=20 > way of doing things. NH=3D> This was certainly not the intention. I agree we have had the = situation where each new technology that has emerged has done its own = thing wrt its functional components....these are things like addressing, = routing (required for all scalable modes) signalling (for the = co-ps/co-cs modes), OAM, etc. But if one agrees that: - all technologies map to one of these modes - we don't need lots of technologies belonging to the same = mode.....since they are all essentially doing the same job - but we do actually need the 3 modes since they are doing different = jobs (and as we move from cl-ps to co-ps to co-cs the increasing = constraints applied result in important design/operational = simplifications and benefits) .......then there ought to be a 'best-of-breed' way of doing things for = each mode. When I was looking at the best-of-breed defect detection/handling = solution for the co-ps mode the above thinking was central. In fact, I = can recall a conversation between myself and Maarten Vissers from a long = time ago where we agreed that to stop this re-invention of functional = components (in our case OAM) we ought to try and get it right next = time....we were, at the time, reflecting on the problems we had = uncovered in I.610 OAM for ATM because folks had not focussed on the = basics, but instead rushed off into the network performance/QoS stuff. = So Y.1710/11 is not just 'something different' yet again for the sake of = it, the intention was to try and get the basic defect detection/handling = right at the outset for any technology belonging to the co-ps mode. And if you think about many of the arguments I put forward for using = functional arch techniques and avoiding arch violations, it is again = based on trying to do thing right from the outset. > Particular anomalies will be detected in=20 > one technology and not in another. E.g., if I am not=20 > mistaken, a four-second break would be detected in Y.1711 as=20 > a defect and would lead to a suspension of performance=20 > measurements, while the same break would not be registered as=20 > a defect in ATM. This is just one example. In earlier emails,=20 > you have pointed out other differences between the various=20 > technologies. NH=3D> We cannot go back and re-spin ATM now. All I can argue for is = trying to so things right in the future based on lessons learnt. >=20 > Therefore, in today's world, an operator can not easily=20 > compare network performance data obtained in one technology=20 > with performance data obtained in another. NH=3D> I do agree (esp across technologies belonging to different = modes), but this is no argument for keep making mistakes is it....or = even making things worse? For example, the problems of ATM OAM I have = alluded to are small beer compare to the OAM problems that are created = by violating the architecture of the co-ps mode. I sincerely hope you = are not trying to tell me that mp2p constructions in the co-ps mode and = the resultant LSP-Ping is an advancement in network OAM for operators = are you? =20 >=20 > Furthermore, networks are becoming increasingly divers. With=20 > IP VPN or VPLS services, nodes that do connectionless=20 > forwarding (i.e. the PEs) can be interconnected through large=20 > connection-oriented islands. A single IP VPN instances may=20 > have traffic passing through both ATM and Ethernet access=20 > networks and an MPLS core network. NH=3D> Yes, the increasing complexity issue is a real concern. This is = also why it is increasingly important to properly understand what is = happening in functional architecture terms. When client/server layer = relationship are done right folks don't even notice them, eg when one = sees a 'cloud' diagram don't forget that between each of the nodes in = the client technology considered are (transparent) server layer trails. = This is so often taken for granted. This is why I am not at all = impressed with folks who think compressing a client layer network is a = 'good thing'....its isn't, its actually a 'bad thing'. >=20 > It seems to me that the only way Service Providers can deal=20 > with such a situation is by using sophisticated performance=20 > monitoring tools that gather information from the various=20 > independent network layers and islands and do the=20 > harmonization and sanitization off-line. NH=3D> The complexity we are seeing unfold today is not sustainable in = the long-term IMO......esp if the ability to deliver truly = differentiable/meaningful/consistent network services (both private and = public) over a range of load points is not possible. There are smarter = ways to do things IMO. However, I suspect we may have to learn these = the hard way. >=20 > In other words, the notion that we can create an OAM model in=20 > MPLS and turn that into a consistent end-to-end mechanism by=20 > proper layering, FDI, etc, does not seem to jibe with (1) the=20 > existence of legacy networks; and (2) the nature of=20 > tomorrow's services. NH=3D> It for sure won't happen if you do not plan for it. And it also = depends on how one views the role of MPLS. > =20 > Another wrinkle: BFD allows the operator to decide how often=20 > control messages are sent. The detection time of a defect is=20 > a multiple of the specified period. Therefore, if an operator=20 > decides to use an interval in the order of minutes, it does=20 > not make much sense to define availability with a granularity=20 > of seconds. NH=3D> I understand. So one consciously decides not to have consistent = defects, etc. That is workable within a single domain, but it means = there are problems when one wants to i/w with other operators. What is = the basis now? Is it bilaterally negotiated with no client layer alarm = suppression? What happens when a customer complains....how do we = identify the whose partition is breaking their apportionment (and how is = this apportionment decided?) of some end objective (and what are these = now)? Takes me back maybe 20 years if that is the case. >=20 > I would conclude that it does not make much sense to define=20 > availability as part of a network layer OAM spec. If you have=20 > a clear definition of defects - depending on the tools that=20 > are used for failure detection - it should be up to an=20 > off-line performance monitoring tool to translate information=20 > on defects and performance measurements to harmonized=20 > indicators that are useful to the operator. NH=3D> I can see what you are saying. Though as noted above when it = comes to defining global i/w cases then a lack of agreed metrics would = seem to be a problem. I would however assume, as a minimum, = consistent/automated defect detection/handling would be something most = operators would still like to see. General comment - I am arguing for more simplicity and consistency based = on past experience of not having this. I think you are arguing for more = choice and diversity also based on past experience of not having this. = Well, all I know is that our Ops folks have never been that happy in the = past with OAM (except perhaps with SDH) and they are for sure not = impressed with what they are getting today. But then if the Operator = community does not collectively argue/agree for what it wants then they = deserve no better than what they get. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: The IESG Subject: Document Action: 'PWE3 Architecture' to Informational RFC Date: Tue, 06 Apr 2004 18:22:58 -0400 Lines: 31 Sender: pwe3-admin@ietf.org Cc: Internet Architecture Board , RFC Editor , pwe3 mailing list , pwe3 chair , pwe3 chair X-From: pwe3-admin@ietf.org Wed Apr 07 00:24:05 2004 Return-path: X-test-idtracker: no 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: , The IESG has approved the following document: - 'PWE3 Architecture ' as an Informational RFC This document is the product of the Pseudo Wire Emulation Edge to Edge Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. RFC Editor Note: 3rd paragraph of Section 10: OLD: Protection mechanisms must also address the spoofing of tunneled PW data. The validation of traffic addressed to the PW Demultiplexer end-point is paramount in ensuring integrity of PW encapsulation. Security protocols such as IPSec [RFC2401] may be used by the PW Demultiplexer Layer in order to maintain the integrity of the PW by authenticating data between the PW Demultiplexer End-points. NEW: Protection mechanisms must also address the spoofing of tunneled PW data. The validation of traffic addressed to the PW Demultiplexer end-point is paramount in ensuring integrity of PW encapsulation. Security protocols such as IPSec [RFC2401] may be used by the PW Demultiplexer Layer in order to provide authentication and data integrity of data between the PW Demultiplexer End-points. From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Nick Weeds Subject: RE: Clarifications of Generalized ID FECs Date: Wed, 7 Apr 2004 15:24:06 +0100 Lines: 145 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Luca Martini'" , "pwe3@ietf.org (E-mail)" X-From: pwe3-admin@ietf.org Wed Apr 07 19:56:26 2004 Return-path: To: "'Wei Luo'" , 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: , Wei: Thanks for your reply. The L2VPN signaling draft is indeed clearer (especially section 2.3 paragraph 7), though it doesn't describe the Label Release usage as clearly as your reply. As you point out, the L2TP drafts are clear that Local End ID = SAII and Remote End ID = TAII. Eric & Wei: Do we have agreement to follow option (b) ? This means that we always set SAII = sender's local AII and TAII = remote AII, so that in a Label Release the SAII and TAII are reversed compared to the Label Mapping being released. The one drawback I see is that if the receiver doesn't understand the AGI, SAII and TAII IDs in a Label Mapping then it is unable to send a Label Release with the correct FEC. According to draft-ietf-pwe3-control-protocol-06.txt these IDs are application-specific, and I haven't yet seen any ID values specified, so failure to recognize the IDs does seem to be a possibility. I don't think this drawback arises in L2TP because a CDN ("disconnect") identifies the call by session ID instead of Local & Remote End IDs. I don't think this drawback in LDP is a show-stopper, but option (a) does avoid it. Nick. > -----Original Message----- > From: Wei Luo [mailto:luo@cisco.com] > Sent: 03 April 2004 01:49 > To: erosen@cisco.com; Nick Weeds > Cc: 'Luca Martini'; pwe3@ietf.org (E-mail) > Subject: Re: [PWE3] Clarifications of Generalized ID FECs > > > (resend with the complete response, hit the send button too > early by mistake) > > The L2VPN signaling draft that defines the usage of > Generalized ID FEC more or > less explains the scenario, and it could certainly be more > precise in future > revisions. > > 1. When PE1 sends a Label Mapping with SAII (Fred) and TAII > (Bill) to PE2, PE2 > treats it as a pseudowire connection request from PE1 to its > local attachment > named Bill. > > 2. PE2 examines whether it should accept this connection > request according to > its local configuration. If the attachment Bill is not > provisioned, it could > save the label binding for future use if using liberal > retention or discard it, > and the processing is complete. > > 3. If the attchment Bill is provisioned but with a targeted > PE other than PE1, > PE2 sends a Label Release with SAII (Bill) and TAII (Fred) to > PE1 and the error > code is set to "attachment bound to different PE". PE1 > treats the Label Release > message as the refusal of the original pseudowire connection request. > > 4. If the attachment Bill is provisioned with PE1 as the > targeted PE but with a > targeted attachment other than Fred, PE2 sends a Label > Release with SAII (Bill) > and TAII (Fred) and the error code is set to "attachment > bound to different > remote attachment". PE1 treats the Label Release message as > the refusal of the > original pseudowire connection request. > > In essence, SAII and TAII are properties pertaining to the > *bidirectional* > pseudowire instead of individual LSPs. Therefore, whenever > receiving a Label > message regardless its type, the TAII always correponds to an > attachment > provisioned locally, and the SAII always correponds to an > attachment provisioned > remotely. This is what described in option b) below. This > consistence > eliminates confusions often raised when mixing unidirectional LSP and > bidirectional pseudowire in the same context. It is also > consistent with the > other L2VPN signaling protocol. > > ---Wei > > > Nick> The sense of the SAII and TAII is clear in Label > Mapping messages, but > > Nick> the draft doesn't explicitly state the sense of the > SAII and TAII in > > Nick> LDP messages flowing in the reverse direction, > for example Label > > Nick> Release. Two possibilities come to mind: > > Nick> > > Nick> (a) The FEC TLV sent in a Label Release is the > same as the FEC TLV > > Nick> received in the Label Mapping being released > (but without the > > Nick> interface parameters). More generally, the FEC > TLV is the same in > > Nick> all LDP messages relating to the same LSP. > In a Label Release > > Nick> this means that the SAII is the remote peer's > AII and the TAII is > > Nick> the sender's local AII. > > Nick> > > Nick> (b) The FEC TLV sent in a Label Release is the > same as the FEC TLV > > Nick> sent in a Label Mapping (for the reverse LSP). > More generally, > > Nick> the SAII is always the sender's local AII and > the TAII is the > > Nick> remote peer's AII. In a Label Release this > means that the SAII > > Nick> and TAII are reversed compared to the > Label Mapping being > > Nick> released. > > > > Nick> Which of these is intended? > > > > Uh oh. After 10 minutes of intensive thought, and > having changed my mind > > three times during that period, I think I'd like to say > that the intention > > was (a). When you talk about a particular LSP, you > should use the FEC > > associated with that LSP, and a Label Release is about > the incoming LSP. > > However, comments of "but I interpreted it the other way" > are welcomed! > > > > > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Wei Luo Subject: Re: Clarifications of Generalized ID FECs Date: Wed, 07 Apr 2004 09:54:24 -0700 Lines: 167 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, "'Luca Martini'" , "pwe3@ietf.org (E-mail)" X-From: pwe3-admin@ietf.org Wed Apr 07 20:48:09 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en,zh-CN To: Nick Weeds 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: , Nick, Nick Weeds wrote: > Wei: Thanks for your reply. The L2VPN signaling draft is indeed clearer > (especially section 2.3 paragraph 7), though it doesn't describe the Label > Release usage as clearly as your reply. As you point out, the L2TP drafts > are clear that Local End ID = SAII and Remote End ID = TAII. > > Eric & Wei: > > Do we have agreement to follow option (b) ? > This means that we always set SAII = sender's local AII and TAII = remote > AII, so that in a Label Release the SAII and TAII are reversed compared to > the Label Mapping being released. > The one drawback I see is that if the receiver doesn't understand the AGI, > SAII and TAII IDs in a Label Mapping then it is unable to send a Label > Release with the correct FEC. In RFC3036, Section 3.4.1.1 " If it encounters a FEC Element type it cannot decode, it should stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error. " Based on the RFC text, if the receiver does not understand FEC 129, it should send a Notification message instead of a Label Release, and the Notification message does not contain a FEC TLV. So it should not be a problem for LDP signaling even if the receiver does not understand FEC 129. ---Wei > According to > draft-ietf-pwe3-control-protocol-06.txt these IDs are application-specific, > and I haven't yet seen any ID values specified, so failure to recognize the > IDs does seem to be a possibility. I don't think this drawback arises in > L2TP because a CDN ("disconnect") identifies the call by session ID instead > of Local & Remote End IDs. I don't think this drawback in LDP is a > show-stopper, but option (a) does avoid it. > > Nick. > > >>-----Original Message----- >>From: Wei Luo [mailto:luo@cisco.com] >>Sent: 03 April 2004 01:49 >>To: erosen@cisco.com; Nick Weeds >>Cc: 'Luca Martini'; pwe3@ietf.org (E-mail) >>Subject: Re: [PWE3] Clarifications of Generalized ID FECs >> >> >>(resend with the complete response, hit the send button too >>early by mistake) >> >>The L2VPN signaling draft that defines the usage of >>Generalized ID FEC more or >>less explains the scenario, and it could certainly be more >>precise in future >>revisions. >> >>1. When PE1 sends a Label Mapping with SAII (Fred) and TAII >>(Bill) to PE2, PE2 >>treats it as a pseudowire connection request from PE1 to its >>local attachment >>named Bill. >> >>2. PE2 examines whether it should accept this connection >>request according to >>its local configuration. If the attachment Bill is not >>provisioned, it could >>save the label binding for future use if using liberal >>retention or discard it, >>and the processing is complete. >> >>3. If the attchment Bill is provisioned but with a targeted >>PE other than PE1, >>PE2 sends a Label Release with SAII (Bill) and TAII (Fred) to >>PE1 and the error >>code is set to "attachment bound to different PE". PE1 >>treats the Label Release >>message as the refusal of the original pseudowire connection request. >> >>4. If the attachment Bill is provisioned with PE1 as the >>targeted PE but with a >>targeted attachment other than Fred, PE2 sends a Label >>Release with SAII (Bill) >>and TAII (Fred) and the error code is set to "attachment >>bound to different >>remote attachment". PE1 treats the Label Release message as >>the refusal of the >>original pseudowire connection request. >> >>In essence, SAII and TAII are properties pertaining to the >>*bidirectional* >>pseudowire instead of individual LSPs. Therefore, whenever >>receiving a Label >>message regardless its type, the TAII always correponds to an >>attachment >>provisioned locally, and the SAII always correponds to an >>attachment provisioned >>remotely. This is what described in option b) below. This >>consistence >>eliminates confusions often raised when mixing unidirectional LSP and >>bidirectional pseudowire in the same context. It is also >>consistent with the >>other L2VPN signaling protocol. >> >>---Wei >> >> > Nick> The sense of the SAII and TAII is clear in Label >>Mapping messages, but >> > Nick> the draft doesn't explicitly state the sense of the >> SAII and TAII in >> > Nick> LDP messages flowing in the reverse direction, >>for example Label >> > Nick> Release. Two possibilities come to mind: >> > Nick> >> > Nick> (a) The FEC TLV sent in a Label Release is the >>same as the FEC TLV >> > Nick> received in the Label Mapping being released >>(but without the >> > Nick> interface parameters). More generally, the FEC >>TLV is the same in >> > Nick> all LDP messages relating to the same LSP. >>In a Label Release >> > Nick> this means that the SAII is the remote peer's >>AII and the TAII is >> > Nick> the sender's local AII. >> > Nick> >> > Nick> (b) The FEC TLV sent in a Label Release is the >>same as the FEC TLV >> > Nick> sent in a Label Mapping (for the reverse LSP). >> More generally, >> > Nick> the SAII is always the sender's local AII and >> the TAII is the >> > Nick> remote peer's AII. In a Label Release this >>means that the SAII >> > Nick> and TAII are reversed compared to the >>Label Mapping being >> > Nick> released. >> > >> > Nick> Which of these is intended? >> > >> > Uh oh. After 10 minutes of intensive thought, and >>having changed my mind >> > three times during that period, I think I'd like to say >>that the intention >> > was (a). When you talk about a particular LSP, you >>should use the FEC >> > associated with that LSP, and a Label Release is about >>the incoming LSP. >> > However, comments of "but I interpreted it the other way" >>are welcomed! >> > >> > >> > >> > >> > >> > _______________________________________________ >> > pwe3 mailing list >> > pwe3@ietf.org >> > https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> > From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: PWE3 WG draft status Date: Wed, 14 Apr 2004 10:06:26 +0100 Organization: Cisco Systems, Inc. Lines: 50 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Apr 14 11:28:05 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "pwe3@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: , This is the current state of the PWE3 WG drafts. If there are any corrections, please let us know. Stewart/Danny RFC Editor ---------- draft-ietf-pwe3-arch-07.txt - INFO IESG Review ----------- draft-ietf-pwe3-requirements-08.txt - INFO (WG chairs investigating the hold-up) Completed Last Call ------------------- draft-ietf-pwe3-tdm-requirements-04.txt - INFO draft-ietf-pwe3-fragmentation-05.txt - STD draft-ietf-pwe3-ethernet-encap-05.txt - STD draft-ietf-pwe3-control-protocol-06.txt - STD draft-ietf-pwe3-atm-encap-04.txt - STD Ready for Last Call ------------------- draft-ietf-pwe3-frame-relay-02.txt (needs a refresh first) - STD draft-ietf-pwe3-satop-01.txt - STD draft-ietf-pwe3-sonet-04.txt - STD draft-ietf-pwe3-hdlc-ppp-encap-mpls-02.txt - STD Probably ready for Last Call - need Authors to confirm ---------------------------- draft-ietf-pwe3-cesopsn-00.txt - INFO draft-ietf-pwe3-tdmoip-00.txt - INFO Work in Progress ---------------- draft-ietf-pwe3-iana-allocation-03.txt (WG Chairs expect this to remain a draft until it is handed to IANA as a registry, and that it will not proceed to RFC) draft-ietf-pwe3-pw-mib-04.txt - STD draft-ietf-pwe3-pw-mpls-mib-05.txt - STD draft-ietf-pwe3-pw-tc-mib-04.txt - STD draft-ietf-pwe3-cep-mib-04.txt - STD draft-pwe3-enet-mib-04.txt (needs a name change) - STD draft-ietf-pwe3-pw-atm-mib-00.txt - STD draft-ietf-pwe3-vccv-02.txt - STD draft-ietf-pwe3-fcs-retention-00.txt - STD From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: Re: PWE3 WG draft status Date: Wed, 14 Apr 2004 14:33:40 +0100 Organization: Cisco Systems, Inc. Lines: 12 Sender: pwe3-admin@ietf.org References: <407CFF12.8020805@cisco.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Wed Apr 14 16:09:16 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: stbryant@cisco.com In-Reply-To: <407CFF12.8020805@cisco.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , > draft-ietf-pwe3-frame-relay-02.txt (needs a refresh first) - STD When I noted the need for a refresh in the status, it was because I thought that it had time expired. That was my mistake, the draft is current. However the draft has 17 authors which does not comply with http://www.rfc-editor.org/policy.html#policy.authlist Stewart From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Sasha Vainshtein Subject: RE: Re: PWE3 WG draft status Date: Wed, 14 Apr 2004 17:07:34 +0200 Lines: 50 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 Apr 14 16:24:48 2004 Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Stewart and all, I'd like to note that I've posted on this list a long list of issues I have with this draft. Actually I've done so twice: once after the -01 version and then (almost the same list) after the -02 version. So far none of these issuse have been addressed by the Editor and/or authors. One of these issues is related to Stewart's comment on the number of authors: actually, one of them is listed twice (otherwise there would be only 16 of them:-). Resolving this issue would make the task of reducing the number of authors ~6% easier. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Wednesday, April 14, 2004 3:34 PM > To: stbryant@cisco.com > Cc: pwe3@ietf.org > Subject: [PWE3] Re: PWE3 WG draft status > > > > > draft-ietf-pwe3-frame-relay-02.txt (needs a refresh first) - STD > > When I noted the need for a refresh in the status, it was > because I thought that it had time expired. That was my mistake, > the draft is current. > > However the draft has 17 authors which does not comply with > > http://www.rfc-editor.org/policy.html#policy.authlist > > Stewart > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Yet another iana allocation problem. Date: Wed, 14 Apr 2004 13:17:41 -0600 Lines: 10 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Apr 14 21:24:20 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029 X-Accept-Language: Italian [it],French/Canada [fr-CA],French/France [fr-FR],English/United States [en-US] To: pwe3 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: , The interface parameter: 0x0A 4 FCS retention indicator is also used in vccv as the VCCV parameter. Has anybody coded this ? Any issues in moving this value to 0x0c ? Luca From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: [Fwd: Comments draft-ietf-pwe3-frame-relay-02.txt] Date: Thu, 15 Apr 2004 16:57:44 +0100 Organization: Cisco Systems, Inc. Lines: 241 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Danny McPherson X-From: pwe3-admin@ietf.org Thu Apr 15 18:28:13 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "pwe3@ietf.org" , claude.kawa@sympatico.ca Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , There has been no comment to the list addressing Sasha's concerns WRT draft-ietf-pwe3-frame-relay-02.txt Resolution of these issues will gate us moving this draft to LC. Please will the editor and co-authors address these issues, either by correcting the draft text, or by placing on record the reason why the issue does not need to be addressed. Also, have the author's checked that the text is aligned with the other standards bodies definition of FR over PW? Thanks Stewart -------- Original Message -------- Subject: [PWE3] Comments draft-ietf-pwe3-frame-relay-02.txt Date: Wed, 4 Feb 2004 11:05:25 +0200 From: Sasha Vainshtein To: 'claude.kawa@sympatico.ca' CC: 'PWE3 WG (E-mail)' , Andrew G. Malis (E-mail) , Rao Cherukuri (E-mail) , David Sinicrope (E-mail) , Alik Shimelmits , Sharon Galtzur , Israel Sasson , Itsik Goldraich Claude and all, After having read the -02 draft I sorry to say that almost all my comments to the -01 version have remained unresolved. Please find below the (indented) text of the original comments with the added status of their resolution (marked [02-status]). In some cases I've added some fresh considerations and suggestions. Hopefully these comments will be useful. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Sasha Vainshtein > Sent: Sunday, July 06, 2003 12:48 PM > To: 'claude.kawa@polymtl.ca' > Cc: PWE3 WG (E-mail) > Subject: Comments draft-ietf-pwe3-frame-relay-01.txt > > > Claude and all, > Please see below several comments on the latest revision > of the FRoPW draft. Some of these are purely editorial nits, > while some other look to me like substantial omissions. > > 1. The Intro section defines the difference between one-to-one > and many-to-one modes like following: > > > Two mapping modes are defined between FR VCs and FR PWs: The first > one is called "one-to-one" mapping. because there is a one-to-one > correspondence between a FR VC and a pair of > unidirectional PWs. The > second mapping is called "many-to-one" mapping or "port > mode" because > multiple FR VCs assigned to a port are mapped to one pair of PWs. > > > I think that "unidirectional PWs" are not defined anywhere in the > PWE3 architecture. And somehow "unidirectional" is missing in the > definition of the "many-to-one" mode while the "pair" remains. > Pairs of PWs are also mentioned in the Reference Model section... > but Section 7.2 changes the language and discusses a pair of > (unidirectional) VC LSPs per a FR VC. And section 9 explicitly > refers to "a PW, i.e. a pair of VC LSPs"... > [02-status] - no change found. Of coures, this is mainly editorial stuff... > > 2. The PWE3 framework and PWE3 Protocol Layers drafts referenced > in the document has been merged into a common PWE3 architecure > document. > [02-status] - Done > > 3. Requirement to "detect detectable" transmission errors looks > somewhat vague. (I believe that nobody expects the FRoPW to detect > undetectable transmission errors:-) > [02-status] - almost no change (brackets have been placed around the word "detectable"). > > 4. The draft mentions padding at the end of the FRoPW packet "when > a pseudo-wire traverses a link that requires a minimum layer 2 > frame length". Since the PWE3 functionality resides exclusively > in the edge devices which are, at most, aware, of the > types of links they terminate, the text is misguiding. > a) Section 7.4.1.1 seems to define padding as part of the > ingress PE > functionality. It states that "If the link layer > protocol does not > have a minimum length requirement then Length_field is > set to zero > and no padding is required." Would this logic really be > implemented, > the egress PE would be unable to recover the actual > length of a short > FR frame if the PW crosses an Ethernet link somewhere > in the PSN core > while the ingress PE uses, say, POS for its connection > to the PSN. > b) The definition of padding characters in Section 7.3. > states that > "any 8-bit character with a decimal value from 0 to 255 > may be used as a padding character" as if 8-bit characters with > other decimal values exist... > IMO, padding is the function of the appropriate link > anywhere in the > network, and not of the PW IWF. The ingress PE must set > the length field > to sizeof (payload + FRoPW header) if this size is less > then 64 bytes, > otherwise the length field must be set to 0. The egress > PE then always > can recover the length of the payload. > And, of course, padding is irrelevant with and IP PSN. > [02-status] - No changes found. This is NOT an editorial comment, since the PWE3 Charter explicitly limits the PW functionality to the PEs! Please compare this text to the (IMHO, correct!) padding-related wording taken from draft-ietf-pwe3-atm-encap-04.txt: If the Pseudo Wire traverses a network link that requires a minimum frame size such as Ethernet as a practical example, with a minimum frame size of 64 octets, then such links will apply padding to the Pseudo Wire PDU to reach its minimum frame size. In this case the control word must include a length field set to the PDU length. A mechanism is required for the egress PE to detect and remove such padding. I suggest to copy and paste this text (assuming, of course, that the ATM draft authors do not object) as a replacement of all the padding-related considerations in the FR draft. Among other things, it would also make the draft shorter... > > 5. There are two "B" bits in the FRoPW control word (one carrying > the BECN bit of the encapsulated FR frame, and one belonging > to the fragmentation mechanism). > [02-status] - No changes found!!! > > 6. The draft says that D and F bits of the FRoPW header are "copied" > to DE and FECN bits of the recovered FR frame and then > explains that > a cleared bit can become set as the result of this "copying". > [02-status] - No changes found. This is mainly editorial stuff... > > 7. The following text seems superfluous: > > Re-ordering FRoPW packets is an implementation option but > requires that the sender numbers FRoPW packets. > > (Does anybody expect the egress PE to reorder unnumbered > packets?:-) > [02-status] - No changes found. In addition, I'd like to note that the draft seems controversial wrt numbering of FRoPW packets: on one hand, it states (in Section 4, item 3) that FR frames order must be preserved; on the other hand, it does not absolutely disallow using "unnumbered" packets (i.e. with the sequence number set to 0). The draft does not even preculde mixing numbered and unnumbered packets on the same FR PW. I suggest to state explicitly that such a mixture MUST NOT be used! And, BTW, Section 4 (Requirements) does not use the IETF all-capitals "MUST"s and "SHOULD"s even if Section 2 (Terminology) provides an appropriate reference to RFC 2119. Does this mean that these words are interpreted differently? E.g. "must" clauses do not specify absolute requirements? This would account for handling of the numbering issue in the draft... > > 8. Section 7.5 says that a FRoPW packet received with errors must be > silently discarded. It is not clear to which errors this section > refers: > a) Frames with L2 errors are (usually) discarded > regardless of being or > not being FRoPW packets (indeed, I am not sure one can identifiy > such frames as belonging to any specific PW) > b) No FRoPW specific errors are defined in the draft > c) In particular, it is not clear how to treat a packet > with L2 size > exceeding by far 64 bytes (after skipping the label stack) > and non-zero Length field. > [02-status] - No changes found. The draft actually says that in such a case the receiver must believe to what the Length field says (Section 7.4.2.2). This is acceptable and leaves just one possible FRoPW error to check: (Lenght-field != 0) && (Length_FRoPW_packet < Length-field). BTW, this case is not considered in the draft!!! > > 9. The draft does not specify whether the DE indications in > the FR frames > may be somehow reflected in the Diffserv markings of the > PSN headers. > (The WG Charter explicitly provides for such an activity.) > [02-status] - No changes found. I'd like to note that the draft mentions the need to map FR transfer and discard priorities to "appropriately engineered PWs and PSN tunnels" (Section 4, item 8). Since, AFAIK, PWs are not engineered and, in any case their parameters cannot be perceived by the PSN, the words "PWs and" seem superfluous. In other words, the QoS requirement is neither spelled out properly nor met! > > 10.With full respect to Steve Vogelsang, his name appears twice > in the list of the draft co-authors (but only once in the authors' > addresses list:-). > [02-status] - no changes found!!! > > Hopefully these comments will be useful. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Nick Weeds Subject: Clarifications of Generalized ID FECs Date: Thu, 1 Apr 2004 11:00:28 +0100 Lines: 62 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "pwe3@ietf.org (E-mail)" X-From: pwe3-admin@ietf.org Thu Apr 01 12:04:19 2004 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: , > Luca, > > A couple of points about Generalized ID FECs as described in > draft-ietf-pwe3-control-protocol-06.txt... > > > (1) Format of AGI, SAII, TAII vs interface parameters. > > I believe the intent is that the AGI, SAII and TAII are encoded as > ID+length+value, like interface parameters, and that the AGI, SAII and > TAII are distinguished from interface parameters by their ID bytes. > > However, there is a discrepancy between the length encoding for the AGI / > SAII / TAII and the length encoding for the interface parameters. > - Section 5.2.2 says that for AGI / SAII / TAII the length excludes the > ID+length header. > - Section 5.4 says that for interface parameters the length includes the > ID+length header. > > There has been confusion about the length encoding for interface > parameters in the past, but this has been corrected in > draft-ietf-pwe3-iana-allocation-03.txt. > > Is the discrepancy between the AGI / SAII / TAII and interface parameters > intentional? > > If not, can we bring the AGI / SAII / TAII into line with the interface > parameters? > > Using different formats for the two makes parsing the FEC element awkward, > especially as the AGI / SAII / TAII are all optional and their IDs not yet > specified. For example, it isn't possible to parse out the interface > parameters without additional information about the AGI / SAII / TAII ID > values . > > > (2) Sense of SAII and TAII on different LDP messages. > > The sense of the SAII and TAII is clear in Label Mapping messages, but the > draft doesn't explicitly state the sense of the SAII and TAII in LDP > messages flowing in the reverse direction, for example Label Release. Two > possibilities come to mind: > > (a) The FEC TLV sent in a Label Release is the same as the FEC TLV > received in the Label Mapping being released (but without the interface > parameters). More generally, the FEC TLV is the same in all LDP messages > relating to the same LSP. In a Label Release this means that the SAII is > the remote peer's AII and the TAII is the sender's local AII. > > (b) The FEC TLV sent in a Label Release is the same as the FEC TLV sent in > a Label Mapping (for the reverse LSP). More generally, the SAII is always > the sender's local AII and the TAII is the remote peer's AII. In a Label > Release this means that the SAII and TAII are reversed compared to the > Label Mapping being released. > > Which of these is intended? > > > Thanks, > > Nick. > From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: claude.kawa@sympatico.ca Subject: Re: [Fwd: Comments draft-ietf-pwe3-frame-relay-02.txt] Date: Fri, 16 Apr 2004 9:32:06 -0400 Lines: 30 Sender: pwe3-admin@ietf.org 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 Fri Apr 16 15:41:32 2004 Return-path: X-Mailer: Openwave WebEngine, version 2.8.6.6 (webedge20-101-174-112-20020617)" 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: , Stewart, We will address Shasha comments and ensure alignement of the draft with other texts on FR/PW. We will have a newd draft ready before the next IETF meeting in August. claude > > From: Stewart Bryant > Date: 2004/04/15 Thu AM 11:57:44 EST > To: "pwe3@ietf.org" , claude.kawa@sympatico.ca > CC: Danny McPherson > Subject: [Fwd: [PWE3] Comments draft-ietf-pwe3-frame-relay-02.txt] > > There has been no comment to the list addressing Sasha's > concerns WRT draft-ietf-pwe3-frame-relay-02.txt > Resolution of these issues will gate us moving this draft > to LC. > > Please will the editor and co-authors address these > issues, either by correcting the draft text, or by > placing on record the reason why the issue does not > need to be addressed. > > Also, have the author's checked that the text is aligned > with the other standards bodies definition of FR over PW? > > Thanks > > Stewart From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Danny McPherson Subject: Re: [Fwd: Comments draft-ietf-pwe3-frame-relay-02.txt] Date: Fri, 16 Apr 2004 09:27:01 -0600 Lines: 24 Sender: pwe3-admin@ietf.org References: <20040416133204.GFLT25045.tomts6-srv.bellnexxia.net@mxmta.bellnexxia.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Apr 16 17:50:18 2004 Return-path: In-Reply-To: <20040416133204.GFLT25045.tomts6-srv.bellnexxia.net@mxmta.bellnexxia.net> To: X-Mailer: Apple Mail (2.613) 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: , On Apr 16, 2004, at 7:32 AM, wrote: > We will address Shasha comments and ensure alignement > of the draft with other texts on FR/PW. We will have a > newd draft ready before the next IETF meeting in August. Claude, We'd really like to get this out of the WG and fully in the hands of the IESG (and back) well before the next IETF, (with the group of other services drafts) rather than simply posting a new draft in a few months. There's been plenty of time to respond to outstanding concerns. Stewart and I believe that it's reasonable to ask that the updates be done and a new draft posted within 4 weeks (i.e., by May 15). Given the current author list surely someone has the resources to address outstanding concerns from Sasha and others. If you have problems lining that person up let me know. Thanks! -danny From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "Andrew G. Malis" Subject: Re: Yet another iana allocation problem. Date: Fri, 16 Apr 2004 15:25:36 -0400 Lines: 21 Sender: pwe3-admin@ietf.org References: <407D8E55.3060301@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3 X-From: pwe3-admin@ietf.org Fri Apr 16 21:35:10 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: Luca Martini In-Reply-To: <407D8E55.3060301@cisco.com> References: <407D8E55.3060301@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: , Luca, This is OK to change to 0x0c. Once you release the next IANA allocation draft, I'll update the FCS retention draft. Cheers, Andy ----------- At 4/14/2004 01:17 PM -0600, Luca Martini wrote: >The interface parameter: > > 0x0A 4 FCS retention indicator > >is also used in vccv as the VCCV parameter. > >Has anybody coded this ? >Any issues in moving this value to 0x0c ? > >Luca From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "Shah, Himanshu" Subject: QOS signaling for PW Date: Fri, 16 Apr 2004 15:30:16 -0400 Lines: 114 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C423E9.3F3A8B50" X-From: pwe3-admin@ietf.org Fri Apr 16 21:37:14 2004 Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , 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_01C423E9.3F3A8B50 Content-Type: text/plain; charset="iso-8859-1" FYI.. /himanshu A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Qos Signaling for PW Author(s) : H. Shah, et al. Filename : draft-shah-pwe3-pw-qos-signaling-00.txt Pages : 7 Date : 2004-4-8 This document discusses how a tail-end PE can signal the Quality of Service parameters of the local Attachment Circuit to the head-end PE for appropriate Pseudowire generation from head to tail end PE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shah-pwe3-pw-qos-signaling-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shah-pwe3-pw-qos-signaling-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-shah-pwe3-pw-qos-signaling-00.txt". ------_=_NextPart_001_01C423E9.3F3A8B50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
FYI..
 
/himanshu
 
 
A New Internet-Draft is available from the on-line Internet-Drafts = directories.


Title : Qos Signaling for PW
Author(s) : = H. Shah,=20 et al.
Filename : draft-shah-pwe3-pw-qos-signaling-00.txt
Pages = :=20 7
Date : 2004-4-8

This document discusses how a tail-end = PE can=20 signal the Quality of
   Service parameters of the local=20 Attachment Circuit to the head-end
   PE for appropriate=20 Pseudowire generation from head to tail end PE.

A URL for this=20 Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shah-pwe3-pw-qos-= signaling-00.txt

To=20 remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body = of the=20 message. 
You can also visit https://www= 1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login = with the=20 username
"anonymous" and a password of your e-mail address. After = logging=20 in,
type "cd internet-drafts" and then
"get=20 draft-shah-pwe3-pw-qos-signaling-00.txt".

A list of = Internet-Drafts=20 directories can be found in
http://www.ietf.org/shadow.html= =20
or ftp://ftp.ietf.org/ie= tf/1shadow-sites.txt


Internet-Drafts=20 can also be obtained by e-mail.

Send a message=20 to:
mailserv@ietf.org.
In the body type:
"FILE=20 /internet-drafts/draft-shah-pwe3-pw-qos-signaling-00.txt".

------_=_NextPart_001_01C423E9.3F3A8B50-- From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Re: Yet another iana allocation problem. Date: Fri, 16 Apr 2004 15:31:19 -0600 Organization: Cisco Systems Lines: 44 Sender: pwe3-admin@ietf.org References: <407D8E55.3060301@cisco.com> <6.0.3.0.2.20040416152248.04a1df58@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3 X-From: pwe3-admin@ietf.org Fri Apr 16 23:54:31 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: "Andrew G. Malis" In-Reply-To: <6.0.3.0.2.20040416152248.04a1df58@mail.comcast.net> X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 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: , Andy, Actually after more thought we can leave it as is , I allocated a code point of 0x0c for the vccv. ( the TLV was changed by Kireeti anyway , so changing this might actually make it better ) I sent an updated iana draft to make sure everybody is on the same page. Luca Andrew G. Malis wrote: > Luca, > > This is OK to change to 0x0c. Once you release the next IANA > allocation draft, I'll update the FCS retention draft. > > Cheers, > Andy > > ----------- > > At 4/14/2004 01:17 PM -0600, Luca Martini wrote: > >> The interface parameter: >> >> 0x0A 4 FCS retention indicator >> >> is also used in vccv as the VCCV parameter. >> >> Has anybody coded this ? >> Any issues in moving this value to 0x0c ? >> >> Luca > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "M. ELK" Subject: PW Performance Date: Sat, 17 Apr 2004 07:11:59 +0000 Lines: 10 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-From: pwe3-admin@ietf.org Sat Apr 17 10:30:14 2004 Return-path: X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com To: pwe3@ietf.org X-OriginalArrivalTime: 17 Apr 2004 07:11:59.0921 (UTC) FILETIME=[469F5210:01C4244B] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Hi Appreciate to advise if it exist any draft address the Performance Management for Pseudo Wire . Brgds _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "M. ELK" Subject: Draft-Shash-pwe3-PW-QOS-Signalling Date: Sat, 17 Apr 2004 09:18:42 +0000 Lines: 36 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-From: pwe3-admin@ietf.org Sat Apr 17 11:35:23 2004 Return-path: X-Originating-IP: [57.250.229.136] X-Originating-Email: [elkou141061@hotmail.com] X-Sender: elkou141061@hotmail.com To: pwe3@ietf.org X-OriginalArrivalTime: 17 Apr 2004 09:18:42.0912 (UTC) FILETIME=[FA5BAE00:01C4245C] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Hi The PW QOS TLV do not signal the COS (Differ serv ) needed for the PW , what are the reason's . is the COS will be signaled in the Sub-TLV ?? For the status code "Can not accept the TC Parameter" sent by the Head-end Node for the PW , why not such node also indicate what TC parameters is willing to accept . What about setup and hold priorities for the PW to be part of the QOS signal . Could we add a flag to indicate that the QOS (TC ..etc ) Parameters need/mandatory to be used in both direction . This will help to : configure just one end with the QOS parameter , A Node recieving QOS TLV with this flag set and have no config for QOS parmeter will use same QOS TLV in the "Learning Label Mapping" msg . For 2 node configured with different QOS Parameters , the QOS parametrs TLV with this flag set will prevail . For 2 node configured with different QOS Parameters and both configured with this flag set , the PW initiation should be aborted . l Brgds _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "Andrew G. Malis" Subject: Re: Yet another iana allocation problem. Date: Sat, 17 Apr 2004 08:41:51 -0400 Lines: 46 Sender: pwe3-admin@ietf.org References: <407D8E55.3060301@cisco.com> <6.0.3.0.2.20040416152248.04a1df58@mail.comcast.net> <408050A7.2000805@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andrew G. Malis" , pwe3 , "Thomas D. Nadeau" X-From: pwe3-admin@ietf.org Sat Apr 17 14:50:12 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: Luca Martini In-Reply-To: <408050A7.2000805@cisco.com> References: <407D8E55.3060301@cisco.com> <6.0.3.0.2.20040416152248.04a1df58@mail.comcast.net> <408050A7.2000805@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: , Luca, Thanks for the update. Cheers, Andy --------- At 4/16/2004 03:31 PM -0600, Luca Martini wrote: >Andy, > >Actually after more thought we can leave it as is , I allocated a code >point of 0x0c for the vccv. >( the TLV was changed by Kireeti anyway , so changing this might actually >make it better ) > >I sent an updated iana draft to make sure everybody is on the same page. > >Luca > > >Andrew G. Malis wrote: > >>Luca, >> >>This is OK to change to 0x0c. Once you release the next IANA allocation >>draft, I'll update the FCS retention draft. >> >>Cheers, >>Andy >> >>----------- >> >>At 4/14/2004 01:17 PM -0600, Luca Martini wrote: >> >>>The interface parameter: >>> >>> 0x0A 4 FCS retention indicator >>> >>>is also used in vccv as the VCCV parameter. >>> >>>Has anybody coded this ? >>>Any issues in moving this value to 0x0c ? >>> >>>Luca From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-satop-01.txt - Last Call Date: Mon, 19 Apr 2004 13:25:44 +0100 Organization: Cisco Systems, Inc. Lines: 8 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Danny McPherson X-From: pwe3-admin@ietf.org Mon Apr 19 14:39:14 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "pwe3@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: , This the two week Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-01.txt Last Call will end Tuesday 4th May 2004 - Stewart From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-hdlc-ppp-encap-mpls-02.txt - Last Call Date: Mon, 19 Apr 2004 13:30:34 +0100 Organization: Cisco Systems, Inc. Lines: 7 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Danny McPherson X-From: pwe3-admin@ietf.org Mon Apr 19 14:44:28 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "pwe3@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: , This the two week Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-02.txt Last Call will end Tuesday 4th May 2004 - Stewart From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: Ethernet Raw mode encapsulation Date: Thu, 01 Apr 2004 13:33:07 -0500 Lines: 12 Sender: pwe3-admin@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D209C4F13D@II0015EXCH002U> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Apr 02 03:55:04 2004 Return-path: X-BrightmailFiltered: true To: "Ramalingam, Swaminathan (Swaminathan)" In-reply-to: Your message of Wed, 31 Mar 2004 17:38:14 +0530. <6733C768256DEC42A72BAFEFA9CF06D209C4F13D@II0015EXCH002U> 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: , > As per section 4.4 Ethernet of PWE3-CTRL, Ethernet frame (untagged) should > be encapsulated with "ethernet raw mode". I think sections 4.3 and 4.4 are mistaken in requiring the use of tagged mode or raw mode for one or another ethernet application. > how does Ethernet raw mode PW can have non-service-delimiting tag, as this > mode is only for Ethernet frame not the frame with VLAN tags There is no reason why raw mode should not be used to carry customer VLAN tags. From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: claude.kawa@sympatico.ca Subject: Re: Re: [Fwd: Comments draft-ietf-pwe3-frame-relay-02.txt] Date: Mon, 19 Apr 2004 8:38:55 -0400 Lines: 40 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: , "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Mon Apr 19 14:52:30 2004 Return-path: X-Mailer: Openwave WebEngine, version 2.8.11 (webedge20-101-194-20030622) To: 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: , Danny No problem we will have a new draft posted for mid-May. claude > > From: Danny McPherson > Date: 2004/04/16 Fri AM 11:27:01 EST > To: > CC: , "pwe3@ietf.org" > Subject: Re: [Fwd: [PWE3] Comments draft-ietf-pwe3-frame-relay-02.txt] > > > On Apr 16, 2004, at 7:32 AM, wrote: > > > We will address Shasha comments and ensure alignement > > of the draft with other texts on FR/PW. We will have a > > newd draft ready before the next IETF meeting in August. > > Claude, > We'd really like to get this out of the WG and fully in > the hands of the IESG (and back) well before the next IETF, > (with the group of other services drafts) rather than simply > posting a new draft in a few months. There's been plenty > of time to respond to outstanding concerns. > > Stewart and I believe that it's reasonable to ask that the > updates be done and a new draft posted within 4 weeks > (i.e., by May 15). Given the current author list surely > someone has the resources to address outstanding concerns > from Sasha and others. If you have problems lining that > person up let me know. > > Thanks! > > -danny > > From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "Shah, Himanshu" Subject: RE: Draft-Shah-pwe3-PW-QOS-Signalling Date: Mon, 19 Apr 2004 10:12:02 -0400 Lines: 77 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Mon Apr 19 16:26:45 2004 Return-path: To: "'M. ELK'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , PW signaling per say is independant of underlying tunneling technology. Hence the reason for not including COS info in the PW QOS TLV in the initial draft. However, if there is sufficient interest, sub-TLVs exist for such extensions. Ditto for other params, like setup/hold, etc. The goal for PW QOS signaling is to inform other PE about local AC's QOS constraints. The remote PE may use that information only to adjust traffic policing. It may also use that information to select appropriate traffic engineered tunnel. How the QOS information is utilized is not manadated. Hence I don't believe in need for the flag. A PE can always do "label release" if "TC param not accepted" status is received from the other side. regards, /himanshu > -----Original Message----- > From: M. ELK [mailto:elkou141061@hotmail.com] > Sent: Saturday, April 17, 2004 5:19 AM > To: pwe3@ietf.org > Subject: [PWE3] Draft-Shash-pwe3-PW-QOS-Signalling > > > > Hi > > The PW QOS TLV do not signal the COS (Differ serv ) needed > for the PW , what > are the reason's . > is the COS will be signaled in the Sub-TLV ?? > > For the status code "Can not accept the TC Parameter" sent by > the Head-end > Node for the PW , why not such node also indicate what TC > parameters is > willing to accept . > > What about setup and hold priorities for the PW to be part of > the QOS signal > . > > Could we add a flag to indicate that the QOS (TC ..etc ) Parameters > need/mandatory to be used in both direction . This will help to : > > configure just one end with the QOS parameter , A Node > recieving QOS TLV > with this flag set and have no config for QOS parmeter will > use same QOS > TLV in the "Learning Label Mapping" msg . > > For 2 node configured with different QOS Parameters , the QOS > parametrs TLV > with this flag set > will prevail . > > For 2 node configured with different QOS Parameters and both > configured with > this flag set , > the PW initiation should be aborted . > > l > > Brgds > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: Final Update to the ethernet encap draft. Date: Mon, 19 Apr 2004 11:33:44 -0600 Organization: Cisco Systems Lines: 11 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 19 19:47:31 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: Stewart Bryant , Danny McPherson X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 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: , Stewart/Danny, I Just sent out a final revision to the ethernet encapsulation draft. I only had minor changes in author's addresses , and I removed the mention of the "PID" to allign with the latest IESG comments. Please submit draft-ietf-pwe3-ethernet-encap-06.txt to the IESG as soon as it is published. Thanks. Luca From i-d-announce-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-iana-allocation-04.txt Date: Tue, 20 Apr 2004 10:57:09 -0400 Lines: 94 Sender: i-d-announce-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: i-d-announce-admin@ietf.org Tue Apr 20 17:51:15 2004 Return-path: To: i-d-announce@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) Author(s) : L. Martini, M. Townsley Filename : draft-ietf-pwe3-iana-allocation-04.txt Pages : 5 Date : 2004-4-19 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-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-iana-allocation-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-iana-allocation-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 i-d-announce-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-atm-encap-05.txt Date: Tue, 20 Apr 2004 15:51:53 -0400 Lines: 93 Sender: i-d-announce-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: i-d-announce-admin@ietf.org Tue Apr 20 23:09:51 2004 Return-path: To: i-d-announce@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-atm-encap-05.txt Pages : 36 Date : 2004-4-20 A framework for providing various Layer 1 and Layer 2 services over a Packet Switched Network has been described in [3]. This draft provides encapsulation formats and guidelines for transporting a variety of ATM services over a PSN. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-atm-encap-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-atm-encap-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-atm-encap-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From i-d-announce-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-ethernet-encap-06.txt Date: Tue, 20 Apr 2004 15:51:58 -0400 Lines: 95 Sender: i-d-announce-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: i-d-announce-admin@ietf.org Tue Apr 20 23:12:35 2004 Return-path: To: i-d-announce@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-ethernet-encap-06.txt Pages : 19 Date : 2004-4-20 An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units over an IP or MPLS network. This enables service providers to offer 'emulated' ethernet services over existing IP or MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a 'point-to-point ethernet' service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-ethernet-encap-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-ethernet-encap-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "Vach Kompella" Subject: Couple of questions about the generalized pwid fec Date: Tue, 20 Apr 2004 14:05:19 -0700 Organization: Alcatel USA Lines: 31 Sender: pwe3-admin@ietf.org Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Wed Apr 21 00:11:19 2004 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 20 Apr 2004 21:05:10.0854 (UTC) FILETIME=[2AC79660:01C4271B] 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: , Eric, Sec 5.2.3, para three (after What happens when PE2 receives such a Label Mapping) says: In VPLS, the TAI would be a VPN-id, identifying a particular VPLS instance. I thought the AGI defined the VPLS instance. Also, in the definition of the GPWID FEC: AGI - 1 byte Length - 1 byte Value - variable I have been objecting to this structure, but I think the problem was more terminology: I wanted type, length, value. However, we now have the confusion that the AGI is only one byte, and defines the type of Attachment Group Identifier. The Length field is fine. The Value field is the actual name (within the namespace identified by the type of Attachment Group Identifier). In a nutshell, I agree with the structure, I disagree with the naming of the fields. The AGI field should be called AGI Type. The Length, I wish it were 2 bytes so that we would never run into an issue where the name is some machine readable/generated thing, maybe a group certificate? Vach Kompella IP Division, Alcatel vach.kompella@alcatel.com +1 650 237-5152=20 From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Luca Martini Subject: PPP/HDLC draft V 03 Date: Tue, 20 Apr 2004 16:14:23 -0600 Organization: Cisco Systems Lines: 17 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 Wed Apr 21 00:41:00 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: pwe3@ietf.org X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 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: , Hello! I just sent out an update to the ppp/hdlc draft. Changes are : - Fixed reference diagram according to latest arch document. - Added comments about which protocols will work in hdlc transport mode. - Added pointer to fragmentation draft in the MTU section. - Fixed references. I believe that this document is ready for wg last call. Chairs please issue a LC as soon as it is published. Thanks. Luca From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: Couple of questions about the generalized pwid fec Date: Wed, 21 Apr 2004 00:01:17 -0400 Lines: 30 Sender: pwe3-admin@ietf.org References: <056401c4271b$313cb980$0101010a@eng.timetra.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 Apr 21 06:12:04 2004 Return-path: X-BrightmailFiltered: true To: vach.kompella@alcatel.com In-reply-to: Your message of Tue, 20 Apr 2004 14:05:19 -0700. <056401c4271b$313cb980$0101010a@eng.timetra.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: , Vach> Sec 5.2.3, para three (after What happens when PE2 receives such a Label Vach> Mapping) says: In VPLS, the TAI would be a VPN-id, identifying a Vach> particular VPLS instance. Vach> I thought the AGI defined the VPLS instance. Strictly speaking, the TAI includes the AGI and the TAII, so if the AGI identifiers the VPLS instance, so does the TAI. However, it would be less misleading just to say "the AGI identifies the VPLS instance", or perhaps just to refer to draft-ietf-l2vpn-signaling. Vach> I wanted type, length, value. I thought that's what it is now ;-) Vach> The AGI field should be called AGI Type. I have no problem with this, others may have opinions though. Vach> The Length, I wish it were 2 bytes so that we would never run into an Vach> issue where the name is some machine readable/generated thing, maybe a Vach> group certificate? Or a DNS name? ;-) A possible alternative is to reserve the first bit of the length field to indicate that the length field is two bytes long. Or the AGI type might determine the length of the length field. From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: Re: draft-ietf-pwe3-hdlc-ppp-encap-mpls-02.txt - Last Call Date: Wed, 21 Apr 2004 11:45:27 +0100 Organization: Cisco Systems, Inc. Lines: 32 Sender: pwe3-admin@ietf.org References: <4083C66A.9000804@cisco.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" , Danny McPherson X-From: pwe3-admin@ietf.org Wed Apr 21 12:58:09 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: stbryant@cisco.com In-Reply-To: <4083C66A.9000804@cisco.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Luca tells me that he has updated -02 -03 has been submitted to drafts but has not yet appeared. When it appears in the drafts repository I will restart LC. Sorry for the confusion. - Stewart Stewart Bryant wrote: > This the two week Last Call for comments on > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-02.txt > > > Last Call will end Tuesday 4th May 2004 > > - Stewart > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Eric Rosen Subject: Re: Clarifications of Generalized ID FECs Date: Thu, 01 Apr 2004 14:06:54 -0500 Lines: 37 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "'Luca Martini'" , "pwe3@ietf.org (E-mail)" X-From: pwe3-admin@ietf.org Fri Apr 02 03:59:23 2004 Return-path: X-BrightmailFiltered: true To: Nick Weeds In-reply-to: Your message of Thu, 01 Apr 2004 11:00:28 +0100. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Nick> Is the discrepancy between the AGI / SAII / TAII and interface Nick> parameters intentional? No, I don't believe that these were intentionally made different. Nick> If not, can we bring the AGI / SAII / TAII into line with the Nick> interface parameters? I guess we need input on this one from other implementers. Nick> The sense of the SAII and TAII is clear in Label Mapping messages, but Nick> the draft doesn't explicitly state the sense of the SAII and TAII in Nick> LDP messages flowing in the reverse direction, for example Label Nick> Release. Two possibilities come to mind: Nick> Nick> (a) The FEC TLV sent in a Label Release is the same as the FEC TLV Nick> received in the Label Mapping being released (but without the Nick> interface parameters). More generally, the FEC TLV is the same in Nick> all LDP messages relating to the same LSP. In a Label Release Nick> this means that the SAII is the remote peer's AII and the TAII is Nick> the sender's local AII. Nick> Nick> (b) The FEC TLV sent in a Label Release is the same as the FEC TLV Nick> sent in a Label Mapping (for the reverse LSP). More generally, Nick> the SAII is always the sender's local AII and the TAII is the Nick> remote peer's AII. In a Label Release this means that the SAII Nick> and TAII are reversed compared to the Label Mapping being Nick> released. Nick> Which of these is intended? Uh oh. After 10 minutes of intensive thought, and having changed my mind three times during that period, I think I'd like to say that the intention was (a). When you talk about a particular LSP, you should use the FEC associated with that LSP, and a Label Release is about the incoming LSP. However, comments of "but I interpreted it the other way" are welcomed! From i-d-announce-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt Date: Wed, 21 Apr 2004 15:38:16 -0400 Lines: 94 Sender: i-d-announce-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: i-d-announce-admin@ietf.org Wed Apr 21 23:35:05 2004 Return-path: To: i-d-announce@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 Over IP and MPLS Networks Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt Pages : 11 Date : 2004-4-21 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-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-hdlc-ppp-encap-mpls-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-hdlc-ppp-encap-mpls-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 15:58:26 2006 From: "Vach Kompella" Subject: RE: Couple of questions about the generalized pwid fec Date: Wed, 21 Apr 2004 14:28:43 -0700 Organization: Alcatel USA Lines: 52 Sender: pwe3-admin@ietf.org References: <200404210401.i3L41Hwb014487@rtp-core-1.cisco.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Thu Apr 22 00:38:40 2004 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200404210401.i3L41Hwb014487@rtp-core-1.cisco.com> X-OriginalArrivalTime: 21 Apr 2004 21:30:46.0321 (UTC) FILETIME=[E8670210:01C427E7] 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: , See below. -Vach=20 > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com]=20 >=20 >=20 > Vach> Sec 5.2.3, para three (after What happens when PE2=20 > receives such a=20 > Vach> Label > Vach> Mapping) says: In VPLS, the TAI would be a VPN-id, identifying a > Vach> particular VPLS instance. >=20 > Vach> I thought the AGI defined the VPLS instance. >=20 > Strictly speaking, the TAI includes the AGI and the TAII,=20 > so if the AGI identifiers the VPLS instance, so does the=20 > TAI. However, it would be less misleading just to say "the=20 > AGI identifies the VPLS instance", or perhaps just to refer=20 > to draft-ietf-l2vpn-signaling.=20 Yes, to both. I'll add the ref to draft-l2vpn-signaling. >=20 >=20 > Vach> The AGI field should be called AGI Type. >=20 > I have no problem with this, others may have opinions though.=20 >=20 > Vach> The Length, I wish it were 2 bytes so that we would never run=20 > Vach> into an issue where the name is some machine readable/generated=20 > Vach> thing, maybe a group certificate? >=20 > Or a DNS name? ;-) >=20 > A possible alternative is to reserve the first bit of the =20 > length field to indicate that the length field is two bytes=20 > long. Or the AGI type might determine the length of the=20 > length field.=20 >=20 I don't think we need to be that stingy on a single byte, at the expense of some additional parsing code. Neither resource is an issue (i.e., more cycles on parsing and more memory/bandwidth for an extra byte), but it makes it simpler to understand if it's just an unsigned short because life's too complicated already. Besides, that hack is used way too many times in SNA :-) -Vach From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "Mauro Perez Santos" Subject: RE: Welcome to the "pwe3" mailing list (Digest mode) Date: Fri, 23 Apr 2004 11:05:32 -0600 Lines: 91 Sender: pwe3-admin@ietf.org References: <20040423030618.27227.97641.Mailman@www1.ietf.org> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Fri Apr 23 18:53:05 2004 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20040423030618.27227.97641.Mailman@www1.ietf.org> 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: , ---------------------------------------- Mauro P=E9rez Santos Estracom, S.A. de C.V. Mariano Escobedo 525 Piso 4 Bosques de Chapultepec 11560, M=E9xico, D.F. T. (52 55) 5250.5088 y 5250.5510 M. 044 55 1256.6154 mauro.perez@estracom.com.mx =20 -----Mensaje original----- De: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] En nombre de pwe3-request@ietf.org Enviado el: jueves, 22 de abril de 2004 21:06 Para: mauro.perez@estracom.com.mx Asunto: Welcome to the "pwe3" mailing list (Digest mode) Welcome to the pwe3@ietf.org mailing list! To post to this list, send your email to: pwe3@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/pwe3 ************************************************************************ ** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. =20 ************************************************************************ ** If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: =20 https://www1.ietf.org/mailman/options/pwe3/mauro.perez%40estracom.com.mx You can also make such adjustments via email by sending a message to: pwe3-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: perezsan If you forget your password, don't worry, you will receive a monthly reminder telling you what all your ietf.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "Devadas Patil (dpatil)" Subject: Clarification needed on PW fragmentation ... Date: Fri, 23 Apr 2004 19:04:58 -0400 Lines: 12 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Sun Apr 25 19:02:51 2004 Return-path: X-BrightmailFiltered: true X-Sender: dpatil@mira-sjcm-2.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 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: , Hi all, Could someone please clarify whether AAL5 PDUs larger than the PW MTU must be fragmented? The internet draft 'draft-ietf-pwe3-atm-encap-05.txt' uses 'shall' (in lower case) in section 10.2 wrt AAL5 PDUs. However, for the OAM cell sequencing scenario in section 10.1, it uses upper case 'MAY'. Also, am I right in concluding from Sections 4.4, 10.1 and 10.2 that all frames larger than PW MTU must be dropped, with OAM cell sequencing and AAL5 PDUs being exceptions? Thanks and regards, Devadas Patil Cisco Systems, Inc. From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Sumit Subject: Suggestion for a minor modification in draft-ietf-pwe3-control-protocol-06.txt Date: Mon, 26 Apr 2004 16:06:11 +0530 Organization: Samsung India Lines: 92 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary_(ID_o6doSkLJ3S7l0eCnQ7w8sA)" X-From: pwe3-admin@ietf.org Mon Apr 26 12:56:54 2004 Return-path: To: pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-Priority: 3 X-MSMail-priority: 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: , This is a multi-part message in MIME format. --Boundary_(ID_o6doSkLJ3S7l0eCnQ7w8sA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hello All, I want to suggest rephrasing two sentences in draft-ietf-pwe3-control-protocol-06.txt: Section 4.3. Ethernet VLAN: "The Ethernet frame will be encapsulated according to the procedures in [11] tagged mode...... " The above sentence seems to indicate that the encapsulation procedure can only be "tagged mode" while emulating Ethernet VLAN, which is not true, as even the "raw mode" can be used. The above sentence should be rephrased to the following to remove the possibility of confusion. "The Ethernet frame will be encapsulated according to the procedures in [11], either in "tagged mode" or in the "raw mode"" Similarly, Section 4.4. Ethernet: "The Ethernet frame will be encapsulated according to the procedures in [11] "ethernet raw mode"..... " The above sentence can be rephrased to the following: "The Ethernet frame will be encapsulated according to the procedures in [11]" The above two sections should not require the use of tagged or raw mode for one or another Ethernet service being emulated. This might hamper clear understanding of the encapsulation procedures. Please correct me if I am wrong. Regards Sumit --Boundary_(ID_o6doSkLJ3S7l0eCnQ7w8sA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hello All,
 
I want to suggest rephrasing two sentences in draft-ietf-pwe3-control-protocol-06.txt:
 
Section 4.3. Ethernet VLAN:
 
"The Ethernet frame will be encapsulated according to the procedures in [11] tagged mode...... " 
 
The above sentence seems to indicate that the encapsulation procedure can only be "tagged mode" while emulating Ethernet VLAN, which is not true, as even the "raw mode" can be used. The above sentence should be rephrased to the following to remove the possibility of confusion. 
 
"The Ethernet frame will be encapsulated according to the procedures in [11], either in "tagged mode" or in the "raw mode""
 
Similarly,

Section 4.4. Ethernet:

"The Ethernet frame will be encapsulated according to the procedures in [11] "ethernet raw mode"..... "

The above sentence can be rephrased to the following:
 
"The Ethernet frame will be encapsulated according to the procedures in [11]"
 
The above two sections should not require the use of tagged or raw mode for one or another Ethernet service being emulated. This might hamper clear understanding of the encapsulation procedures.
 
Please correct me if I am wrong. 
 
Regards
Sumit
 
 
--Boundary_(ID_o6doSkLJ3S7l0eCnQ7w8sA)-- From i-d-announce-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-sonet-05.txt Date: Mon, 26 Apr 2004 15:26:56 -0400 Lines: 95 Sender: i-d-announce-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: i-d-announce-admin@ietf.org Mon Apr 26 22:29:42 2004 Return-path: To: i-d-announce@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : SONET/SDH Circuit Emulation over Packet (CEP) Author(s) : A. Malis, et al. Filename : draft-ietf-pwe3-sonet-05.txt Pages : 48 Date : 2004-4-26 The generic requirements and architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3- ARCH]. Additional requirements for emulation of SONET/SDH and lower-rate TDM circuits has been defined in [PWE3-TDM-REQ]. This draft provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over a packet-switched network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-sonet-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-sonet-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: "Ron Cohen" Subject: CEP 05: Ready for last call Date: Tue, 27 Apr 2004 03:42:21 -0700 Lines: 45 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Apr 27 12:54:32 2004 Return-path: To: "PWE3 \(IETF\)" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal 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: , Dear PWE3ers The updated CEP draft is now available at http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-05.txt Below please find the list of modification made since the 04 version. The authors believe the draft is now ready for last call. 1. Section 11: Signaling of CEP pseudo-wires: Added mandatory/optional attribute for each parameter. Clarified which error codes are returned when signaling fails and referenced the IANA draft for actual values. Added a table of values for the CEP/TDM bit rate parameter. Fixed language. 2. Draft 04 appendix B discussing actual payload sizes of fractional payload compression modes was folded into section 10. This removed duplication of data and clarified in-context the actual payload sizes. Verify that the draft body (without appendixes) includes all information required for implementation and interoperability. 3. Removed non-ASCII characters. Aligned formats and language (DS-3, DS3 and T3 to T3). Removed empty open issues section. Added VT payload size table. Updated authors contact addresses. 4. Security section rewritten Thanks Ron & Co-authors Ron Cohen CTO Lycium Networks Mobile: 650.823.7672 Mobile: +972.55.245.104 Tel: 650.234.4010 Fax: 650.854.8183 ===================================================== This email message and any files transmitted with it contain confidential information intended only for its addressee(s). If you are not the addressee of this message, any reading, disclosure, copying, printing, distribution or forwarding by you of this message or its content or attachments is strictly forbidden. In such case, please notify us immediately by replying to this message or by calling 650.234.4010 and delete the message from your computer. Thank you. From pwe3-admin@ietf.org Wed Dec 27 15:58:26 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-sonet-05.txt - Last Call Date: Tue, 27 Apr 2004 13:25:06 +0100 Organization: Cisco Systems, Inc. Lines: 62 Sender: pwe3-admin@ietf.org References: <002001c42c44$51f4c310$212d010a@lycium.net> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "PWE3 (IETF)" X-From: pwe3-admin@ietf.org Tue Apr 27 14:54:21 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Ron Cohen In-Reply-To: <002001c42c44$51f4c310$212d010a@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: , This formally starts the two week Last Call process. Last Call will end Wednesday 12th May - Stewart Ron Cohen wrote: > Dear PWE3ers > > The updated CEP draft is now available at > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-05.txt > > Below please find the list of modification made since the 04 version. > The authors believe the draft is now ready for last call. > > 1. Section 11: Signaling of CEP pseudo-wires: Added mandatory/optional > attribute for each parameter. Clarified which error codes are returned > when signaling fails and referenced the IANA draft for actual values. > Added a table of values for the CEP/TDM bit rate parameter. Fixed > language. > > 2. Draft 04 appendix B discussing actual payload sizes of fractional > payload compression modes was folded into section 10. This removed > duplication of data and clarified in-context the actual payload sizes. > Verify that the draft body (without appendixes) includes all information > required for implementation and interoperability. > > 3. Removed non-ASCII characters. Aligned formats and language (DS-3, DS3 > and T3 to T3). Removed empty open issues section. Added VT payload size > table. Updated authors contact addresses. > > 4. Security section rewritten > > Thanks > Ron & Co-authors > > Ron Cohen > CTO > Lycium Networks > Mobile: 650.823.7672 > Mobile: +972.55.245.104 > Tel: 650.234.4010 > Fax: 650.854.8183 > > ===================================================== > This email message and any files transmitted with it contain > confidential information intended only for its addressee(s). If you are > not the addressee of this message, any reading, disclosure, copying, > printing, distribution or forwarding by you of this message or its > content or attachments is strictly forbidden. In such case, please > notify us immediately by replying to this message or by calling > 650.234.4010 and delete the message from your computer. Thank you. > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: RE: Couple of questions about the generalized pwid fec Date: Tue, 27 Apr 2004 09:47:49 -0600 Organization: Cisco Systems Lines: 21 Sender: pwe3-admin@ietf.org References: <05ef01c427e7$a0987090$0101010a@eng.timetra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 27 18:06:52 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: vach.kompella@alcatel.com In-Reply-To: <05ef01c427e7$a0987090$0101010a@eng.timetra.com> X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 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: , >> >>Strictly speaking, the TAI includes the AGI and the TAII, >>so if the AGI identifiers the VPLS instance, so does the >>TAI. However, it would be less misleading just to say "the >>AGI identifies the VPLS instance", or perhaps just to refer >>to draft-ietf-l2vpn-signaling. >> >> > >Yes, to both. I'll add the ref to draft-l2vpn-signaling. > > > >> >> I'll change the control draft to say this as well. Luca From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: Clarification needed on PW fragmentation ... Date: Tue, 27 Apr 2004 10:03:28 -0600 Organization: Cisco Systems Lines: 36 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20040423190409.00b054d8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 27 18:39:59 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: "Devadas Patil (dpatil)" In-Reply-To: <4.3.2.7.2.20040423190409.00b054d8@mira-sjcm-2.cisco.com> X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 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: , Devadas Patil (dpatil) wrote: > Hi all, > Could someone please clarify whether AAL5 PDUs larger than the PW MTU > must be fragmented? The internet draft > 'draft-ietf-pwe3-atm-encap-05.txt' uses 'shall' (in lower case) in > section 10.2 wrt AAL5 PDUs. However, for the OAM cell sequencing > scenario in section 10.1, it uses upper case 'MAY'. The intent was a MUST. > Also, am I right in concluding from Sections 4.4, 10.1 and 10.2 that > all frames larger than PW MTU must be dropped, with > OAM cell sequencing and AAL5 PDUs > being exceptions? yes , unless you use draft-ietf-pwe3-fragmentation-05.txt Luca > Thanks > and regards, > Devadas Patil > Cisco Systems, Inc. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Tim.Frost@Zarlink.Com Subject: Re: I-D ACTION:draft-ietf-pwe3-arch-07.txt Date: Fri, 2 Apr 2004 09:02:39 +0000 Lines: 50 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0031AEA080256E6A_=" X-From: pwe3-admin@ietf.org Fri Apr 02 17:42:44 2004 Return-path: To: pwe3@ietf.org, stbryant@cisco.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 X-MIMETrack: Serialize by Router on ottmta01/Zarlink(Release 6.5.1|January 21, 2004) at 04/02/2004 04:02:43 AM, Serialize complete at 04/02/2004 04:02:43 AM X-Spam-Score: 0.499 () HTML_MESSAGE,NO_REAL_NAME X-Scanned-By: MIMEDefang 2.38 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 0031AEA080256E6A_= Content-Type: text/plain; charset="us-ascii" Hi Stewart, Sorry this comment comes so late as far as the architecture draft is concerned. I recently reviewed the CESoPSN and SAToP drafts, and one comment I picked up was that they used the term "PSN-bound" for the traffic direction from the CE, through the PE and into the PSN. The architecture draft uses the term "PE-bound" for this direction. When I pointed this out to the authors, Sasha came back with the comment that traffic from the PSN to the PE is also "PE-bound". Therefore the term in the architecture draft is misleading and potentially ambiguous. I tend to agree with Sasha on this, that "PSN-bound" is the clearer term to use. Is it too late to change the terminology in the architecture draft? A quick search through the other drafts reveals no occurences in draft-ietf-pwe3-atm-encap-04, draft-ietf-pwe3-frame-relay-02 or draft-ietf-pwe3-sonet-03, and just 2 occurences in draft-ietf-ethernet-encap-05, so it should only have a small knock-on to other drafts. The term "PSN-bound" is used frequently in draft-ietf-pwe3-satop-01 and draft-ietf-pwe3-cesopsn-00, so in fact this would be the bigger change to make. Cheers, Tim --=_alternative 0031AEA080256E6A_= Content-Type: text/html; charset="us-ascii"
Hi Stewart,

Sorry this comment comes so late as far as the architecture draft is concerned.

I recently reviewed the CESoPSN and SAToP drafts, and one comment I picked up was that they used the term "PSN-bound" for the traffic direction from the CE, through the PE and into the PSN. The architecture draft uses the term "PE-bound" for this direction. When I pointed this out to the authors, Sasha came back with the comment that traffic from the PSN to the PE is also "PE-bound". Therefore the term in the architecture draft is misleading and potentially ambiguous.

I tend to agree with Sasha on this, that "PSN-bound" is the clearer term to use. Is it too late to change the terminology in the architecture draft?

A quick search through the other drafts reveals no occurences in draft-ietf-pwe3-atm-encap-04, draft-ietf-pwe3-frame-relay-02 or draft-ietf-pwe3-sonet-03, and just  2 occurences in draft-ietf-ethernet-encap-05, so it should only have a small knock-on to other drafts. The term "PSN-bound" is used frequently in draft-ietf-pwe3-satop-01 and draft-ietf-pwe3-cesopsn-00, so in fact this would be the bigger change to make.

Cheers,
Tim
--=_alternative 0031AEA080256E6A_=-- From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: Suggestion for a minor modification in draft-ietf-pwe3-control-protocol-06.txt Date: Tue, 27 Apr 2004 10:14:12 -0600 Organization: Cisco Systems Lines: 42 Sender: pwe3-admin@ietf.org References: <00ee01c42b7a$4bc34770$89476c6b@sisodomain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Apr 27 18:47:22 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: Sumit In-Reply-To: <00ee01c42b7a$4bc34770$89476c6b@sisodomain.com> X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 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: , Sumit wrote: > Hello All, I want to suggest rephrasing two sentences in > draft-ietf-pwe3-control-protocol-06.txt: Section 4.3. Ethernet VLAN: > "The Ethernet frame will be encapsulated according to the procedures > in [11] tagged mode...... " The above sentence seems to indicate > that the encapsulation procedure can only be "tagged mode" while > emulating Ethernet VLAN, which is not true, as even the "raw mode" can > be used. The above sentence should be rephrased to the following to > remove the possibility of confusion. "The Ethernet frame will be > encapsulated according to the procedures in [11], either in "tagged > mode" or in the "raw mode"" Similarly, In section 4.3 we refer to PW type "0x0004 Ethernet Tagged Mode" which means only tagged mode encapsulation is allowed. I believe that perhaps we need to change the section heading from "Ethernet VLAN" to "Ethernet Tagged Mode" Would this make it easier to understand ? > Section 4.4. Ethernet: > > "The Ethernet frame will be encapsulated according to the procedures > in [11] "ethernet raw mode"..... " > > The above sentence can be rephrased to the following: "The Ethernet > frame will be encapsulated according to the procedures in [11]" The > above two sections should not require the use of tagged or raw mode > for one or another Ethernet service being emulated. This might hamper > clear understanding of the encapsulation procedures. Please correct > me if I am wrong. Regards Sumit in section 4.4 we refer to pw type "0x0005 Ethernet" which is only raw mode. ( may or may not contain a tag , but in any case service delimiting tags are not sent over the PW. ) Luca From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Generalized PWID FEC and the question of the Group ID Date: Tue, 27 Apr 2004 16:03:41 -0600 Organization: Cisco Systems Lines: 82 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Apr 28 00:21:11 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: pwe3@ietf.org X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 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: , Hello! It has been pointed out that the GPW FEC design was somewhat inconsistent with the other PWId design in the control draft. I have fixed several issues related to length fields, and clarified the label with draw procedures. The only thing that remains is the GR ID functionality. This was initially suggested at a diner/meeting at the San Diego IETF. The idea is that if there are large amounts of PWs originating on a port , with a few dozen different destinations it would be much faster to send a few dozen withdraw ( or status messages ) instead of thousands individual PW withdraw , or PW status messages. We left the association of GR IDs open to implementors, as it is not relevant for protocol compatibility. This time around, I would like to keep the same functionality, but remove the GR ID from the FEC if possible. So I propose the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 129 |C| PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID=0 | Length=4 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAII | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Interface Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To identify the GR ID we set the type to the reserved type of 0 ... the length is set to 4 to specify a 16 bit value , but we can make that bigger if needed. ( however I cannot think of an application requiring more then 16 bit of locally defined groups ) the semantics would remain similar with the following exception: The GR ID is not part of the FEC, is OPTIONAL, and will not be advertised except in the initial PW FEC advertisement. If the GR ID is advertised , then the advertising PE can use the wild card withdraw semantics, and the if the remote PEs accepts the FEC it MUST implement this. If a PE chooses not to implement the GR ID, and it receives an advertisement containing one, a Label Release MUST be sent, with an "GR ID not Supported" status code. In this case, the PW will not be enabled. ( the PE is free to advertise a new PW FEC without the GR ID, but that is a matter of local configuration policy ) 0x00000029 "GR ID not Supported" To issue a wild card command ( status/or withdraw ): Set the PW Info Length to 0 , and send only the GR ID in the FEC. ( we could also make this be the correct length, since we can recognize the GR ID , by the code point = 0 ) One other option is to make this mandatory, in a similar way as with FEC 128. Of course we will need to reissue a last call for this section as well as the status TLV section. Comments ? Thanks. Luca From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Sumit Singh Subject: Re: Suggestion for a minor modification in draft-ietf-pwe3-control-protocol-06.txt Date: Wed, 28 Apr 2004 10:38:12 +0530 Organization: Samsung Electronics Lines: 68 Sender: pwe3-admin@ietf.org References: <00ee01c42b7a$4bc34770$89476c6b@sisodomain.com> <408E86D4.8060807@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 28 13:18:19 2004 Return-path: To: Luca Martini X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-Priority: 3 X-MSMail-priority: 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: , Luca, Thanks for the reply. Please see my comment inline. Regards, Sumit ----- Original Message ----- From: "Luca Martini" To: "Sumit" Cc: Sent: Tuesday, April 27, 2004 9:44 PM Subject: Re: [PWE3] Suggestion for a minor modification in draft-ietf-pwe3-control-protocol-06.txt > > > Sumit wrote: > > > Hello All, I want to suggest rephrasing two sentences in > > draft-ietf-pwe3-control-protocol-06.txt: Section 4.3. Ethernet VLAN: > > "The Ethernet frame will be encapsulated according to the procedures > > in [11] tagged mode...... " The above sentence seems to indicate > > that the encapsulation procedure can only be "tagged mode" while > > emulating Ethernet VLAN, which is not true, as even the "raw mode" can > > be used. The above sentence should be rephrased to the following to > > remove the possibility of confusion. "The Ethernet frame will be > > encapsulated according to the procedures in [11], either in "tagged > > mode" or in the "raw mode"" Similarly, > > In section 4.3 we refer to PW type "0x0004 Ethernet Tagged Mode" which > means only tagged mode encapsulation is allowed. > > I believe that perhaps we need to change the section heading from > "Ethernet VLAN" to "Ethernet Tagged Mode" > > Would this make it easier to understand ? This would definitely add to clarity. Actually confusion arises because of the heading of Section 4: "Details Specific to Particular Emulated Services", whereas, what is being discussed in the sub-sections is details specific to different Pseudowire types. That's why one gets this idea of Ethernet VLAN service emulation requiring only tagged mode and Ethernet service emulation requiring only raw mode, on reading sub-sections 4.3 & 4.4. May be you could consider renaming Section 4 to "Details Specific to Different Pseudowire Types". > > Section 4.4. Ethernet: > > > > "The Ethernet frame will be encapsulated according to the procedures > > in [11] "ethernet raw mode"..... " > > > > The above sentence can be rephrased to the following: "The Ethernet > > frame will be encapsulated according to the procedures in [11]" The > > above two sections should not require the use of tagged or raw mode > > for one or another Ethernet service being emulated. This might hamper > > clear understanding of the encapsulation procedures. Please correct > > me if I am wrong. Regards Sumit > > in section 4.4 we refer to pw type "0x0005 Ethernet" which is only raw > mode. ( may or may not contain a tag , but in any case service > delimiting tags are not sent over the PW. ) > > > Luca > > > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Ramalingam, Swaminathan (Swaminathan)" Subject: RE: Suggestion for a minor modification in draft-ietf-pwe3 -control-protocol-06.txt Date: Wed, 28 Apr 2004 16:57:54 +0530 Lines: 28 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 Apr 28 13:40:13 2004 Return-path: To: Sumit Singh , Luca Martini X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Luca, > >This would definitely add to clarity. Actually confusion >arises because of >the heading of Section 4: "Details Specific to Particular Emulated >Services", whereas, what is being discussed in the >sub-sections is details >specific to different Pseudowire types. That's why one gets >this idea of >Ethernet VLAN service emulation requiring only tagged mode and Ethernet >service emulation requiring only raw mode, on reading >sub-sections 4.3 & >4.4. May be you could consider renaming Section 4 to "Details >Specific to >Different Pseudowire Types". > I too agree with him. We can make section 4.3 as "Ethernet" and two type of PWs can be used to emulate the Ethernet service over IP/MPLS core 4.3.1 as "Ethernet Tagged mode" 4.3.2 as "Ethernet Raw Mode" Thanks, Swami From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Ramalingam, Swaminathan (Swaminathan)" Subject: RE: Suggestion for a minor modification in draft-ietf-pwe3 -control-protocol-06.txt Date: Wed, 28 Apr 2004 17:17:30 +0530 Lines: 55 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 28 15:03:19 2004 Return-path: To: "Ramalingam, Swaminathan (Swaminathan)" , Sumit Singh , Luca Martini X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , I think renaming section 4.3 to "Ethernet VLAN" to "Ethernet tagged Mode" 4.4 to "Ethernet" to "Ethernet raw mode" should suffice. Thanks, Swami >-----Original Message----- >From: Ramalingam, Swaminathan (Swaminathan) [mailto:swamir@lucent.com] >Sent: Wednesday, April 28, 2004 4:58 PM >To: Sumit Singh; Luca Martini >Cc: pwe3@ietf.org >Subject: RE: [PWE3] Suggestion for a minor modification in >draft-ietf-pwe3 -control-protocol-06.txt > > >Luca, > >> >>This would definitely add to clarity. Actually confusion >>arises because of >>the heading of Section 4: "Details Specific to Particular Emulated >>Services", whereas, what is being discussed in the >>sub-sections is details >>specific to different Pseudowire types. That's why one gets >>this idea of >>Ethernet VLAN service emulation requiring only tagged mode >and Ethernet >>service emulation requiring only raw mode, on reading >>sub-sections 4.3 & >>4.4. May be you could consider renaming Section 4 to "Details >>Specific to >>Different Pseudowire Types". >> > >I too agree with him. >We can make section 4.3 as "Ethernet" and two type of PWs can >be used to >emulate the Ethernet service over IP/MPLS core > >4.3.1 as "Ethernet Tagged mode" >4.3.2 as "Ethernet Raw Mode" > > >Thanks, >Swami > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Luca Martini Subject: Re: Suggestion for a minor modification in draft-ietf-pwe3 -control-protocol-06.txt Date: Wed, 28 Apr 2004 09:34:20 -0600 Organization: Cisco Systems Lines: 79 Sender: pwe3-admin@ietf.org References: <6733C768256DEC42A72BAFEFA9CF06D20A8D2BF1@II0015EXCH002U> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Sumit Singh , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Apr 28 18:05:50 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: "Ramalingam, Swaminathan (Swaminathan)" In-Reply-To: <6733C768256DEC42A72BAFEFA9CF06D20A8D2BF1@II0015EXCH002U> X-from-outside-Cisco-experimental-header: [10.32.224.186] X-PMX-Version: 4.5.0.92886 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: , Done. Luca Ramalingam, Swaminathan (Swaminathan) wrote: >I think renaming section 4.3 to "Ethernet VLAN" to "Ethernet tagged Mode" > 4.4 to "Ethernet" to "Ethernet raw mode" > >should suffice. > > >Thanks, >Swami > > > > >>-----Original Message----- >>From: Ramalingam, Swaminathan (Swaminathan) [mailto:swamir@lucent.com] >>Sent: Wednesday, April 28, 2004 4:58 PM >>To: Sumit Singh; Luca Martini >>Cc: pwe3@ietf.org >>Subject: RE: [PWE3] Suggestion for a minor modification in >>draft-ietf-pwe3 -control-protocol-06.txt >> >> >>Luca, >> >> >> >>>This would definitely add to clarity. Actually confusion >>>arises because of >>>the heading of Section 4: "Details Specific to Particular Emulated >>>Services", whereas, what is being discussed in the >>>sub-sections is details >>>specific to different Pseudowire types. That's why one gets >>>this idea of >>>Ethernet VLAN service emulation requiring only tagged mode >>> >>> >>and Ethernet >> >> >>>service emulation requiring only raw mode, on reading >>>sub-sections 4.3 & >>>4.4. May be you could consider renaming Section 4 to "Details >>>Specific to >>>Different Pseudowire Types". >>> >>> >>> >>I too agree with him. >>We can make section 4.3 as "Ethernet" and two type of PWs can >>be used to >>emulate the Ethernet service over IP/MPLS core >> >>4.3.1 as "Ethernet Tagged mode" >>4.3.2 as "Ethernet Raw Mode" >> >> >>Thanks, >>Swami >> >>_______________________________________________ >>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 15:58:27 2006 From: "Andrew G. Malis" Subject: Re: Generalized PWID FEC and the question of the Group ID Date: Thu, 29 Apr 2004 13:13:19 -0400 Lines: 43 Sender: pwe3-admin@ietf.org References: <408ED8BD.10204@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Apr 29 19:48:00 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: Luca Martini In-Reply-To: <408ED8BD.10204@cisco.com> References: <408ED8BD.10204@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: , This is certainly a reasonable proposal. In fact, I would prefer making this mandatory, since that would simplify the procedures and remove the need for the new status code. Just to be clear, even if we don't make it mandatory, I'm still in favor of this change. Cheers, Andy ---------- At 4/27/2004 04:03 PM -0600, Luca Martini wrote: >Hello! > >It has been pointed out that the GPW FEC design was somewhat inconsistent >with the other PWId design in the control draft. >I have fixed several issues related to length fields, and clarified the >label with draw procedures. The only thing that remains is the GR ID >functionality. >This was initially suggested at a diner/meeting at the San Diego IETF. The >idea is that if there are large amounts of PWs originating on a port , >with a few dozen different destinations it would be much faster to send a >few dozen withdraw ( or status messages ) instead of thousands individual >PW withdraw , or PW status messages. >We left the association of GR IDs open to implementors, as it is not >relevant for protocol compatibility. > >This time around, I would like to keep the same functionality, but remove >the GR ID from the FEC if possible. > >So I propose the following: > > > >One other option is to make this mandatory, in a similar way as with FEC 128. > >Of course we will need to reissue a last call for this section as well as >the status TLV section. > >Comments ? > >Thanks. >Luca From i-d-announce-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-tdm-requirements-05.txt Date: Thu, 29 Apr 2004 15:52:51 -0400 Lines: 97 Sender: i-d-announce-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: i-d-announce-admin@ietf.org Thu Apr 29 22:50:19 2004 Return-path: To: i-d-announce@ietf.org Errors-To: i-d-announce-admin@ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN) Author(s) : M. Riegel Filename : draft-ietf-pwe3-tdm-requirements-05.txt Pages : 26 Date : 2004-4-29 This document specifies the particular requirements for edge-to-edge-emulation of circuits carrying time division multiplexed digital signals of the PDH as well as the SONET/SDH hierarchy over packet-switched networks. It is based on the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH]. It makes references to requirements in [PWE3-REQ] where applicable and complements [PWE3-REQ] by defining requirements originating from specifics of TDM circuits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-tdm-requirements-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-tdm-requirements-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Stewart Bryant Subject: draft-ietf-pwe3-cesopsn-00.txt LAST CALL Date: Thu, 29 Apr 2004 22:39:42 +0100 Organization: Cisco Systems, Inc. Lines: 7 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 Thu Apr 29 23:57:29 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "pwe3@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: , This the start of the two week Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-00.txt Last Call will end Monday 17th May 2004 - Stewart From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Nick Weeds Subject: RE: Clarifications of Generalized ID FECs Date: Fri, 2 Apr 2004 11:46:21 +0100 Lines: 88 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Luca Martini'" , "pwe3@ietf.org (E-mail)" X-From: pwe3-admin@ietf.org Fri Apr 02 19:06:44 2004 Return-path: To: "'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: , Eric, Many thanks for your prompt response. For the record, our implementation currently assumes the following: - AGI / SAII / TAII use the same length encoding as interface parameters. - (a) FEC TLV is the same in all LDP messages relating to the same LSP (but with interface paramters omitted in some cases). Nick. > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 01 April 2004 20:07 > To: Nick Weeds > Cc: 'Luca Martini'; pwe3@ietf.org (E-mail) > Subject: Re: [PWE3] Clarifications of Generalized ID FECs > > > > Nick> Is the discrepancy between the AGI / SAII / TAII > and interface > Nick> parameters intentional? > > No, I don't believe that these were intentionally made different. > > Nick> If not, can we bring the AGI / SAII / TAII into > line with the > Nick> interface parameters? > > I guess we need input on this one from other implementers. > > Nick> The sense of the SAII and TAII is clear in Label > Mapping messages, but > Nick> the draft doesn't explicitly state the sense of the > SAII and TAII in > Nick> LDP messages flowing in the reverse direction, for > example Label > Nick> Release. Two possibilities come to mind: > Nick> > Nick> (a) The FEC TLV sent in a Label Release is the same > as the FEC TLV > Nick> received in the Label Mapping being released > (but without the > Nick> interface parameters). More generally, the FEC TLV > is the same in > Nick> all LDP messages relating to the same LSP. In a > Label Release > Nick> this means that the SAII is the remote peer's AII > and the TAII is > Nick> the sender's local AII. > Nick> > Nick> (b) The FEC TLV sent in a Label Release is the same > as the FEC TLV > Nick> sent in a Label Mapping (for the reverse LSP). > More generally, > Nick> the SAII is always the sender's local AII and > the TAII is the > Nick> remote peer's AII. In a Label Release this means > that the SAII > Nick> and TAII are reversed compared to the Label > Mapping being > Nick> released. > > Nick> Which of these is intended? > > Uh oh. After 10 minutes of intensive thought, and having > changed my mind > three times during that period, I think I'd like to say > that the intention > was (a). When you talk about a particular LSP, you > should use the FEC > associated with that LSP, and a Label Release is about the > incoming LSP. > However, comments of "but I interpreted it the other way" are > welcomed! > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Wei Luo Subject: Re: Clarifications of Generalized ID FECs Date: Fri, 02 Apr 2004 16:21:42 -0800 Lines: 50 Sender: pwe3-admin@ietf.org References: <200404011906.i31J6sA6012847@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Luca Martini'" , "pwe3@ietf.org (E-mail)" X-From: pwe3-admin@ietf.org Sat Apr 03 02:25:11 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en,zh-CN To: erosen@cisco.com, Nick Weeds 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: , The L2VPN signaling draft that defines the usage of Generalized ID FEC more or less explains the scenario, and it could certainly be more precise in future revisions. 1. When PE1 sends a Label Mapping with SAII (Fred) and TAII (Bill) to PE2, PE2 treats it as a connection request from PE1 to its local attachment named Bill. 2. PE2 examines whether it should accept this connection request according to its local configuration. If not, it could save the label binding for future use if using liberal retention or discard it, and the processing is complete. 3. If yes, PE2 either has already sent or is about to send a Label Mapping with SAII (Bill) and TAII (Fred) to PE1. After > Nick> The sense of the SAII and TAII is clear in Label Mapping messages, but > Nick> the draft doesn't explicitly state the sense of the SAII and TAII in > Nick> LDP messages flowing in the reverse direction, for example Label > Nick> Release. Two possibilities come to mind: > Nick> > Nick> (a) The FEC TLV sent in a Label Release is the same as the FEC TLV > Nick> received in the Label Mapping being released (but without the > Nick> interface parameters). More generally, the FEC TLV is the same in > Nick> all LDP messages relating to the same LSP. In a Label Release > Nick> this means that the SAII is the remote peer's AII and the TAII is > Nick> the sender's local AII. > Nick> > Nick> (b) The FEC TLV sent in a Label Release is the same as the FEC TLV > Nick> sent in a Label Mapping (for the reverse LSP). More generally, > Nick> the SAII is always the sender's local AII and the TAII is the > Nick> remote peer's AII. In a Label Release this means that the SAII > Nick> and TAII are reversed compared to the Label Mapping being > Nick> released. > > Nick> Which of these is intended? > > Uh oh. After 10 minutes of intensive thought, and having changed my mind > three times during that period, I think I'd like to say that the intention > was (a). When you talk about a particular LSP, you should use the FEC > associated with that LSP, and a Label Release is about the incoming LSP. > However, comments of "but I interpreted it the other way" are welcomed! > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: Wei Luo Subject: Re: Clarifications of Generalized ID FECs Date: Fri, 02 Apr 2004 16:48:33 -0800 Lines: 72 Sender: pwe3-admin@ietf.org References: <200404011906.i31J6sA6012847@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Luca Martini'" , "pwe3@ietf.org (E-mail)" X-From: pwe3-admin@ietf.org Sat Apr 03 02:51:07 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en,zh-CN To: erosen@cisco.com, Nick Weeds 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: , (resend with the complete response, hit the send button too early by mistake) The L2VPN signaling draft that defines the usage of Generalized ID FEC more or less explains the scenario, and it could certainly be more precise in future revisions. 1. When PE1 sends a Label Mapping with SAII (Fred) and TAII (Bill) to PE2, PE2 treats it as a pseudowire connection request from PE1 to its local attachment named Bill. 2. PE2 examines whether it should accept this connection request according to its local configuration. If the attachment Bill is not provisioned, it could save the label binding for future use if using liberal retention or discard it, and the processing is complete. 3. If the attchment Bill is provisioned but with a targeted PE other than PE1, PE2 sends a Label Release with SAII (Bill) and TAII (Fred) to PE1 and the error code is set to "attachment bound to different PE". PE1 treats the Label Release message as the refusal of the original pseudowire connection request. 4. If the attachment Bill is provisioned with PE1 as the targeted PE but with a targeted attachment other than Fred, PE2 sends a Label Release with SAII (Bill) and TAII (Fred) and the error code is set to "attachment bound to different remote attachment". PE1 treats the Label Release message as the refusal of the original pseudowire connection request. In essence, SAII and TAII are properties pertaining to the *bidirectional* pseudowire instead of individual LSPs. Therefore, whenever receiving a Label message regardless its type, the TAII always correponds to an attachment provisioned locally, and the SAII always correponds to an attachment provisioned remotely. This is what described in option b) below. This consistence eliminates confusions often raised when mixing unidirectional LSP and bidirectional pseudowire in the same context. It is also consistent with the other L2VPN signaling protocol. ---Wei > Nick> The sense of the SAII and TAII is clear in Label Mapping messages, but > Nick> the draft doesn't explicitly state the sense of the SAII and TAII in > Nick> LDP messages flowing in the reverse direction, for example Label > Nick> Release. Two possibilities come to mind: > Nick> > Nick> (a) The FEC TLV sent in a Label Release is the same as the FEC TLV > Nick> received in the Label Mapping being released (but without the > Nick> interface parameters). More generally, the FEC TLV is the same in > Nick> all LDP messages relating to the same LSP. In a Label Release > Nick> this means that the SAII is the remote peer's AII and the TAII is > Nick> the sender's local AII. > Nick> > Nick> (b) The FEC TLV sent in a Label Release is the same as the FEC TLV > Nick> sent in a Label Mapping (for the reverse LSP). More generally, > Nick> the SAII is always the sender's local AII and the TAII is the > Nick> remote peer's AII. In a Label Release this means that the SAII > Nick> and TAII are reversed compared to the Label Mapping being > Nick> released. > > Nick> Which of these is intended? > > Uh oh. After 10 minutes of intensive thought, and having changed my mind > three times during that period, I think I'd like to say that the intention > was (a). When you talk about a particular LSP, you should use the FEC > associated with that LSP, and a Label Release is about the incoming LSP. > However, comments of "but I interpreted it the other way" are welcomed! > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Ron Cohen" Subject: SONET CEP 04 Date: Sun, 4 Apr 2004 17:20:21 -0700 Lines: 58 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Mon Apr 05 02:22:11 2004 Return-path: To: "PWE3 \(IETF\)" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Hi, Version 04 of the PWE3 SONET CEP draft is available at http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-04.txt Apart from editorials and reference updates, the following changes were made: 1. Aligned to Arch draft: remove MPLS PID and add CEP MPLS Adaptation Header instead. Changes made in LDP signaling section to accommodate the name change. 2. Added clarification of the VT order within VTG in fractional STS-1 and VC-4 modes. Also added text about VT3 and VT6 there. 3. Changed the name of the LDP signaling object from CEP bytes to CEP/TDM bytes according to change in IANA draft. The draft has several non-ASCII characters in various places. This will be fixed in the next version. I also received comments on the LDP signaling section from Sasha after submission. Below are the comments and their resolution: 1. Specify which of the CEP PW objects are mandatory and which are optional (section 11) : CEP option (MUST), CEP/TDM bit rate (MUST) CEP/TDM Payload bytes (SHOULD, if is not included, default payload size is assumed). 2. Fix consistency between MUSTs and MAYs in this section 3. Reference the TDM/CEP error code defined in new IANA draft 4. Elaborate on the need for EBM flag in CEP option object. Change 'indicate' to 'indicates' in the CEP options flag description. We would greatly appreciate further comments. The authors believe the draft is ready for last call. Thanks Ron Ron Cohen CTO Lycium Networks Mobile: 650.823.7672 Mobile: +972.55.245.104 Tel: 650.234.4010 Fax: 650.854.8183 ===================================================== This email message and any files transmitted with it contain confidential information intended only for its addressee(s). If you are not the addressee of this message, any reading, disclosure, copying, printing, distribution or forwarding by you of this message or its content or attachments is strictly forbidden. In such case, please notify us immediately by replying to this message or by calling 650.234.4010 and delete the message from your computer. Thank you. From pwe3-admin@ietf.org Wed Dec 27 15:58:27 2006 From: "Ramalingam, Swaminathan (Swaminathan)" Subject: RE: Ethernet Raw mode encapsulation Date: Mon, 5 Apr 2004 14:31:35 +0530 Lines: 50 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Apr 05 12:29:12 2004 Return-path: To: erosen@cisco.com X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Eric, Thanks for the reply. See inline. Thanks, Swami >-----Original Message----- >From: Eric Rosen [mailto:erosen@cisco.com] >Sent: Friday, April 02, 2004 12:03 AM >To: Ramalingam, Swaminathan (Swaminathan) >Cc: pwe3@ietf.org >Subject: Re: [PWE3] Ethernet Raw mode encapsulation > > > >> As per section 4.4 Ethernet of PWE3-CTRL, Ethernet frame >(untagged) should >> be encapsulated with "ethernet raw mode". > >I think sections 4.3 and 4.4 are mistaken in requiring the >use of tagged >mode or raw mode for one or another ethernet application. Is this mean, service de-limiting tags *ALWAYS* used to select an PW in tagged mode and NSDTs are *ALWAYS* used to select an PW in raw mode ? > >> how does Ethernet raw mode PW can have >non-service-delimiting tag, as this >> mode is only for Ethernet frame not the frame with VLAN tags > >There is no reason why raw mode should not be used to carry >customer VLAN >tags. I too see no reason other than an overhead of 4 bytes in the payload. In case, if we use raw mode for VLAN frame, as per section 3.1.2, "In both modes, non-service-delimiting tags are passed transparently across the PW as part of the payload." CE-VLAN tag needs to be mapped to an PW but MPLS data still need to carry the CE-VLAN tag (even when one-to-one mapping of CE-VLAN <-> an PW) Pl. clarify if am wrong. Thanks, Swami