From mailman-bounces@ietf.org Sat Jan 1 05:21:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05804 for ; Sat, 1 Jan 2005 05:21:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ckga8-0006V3-1M for mpls-archive@ietf.org; Sat, 01 Jan 2005 05:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ckg54-0001zA-O5 for mpls-archive@ietf.org; Sat, 01 Jan 2005 05:01:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: mpls-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:00:30 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for mpls-archive@ietf.org: List Password // URL ---- -------- mpls@lists.ietf.org duubek https://www1.ietf.org/mailman/options/mpls/mpls-archive%40ietf.org From mpls-bounces@ietf.org Mon Jan 3 17:11:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27381; Mon, 3 Jan 2005 17:11:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Clac9-0004Ao-CB; Mon, 03 Jan 2005 17:23:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cla4x-0003uo-08; Mon, 03 Jan 2005 16:49:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClZad-000619-W9 for mpls@megatron.ietf.org; Mon, 03 Jan 2005 16:18:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14657 for ; Mon, 3 Jan 2005 16:18:10 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClZmn-000080-CR for mpls@ietf.org; Mon, 03 Jan 2005 16:30:50 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j03LHS40026033 for ; Mon, 3 Jan 2005 15:17:28 -0600 (CST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 3 Jan 2005 16:17:27 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'neil.2.harrison@bt.com'" , adrian@olddog.co.uk, loa@pi.se, tnadeau@cisco.com, dallan@nortelnetworks.com Subject: RE: [mpls] working group last call on draft-ietf-mpls-oam-frmwk-0 1.txt Date: Mon, 3 Jan 2005 16:17:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Thanks, Neil. A few comments in-line. Peter neil.2.harrison@bt.com wrote: > Hi Peter..... > >> >> Neil, >> >> Two questions: >> >> 1) You say that PM can not be defined without defining entry >> and exit criteria for availability. However, in Y.1711 you >> specify that PM SLA recording be turned off at the entry of >> the defect state. Does't this proof that PM is dependent on >> an unambiguous definition of defect states, but independent >> of the definition of availability? > NH=> In my opinion, and from a practical point of view, 'yes' is the > trite answer.....but only with how I have specified defects here, so > let me explain this a bit further. Note - if you look at the ITU > Recs that deal with this they all define that a 10s period is to be > used for unavailability entry/exit and the turning off/on of PM, eg > see G.826 for example. > > My main objectives were simplicity whilst concentrating on what is > operationally important based on many years of studying real tranport > networks. Now in a bit more detail wrt your question: > > True PM purists won't like my proposals, such as (i) not including PM > in the entry and exit criteria of availability or (ii) the fact I > suggested stopping the PM counters at the end of 3s defect evaluation > period. We don't have to do either of these things of course...we > can go for full 'by the book' processing with the added complexity > and loss of information this might result in. Let me try and explain > what I mean by this. > > Nearly all (close to 100%) of SES events I ever saw were accompanied > by defect conditions in transport networks. But SES came in 2 > flavours (you may recall the reasons for this that I explained in a > long mail to you some time ago which I won't repeat here): (i) few > ms events at an effective error density 0.5 (ii) few seconds events > at an effective error density 0.5. Most <1s events self healed, so > did a few 1-2s events, but few >3s events ever did (ergo why 3s in > Y.1711 for defects).....and there was invariably a (server layer) > defect present for all this time, meaning there would be FDI inserted > into whatever the clients were (assuming they had an FDI). In other > words just looking for defects was sufficient to measure SES and thus > was the simple way to measure unavailability in transport networks. > > The few seconds SES events (which we called short-breaks) were however > rather important. These were 3 orders of magnitude bigger than the > few ms SES and they knocked over applications. This would not have > been such a problem if they were rare compared to the few ms SES > events. But they were not....I was very surprised to see a roughly > 50/50 split of these. But we had no method of measuring these...and > if they just got dumped in the same SES bucket with singleton PM SES > events we lost sight of them. You observed this behavior in an SDH network, right? It would be interesting to find out if th same behavior occurs in networks that rely on packet switching switching more than on SDH (e.g. ethernet-based metro networks). > > It was so we could also distinguish these, and not lose sight of them, > that I have suggested these be measured as a parameter in their own > right (albeit harmonised with the manner in which defect entry events > were defined). In other words a defect lasting 3-9s would register a > short-break event....else it will 'get lost' in the PM measurements > (and it obviously will not factor as an unavailability event). > However, letting these short-break events get captured by the PM > process will distort the metric objectives PM is intended to measure. > And it is this latter point that is the practical reason for saying > there is liitle point in continuing to meausre PM metrics after a > period of about 3s. > > However, you imply stopping PM measurements on defect entry (any?). > But this is critical on how one defines the defect entry criteria. > If this means the 3s as noted above they I'd be happy with that, but > if you were to imply defects detected in <<1s periods (as you can > easily do on transport networks) I would not, as I believe this > should still be counted in the PM category. Good point. I was thinking of defects that would be detected through MPLS CV or BFD. How do you deal with server-layer defects? Do they have any impact on MPLS PM, or would the LSP end-point wait for Loss of CV to occur? > > Note also that we should be a bit careful not to act too fast on <<1s > events as we can trigger prot-sw on (PM) error events that would > otherwise go away. > > Finally here, please note we don't have to make the simplifications I > suggested. The 'by the book' approach means one has to let all events > lasting <9s get registered as PM....though as I note this will distort > PM and we will lose sight of short-break events....and simply use the > 10s unavailable state entry/exit criteria to turn on/off PMs. I'd > settle for this, though I don't think its the smartest approach. I am not in favor of this 'by the book' approach. My concern is that I think that many service providers will run MPLS connectivity verification at rates (much) slower than once per second. In that case, a ten-second availability definition is useless. Therefore, I would prefer it if we could take availability out of the equation and relate PM to defects only. > >> >> 2) Isn't availability only relevant with respect to SLAs? In >> most networks, services are carried over multiple networks >> layers. Eg. an ethernet service can be carried over an >> MPLS-over-SONET-over-WDM core network. Defect conditions need >> to be defined for each network layer, but availability is >> only relevant for the end-to-end Ethernet service. Therefore, >> it seems to me that the SLA itself can provide the definition >> of availability (including a description of the verification >> process) and that there is not necessarily a need for a tight >> coupling with the defect definitions in the underlying network >> layers. > > NH=> If I have SDHoverMPLS which is the layer you would apply this > reasoning to? And what about MPLSoverSDH?...does this change things? > > Please also note that the SLA will apply to all layer networks. I disagree. A Service Level Agreement applies to a service (as the name implies) not to network layers. Assume for example the following service guarantee for an IP or Ethernet VPN service: - every 15 minutes, generate a Ping request from each CE router to each peer CE router in the same VPN - the number of failed ping attemps will not be more than X per Y hours Such an SLA is completely independent of the network layers over which the VPN service is carried. > If you were leasing capacity off some SP in some layer network X I'd > assume you want and SLA for that, and not just the services you were > then running over that. And if there was no alignment at all between > how the leasing SP specified his SLA and you specified your SLA then > what would do about that? SLAs need to be aligned, but that does not mean that there must be a consistent definition of availabillity. Obviously, it would be unwise if a service provider would offer his customers more stringent SLAs than he himself would get from a backbone provider. However, there is no problem if the customer SLAs are less stringent than the backbone provider's SLA. Therefore, I don't see why Ethernet services would need to inherit the availability definition used in SDH networks. > > My simple approach (because there are currently no rules for XoverY or > how many XoverY can be allowed in some global HRX) is to aim for as > much harmonisation as possible....some folks might call it 'backwards > compatibility', I'm just trying to be pragmatic. > > Now let me ask you a question if I may. I have made a fair stab at > defining quite a lot of stuff as simply as I can in Y.1711 (which > would apply to for p2p and p2mp). So can you please explain to me how > defects, availability and all this PM stuff is going to work on mp2p > constructs? As far as I can tell, most of the fault detection mechanisms work as well in mp2p constructs as in p2p constructs. As long as Connectivity Verification messages carry identifiers that uniquely identify a source-destination pair, all possible errors (loss of CV, mismerge, misbranching) can be detected. Also, ping, traceroute and loopback will still work. The only mechanism that does not work well in mp2p constructs is AIS insertion due to server layer defects. However, Service Providers can avoid mp2p construct if they setup LSPs with RSVP-TE. Since it is likely that services with stringent quality requirements are carried over traffic-engineered LSPs, whereas service with less stringent requirements are carried over autonomously-created LSP (through LDP), I don't see the problem with mp2p. > > regards, Neil >> >> Peter >> [snipped till the end] _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Jan 4 05:43:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00837; Tue, 4 Jan 2005 05:43:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClmMj-00026J-2x; Tue, 04 Jan 2005 05:56:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clm8P-0003pt-KD; Tue, 04 Jan 2005 05:41:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clm7l-0003Vc-Fo for mpls@megatron.ietf.org; Tue, 04 Jan 2005 05:41:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00624 for ; Tue, 4 Jan 2005 05:41:11 -0500 (EST) From: neil.2.harrison@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClmK4-00022T-Bv for mpls@ietf.org; Tue, 04 Jan 2005 05:53:59 -0500 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 4 Jan 2005 10:41:18 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Jan 2005 10:41:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] working group last call on draft-ietf-mpls-oam-frmwk-01.txt Date: Tue, 4 Jan 2005 10:41:15 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A353890A9F16EF@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: [mpls] working group last call on draft-ietf-mpls-oam-frmwk-01.txt Thread-Index: AcTx2dub9z+Hu0FhQGqVuT6cW8yDKgAVT68Q To: , , , , X-OriginalArrivalTime: 04 Jan 2005 10:41:16.0331 (UTC) FILETIME=[EB0DEFB0:01C4F249] X-Spam-Score: 0.3 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 Content-Transfer-Encoding: quoted-printable Hi Peter..... >=20 > Thanks, Neil. >=20 > A few comments in-line. NH=3D> Thanks....some attempted responses to these also in-line. >=20 > Peter >=20 >=20 > neil.2.harrison@bt.com wrote: > > Hi Peter..... > >=20 > >>=20 > >> Neil, > >>=20 > >> Two questions: > >>=20 > >> 1) You say that PM can not be defined without defining=20 > entry and exit=20 > >> criteria for availability. However, in Y.1711 you specify=20 > that PM SLA=20 > >> recording be turned off at the entry of the defect state.=20 > Does't this=20 > >> proof that PM is dependent on an unambiguous definition of defect=20 > >> states, but independent of the definition of availability? > > NH=3D> In my opinion, and from a practical point of view,=20 > 'yes' is the=20 > > trite answer.....but only with how I have specified defects=20 > here, so=20 > > let me explain this a bit further. Note - if you look at=20 > the ITU Recs=20 > > that deal with this they all define that a 10s period is to be used=20 > > for unavailability entry/exit and the turning off/on of PM, eg see=20 > > G.826 for example. > >=20 > > My main objectives were simplicity whilst concentrating on what is=20 > > operationally important based on many years of studying=20 > real tranport=20 > > networks. Now in a bit more detail wrt your question: > >=20 > > True PM purists won't like my proposals, such as (i) not=20 > including PM=20 > > in the entry and exit criteria of availability or (ii) the fact I=20 > > suggested stopping the PM counters at the end of 3s defect=20 > evaluation=20 > > period. We don't have to do either of these things of=20 > course...we can=20 > > go for full 'by the book' processing with the added complexity and=20 > > loss of information this might result in. Let me try and=20 > explain what=20 > > I mean by this. > >=20 > > Nearly all (close to 100%) of SES events I ever saw were=20 > accompanied=20 > > by defect conditions in transport networks. But SES came in 2=20 > > flavours (you may recall the reasons for this that I explained in a=20 > > long mail to you some time ago which I won't repeat here): =20 > (i) few ms=20 > > events at an effective error density 0.5 (ii) few seconds=20 > events at an=20 > > effective error density 0.5. Most <1s events self healed, so did a=20 > > few 1-2s events, but few >3s events ever did (ergo why 3s in Y.1711=20 > > for defects).....and there was invariably a (server layer) defect=20 > > present for all this time, meaning there would be FDI inserted into=20 > > whatever the clients were (assuming they had an FDI). In=20 > other words=20 > > just looking for defects was sufficient to measure SES and thus was=20 > > the simple way to measure unavailability in transport networks. > >=20 > > The few seconds SES events (which we called short-breaks)=20 > were however=20 > > rather important. These were 3 orders of magnitude bigger than the=20 > > few ms SES and they knocked over applications. This would not have=20 > > been such a problem if they were rare compared to the few ms SES=20 > > events. But they were not....I was very surprised to see a roughly=20 > > 50/50 split of these. But we had no method of measuring=20 > these...and=20 > > if they just got dumped in the same SES bucket with=20 > singleton PM SES=20 > > events we lost sight of them. >=20 > You observed this behavior in an SDH network, right? NH=3D> Not specifically. PDH and SDH networks really are just that, ie 'networks'.....we 'network' (switch) the trails of the various layer networks involved here (eg E1, VC12, etc). However, below these there are the (p2p) section layer transmission technologies. These can be electrical, optical or radio in nature. So what I was measuring was principally the error events orginally sourced from the line systems. However, if I was observing these via a E4, VC4, E1 or whatever layer network above these then the error events are likely to be modified by the framing structures that are used. For example, due to the way justification is defined for the PDH layer networks it means that quite short error events (10s of us) are highly likely to cause justification corruption (ie leads to a bit slip) and a non-linear extension of the error event (as the various nested layer network lose/recover framing). This non-linearity is not a problem, its just something to be aware of. > It would=20 > be interesting to find out if th same behavior occurs in=20 > networks that rely on packet switching switching more than =20 > on SDH (e.g. ethernet-based metro networks). NH=3D> I agree. I had to stop the program of research I had in place in the late 80s early 90s for various reasons (eg job changes). Then we were trying to mathematically quantify the behaviour of our transport networks so we could (i) better understand what was happening and (ii) define more meaningful SLAs. We suceeded and got some very useful data. However, since I stopped driving this work no one else here has continued it (at least to the detail we were looking at) and I am not aware of other operators doing similar studies. So I don't really know what real error events look like these days. It would be useful if we had this information. Is anyone reading this able to say anything on this matter? >=20 >=20 > >=20 > > It was so we could also distinguish these, and not lose=20 > sight of them,=20 > > that I have suggested these be measured as a parameter in their own=20 > > right (albeit harmonised with the manner in which defect=20 > entry events=20 > > were defined). In other words a defect lasting 3-9s would=20 > register a=20 > > short-break event....else it will 'get lost' in the PM measurements=20 > > (and it obviously will not factor as an unavailability event).=20 > > However, letting these short-break events get captured by the PM=20 > > process will distort the metric objectives PM is intended=20 > to measure.=20 > > And it is this latter point that is the practical reason for saying=20 > > there is liitle point in continuing to meausre PM metrics after a=20 > > period of about 3s. > >=20 > > However, you imply stopping PM measurements on defect entry (any?). > > But this is critical on how one defines the defect entry criteria.=20 > > If this means the 3s as noted above they I'd be happy with that, but > > if you were to imply defects detected in <<1s periods (as you can > > easily do on transport networks) I would not, as I believe this > > should still be counted in the PM category. >=20 > Good point. I was thinking of defects that would be detected=20 > through MPLS CV or BFD. >=20 > How do you deal with server-layer defects? Do they have any=20 > impact on MPLS PM, or would the LSP end-point wait for Loss=20 > of CV to occur? NH=3D> If we have a set of nested layer networks then there are 2 inheritance behaviours we should be aware of: - there is a 'static' 2-dimensional topological inheritance, ie one cannot improve on the disjoint connectivity of the duct graph.....this is critical to network survivability design (esp control/management plane networks) and impacts the availability metric. - there is a 'dynamic' 1-dimensional nested trail performance inheritance, due to the fact that a link-connection in layer network N is supported by a lower level trail in layer network N-1....and this recurses to the duct. Now from the 2nd point above, any impairments that arise in layer network M say get inherited (and possibly/likely(?) distorted) in layer network M+1. Of course layer network M will have its own type of impairments, and these will (in some way) be additive to those inherited from the lower layer network M+1. So, starting from the duct, we can observe that what an application sees PM-wise will be some form of PM addition across all the layer networks involved down to the duct. There are very good reasons why co-cs mode technologies usually sit at the bottom of the stack, ie these have the 'best' PM behaviour, eg low fixed abs delay with very low variance (due to the jittter/wander of the physics here), and clearly there is no such thing as 'congestion' impacting either loss or delay (which is why you will often see me remark that the co-cs mode has no QoS classes). Clearly this is not true of any packet-switching technologies....be these co-ps or cl-ps in mode....and of course network load is a critical factor here (though one can have CAC to control this with the co-ps mode since this has trails like the co-cs mode). So the degree of PM one sees is a function of the mode considered, network loading (if pkt-sw) and the type and number of XoverY client/server modal nestings allowed. So to answer your question...... - all layer networks at and above that where an error or defect event originates will 'see' that event in some manner - we should arrange that defects are detected and acted on in some sensible manner in nested layer networks, ie faster closer to the duct, slower closer to the application (which is why I express concern about folks wanting to act too fast too high in the stack) This of course assumes one has some logical design paradigm on what constitutes sensible X/Y client/server layer network relationships (and how many of these are allowed per some HRX). However, there are no formal rules here, at least at the present time. >=20 >=20 > >=20 > > Note also that we should be a bit careful not to act too=20 > fast on <<1s=20 > > events as we can trigger prot-sw on (PM) error events that would=20 > > otherwise go away. > >=20 > > Finally here, please note we don't have to make the=20 > simplifications I=20 > > suggested. The 'by the book' approach means one has to let=20 > all events=20 > > lasting <9s get registered as PM....though as I note this=20 > will distort=20 > > PM and we will lose sight of short-break events....and=20 > simply use the=20 > > 10s unavailable state entry/exit criteria to turn on/off PMs. I'd=20 > > settle for this, though I don't think its the smartest approach. >=20 >=20 > I am not in favor of this 'by the book' approach. NH=3D> Yes, I also have some concerns with this. I gave my reasons for = a pragmatic departure whilst trying to be at least consistent with how networks are currently specified. > My concern=20 > is that I think that many service providers will run MPLS=20 > connectivity verification at rates (much) slower than once=20 > per second. NH=3D> I have seen folks argue for very fast (ie must beat SDH 50ms) = and, as you note here, very slow defect detection/handling behaviour. My view however is simply this: As fast as possible when close to the duct, and as slow as possible when close to the application......though this does imply one has some view of what constitutes what sensible client/server relationships are allowed (else there is no logical ordering). The 3s defect detection periods in Y.1711 were (IMO at least) a practically sensible choice. Remember this however: If one varies the CV rate there is no possibility of consistent defect definition and detection/handling, eg imagine an LSPA with a CV rate of 1/min interferring with an LSPB with a CV rate of 1/s. In simple terms, the LSPB with the 1/s CV rate (and all clients supported by this) will see a cycle of in/out of defect state every minute. So be careful. We need some common sense here. > In that case, a ten-second availability=20 > definition is useless. Therefore, I would prefer it if we=20 > could take availability out of the equation and relate PM to=20 > defects only. NH=3D> I can see the thrust of your argument. But we do need to take a holistic view from duct to application, ie we have to consider the specification of all the layer networks involved due to: - inheritance=20 - the setting of mtce thresholds - consistency of SLAs between parties....IMO network buider services will always be required and we can't simply disregard this. If we don't have a some unifying view (ie across all layer networks) of what constitutes available/unavailable time then I cannot see how we can ever have any meaningful basis for SLAs. And I note here that arbitrary XoverY is making this even more of a requirement and not less of one. >=20 >=20 > >=20 > >>=20 > >> 2) Isn't availability only relevant with respect to SLAs? In most=20 > >> networks, services are carried over multiple networks=20 > layers. Eg. an=20 > >> ethernet service can be carried over an=20 > MPLS-over-SONET-over-WDM core=20 > >> network. Defect conditions need to be defined for each=20 > network layer,=20 > >> but availability is only relevant for the end-to-end Ethernet=20 > >> service. Therefore, it seems to me that the SLA itself can provide=20 > >> the definition of availability (including a description of the=20 > >> verification > >> process) and that there is not necessarily a need for a tight=20 > >> coupling with the defect definitions in the underlying network=20 > >> layers. > >=20 > > NH=3D> If I have SDHoverMPLS which is the layer you would apply this = > > reasoning to? And what about MPLSoverSDH?...does this=20 > change things? > >=20 > > Please also note that the SLA will apply to all layer networks. >=20 > I disagree. A Service Level Agreement applies to a service=20 > (as the name implies) not to network layers.=20 NH=3D> If only this were the case! You do realise operators currently sell 'technology' as 'services', eg FR, E1/T1 leased-lines, ATM, etc? And please do not overlook the fact that one man's service is another man's layer network.....this is the essence of all client/server relationships and it is a crucial aspect of all network builder services. >=20 > Assume for example the following service guarantee for an IP=20 > or Ethernet VPN service: >=20 > - every 15 minutes, generate a Ping request from each CE=20 > router to each peer CE router in the same VPN >=20 > - the number of failed ping attemps will not be more than X=20 > per Y hours >=20 > Such an SLA is completely independent of the network layers=20 > over which the VPN service is carried. NH=3D> So how are these specified then? And what about an SDHoverPSN PW here.....how is the SDH 'service' specified in this case? >=20 >=20 > > If you were leasing capacity off some SP in some layer=20 > network X I'd=20 > > assume you want and SLA for that, and not just the services=20 > you were=20 > > then running over that. And if there was no alignment at=20 > all between=20 > > how the leasing SP specified his SLA and you specified your=20 > SLA then=20 > > what would do about that? >=20 > SLAs need to be aligned, but that does not mean that there=20 > must be a consistent definition of availabillity. >=20 > Obviously, it would be unwise if a service provider would=20 > offer his customers more stringent SLAs than he himself would=20 > get from a backbone provider. However, there is no problem if=20 > the customer SLAs are less stringent than the backbone=20 > provider's SLA. Therefore, I don't see why Ethernet services=20 > would need to inherit the availability definition used in SDH=20 > networks. NH=3D> You seem to be implying some implicit ordering of what can be the client and what can be the server (which I would agree with). But what about a SDHoverPSN PW here? >=20 > >=20 > > My simple approach (because there are currently no rules=20 > for XoverY or=20 > > how many XoverY can be allowed in some global HRX) is to aim for as=20 > > much harmonisation as possible....some folks might call it=20 > 'backwards=20 > > compatibility', I'm just trying to be pragmatic. > >=20 > > Now let me ask you a question if I may. I have made a fair stab at=20 > > defining quite a lot of stuff as simply as I can in Y.1711 (which=20 > > would apply to for p2p and p2mp). So can you please=20 > explain to me how=20 > > defects, availability and all this PM stuff is going to=20 > work on mp2p=20 > > constructs? >=20 > As far as I can tell, most of the fault detection mechanisms=20 > work as well in mp2p constructs as in p2p constructs. As long=20 > as Connectivity Verification messages carry identifiers that=20 > uniquely identify a source-destination pair, all possible=20 > errors (loss of CV, mismerge, misbranching) can be detected. NH=3D> If you studied how mp2p is defined in func arch terms then you would note that demerging has to be performed by something above the mp2p level. A cl-ps client can always effect such recovery due to the fact each/every pkt carries a SA/DA pair (and of course the cl-ps mode cannot merge in the 1st place). A non-cl-ps client however requires one must run a p2p LSP above the mp2p construction to effect the demerging. So here the p2p label is proxing for the role of the SA. So one can run the OAM on the p2p construct and define defects here in a sensible way......but I don't know how to do this for the mp2p construct itself. regards, Neil > Also, ping, traceroute and loopback will still work. >=20 > The only mechanism that does not work well in mp2p constructs=20 > is AIS insertion due to server layer defects. >=20 > However, Service Providers can avoid mp2p construct if they=20 > setup LSPs with RSVP-TE. Since it is likely that services=20 > with stringent quality requirements are carried over=20 > traffic-engineered LSPs, whereas service with less stringent=20 > requirements are carried over autonomously-created LSP=20 > (through LDP), I don't see the problem with mp2p. >=20 >=20 > >=20 > > regards, Neil > >>=20 > >> Peter > >>=20 > [snipped till the end] >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Jan 4 11:07:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22391; Tue, 4 Jan 2005 11:07:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClrPW-0008Ni-7h; Tue, 04 Jan 2005 11:19:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clr6m-0002fW-5K; Tue, 04 Jan 2005 11:00:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clr0Y-0000cA-6d; Tue, 04 Jan 2005 10:54:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21602; Tue, 4 Jan 2005 10:54:04 -0500 (EST) Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClrCv-000886-Ci; Tue, 04 Jan 2005 11:06:54 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j04FrLJn018264; Tue, 4 Jan 2005 09:53:30 -0600 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (7.1.006) id 41C5B4F4002897EA; Tue, 4 Jan 2005 10:53:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2005 09:53:29 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060C8521@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [AVT] Comments on draft-ash-avt-ecrtp-over-mpls-protocol-01.txt Thread-Index: AcTo3VhU5ysATSwbT6eujl2Yed5yQQJky5GQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Magnus Westerlund" , "IETF AVT WG" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Subject: [mpls] RE: [AVT] Comments on draft-ash-avt-ecrtp-over-mpls-protocol-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Comments are in line. Thanks, Jerry=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Magnus Westerlund > Sent: Wednesday, December 22, 2004 4:30 PM > To: IETF AVT WG; rohc@ietf.org; mpls@ietf.org > Subject: [AVT] Comments on=20 > draft-ash-avt-ecrtp-over-mpls-protocol-01.txt >=20 > Hi, >=20 > Sorry for the crossposting, however this is something that I think needs > to be generally discussed between all 3 WGs. To me it looks like the > proposed solution for VoIP header compression across an MPLS network > contains a problematic demultiplexing mechanism. I don't think people=20 > has realized the issues with the proposed mechanism due to lack of=20 > communication between the header compression and MPLS folks. If it is my=20 > lack of knowledge please educate me, and the others. I would request=20 > that people providing input in this discussion is overly explaining as > education seems necessary. >=20 > The current draft is available at: > http://www.watersprings.org/pub/id/draft-ash-avt-ecrtp-over-mpls-protoco l-01.txt > it should also be available in the IETF repository if it hasn't expired. Jerry>> The latest draft is available at http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protoc ol-02.txt. > The header compression mechanisms such as CRTP and ROHC to my=20 > understanding assumes that they have a lower link layer that carries=20 > their compressed messages between compressor and decompressor. This is > due to that they are intended to be used with only a single link between=20 > the compressor and decompressor. In the case of CRTP, it also assumes=20 > that the link-layer can also provide the with identification of the=20 > packet types, while ROHC makes this identification internally. >=20 > The MPLS network uses one or more labels in the transport between=20 > ingress and egress from the MPLS network. Due to the possible relabeling=20 > in the middle of the network, it can't be generally assumed that packets=20 > arriving with the same label comes from the same ingress point. This=20 > makes the label not sufficient to identify the ingress for the egress, > thus not making labels equal to a link. >=20 > The proposed solution has thought of the above MPLS problem and proposes=20 > that one uses the setup signalling to allow the decompressor point to=20 > select which parts of its context identifier (SCID) space that belongs > to different ingress points that arrives over the same label. However my=20 > understanding is that this definitely not without problems for the=20 > header compression mechanisms. I would like the header compression guy > to clarify what problems that would arise from such a solution. One=20 > thing I definitely can see would be an issue, the proposed change would=20 > prevent MPLS HC to use any standard implementation of the HC=20 > mechanism used. >=20 > I would also like to point out that the Header Compression mechanism=20 > needs a return path from the decompressor mechanism. However the draft > does not seem to discuss this issue at all. Or is a MPLS label path=20 > automatically reversible? Jerry>> It is the CONTEXT_STATE packets that travel on the reverse path, as stated in the ID. Here is the relevant passage in the ID: "4. Compressed packets and header compression control packets (FULL_HEADER and CONTEXT_STATE packets) are routed on a separate LSP, set up by RSVP-TE, from non-compressed packets; FULL-HEADER packets are routed on the same R1/HC --> R4/HD LSP as the R1/HC to R4/HD compressed packets for the ECRTP flow; CONTEXT-STATE packets are routed on the same R4/HD --> R1/HC LSP as the R4/HD to R1/HC compressed packets for the=20 ECRTP flow. 5. compressed packets, FULL_HEADER packets, and CONTEXT_STATE packets are routed with MPLS labels. 6. R4/HD uses the incoming MPLS label and the SCID to locate the proper decompression context." I think this is quite clear. > It would be desirable if the MPLS people could consider if there exist > other ways of providing for the standard assumption on link layers that=20 > header compression has? For these assumption please see chapter 2 of RFC=20 > 2508, section 4.1 of RFC 3095, and RFC 3409. >=20 > For example, what would be the effects of requiring unique labels=20 > between ingress and egress and for the reverse path? >=20 > What effects would it have to put the multiplexing point in the layer=20 > two extension? Jerry>> FYI, the proposed protocol extensions in the current draft are much the same as originally proposed by George Swallow (almost 5 years ago) to the MPLS WG for the 'Simple Header Compression' protocol http://www.watersprings.org/pub/id/draft-swallow-mpls-simple-hdr-compres s-00.txt. > I would also like to see the draft be more header compression agnostic > as has been agreed on in the requirements phase. There is no problem=20 > with using ECRTP as an example how one realize the solution, however the=20 > necessary hooks and signalling must be in place for any header=20 > compression mechanism. Jerry>> It isn't obvious how to make this 'header compression agnostic' for 'any header compression mechanism', given the differences in HC protocol specifics, etc. Also, it's not clear whether that would really buy a lot: ROHC is the only other proposed protocol to be accommodated within HC over MPLS, and one more protocol extensions draft (perhaps taken on within the ROHC WG) seems like a reasonable approach. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jan 5 22:32:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19560; Wed, 5 Jan 2005 22:32:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmOaY-0003uR-Qg; Wed, 05 Jan 2005 22:45:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmOHi-0001um-Qi; Wed, 05 Jan 2005 22:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmODM-0000KQ-Bd for mpls@megatron.ietf.org; Wed, 05 Jan 2005 22:21:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18857 for ; Wed, 5 Jan 2005 22:21:29 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmOPy-0000DZ-QY for mpls@ietf.org; Wed, 05 Jan 2005 22:34:40 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CmODD-0006gO-T4 for mpls@ietf.org; Thu, 06 Jan 2005 03:21:23 +0000 Date: Wed, 5 Jan 2005 19:21:21 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1054880755.20050105192121@psg.com> To: mpls@ietf.org In-Reply-To: <1112699459.20050105162900@psg.com> References: <1112699459.20050105162900@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: Review Call: draft-andersson-rtg-gmpls-change-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit fyi -- Alex http://www.psg.com/~zinin This is a forwarded message From: Alex Zinin To: routing-discussion@ietf.org Cc: Date: Wednesday, January 5, 2005, 4:29:00 PM Subject: Review Call: draft-andersson-rtg-gmpls-change-00.txt ===8<==============Original message text=============== Folks- We'd like to solicit your comments on this document before Last-Call'ing it. Please send your comments to the routing-discussion mailing list. http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-00.txt MPLS and GMPLS Change Process draft-andersson-rtg-gmpls-change-00.txt Abstract The MPLS and GMPLS protocol suites have become quite popular for a growing number of applications and deployment scenarios. One result of this popularity is a large number of suggestions for modifications and extensions. The IETF needs to be flexible and responsive in how it handles these suggestions, and has a responsiblity to supervise the growth and evolution of MPLS and GMPLS protocols. This memo describes the process through which individuals, working groups and external standards bodies can influence the development of the MPLS and GMPLS standards. This process means that extensions and changes to protocols specified by these working groups can only be made through the IETF, the body that created the (G)MPLS ((Generalized) Multiprotocol Label Switching) technologies. -- Alex http://www.psg.com/~zinin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of original message text=========== _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Jan 6 16:33:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24962; Thu, 6 Jan 2005 16:33:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmfSb-0003U6-45; Thu, 06 Jan 2005 16:46:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmedu-0003q9-Rv; Thu, 06 Jan 2005 15:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmeX0-0007tc-4I for mpls@megatron.ietf.org; Thu, 06 Jan 2005 15:46:54 -0500 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14904 for ; Thu, 6 Jan 2005 15:46:51 -0500 (EST) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CmeQB-0003CE-9G; Thu, 06 Jan 2005 15:39:51 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 06 Jan 2005 15:39:51 -0500 Cc: mpls@ietf.org Subject: [mpls] Last Call: 'Link Bundling in MPLS Traffic Engineering' to Proposed Standard X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has received a request from the Multiprotocol Label Switching WG to consider the following document: - 'Link Bundling in MPLS Traffic Engineering ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-06.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jan 10 19:18:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16936; Mon, 10 Jan 2005 19:18:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co9y3-0006pA-GO; Mon, 10 Jan 2005 19:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co9aH-0003aY-0g; Mon, 10 Jan 2005 19:08:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co9PS-0000O6-7z for mpls@megatron.ietf.org; Mon, 10 Jan 2005 18:57:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15889 for ; Mon, 10 Jan 2005 18:57:15 -0500 (EST) Received: from 67.111.75.190.ptr.us.xo.net ([67.111.75.190] helo=BCNW02.bcn-inc.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co9d5-0006Rf-Vl for mpls@ietf.org; Mon, 10 Jan 2005 19:11:28 -0500 Received: from mail pickup service by BCNW02.bcn-inc.net with Microsoft SMTPSVC; Mon, 10 Jan 2005 15:56:37 -0800 X-Contents: 0a192656e7bab47db66144f0e6718d29 thread-index: AcT3cAWgtT5O1oqnSwu99gsQv/92BQ== Thread-Topic: [MailServer Notification]To Recipient virus found and action taken. From: To: Date: Mon, 10 Jan 2005 15:56:37 -0800 Message-ID: <000101c4f770$05a00ef0$020a0a0a@bcninc.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 10 Jan 2005 23:56:37.0786 (UTC) FILETIME=[05BC97A0:01C4F770] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [mpls] [MailServer Notification]To Recipient virus found and action taken. X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = mpls-bounces@lists.ietf.org Recipient(s) = mpls@ietf.org Subject = [mpls] Delivery reports about your e-mail Scanning time = 1/10/2005 3:56:37 PM Engine/Pattern = 7.000-1004/2.339.00 Action on virus found: The attachment transcript.zip contains WORM_MYDOOM.M virus. ScanMail has Deleted it. Warning to recipient. ScanMail has detected a virus. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jan 12 18:33:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29043; Wed, 12 Jan 2005 18:33:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CosDS-0003Hf-EH; Wed, 12 Jan 2005 18:47:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorkY-0002kV-M4; Wed, 12 Jan 2005 18:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorhR-0000jP-DL; Wed, 12 Jan 2005 18:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27578; Wed, 12 Jan 2005 18:14:46 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CorvX-0002wr-Th; Wed, 12 Jan 2005 18:29:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2005 15:14:15 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0CNE6l2006174; Wed, 12 Jan 2005 15:14:07 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-181.cisco.com [10.86.240.181]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA09242; Wed, 12 Jan 2005 15:14:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) To: Mailing List , mpls@ietf.org, idr@ietf.org, ccamp@ops.ietf.org, isis-wg@ietf.org Message-Id: From: JP Vasseur Date: Wed, 12 Jan 2005 18:14:19 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 Subject: [mpls] Fwd: WG Action: Path Computation Element (pce) X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0288458767==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a --===============0288458767== Content-Type: multipart/alternative; boundary=Apple-Mail-42-562924577 --Apple-Mail-42-562924577 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: > From: The IESG > Date: January 12, 2005 3:39:31 PM EST > To: IETF-Announce@ietf.org > Cc: pce@ietf.org, Adrian Farrel , JP Vasseur > > Subject: WG Action: Path Computation Element (pce) > > A new IETF working group has been formed in the Routing Area. For > additional > information, please contact the Area Directors or the WG Chairs. > > Path Computation Element (pce) > ================================ > > Current Status: Active Working Group > > Chair(s): > Adrian Farrel > JP Vasseur > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Mailing Lists: > General Discussion: pce@ietf.org > To Subscribe: pce-request@ietf.org > In Body: subscribe pce > Archive: http://www.ietf.org/mail-archive/web/pce/ > > Description of Working Group: > > The PCE Working Group is chartered to specify a Path Computation > Element (PCE) > based architecture for the computation of paths for MPLS and GMPLS > Traffic > Engineering LSPs. > > In this architecture path computation does not occur on the head-end > (ingress) > LSR, but on some other path computation entity that may physically not > be > located on the head-end LSR. > > The PCE WG will work on application of this model within a single > domain > or within a small group of domains (where a domain is a layer, IGP area > or Autonomous System with limited visibility from the head-end LSR). > At this time, applying this model to large groups of domains such as > the > Internet is not thought to be possible, and the PCE WG will not spend > energy on that topic. > > The WG will specify a protocol for communication between LSRs (termed > Path > Computation Clients - PCCs) and PCEs, and between cooperating PCEs. > This > protocol will be capable of representing requests for path computation > including a full set of constraints, will be able to return multiple > paths, and > will include security mechanisms such as authentication and > confidentiality. > > The WG will determine requirements for extensions to existing routing > and > signaling protocols in support of PCE discovery and signaling of > inter-domain > paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, > ISIS-TE and > BGP. Any necessary extensions will be produced in collaboration with > the > Working Groups responsible for the protocols. > > The Working Group will also work on the definition of metrics to > evaluate path quality, scalability, responsiveness and robustness of > path computation models. > > Work Items: > > - Functional specification of MPLS and GMPLS Traffic Engineered LSP > path > computation models involving Path Computation Element(s). This > includes the case of computing the paths of intra and inter-domain > TE LSPs. Such path computation includes the generation of primary, > protection and recovery paths, as well as computations for > (local/global) > reoptimization and load balancing. The WG will address the inter-area > (single IGP domain) scenario first. WG progress will be evaluated > before > inter-AS related work is started. > > - Specification of the PCE-based architecture. > > - Specification of requirements and protocol extensions related to > the policy, and security aspects of PCE-based path computation > involving > PCEs of multiple administrative entities. > > - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models. > > - Specification of techniques in support of PCE discovery within and > across domains. Where such techniques result in the extensions of > existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in > conjunction with the appropriate WGs. > > - Specification of a new communication protocol for use between a PCC > and a PCE, and between PCEs. A single protocol will be selected from > among candidates that include the existing protocols defined in other > WGs. > > - Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and > scalability of path computation models. > > Review of the document "Requirements for path computation element in > GMPLS inter-domain networks" produced by the CCAMP WG. > > > Goals and Milestones: > > Feb 05: Submit first draft of PCE architecture document > > Feb 05: Submit first draft of PCE discovery requirements and protocol > extensions documents > > Apr 05: Submit first draft of the PCE communication protocol > requirements > > May 05: Submit first draft of the definition of objective metrics > > Jul 05: Submit first draft of the PCE communication protocol > specification > > Aug 05: Submit PCE architecture specification to the IESG to be > considered as Informational RFC > > Nov 05: Submit first draft of applicability statement (describing the > processes > and procedures for the use of the PCE architecture, protocols > and protocol extensions for inter-area MPLS and GMPLS Traffic > Engineering) > > Nov 05: Submit first draft of the MIB module for the PCE protocol > > Dec 05: Submit PCE communication protocol requirements to the IESG to > be > considered as an Informational RFC > > Dec 05: Submit PCE discovery protocol extensions specifications to the > IESG to be considered as a Proposed Standard > > Dec 05: Submit PCE communication protocol specification to the IESG to > be considered as a Proposed Standard > > Feb 06: Submit the applicability and metrics documents to the IESG to > be > considered as Informational RFC > > Feb 06: Evaluate WG progress, recharter or close. > --Apple-Mail-42-562924577 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: Helvetica0000,0000,0000From: HelveticaThe IESG < 0000,0000,0000Date: January 12, 2005 3:39:31 PM EST 0000,0000,0000To: IETF-Announce@ietf.org 0000,0000,0000Cc: pce@ietf.org, Adrian Farrel <, JP Vasseur < 0000,0000,0000Subject: WG Action: Path Computation Element (pce) A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Path Computation Element (pce) ================================ Current Status: Active Working Group Chair(s): Adrian Farrel < JP Vasseur < Routing Area Director(s): Bill Fenner < Alex Zinin < Routing Area Advisor: Alex Zinin < Mailing Lists: General Discussion: pce@ietf.org To Subscribe: pce-request@ietf.org In Body: subscribe pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Goals and Milestones: Feb 05: Submit first draft of PCE architecture document Feb 05: Submit first draft of PCE discovery requirements and protocol extensions documents Apr 05: Submit first draft of the PCE communication protocol requirements May 05: Submit first draft of the definition of objective metrics Jul 05: Submit first draft of the PCE communication protocol specification Aug 05: Submit PCE architecture specification to the IESG to be considered as Informational RFC Nov 05: Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering) Nov 05: Submit first draft of the MIB module for the PCE protocol Dec 05: Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Dec 05: Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Dec 05: Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Feb 06: Submit the applicability and metrics documents to the IESG to be considered as Informational RFC Feb 06: Evaluate WG progress, recharter or close. --Apple-Mail-42-562924577-- --===============0288458767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0288458767==-- From mpls-bounces@ietf.org Thu Jan 13 02:03:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00495; Thu, 13 Jan 2005 02:03:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CozFF-0003f3-Rp; Thu, 13 Jan 2005 02:18:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoyyU-0005uL-CV; Thu, 13 Jan 2005 02:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoyxR-0005HZ-43 for mpls@megatron.ietf.org; Thu, 13 Jan 2005 01:59:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26707 for ; Thu, 13 Jan 2005 01:59:47 -0500 (EST) Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CozBY-0003a0-S3 for mpls@ietf.org; Thu, 13 Jan 2005 02:14:28 -0500 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 13 Jan 2005 12:35:07 +0530 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from ind-mira-01.cisco.com (IDENT:mirapoint@ind-mira-01.cisco.com [64.104.129.12]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0D6x6Hp003254 for ; Thu, 13 Jan 2005 06:59:07 GMT Received: from agoyalw2k (dhcp-10-77-7-158.cisco.com [10.77.7.158]) by ind-mira-01.cisco.com (MOS 3.4.6-GR) with ESMTP id AHV06207; Thu, 13 Jan 2005 12:24:40 +0530 (IST) Message-Id: <200501130654.AHV06207@ind-mira-01.cisco.com> From: "Amit Goyal \(agoyal\)" To: Date: Thu, 13 Jan 2005 12:29:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: AcT5PV+/o8hKP/ubTaOFxlXzuiBGKw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [mpls] Lsp ping question X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: agoyal@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Hi All, I have couple of questions regarding the operation of lsp ping and trace route. 1. If an intermediate router does the FEC aggregation then how lsp ping works for e.g. A -------------- B --------------- C | |---------------- C' In the above case B does the FEC aggregation for both C and C'. a. Does the lsp ping from A for the aggregated FEC terminates at node B? b. What if I does lsp ping for FEC corresponding to C' only? Is it possible to do that, as A is not having label mapping for the C' FEC. 2. In case of different tunnel levels in network topology, the lsp ping would contain the FEC stack of depth > 1 to get it across the tunnel. If lsp ping is performed (not trace route) then does the tunnel egress after stripping of corresponding label stack, forwards the MPLS Echo Request further or it sends MPLS Echo Reply with the return code 8 "Label switched at stack-depth" (assuming it has the forwarding information) Any insight on the above questions would be of great help. Thanks in advance, Amit Goyal _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From Isocore_events-bounces@isocore.com Fri Jan 14 14:58:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09700 for ; Fri, 14 Jan 2005 14:58:43 -0500 (EST) Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpXpF-0002as-Lb for mpls-archive@ietf.org; Fri, 14 Jan 2005 15:13:44 -0500 Received: from localhost ([127.0.0.1] helo=ns1.cpanel.btnaccess.com) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.43) id 1CpXF4-0006IB-PH; Fri, 14 Jan 2005 14:36:18 -0500 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.43) id 1CpXEt-0006HO-JB for isocore_events@isocore.com; Fri, 14 Jan 2005 14:36:07 -0500 Received: from 68.49.141.82 ([68.49.141.82]) by isocore.com (IMP) with HTTP for ; Fri, 14 Jan 2005 14:36:07 -0500 Message-ID: <1105731367.41e81f27493ff@isocore.com> Date: Fri, 14 Jan 2005 14:36:07 -0500 From: kkhanna@isocore.com To: isocore_events@isocore.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 68.49.141.82 Subject: [Isocore_events] iPOP 2005: Call for Participation X-BeenThere: Isocore_events@isocore.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: list-admin@isocore.com List-Id: isocore_events_isocore.com.isocore.com List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: Isocore_events-bounces@isocore.com Errors-To: Isocore_events-bounces@isocore.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 8bit Greetings, We wanted to inform you all of Asia's premier conference on IP-Optical, iPOP 2005. Isocore is a proud sponsor of the conference, and encourages participation in this no-fee event. The following Call for Participation has been issued for the conference: - CALL FOR PARTICIPATION - The International Conference on IP + Optical Network (iPOP 2005) GMPLS Interoperability Public Demonstration, Exhibition and Conference Tokyo, Japan, February 21-22, 2005 http://www.pilab.org/ipop2005/ iPOP 2005 is the international conference showcasing breakthrough IP and Optical technologies for the next-generation network infrastructure. It is intended to share the latest results among industry and academia, and experience in state-of-the-art of "IP and Optical Networking technologies". Following this theme, it will provide a showcase for GMPLS interoperability, which is the first demonstration of its kind in Asia. Additionally, it will exhibit GMPLS network equipment (IP routers, SONET/SDH XCs, Optical/Photonic XCs), GMPLS protocol test equipment, GMPLS network operation support tools, Optical Switches, and other related devices. The conference also features keynotes, special and technical sessions by leaders of IP and Photonic Network technologies from academia and industry. We hope for your participation. YOU WILL ENJOY: * GMPLS Interoperability Demonstrations by world-wide vendors: - Multi-Region Routing and Signaling - Multi-Layer Traffic Engineering - MPLS/GMPLS Migration - GMPLS-based Protection and Restoration * Exhibition of state-of-the-art photonic network products: - GMPLS network equipment: IP routers, SONET/SDH XCs, Optical/Photonic XCs - GMPLS protocol test equipment, - GMPLS network operation support tools, - Optical switches and other devices. * Conference sessions on - Interoperability of IP and Optical Networking Products and Services - Field trial Plan/Report - Network Operator Experience - Advances of GMPLS and Future Optical Networking Technologies CONFIRMED SPEAKERS - Prof. Tomonori Aoyama, University of Tokyo, Japan. - Prof. Shoichiro Asano, the National Institute of Informatics (NII), Japan. - Mr. Hisao Iizuka, NTT Communications, Japan. - Dr. Bijan Jabbari, ISOCORE, USA. - Prof. Ken-ichi Kitayama, Osaka University, Japan. - Dr. Tatsuzo Koga, Tsukuba JGN II Research Center, Japan. - Mr. Rajiv Papneja, ISOCORE, USA. - Dr. Rajiv Ramaswami, Cisco Systems, USA. - Mr. Jerry Sobieski, Mid-Atlantic Crossroads, USA. - Dr. Masatoshi Suzuki, KDDI Laboratories, Japan. - Ms. Amy Wang, Avici Systems, USA. - Prof. Naoaki Yamanaka, Keio University, Japan. REGISTRATION Attendance to iPOP 2005 is FREE OF CHARGE with pre-registration required. Please register at http://www.pilab.org/ipop2005/ through January 31, 2005. LOCATION The venue, Tokyo Fashion Town (TFT) Hall is located in Tokyo's newly developed seafront area known as Odaiba. It is easily accessible by public transport from downtown Tokyo and Narita International Airport. For more information, please visit the iPOP 2005 Web site at . TENTATIVE CONFERENCE PROGRAM February 21, 2005 * Opening Addresses - Prof. Tomonori Aoyama (General Chair, University of Tokyo) - Dr. Bijan Jabbari (General Chair, ISOCORE) * Keynote - IP + Optical in the Next Generation Network by Dr. Rajiv Ramaswami (Cisco Systems) * Program Introduction - Mr. Tadanobu Okada (TPC Chair, NTT) * Special Session 1: Toward Truly Interoperable IP and Optical Networking Products and Services - Mr. Rajiv Papneja (ISOCORE) - Prof. Naoaki Yamanaka (Organization Committee Chair, PIL) - Ms. Amy Wang (OIF) * Special Session 2: Project Report: IP+Optical Testbed - Super SINET by Prof. Shoichiro Asano (NII) - JGN II by Dr. Tatsuzo Koga (Tsukuba JGN II Research Center) - 863 Project (China: Inviting) - Keihanna by Prof. Ken-ichi Kitayama (Osaka University) - Dragon Project by Mr. Jerry Sobieski (Mid-Atlantic Crossroads) * Public Demonstration GMPLS Interop Showcase at Exhibition Hall * Special Session 3: Visions for the Next Generation IP+Optical Network Research and Development - Mr. Hisao Iizuka (NTT Communications) - Dr. Masatoshi Suzuki (KDDI Laboratories) February 22, 2005 * Technical Session 1: Multi-layer: IP+Optical * Technical Session 2: New services: VPN, QoS, Grid * Technical Session 3: Migration Scenario to GMPLS Networks * Technical Session 4: Implementation Report Experiments SPONSORSHIP PIL (Photonic Internet Lab, http://www.pilab.org), founded by 6 vendors and 1 service provider in 2002, is promoting R&D on next-generation photonic network control protocols based on photonic technologies for managed networks. ISOCORE (http://www.isocore.com) is the leading technology validation lab in the next generation IP and optical networking. Its goal is to advance internetworking through technology validation and product verification and to promote development and rapid deployment of innovative networking technologies. PIF (Photonic Internet Forum, http://www.scat.or.jp/photonic/english/) is a non-profit organization contributing to the progress of info- communication technology to realize all optical ultra-high-speed networks. ************************************************************************ Regards, Kavita --------------------------------------- ISOCORE Corp. 12359 Sunrise Valley Drive, Suite 100 Reston, Virginia 20191 703.860.9275 (Office) 571.332.3207 (Cell) kkhanna@isocore.com http://www.isocore.com --------------------------------------- _______________________________________________ Isocore_events mailing list http://www.isocore.com To unsubscribe, send email to list-admin@isocore.com From mpls-bounces@ietf.org Fri Jan 14 16:16:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20922; Fri, 14 Jan 2005 16:16:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpZ2W-0005rO-7x; Fri, 14 Jan 2005 16:31:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpYGI-0002Qd-OF; Fri, 14 Jan 2005 15:41:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpY8K-0004EG-LV; Fri, 14 Jan 2005 15:33:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14394; Fri, 14 Jan 2005 15:33:23 -0500 (EST) Message-Id: <200501142033.PAA14394@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 14 Jan 2005 15:33:22 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-nodeid-subobject-03.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definition of an RRO node-id subobject Author(s) : J. Vasseur, et al. Filename : draft-ietf-mpls-nodeid-subobject-03.txt Pages : 9 Date : 2005-1-14 In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering LSP on a downstream LSR. However, existing protocol mechanisms are not sufficient to find an MP address in multi-areas or multi-domain routing networks. Hence, the current MPLS Fast Reroute mechanism cannot be used to protect inter-area or inter-AS TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. Such functionality has been listed as a clear requirement in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]. This document specifies the use of existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to define the node-id subobject in order to solve this issue. Note that the MPLS Fast reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-nodeid-subobject-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-mpls-nodeid-subobject-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-mpls-nodeid-subobject-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" Content-Type: text/plain Content-ID: <2005-1-14153323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-nodeid-subobject-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-nodeid-subobject-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-14153323.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Tue Jan 18 03:39:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00378; Tue, 18 Jan 2005 03:39:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqp8x-00012h-Kv; Tue, 18 Jan 2005 03:55:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqomP-0005rc-4Q; Tue, 18 Jan 2005 03:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqogF-0004iq-Kc; Tue, 18 Jan 2005 03:25:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29564; Tue, 18 Jan 2005 03:25:37 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqovR-0000m6-Lv; Tue, 18 Jan 2005 03:41:23 -0500 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0I8PUvD002538; Tue, 18 Jan 2005 09:25:31 +0100 (MET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jan 2005 09:25:29 +0100 Received: from [147.214.34.55] ([147.214.34.55]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Jan 2005 09:25:29 +0100 Message-ID: <41ECC7F8.5050900@ericsson.com> Date: Tue, 18 Jan 2005 09:25:28 +0100 From: Magnus Westerlund User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" References: <9473683187ADC049A855ED2DA739ABCA060C8521@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA060C8521@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2005 08:25:29.0135 (UTC) FILETIME=[44BAFBF0:01C4FD37] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, rohc@ietf.org, IETF AVT WG Subject: [mpls] Re: [AVT] Comments on draft-ash-avt-ecrtp-over-mpls-protocol-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Hi Jerry, Sorry for the delay in responding. Also I would still like to hear some response from the header compression people about the SCID issues. In regards to rechartering I will send out a message to AVT with a proposed new charter for the WG members to comment on. See comments inline. Ash, Gerald R (Jerry), ALABS wrote: >> >>I would also like to point out that the Header Compression mechanism >>needs a return path from the decompressor mechanism. However the draft > > >>does not seem to discuss this issue at all. Or is a MPLS label path >>automatically reversible? > > > Jerry>> It is the CONTEXT_STATE packets that travel on the reverse path, > as stated in the ID. Here is the relevant passage in the ID: > > "4. Compressed packets and header compression control packets > (FULL_HEADER and CONTEXT_STATE packets) are routed on a separate LSP, > set up by RSVP-TE, from non-compressed packets; FULL-HEADER packets are > routed on the same R1/HC --> R4/HD LSP as the R1/HC to R4/HD compressed > packets for the ECRTP flow; CONTEXT-STATE packets are routed on the same > R4/HD --> R1/HC LSP as the R4/HD to R1/HC compressed packets for the > ECRTP flow. > 5. compressed packets, FULL_HEADER packets, and CONTEXT_STATE packets > are routed with MPLS labels. > 6. R4/HD uses the incoming MPLS label and the SCID to locate the proper > decompression context." > > I think this is quite clear. > No, it is not clear. This text seems more a statement of intention, than an actual solution. This is important part of the solution and effects the signalling and multiplexing mechanism. Can I assume that the same need to be able to multiplex multiple peers onto the same LSP exist also in the return path? > >>It would be desirable if the MPLS people could consider if there exist > > >>other ways of providing for the standard assumption on link layers > > that > >>header compression has? For these assumption please see chapter 2 of > > RFC > >>2508, section 4.1 of RFC 3095, and RFC 3409. >> >>For example, what would be the effects of requiring unique labels >>between ingress and egress and for the reverse path? >> >>What effects would it have to put the multiplexing point in the layer >>two extension? > > > Jerry>> FYI, the proposed protocol extensions in the current draft are > much the same as originally proposed by George Swallow (almost 5 years > ago) to the MPLS WG for the 'Simple Header Compression' protocol > http://www.watersprings.org/pub/id/draft-swallow-mpls-simple-hdr-compres > s-00.txt. > Okay, but you haven't answered my question. What would be the effect of putting the multiplexing that you propose using a split SCID space into the layer 2 extension? > >>I would also like to see the draft be more header compression agnostic > > >>as has been agreed on in the requirements phase. There is no problem >>with using ECRTP as an example how one realize the solution, however > > the > >>necessary hooks and signalling must be in place for any header >>compression mechanism. > > > Jerry>> It isn't obvious how to make this 'header compression agnostic' > for 'any header compression mechanism', given the differences in HC > protocol specifics, etc. Also, it's not clear whether that would really > buy a lot: ROHC is the only other proposed protocol to be accommodated > within HC over MPLS, and one more protocol extensions draft (perhaps > taken on within the ROHC WG) seems like a reasonable approach. > > To my understanding this solution consists of three parts. 1. Setup signalling 2. MPLS transport and multiplexing of header compression messages 3. Any potential extensions or adaptation to make the header compression work over the MPLS generated properties. To my understanding the setup signalling must be generic and allow the setup of any header compression mechanism. So this part in my view needs to be HC mechanism agnostic. The MPLS transport of compressed messages may not be agnostic but are probably similar. If a header compression mechanism needs special extension or clarifications, like ROHC over re-ordering channels, fine. However we must ensure that the common requirements that the available HC mechanisms put, is supported by the MPLS HC solution. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Jan 18 05:16:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08397; Tue, 18 Jan 2005 05:16:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqqeW-0003hV-Uw; Tue, 18 Jan 2005 05:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqqJH-00012q-MS; Tue, 18 Jan 2005 05:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqqIs-0000nq-CW for mpls@megatron.ietf.org; Tue, 18 Jan 2005 05:09:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07957 for ; Tue, 18 Jan 2005 05:09:35 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqqY5-0003XE-BZ for mpls@ietf.org; Tue, 18 Jan 2005 05:25:22 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0IA9Qqf001851 for ; Tue, 18 Jan 2005 19:09:31 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0IA9Pxw024984 for ; Tue, 18 Jan 2005 19:09:26 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0IA9P0F024969 for ; Tue, 18 Jan 2005 19:09:25 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0IA9Orl000637 for ; Tue, 18 Jan 2005 19:09:24 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0IA9M25000612 for ; Tue, 18 Jan 2005 19:09:22 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0IA9LBH022436 for ; Tue, 18 Jan 2005 19:09:21 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0IA9Lur028271 for ; Tue, 18 Jan 2005 19:09:21 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j0IA9KaD028266; Tue, 18 Jan 2005 19:09:20 +0900 (JST) Received: from win-yasukawa.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id TAA02550; Tue, 18 Jan 2005 19:09:19 +0900 (JST) Message-Id: <5.0.2.5.2.20050118182723.0659d4d0@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Tue, 18 Jan 2005 19:23:33 +0900 To: mpls@ietf.org From: Seisho Yasukawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [mpls] Next MPLS-TE P2MP Requirements Issue X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Hi, Thank you for your support in the discussion of the first MPLS-TE P2MP signaling requirements issue and I am sorry for breaking up the discussion for a while. I would like to move on to the next open issue which is in section 4.10 of the draft (draft-ietf-mpls-p2mp-sig-requirement-00.txt) This section discusses re-optimization of P2MP LSP trees. The main intention is that the ingress LSR is able to perform any form of re-optimization of all or part of the tree and that such an operation should be available in a way that has minimal impact on the service (i.e. negligible traffic hit). The section concludes with the paragraph... The solution SHOULD also provide the ability for the ingress LSR to have a strict control on the re-optimization process. Such re-optimization MAY be initiated by the sub-tree root branch node (that is, the branch node MAY setup a new sub-tree, then splice traffic on the new subtree and delete the former sub-tree). This paragraph is open to some debate. [Debate 1] Should a non-ingress LSR (branch & transit) be allowed to notice that re-optimizataion is possible ? Our opinion is yes. [Debate 2] What should it do when it does notice ? a. Act autonomously ? b. Act autonomously, but only if granted permission by the ingress on LSP setup ? c. Notify the ingress of potential re-optimization and allow the ingress to act ? Previous discussion said that it was dangerous to allow re-optimization out of the control of the ingress LSR. At the least, the ingress should have the ability to grant or deny permission for autonomous re-optimization. This can be compared to draft-vasseur-ccamp-loose-path-reopt-02.txt for P2P TE LSPs, but there may be additional mechanisms available to facilitate splicing new sub-trees in P2MP MPLS-TE. There are some immediate concerns about the possibility of re-convergence (merging) of the data tree as a result of partial re-optimization outside the control of the ingress LSR. However, no re-optimization is ever allowed to avoid the explicit path of the LSP, so the problem is no different from that which exists with loose hops in the first place. [A separate discussion on how tree remerge is handled comes later in this thread.] [Debate 3] Can re-optimization be carried out by any downstream LSR ? We think the answer is yes. That is, each downstream LSR may consider itself to be the root of a sub-tree and may perform whatever re-optimization is required. This reasoning led us to the original paragraph which we would like to refine as follows: The solution SHOULD also provide the ability for the ingress LSR to have a strict control on the re-optimization process. The ingress LSR SHOULD be able to limit all re-optimization to be source- initiated. Where sub-tree re-optimization is allowed by the ingress LSR, such re-optimization MAY be initiated by a downstream LSR that is the root of the sub-tree that is to be re-optimized. Sub-tree re-optimization initiated by a downstream LSR MUST be carried out with the same regard to minimizing the hit on active traffic as was described above for other re-optimization. Please contribute your opinions. Thanks, Seisho. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Jan 18 10:15:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00537; Tue, 18 Jan 2005 10:15:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqvKN-0002CG-O7; Tue, 18 Jan 2005 10:31:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CquyU-0001RG-1f; Tue, 18 Jan 2005 10:08:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cquwc-0000V5-7Z for mpls@megatron.ietf.org; Tue, 18 Jan 2005 10:06:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29322 for ; Tue, 18 Jan 2005 10:06:56 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqvBs-0001xv-SS for mpls@ietf.org; Tue, 18 Jan 2005 10:22:46 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2005 10:20:24 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0IF6MoA006793; Tue, 18 Jan 2005 10:06:23 -0500 (EST) Received: from [10.86.162.189] (dhcp-10-86-162-189.cisco.com [10.86.162.189]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOK18126; Tue, 18 Jan 2005 10:06:18 -0500 (EST) In-Reply-To: <41C828A3.4020108@pi.se> References: <41C828A3.4020108@pi.se> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <82798D5E-6962-11D9-8236-000D93AD480A@cisco.com> Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [mpls] draft-ietf-mpls-p2mp-sig-requirement-00.txt Date: Tue, 18 Jan 2005 10:06:20 -0500 To: mpls@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Monique Morrow X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit MPLS WG, This note is an update on the p2mp requirement discussion pertaining to its relationship to the MPLS OAM Requirements and OAM Framework drafts that we had on the list a few weeks ago. The various parties involved have agreed to the following to resolve the situation as follows. The P2MP co-authors should craft-up new text for two new documents: a P2MP-OAM-Requirements + P2MP-OAM-Framework. These documents will reference the existing requirements and framework documents. Dave and I agreed to co-author/edit these new drafts with the p2mp co-authors to assist with them and to also ensure their alignment with the existing documents. In the meantime, this leaves Dave and I with just edits left on the Framework document that Adrian Farrel sent out during last call, which I believe we have accomplished, and then that draft is finished. We should be re-spinning the updated draft in the next few days. It also now appears that the MPLS OAM Requirements is therefore completed, and is ready to ship to the IESG. Regards, Tom/Dave/Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jan 19 05:21:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28052; Wed, 19 Jan 2005 05:21:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrDCx-00063Y-LU; Wed, 19 Jan 2005 05:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrCuv-0005OR-5F; Wed, 19 Jan 2005 05:18:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrCok-0003nl-JS for mpls@megatron.ietf.org; Wed, 19 Jan 2005 05:12:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27004 for ; Wed, 19 Jan 2005 05:11:59 -0500 (EST) Received: from smtp5.clb.oleane.net ([213.56.31.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrD48-0005gx-UQ for mpls@ietf.org; Wed, 19 Jan 2005 05:28:00 -0500 Received: from PAVILLONTROIS (upperside.rain.fr [194.206.151.59] (may be forged)) (authenticated) by smtp5.clb.oleane.net with ESMTP id j0JABBt3000520 for ; Wed, 19 Jan 2005 11:11:15 +0100 Message-Id: <200501191011.j0JABBt3000520@smtp5.clb.oleane.net> From: "Michel Gosse" To: Date: Wed, 19 Jan 2005 11:11:06 +0100 Organization: Upper Side Conferences MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcT+DzCEg+OOBaehSByQWqoeUokN5Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Subject: [mpls] MPLS World Congress 2005 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0068605544==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc This is a multi-part message in MIME format. --===============0068605544== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C4FE17.92BD7810" This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C4FE17.92BD7810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 2005 edition of MPLS World Congress will stand in Paris in one month. Please feel free to visit: http://www.upperside.fr/mplsworldcongress05/mplsworld2005intro.htm Thanks. Michel Gosse michelg@upperside.fr ------=_NextPart_000_0000_01C4FE17.92BD7810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 2005 edition of MPLS World Congress will = stand in Paris in one month.

 

Please feel free to = visit:

http://www.upperside.fr/mplsworldcongress05/mplsworld2005int= ro.htm

 

Thanks.

 

Michel Gosse

michelg@upperside.fr

 

 

 

------=_NextPart_000_0000_01C4FE17.92BD7810-- --===============0068605544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0068605544==-- From mpls-bounces@ietf.org Wed Jan 19 12:56:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06022; Wed, 19 Jan 2005 12:56:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrKJJ-0000rv-Uh; Wed, 19 Jan 2005 13:12:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrJwK-00016m-Is; Wed, 19 Jan 2005 12:48:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrJsH-00089J-4X for mpls@megatron.ietf.org; Wed, 19 Jan 2005 12:44:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04852 for ; Wed, 19 Jan 2005 12:44:06 -0500 (EST) Received: from bgslc11.burtongroup.com ([63.99.125.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrK7l-0000RD-UR for mpls@ietf.org; Wed, 19 Jan 2005 13:00:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Jan 2005 10:43:26 -0700 Message-ID: <93C5326FCFEA7241BB6731D44D4147BC013F99F8@bgslc11.burtongroup.com> Thread-Topic: [mpls] MPLS World Congress 2005 Thread-Index: AcT+ENrD6BkEJtx0TDuVDJGKhJOkeAAPWOzg From: "Irwin Lazar" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [mpls] MPLScon 2005 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1298674061==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 This is a multi-part message in MIME format. --===============1298674061== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FE4E.61192D31" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FE4E.61192D31 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Registration is now open for MPLScon 2005, May 16-19 in NYC. =20 The complete program is available at = http://www.mplscon.com/attend/conf_at_a_glance.html =20 Thanks, Irwin=20 =20 =20 =20 ------_=_NextPart_001_01C4FE4E.61192D31 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Registration is now open for MPLScon 2005, = May 16-19 in=20 NYC.
 
The=20 complete program is available at http://www.m= plscon.com/attend/conf_at_a_glance.html
 
Thanks,
Irwin 

 

 

 

------_=_NextPart_001_01C4FE4E.61192D31-- --===============1298674061== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1298674061==-- From mpls-bounces@ietf.org Thu Jan 20 14:15:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26638; Thu, 20 Jan 2005 14:15:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cri2P-0007gO-MT; Thu, 20 Jan 2005 14:32:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crhd3-0006Af-1c; Thu, 20 Jan 2005 14:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrhPV-0002Kw-0i for mpls@megatron.ietf.org; Thu, 20 Jan 2005 13:52:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24142 for ; Thu, 20 Jan 2005 13:51:59 -0500 (EST) Received: from evita2.cs.fredonia.edu ([141.238.30.15] helo=evita3.cs.fredonia.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrhfD-0006me-AH for mpls@ietf.org; Thu, 20 Jan 2005 14:08:16 -0500 Received: from zubairi (taylor.cs.fredonia.edu [141.238.30.222]) by evita3.cs.fredonia.edu (8.10.2/8.10.2) with SMTP id j0KIpQ220034 for ; Thu, 20 Jan 2005 13:51:27 -0500 Message-ID: <001b01c4ff21$39462b00$de1eee8d@zubairi> From: "Junaid Ahmed Zubairi" To: Date: Thu, 20 Jan 2005 13:52:41 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C4FEF7.4F5DEFB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 1.2 (+) X-Scan-Signature: 5d99cba2a085c3987933aa34e30e85ab Subject: [mpls] collaborative network infrastructure X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junaid Ahmed Zubairi List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C4FEF7.4F5DEFB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Kindly contribute to the special session devoted to network technologies for collaborative work in CTS'05. CFP is enclosed as HTML file. The draft papers are due at the end of January. Junaid *********************************************************** Dr. Junaid Ahmed Zubairi Department of Computer Science SUNY at Fredonia, Fredonia, NY 14063, USA. Tel: (716)673-4694 WWW: http://www.cs.fredonia.edu/~zubairi Email: zubairi@fredonia.edu *********************************************************** ------=_NextPart_000_0018_01C4FEF7.4F5DEFB0 Content-Type: text/html; name="CTS 2005.htm" Content-Disposition: attachment; filename="CTS 2005.htm" Content-Transfer-Encoding: quoted-printable CTS = 2005

The 2005 International Symposium on = Collaborative=20 Technologies and Systems
(CTS 2005)

May 15-19, 2005
Adam's Mark Hotels & Resorts
Saint=20 Louis, Missouri, USA

In cooperation with the IEEE Systems, Man and Cybernetics=20 Society

=20

CALL FOR PAPERS =

Special=20 Session on Collaborative Networking = Infrastructure

Extended Submission Deadline: = January 31,=20 2005

A=20 Special Session on collaborative networking infrastructure is being = organized=20 under the 2005 Collaborative Technologies Symposium (CTS'05) to be held = in=20 St. = Louis, Missouri=20 May 15-19,=20 2005. =20

This special session is planned = to bring=20 together people from industry, government and academia who are working = to=20 innovate, develop and use networking infrastructure for the purpose of=20 collaborative work in various fields of knowledge.  Some of the recent examples of = collaborative work via networking include SPARC that researchers in = upper=20 atmospheric and space physics from around the world are able to = use.  SPARC provides the users with = a set of=20 online collaboration tools and workspaces that link together scientific=20 instruments, data, and models.  = Work=20 is in progress to design and test portable mobile collaborative networks = that=20 can be created to deal with emergencies.

This special session looks at the hardware and software = issues that=20 are involved in providing a reliable, robust and ubiquitous networking=20 infrastructure to build collaborative tools and services and the state = of the=20 art as well as experimental results and posters about ongoing work in = this=20 direction. 

Topics include, = but not=20 limited to:

* Protocols for Collaborative = Networking* High Speed Networking
* Design, = Implementation and=20 Management of Collaborative Websites and Services
* Tools = and=20 Techniques for Web based Collaborative Multimedia Communications
*=20 Software Development for Data Visualization from Distributed Data = Centers* Technical Issues in Building Community Networks
*=20 Wireless and Mobile Portable Collaborative Networking and Issues 

Paper=20 Submission

Papers reporting original and unpublished research results = on above=20 and any other related CTS topics are solicited.  Submission should include a = cover page=20 with authors' names, affiliations, addresses, fax and phone numbers, and = email=20 addresses.  Please = indicate clearly=20 the corresponding author and the name of the special session.  Include up to 6 keywords and = an abstract=20 of no more than 300 words.  = Please=20 submit an electronic copy of your full manuscript (not to exceed 15=20 double-spaced pages including figures, tables, and references or not = exceeding 6=20 pages in length in single-space, two columns format) for consideration, = to=20 session organizer at zubairi@cs.fredonia.edu by=20 January=20 31, 2005. 

Consistent with standard practice, each submitted = paper=20 will receive a minimum of three reviews. =20 Papers will be selected based on their originality, timeliness,=20 significance, relevance, and clarity of presentation.  Initial selection will be = based on full=20 papers.  Submission = implies the=20 willingness of at least one of the authors to register and present the = paper, if=20 accepted.  All accepted = papers in=20 the Symposium are expected to be presented and will be included in the=20 conference proceedings.  = It is our=20 intent to have the proceedings formally published in hard and soft = copies and be=20 available at the time of the conference. =20

Session=20 Organizer:

Dr. Junaid Ahmed=20 Zubairi
Department of=20 Computer=20 Science
State=20 University of=20 New=20 York at=20 Fredonia
Fredonia,=20 NY=20 14063, USA
Tel:=20 +1-716-673-4694
Fax: +1-508-256-8324
Email: zubairi@fredonia.edu
WWW: http://www.cs.fredonia.edu/~= zubairi

 

Extended Draft = Papers due=20 on:

Notification of = Acceptance:

Final Manuscripts and Preregistrations due on:

Important=20 Dates:

January 31, = 2005

February 14, = 2005

March 14, = 2005

 

 

 

 

If you have questions concerning session paper = submission or=20 session content, please contact the Special Session = organizer=20 at the address above. =20

If=20 you have questions concerning symposium paper submissions or the = symposium=20 program, please contact the symposium co-chairs: Bill McQuay at AFRL/IFSD, WPAFB (William.McQuay@wpafb.af.mil) or=20 Waleed Smari at the Dept. of Electrical and Computer Engineering,=20 University of=20 Dayton (Waleed.Smari@notes.udayton= .edu).  =

------=_NextPart_000_0018_01C4FEF7.4F5DEFB0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_0018_01C4FEF7.4F5DEFB0-- From mpls-bounces@ietf.org Thu Jan 20 16:51:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13685; Thu, 20 Jan 2005 16:51:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrkTH-0004iq-AW; Thu, 20 Jan 2005 17:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjZS-0004cz-Al; Thu, 20 Jan 2005 16:10:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjLe-0006IZ-4h; Thu, 20 Jan 2005 15:56:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05005; Thu, 20 Jan 2005 15:56:08 -0500 (EST) Message-Id: <200501202056.PAA05005@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 20 Jan 2005 15:56:08 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-bgp-mpls-restart-04.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Graceful Restart Mechanism for BGP with MPLS Author(s) : Y. Rekhter, R. Aggarwal Filename : draft-ietf-mpls-bgp-mpls-restart-04.txt Pages : 12 Date : 2005-1-20 A mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart is described in "Graceful Restart Mechanism for BGP" (see [1]). This document extends this mechanism to also minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart. The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such it works in conjunction with any of the address famililies that could be carried in BGP (e.g., IPv4, IPv6, etc...) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp-mpls-restart-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-mpls-bgp-mpls-restart-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-mpls-bgp-mpls-restart-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" Content-Type: text/plain Content-ID: <2005-1-20161838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bgp-mpls-restart-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bgp-mpls-restart-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-20161838.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Tue Jan 25 06:58:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26681; Tue, 25 Jan 2005 06:58:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtPbz-00064P-2T; Tue, 25 Jan 2005 07:15:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtPGv-0003jm-VM; Tue, 25 Jan 2005 06:54:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtPDK-0002HB-8k for mpls@megatron.ietf.org; Tue, 25 Jan 2005 06:50:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26217 for ; Tue, 25 Jan 2005 06:50:27 -0500 (EST) Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtPTy-0005nI-PI for mpls@ietf.org; Tue, 25 Jan 2005 07:07:46 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 25 Jan 2005 11:49:34 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8057D8B92@baker.datcon.co.uk> Thread-Topic: Question on TE-MIB. Thread-Index: AcUC0/eB/1VMzNlZTLmvytqcE9M1Bg== From: "Alan Davey" To: , , "Force 10 - Arun Viswanathan" , "Cisco - Thomas Nadeau" X-Spam-Score: 0.5 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Subject: [mpls] Question on TE-MIB. X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1119583409==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 This is a multi-part message in MIME format. --===============1119583409== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C502D3.F0946820" This is a multi-part message in MIME format. ------_=_NextPart_001_01C502D3.F0946820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have a query relating to RFC3812, the MPLS TE-MIB. How are the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects = intended to be used for RSVP-TE IPv6 tunnels? I note that - the description of the mplsTunnelIngressLSRId states that, for RSVP, = the value SHOULD be equal to the Tunnel Sender Address in the Sender = Template object and MAY be equal to the Extended Tunnel Id field in the = SESSION object. - for IPv6, RFC3209 defines the Tunnel Sender Address to be an IPv6 = address and the Extended Tunnel ID to be a 16-byte value. - the syntax of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId = objects is MplsExtendedTunnelId, that is Unsigned32(0..4294967295). Further, the mplsTunnelEgressLSRId needs to be routable in the TE = routing domain, and needs to be converted to an IPv6 address to use as = the IPv6 tunnel end point address in the RSVP SESSION object. I also note that the issue of configuring of IPv6 tunnels has been = raised in the mailing list before but I cannot find any resolution. - Arun Satyanarayana raised the point on the mailing list on 26 June = 2003 in response to the WG last call on the TE-MIB module but I cannot = find any response - Tom Nadeau suggested, on 2 June 2000, adding mplsTunnelSrcAddrType, = mplsTunnelSrcAddrIPv4 and mplsTunnelSrcAddrIPv6 as index fields to the = mplsTunnelTable. However, these fields were not added in the next = revision of the draft. Again, I cannot find any emails explaining why = the change was not implemented. Can anyone tell me - why Tom's suggestion was not implemented - how RSVP-TE IPv6 tunnels are configured using the current TE-MIB = definition? Thanks in advance Alan Davey ------------------------------------ Alan Davey Data Connection Ltd Tel: +44 20 8366 1177 =20 Fax: +44 20 8363 1039 Email: Alan.Davey@dataconnection.com =20 Web: http://www.dataconnection.com=20 ------_=_NextPart_001_01C502D3.F0946820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question on TE-MIB.

Hi

I have a query relating to = RFC3812, the MPLS TE-MIB.

How are the = mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects intended to be = used for RSVP-TE IPv6 tunnels?

I note that

-       the description of the = mplsTunnelIngressLSRId states that, for RSVP, the value SHOULD be equal = to the Tunnel Sender Address in the Sender Template object and MAY be = equal to the Extended Tunnel Id field in the SESSION object.

-       for IPv6, RFC3209 defines the = Tunnel Sender Address to be an IPv6 address and the Extended Tunnel ID = to be a 16-byte value.

-       the syntax of the = mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects is = MplsExtendedTunnelId, that is Unsigned32(0..4294967295).

Further, the = mplsTunnelEgressLSRId needs to be routable in the TE routing domain, and = needs to be converted to an IPv6 address to use as the IPv6 tunnel end = point address in the RSVP SESSION object.

I also note that the issue of = configuring of IPv6 tunnels has been raised in the mailing list before = but I cannot find any resolution.

-       Arun Satyanarayana raised the = point on the mailing list on 26 June 2003 in response to the WG last = call on the TE-MIB module but I cannot find any response

-       Tom Nadeau suggested, on 2 = June 2000, adding mplsTunnelSrcAddrType, mplsTunnelSrcAddrIPv4 and = mplsTunnelSrcAddrIPv6 as index fields to the mplsTunnelTable.  = However, these fields were not added in the next revision of the = draft.  Again, I cannot find any emails explaining why the change = was not implemented.

Can anyone tell me

-       why Tom's suggestion was not = implemented

-       how RSVP-TE IPv6 tunnels are = configured using the current TE-MIB definition?

Thanks in advance

Alan Davey

------------------------------------
Alan Davey
Data Connection Ltd
Tel:   +44 20 8366 = 1177      
Fax:   +44 20 8363 = 1039
Email: = Alan.Davey@dataconnection.com 
Web:   http://www.dataconnection.com =



------_=_NextPart_001_01C502D3.F0946820-- --===============1119583409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1119583409==-- From mpls-bounces@ietf.org Wed Jan 26 03:56:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02271; Wed, 26 Jan 2005 03:56:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtjFT-0006PI-BC; Wed, 26 Jan 2005 04:14:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtiwP-0000Ha-Rh; Wed, 26 Jan 2005 03:54:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtirG-0007fT-DK for mpls@megatron.ietf.org; Wed, 26 Jan 2005 03:49:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01870 for ; Wed, 26 Jan 2005 03:49:00 -0500 (EST) Received: from [80.86.78.228] (helo=tbdns.testbed.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctj87-0006CB-R5 for mpls@ietf.org; Wed, 26 Jan 2005 04:06:29 -0500 Received: from [172.16.2.191] (gw.imc.kth.se [193.10.152.67]) (authenticated bits=0) by tbdns.testbed.local (8.12.8/8.12.8) with ESMTP id j0Q8hipt003163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2005 09:43:47 +0100 Message-ID: <41F758F5.8090608@pi.se> Date: Wed, 26 Jan 2005 09:46:45 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-p2mp-sig-requirement-00.txt References: <41C828A3.4020108@pi.se> <82798D5E-6962-11D9-8236-000D93AD480A@cisco.com> In-Reply-To: <82798D5E-6962-11D9-8236-000D93AD480A@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: "Thomas D. Nadeau" , Monique Morrow X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit All, thanks - great work! seems like we have path forward with these documents! /Loa Thomas D. Nadeau wrote: > > MPLS WG, > > This note is an update on the p2mp requirement discussion > pertaining to its relationship to the MPLS OAM Requirements > and OAM Framework drafts that we had on the list a few weeks ago. > The various parties involved have agreed to the following to > resolve the situation as follows. > > The P2MP co-authors should craft-up new text for two new > documents: a P2MP-OAM-Requirements + P2MP-OAM-Framework. These > documents will reference the existing requirements and framework > documents. Dave and I agreed to co-author/edit these new drafts > with the p2mp co-authors to assist with them and to also > ensure their alignment with the existing documents. In the > meantime, this leaves Dave and I with just edits left on the > Framework document that Adrian Farrel sent out during last call, > which I believe we have accomplished, and then that draft is finished. > We should be re-spinning the updated draft in the next few days. > It also now appears that the MPLS OAM Requirements is therefore > completed, and is ready to ship to the IESG. > > > Regards, > > Tom/Dave/Adrian > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jan 26 04:09:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03016; Wed, 26 Jan 2005 04:09:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtjSR-0006jL-Ud; Wed, 26 Jan 2005 04:27:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctj9z-0003GZ-PE; Wed, 26 Jan 2005 04:08:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctj8e-0002x4-24 for mpls@megatron.ietf.org; Wed, 26 Jan 2005 04:07:00 -0500 Received: from tbdns.testbed.local ([80.86.78.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02907 for ; Wed, 26 Jan 2005 04:06:57 -0500 (EST) Received: from [172.16.2.191] (gw.imc.kth.se [193.10.152.67]) (authenticated bits=0) by tbdns.testbed.local (8.12.8/8.12.8) with ESMTP id j0Q91bpt003171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2005 10:01:46 +0100 Message-ID: <41F75D26.4090004@pi.se> Date: Wed, 26 Jan 2005 10:04:38 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org References: <41D28B4B.5090507@pi.se> In-Reply-To: <41D28B4B.5090507@pi.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [mpls] Re: working group last call on draft-ietf-mpls-oam-frmwk-01.txt - ended X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit All, this ends the wg last call on: draft-ietf-mpls-oam-frmwk-01.txt The authors and people who have had comments during the wg last call have agreed on a method of taking care of the comments (see the note sent to the working group mailing list by Tom, Dave and Adrian). /Loa Loa Andersson wrote: > All, > > this is to initiate a working group last call on > draft-ietf-mpls-oam-frmwk-01.txt. > > Please send your comments to the mailing list or the > working group chairs. > > The draft originates in merging of two separate MPLS > OAM approaches, therefore it would be good to have also > comments in support of the draft. > > To give time for comments during the holiday season the > working group last call ends on January 19th 11.59PM PST. > > /Loa and George > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Jan 27 11:21:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25254; Thu, 27 Jan 2005 11:21:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuCg8-0007lC-DV; Thu, 27 Jan 2005 11:39:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuCCl-0005Lg-Jg; Thu, 27 Jan 2005 11:09:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuC7H-0003Pe-DQ; Thu, 27 Jan 2005 11:03:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22288; Thu, 27 Jan 2005 11:03:28 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuCOQ-00076c-E4; Thu, 27 Jan 2005 11:21:15 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0RG3Sh5007922; Thu, 27 Jan 2005 17:03:28 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Jan 2005 17:03:36 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Jan 2005 17:03:28 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: IETF AVT WG , rohc@ietf.org, mpls@ietf.org Subject: RE: [AVT] [mpls] Comments ondraft-ash-avt-ecrtp-over-mpls-protoco l-01.txt Date: Thu, 27 Jan 2005 17:03:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-OriginalArrivalTime: 27 Jan 2005 16:03:36.0787 (UTC) FILETIME=[C25D9230:01C50489] X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae MPLS-HC folks, I've now looked into the MPLS-HC solution draft as well as the mail exchanges between Magnus and Jerry. The problems I see with the draft are very similar to those pointed out by Magnus. However, in an attempt to avoid getting too influenced by Magnus comments I will make my points purely based on my own reflections from the draft, and then from that refer to the discussion between Magnus and Jerry. Overall document structure and purpose -------------------------------------- On a high level, I think this MPLS-HC document should be about three things: 1) Negotiation of use, i.e. setup signalling 2) Encapsulation, i.e. how to send HC-packets over MPLS 3) Operation, i.e. considerations for the actual compression scheme(s), e.g. how to implement the scheme(s) to be able to handle reordering 1-2 are addressed in the draft, while 3) is not, although it is essential as an ordinary implementation of the existing HC schemes would e.g. not necessarily work well enough in case of reordering. I also strongly believe this MPLS-HC mapping solution should cover the currently available HC schemes, IP-HC, CRTP, eCRTP, and ROHC. I would not say we have to make it totally generic for *any* HC scheme, as I do not think we can cover up for future solutions. RFC 3544 (i.e. RFC 2509bis), which provides 1) and 2) for IP-HC, CRTP, and eCRTP, as well as RFC 3409, which do the same for ROHC, could be used as a basis for this work. The similarities in how to solve 1), 2), and 3) for existing HC schemes should be dominating rather than the differences. By the way, could we please avoid the terminology "control/data plane". Context multiplexing within an LSP, why signalling? --------------------------------------------------- The second main concern I have is the same one as Magnus expressed, about the multiplexing, which seems to require signalling that I can not see the point of. As I know nothing about the details of MPLS, my question from reading the draft was simply why there would have to be any signalling for picking a CID value, existing HC schemes assume the compressor does this without any signalling. The draft just talks about "...to signal the SCIDs...", without explaining the meaning of this. I do not exactly understand the underlying MPLS problem that Magnus talked about that might be the motivation for having to do CID tricks, but I agree with his concerns about this approach, which seems to require signalling for each new packet stream, and also contradicts the way existing HC schemes handle CID assignment. In any case, the draft should explain better the motivations behind solutions like this. For the negotiation & encapsulation I would strongly recommend using RFC 3544 and RFC 3409 as a basis, and clearly highlight potential deviations from the solutions used in these RFC's, that would help to get more constructive involvement from the HC folks in this work. On the CID handling question, I also noticed the text about how to free up CID. I am not sure what the purpose of that is, but this also represents a deviation from how existing HC schemes are defined. Looking at packets not belonging to the flow (e.g. SIP messages) also seems like a not very desirable approach, in my mind. What creates a feedback channel? -------------------------------- Is the LSP per definition bidirectional, or are LSP's always set up as pairs, one in each direction? If we talk about multiple LSP's, there must be an exact 1-1 mapping, or there must be a way to create that binding between them. eCRTP packet type identification -------------------------------- Inconsistency, first paragraph of 2.2 talks about a 4-bit packet type, while the second paragraph says a one-octet PT ID is used. In the figure, I wonder what the first octet of zeros is, not really explained. "Defined by PPP Data Link Layer Protocol" means? HC object formats ----------------- This section was very confusing to me. First, the text talks about intermediates that do not understand HC and could drop the object. My question is, should not the solution be transparent to intermediates, i.e. compression should be possible between ingress and egress without any knowledge in the notes in between? Why should it at all concern intermediates? Further, I have a hard time commenting on the content as the fields in these objects are not described. There should be explanations after the figures. Operations ---------- For the operations part, the draft currently says nothing, while we know there are at least concerns related to reordering. The ROHC over reordering draft can be a useful source for information in that area, as well as the eCRTP evaluation I made the list aware of earlier today. http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-01.txt http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf Summary ------- I thus suggest that the overall purpose of this document (to be adopted as a WG document) should be to create a HC mapping for MPLS, covering the HC schemes we currently have, similar to RFC 3544 and 3409. It should address negotiation (setup), encapsulation, and potential issues with operation of each HC scheme. I'll do my best to support this work from an HC perspective. Cheers, /L-E > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > Sent: den 22 december 2004 22:30 > To: IETF AVT WG; rohc@ietf.org; mpls@ietf.org > Subject: [AVT] [mpls] Comments > ondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt > > > Hi, > > Sorry for the crossposting, however this is something that I > think needs > to be generally discussed between all 3 WGs. To me it looks like the > proposed solution for VoIP header compression across an MPLS network > contains a problematic demultiplexing mechanism. I don't think people > has realized the issues with the proposed mechanism due to lack of > communication between the header compression and MPLS folks. > If it is my > lack of knowledge please educate me, and the others. I would request > that people providing input in this discussion is overly > explaining as > education seems necessary. > > The current draft is available at: > http://www.watersprings.org/pub/id/draft-ash-avt-ecrtp-over-mp > ls-protocol-01.txt > it should also be available in the IETF repository if it > hasn't expired. > > The header compression mechanisms such as CRTP and ROHC to my > understanding assumes that they have a lower link layer that carries > their compressed messages between compressor and > decompressor. This is > due to that they are intended to be used with only a single > link between > the compressor and decompressor. In the case of CRTP, it also assumes > that the link-layer can also provide the with identification of the > packet types, while ROHC makes this identification internally. > > The MPLS network uses one or more labels in the transport between > ingress and egress from the MPLS network. Due to the possible > relabeling > in the middle of the network, it can't be generally assumed > that packets > arriving with the same label comes from the same ingress point. This > makes the label not sufficient to identify the ingress for > the egress, > thus not making labels equal to a link. > > The proposed solution has thought of the above MPLS problem > and proposes > that one uses the setup signalling to allow the decompressor point to > select which parts of its context identifier (SCID) space > that belongs > to different ingress points that arrives over the same label. > However my > understanding is that this definitely not without problems for the > header compression mechanisms. I would like the header > compression guy > to clarify what problems that would arise from such a solution. One > thing I definitely can see would be an issue, the proposed > change would > prevent MPLS HC to use any standard implementation of the HC > mechanism used. > > I would also like to point out that the Header Compression mechanism > needs a return path from the decompressor mechanism. However > the draft > does not seem to discuss this issue at all. Or is a MPLS label path > automatically reversible? > > It would be desirable if the MPLS people could consider if > there exist > other ways of providing for the standard assumption on link > layers that > header compression has? For these assumption please see > chapter 2 of RFC > 2508, section 4.1 of RFC 3095, and RFC 3409. > > For example, what would be the effects of requiring unique labels > between ingress and egress and for the reverse path? > > What effects would it have to put the multiplexing point in the layer > two extension? > > I would also like to see the draft be more header compression > agnostic > as has been agreed on in the requirements phase. There is no problem > with using ECRTP as an example how one realize the solution, > however the > necessary hooks and signalling must be in place for any header > compression mechanism. > > So lets get the discussion going and hope that something good results. > > Cheers > > Magnus Westerlund > AVT Chair _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Jan 27 19:15:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14363; Thu, 27 Jan 2005 19:15:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuK4W-0004DY-GY; Thu, 27 Jan 2005 19:33:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuJlZ-00033k-5l; Thu, 27 Jan 2005 19:13:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuJeJ-00013Q-5F; Thu, 27 Jan 2005 19:06:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13339; Thu, 27 Jan 2005 19:06:02 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuJvV-0003zf-Jz; Thu, 27 Jan 2005 19:23:54 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j0S05rh5022413; Fri, 28 Jan 2005 01:05:57 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Jan 2005 01:06:01 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 28 Jan 2005 01:05:53 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Colin Perkins'" Subject: RE: [AVT] [mpls] Comments ondraft-ash-avt-ecrtp-over-mpls-protoco l-01.txt Date: Fri, 28 Jan 2005 01:05:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 28 Jan 2005 00:06:01.0762 (UTC) FILETIME=[26EA4020:01C504CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: mpls@ietf.org, rohc@ietf.org, IETF AVT WG X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Colin, Actually, these comments are based on the -02 version. /L-E > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: den 27 januari 2005 19:29 > To: Lars-Erik Jonsson (LU/EAB) > Cc: mpls@ietf.org; IETF AVT WG; rohc@ietf.org > Subject: Re: [AVT] [mpls] Comments > ondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt > > > Lars-Erik, > > I notice that the -02 draft is available, but that these > comments are > based on the -01 version. Do the changes in the -02 version address > your concerns? > > Colin > > > > On 27 Jan 2005, at 16:03, Lars-Erik Jonsson (LU/EAB) wrote: > > MPLS-HC folks, > > > > I've now looked into the MPLS-HC solution draft as well as the > > mail exchanges between Magnus and Jerry. The problems I see with > > the draft are very similar to those pointed out by Magnus. However, > > in an attempt to avoid getting too influenced by Magnus comments > > I will make my points purely based on my own reflections from the > > draft, and then from that refer to the discussion between Magnus > > and Jerry. > > > > Overall document structure and purpose > > -------------------------------------- > > On a high level, I think this MPLS-HC document should be about > > three things: > > 1) Negotiation of use, i.e. setup signalling > > 2) Encapsulation, i.e. how to send HC-packets over MPLS > > 3) Operation, i.e. considerations for the actual > compression scheme(s), > > e.g. how to implement the scheme(s) to be able to handle > reordering > > > > 1-2 are addressed in the draft, while 3) is not, although it is > > essential as an ordinary implementation of the existing HC schemes > > would e.g. not necessarily work well enough in case of reordering. > > > > I also strongly believe this MPLS-HC mapping solution should cover > > the currently available HC schemes, IP-HC, CRTP, eCRTP, and ROHC. > > I would not say we have to make it totally generic for *any* HC > > scheme, as I do not think we can cover up for future solutions. > > RFC 3544 (i.e. RFC 2509bis), which provides 1) and 2) for IP-HC, > > CRTP, and eCRTP, as well as RFC 3409, which do the same for ROHC, > > could be used as a basis for this work. The similarities in how to > > solve 1), 2), and 3) for existing HC schemes should be dominating > > rather than the differences. > > > > By the way, could we please avoid the terminology > "control/data plane". > > > > > > Context multiplexing within an LSP, why signalling? > > --------------------------------------------------- > > The second main concern I have is the same one as Magnus expressed, > > about the multiplexing, which seems to require signalling that I > > can not see the point of. As I know nothing about the details > > of MPLS, my question from reading the draft was simply why there > > would have to be any signalling for picking a CID value, existing > > HC schemes assume the compressor does this without any signalling. > > The draft just talks about "...to signal the SCIDs...", without > > explaining the meaning of this. > > > > I do not exactly understand the underlying MPLS problem that Magnus > > talked about that might be the motivation for having to do > CID tricks, > > but I agree with his concerns about this approach, which seems to > > require signalling for each new packet stream, and also contradicts > > the way existing HC schemes handle CID assignment. In any case, the > > draft should explain better the motivations behind solutions like > > this. > > > > For the negotiation & encapsulation I would strongly recommend using > > RFC 3544 and RFC 3409 as a basis, and clearly highlight potential > > deviations from the solutions used in these RFC's, that would help > > to get more constructive involvement from the HC folks in this work. > > > > On the CID handling question, I also noticed the text about how to > > free up CID. I am not sure what the purpose of that is, but > this also > > represents a deviation from how existing HC schemes are defined. > > Looking at packets not belonging to the flow (e.g. SIP messages) > > also seems like a not very desirable approach, in my mind. > > > > > > What creates a feedback channel? > > -------------------------------- > > Is the LSP per definition bidirectional, or are LSP's always set up > > as pairs, one in each direction? If we talk about multiple LSP's, > > there must be an exact 1-1 mapping, or there must be a way to create > > that binding between them. > > > > > > eCRTP packet type identification > > -------------------------------- > > Inconsistency, first paragraph of 2.2 talks about a 4-bit > packet type, > > while the second paragraph says a one-octet PT ID is used. In the > > figure, I wonder what the first octet of zeros is, not really > > explained. "Defined by PPP Data Link Layer Protocol" means? > > > > > > HC object formats > > ----------------- > > This section was very confusing to me. First, the text talks about > > intermediates that do not understand HC and could drop the object. > > My question is, should not the solution be transparent to > > intermediates, > > i.e. compression should be possible between ingress and > egress without > > any knowledge in the notes in between? Why should it at all concern > > intermediates? > > > > Further, I have a hard time commenting on the content as the fields > > in these objects are not described. There should be explanations > > after the figures. > > > > > > Operations > > ---------- > > For the operations part, the draft currently says nothing, while we > > know there are at least concerns related to reordering. The > ROHC over > > reordering draft can be a useful source for information in > that area, > > as well as the eCRTP evaluation I made the list aware of > earlier today. > > http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering > > -01.txt > > http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf > > > > > > Summary > > ------- > > I thus suggest that the overall purpose of this document > (to be adopted > > as a WG document) should be to create a HC mapping for > MPLS, covering > > the HC schemes we currently have, similar to RFC 3544 and 3409. It > > should address negotiation (setup), encapsulation, and > potential issues > > with operation of each HC scheme. > > > > > > I'll do my best to support this work from an HC perspective. > > > > Cheers, > > /L-E > > > > > >> -----Original Message----- > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] > >> Sent: den 22 december 2004 22:30 > >> To: IETF AVT WG; rohc@ietf.org; mpls@ietf.org > >> Subject: [AVT] [mpls] Comments > >> ondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt > >> > >> > >> Hi, > >> > >> Sorry for the crossposting, however this is something that I > >> think needs > >> to be generally discussed between all 3 WGs. To me it > looks like the > >> proposed solution for VoIP header compression across an > MPLS network > >> contains a problematic demultiplexing mechanism. I don't > think people > >> has realized the issues with the proposed mechanism due to lack of > >> communication between the header compression and MPLS folks. > >> If it is my > >> lack of knowledge please educate me, and the others. I > would request > >> that people providing input in this discussion is overly > >> explaining as > >> education seems necessary. > >> > >> The current draft is available at: > >> http://www.watersprings.org/pub/id/draft-ash-avt-ecrtp-over-mp > >> ls-protocol-01.txt > >> it should also be available in the IETF repository if it > >> hasn't expired. > >> > >> The header compression mechanisms such as CRTP and ROHC to my > >> understanding assumes that they have a lower link layer > that carries > >> their compressed messages between compressor and > >> decompressor. This is > >> due to that they are intended to be used with only a single > >> link between > >> the compressor and decompressor. In the case of CRTP, it > also assumes > >> that the link-layer can also provide the with identification of the > >> packet types, while ROHC makes this identification internally. > >> > >> The MPLS network uses one or more labels in the transport between > >> ingress and egress from the MPLS network. Due to the possible > >> relabeling > >> in the middle of the network, it can't be generally assumed > >> that packets > >> arriving with the same label comes from the same ingress > point. This > >> makes the label not sufficient to identify the ingress for > >> the egress, > >> thus not making labels equal to a link. > >> > >> The proposed solution has thought of the above MPLS problem > >> and proposes > >> that one uses the setup signalling to allow the > decompressor point to > >> select which parts of its context identifier (SCID) space > >> that belongs > >> to different ingress points that arrives over the same label. > >> However my > >> understanding is that this definitely not without problems for the > >> header compression mechanisms. I would like the header > >> compression guy > >> to clarify what problems that would arise from such a solution. One > >> thing I definitely can see would be an issue, the proposed > >> change would > >> prevent MPLS HC to use any standard implementation of the HC > >> mechanism used. > >> > >> I would also like to point out that the Header Compression > mechanism > >> needs a return path from the decompressor mechanism. However > >> the draft > >> does not seem to discuss this issue at all. Or is a MPLS label path > >> automatically reversible? > >> > >> It would be desirable if the MPLS people could consider if > >> there exist > >> other ways of providing for the standard assumption on link > >> layers that > >> header compression has? For these assumption please see > >> chapter 2 of RFC > >> 2508, section 4.1 of RFC 3095, and RFC 3409. > >> > >> For example, what would be the effects of requiring unique labels > >> between ingress and egress and for the reverse path? > >> > >> What effects would it have to put the multiplexing point > in the layer > >> two extension? > >> > >> I would also like to see the draft be more header compression > >> agnostic > >> as has been agreed on in the requirements phase. There is > no problem > >> with using ECRTP as an example how one realize the solution, > >> however the > >> necessary hooks and signalling must be in place for any header > >> compression mechanism. > >> > >> So lets get the discussion going and hope that something > good results. > >> > >> Cheers > >> > >> Magnus Westerlund > >> AVT Chair > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Jan 28 07:53:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25560; Fri, 28 Jan 2005 07:53:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuVuO-0003wL-NM; Fri, 28 Jan 2005 08:11:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuVVO-0008Nc-OF; Fri, 28 Jan 2005 07:45:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuVOt-0007YS-9b for mpls@megatron.ietf.org; Fri, 28 Jan 2005 07:38:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24010 for ; Fri, 28 Jan 2005 07:38:58 -0500 (EST) Received: from [132.151.6.18] (helo=ticket.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuVgD-0003RU-QG for mpls@ietf.org; Fri, 28 Jan 2005 07:56:53 -0500 Received: from apache by ticket.ietf.org with local (Exim 4.33) id 1CuVXT-00063S-3U for mpls@ietf.org; Fri, 28 Jan 2005 07:47:51 -0500 From: "Webmaster via RT" In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #34702 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: mpls@ietf.org To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Fri, 28 Jan 2005 07:47:51 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [mpls] [Inquiry #34702] AutoReply: Is delivered mail X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: webmaster@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Greetings, This message has been automatically generated in response to the creation of a ticket regarding: "Is delivered mail", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [Inquiry #34702] in the queue: Webmaster. Please include the string: [Inquiry #34702] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, webmaster@ietf.org ------------------------------------------------------------------------- This transaction appears to have no content _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Jan 28 08:06:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26695; Fri, 28 Jan 2005 08:06:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuW6x-0004De-22; Fri, 28 Jan 2005 08:24:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuVhn-0002Fk-Ks; Fri, 28 Jan 2005 07:58:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuVgr-0001wd-CE for mpls@megatron.ietf.org; Fri, 28 Jan 2005 07:57:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25845 for ; Fri, 28 Jan 2005 07:57:32 -0500 (EST) Received: from [132.151.6.18] (helo=ticket.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuVyC-000416-9f for mpls@ietf.org; Fri, 28 Jan 2005 08:15:28 -0500 Received: from apache by ticket.ietf.org with local (Exim 4.33) id 1CuVpR-0006Ej-MN for mpls@ietf.org; Fri, 28 Jan 2005 08:06:25 -0500 Subject: RE: [mpls] [Inquiry #34702] AutoReply: Is delivered mail From: "neil.2.harrison@bt.com via RT" In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: Inquiry RT-Ticket: Inquiry #34702 Managed-by: RT 3.2.1 (http://www.bestpractical.com/rt/) RT-Originator: neil.2.harrison@bt.com To: mpls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Fri, 28 Jan 2005 08:06:25 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: webmaster@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 I have no idea what this is about. regards Neil Harrison, BT/GS/CTO > -----Original Message----- > From: mpls-bounces@lists.ietf.org > [mailto:mpls-bounces@lists.ietf.org] On Behalf Of Webmaster via RT > Sent: 28 January 2005 12:48 > To: mpls@ietf.org > Subject: [mpls] [Inquiry #34702] AutoReply: Is delivered mail > > > > Greetings, > > This message has been automatically generated in response to > the creation of a ticket regarding: > "Is delivered mail", > a summary of which appears below. > > There is no need to reply to this message right now. Your > ticket has been assigned an ID of [Inquiry #34702] in the > queue: Webmaster. > > Please include the string: > > [Inquiry #34702] > > in the subject line of all future correspondence about this > issue. To do so, > you may reply to this message. > > Thank you, > webmaster@ietf.org > > -------------------------------------------------------------- > ----------- > This transaction appears to have no content > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Jan 28 16:37:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19780; Fri, 28 Jan 2005 16:37:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cue5W-0001qL-I7; Fri, 28 Jan 2005 16:55:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CudH2-0003d4-Jz; Fri, 28 Jan 2005 16:03:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CudBT-00005I-2S; Fri, 28 Jan 2005 15:57:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12615; Fri, 28 Jan 2005 15:57:37 -0500 (EST) Message-Id: <200501282057.PAA12615@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 28 Jan 2005 15:57:36 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-nodeid-subobject-04.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definition of an RRO node-id subobject Author(s) : J. Vasseur, et al. Filename : draft-ietf-mpls-nodeid-subobject-04.txt Pages : 9 Date : 2005-1-28 In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering LSP on a downstream LSR. However, existing protocol mechanisms are not sufficient to find an MP address in multi-areas or multi-domain routing networks. Hence, the current MPLS Fast Reroute mechanism cannot be used to protect inter-area or inter-AS TE LSPs from a failure of an ABR (Area Border Router) or ASBR (Autonomous System Border Router) respectively. Such functionality has been listed as a clear requirement in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS]. This document specifies the use of existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to define the node-id subobject in order to solve this issue. Note that the MPLS Fast reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-nodeid-subobject-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-mpls-nodeid-subobject-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-mpls-nodeid-subobject-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" Content-Type: text/plain Content-ID: <2005-1-28152638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-nodeid-subobject-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-nodeid-subobject-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-28152638.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Sun Jan 30 12:49:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19408; Sun, 30 Jan 2005 12:49:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvJUU-00067U-SN; Sun, 30 Jan 2005 13:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvJ9l-0005Tc-6i; Sun, 30 Jan 2005 12:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvJ7c-00052l-E7 for mpls@megatron.ietf.org; Sun, 30 Jan 2005 12:44:28 -0500 Received: from hotmail.com (bay102-dav14.bay102.hotmail.com [64.4.61.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19165 for ; Sun, 30 Jan 2005 12:44:24 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 Jan 2005 09:43:00 -0800 Message-ID: Received: from 24.184.93.116 by BAY102-DAV14.phx.gbl with DAV; Sun, 30 Jan 2005 17:42:04 +0000 X-Originating-IP: [24.184.93.116] X-Originating-Email: [chadwickallison@hotmail.com] X-Sender: chadwickallison@hotmail.com From: "Chadwick Allison" To: Date: Sun, 30 Jan 2005 12:46:44 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-OriginalArrivalTime: 30 Jan 2005 17:43:00.0440 (UTC) FILETIME=[24380D80:01C506F3] Subject: [mpls] Becoming member X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0311399510==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 This is a multi-part message in MIME format. --===============0311399510== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C506C9.C0BF1AB0" This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C506C9.C0BF1AB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Becoming member ------=_NextPart_000_003C_01C506C9.C0BF1AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Becoming member

------=_NextPart_000_003C_01C506C9.C0BF1AB0-- --===============0311399510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0311399510==-- From mpls-bounces@ietf.org Sun Jan 30 23:00:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28926; Sun, 30 Jan 2005 23:00:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvT1f-0008Lm-LC; Sun, 30 Jan 2005 23:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvSi4-0003EP-1d; Sun, 30 Jan 2005 22:58:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEP8-0004i8-65; Thu, 27 Jan 2005 13:30:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09319; Thu, 27 Jan 2005 13:30:02 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEgI-0002mC-EA; Thu, 27 Jan 2005 13:47:51 -0500 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:57346) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CuEOX-0005Z8-9K; Thu, 27 Jan 2005 18:29:29 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [AVT] [mpls] Comments ondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt Date: Thu, 27 Jan 2005 18:29:26 +0000 To: "Lars-Erik Jonsson (LU/EAB)" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 30 Jan 2005 22:58:43 -0500 Cc: mpls@ietf.org, rohc@ietf.org, IETF AVT WG X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Content-Transfer-Encoding: 7bit Lars-Erik, I notice that the -02 draft is available, but that these comments are based on the -01 version. Do the changes in the -02 version address your concerns? Colin On 27 Jan 2005, at 16:03, Lars-Erik Jonsson (LU/EAB) wrote: > MPLS-HC folks, > > I've now looked into the MPLS-HC solution draft as well as the > mail exchanges between Magnus and Jerry. The problems I see with > the draft are very similar to those pointed out by Magnus. However, > in an attempt to avoid getting too influenced by Magnus comments > I will make my points purely based on my own reflections from the > draft, and then from that refer to the discussion between Magnus > and Jerry. > > Overall document structure and purpose > -------------------------------------- > On a high level, I think this MPLS-HC document should be about > three things: > 1) Negotiation of use, i.e. setup signalling > 2) Encapsulation, i.e. how to send HC-packets over MPLS > 3) Operation, i.e. considerations for the actual compression scheme(s), > e.g. how to implement the scheme(s) to be able to handle reordering > > 1-2 are addressed in the draft, while 3) is not, although it is > essential as an ordinary implementation of the existing HC schemes > would e.g. not necessarily work well enough in case of reordering. > > I also strongly believe this MPLS-HC mapping solution should cover > the currently available HC schemes, IP-HC, CRTP, eCRTP, and ROHC. > I would not say we have to make it totally generic for *any* HC > scheme, as I do not think we can cover up for future solutions. > RFC 3544 (i.e. RFC 2509bis), which provides 1) and 2) for IP-HC, > CRTP, and eCRTP, as well as RFC 3409, which do the same for ROHC, > could be used as a basis for this work. The similarities in how to > solve 1), 2), and 3) for existing HC schemes should be dominating > rather than the differences. > > By the way, could we please avoid the terminology "control/data plane". > > > Context multiplexing within an LSP, why signalling? > --------------------------------------------------- > The second main concern I have is the same one as Magnus expressed, > about the multiplexing, which seems to require signalling that I > can not see the point of. As I know nothing about the details > of MPLS, my question from reading the draft was simply why there > would have to be any signalling for picking a CID value, existing > HC schemes assume the compressor does this without any signalling. > The draft just talks about "...to signal the SCIDs...", without > explaining the meaning of this. > > I do not exactly understand the underlying MPLS problem that Magnus > talked about that might be the motivation for having to do CID tricks, > but I agree with his concerns about this approach, which seems to > require signalling for each new packet stream, and also contradicts > the way existing HC schemes handle CID assignment. In any case, the > draft should explain better the motivations behind solutions like > this. > > For the negotiation & encapsulation I would strongly recommend using > RFC 3544 and RFC 3409 as a basis, and clearly highlight potential > deviations from the solutions used in these RFC's, that would help > to get more constructive involvement from the HC folks in this work. > > On the CID handling question, I also noticed the text about how to > free up CID. I am not sure what the purpose of that is, but this also > represents a deviation from how existing HC schemes are defined. > Looking at packets not belonging to the flow (e.g. SIP messages) > also seems like a not very desirable approach, in my mind. > > > What creates a feedback channel? > -------------------------------- > Is the LSP per definition bidirectional, or are LSP's always set up > as pairs, one in each direction? If we talk about multiple LSP's, > there must be an exact 1-1 mapping, or there must be a way to create > that binding between them. > > > eCRTP packet type identification > -------------------------------- > Inconsistency, first paragraph of 2.2 talks about a 4-bit packet type, > while the second paragraph says a one-octet PT ID is used. In the > figure, I wonder what the first octet of zeros is, not really > explained. "Defined by PPP Data Link Layer Protocol" means? > > > HC object formats > ----------------- > This section was very confusing to me. First, the text talks about > intermediates that do not understand HC and could drop the object. > My question is, should not the solution be transparent to > intermediates, > i.e. compression should be possible between ingress and egress without > any knowledge in the notes in between? Why should it at all concern > intermediates? > > Further, I have a hard time commenting on the content as the fields > in these objects are not described. There should be explanations > after the figures. > > > Operations > ---------- > For the operations part, the draft currently says nothing, while we > know there are at least concerns related to reordering. The ROHC over > reordering draft can be a useful source for information in that area, > as well as the eCRTP evaluation I made the list aware of earlier today. > http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering > -01.txt > http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf > > > Summary > ------- > I thus suggest that the overall purpose of this document (to be adopted > as a WG document) should be to create a HC mapping for MPLS, covering > the HC schemes we currently have, similar to RFC 3544 and 3409. It > should address negotiation (setup), encapsulation, and potential issues > with operation of each HC scheme. > > > I'll do my best to support this work from an HC perspective. > > Cheers, > /L-E > > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] >> Sent: den 22 december 2004 22:30 >> To: IETF AVT WG; rohc@ietf.org; mpls@ietf.org >> Subject: [AVT] [mpls] Comments >> ondraft-ash-avt-ecrtp-over-mpls-protocol-01.txt >> >> >> Hi, >> >> Sorry for the crossposting, however this is something that I >> think needs >> to be generally discussed between all 3 WGs. To me it looks like the >> proposed solution for VoIP header compression across an MPLS network >> contains a problematic demultiplexing mechanism. I don't think people >> has realized the issues with the proposed mechanism due to lack of >> communication between the header compression and MPLS folks. >> If it is my >> lack of knowledge please educate me, and the others. I would request >> that people providing input in this discussion is overly >> explaining as >> education seems necessary. >> >> The current draft is available at: >> http://www.watersprings.org/pub/id/draft-ash-avt-ecrtp-over-mp >> ls-protocol-01.txt >> it should also be available in the IETF repository if it >> hasn't expired. >> >> The header compression mechanisms such as CRTP and ROHC to my >> understanding assumes that they have a lower link layer that carries >> their compressed messages between compressor and >> decompressor. This is >> due to that they are intended to be used with only a single >> link between >> the compressor and decompressor. In the case of CRTP, it also assumes >> that the link-layer can also provide the with identification of the >> packet types, while ROHC makes this identification internally. >> >> The MPLS network uses one or more labels in the transport between >> ingress and egress from the MPLS network. Due to the possible >> relabeling >> in the middle of the network, it can't be generally assumed >> that packets >> arriving with the same label comes from the same ingress point. This >> makes the label not sufficient to identify the ingress for >> the egress, >> thus not making labels equal to a link. >> >> The proposed solution has thought of the above MPLS problem >> and proposes >> that one uses the setup signalling to allow the decompressor point to >> select which parts of its context identifier (SCID) space >> that belongs >> to different ingress points that arrives over the same label. >> However my >> understanding is that this definitely not without problems for the >> header compression mechanisms. I would like the header >> compression guy >> to clarify what problems that would arise from such a solution. One >> thing I definitely can see would be an issue, the proposed >> change would >> prevent MPLS HC to use any standard implementation of the HC >> mechanism used. >> >> I would also like to point out that the Header Compression mechanism >> needs a return path from the decompressor mechanism. However >> the draft >> does not seem to discuss this issue at all. Or is a MPLS label path >> automatically reversible? >> >> It would be desirable if the MPLS people could consider if >> there exist >> other ways of providing for the standard assumption on link >> layers that >> header compression has? For these assumption please see >> chapter 2 of RFC >> 2508, section 4.1 of RFC 3095, and RFC 3409. >> >> For example, what would be the effects of requiring unique labels >> between ingress and egress and for the reverse path? >> >> What effects would it have to put the multiplexing point in the layer >> two extension? >> >> I would also like to see the draft be more header compression >> agnostic >> as has been agreed on in the requirements phase. There is no problem >> with using ECRTP as an example how one realize the solution, >> however the >> necessary hooks and signalling must be in place for any header >> compression mechanism. >> >> So lets get the discussion going and hope that something good results. >> >> Cheers >> >> Magnus Westerlund >> AVT Chair > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jan 31 17:11:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08508; Mon, 31 Jan 2005 17:11:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvk3i-0003Kb-IA; Mon, 31 Jan 2005 17:30:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvj96-0004IO-9s; Mon, 31 Jan 2005 16:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CviR6-00043x-23; Mon, 31 Jan 2005 15:46:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18954; Mon, 31 Jan 2005 15:46:14 -0500 (EST) Message-Id: <200501312046.PAA18954@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 31 Jan 2005 15:46:14 -0500 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP-TE for Point to Multipoint TE LSPs Author(s) : R. Aggarwal, et al. Filename : draft-ietf-mpls-rsvp-te-p2mp-01.txt Pages : 45 Date : 2005-1-31 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-te-p2mp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-31155418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-te-p2mp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-31155418.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Mon Jan 31 21:13:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07608; Mon, 31 Jan 2005 21:13:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvnpN-00027m-8z; Mon, 31 Jan 2005 21:31:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvnV5-0001z6-0m; Mon, 31 Jan 2005 21:10:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvliv-0006SB-0Q; Mon, 31 Jan 2005 19:16:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27415; Mon, 31 Jan 2005 19:16:47 -0500 (EST) Received: from out010pub.verizon.net ([206.46.170.133] helo=out010.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvm0l-00085O-K5; Mon, 31 Jan 2005 19:35:29 -0500 Received: from cow ([4.12.170.137]) by out010.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050201001352.YLW25119.out010.verizon.net@cow>; Mon, 31 Jan 2005 18:13:52 -0600 From: "Dawn Akin" To: Date: Mon, 31 Jan 2005 18:12:45 -0600 Message-ID: <000201c507f2$e7388c10$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authentication-Info: Submitted using SMTP AUTH at out010.verizon.net from [4.12.170.137] at Mon, 31 Jan 2005 18:13:51 -0600 X-Spam-Score: 0.4 (/) X-Scan-Signature: f90770ef080cd30a3a9496366ec9eae7 X-Mailman-Approved-At: Mon, 31 Jan 2005 21:10:41 -0500 Subject: [mpls] Call for Papers - Broadnets 2005 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0355684540==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 9b69b1193ec31d87dbcfc64057278e7d This is a multi-part message in MIME format. --===============0355684540== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C507C0.9C9E1C10" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C507C0.9C9E1C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------------------- CALL FOR PAPERS =20 Second Annual International Conference on Broadband Networks (BroadNets 2005) Broadband Applications and Services Symposium October 3 - 7, 2005 Boston, Massachusetts, USA http://www.broadnets.org =20 Submission Deadline Extended: February 25, 2005 ----------------------------------------------------------------------- =20 SCOPE ----- =20 BroadNets 2005 is an international conference focusing on broadband networking and covers the entire gamut of next generation networks with high bandwidth available for both wireless and wireline networks. = The conference will consist of the following three symposia: =20 ** Broadband Wireless Networking Symposium: covers mobility, routing for multihop, multimedia QoS and traffic management, cross-layer optimization, MAC and emerging physical layer technologies = (UWB, MIMO) for high-speed wireless networking. =20 ** Broadband Optical Networking Symposium: covers WDM technologies, = Ethernet and MPLS integration into the optical layer,=20 Next-Generation SONET/SDH, as well as SAN extensions over = DWDM/SONET/SDH. =20 ** Broadband Applications/Services Symposium: covers middleware and = service architectures for broadband applications, pervasive computing and ubiquitous communications, and universal broadband access = for information services. =20 BroadNets 2005 will thus offer a unique forum for researchers from = academia, government and industry to share ideas and disseminate new results in these important areas. =20 This Call for Papers describes the details for the Broadband Applications/Services Symposium ONLY. (Refer to the www.broadnets.org website for the details of Broadband Optical Networking Symposium and Broadband Wireless Networking Symposium.) This Symposium invites academic and industry researchers to present issues and opportunities = for tomorrow's IT infrastructure as driven by broadband applications and services. We invite the research community to present the most recent advances in this field, to discuss exciting research topics and = development of test beds and applications, and to share their research and = development experiences. We hope to organize one or more panel sessions of industry leaders to offer them an opportunity to outline their vision = for future broadband networks, as well as to offer academic and national laboratory researchers an opportunity to ask questions/provide feedback = to these industry leaders. Our goal is to raise the awareness of new industry developments in the academic community, and, at the same time, = to establish a sound link between applied and theoretical research. =20 Topics of interest for which we are soliciting full-length papers = include, but are not limited to, the following: =20 . Applications for security and privacy . Applications and services for grid networks . Grid middleware . Collaborative remote visualization and virtual reality . Data mining and high-speed file transfer applications . Collaborative computational steering . Multimedia applications for wireless networks . Multimedia applications for optical networks . Video-conferencing and video-telephony . Video-on-demand, TV-on-demand . Ultra Wideband (UWB) applications . Applications in 3G/4G networks . Applications and services in integrated 3GPP-WLAN networks . Applications for wireless indoor & home networks . Applications in large-scale sensor networks . P2P applications . Applications for overlay networks . Multicast applications . Broadband access applications . Pricing models for new services . Standards, licensing and regulation . Economics and business cases . Applications for e-government, e-health and e-science . Storage applications =20 =20 IMPORTANT DATES --------------- =20 Submission Deadline: February 25, 2005 Acceptance Notification: May 15, 2005 Final Manuscript Due: June 1, 2005 =20 PAPER SUBMISSION INSTRUCTIONS ----------------------------- =20 Authors are invited to submit full papers of up to 10 pages in IEEE conference proceedings format. Papers should be submitted in PDF format to the respective symposium through the EDAS system at http://edas.info/Conference.cgi. =20 =20 CONFERENCE ORGANIZING COMMITTEE ------------------------------- =20 General Chair: Dr. Arun Somani, Iowa State University, arun@iastate.edu =20 General Vice Chair: Dr. Thomas Hou, Virginia Tech, thou@vt.edu =20 Technical Program Chairs - Services and Applications Symposium Dr. Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu Dr. Admela Jukan, Georgia Tech, admela.jukan@ece.gatech.edu =20 Technical Program Chair- Wireless Networking Symposium: Dr. Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca =20 Technical Program Chairs - Optical Networking Symposium Dr. David Griffith, NIST, david.griffith@nist.gov Dr. Srini Ramasubramanian, Univ. of Arizona, srini@ece.arizona.edu =20 Workshops Chair: Dr. Wendi Heinzelman, University of Rochester, = wheinzel@ece.rochester.edu Dr. Byrav Ramamurthy, University of Nebraska-Lincoln, byrav@cse.unl.edu Dr. Behcet Sarikaya, University of Northern British Columbia, sarikaya@unbc.ca =20 Tutorials Chair: Dr. Steven Low, Cal. Tech., slow@caltech.edu =20 Panels Chairs: Dr. Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu Dr. Rudra Dutta, NCSU, dutta@csc.ncsu.edu =20 Publicity Chairs: Dr. Bhaskar Krishnamachari, USC, bkrishna@usc.edu Dr. Takeo Hamada, Fujitsu Labs of America, thamada@fla.fujitsu.com =20 Website/Information Systems Chair: Dr. Shiwen Mao, Virginia Tech, smao@vt.edu =20 Local Arrangements Chairs: Dr. Aura Ganz, Univ. of Massachusetts, Amherst, ganz@ecs.umass.edu Dr. Ling Li, CIENA, linlisu@hotmail.com =20 Publications Chairs: Dr. Ahmed Kamal, Iowa State University, kamal@iastate.edu Dr. Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com =20 Exhibits and Sponsorships Chair: Dr. Sai Shankar N, Philips Research USA, sai.shankar@philips.com =20 Finance Chair: Karen Decker, ICST, karen@icst.org =20 Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, Univ. of Maryland, Baltimore County, krishna@umbc.edu =20 -------------------------------------------------------------------------= - =20 =20 =20 =20 =20 ------=_NextPart_000_0003_01C507C0.9C9E1C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

--------------------------= ---------------------------------------------

CALL FOR = PAPERS

 

Second = Annual International Conference on Broadband Networks

(BroadNets 2005)

Broadband = Applications and Services Symposium

October 3 - 7, 2005

Boston, Massachusetts, USA

http://www.broadnets.org

 

Submission Deadline Extended: February 25, = 2005

--------------------------= ---------------------------------------------

 

SCOPE

-----

 

BroadNets 2005 is an international conference focusing on broadband networking and = covers the entire gamut of next generation networks

with = high bandwidth available for both wireless and wireline networks.  The conference will consist of the following three = symposia:

 

** = Broadband Wireless Networking Symposium: covers mobility, routing for multihop, multimedia QoS and traffic management,

cross-layer optimization, MAC and emerging physical = layer technologies (UWB, MIMO) for high-speed wireless networking.

 

** = Broadband Optical Networking Symposium: covers WDM technologies, Ethernet and MPLS integration into the optical layer,

Next-Generation SONET/SDH, as well as SAN = extensions over DWDM/SONET/SDH.

 

** = Broadband Applications/Services Symposium: covers middleware and service architectures for broadband applications, pervasive

computing and ubiquitous communications, and universal broadband access for = information services.

 

BroadNets 2005 will thus offer a unique forum for researchers from academia, government = and industry to share ideas and disseminate new

results in these important areas.

 

This = Call for Papers describes the details for the Broadband Applications/Services Symposium ONLY. (Refer to the www.broadnets.org

website for the details of Broadband Optical Networking Symposium and Broadband Wireless Networking Symposium.) This Symposium invites

academic and industry researchers to present issues and opportunities for = tomorrow’s IT infrastructure as driven by broadband applications = and

services.  We invite the research community to present the most recent advances in = this field, to discuss exciting research topics and = development

of = test beds and applications, and to share their research and development = experiences.  We hope to organize one or more panel sessions of

industry leaders to offer them an opportunity to outline their vision for future broadband networks, as well as to offer academic and = national

laboratory researchers an opportunity to ask questions/provide feedback to these = industry leaders.  Our goal is to raise the awareness of = new

industry developments in the academic community, and, at the same time, to = establish a sound link between applied and theoretical research.

 

Topics of interest for which we are soliciting full-length papers include, but are = not limited to, the following:

 

·   =         Applications for security and privacy

·   =         Applications and services for grid networks

·   =         Grid middleware

·   =         Collaborative remote visualization and virtual reality

·   =         Data mining and high-speed file transfer applications

·   =         Collaborative computational steering

·   =         Multimedia applications for wireless networks

·   =         Multimedia applications for optical networks

·   =         Video-conferencing and video-telephony

·   =         Video-on-demand, TV-on-demand

·   =         Ultra Wideband (UWB) applications

·   =         Applications in 3G/4G networks

·   =         Applications and services in integrated 3GPP-WLAN = networks

·   =         Applications for wireless indoor & home networks

·   =         Applications in large-scale sensor networks

·   =         P2P applications

·   =         Applications for overlay networks

·   =         Multicast applications

·   =         Broadband access applications

·   =         Pricing models for new services

·   =         Standards, licensing and regulation

·   =         Economics and business cases

·   =         Applications for e-government, e-health and e-science

·   =         Storage applications

 

 

IMPORTANT DATES

---------------

 

Submission Deadline:          &nbs= p;            = ; February 25, 2005

Acceptance Notification:        = May 15, = 2005

Final Manuscript = Due:           = June 1, = 2005

 

PAPER SUBMISSION INSTRUCTIONS

--------------------------= ---

 

Authors are invited to submit full papers of up to 10 pages in = IEEE

conference proceedings format.  Papers should be submitted in = PDF

format to the respective symposium through the EDAS = system at

http://edas.info/Conferenc= e.cgi.

 

 

CONFERENCE = ORGANIZING COMMITTEE

--------------------------= -----

 

General = Chair:

Dr. = Arun Somani, Iowa State University, arun@iastate.edu

 

General Vice Chair:

Dr. = Thomas Hou, Virginia Tech, thou@vt.edu

 

Technical Program Chairs - Services and Applications Symposium

Dr. = Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu

Dr. = Admela Jukan, Georgia Tech, admela.jukan@ece.gatech.edu

 

Technical Program Chair- Wireless Networking Symposium:

Dr. = Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca

 

Technical Program Chairs - Optical Networking Symposium

Dr. = David Griffith, NIST, david.griffith@nist.gov

Dr. = Srini Ramasubramanian, Univ. of Arizona, srini@ece.arizona.edu

 

Workshops = Chair:

Dr. = Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu=

Dr. = Byrav Ramamurthy, University of = Nebraska-Lincoln, byrav@cse.unl.edu

Dr. = Behcet Sarikaya, University of Northern British Columbia,

sarikaya@unbc.ca

 

Tutorials Chair:

Dr. = Steven Low, Cal. Tech., slow@caltech.edu

 

Panels = Chairs:

Dr. = Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu

Dr. = Rudra Dutta, NCSU, dutta@csc.ncsu.edu

 

Publicity Chairs:

Dr. = Bhaskar Krishnamachari, USC, bkrishna@usc.edu

Dr. = Takeo Hamada, Fujitsu Labs of America, thamada@fla.fujitsu.com

 

Website/Information Systems Chair:

Dr. = Shiwen Mao, Virginia Tech, smao@vt.edu

 

Local Arrangements Chairs:

Dr. = Aura Ganz, Univ. of Massachusetts, Amherst, ganz@ecs.umass.edu<= /font>

Dr. = Ling Li, CIENA, linlisu@hotmail.com

 

Publications Chairs:

Dr. = Ahmed Kamal, Iowa State University, kamal@iastate.edu

Dr. = Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com

 

Exhibits and Sponsorships Chair:

Dr. = Sai Shankar N, Philips Research USA, sai.shankar@philips.com

 

Finance = Chair:

Karen Decker, ICST, karen@icst.org

 

Steering Committee Co-Chairs:

Dr. = Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu

Dr. = Krishna Sivalingam, Univ. of Maryland, Baltimore County,

krishna@umbc.edu

 

--------------------------= ------------------------------------------------

 

 

 

 

 

------=_NextPart_000_0003_01C507C0.9C9E1C10-- --===============0355684540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0355684540==--