From owner-mpls@UU.NET Sun Oct 1 06:40:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07856 for ; Sun, 1 Oct 2000 06:40:36 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjizy04405; Sun, 1 Oct 2000 10:40:22 GMT Received: by mail-control.mail.uu.net id QQjizy05606 for mpls-outgoing; Sun, 1 Oct 2000 10:39:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjizy05594 for ; Sun, 1 Oct 2000 10:39:44 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjizy21342 for ; Sun, 1 Oct 2000 06:33:28 -0400 (EDT) From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjizy12744 for ; Sun, 1 Oct 2000 10:33:27 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id TAA02008; Sun, 1 Oct 2000 19:34:27 +0900 (KST) X-OpenMail-Hops: 2 Date: Sun, 1 Oct 2000 19:33:42 +0900 Message-Id: Subject: LDP-SessionRej / Bad KeepAlive MIME-Version: 1.0 TO: mpls@UU.NET, rhthomas@cisco.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Sun, 1 Oct 2000 19:19:39 +0900" ;Modification-Date="Sun, 1 Oct 2000 19:33:37 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit >> Thank u. >> I have one more doubt on the usage of "Session Rejected/Bad keep alive" >> when we need to use it exactly. >Use it when the Keep Alive time requested by the peer's Initialization >message is unacceptable. Bob, u r saying that during initialization message if KeepAlive time is unacceptable send this notification. but the draft says " The receiving LSR MUST calculate the value of the KeepAlive Timer by using the smaller of its proposed KeepAlive Time and the KeepAlive Time received in the PDU. The value chosen for KeepAlive Time indicates the maximum number of seconds that may elapse between the receipt of successive PDUs from the LDP peer on the session TCP connection. The KeepAlive Timer is reset each time a PDU arrives." (pls ref : Initialization message) In the case of max PDU length etc....there is some range and LSR should obey them, during negotiation if it is out of range the negotiation fails....and LSR sends a suitable notification to the peer. I feel this is the way it should work..IF I AM WORNG PLS CORRECT ME. but in case of keepAlive how it happens.....as it always takes min of the proposed values. Draft has defined these new TLVs (Unsupported Address family, Bad_KeepAlive,...) but why it has not said anything about its usage....I mean when and where to use....how to handle it....? Thanks in advance regards seenu From owner-mpls@UU.NET Sun Oct 1 17:19:22 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12295 for ; Sun, 1 Oct 2000 17:19:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjbp00546; Sun, 1 Oct 2000 21:19:02 GMT Received: by mail-control.mail.uu.net id QQjjbp15118 for mpls-outgoing; Sun, 1 Oct 2000 21:18:32 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjbp15108 for ; Sun, 1 Oct 2000 21:18:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjbp18061 for ; Sun, 1 Oct 2000 17:18:10 -0400 (EDT) From: Vishal.Sharma@tellabs.com Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQjjbp25190 for ; Sun, 1 Oct 2000 21:17:39 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id QAA02286 for ; Sun, 1 Oct 2000 16:16:16 -0500 (CDT) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA21354 for ; Sun, 1 Oct 2000 16:17:38 -0500 (CDT) X-OpenMail-Hops: 1 Date: Sun, 1 Oct 2000 16:17:36 -0500 Message-Id: Subject: Re: Comments draft-ietf-mpls-recovery-frmwork-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Sun, 1 Oct 2000 16:17:35 -0500" To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk Hi Sergey, I apologize for the delayed response. Our company email server was having some problems the week you sent this email, so I never received a copy of it directly. It was only this weekend, while reviewing the MPLS list archives, that I came across it, so I am responding at the first opportunity. Anyway, thanks very much for your comments and observations. Please see my comments below. Regards, -Vishal > -----Original Message----- > Comments: draft-ietf-mpls-recovery-frmwork-00.txt > > From: Porotsky Sergey > Date: Thu, 21 Sep 2000 15:58:25 +0300 > > > Hello, Vishal. > Thanks for this draft, it gets us very good initial point to create > protection/restoration schemes. > I have a few comments and questions. > > 1. In section 1.3 you have wrote : > "I. MPLS-based recovery mechanisms should facilitate fast (10?s of ms) > recovery times." > I agree, that it is necessary and it is possible to support > for protection > mechanisms. But is it really to support for rerouting > schemes, in which the > recovery path is not pre-established ? If I understand your question, you are asking whether the 10s of ms objective holds also for the case where one uses reroute recovery. Please note that we specify the 10s of ms as an _objective or goal_ for protection/recovery schemes, as opposed to making it a requirement. Not all of the schemes may meet this goal. In particular, reroute recovery schemes, where the recovery path is not pre-established may take longer to recover the working traffic. > > 2. In section 2.1.1 is written : > "In terms of the principles defined in section 3, reroute > recovery employs > paths established-on-demand with resources reserved-on-demand." > I think, that for pre-planned rerouting techniques we can use two > alternatives: > * Only recovery route is selected, resource reservation > is absent; > * Recovery route is selected and resources are > semi-dedicated (e.g., > bandwidth is pre-planned assigned and shared for several > recovery paths). You are correct. This is something we realized before the last IETF but did not incorporate into the draft yet. In fact, the latter case is particularly important in the case of generalized MPLS (GMPLS), where resources for protection paths in a SONET or an optical cross-connect may be reserved, but the actual cross-connections may not be made until a fault occurs, and it becomes known which of the working paths sharing the protection resources actually has the fault. We will incorporate this in the next revision. > 3. In section 2.3.1 is written: > "Rerouting - a recovery mechanism in which the recovery path or path > segments are created dynamically after the detection of a fault on the > working path." > Notion "rerouting" usually is used not only for recovery. For example, > ATMForum uses both notions hard-rerouting > (break-before-make)for recovery > and soft-rerouting (make-before-break)for re-arrangement. The draft, as written, does not, strictly speaking, have a notion of "soft rerouting" in it, since we felt that that is not a notion that is related to protection or recovery. We were using "rerouting" always in the context of "hard rerouting." The notion of optimizing a path is partially addressed in the draft under "dynamic re-routing cycle" in Section 2.2.3. Do you think that we need to talk about "soft rerouting" in the draft? > 4.In section 3.3 is written: > "Reserved-on-Demand:This option may apply either to rerouting or to > protection switching. Here a recovery path reserves the > required resources > after a failure..." > Is it really for protection scheme to reserve resources after > failure? If I > understand right, for this scheme the aim of the recovery LSP > establishment > before failure is only label assignments. In this case after > failure for > early established recovery LSP it is necessary once more to > perform Setup by > means of LDP/RSVP signalling, isn't it? Moreover - this > scheme, in differ > of pre-reserved protection, can't guarantee success of this > second Setup. > What is significant difference and advantage of this scheme > from re-routing ? The scheme referred to above is what you have earlier called: >* Only recovery route is selected, resource reservation > is absent; The advantage of such a scheme over rerouting is that the recovery route can be selected a priori by on-line or off-line algorithms and, as you observe, label allocation can be also done along the recovery route (although it may not be), which would not be possible in a pure rerouting scenario. Also, in the above scheme, since the backup route is selected before hand, it can be done more carefully than might be possible in a rerouting scenario. The only thing that remains upon the occurrence of a fault is to use signaling to reserve resources along the path. If the backup route calculation is a time consuming exercise (which it can be in a mesh network) this scheme can be faster than pure rerouting. In fact, pure rerouting may be forced, due to time constraints, to simply resort to using hop-by-hop routing to find the protection path, which may not be good or optimal. Of course, if one argues that in the "rerouting" case also, one will run the same path computation algorithms as in the protection switching case, and make a resource reservation along an optimal backup path, then the first scheme may not offer any advantage over the reroute case. > > 5. In section 3.6 is written: > "Fault Notification: Protection switching relies...the node > should send out > a notification of the fault by transmitting a FIS to those of > its upstream > LSRs..." > What we have to use for notification on the Rerouting Scheme > - also FIS or > other mechanisms? The implicit assumption in our description of the reroute scheme was that the nodes affected by the fault learn of the fault via changes to the routing updates. I suppose it is possible, even in the reroute case, to have the affected nodes (PSLs) be notified by some means other than routing. In that case, an FIS message would be one way to do so. From owner-mpls@UU.NET Mon Oct 2 00:07:29 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18380 for ; Mon, 2 Oct 2000 00:07:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjcq14567; Mon, 2 Oct 2000 04:07:06 GMT Received: by mail-control.mail.uu.net id QQjjcq27108 for mpls-outgoing; Mon, 2 Oct 2000 04:06:34 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjcq27103 for ; Mon, 2 Oct 2000 04:06:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjcq16479 for ; Mon, 2 Oct 2000 00:06:20 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjcq14343 for ; Mon, 2 Oct 2000 04:06:19 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA07233 for mpls@uu.net; Mon, 2 Oct 2000 00:06:19 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjcq27012 for ; Mon, 2 Oct 2000 04:06:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjcq16446 for ; Mon, 2 Oct 2000 00:05:56 -0400 (EDT) Received: from boreas.isi.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjjcq14267 for ; Mon, 2 Oct 2000 04:05:56 GMT Received: (from braden@localhost) by boreas.isi.edu (8.9.3/8.9.3) id VAA00229; Sun, 1 Oct 2000 21:05:48 -0700 (PDT) Date: Sun, 1 Oct 2000 21:05:48 -0700 (PDT) From: Bob Braden Message-Id: <200010020405.VAA00229@boreas.isi.edu> To: braden@ISI.EDU, lberger@labn.net, AF@dataconnection.com, jdrake@calient.net Subject: RE: RSVP HOP on PathErr Cc: swallow@cisco.com, petera@nortelnetworks.com, mpls@UU.NET X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk *> *> Bob, *> *> As I mentioned, we're dealing with a distributed implementation and we're *> trying to minimize the amount of replicated state information. The PathErr *> as well as all other messages that flow towards the origin have to be *> transferred from the egress card to the correct ingress card, and having a *> separate mechanism for PathErr is a nuisance. *> *> Thanks, *> *> John *> I am not fundamentally hostile to adding HOP to PathErr if there is a good reason, but I interpret your comment above as an implementation problem in a particular organization of the router hardware. Did I misinterpret? Such considerations aside, I see NO separate mechanism; the PathErr is routed upstream just as Resv messages are routed upstream. Bob Braden *> -----Original Message----- *> From: Bob Braden [mailto:braden@ISI.EDU] *> Sent: Tuesday, September 19, 2000 8:44 AM *> To: lberger@labn.net; AF@dataconnection.com; John Drake *> Cc: swallow@cisco.com; petera@nortelnetworks.com; mpls@UU.NET; *> braden@ISI.EDU *> Subject: RE: RSVP HOP on PathErr *> *> *> *> *> From jdrake@calient.net Tue Sep 19 08:13:33 2000 *> *> From: John Drake *> *> To: "'Lou Berger'" , Adrian Farrel *> *> *> Cc: swallow@cisco.com, petera@nortelnetworks.com, mpls@UU.NET, *> braden@ISI.EDU *> *> Subject: RE: RSVP HOP on PathErr *> *> Date: Tue, 19 Sep 2000 08:13:22 -0700 *> *> MIME-Version: 1.0 *> *> X-Mailer: Internet Mail Service (5.5.2650.21) *> *> X-Lines: 61 *> *> *> *> Lou, *> *> *> *> I think the point is that since PathErr doesn't have HOP, it doesn't *> have *> *> the LIH information. This means that a node has to have another *> mechanism, *> *> like Session ID, to get PathErr to the correct ingress interface, and *> this *> *> is extra work and complexity, paticularly in a distributed *> implementation. *> *> *> *> Thanks, *> *> *> *> John *> *> Why doesn't the path state tell you the correct incoming interface? *> You should have path state at all nodes upstream of the failure. *> *> Bob Braden *> *> *> *> *> -----Original Message----- *> *> From: Lou Berger [mailto:lberger@labn.net] *> *> Sent: Tuesday, September 19, 2000 3:34 AM *> *> To: Adrian Farrel *> *> Cc: swallow@cisco.com; petera@nortelnetworks.com; mpls@UU.NET; *> *> braden@isi.edu *> *> Subject: Re: RSVP HOP on PathErr *> *> *> *> *> *> Adrian, *> *> *> *> I don't see the need for this change, particularly since there are no *> *> non-RSVP hops with RSVP-TE. *> *> *> *> In an abstract sense having HOP in PathErr is no big deal, but the call *> was *> *> made not to include it when the protocol was specified in RFC2205. I *> don't *> *> think we should make changes in the base protocol just because of *> *> aesthetics. *> *> *> *> What case do see where you can't "get back to the same interface" on *> *> receipt of a PathErr? *> *> *> *> Lou *> *> *> *> At 04:45 AM 9/19/00, Adrian Farrel wrote: *> *> >Hi, *> *> > *> *> >Here's a bit of controversy for you! *> *> > *> *> >I just polled the RSVP list to see if anyone recalled why PathErr does *> not *> *> >carry RSVP HOP. Bob Braden helpfully replied that it was left out *> because *> *> >it was not needed (reasonable enough!). *> *> > *> *> >Can I suggest that it now has its uses in MPLS, especially GMPLS where *> a *> *> >reservation may already have been made on the forward path (i.e. when *> the *> *> >Path message was processed) and it is necessary to get back to the *> same *> *> >interface (identified by the LIH) when the PathErr is received. *> *> > *> *> >Would either of you, for this reason or for symmetry, be prepared to *> put *> *> >RSVP HOP on PathErr in your drafts (rsvp-lsp-tunnel or *> *> >generalized-signaling)? *> *> > *> *> >Regards, *> *> >Adrian *> *> >-- *> *> >Adrian Farrel mailto:af@datcon.co.uk *> *> >Network Convergence Group *> *> >Data Connection Ltd., Chester, UK *> *> >http://www.datcon.co.uk/ *> *> >Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 *> *> *> From owner-mpls@UU.NET Mon Oct 2 10:12:00 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08238 for ; Mon, 2 Oct 2000 10:12:00 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjee10175; Mon, 2 Oct 2000 14:11:10 GMT Received: by mail-control.mail.uu.net id QQjjee25260 for mpls-outgoing; Mon, 2 Oct 2000 14:10:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjee25251 for ; Mon, 2 Oct 2000 14:10:36 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjee00266 for ; Mon, 2 Oct 2000 10:10:12 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjjee09662 for ; Mon, 2 Oct 2000 14:10:11 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA05300 for ; Mon, 2 Oct 2000 07:10:11 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA17915 for mpls@uu.net; Mon, 2 Oct 2000 10:10:09 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjcy26203 for ; Mon, 2 Oct 2000 06:05:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjcy20783 for ; Mon, 2 Oct 2000 02:05:38 -0400 (EDT) Received: from p-mail1.cnet.fr by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: p-mail1.rd.francetelecom.fr [193.49.124.31]) id QQjjcy03463 for ; Mon, 2 Oct 2000 06:05:07 GMT Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Mon, 2 Oct 2000 08:04:32 +0200 Message-ID: <98388C05D464D111B61800805F150416015B9A18@p-ibis.issy.cnet.fr> From: GUESDON Herve FTRD/DAC/ISS To: "'S.Matsushima'" , erosen@cisco.com Cc: mpls@UU.NET, "'nbvpn@bbo.com'" Subject: RE: MPLS/BGP routing question Date: Mon, 2 Oct 2000 08:04:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA08238 Hi If a network event breaks the MPLS LSP between two PE in a BGP/MPLS VPN design, then I agree that the rerouting is an IGP issue. But there is also a MP-BGP-MPLS synchronisation issue if this rerouting leads to a change in the MP-BGP next hop. The switch to the LSP corresponding to the new MP-BGP net hop has to be transparent to the customer VPN traffic. Regards hervé **************************************************************** Hervé Guesdon DAC/CPN/RRI Research and Development Engineer IP Routing and VPN lab France Télécom - R&D 38-40 rue du Général-Leclerc 92794 Issy Moulineaux Cedex 9 France phone : +33.1.45.29.43.74 fax : +33.1.45.29.54.11 **************************************************************** "L'avenir c'est du passé en préparation." >-----Message d'origine----- >De : S.Matsushima [mailto:satoru@japan-telecom.co.jp] >Envoyé : samedi 30 septembre 2000 03:24 >À : erosen@cisco.com; Satoru Matsushima >Cc : mpls@UU.NET >Objet : Re: MPLS/BGP routing question > > >on 00.9.30 0:32 AM, Eric Rosen at erosen@cisco.com wrote: > >> >> Matsushima> When a LSP of PE to PE broken, BGP has no way >of LSP broken. >> Matsushima> Then, BGP keep up of VPN routes and VPN >traffic going to black >> Matsushima> hole, until LSP available. >> >> Matsushima> As a result, VPN customer can not back up >their traffic to any >> Matsushima> link. >> >> Matsushima> I think this is one of most seriously problem of >BGP/MPLS VPN. >> >> The situation you are worried about is where there is >IGP connectivity >> between the edges, but for some reason labeled packets >cannot make it from >> one edge to another. > >Yes, exactly. > >> I guess we don't really see this as a realistic failure >> scenario. Sure, buggy software could cause this, but >there's a million ways >> in which buggy software could cause undetected packet loss. >> > >I think that LSP failure was caused by not only buggy software but also >oparation failure. >For example, i) erase a interface as LDP ID ;-< , ii) routes >summarization >failure on ospf area,... > >IMO, BGP which on PE should has some way to know of LSP failure. >This is for customer. > >-- >Satoru Matsushima > From owner-mpls@UU.NET Mon Oct 2 10:26:05 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08363 for ; Mon, 2 Oct 2000 10:26:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjef15821; Mon, 2 Oct 2000 14:25:40 GMT Received: by mail-control.mail.uu.net id QQjjef26593 for mpls-outgoing; Mon, 2 Oct 2000 14:25:00 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjef26587 for ; Mon, 2 Oct 2000 14:24:57 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjef02669 for ; Mon, 2 Oct 2000 10:24:39 -0400 (EDT) Received: from hermes.research.kpn.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjjef18864 for ; Mon, 2 Oct 2000 14:24:24 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JUV9EGKE3O000MJN@research.kpn.com> for mpls@UU.NET; Mon, 2 Oct 2000 16:24:23 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Mon, 02 Oct 2000 16:24:20 +0100 Content-return: allowed Date: Mon, 02 Oct 2000 16:24:18 +0100 From: "Metz, E.T." Subject: RE: MPLS/BGP routing question To: "'curtis@avici.com'" , bkumar@ennovatenetworks.com Cc: erosen@cisco.com, "'Chris Flores'" , "'Javier Antich'" , "'Michel Redondo Ferrero'" , mpls@UU.NET Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A4F0@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk When considering a large-scale RFC2547-style VPN situation (many VPNs, many VPN routes) I would not use the actual core-routers as RRs. Instead a core-router type-of-box (or multiple), or something similar with stable BGP and sufficient memory, that sits outside the forwarding path seems a better idea to me. In particular with regard to core stability. cheers, Eduard > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: vrijdag 29 september 2000 21:27 > To: bkumar@ennovatenetworks.com > Cc: erosen@cisco.com; 'Chris Flores'; 'Javier Antich'; 'Michel Redondo > Ferrero'; mpls@UU.NET > Subject: Re: MPLS/BGP routing question > > > > In message > <000a01c0298e$65239720$d001010a@tst.ennovatenetworks.com>, "Brijesh > Kumar" writes: > > Eric, > > > > I don't think I said that Route Reflectors need to be in > the path, or > > this function cannot be implemented on an Edge router itself. But > > given the performance difference in access routers and core routers, > > and the role of a route reflector in applying policies on behalf of > > clients, it is pretty obvious that a core router is more > suitable for > > route reflection function. And we both agree that a router > designated > > as Route Reflector need to run BGP. > > > > Cheers, > > > > --brijesh > > > A route reflector need not be a router but it does have to run BGP. > Though common practice is to use the core routers since currently they > must IBGP anyway and generally have the memory and CPU power and a > stable BGP implementation to do it well. > > Curtis > From owner-mpls@UU.NET Mon Oct 2 10:32:57 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08429 for ; Mon, 2 Oct 2000 10:32:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjeg19003; Mon, 2 Oct 2000 14:32:22 GMT Received: by mail-control.mail.uu.net id QQjjeg27077 for mpls-outgoing; Mon, 2 Oct 2000 14:31:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjeg27072 for ; Mon, 2 Oct 2000 14:31:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjeg04060 for ; Mon, 2 Oct 2000 10:31:30 -0400 (EDT) Received: from hermes.research.kpn.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjjeg22429 for ; Mon, 2 Oct 2000 14:31:28 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JUV9N8BWPI000N4F@research.kpn.com> for mpls@UU.NET; Mon, 2 Oct 2000 16:31:27 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Mon, 02 Oct 2000 16:31:25 +0100 Content-return: allowed Date: Mon, 02 Oct 2000 16:31:24 +0100 From: "Metz, E.T." Subject: RE: MPLS/BGP routing question To: "'GUESDON Herve FTRD/DAC/ISS'" , "'S.Matsushima'" , erosen@cisco.com Cc: mpls@UU.NET, "'nbvpn@bbo.com'" Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A4F1@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA08429 Why would the MP-BGP next-hop change? In general this is the address of a logical interface right?, since these only tend to disappear when deleted, at router failure, or complete router isolation (which does not seems the case here), I do not see why it should change. Am I missing something? cheers, Eduard > -----Original Message----- > From: GUESDON Herve FTRD/DAC/ISS > [mailto:herve.guesdon@rd.francetelecom.fr] > Sent: maandag 2 oktober 2000 7:04 > To: 'S.Matsushima'; erosen@cisco.com > Cc: mpls@UU.NET; 'nbvpn@bbo.com' > Subject: RE: MPLS/BGP routing question > > > Hi > > If a network event breaks the MPLS LSP between two PE in a > BGP/MPLS VPN > design, then I agree that the rerouting is an IGP issue. But > there is also a > MP-BGP-MPLS synchronisation issue if this rerouting leads to > a change in the > MP-BGP next hop. The switch to the LSP corresponding to the > new MP-BGP net > hop has to be transparent to the customer VPN traffic. > > Regards > > hervé > > **************************************************************** > Hervé Guesdon DAC/CPN/RRI > Research and Development Engineer > IP Routing and VPN lab > France Télécom - R&D > 38-40 rue du Général-Leclerc > 92794 Issy Moulineaux Cedex 9 France > phone : +33.1.45.29.43.74 fax : +33.1.45.29.54.11 > **************************************************************** > > "L'avenir c'est du passé en préparation." > > > >-----Message d'origine----- > >De : S.Matsushima [mailto:satoru@japan-telecom.co.jp] > >Envoyé : samedi 30 septembre 2000 03:24 > >À : erosen@cisco.com; Satoru Matsushima > >Cc : mpls@UU.NET > >Objet : Re: MPLS/BGP routing question > > > > > >on 00.9.30 0:32 AM, Eric Rosen at erosen@cisco.com wrote: > > > >> > >> Matsushima> When a LSP of PE to PE broken, BGP has no way > >of LSP broken. > >> Matsushima> Then, BGP keep up of VPN routes and VPN > >traffic going to black > >> Matsushima> hole, until LSP available. > >> > >> Matsushima> As a result, VPN customer can not back up > >their traffic to any > >> Matsushima> link. > >> > >> Matsushima> I think this is one of most seriously problem of > >BGP/MPLS VPN. > >> > >> The situation you are worried about is where there is > >IGP connectivity > >> between the edges, but for some reason labeled packets > >cannot make it from > >> one edge to another. > > > >Yes, exactly. > > > >> I guess we don't really see this as a realistic failure > >> scenario. Sure, buggy software could cause this, but > >there's a million ways > >> in which buggy software could cause undetected packet loss. > >> > > > >I think that LSP failure was caused by not only buggy > software but also > >oparation failure. > >For example, i) erase a interface as LDP ID ;-< , ii) routes > >summarization > >failure on ospf area,... > > > >IMO, BGP which on PE should has some way to know of LSP failure. > >This is for customer. > > > >-- > >Satoru Matsushima > > > From owner-mpls@UU.NET Mon Oct 2 10:48:09 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08585 for ; Mon, 2 Oct 2000 10:48:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjeh25496; Mon, 2 Oct 2000 14:47:50 GMT Received: by mail-control.mail.uu.net id QQjjeh28113 for mpls-outgoing; Mon, 2 Oct 2000 14:47:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjeh28078 for ; Mon, 2 Oct 2000 14:47:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjeh06836 for ; Mon, 2 Oct 2000 10:47:00 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjeh24921 for ; Mon, 2 Oct 2000 14:46:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA12951 for mpls@uu.net; Mon, 2 Oct 2000 10:46:29 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjeh27883 for ; Mon, 2 Oct 2000 14:46:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjeh08051 for ; Mon, 2 Oct 2000 10:45:40 -0400 (EDT) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjjeh29975 for ; Mon, 2 Oct 2000 14:45:39 GMT Received: from london.cisco.com (london.cisco.com [144.254.32.9]) by ogma.cisco.com (Postfix) with ESMTP id 4129911D; Mon, 2 Oct 2000 16:45:39 +0200 (MET DST) Received: from jguichar-8kcdt.cisco.com (lon-sto4-lan-vlan127-dhcp35.cisco.com [144.254.105.102]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA16297; Mon, 2 Oct 2000 16:45:36 +0200 (MET DST) Message-Id: <200010021445.QAA16297@london.cisco.com> X-Sender: jguichar@uk.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 02 Oct 2000 15:43:01 +0100 To: GUESDON Herve FTRD/DAC/ISS , "'S.Matsushima'" , erosen@cisco.com From: Jim Guichard Subject: RE: MPLS/BGP routing question Cc: mpls@UU.NET, "'nbvpn@bbo.com'" In-Reply-To: <98388C05D464D111B61800805F150416015B9A18@p-ibis.issy.cnet. fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA08585 it seems reasonable to suppose that if the BGP next-hop changes then the MP-BGP update has been originated by a different PE router. This being the case, then one can assume that the attached VPN site will have advertised the route across two separate paths so that two separate PE routers can originate the route. In this scenario, we should pick the best path based on BGP decision process and if this best path goes away, we would revert to the other path, hence tranparency to the VPN traffic. Not sure how else the BGP next-hop would change .. regards, Jim At 08:04 02/10/2000 +0200, GUESDON Herve FTRD/DAC/ISS wrote: >Hi > >If a network event breaks the MPLS LSP between two PE in a BGP/MPLS VPN >design, then I agree that the rerouting is an IGP issue. But there is also a >MP-BGP-MPLS synchronisation issue if this rerouting leads to a change in the >MP-BGP next hop. The switch to the LSP corresponding to the new MP-BGP net >hop has to be transparent to the customer VPN traffic. > >Regards > >hervé > >**************************************************************** >Hervé Guesdon DAC/CPN/RRI >Research and Development Engineer >IP Routing and VPN lab >France Télécom - R&D >38-40 rue du Général-Leclerc >92794 Issy Moulineaux Cedex 9 France >phone : +33.1.45.29.43.74 fax : +33.1.45.29.54.11 >**************************************************************** > >"L'avenir c'est du passé en préparation." > > >>-----Message d'origine----- >>De : S.Matsushima [mailto:satoru@japan-telecom.co.jp] >>Envoyé : samedi 30 septembre 2000 03:24 >>À : erosen@cisco.com; Satoru Matsushima >>Cc : mpls@UU.NET >>Objet : Re: MPLS/BGP routing question >> >> >>on 00.9.30 0:32 AM, Eric Rosen at erosen@cisco.com wrote: >> >>> >>> Matsushima> When a LSP of PE to PE broken, BGP has no way >>of LSP broken. >>> Matsushima> Then, BGP keep up of VPN routes and VPN >>traffic going to black >>> Matsushima> hole, until LSP available. >>> >>> Matsushima> As a result, VPN customer can not back up >>their traffic to any >>> Matsushima> link. >>> >>> Matsushima> I think this is one of most seriously problem of >>BGP/MPLS VPN. >>> >>> The situation you are worried about is where there is >>IGP connectivity >>> between the edges, but for some reason labeled packets >>cannot make it from >>> one edge to another. >> >>Yes, exactly. >> >>> I guess we don't really see this as a realistic failure >>> scenario. Sure, buggy software could cause this, but >>there's a million ways >>> in which buggy software could cause undetected packet loss. >>> >> >>I think that LSP failure was caused by not only buggy software but also >>oparation failure. >>For example, i) erase a interface as LDP ID ;-< , ii) routes >>summarization >>failure on ospf area,... >> >>IMO, BGP which on PE should has some way to know of LSP failure. >>This is for customer. >> >>-- >>Satoru Matsushima >> > Jim Guichard CCIE #2069 Network Design Consultant EMEA Global Solutions Engineering +44 (0)181 756 8806 Mobile: +44 802 809763 From owner-mpls@UU.NET Mon Oct 2 11:04:18 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08799 for ; Mon, 2 Oct 2000 11:04:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjei09116; Mon, 2 Oct 2000 15:03:23 GMT Received: by mail-control.mail.uu.net id QQjjei05846 for mpls-outgoing; Mon, 2 Oct 2000 15:02:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjei05691 for ; Mon, 2 Oct 2000 15:02:30 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjei10933 for ; Mon, 2 Oct 2000 11:01:35 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjei01401 for ; Mon, 2 Oct 2000 15:01:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA15696 for mpls@uu.net; Mon, 2 Oct 2000 11:01:34 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjei01868 for ; Mon, 2 Oct 2000 15:00:43 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjei09318 for ; Mon, 2 Oct 2000 11:00:18 -0400 (EDT) Received: from omega.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjjei07364 for ; Mon, 2 Oct 2000 15:00:18 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA19032; Mon, 2 Oct 2000 08:00:16 -0700 (PDT) Message-Id: <200010021500.IAA19032@omega.cisco.com> To: mpls@UU.NET, swallow@cisco.com cc: kireeti@juniper.net, lberger@labn.net Subject: draft-kompella-mpls-bundle-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19029.970498813.1@cisco.com> Date: Mon, 02 Oct 2000 08:00:13 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Folks, Kireeti, Lou, and myself would like to ask the MPLS WG to accept draft-kompella-mpls-bundle-03.txt as an MPLS WG document. Yakov. ------- Forwarded Message Date: Mon, 02 Oct 2000 06:51:59 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-kompella-mpls-bundle-03.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Link Bundling in MPLS Traffic Engineering Author(s) : K. Kompella, Y. Rekhter, L. Berger Filename : draft-kompella-mpls-bundle-03.txt Pages : 10 Date : 29-Sep-00 In some cases a pair of Label Switching Routers (LSRs) may be connected by several (parallel) links. From the MPLS Traffic Engineering point of view for reasons of scalability it may be desirable to advertise all these links as a single link into OSPF and/or IS-IS. This document describes how to accomplish this. This document also defines corresponding signaling (RSVP-TE) support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kompella-mpls-bundle-03.txt 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-kompella-mpls-bundle-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-kompella-mpls-bundle-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: <20000929074304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kompella-mpls-bundle-03.txt - --OtherAccess Content-Type: Message/External-body; name="draft-kompella-mpls-bundle-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000929074304.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-mpls@UU.NET Mon Oct 2 11:10:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08921 for ; Mon, 2 Oct 2000 11:10:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjei04857; Mon, 2 Oct 2000 15:09:35 GMT Received: by mail-control.mail.uu.net id QQjjei11299 for mpls-outgoing; Mon, 2 Oct 2000 15:09:04 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjei11294 for ; Mon, 2 Oct 2000 15:08:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjei12280 for ; Mon, 2 Oct 2000 11:08:53 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQjjei04456 for ; Mon, 2 Oct 2000 15:08:52 GMT Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id LAA10266; Mon, 2 Oct 2000 11:08:45 -0400 Received: (from jleu@localhost) by localhost.laurelnetworks.com (8.9.3/8.9.3) id LAA01855; Mon, 2 Oct 2000 11:08:45 -0400 Date: Mon, 2 Oct 2000 11:08:44 -0400 From: "James R. Leu" To: mpls@UU.NET Cc: jplang@calient.net Subject: Comments on draft-ietf-mpls-lmp-00.txt Message-ID: <20001002110844.A853@laurelnetworks.com> Reply-To: jleu@laurelnetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: Laurel Networks Sender: owner-mpls@UU.NET Precedence: bulk Hello, While reading draft-ietf-mpls-lmp-00.txt, I noticed a couple of areas which could use some editing or clarification. Section 9.4.5 "EndVerifyAck Message" ------------------------------------ The phrase "The EndVerifyNack object has the following format:" Should be "The EndVerifyAck object has the following format:" Section 9.1 "Common Header" --------------------------- Isn't it common practice to byte align fields? If so I suggest: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | (Reserved) | Flags | Msg Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Channel Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 9.4.6 "Test Message" ---------------------------- Correct me if I'm wrong, but isn't the Link Id value which is being exchanged used in draft-kompella-mpls-bundle-03.txt section 5.2.1 "COMPONENT_INTERFACE_ID Object Class" where it is specified as a 16 bit number? (the same statement holds true every place where Link Id is specified) Section 9.5.1 "LinkSummary Message" ----------------------------------- If my understanding is correct, a Link Summary message could contain a sub object for every working channel between the two nodes. If this is correct isn't there a concern that the resulting PDU will exceed the MTU or available receive buffers on a node? Maybe a Maximum Protocol PDU size should be negotiated during the configuration state. General ------- I know this is being very "nit-picky", but you will need a section addressing the implications of using IPv6 addresses before this can move move towards RFC state. Jim -- James R. Leu Software Engineer Laurel Networks, Inc jleu@laurelnetworks.com From owner-mpls@UU.NET Mon Oct 2 11:10:44 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08952 for ; Mon, 2 Oct 2000 11:10:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjei13084; Mon, 2 Oct 2000 15:10:12 GMT Received: by mail-control.mail.uu.net id QQjjei11308 for mpls-outgoing; Mon, 2 Oct 2000 15:09:24 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjei11303 for ; Mon, 2 Oct 2000 15:09:21 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjei11025 for ; Mon, 2 Oct 2000 11:09:02 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjjei12153 for ; Mon, 2 Oct 2000 15:08:31 GMT Received: from tellium.com (node1.tellium.com [151.198.92.15]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e92F0tb08976; Mon, 2 Oct 2000 11:00:55 -0400 (EDT) Message-ID: <39D8A4EB.625868D5@tellium.com> Date: Mon, 02 Oct 2000 11:08:27 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: mpls@UU.NET, swallow@cisco.com, kireeti@juniper.net, lberger@labn.net Subject: Re: draft-kompella-mpls-bundle-03.txt References: <200010021500.IAA19032@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Debanjan Saha and myself are submitting a revised version of our bundling draft, draft-rs-optical-bundling-01.txt. I would like a discussion of this draft in the working group prior to deciding whether draft-kompella-mpls-bundle-03.txt should be a working group draft. Regards, Bala Yakov Rekhter wrote: > Folks, > > Kireeti, Lou, and myself would like to ask the MPLS WG to accept > draft-kompella-mpls-bundle-03.txt as an MPLS WG document. > > Yakov. > > ------- Forwarded Message > > Date: Mon, 02 Oct 2000 06:51:59 -0400 > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > Subject: I-D ACTION:draft-kompella-mpls-bundle-03.txt > > - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Link Bundling in MPLS Traffic Engineering > Author(s) : K. Kompella, Y. Rekhter, L. Berger > Filename : draft-kompella-mpls-bundle-03.txt > Pages : 10 > Date : 29-Sep-00 > > In some cases a pair of Label Switching Routers (LSRs) may be > connected by several (parallel) links. From the MPLS Traffic > Engineering point of view for reasons of scalability it may be > desirable to advertise all these links as a single link into OSPF > and/or IS-IS. This document describes how to accomplish this. This > document also defines corresponding signaling (RSVP-TE) support. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kompella-mpls-bundle-03.txt > > 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-kompella-mpls-bundle-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-kompella-mpls-bundle-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: <20000929074304.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-kompella-mpls-bundle-03.txt > > - --OtherAccess > Content-Type: Message/External-body; > name="draft-kompella-mpls-bundle-03.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <20000929074304.I-D@ietf.org> > > - --OtherAccess-- > > - --NextPart-- > > ------- End of Forwarded Message -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Mon Oct 2 11:52:35 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09969 for ; Mon, 2 Oct 2000 11:52:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjel06687; Mon, 2 Oct 2000 15:51:59 GMT Received: by mail-control.mail.uu.net id QQjjel14402 for mpls-outgoing; Mon, 2 Oct 2000 15:50:54 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjel14397 for ; Mon, 2 Oct 2000 15:50:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjel18446 for ; Mon, 2 Oct 2000 11:50:23 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjel05753 for ; Mon, 2 Oct 2000 15:50:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA24683 for mpls@uu.net; Mon, 2 Oct 2000 11:50:06 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjel14361 for ; Mon, 2 Oct 2000 15:49:42 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjel20162 for ; Mon, 2 Oct 2000 11:49:03 -0400 (EDT) Received: from p-mail2.cnet.fr by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQjjel05084 for ; Mon, 2 Oct 2000 15:48:47 GMT Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <4DZ1M90W>; Mon, 2 Oct 2000 17:47:11 +0200 Message-ID: <98388C05D464D111B61800805F150416015B9A19@p-ibis.issy.cnet.fr> From: GUESDON Herve FTRD/DAC/ISS To: "'Jim Guichard'" Cc: mpls@UU.NET, "'nbvpn@bbo.com'" Subject: RE: MPLS/BGP routing question Date: Mon, 2 Oct 2000 17:47:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA09969 Hi Jim You are right, I forgot to mention that the MP-BGP next hop can change due to the fact that the CPE is multihomed. That change must be transparent for the customer traffic. Transparency of the provider network like opaque packet transport should be a requirements for designing IP VPN. Regards herve **************************************************************** Hervé Guesdon DAC/CPN/RRI Research and Development Engineer IP Routing and VPN lab France Télécom - R&D 38-40 rue du Général-Leclerc 92794 Issy Moulineaux Cedex 9 France phone : +33.1.45.29.43.74 fax : +33.1.45.29.54.11 **************************************************************** "L'avenir c'est du passé en préparation." >-----Message d'origine----- >De : Jim Guichard [mailto:jguichar@cisco.com] >Envoyé : lundi 2 octobre 2000 16:43 >À : GUESDON Herve FTRD/DAC/ISS; 'S.Matsushima'; erosen@cisco.com >Cc : mpls@UU.NET; 'nbvpn@bbo.com' >Objet : RE: MPLS/BGP routing question > > >it seems reasonable to suppose that if the BGP next-hop >changes then the >MP-BGP update has been originated by a different PE router. >This being the >case, then one can assume that the attached VPN site will have >advertised >the route across two separate paths so that two separate PE routers can >originate the route. In this scenario, we should pick the best >path based >on BGP decision process and if this best path goes away, we >would revert to >the other path, hence tranparency to the VPN traffic. Not sure >how else the >BGP next-hop would change .. regards, Jim > >At 08:04 02/10/2000 +0200, GUESDON Herve FTRD/DAC/ISS wrote: >>Hi >> >>If a network event breaks the MPLS LSP between two PE in a >BGP/MPLS VPN >>design, then I agree that the rerouting is an IGP issue. But >there is also a >>MP-BGP-MPLS synchronisation issue if this rerouting leads to >a change in the >>MP-BGP next hop. The switch to the LSP corresponding to the >new MP-BGP net >>hop has to be transparent to the customer VPN traffic. >> >>Regards >> >>hervé >> >>**************************************************************** >>Hervé Guesdon DAC/CPN/RRI >>Research and Development Engineer >>IP Routing and VPN lab >>France Télécom - R&D >>38-40 rue du Général-Leclerc >>92794 Issy Moulineaux Cedex 9 France >>phone : +33.1.45.29.43.74 fax : +33.1.45.29.54.11 >>**************************************************************** >> >>"L'avenir c'est du passé en préparation." >> >> >>>-----Message d'origine----- >>>De : S.Matsushima [mailto:satoru@japan-telecom.co.jp] >>>Envoyé : samedi 30 septembre 2000 03:24 >>>À : erosen@cisco.com; Satoru Matsushima >>>Cc : mpls@UU.NET >>>Objet : Re: MPLS/BGP routing question >>> >>> >>>on 00.9.30 0:32 AM, Eric Rosen at erosen@cisco.com wrote: >>> >>>> >>>> Matsushima> When a LSP of PE to PE broken, BGP has no way >>>of LSP broken. >>>> Matsushima> Then, BGP keep up of VPN routes and VPN >>>traffic going to black >>>> Matsushima> hole, until LSP available. >>>> >>>> Matsushima> As a result, VPN customer can not back up >>>their traffic to any >>>> Matsushima> link. >>>> >>>> Matsushima> I think this is one of most seriously problem of >>>BGP/MPLS VPN. >>>> >>>> The situation you are worried about is where there is >>>IGP connectivity >>>> between the edges, but for some reason labeled packets >>>cannot make it from >>>> one edge to another. >>> >>>Yes, exactly. >>> >>>> I guess we don't really see this as a realistic failure >>>> scenario. Sure, buggy software could cause this, but >>>there's a million ways >>>> in which buggy software could cause undetected packet loss. >>>> >>> >>>I think that LSP failure was caused by not only buggy >software but also >>>oparation failure. >>>For example, i) erase a interface as LDP ID ;-< , ii) routes >>>summarization >>>failure on ospf area,... >>> >>>IMO, BGP which on PE should has some way to know of LSP failure. >>>This is for customer. >>> >>>-- >>>Satoru Matsushima >>> >> > > >Jim Guichard CCIE #2069 >Network Design Consultant EMEA >Global Solutions Engineering > >+44 (0)181 756 8806 >Mobile: +44 802 809763 > From owner-mpls@UU.NET Mon Oct 2 19:06:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15507 for ; Mon, 2 Oct 2000 19:06:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjfo20098; Mon, 2 Oct 2000 23:05:49 GMT Received: by mail-control.mail.uu.net id QQjjfo16567 for mpls-outgoing; Mon, 2 Oct 2000 23:05:18 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjfo16546 for ; Mon, 2 Oct 2000 23:05:13 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.38]) id QQjjfo16055 for ; Mon, 2 Oct 2000 23:04:53 GMT Received: from lux.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQjjfo27367 for ; Mon, 2 Oct 2000 23:04:52 GMT Received: by lux.chromisys.com with Internet Mail Service (5.5.2650.21) id <4B1P6AL3>; Mon, 2 Oct 2000 16:04:43 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CECF1@lux.chromisys.com> From: Jonathan Lang To: "'jleu@laurelnetworks.com'" , mpls@UU.NET Cc: Jonathan Lang Subject: RE: Comments on draft-ietf-mpls-lmp-00.txt Date: Mon, 2 Oct 2000 16:04:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk James, Thanks for the comments. Responses in-line. -Jonathan > Section 9.4.5 "EndVerifyAck Message" > ------------------------------------ > The phrase "The EndVerifyNack object has the following format:" > Should be "The EndVerifyAck object has the following format:" Thanks for pointing out the typo. > > Section 9.1 "Common Header" > --------------------------- > Isn't it common practice to byte align fields? If so I suggest: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | (Reserved) | Flags | Msg Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Control Channel Id | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Good suggestion. > > Section 9.4.6 "Test Message" > ---------------------------- > Correct me if I'm wrong, but isn't the Link Id value which is being > exchanged used in draft-kompella-mpls-bundle-03.txt section 5.2.1 > "COMPONENT_INTERFACE_ID Object Class" where it is specified > as a 16 bit > number? > > (the same statement holds true every place where Link Id is specified) You are correct that the Link Id value is the same as the Component Interface Identifier in the bundle draft and the next version of LMP will be realigned appropriately with the bundle draft. > > Section 9.5.1 "LinkSummary Message" > ----------------------------------- > If my understanding is correct, a Link Summary message could contain a > sub object for every working channel between the two nodes. > If this is correct > isn't there a concern that the resulting PDU will exceed the MTU or > available receive buffers on a node? Maybe a Maximum > Protocol PDU size should > be negotiated during the configuration state. The LinkSummary message, like all other LMP messages except the Test message, are IP encoded, so normal IP fragmentation should take care of this. > > General > ------- > I know this is being very "nit-picky", but you will need a section addressing > the implications of using IPv6 addresses before this can move move towards RFC state. > We'll work on this. > Jim > -- > James R. Leu > Software Engineer > Laurel Networks, Inc > jleu@laurelnetworks.com > From owner-mpls@UU.NET Mon Oct 2 19:32:33 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15731 for ; Mon, 2 Oct 2000 19:32:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjfq28726; Mon, 2 Oct 2000 23:31:52 GMT Received: by mail-control.mail.uu.net id QQjjfq19891 for mpls-outgoing; Mon, 2 Oct 2000 23:31:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjfq19882 for ; Mon, 2 Oct 2000 23:31:21 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.40]) id QQjjfq11291 for ; Mon, 2 Oct 2000 19:31:16 -0400 (EDT) Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjjfq15923 for ; Mon, 2 Oct 2000 23:31:15 GMT Received: from oleary-lt (pfleger-lt1.jnpr.net [172.24.249.32] (may be forged)) by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA14414; Mon, 2 Oct 2000 16:30:54 -0700 (PDT) Message-Id: <4.2.0.58.20001002162745.02264680@garnet.juniper.net> X-Sender: doleary@garnet.juniper.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 02 Oct 2000 16:34:01 -0700 To: "David Allan" , Juan Diego Otero , mpls@UU.NET From: "dave o'leary" Subject: RE: MPLS and fast reroute. In-Reply-To: <6DDA62170439D31185750000F80826AC02C36DB7@zmerd004.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA15731 At 08:05 AM 6/8/00 -0500, David Allan wrote: >IMHO only in a simple case "look thog, fiber go dark", which can only deal >with gross physical defects, and I have predefined recovery strategies >(such as the virtual ring proposals the group has entertained). > >Dave The general consensus (as far as I could read it) at the Barcelona OIF meeting in August is that the variations between different optical vendor equipment in terms of ability to recognize and report "faults" is so wide that at this point it only makes sense to start with a least common denominator (like a binary "up/down", as Tony suggests), since there is easy path toward richer signalling at this point. I've certainly been known to misread the group, and I recognize that this is an IETF rather than an OIF list, and there is enough common membership and optical clues lying around here that if I have mischaracterized the situation, it would be great if someone could enlighten me / us. thanks, dave >-----Original Message----- From: Juan Diego Otero >[SMTP:jote4102@alu-etsetb.upc.es] Sent: Thursday, June 08, 2000 6:20 >AM To: mpls@UU.NET Subject: MPLS and fast reroute. > >Hi, > >In IEEE Communications Magazine (December 1999), there is an >article written by Tony Li called "MPLS and the Evolving Internet >Architecture". In page 41, talking about fast reroute, Tony says: >"...MPLS can also be used in a manner very similar to synchronous optical >network (SONET), where no signaling is necessary to perform the >protection switching of the LSP. This results in restoration times >competitive with SONET." My question is: > >Can anybody explain me how MPLS can be used as SONET in switching a LSP >after a faliure, with no signaling? > >Thanks a lot. > >Diego Otero UPC (Universitat Politècnica de Catalunya) From owner-mpls@UU.NET Mon Oct 2 21:39:47 2000 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17794 for ; Mon, 2 Oct 2000 21:39:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjfy05136; Tue, 3 Oct 2000 01:35:20 GMT Received: by mail-control.mail.uu.net id QQjjfy23321 for mpls-outgoing; Tue, 3 Oct 2000 01:34:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjfy23315 for ; Tue, 3 Oct 2000 01:34:55 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.40]) id QQjjfy23280 for ; Mon, 2 Oct 2000 21:34:47 -0400 (EDT) Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjfy26935 for ; Tue, 3 Oct 2000 01:34:47 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA00306 for mpls@uu.net; Mon, 2 Oct 2000 21:34:46 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjfy23259 for ; Tue, 3 Oct 2000 01:33:55 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.40]) id QQjjfy23220 for ; Mon, 2 Oct 2000 21:33:37 -0400 (EDT) Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjjfy25375 for ; Tue, 3 Oct 2000 01:33:37 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id SAA06454 for ; Mon, 2 Oct 2000 18:33:35 -0700 (PDT) Message-ID: <39D9376F.46CF2514@pluris.com> Date: Mon, 02 Oct 2000 18:33:35 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET Subject: ERO List with numbered and unnumbered interfaces Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit When filling in the ERO, there are three options: 1) Put in the router ID of the routers. This does not work for cases when routers have multiple links and for unnumbered interfaces. 2) Put in the egress interface of the routers on the path and finish it with the router ID of the final router. So that from router A to router B, we represent the hop as the IP address/interface index of the interface from A to B on router A. 3) Put in the ingress interface of the routers on the path starting with the router ID of ingress and finishing with the router ID of the egress LSRs. This is kind of opposite of (2). I believe that (2) is the only option that works with unnumbered interfaces. Does anyone think otherwise? Bora From owner-mpls@UU.NET Tue Oct 3 09:55:42 2000 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11494 for ; Tue, 3 Oct 2000 09:55:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjhv09233; Tue, 3 Oct 2000 13:51:00 GMT Received: by mail-control.mail.uu.net id QQjjhv12934 for mpls-outgoing; Tue, 3 Oct 2000 13:50:21 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjhv12926 for ; Tue, 3 Oct 2000 13:50:10 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.39]) id QQjjhv04534 for ; Tue, 3 Oct 2000 09:50:04 -0400 (EDT) Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjjhv07775 for ; Tue, 3 Oct 2000 13:50:03 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e93DnT405980; Tue, 3 Oct 2000 09:49:30 -0400 (EDT) Message-Id: <200010031349.e93DnT405980@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: Bora Akyol cc: mpls@UU.NET Subject: Re: ERO List with numbered and unnumbered interfaces In-reply-to: Your message of "Mon, 02 Oct 2000 18:33:35 PDT." <39D9376F.46CF2514@pluris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Oct 2000 09:49:29 -0400 Sender: owner-mpls@UU.NET Precedence: bulk Bora, > When filling in the ERO, there are three options: > > 1) Put in the router ID of the routers. This does not work for cases > when routers have multiple links and for unnumbered interfaces. > > 2) Put in the egress interface of the routers on the path and finish it > with the router ID of the final router. So that from router A to router > B, we represent the hop as the IP address/interface index of the > interface from A to B on router A. > > 3) Put in the ingress interface of the routers on the path starting with > the router ID of ingress and finishing with the router ID of the egress > LSRs. This is kind of opposite of (2). > > I believe that (2) is the only option that works with unnumbered > interfaces. > > Does anyone think otherwise? your option (1) will work when you only have a single link (which may be unnumbered) between the routers. Using router IDs in the ERO may also be useful in the presence of multiple links when you don't care which of the multiple links between a pair of routers will be used. I'm kind of confused about your option (2). Have you read draft-kompella-mpls-unnum or are you trying to reinvent it here? Markus From owner-mpls@UU.NET Tue Oct 3 10:55:25 2000 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13282 for ; Tue, 3 Oct 2000 10:55:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjhz22270; Tue, 3 Oct 2000 14:46:30 GMT Received: by mail-control.mail.uu.net id QQjjhz28534 for mpls-outgoing; Tue, 3 Oct 2000 14:45:41 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjhz28525 for ; Tue, 3 Oct 2000 14:45:32 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjhz13499 for ; Tue, 3 Oct 2000 10:45:24 -0400 (EDT) Received: from smtp4.cluster.oleane.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62]) id QQjjhz10083 for ; Tue, 3 Oct 2000 14:45:07 GMT Received: from oleane (dyn-1-1-205.Vin.dialup.oleane.fr [195.25.4.205]) by smtp4.cluster.oleane.net with SMTP id QAA78200 for ; Tue, 3 Oct 2000 16:44:58 +0200 (CEST) Message-ID: <007301c02d48$58ea01c0$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World 2001 Date: Tue, 3 Oct 2000 16:43:48 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01C02D59.1A48ECE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0070_01C02D59.1A48ECE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MPLS World 2001, Paris 6-9 February:=20 please remind that the pre-registration dead line is on October 15th http://www.upperside.fr/congress/congress.htm =20 ------=_NextPart_000_0070_01C02D59.1A48ECE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
MPLS World 2001, Paris 6-9 February: =
please remind that the = pre-registration dead=20 line is on October 15th
http://www.uppersi= de.fr/congress/congress.htm
 
------=_NextPart_000_0070_01C02D59.1A48ECE0-- From owner-mpls@UU.NET Tue Oct 3 13:39:57 2000 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19328 for ; Tue, 3 Oct 2000 13:39:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjik14335; Tue, 3 Oct 2000 17:36:05 GMT Received: by mail-control.mail.uu.net id QQjjik18586 for mpls-outgoing; Tue, 3 Oct 2000 17:35:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjik18576 for ; Tue, 3 Oct 2000 17:35:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjik10146 for ; Tue, 3 Oct 2000 13:35:16 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjik18927 for ; Tue, 3 Oct 2000 17:35:00 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA08994 for mpls@uu.net; Tue, 3 Oct 2000 13:34:59 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjik18495 for ; Tue, 3 Oct 2000 17:34:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjik09975 for ; Tue, 3 Oct 2000 13:33:54 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjjik18581 for ; Tue, 3 Oct 2000 17:33:54 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA23358; Tue, 3 Oct 2000 10:33:53 -0700 (PDT) Message-ID: <39DA1880.B9C7766C@pluris.com> Date: Tue, 03 Oct 2000 10:33:52 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 CC: mpls@UU.NET, kireeti@juniper.net Subject: Re: ERO List with numbered and unnumbered interfaces References: <200010031349.e93DnT405980@mailhost.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Markus Jork wrote: > Bora, > > > When filling in the ERO, there are three options: > > > > 1) Put in the router ID of the routers. This does not work for cases > > when routers have multiple links and for unnumbered interfaces. > > > > 2) Put in the egress interface of the routers on the path and finish it > > with the router ID of the final router. So that from router A to router > > B, we represent the hop as the IP address/interface index of the > > interface from A to B on router A. > > > > 3) Put in the ingress interface of the routers on the path starting with > > the router ID of ingress and finishing with the router ID of the egress > > LSRs. This is kind of opposite of (2). > > > > I believe that (2) is the only option that works with unnumbered > > interfaces. > > > > Does anyone think otherwise? > > your option (1) will work when you only have a single link (which may > be unnumbered) between the routers. Using router IDs in the > ERO may also be useful in the presence of multiple links when you > don't care which of the multiple links between a pair of routers will > be used. > Thanks for pointing out the obvious which I have already stated in my previous email. Next time, you may want to actually read the message before jumping on the trigger ;-) > > I'm kind of confused about your option (2). Have you read > draft-kompella-mpls-unnum or are you trying to reinvent it here? > Yes, and this is exactly why I think only option (2) would work, since only the local router has information about its ifindex to interface mapping. Bora From owner-mpls@UU.NET Tue Oct 3 14:20:33 2000 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20335 for ; Tue, 3 Oct 2000 14:20:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjhz07837; Tue, 3 Oct 2000 14:55:17 GMT Received: by mail-control.mail.uu.net id QQjjhz29373 for mpls-outgoing; Tue, 3 Oct 2000 14:54:46 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjhz29362 for ; Tue, 3 Oct 2000 14:54:35 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.40]) id QQjjhz14856 for ; Tue, 3 Oct 2000 10:54:27 -0400 (EDT) From: Vishal.Sharma@tellabs.com Received: from mx2.tellabs.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQjjhz02567 for ; Tue, 3 Oct 2000 14:54:26 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id JAA03583; Tue, 3 Oct 2000 09:53:00 -0500 (CDT) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA29972; Tue, 3 Oct 2000 09:54:24 -0500 (CDT) X-OpenMail-Hops: 1 Date: Tue, 3 Oct 2000 09:54:23 -0500 Message-Id: Subject: RE: draft-kompella-mpls-bundle-03.txt MIME-Version: 1.0 TO: braja@tellium.com, yakov@cisco.com CC: kireeti@juniper.net, lberger@labn.net, mpls@UU.NET, swallow@cisco.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 3 Oct 2000 09:54:23 -0500" Sender: owner-mpls@UU.NET Precedence: bulk I second this proposal. I think it would be worthwhile for the WG to focus a little bit more on the bundling issue. -Vishal > -----Original Message----- > From: braja@tellium.com [mailto:braja@tellium.com] > Sent: Monday, October 02, 2000 11:08 AM > To: yakov@cisco.com > Cc: mpls@UU.NET; swallow@cisco.com; kireeti@juniper.net; > lberger@labn.net > Subject: Re: draft-kompella-mpls-bundle-03.txt > > > Hello, > > Debanjan Saha and myself are submitting > a revised version of our bundling draft, > draft-rs-optical-bundling-01.txt. > I would like a discussion of this draft in the working group > prior to deciding whether draft-kompella-mpls-bundle-03.txt > should be a working group draft. > > Regards, > > Bala > > Yakov Rekhter wrote: > > > Folks, > > > > Kireeti, Lou, and myself would like to ask the MPLS WG to accept > > draft-kompella-mpls-bundle-03.txt as an MPLS WG document. > > > > Yakov. > > > > ------- Forwarded Message > > > > Date: Mon, 02 Oct 2000 06:51:59 -0400 > > From: Internet-Drafts@ietf.org > > To: IETF-Announce: ; > > Subject: I-D ACTION:draft-kompella-mpls-bundle-03.txt > > > > - --NextPart > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > Title : Link Bundling in MPLS Traffic Engineering > > Author(s) : K. Kompella, Y. Rekhter, L. Berger > > Filename : draft-kompella-mpls-bundle-03.txt > > Pages : 10 > > Date : 29-Sep-00 > > > > In some cases a pair of Label Switching Routers (LSRs) may be > > connected by several (parallel) links. From the MPLS Traffic > > Engineering point of view for reasons of scalability it may be > > desirable to advertise all these links as a single link into OSPF > > and/or IS-IS. This document describes how to accomplish this. This > > document also defines corresponding signaling (RSVP-TE) support. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-kompella-mpls-bundle-03.txt > > > > 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-kompella-mpls-bundle-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-kompella-mpls-bundle-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: <20000929074304.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-kompella-mpls-bundle-03.txt > > > > - --OtherAccess > > Content-Type: Message/External-body; > > name="draft-kompella-mpls-bundle-03.txt"; > > site="ftp.ietf.org"; > > access-type="anon-ftp"; > > directory="internet-drafts" > > > > Content-Type: text/plain > > Content-ID: <20000929074304.I-D@ietf.org> > > > > - --OtherAccess-- > > > > - --NextPart-- > > > > ------- End of Forwarded Message > > -- > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > From owner-mpls@UU.NET Tue Oct 3 14:29:28 2000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20495 for ; Tue, 3 Oct 2000 14:29:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjin00841; Tue, 3 Oct 2000 18:25:08 GMT Received: by mail-control.mail.uu.net id QQjjin05531 for mpls-outgoing; Tue, 3 Oct 2000 18:24:44 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjin05513 for ; Tue, 3 Oct 2000 18:24:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjin23148 for ; Tue, 3 Oct 2000 14:23:05 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjin01401 for ; Tue, 3 Oct 2000 18:23:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA16412 for mpls@uu.net; Tue, 3 Oct 2000 14:23:04 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjin05346 for ; Tue, 3 Oct 2000 18:22:17 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.39]) id QQjjin10624 for ; Tue, 3 Oct 2000 18:22:01 GMT Received: from ertpg14e1.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35]) id QQjjin05204 for ; Tue, 3 Oct 2000 18:22:01 GMT Received: from zcard00m.ca.nortel.com by ertpg14e1.nortelnetworks.com; Tue, 3 Oct 2000 12:58:00 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 41VMLLJ8; Tue, 3 Oct 2000 12:57:52 -0400 Received: from nortelnetworks.com (dhcp220-148.engeast.baynetworks.com [192.32.220.148]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TW4RJ8XA; Tue, 3 Oct 2000 12:57:52 -0400 Message-ID: <39DA0F41.4ABFE026@nortelnetworks.com> Date: Tue, 03 Oct 2000 12:54:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Dave Wilder" Reply-To: "Dave Wilder" Organization: Nortel Networks X-Mailer: Mozilla 4.5 [en]C-3M;VANGRD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Info on Extensions to OSPF and ISIS for Traffic Engineering Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, If my memory serves me correctly, a draft(s) was recently updated concerning extensions to OSPF and IS-IS for Traffic Engineering. I have been unable to locate these drafts. Would someone point me in the right direction as to where I could find them? Thanks, Dave Wilder From owner-mpls@UU.NET Tue Oct 3 14:47:07 2000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20874 for ; Tue, 3 Oct 2000 14:47:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjio23986; Tue, 3 Oct 2000 18:43:00 GMT Received: by mail-control.mail.uu.net id QQjjio06947 for mpls-outgoing; Tue, 3 Oct 2000 18:42:32 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjio06936 for ; Tue, 3 Oct 2000 18:42:24 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.38]) id QQjjio27219 for ; Tue, 3 Oct 2000 18:42:16 GMT Received: from hatl0s02.cci.cox.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: user1.cox.com [206.98.143.250]) id QQjjio23004 for ; Tue, 3 Oct 2000 18:42:15 GMT Received: by hatl0s02.cci.cox.com with Internet Mail Service (5.5.2650.21) id <41XCS6FQ>; Tue, 3 Oct 2000 14:43:33 -0400 Message-ID: <2F6E09459060D21196A60000F654A23405016C3F@cwwk0s04.cci.cox.com> From: "Osteen, Rick (CCI-Warwick)" To: "'mpls@UU.NET'" Subject: MPLS shim header Date: Tue, 3 Oct 2000 14:42:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Can someone direct me to the document that gives more detail regarding "MPLS shim header"? Thanks, Rick Osteen New England Data Engineering Manager Cox Communications - New England 401-821-1919 ext 2250 From owner-mpls@UU.NET Tue Oct 3 15:15:40 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21353 for ; Tue, 3 Oct 2000 15:15:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjir10039; Tue, 3 Oct 2000 19:15:05 GMT Received: by mail-control.mail.uu.net id QQjjiq21452 for mpls-outgoing; Tue, 3 Oct 2000 19:14:46 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjiq21439 for ; Tue, 3 Oct 2000 19:14:35 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.39]) id QQjjiq07212 for ; Tue, 3 Oct 2000 19:12:30 GMT Received: from jumpstart.maplenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: w082.z216112072.sjc-ca.dsl.cnc.net [216.112.72.82]) id QQjjiq11592 for ; Tue, 3 Oct 2000 19:12:29 GMT Received: from maplenetworks.com (shasta [192.168.10.215]) by jumpstart.maplenetworks.com (8.11.0/8.11.0) with ESMTP id e93IvYT10010; Tue, 3 Oct 2000 11:57:34 -0700 (PDT) Message-ID: <39DA2C1B.7126AD39@maplenetworks.com> Date: Tue, 03 Oct 2000 11:57:31 -0700 From: Mohammad Hanif Organization: Maple Optical Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Osteen, Rick (CCI-Warwick)" CC: "'mpls@UU.NET'" Subject: Re: MPLS shim header References: <2F6E09459060D21196A60000F654A23405016C3F@cwwk0s04.cci.cox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Try this: http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-08.txt --Hanif. "Osteen, Rick (CCI-Warwick)" wrote: > Can someone direct me to the document that gives more detail regarding "MPLS > shim header"? > Thanks, > > Rick Osteen > New England Data Engineering Manager > Cox Communications - New England > 401-821-1919 ext 2250 From owner-mpls@UU.NET Tue Oct 3 16:55:17 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23148 for ; Tue, 3 Oct 2000 16:55:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjix05112; Tue, 3 Oct 2000 20:54:37 GMT Received: by mail-control.mail.uu.net id QQjjix10484 for mpls-outgoing; Tue, 3 Oct 2000 20:54:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjix10479 for ; Tue, 3 Oct 2000 20:54:01 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.38]) id QQjjix22351 for ; Tue, 3 Oct 2000 16:53:58 -0400 (EDT) Received: from server.nayna.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) id QQjjix13204 for ; Tue, 3 Oct 2000 20:53:58 GMT Received: from nayna.com (sonicwall [64.145.162.226]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA20312; Tue, 3 Oct 2000 13:44:04 -0700 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be nayna.com Message-ID: <39DA2B80.D090B5CE@nayna.com> Date: Tue, 03 Oct 2000 13:54:56 -0500 From: Sudheer Dharanikota X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Wilder CC: mpls@UU.NET Subject: Re: Info on Extensions to OSPF and ISIS for Traffic Engineering References: <39DA0F41.4ABFE026@nortelnetworks.com> Content-Type: multipart/mixed; boundary="------------468E7D133CB487D168423361" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------468E7D133CB487D168423361 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The following two discuss the extensions to OSPF and ISIS for inter-area. http://search.ietf.org/internet-drafts/draft-venkatachalam-interarea-mpls-te-00.txt http://search.ietf.org/internet-drafts/draft-dharanikota-interarea-mpls-te-ext-00.txt sudheer Dave Wilder wrote: > > Hi, > > If my memory serves me correctly, a draft(s) was recently updated > concerning extensions to OSPF and IS-IS for Traffic Engineering. I have > been unable to locate these drafts. Would someone point me in the right > direction as to where I could find them? > > Thanks, > > Dave Wilder --------------468E7D133CB487D168423361 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dharanikota;Sudheer tel;cell:408-829-8812 tel;work:408-956-8000 X357 x-mozilla-html:TRUE org:Nayna Networks adr:;;;;;; version:2.1 email;internet:sudheer@nayna.com fn:Sudheer Dharanikota end:vcard --------------468E7D133CB487D168423361-- From owner-mpls@UU.NET Tue Oct 3 17:17:26 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23454 for ; Tue, 3 Oct 2000 17:17:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjiz09492; Tue, 3 Oct 2000 21:16:52 GMT Received: by mail-control.mail.uu.net id QQjjiz23967 for mpls-outgoing; Tue, 3 Oct 2000 21:16:27 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjiz23940 for ; Tue, 3 Oct 2000 21:16:16 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.38]) id QQjjiz25799 for ; Tue, 3 Oct 2000 17:15:57 -0400 (EDT) Received: from bgslc02.TBG.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQjjiz13228 for ; Tue, 3 Oct 2000 21:15:57 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id <41DPCBPD>; Tue, 3 Oct 2000 15:00:57 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE7BAEAD4@BGSLC02> From: Irwin Lazar To: Dave Wilder Cc: mpls@UU.NET Subject: RE: Info on Extensions to OSPF and ISIS for Traffic Engineering Date: Tue, 3 Oct 2000 15:00:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Hi, > > If my memory serves me correctly, a draft(s) was recently updated > concerning extensions to OSPF and IS-IS for Traffic Engineering. I have > been unable to locate these drafts. Would someone point me in the right > direction as to where I could find them? > > Thanks, > > Dave Wilder Dave, We maintain a fairly currrent catagorized collection of links to MPLS-related internet drafts at http://www.mplsrc.com/drafts.shtml I believe the one you are referring to is: http://www.ietf.org/internet-drafts/draft-dharanikota-interarea-mpls-te-ext- 00.txt Irwin From owner-mpls@UU.NET Wed Oct 4 00:08:26 2000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28994 for ; Wed, 4 Oct 2000 00:08:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjka24524; Wed, 4 Oct 2000 04:04:27 GMT Received: by mail-control.mail.uu.net id QQjjka07823 for mpls-outgoing; Wed, 4 Oct 2000 04:03:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjka07774 for ; Wed, 4 Oct 2000 04:03:46 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjka03819 for ; Wed, 4 Oct 2000 00:03:44 -0400 (EDT) Received: from ucayali.unired.net.pe by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ucayali.unired.net.pe [206.138.105.38]) id QQjjka15008 for ; Wed, 4 Oct 2000 04:03:41 GMT Received: from telefonica.com.pe ([200.37.84.140]) by ucayali.unired.net.pe (8.10.0.Beta10/8.10.0.Beta10) with ESMTP id e93I1K407537; Tue, 3 Oct 2000 23:01:21 +0500 (GMT) Message-ID: <39DAAAFF.E8A8375@telefonica.com.pe> Date: Tue, 03 Oct 2000 22:58:55 -0500 From: Jesus Rodriguez Stuart X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Metz, E.T." CC: "'GUESDON Herve FTRD/DAC/ISS'" , "'S.Matsushima'" , erosen@cisco.com, mpls@UU.NET Subject: MPLS/BGP VPNs - Bandwith Reservation References: <59063B5B4D98D311BC0D0001FA7E45220316A4F1@l04.research.kpn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sirs Question in MPLS/BGP VPN context:: If I have 2 PEs with 10 CEs in one of them and 20 in the other. All of CEs belong to a same IP-VPN. How can I Reserve Bandwith between the two PEs for this IP-VPN, also How can I reserve Bandwith for diferent class of service (Premium, Standard) between the PEs for the IP-VPN. The same question If we have many VPNs . Thanks in advance JRSTUART Jesus Rodriguez Stuart Network Planning Telefonica del Peru 51-1-2104835 From owner-mpls@UU.NET Wed Oct 4 03:36:34 2000 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13133 for ; Wed, 4 Oct 2000 03:36:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjko18756; Wed, 4 Oct 2000 07:31:34 GMT Received: by mail-control.mail.uu.net id QQjjko23523 for mpls-outgoing; Wed, 4 Oct 2000 07:31:07 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjko23496 for ; Wed, 4 Oct 2000 07:31:03 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjko23647 for ; Wed, 4 Oct 2000 03:31:02 -0400 (EDT) Received: from hermes.research.kpn.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjjko17712 for ; Wed, 4 Oct 2000 07:30:31 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JUXNJ0IB6O000M2Q@research.kpn.com> for mpls@UU.NET; Wed, 4 Oct 2000 09:30:30 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Wed, 04 Oct 2000 09:30:28 +0100 Content-return: allowed Date: Wed, 04 Oct 2000 09:30:23 +0100 From: "Metz, E.T." Subject: RE: MPLS/BGP VPNs - Bandwith Reservation To: "'Jesus Rodriguez Stuart'" Cc: "'GUESDON Herve FTRD/DAC/ISS'" , "'S.Matsushima'" , erosen@cisco.com, mpls@UU.NET Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A4FC@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk To reserve bandwidth between the CEs in the VPN you could create a TE path (with BW resv) between the interfaces that are used for the iBGP session between the PE, probably some logical interface in the routers (e.g. the loopback). This will cause the VPN traffic to be routed over the TE path. However, this applies to all VPN traffic between these PEs, so it is not exclusive to a particular VPN. Even regular IPv4 traffic with the same BGP next-hop will go over this TE path. If you have multiple classess, I assume you mean a DIFFSERV alike situation. First of all you should mark the VPN traffic according to these classes. To reserve BW for eahc class, probably a TE path needs to be established between the PEs for each class. To map the traffic to the right TE LSP, the FEC should include the DIFFSERV class (encoded in the EXP field of the MPLS header). Hope this helps. cheers, Eduard > -----Original Message----- > From: Jesus Rodriguez Stuart [mailto:jrstuart@telefonica.com.pe] > Sent: woensdag 4 oktober 2000 4:59 > To: Metz, E.T. > Cc: 'GUESDON Herve FTRD/DAC/ISS'; 'S.Matsushima'; erosen@cisco.com; > mpls@UU.NET > Subject: MPLS/BGP VPNs - Bandwith Reservation > > > > Sirs > > Question in MPLS/BGP VPN context:: > If I have 2 PEs with 10 CEs in one of them and 20 in the > other. All of CEs > belong to a same IP-VPN. How can I Reserve Bandwith between > the two PEs for > this IP-VPN, also How can I reserve Bandwith for diferent > class of service > (Premium, Standard) between the PEs for the IP-VPN. > The same question If we have many VPNs . > > Thanks in advance > > JRSTUART > Jesus Rodriguez Stuart > Network Planning > Telefonica del Peru > 51-1-2104835 > > > From owner-mpls@UU.NET Wed Oct 4 04:47:06 2000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13776 for ; Wed, 4 Oct 2000 04:47:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjks15659; Wed, 4 Oct 2000 08:42:45 GMT Received: by mail-control.mail.uu.net id QQjjks08673 for mpls-outgoing; Wed, 4 Oct 2000 08:42:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjks08668 for ; Wed, 4 Oct 2000 08:42:15 GMT Received: from cmr0.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.38]) id QQjjks29853 for ; Wed, 4 Oct 2000 04:42:09 -0400 (EDT) Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjjks14809 for ; Wed, 4 Oct 2000 08:42:05 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA15055; Wed, 4 Oct 2000 14:10:38 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA26099; Wed, 4 Oct 2000 14:11:21 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Wed, 4 Oct 2000 14:11:21 +0530 (IST) From: Ramanjaneyulu Y T To: "Osteen, Rick (CCI-Warwick)" cc: "'mpls@UU.NET'" Subject: Re: MPLS shim header In-Reply-To: <2F6E09459060D21196A60000F654A23405016C3F@cwwk0s04.cci.cox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, pls refer a draft "draft-ietf-mpls-arch-07.txt" in page 25. Regards Ramanjaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ------------------------------------------------------------------------------ Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@123india.com BANGALORE - 560012 | kingytr@excite.com PH: 0091 - 080 - 3092622 ( HOSTEL ) | 0091 - 080 - 3092568 ( HFCL LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- On Tue, 3 Oct 2000, Osteen, Rick (CCI-Warwick) wrote: > Can someone direct me to the document that gives more detail regarding "MPLS > shim header"? > Thanks, > > Rick Osteen > New England Data Engineering Manager > Cox Communications - New England > 401-821-1919 ext 2250 > > From owner-mpls@UU.NET Wed Oct 4 04:55:51 2000 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13827 for ; Wed, 4 Oct 2000 04:55:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjkt19360; Wed, 4 Oct 2000 08:50:46 GMT Received: by mail-control.mail.uu.net id QQjjkt09158 for mpls-outgoing; Wed, 4 Oct 2000 08:50:27 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjkt09151 for ; Wed, 4 Oct 2000 08:50:18 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.38]) id QQjjkt24654 for ; Wed, 4 Oct 2000 08:49:11 GMT From: weng.qing@mail.zte.com.cn Received: from mail.zhongxing.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.103.147.133]) id QQjjkt23160 for ; Wed, 4 Oct 2000 08:49:10 GMT Received: by mail.zhongxing.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 4825696E.00301FEB ; Wed, 4 Oct 2000 16:45:38 +0800 X-Lotus-FromDomain: ZTE_LTD To: mpls@UU.NET Message-ID: <4825696E.00301E8B.00@mail.zhongxing.com> Date: Wed, 4 Oct 2000 16:50:09 +0800 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi,all I am involved to implement MPLS Diffserv extention over ATM Switch, I choose L-LSP,Pipe Tunnel to implement. But I am not sure about: 1)According to draft-ietf-mpls-diff-ext-07.txt,we choose CR-LDP to implement; I think,at each MPLS Edge LSR,configure service bandwidth of each supported DSCP on every SB(Service Board), when setup CR-LSP,Label-Request message include DS TLV and Traffic TLV(imply if CR-LDP Label-Request message includes DS TLV,it must include Traffic TLV.Is this applicable?) but Traffic TLV currently doesn't define how to map ATM ABR Service Type to Traffic TLV 's five parameters; Is this idea applicable? If it is, but what does this mean" - the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (eg bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13)"(from draft-ietf-mpls-diff-ext-07.txt Scenario 4) How to deal with CS PHB? 2)Which MIB(s) to implement or extend? And how? Thanks ChingWeng 2000/10/04 From owner-mpls@UU.NET Wed Oct 4 10:34:19 2000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21363 for ; Wed, 4 Oct 2000 10:34:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjlp06643; Wed, 4 Oct 2000 14:29:20 GMT Received: by mail-control.mail.uu.net id QQjjlp08785 for mpls-outgoing; Wed, 4 Oct 2000 14:29:01 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjlp08765 for ; Wed, 4 Oct 2000 14:28:52 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.39]) id QQjjlp26300 for ; Wed, 4 Oct 2000 14:28:32 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjjlp24063 for ; Wed, 4 Oct 2000 14:28:32 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA24529 for ; Wed, 4 Oct 2000 07:28:57 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA25992 for mpls@uu.net; Wed, 4 Oct 2000 10:28:30 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjjy25063 for ; Wed, 4 Oct 2000 03:33:13 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.39]) id QQjjjy27683 for ; Wed, 4 Oct 2000 03:32:30 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f290.law3.hotmail.com [209.185.240.84]) id QQjjjy05358 for ; Wed, 4 Oct 2000 03:32:29 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Oct 2000 20:32:28 -0700 Received: from 156.26.35.161 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 04 Oct 2000 03:32:28 GMT X-Originating-IP: [156.26.35.161] From: "Amzad Hossain Chowdhury" To: J.Hopkins@fujitsu.co.uk Cc: yakov@cisco.com, drake@fore.com Date: Tue, 03 Oct 2000 22:32:28 CDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Oct 2000 03:32:28.0933 (UTC) FILETIME=[B8CECB50:01C02DB3] Sender: owner-mpls@UU.NET Precedence: bulk Hi I am doing project on multiprotocol lamda switching . I am not getting enough information about . If yu can pls give me some information that I can proceed . Thanks Amzad Wichita st Univ. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Wed Oct 4 10:39:46 2000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21466 for ; Wed, 4 Oct 2000 10:39:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjlq13211; Wed, 4 Oct 2000 14:34:15 GMT Received: by mail-control.mail.uu.net id QQjjlq09219 for mpls-outgoing; Wed, 4 Oct 2000 14:33:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjlq09193 for ; Wed, 4 Oct 2000 14:33:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjlq16543 for ; Wed, 4 Oct 2000 10:33:19 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjjlq18789 for ; Wed, 4 Oct 2000 14:32:48 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id e94EWF415549; Wed, 4 Oct 2000 10:32:15 -0400 (EDT) Message-Id: <200010041432.e94EWF415549@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: Bora Akyol cc: mpls@UU.NET Subject: Re: ERO List with numbered and unnumbered interfaces In-reply-to: Your message of "Tue, 03 Oct 2000 10:33:52 PDT." <39DA1880.B9C7766C@pluris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Oct 2000 10:32:15 -0400 Sender: owner-mpls@UU.NET Precedence: bulk Bora, > > your option (1) will work when you only have a single link (which may > > be unnumbered) between the routers. Using router IDs in the > > ERO may also be useful in the presence of multiple links when you > > don't care which of the multiple links between a pair of routers will > > be used. > > > > Thanks for pointing out the obvious which I have already stated in my previous > email. Next time, you may want to actually read the message before jumping on > the trigger ;-) Yes, one of us should have read your previous message more thoroughly :-) I'm sure you knew all this but you did write just the opposite in your message, namely that option (1) does *not* work with unnumbered links: > 1) Put in the router ID of the routers. This does not work for cases > when routers have multiple links and for unnumbered interfaces. This is why I felt compelled to state the obvious... Markus From owner-mpls@UU.NET Wed Oct 4 12:11:13 2000 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24667 for ; Wed, 4 Oct 2000 12:11:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjlw12600; Wed, 4 Oct 2000 16:07:40 GMT Received: by mail-control.mail.uu.net id QQjjlw13164 for mpls-outgoing; Wed, 4 Oct 2000 16:07:01 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjlw12996 for ; Wed, 4 Oct 2000 16:06:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjlw23415 for ; Wed, 4 Oct 2000 12:06:49 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjjlw07156 for ; Wed, 4 Oct 2000 16:06:48 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA13793 for ; Wed, 4 Oct 2000 09:07:13 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA26356 for mpls@uu.net; Wed, 4 Oct 2000 12:06:45 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjlt26578 for ; Wed, 4 Oct 2000 15:19:40 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjlt24767 for ; Wed, 4 Oct 2000 11:19:20 -0400 (EDT) From: r.rutigliano@ciaoweb.it Received: from ciaoweb.it by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [151.88.109.33]) id QQjjlt21173 for ; Wed, 4 Oct 2000 15:19:19 GMT Received: from ciaoweb.it ([151.88.109.38]) by ciaoweb.it with Microsoft SMTPSVC(5.5.1877.447.44); Wed, 4 Oct 2000 17:19:18 +0200 Received: from mail pickup service by ciaoweb.it with Microsoft SMTPSVC; Wed, 4 Oct 2000 17:19:19 +0200 Content-Class: urn:content-classes:message To: Subject: RIP TE Date: Wed, 4 Oct 2000 17:19:19 +0200 Message-ID: <914501c02e16$773e6570$266d5897@ciaoweb> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcAuFnc7VGPAY5oBEdSf+wBQi2cOVw== X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA24667 Hi all, I'm quite sure that this is a stupid question, but just to be sure, why does not exist any extension to RIP for traffic engineering? Thanx in advance. Roberto Rutigliano _________________________________________________________________________ Vuoi essere avvisato via SMS quando c'è posta per te ? Con l'email di Ciaoweb puoi: http://www.ciaoweb.it/email/r1.asp From owner-mpls@UU.NET Wed Oct 4 12:26:22 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25071 for ; Wed, 4 Oct 2000 12:26:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjlx13243; Wed, 4 Oct 2000 16:25:34 GMT Received: by mail-control.mail.uu.net id QQjjlx15507 for mpls-outgoing; Wed, 4 Oct 2000 16:25:03 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjlx15479 for ; Wed, 4 Oct 2000 16:24:55 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.40]) id QQjjlx25938 for ; Wed, 4 Oct 2000 12:24:42 -0400 (EDT) Received: from dnsmx1pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQjjlx05811 for ; Wed, 4 Oct 2000 16:24:41 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id MAA22699 for ; Wed, 4 Oct 2000 12:22:09 -0400 (EDT) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525696E.0059E925 ; Wed, 4 Oct 2000 12:22:03 -0400 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <8525696E.0059E7E1.00@notes949.cc.telcordia.com> Date: Wed, 4 Oct 2000 12:21:36 -0400 Subject: RSVP-TE: Error message to Hello Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello, On Rsvp-TE page 57, Section 5.5 Compatibility, it says that "Depending on the implementation, implementations that do not support the extension will either silently discard Hello messages or will response with an "Unknown Object Class" error." Hello message -------> LSR(implemented not supporting Hello extension) <------- no response(discard hello message) OR response with an "Unknown object class" error so my questions, is this error message put in PathErr message? Since there is not one individual error message for Hello message. Thanks in advance. Julia From owner-mpls@UU.NET Wed Oct 4 13:11:29 2000 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26382 for ; Wed, 4 Oct 2000 13:11:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjma03648; Wed, 4 Oct 2000 17:07:19 GMT Received: by mail-control.mail.uu.net id QQjjma00870 for mpls-outgoing; Wed, 4 Oct 2000 17:06:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjma00857 for ; Wed, 4 Oct 2000 17:06:35 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.40]) id QQjjma00616 for ; Wed, 4 Oct 2000 17:06:05 GMT Received: from griffin.host4u.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQjjma01798 for ; Wed, 4 Oct 2000 17:06:05 GMT Received: from toy.labn.net (labn.net [209.204.240.82]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id MAA25646; Wed, 4 Oct 2000 12:00:05 -0500 Message-Id: <4.3.2.7.2.20001004130445.00ca4830@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Oct 2000 13:06:00 -0400 To: "Hong Liao" From: Lou Berger Subject: Re: RSVP-TE: Error message to Hello Cc: mpls@UU.NET, swallow@cisco.com In-Reply-To: <8525696E.0059E7E1.00@notes949.cc.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Good point. The clause "or will response with an "Unknown Object Class" error." should be dropped. Lou At 12:21 PM 10/4/00, Hong Liao wrote: >Hello, > >On Rsvp-TE page 57, Section 5.5 Compatibility, it says that "Depending on the >implementation, implementations that do not support the extension will either >silently discard Hello messages or will response with an "Unknown Object >Class" >error." > >Hello message -------> LSR(implemented not supporting Hello extension) > <------- no response(discard hello > message) >OR response with an "Unknown object class" error > >so my questions, is this error message put in PathErr message? Since there is >not one individual error message for Hello message. > >Thanks in advance. > >Julia From owner-mpls@UU.NET Wed Oct 4 13:24:32 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26771 for ; Wed, 4 Oct 2000 13:24:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjmb28422; Wed, 4 Oct 2000 17:23:19 GMT Received: by mail-control.mail.uu.net id QQjjmb02891 for mpls-outgoing; Wed, 4 Oct 2000 17:23:04 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjmb02876 for ; Wed, 4 Oct 2000 17:22:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjmb04352 for ; Wed, 4 Oct 2000 13:22:33 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjmb27149 for ; Wed, 4 Oct 2000 17:22:32 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA16605 for mpls@uu.net; Wed, 4 Oct 2000 13:22:31 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjmb02800 for ; Wed, 4 Oct 2000 17:21:53 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjmb14524 for ; Wed, 4 Oct 2000 13:21:49 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjjmb23397 for ; Wed, 4 Oct 2000 17:21:49 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 13:21:07 -0400 Message-ID: <87009604743AD411B1F600508BA0F9591ABE6A@xover.hjinc.com> From: "Kullberg, Alan" To: mpls@UU.NET Subject: unnum-02 comments Date: Wed, 4 Oct 2000 13:21:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I have read the latest Unumbered Links draft and have a question and some suggestions. From section 5, 2nd paragraph, If the LSP is bidirectional, and the tail-end LSR (of the forward LSP) advertises the reverse LSP as an unnumbered Forwarding Adjacency, the tail-end LSR MUST allocate an interface ID to the reverse Forwarding Adjacency. How does the tail-end LSR know that the bidirectional LSP is a FA-LSP so that the reverse interface ID will be assigned? In section 6.2, a comparison is made between the tuple and the tuple. CR-LDP does not have a TLV in the REQUEST message that carries the PHOP information. Actually, the Path Vector TLV carries the LSR ID of the previous hop. But is the LSR ID the same as the Router ID? If so, then the draft could mandate the inclusion of the PV TLV when sending a Request message containing an ER TLV with a 1st ER Hop of type Unnumbered Interface ID. Or should a new TLV be specified to carry the same information as the PHOP in RSVP? In section 5, CR-LDP needs a way to transmit the Reverse Interface ID in the MAPPING message. I took the liberty to suggest some text for section 5 that adds a new TLV to CR-LDP and specifies how to signal the information for CR-LDP. <<<<< and >>>>> surround new and changed parts of the text. ############################ start of changed section 5 5. Unnumbered Forwarding Adjacencies If an LSR that originates an LSP advertises this LSP as an unnumbered Forwarding Adjacency in IS-IS or OSPF [LSP-HIER], the LSR MUST allocate an interface ID to that Forwarding Adjacency. Moreover, the <<<<< Tunnel ID in the Session Object of the Path Message or the Local CR-LSP ID in the LSPID TLV of the Request Message for the LSP MUST be set to that interface ID, and the Extended Tunnel ID in the Session Object or the Ingress LSR Router ID in the LSPID TLV of the LSP MUST be set to the Router ID of the LSR that originates the LSP. >>>>> If the LSP is bidirectional, and the tail-end LSR (of the forward LSP) advertises the reverse LSP as an unnumbered Forwarding Adjacency, the tail-end LSR MUST allocate an interface ID to the <<<<< reverse Forwarding Adjacency. For RSVP, it MUST set the "Reverse >>>>> Interface ID" field in the Filter Specification object in the flow descriptor list for this LSP to the reverse FA's interface ID (note that while in general there can be multiple Filter Specifications, it is expected in the case of point-to-point LSPs that there is only one). To accommodate this, the LSP_TUNNEL_IPv4 Filter Specification Object's format is modified per Figure 1: Figure 1: LSP_TUNNEL_IPv4 Filter Specification Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse Interface ID | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> For CR-LDP, it MUST set the "Reverse Interface ID" field in the Reverse Interface ID TLV in the MAPPING message to the reverse FA's interface ID. The Reverse Interface ID's format is shown in Figure 2: Figure 2: Reverse Interface ID TLV in CR-LDP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Reverse Interface ID (16 bits)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type is TBD (Reverse Interface ID) and the Length is 4. >>>>> ############################ end of changed section 5 Note that all of the figure numbers following this (new) one must be adjusted. Thanks, Alan From owner-mpls@UU.NET Wed Oct 4 13:29:51 2000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26890 for ; Wed, 4 Oct 2000 13:29:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjmb08594; Wed, 4 Oct 2000 17:24:56 GMT Received: by mail-control.mail.uu.net id QQjjmb03056 for mpls-outgoing; Wed, 4 Oct 2000 17:24:36 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjmb03027 for ; Wed, 4 Oct 2000 17:24:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjmb04517 for ; Wed, 4 Oct 2000 13:24:10 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjmb29892 for ; Wed, 4 Oct 2000 17:24:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA16970 for mpls@uu.net; Wed, 4 Oct 2000 13:24:07 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjmb02921 for ; Wed, 4 Oct 2000 17:23:30 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjmb14787 for ; Wed, 4 Oct 2000 13:23:26 -0400 (EDT) Received: from che-cse-115.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.128.23]) id QQjjmb27757 for ; Wed, 4 Oct 2000 17:22:55 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id NAA05751; Wed, 4 Oct 2000 13:22:53 -0400 (EDT) Date: Wed, 4 Oct 2000 13:22:53 -0400 From: Eric Osborne To: r.rutigliano@ciaoweb.it Cc: mpls@UU.NET Subject: Re: RIP TE Message-ID: <20001004132253.A5744@che-cse-115.cisco.com> References: <914501c02e16$773e6570$266d5897@ciaoweb> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <914501c02e16$773e6570$266d5897@ciaoweb>; from r.rutigliano@ciaoweb.it on Wed, Oct 04, 2000 at 05:19:19PM +0200 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQjjmb08594 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26890 On Wed, Oct 04, 2000 at 05:19:19PM +0200, r.rutigliano@ciaoweb.it wrote: > Hi all, > I'm quite sure that this is a stupid question, but just to > be sure, why does not exist any extension to RIP for traffic > engineering? Becuase in order to do TE you need to have a picture of what the whole network looks like, which means you need a link-state protocol like IS-IS and OSPF. Otherwise, you start talking about TE protocols that look a lot like PNNI....:) eric > > Thanx in advance. > > Roberto Rutigliano > _________________________________________________________________________ > Vuoi essere avvisato via SMS quando c'è posta per te ? > Con l'email di Ciaoweb puoi: http://www.ciaoweb.it/email/r1.asp From owner-mpls@UU.NET Wed Oct 4 14:01:24 2000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27457 for ; Wed, 4 Oct 2000 14:01:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjmd20026; Wed, 4 Oct 2000 17:56:52 GMT Received: by mail-control.mail.uu.net id QQjjmd06275 for mpls-outgoing; Wed, 4 Oct 2000 17:56:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjmd06269 for ; Wed, 4 Oct 2000 17:56:14 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjmd19918 for ; Wed, 4 Oct 2000 13:55:54 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjmd22151 for ; Wed, 4 Oct 2000 17:55:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA22667 for mpls@uu.net; Wed, 4 Oct 2000 13:55:38 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjmd06070 for ; Wed, 4 Oct 2000 17:53:51 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.39]) id QQjjmd08919 for ; Wed, 4 Oct 2000 13:53:32 -0400 (EDT) Received: from xover.hjinc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjjmd08622 for ; Wed, 4 Oct 2000 17:53:32 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 13:52:46 -0400 Message-ID: <87009604743AD411B1F600508BA0F9591ABE6C@xover.hjinc.com> From: "Kullberg, Alan" To: mpls@UU.NET Subject: unnum-02 comments - repost with fix Date: Wed, 4 Oct 2000 13:52:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I am reposting this message with an adjustment in the change delimiters since it was pointed out to me that there was a mismatch. ================================ I have read the latest Unumbered Links draft and have a question and some suggestions. From section 5, 2nd paragraph, If the LSP is bidirectional, and the tail-end LSR (of the forward LSP) advertises the reverse LSP as an unnumbered Forwarding Adjacency, the tail-end LSR MUST allocate an interface ID to the reverse Forwarding Adjacency. How does the tail-end LSR know that the bidirectional LSP is a FA-LSP so that the reverse interface ID will be assigned? In section 6.2, a comparison is made between the tuple and the tuple. CR-LDP does not have a TLV in the REQUEST message that carries the PHOP information. Actually, the Path Vector TLV carries the LSR ID of the previous hop. But is the LSR ID the same as the Router ID? If so, then the draft could mandate the inclusion of the PV TLV when sending a Request message containing an ER TLV with a 1st ER Hop of type Unnumbered Interface ID. Or should a new TLV be specified to carry the same information as the PHOP in RSVP? In section 5, CR-LDP needs a way to transmit the Reverse Interface ID in the MAPPING message. I took the liberty to suggest some text for section 5 that adds a new TLV to CR-LDP and specifies how to signal the information for CR-LDP. <<<<< and >>>>> surround new and changed parts of the text. ############################ start of changed section 5 5. Unnumbered Forwarding Adjacencies If an LSR that originates an LSP advertises this LSP as an unnumbered Forwarding Adjacency in IS-IS or OSPF [LSP-HIER], the LSR MUST allocate an interface ID to that Forwarding Adjacency. Moreover, the <<<<< Tunnel ID in the Session Object of the Path Message or the Local CR-LSP ID in the LSPID TLV of the Request Message for the LSP MUST be set to that interface ID, and the Extended Tunnel ID in the Session Object or the Ingress LSR Router ID in the LSPID TLV of the LSP MUST be set to the Router ID of the LSR that originates the LSP. >>>>> If the LSP is bidirectional, and the tail-end LSR (of the forward LSP) advertises the reverse LSP as an unnumbered Forwarding Adjacency, the tail-end LSR MUST allocate an interface ID to the <<<<< reverse Forwarding Adjacency. For RSVP, it MUST set the "Reverse >>>>> Interface ID" field in the Filter Specification object in the flow descriptor list for this LSP to the reverse FA's interface ID (note that while in general there can be multiple Filter Specifications, it is expected in the case of point-to-point LSPs that there is only one). To accommodate this, the LSP_TUNNEL_IPv4 Filter Specification Object's format is modified per Figure 1: Figure 1: LSP_TUNNEL_IPv4 Filter Specification Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse Interface ID | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <<<<< For CR-LDP, it MUST set the "Reverse Interface ID" field in the Reverse Interface ID TLV in the MAPPING message to the reverse FA's interface ID. The Reverse Interface ID's format is shown in Figure 2: Figure 2: Reverse Interface ID TLV in CR-LDP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Reverse Interface ID (16 bits)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type is TBD (Reverse Interface ID) and the Length is 4. >>>>> ############################ end of changed section 5 Note that all of the figure numbers following this (new) one must be adjusted. Thanks, Alan From owner-mpls@UU.NET Wed Oct 4 14:07:51 2000 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27623 for ; Wed, 4 Oct 2000 14:07:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjme17555; Wed, 4 Oct 2000 18:02:25 GMT Received: by mail-control.mail.uu.net id QQjjme10016 for mpls-outgoing; Wed, 4 Oct 2000 18:02:00 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjme09986 for ; Wed, 4 Oct 2000 18:01:56 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.5.241.39]) id QQjjme10193 for ; Wed, 4 Oct 2000 14:01:36 -0400 (EDT) Received: from ginger.lcs.mit.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ginger.lcs.mit.edu [18.26.0.82]) id QQjjme18705 for ; Wed, 4 Oct 2000 18:01:36 GMT Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id OAA06547; Wed, 4 Oct 2000 14:01:31 -0400 Date: Wed, 4 Oct 2000 14:01:31 -0400 From: "J. Noel Chiappa" Message-Id: <200010041801.OAA06547@ginger.lcs.mit.edu> To: eosborne@cisco.com, mpls@UU.NET Subject: Re: RIP TE Cc: jnc@ginger.lcs.mit.edu Sender: owner-mpls@UU.NET Precedence: bulk > From: Eric Osborne > in order to do TE you need to have a picture of what the whole network > looks like, which means you need a link-state protocol like IS-IS and > OSPF. Otherwise, you start talking about TE protocols that look a lot > like PNNI....:) OK, I'll bite. Could you please explain the fundamental differences between something like OSPF augmented with link/node QoS attributes, and PNNI? Noel From owner-mpls@UU.NET Wed Oct 4 17:20:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02029 for ; Wed, 4 Oct 2000 17:20:36 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjmr27399; Wed, 4 Oct 2000 21:19:50 GMT Received: by mail-control.mail.uu.net id QQjjmr08671 for mpls-outgoing; Wed, 4 Oct 2000 21:19:32 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjmr08666 for ; Wed, 4 Oct 2000 21:19:30 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjmr14968 for ; Wed, 4 Oct 2000 21:18:25 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjmr08053 for ; Wed, 4 Oct 2000 21:18:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA22531 for mpls@uu.net; Wed, 4 Oct 2000 17:18:24 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjmr08618 for ; Wed, 4 Oct 2000 21:17:54 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjmr23004 for ; Wed, 4 Oct 2000 21:17:25 GMT Received: from che-cse-115.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.128.23]) id QQjjmi20471 for ; Wed, 4 Oct 2000 19:02:40 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id PAA06041; Wed, 4 Oct 2000 15:02:33 -0400 (EDT) Date: Wed, 4 Oct 2000 15:02:33 -0400 From: Eric Osborne To: "J. Noel Chiappa" Cc: mpls@UU.NET Subject: Re: RIP TE Message-ID: <20001004150233.A6035@che-cse-115.cisco.com> References: <200010041801.OAA06547@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200010041801.OAA06547@ginger.lcs.mit.edu>; from jnc@ginger.lcs.mit.edu on Wed, Oct 04, 2000 at 02:01:31PM -0400 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, Oct 04, 2000 at 02:01:31PM -0400, J. Noel Chiappa wrote: > > From: Eric Osborne > > > in order to do TE you need to have a picture of what the whole network > > looks like, which means you need a link-state protocol like IS-IS and > > OSPF. Otherwise, you start talking about TE protocols that look a lot > > like PNNI....:) > > OK, I'll bite. > > Could you please explain the fundamental differences between something like > OSPF augmented with link/node QoS attributes, and PNNI? Within an area, little to none. Perhaps I was a wee bit hasty. It's not so much the difference between OSPF and PNNI, but the fact that with RIP you'd have to have some sort of dynamic path discovery to reconcile the fact that the headend doesn't have the whole area's topology, which means at some point you'll probably have a protocol mechanism that looks suspiciously like crankback. eric From owner-mpls@UU.NET Wed Oct 4 17:26:06 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02131 for ; Wed, 4 Oct 2000 17:26:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjmr24816; Wed, 4 Oct 2000 21:25:24 GMT Received: by mail-control.mail.uu.net id QQjjmr09038 for mpls-outgoing; Wed, 4 Oct 2000 21:25:05 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjmr09027 for ; Wed, 4 Oct 2000 21:24:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjmr13954 for ; Wed, 4 Oct 2000 17:24:30 -0400 (EDT) From: Vishal.Sharma@tellabs.com Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQjjmr29017 for ; Wed, 4 Oct 2000 21:24:30 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id QAA04293; Wed, 4 Oct 2000 16:19:47 -0500 (CDT) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA07088; Wed, 4 Oct 2000 16:21:03 -0500 (CDT) X-OpenMail-Hops: 1 Date: Wed, 4 Oct 2000 16:21:02 -0500 Message-Id: Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt MIME-Version: 1.0 TO: mpls@UU.NET, Sergey.Porotsky@ecitele.com CC: alchiu@att.com, bcain@baynetworks.com, Ben.Mack-Crane@tellabs.com, Changcheng.Huang@sce.carleton.ca, fiffi@nortelnetworks.com, jamoussi@nortelnetworks.com, jonweil@nortelnetworks.com, ken.owens@tellabs.com, loa.andersson@nortelnetworks.com, scivanlar@coreon.net, Srinivas.Makam@tellabs.com, Vishal.Sharma@tellabs.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Wed, 4 Oct 2000 16:21:02 -0500" Sender: owner-mpls@UU.NET Precedence: bulk Sergey, Thanks for your comments. My responses are inline. -Vishal > -----Original Message----- > From: Sergey.Porotsky@ecitele.com [mailto:Sergey.Porotsky@ecitele.com] > Sent: Wednesday, October 04, 2000 9:08 AM > To: Vishal Sharma /trc,its > Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt > > > Hi Vishal, Thanks for your answer. Please see my comments and further questions below. With best regards, Sergey. <> > > 1. In section 1.3 you have wrote : > "I. MPLS-based recovery mechanisms should facilitate fast (10?s of ms) > recovery times." > I agree, that it is necessary and it is possible to support > for protection > mechanisms. But is it really to support for rerouting > schemes, in which the > recovery path is not pre-established ? If I understand your question, you are asking whether the 10s of ms objective holds also for the case where one uses reroute recovery. Please note that we specify the 10s of ms as an _objective or goal_ for protection/recovery schemes, as opposed to making it a requirement. Not all of the schemes may meet this goal. In particular, reroute recovery schemes, where the recovery path is not pre-established may take longer to recover the working traffic. [Porotsky Sergey] OK. I fully agree with you. But what do you think, what are REALL requirements for rerouting scheme recovery time? I don't know that there is one answer to this question. The REAL requirements are obviously to get the recovery done as soon as possible. The actual constraints will be set by the application or provider that chooses to use reroute recovery. If reroute recovery depends on the convergence of the routing protocols (as we have assumed), then the time is theoretically indeterminate! In practice, it may happen in a few tens of milliseconds to a few minutes depending on the network. > 3. In section 2.3.1 is written: > "Rerouting - a recovery mechanism in which the recovery path or path > segments are created dynamically after the detection of a fault on the > working path." > Notion "rerouting" usually is used not only for recovery. For example, > ATMForum uses both notions hard-rerouting > (break-before-make)for recovery > and soft-rerouting (make-before-break)for re-arrangement. The draft, as written, does not, strictly speaking, have a notion of "soft rerouting" in it, since we felt that that is not a notion that is related to protection or recovery. We were using "rerouting" always in the context of "hard rerouting." The notion of optimizing a path is partially addressed in the draft under "dynamic re-routing cycle" in Section 2.2.3. Do you think that we need to talk about "soft rerouting" in the draft? [Porotsky Sergey] NO. You are right, soft-rerouting is outscope of your draft. <> > 5. In section 3.6 is written: > "Fault Notification: Protection switching relies...the node > should send out > a notification of the fault by transmitting a FIS to those of > its upstream > LSRs..." > What we have to use for notification on the Rerouting Scheme > - also FIS or > other mechanisms? The implicit assumption in our description of the reroute scheme was that the nodes affected by the fault learn of the fault via changes to the routing updates. I suppose it is possible, even in the reroute case, to have the affected nodes (PSLs) be notified by some means other than routing. In that case, an FIS message would be one way to do so. [Porotsky Sergey] I think, that FIS using for on-demand rerouting has many drawbacks: On-demand rerouting does not require very fast recovery. First, after receiving Notification Message, the Source has to wait some hold-off time to successfully finish Pre-Planned Rerouting. Second, On-Demand Rerouting scheme requires some (not very low) time both for Backup Route Selection and Backup LSP Setup (CAC, Bandwidth Reservation, etc.) FISs are sent by means of RNT using. If RNT is used for all LSPs (both supported of protection and restoration), RNT tables will be too large and so FIS messages for protection-LSP should not send for Source very fast. In differ for Protection, Rerouting tools have to free all resources, used for failed LSP. Therefore, in any case it is necessary to send RSVP Tear-Down messages. To use network resources more effectively and to improve Restoration Ratio, it seems prove to release resources of failed LSPs before establishment of backup LSPs. What do you think about RSVP Tear-Down Message using for failure notification on rerouting schemes ? [Vishal] I mentioned the FIS as one possibility to intimate the affected source(s) of a failure that requires their intervention. It does not mean that the source(s) will begin recovery immediately on receipt of the message. They will, as you observe, take care of planned rerouting before initiating reroute recovery. In fact for the reroute recovery to be reliable, they would have to wait for the routing tables to converge. (Otherwise, an alternate route picked by the source might need to be changed again once the tables converge.) As regards the explosion of the RNT tables, that would depend on the number and granularity of the LSPs in the network. In fact, that is why, our assumption was that re-route recovery works in conjunction with IP routing protocols, and has to wait for them to converge. In that case, no special notification to the sources is needed. They learn all they need to via the routing updates. The RSVP Tear-Down message itself may not reach the desired source, if the routing tables haven't converged, so I am not sure that that would be a useful way to intimate the source. (Note that the FIS message uses a preconfigured reverse path, that does not depend on L3 routing tables.) From owner-mpls@UU.NET Wed Oct 4 19:44:40 2000 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04563 for ; Wed, 4 Oct 2000 19:44:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjna29249; Wed, 4 Oct 2000 23:43:53 GMT Received: by mail-control.mail.uu.net id QQjjna13312 for mpls-outgoing; Wed, 4 Oct 2000 23:43:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjna13304 for ; Wed, 4 Oct 2000 23:43:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjna16309 for ; Wed, 4 Oct 2000 19:43:00 -0400 (EDT) Received: from postoffice.opticworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.170.20.5]) id QQjjna17566 for ; Wed, 4 Oct 2000 23:42:44 GMT Received: by postoffice.opticworks.com with Internet Mail Service (5.5.2650.21) id <4GL96AB2>; Wed, 4 Oct 2000 16:41:34 -0700 Message-ID: <5325CE3D64E3D31184B1009027DDD26F679BB0@caems1.opticworks.com> From: Stephen Su To: mpls@UU.NET Subject: Question about Label Distribution Peers Date: Wed, 4 Oct 2000 16:42:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E5C.CB8D7C10" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C02E5C.CB8D7C10 Content-Type: text/plain; charset="iso-8859-1" Hi all, I have a question in regarding to section 4.1.2.1 of "draft-ietf-mpls-arch-07.txt". Could someone explain (perhaps with an example) the following? 2. R1's route to X is a route which it learned about by some instance of routing algorithm A1, and that route is redistributed into an instance of routing algorithm A2, and R2 is a neighbor of R1 in that instance of A2 Thanks, -Stephen ------_=_NextPart_001_01C02E5C.CB8D7C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question about Label Distribution Peers

Hi all,

I have a question in regarding to = section 4.1.2.1 of
"draft-ietf-mpls-arch-07.txt". Could someone = explain (perhaps
with an example) the = following?

      2. R1's route to X is a = route which it learned about by some
         = instance of routing algorithm A1, and that route is
         = redistributed into an instance of routing algorithm A2, and R2
         is a = neighbor of R1 in that instance of A2

Thanks,
-Stephen

------_=_NextPart_001_01C02E5C.CB8D7C10-- From owner-mpls@UU.NET Wed Oct 4 19:52:28 2000 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04724 for ; Wed, 4 Oct 2000 19:52:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjnb09407; Wed, 4 Oct 2000 23:51:55 GMT Received: by mail-control.mail.uu.net id QQjjnb13996 for mpls-outgoing; Wed, 4 Oct 2000 23:51:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjnb13991 for ; Wed, 4 Oct 2000 23:51:20 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjnb02620 for ; Wed, 4 Oct 2000 19:51:18 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjjnb14182 for ; Wed, 4 Oct 2000 23:51:02 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA26760; Wed, 4 Oct 2000 16:51:01 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id QAA13055; Wed, 4 Oct 2000 16:51:01 -0700 (PDT) Date: Wed, 4 Oct 2000 16:51:01 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010042351.QAA13055@kummer.juniper.net> To: akyol@pluris.com, mjork@avici.com Subject: Re: ERO List with numbered and unnumbered interfaces Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi, > > When filling in the ERO, there are three options: > > > > 1) Put in the router ID of the routers. This does not work for cases > > when routers have multiple links and for unnumbered interfaces. Technically this always works. You lose control of exactly which interface to use, but that is a perfectly valid ERO. > > 2) Put in the egress interface of the routers on the path and finish it > > with the router ID of the final router. So that from router A to router > > B, we represent the hop as the IP address/interface index of the > > interface from A to B on router A. I interpret this as "remote IP address on each link", i.e., put B's address (or outgoing interface index from A's point of view) for the A->B link. Note that "finishing with router ID of final router" is not needed. > > 3) Put in the ingress interface of the routers on the path starting with > > the router ID of ingress and finishing with the router ID of the egress > > LSRs. This is kind of opposite of (2). I read: "put the local address of each link, i.e., A's address for the A->B link". In the unnumbered case, you are stuck -- you could somehow put B's outgoing interface id for the A-B link, but it would do A no good in finding the next hop. Note that while either (2) or (3) works for point-to-point links, only (2) works for multipoint links. FWIW, there is yet another option: put both the local and remote interface addresses in the ERO. Yes, the ERO size is doubled, but this works, and there are even some situations where this makes sense. > > I believe that (2) is the only option that works with unnumbered > > interfaces. From the unnumbered draft: 6.1. Interpreting the Unnumbered Interface ID Subobject The Interface ID is the outgoing interface identifier with respect to the previous node in the path (i.e., the PHOP). You are saying the same thing -- use outgoing indices in the ERO. (Which I believe is Markus's point.) In any case, we're in sync :-) Kireeti. From owner-mpls@UU.NET Wed Oct 4 20:08:01 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04970 for ; Wed, 4 Oct 2000 20:08:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjnc10238; Thu, 5 Oct 2000 00:07:23 GMT Received: by mail-control.mail.uu.net id QQjjnc26107 for mpls-outgoing; Thu, 5 Oct 2000 00:06:45 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjnc26085 for ; Thu, 5 Oct 2000 00:06:27 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjnc23122 for ; Thu, 5 Oct 2000 00:06:10 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjnc08613 for ; Thu, 5 Oct 2000 00:06:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA11204 for mpls@uu.net; Wed, 4 Oct 2000 20:06:08 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjnc25950 for ; Thu, 5 Oct 2000 00:05:40 GMT Received: from cmr0.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjnc04173 for ; Wed, 4 Oct 2000 20:05:39 -0400 (EDT) Received: from mailman.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailman.cisco.com [171.68.225.9]) id QQjjnc04641 for ; Thu, 5 Oct 2000 00:05:39 GMT Received: from zaziz-x12.cisco.com (zaziz-dsl1.cisco.com [144.254.219.198]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id RAA20395; Wed, 4 Oct 2000 17:05:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20001004165927.0323b390@ce-nfs-1.cisco.com> X-Sender: zaziz@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Oct 2000 17:02:23 -0700 To: Stephen Su , mpls@UU.NET From: Zaheer Aziz Subject: Re: Question about Label Distribution Peers In-Reply-To: <5325CE3D64E3D31184B1009027DDD26F679BB0@caems1.opticworks.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 04:42 PM 10/04/2000 -0700, Stephen Su wrote: >Hi all, >I have a question in regarding to section 4.1.2.1 of >"draft-ietf-mpls-arch-07.txt". Could someone explain (perhaps >with an example) the following? > > 2. R1's route to X is a route which it learned about by some > instance of routing algorithm A1, and that route is > redistributed into an instance of routing algorithm A2, and R2 > is a neighbor of R1 in that instance of A2 for example, X---RIP---R1--OSPF-----R2 R1 learns X via RIP and R1 redistribute that via OSPF to R2. R1 are R2 are OSPF neighbors. A1 is RIP A2 is OSPF in my example Zaheer >Thanks, >-Stephen From owner-mpls@UU.NET Wed Oct 4 20:20:17 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05187 for ; Wed, 4 Oct 2000 20:20:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjnd25229; Thu, 5 Oct 2000 00:19:41 GMT Received: by mail-control.mail.uu.net id QQjjnd27182 for mpls-outgoing; Thu, 5 Oct 2000 00:19:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjnd27177 for ; Thu, 5 Oct 2000 00:19:11 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjnd20287 for ; Wed, 4 Oct 2000 20:19:01 -0400 (EDT) Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjnd24319 for ; Thu, 5 Oct 2000 00:19:01 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA12293 for mpls@uu.net; Wed, 4 Oct 2000 20:19:00 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjnd27127 for ; Thu, 5 Oct 2000 00:18:34 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjnd05564 for ; Wed, 4 Oct 2000 20:18:12 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjjnd03254 for ; Thu, 5 Oct 2000 00:17:42 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA16928; Wed, 4 Oct 2000 17:17:38 -0700 (PDT) Message-ID: <39DBC8A1.FA9C52E5@pluris.com> Date: Wed, 04 Oct 2000 17:17:37 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Kireeti Kompella , Bora Akyol CC: mpls@UU.NET Subject: Re: ERO List with numbered and unnumbered interfaces X-Priority: 2 (High) References: <200010042351.QAA13055@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Good I think we are saying the same thing, but I made some clarifications to my original email and want to see if you agree. Thanks Bora Kireeti Kompella wrote: > Hi, > > > > When filling in the ERO, there are three options: > > > > > > 1) Put in the router ID of the routers. This does not work for cases > > > when routers have multiple links and for unnumbered interfaces. > > Technically this always works. You lose control of exactly which > interface to use, but that is a perfectly valid ERO. > This is not good when you have bandwidth guarantees across the multiple interfaces. Of course if you have bonded interfaces like we do then this is a non-issue. > > > > 2) Put in the egress interface of the routers on the path and finish it > > > with the router ID of the final router. So that from router A to router > > > B, we represent the hop as the IP address/interface index of the > > > interface from A to B on router A. > > I interpret this as "remote IP address on each link", i.e., put B's > address (or outgoing interface index from A's point of view) for the > A->B link. > Not quite true. This means that I put in A's address on the A->B link. I believe this is what you specified in the unnumbered draft as well. (Since from B's perspective, A is the PHOP) For unnumbered interfaces, this means that I put the ifindex of the outgoing link as seen from A's and then B's perspective. See below: A->B->C->D the ERO then looks like: (Let ID(A,B) represent the ID of the outgoing link at hop A towards B) ID(A,B) ID(B,C) ID(C,D) ID(D) where ID(A,B) never actually makes it out of router A. Do you agree? > > Note that "finishing with router ID of final router" is not needed. > > > > 3) Put in the ingress interface of the routers on the path starting with > > > the router ID of ingress and finishing with the router ID of the egress > > > LSRs. This is kind of opposite of (2). > > I read: "put the local address of each link, i.e., A's address for > the A->B link". In the unnumbered case, you are stuck -- you could > somehow put B's outgoing interface id for the A-B link, but it would > do A no good in finding the next hop. > Exactly true! > > Note that while either (2) or (3) works for point-to-point links, > only (2) works for multipoint links. > > FWIW, there is yet another option: put both the local and remote > interface addresses in the ERO. Yes, the ERO size is doubled, but > this works, and there are even some situations where this makes sense. > > > > I believe that (2) is the only option that works with unnumbered > > > interfaces. > > >From the unnumbered draft: > > 6.1. Interpreting the Unnumbered Interface ID Subobject > > The Interface ID is the outgoing interface identifier with respect to > the previous node in the path (i.e., the PHOP). > > You are saying the same thing -- use outgoing indices in the ERO. > (Which I believe is Markus's point.) In any case, we're in sync :-) > > Kireeti. From owner-mpls@UU.NET Wed Oct 4 21:09:09 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05739 for ; Wed, 4 Oct 2000 21:09:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjng11441; Thu, 5 Oct 2000 01:08:20 GMT Received: by mail-control.mail.uu.net id QQjjng10987 for mpls-outgoing; Thu, 5 Oct 2000 01:07:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjng10966 for ; Thu, 5 Oct 2000 01:07:27 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjng10302 for ; Wed, 4 Oct 2000 21:07:24 -0400 (EDT) Received: from postoffice.opticworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.170.20.5]) id QQjjng10238 for ; Thu, 5 Oct 2000 01:07:24 GMT Received: by postoffice.opticworks.com with Internet Mail Service (5.5.2650.21) id <4GL96A1C>; Wed, 4 Oct 2000 18:06:13 -0700 Message-ID: <5325CE3D64E3D31184B1009027DDD26F679BB1@caems1.opticworks.com> From: Stephen Su To: "'Zaheer Aziz'" , mpls@UU.NET Subject: RE: Question about Label Distribution Peers Date: Wed, 4 Oct 2000 18:07:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E68.9EE41C80" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C02E68.9EE41C80 Content-Type: text/plain; charset="iso-8859-1" Zaheer, first of all, thanks for the example. OSPF allows import of routes from other protocols such as RIP, then why do we need condition 2. It seems condition 1 already covers this case. 1. R1's route to X is a route which it learned about via a particular instance of a particular IGP, and R2 is a neighbor of R1 in that instance of that IGP -Stephen -----Original Message----- From: Zaheer Aziz [mailto:zaziz@cisco.com] Sent: Wednesday, October 04, 2000 5:02 PM To: Stephen Su; mpls@UU.NET Subject: Re: Question about Label Distribution Peers At 04:42 PM 10/04/2000 -0700, Stephen Su wrote: >Hi all, >I have a question in regarding to section 4.1.2.1 of >"draft-ietf-mpls-arch-07.txt". Could someone explain (perhaps >with an example) the following? > > 2. R1's route to X is a route which it learned about by some > instance of routing algorithm A1, and that route is > redistributed into an instance of routing algorithm A2, and R2 > is a neighbor of R1 in that instance of A2 for example, X---RIP---R1--OSPF-----R2 R1 learns X via RIP and R1 redistribute that via OSPF to R2. R1 are R2 are OSPF neighbors. A1 is RIP A2 is OSPF in my example Zaheer >Thanks, >-Stephen ------_=_NextPart_001_01C02E68.9EE41C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question about Label Distribution Peers

Zaheer, first of all, thanks for the example.
OSPF allows import of routes from other = protocols
such as RIP, then why do we need condition 2. = It
seems condition 1 already covers this case.

      1. R1's route to X is = a route which it learned about via a
         = particular instance of a particular IGP, and R2 is a neighbor
         of = R1 in that instance of that IGP

-Stephen

-----Original Message-----
From: Zaheer Aziz [mailto:zaziz@cisco.com]
Sent: Wednesday, October 04, 2000 5:02 PM
To: Stephen Su; mpls@UU.NET
Subject: Re: Question about Label Distribution = Peers


At 04:42 PM 10/04/2000 -0700, Stephen Su = wrote:

>Hi all,




>I have a question in regarding to section 4.1.2.1 = of
>"draft-ietf-mpls-arch-07.txt". Could = someone explain (perhaps
>with an example) the following?
>
>      2. R1's route to = X is a route which it learned about by some
>         = instance of routing algorithm A1, and that route is
>         = redistributed into an instance of routing algorithm A2, and R2
>         = is a neighbor of R1 in that instance of A2


for example,

X---RIP---R1--OSPF-----R2

R1 learns X via RIP and R1 redistribute that via OSPF = to R2. R1 are R2 are OSPF neighbors.

A1 is RIP
A2 is OSPF in my example

Zaheer





>Thanks,
>-Stephen

------_=_NextPart_001_01C02E68.9EE41C80-- From owner-mpls@UU.NET Thu Oct 5 01:42:09 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15061 for ; Thu, 5 Oct 2000 01:42:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjny22051; Thu, 5 Oct 2000 05:40:58 GMT Received: by mail-control.mail.uu.net id QQjjny09743 for mpls-outgoing; Thu, 5 Oct 2000 05:40:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjny09736 for ; Thu, 5 Oct 2000 05:40:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjny21476 for ; Thu, 5 Oct 2000 01:40:09 -0400 (EDT) From: prasad@samsung.co.kr Received: from omail01.samsung.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjjny19011 for ; Thu, 5 Oct 2000 05:40:04 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id OAA01009 for ; Thu, 5 Oct 2000 14:41:06 +0900 (KST) X-OpenMail-Hops: 2 Date: Thu, 5 Oct 2000 14:40:21 +0900 Message-Id: Subject: CR-LDP question regarding resource class MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Thu, 5 Oct 2000 14:24:47 +0900" ;Modification-Date="Thu, 5 Oct 2000 14:40:11 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, ref: ; section 2.5 The draft says The network operator may clasify network resource in various ways.These classes are also known as _colors_or_administrative groups_.When a CR-LSP is being established ,it is necessary to indicate which resource class the CR-LSP can draw from. I am not getting what it mean. can any body explain me what a resource class is all about? may be with some example. Thanq all. prasad. From owner-mpls@UU.NET Thu Oct 5 02:11:53 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23010 for ; Thu, 5 Oct 2000 02:11:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjoa06809; Thu, 5 Oct 2000 06:10:43 GMT Received: by mail-control.mail.uu.net id QQjjoa22726 for mpls-outgoing; Thu, 5 Oct 2000 06:10:06 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjoa22696 for ; Thu, 5 Oct 2000 06:09:57 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjoa08995 for ; Thu, 5 Oct 2000 02:09:49 -0400 (EDT) Received: from mailhost.iitb.ac.in by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQjjoa28416 for ; Thu, 5 Oct 2000 06:09:46 GMT Received: (qmail 12072 invoked from network); 5 Oct 2000 06:13:54 -0000 Received: from bhairav.ee.iitb.ernet.in (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 5 Oct 2000 06:13:54 -0000 Received: from localhost (gabhijit@localhost) by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id LAA19571 for ; Thu, 5 Oct 2000 11:37:27 +0530 (IST) Date: Thu, 5 Oct 2000 11:37:27 +0530 (IST) From: Abhijit To: mpls@UU.NET Subject: meaning of word propagating in LDP draft, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi all, After going thr' LDP draft, its still not very clear to me what exactly is the use of the term "Propagating" as explained in Appendices 1 & 2. Is it necessary to use this variable in an implemntation? If so why? Thanks and regards, -abhijit From owner-mpls@UU.NET Thu Oct 5 07:18:30 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25673 for ; Thu, 5 Oct 2000 07:18:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjov19478; Thu, 5 Oct 2000 11:17:32 GMT Received: by mail-control.mail.uu.net id QQjjov06768 for mpls-outgoing; Thu, 5 Oct 2000 11:17:10 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjov06763 for ; Thu, 5 Oct 2000 11:17:03 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjou07109 for ; Thu, 5 Oct 2000 11:14:43 GMT Received: from neptune.telecomm.tadiran.co.il by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tadiran.co.il [194.90.248.2]) id QQjjou29200 for ; Thu, 5 Oct 2000 11:14:36 GMT Received: from oranus.ecitele.com (oranus [10.115.11.180]) by neptune.telecomm.tadiran.co.il (8.9.3/8.9.3) with ESMTP id NAA13404; Thu, 5 Oct 2000 13:08:16 +0200 (IST) Received: by oranus.ecitele.com with Internet Mail Service (5.5.2650.21) id <4DXBKC45>; Thu, 5 Oct 2000 14:09:14 +0300 Message-ID: From: Porotsky Sergey To: "'Vishal.Sharma@tellabs.com'" , mpls@UU.NET, Porotsky Sergey Cc: alchiu@att.com, bcain@baynetworks.com, Ben.Mack-Crane@tellabs.com, Changcheng.Huang@sce.carleton.ca, fiffi@nortelnetworks.com, jamoussi@nortelnetworks.com, jonweil@nortelnetworks.com, ken.owens@tellabs.com, loa.andersson@nortelnetworks.com, scivanlar@coreon.net, Srinivas.Makam@tellabs.com Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt Date: Thu, 5 Oct 2000 14:09:13 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EBC.B1A1B910" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C02EBC.B1A1B910 Content-Type: text/plain [Porotsky Sergey] Vishal Hi, and thanks for your answer. See my comments below. Regards, Sergey. > [Vishal] > I mentioned the FIS as one possibility to intimate the affected > source(s) of a > failure that requires their intervention. It does not mean that the > source(s) will > begin recovery immediately on receipt of the message. They will, as you > observe, > take care of planned rerouting before initiating reroute recovery. In > fact for > the reroute recovery to be reliable, they would have to wait for the > routing tables > to converge. (Otherwise, an alternate route picked by the source might > need to be > changed again once the tables converge.) > > As regards the explosion of the RNT tables, that would depend on the > number and > granularity of the LSPs in the network. In fact, that is why, our > assumption > was that re-route recovery works in conjunction with IP routing > protocols, and > has to wait for them to converge. In that case, no special notification > to > the sources is needed. They learn all they need to via the routing > updates. > > The RSVP Tear-Down message itself may not reach the desired source, if > the > routing tables haven't converged, so I am not sure that that would be a > useful way to intimate the source. (Note that the FIS message uses > a preconfigured reverse path, that does not depend on L3 routing > tables.) > [Porotsky Sergey] OK. You are correct, for re-routing based on IP/OSPF routing protocol it isn't necessary to use both FIS and Tear-Down. But why do you want to use IP routing and don't use Explicit Path Selection for re-rerouting? I think, that for pre-planned re-routing we MUST to use Explicit Route (pre-defined before failure) and also for on-demand re-rerouting we SHOULD use Explicit Routing - at least for Traffic Engineering Goals. ------_=_NextPart_001_01C02EBC.B1A1B910 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt

    [Porotsky = Sergey]  Vishal Hi, and thanks for your answer. See my comments below. Regards, Sergey.

    [Vishal]
    I mentioned the FIS as one = possibility to intimate the affected
    source(s) of a
    failure that requires their = intervention. It does not mean that the
    source(s) will
    begin recovery immediately on receipt = of the message. They will, as you
    observe,
    take care of planned rerouting before = initiating reroute recovery. In
    fact for
    the reroute recovery to be reliable, = they would have to wait for the
    routing tables
    to converge. (Otherwise, an alternate = route picked by the source might
    need to be
    changed again once the tables = converge.)

    As regards the explosion of the RNT = tables, that would depend on the
    number and
    granularity of the LSPs in the = network. In fact, that is why, our
    assumption
    was that re-route recovery works in = conjunction with IP routing
    protocols, and
    has to wait for them to converge. In = that case, no special notification
    to
    the sources is needed. They learn all = they need to via the routing
    updates.

    The RSVP Tear-Down message itself may = not reach the desired source, if
    the
    routing tables haven't converged, so = I am not sure that that would be a
    useful way to intimate the source. = (Note that the FIS message uses
    a preconfigured reverse path, that = does not depend on L3 routing
    tables.)

    [Porotsky = Sergey]  OK. You are correct, for re-routing based on  = IP/OSPF routing protocol it isn't necessary to use both FIS and = Tear-Down. But why do you want to use IP routing and don't use Explicit = Path Selection for re-rerouting? I think, that for pre-planned = re-routing we MUST to use Explicit Route (pre-defined before failure) = and also for on-demand re-rerouting we SHOULD use Explicit Routing - at = least for Traffic Engineering Goals.


------_=_NextPart_001_01C02EBC.B1A1B910-- From owner-mpls@UU.NET Thu Oct 5 07:24:41 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25810 for ; Thu, 5 Oct 2000 07:24:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjov22577; Thu, 5 Oct 2000 11:24:03 GMT Received: by mail-control.mail.uu.net id QQjjov07211 for mpls-outgoing; Thu, 5 Oct 2000 11:23:30 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjov07206 for ; Thu, 5 Oct 2000 11:23:28 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjov20515; Thu, 5 Oct 2000 11:21:54 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjjov27645; Thu, 5 Oct 2000 11:21:50 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 05 Oct 2000 16:53:51 +0530 Received: from arumugamr (arumugamr.future.futsoft.com [10.0.6.51]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA26407; Thu, 5 Oct 2000 16:39:07 +0530 Received: by localhost with Microsoft MAPI; Thu, 5 Oct 2000 16:47:30 +0530 Message-Id: <01C02EEB.F34EE4C0.arumugamr@future.futsoft.com> From: Arumugam R Reply-To: "arumugamr@future.futsoft.com" To: "'awduche@uu.net'" , "'dhg@juniper.net'" , "'lberger@labn.net'" , "'mpls@uu.net'" , "'swallow@cisco.com'" , "'tonyl@home.net'" To: "'vsriniva@cosinecom.com'" Subject: Generation of Path Error message in Resv message processing Date: Thu, 5 Oct 2000 16:47:28 +0530 Organization: FSL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Section 4.1.1.1 of Rsvp-Lsp-Tunnel-07 (Downstream) states that The downstream node selects a label to represent the flow. If a label range has been specified in the label request, the label MUST be drawn from that range. If no label is available the node sends a PathErr message with an error code of "routing problem" and an error value of "label allocation failure" According to the above mentioned statement, during Resv message processing if a node is unable to allocate a Label should send a Path Error with the above mentioned error code and value. The above statement holds good only for the Egress of the Tunnel. The clarification needed is, whether the intermediate nodes should generate Resv Error or Path Error. Generally the output of any Resv message processing, on success will be a generated Resv message, on failure a Resv Error message. Regards Aru -------------------------------------------------------------------------------- Arumugam R Senior Software Engineer, Future Software Ltd. Chennai - 35 Fone-4330550 Ext-332 -------------------------------------------------------------------------------- From owner-mpls@UU.NET Thu Oct 5 10:54:56 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00324 for ; Thu, 5 Oct 2000 10:54:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjpj29546; Thu, 5 Oct 2000 14:53:47 GMT Received: by mail-control.mail.uu.net id QQjjpj18995 for mpls-outgoing; Thu, 5 Oct 2000 14:53:14 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjpj18975 for ; Thu, 5 Oct 2000 14:53:08 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjpj00742 for ; Thu, 5 Oct 2000 14:52:59 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjjpj14256 for ; Thu, 5 Oct 2000 14:52:58 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA11193 for ; Thu, 5 Oct 2000 07:53:23 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA00736 for mpls@uu.net; Thu, 5 Oct 2000 10:52:57 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjnu25175 for ; Thu, 5 Oct 2000 04:39:34 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjnu15734 for ; Thu, 5 Oct 2000 00:39:31 -0400 (EDT) Received: from boyle.Level3.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: machine77.Level3.com [209.244.4.106]) id QQjjnu19925 for ; Thu, 5 Oct 2000 04:39:30 GMT Received: from localhost (jboyle@localhost) by boyle.Level3.com (8.9.3/8.9.3) with ESMTP id FAA01155; Thu, 5 Oct 2000 05:52:19 -0600 Date: Thu, 5 Oct 2000 05:52:19 -0600 (MDT) From: Jim Boyle X-Sender: jboyle@boyle1.eng.level3.com To: Bala Rajagopalan cc: curtis@avici.com, Michel Redondo Ferrero , mpls@UU.NET Subject: Re: MPLS/BGP routing question In-Reply-To: <39D4B6F6.126C8114@tellium.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 29 Sep 2000, Bala Rajagopalan wrote: > Hello, > > Curtis Villamizar wrote: > > > In message <39D2E493.DD05F9C3@idecnet.com>, Michel Redondo Ferrero writes: > > > > > > > For example, optical switches will definitely NOT run IBGP with the > > Internet routers. They run an IGP and MPLS (plus LMP) but not BGP. > > (In any reasonably sane network). > > Why not E-BGP between OXCs and routers? what if the routers are in the same AS, is this some new use of confederates? Jim p.s. to answer the *original* question, from a protocol perspective, as long as there are LSPs edge to edge (no need to be tunnels), one doesn't have to run BGP on interior nodes. In reality, there are other issues that might keep one running it, though. From owner-mpls@UU.NET Thu Oct 5 11:04:22 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00502 for ; Thu, 5 Oct 2000 11:04:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjpk20697; Thu, 5 Oct 2000 15:02:39 GMT Received: by mail-control.mail.uu.net id QQjjpk26137 for mpls-outgoing; Thu, 5 Oct 2000 15:02:15 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjpk26078 for ; Thu, 5 Oct 2000 15:02:08 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjpk20214 for ; Thu, 5 Oct 2000 11:01:57 -0400 (EDT) Received: from ihemail1.firewall.lucent.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjjpk19974 for ; Thu, 5 Oct 2000 15:01:26 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA10718 for ; Thu, 5 Oct 2000 11:01:26 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id LAA10643; Thu, 5 Oct 2000 11:01:23 -0400 (EDT) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA08142; Thu, 5 Oct 2000 11:01:21 -0400 Message-ID: <39DC982F.A7D3EE21@hotair.hobl.lucent.com> Date: Thu, 05 Oct 2000 11:03:12 -0400 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Vishal.Sharma@tellabs.com CC: mpls@UU.NET, Sergey.Porotsky@ecitele.com, alchiu@att.com, bcain@baynetworks.com, Ben.Mack-Crane@tellabs.com, Changcheng.Huang@sce.carleton.ca, fiffi@nortelnetworks.com, jamoussi@nortelnetworks.com, jonweil@nortelnetworks.com, ken.owens@tellabs.com, loa.andersson@nortelnetworks.com, scivanlar@coreon.net, Srinivas.Makam@tellabs.com Subject: Re: Comments draft-ietf-mpls-recovery-frmwork-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Is the MPLS-based recovery scheme really scalable and conducive to fast restoration? Imagine a catastrophic failure like a fiber cut, in which thousands of LSP's are lost. Are these all resorable in the time frame (tens of ms) you are targeting? Vishal.Sharma@tellabs.com wrote: > Sergey, > > Thanks for your comments. My responses are inline. > > -Vishal > > > -----Original Message----- > > From: Sergey.Porotsky@ecitele.com [mailto:Sergey.Porotsky@ecitele.com] > > Sent: Wednesday, October 04, 2000 9:08 AM > > To: Vishal Sharma /trc,its > > Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt > > > > > > Hi Vishal, > Thanks for your answer. Please see my comments and further questions > below. With best regards, Sergey. > > <> > > > > > 1. In section 1.3 you have wrote : > > "I. MPLS-based recovery mechanisms should facilitate fast (10?s of > ms) > > recovery times." > > I agree, that it is necessary and it is possible to support > > for protection > > mechanisms. But is it really to support for rerouting > > schemes, in which the > > recovery path is not pre-established ? > > If I understand your question, you are asking whether the 10s of ms > objective holds also for the case where one uses reroute recovery. > Please note that we specify the 10s of ms as an _objective or goal_ > for protection/recovery schemes, as opposed to making it a requirement. > Not all of the schemes may meet > this goal. In particular, reroute recovery schemes, where the > recovery path is not pre-established may take longer to recover > the working traffic. > > [Porotsky Sergey] OK. I fully agree with you. But what do you think, > what are REALL requirements for rerouting scheme recovery time? > > I don't know that there is one answer to this question. The REAL > requirements > are obviously to get the recovery done as soon as possible. The actual > constraints > will be set by the application or provider that chooses to use reroute > recovery. > If reroute recovery depends on the convergence of the routing protocols > (as we > have assumed), then the time is theoretically indeterminate! In > practice, it may > happen in a few tens of milliseconds to a few minutes depending on the > network. > > > 3. In section 2.3.1 is written: > > "Rerouting - a recovery mechanism in which the recovery path or path > > segments are created dynamically after the detection of a fault on > the > > working path." > > Notion "rerouting" usually is used not only for recovery. For > example, > > ATMForum uses both notions hard-rerouting > > (break-before-make)for recovery > > and soft-rerouting (make-before-break)for re-arrangement. > > The draft, as written, does not, strictly speaking, have a notion of > "soft rerouting" in it, since we felt that that is not a notion that > is related > to protection or recovery. We were using "rerouting" always in the > context > of "hard rerouting." The notion of optimizing a path is partially > addressed in the draft under "dynamic re-routing cycle" in Section > 2.2.3. > Do you think that we need to talk about "soft rerouting" in the draft? > > [Porotsky Sergey] NO. You are right, soft-rerouting is outscope of > your draft. > > > <> > > > 5. In section 3.6 is written: > > "Fault Notification: Protection switching relies...the node > > should send out > > a notification of the fault by transmitting a FIS to those of > > its upstream > > LSRs..." > > What we have to use for notification on the Rerouting Scheme > > - also FIS or > > other mechanisms? > > The implicit assumption in our description of the reroute scheme was > that the nodes affected by the fault learn of the fault via changes > to the routing updates. I suppose it is possible, even in the > reroute case, to have the affected nodes (PSLs) be notified > by some means other than routing. In that case, an FIS message > would be one way to do so. > > [Porotsky Sergey] I think, that FIS using for on-demand rerouting has > many drawbacks: > > On-demand rerouting does not require very fast recovery. First, after > receiving Notification Message, the Source has to wait some hold-off > time to successfully finish Pre-Planned Rerouting. Second, On-Demand > Rerouting scheme requires some (not very low) time both for Backup > Route Selection and Backup LSP Setup (CAC, Bandwidth Reservation, etc.) > > FISs are sent by means of RNT using. If RNT is used for all LSPs (both > supported of protection and restoration), RNT tables will be too large > and so FIS messages for protection-LSP should not send for Source very > fast. > > In differ for Protection, Rerouting tools have to free all resources, > used for failed LSP. > Therefore, in any case it is necessary to send RSVP Tear-Down messages. > To use network resources more effectively and to improve Restoration > Ratio, it seems prove to release resources of failed LSPs before > establishment of backup LSPs. > What do you think about RSVP Tear-Down Message using for failure > notification on rerouting schemes ? > > [Vishal] > I mentioned the FIS as one possibility to intimate the affected > source(s) of a > failure that requires their intervention. It does not mean that the > source(s) will > begin recovery immediately on receipt of the message. They will, as you > observe, > take care of planned rerouting before initiating reroute recovery. In > fact for > the reroute recovery to be reliable, they would have to wait for the > routing tables > to converge. (Otherwise, an alternate route picked by the source might > need to be > changed again once the tables converge.) > > As regards the explosion of the RNT tables, that would depend on the > number and > granularity of the LSPs in the network. In fact, that is why, our > assumption > was that re-route recovery works in conjunction with IP routing > protocols, and > has to wait for them to converge. In that case, no special notification > to > the sources is needed. They learn all they need to via the routing > updates. > > The RSVP Tear-Down message itself may not reach the desired source, if > the > routing tables haven't converged, so I am not sure that that would be a > useful way to intimate the source. (Note that the FIS message uses > a preconfigured reverse path, that does not depend on L3 routing > tables.) From owner-mpls@UU.NET Thu Oct 5 11:07:12 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00567 for ; Thu, 5 Oct 2000 11:07:12 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjpk23028; Thu, 5 Oct 2000 15:06:26 GMT Received: by mail-control.mail.uu.net id QQjjpk01253 for mpls-outgoing; Thu, 5 Oct 2000 15:05:54 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjpk01248 for ; Thu, 5 Oct 2000 15:05:43 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjpk26633 for ; Thu, 5 Oct 2000 15:04:33 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjjpk29172 for ; Thu, 5 Oct 2000 15:04:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA19966; Thu, 5 Oct 2000 08:04:57 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA00799; Thu, 5 Oct 2000 11:04:30 -0400 (EDT) Message-Id: <200010051504.LAA00799@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Stephen Su cc: "'Zaheer Aziz'" , mpls@UU.NET Subject: Re: Question about Label Distribution Peers In-reply-to: Your message of Wed, 04 Oct 2000 18:07:24 -0700. <5325CE3D64E3D31184B1009027DDD26F679BB1@caems1.opticworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 05 Oct 2000 11:04:30 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Stephen> Zaheer, first of all, thanks for the example. Stephen> OSPF allows import of routes from other protocols Stephen> such as RIP, then why do we need condition 2. It Stephen> seems condition 1 already covers this case. Stephen> 1. R1's route to X is a route which it learned about via a Stephen> particular instance of a particular IGP, and R2 is a neighbor Stephen> of R1 in that instance of that IGP In Zaheer's example, R1 learns the route via RIP, but R1 is not a RIP neighbor of R2. R1 is an OSPF neighbor of R2, but R1 does not learn the router via OSPF. Therefore condition 1 does not hold. From owner-mpls@UU.NET Thu Oct 5 11:13:32 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00694 for ; Thu, 5 Oct 2000 11:13:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjpk07708; Thu, 5 Oct 2000 15:12:54 GMT Received: by mail-control.mail.uu.net id QQjjpk01993 for mpls-outgoing; Thu, 5 Oct 2000 15:12:28 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjpk01988 for ; Thu, 5 Oct 2000 15:12:19 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjpk11619 for ; Thu, 5 Oct 2000 15:10:55 GMT Received: from p-mail2.cnet.fr by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQjjpk04956 for ; Thu, 5 Oct 2000 15:10:54 GMT Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <4JWLXFWR>; Thu, 5 Oct 2000 17:10:35 +0200 Received: from rd.francetelecom.fr (lat4074.lannion.cnet.fr [161.104.15.15]) by l-mhs1.lannion.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 41G0DJ30; Thu, 5 Oct 2000 17:09:14 +0200 Message-ID: <39DC99CB.7858FC6E@rd.francetelecom.fr> Date: Thu, 05 Oct 2000 17:10:03 +0200 From: Olivier Dugeon Organization: France Telecom R&D X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-9mdksmp i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: mpls@UU.NET Subject: draft-ietf-mpls-crlsp-modify-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, Apologize if i miss this information. I would like to know what are the status of the draft about CR-LSP modification. I saw that it has expired since September 2000. Any info ? Thanks, Olivier -- FTR&D/DAC/CPN Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.fr 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 F-22307 LANNION | Fax: +(33) 2 96 05 18 52 From owner-mpls@UU.NET Thu Oct 5 11:58:46 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01981 for ; Thu, 5 Oct 2000 11:58:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjpn20899; Thu, 5 Oct 2000 15:56:20 GMT Received: by mail-control.mail.uu.net id QQjjpn05708 for mpls-outgoing; Thu, 5 Oct 2000 15:55:47 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjpn05703 for ; Thu, 5 Oct 2000 15:55:45 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjpn28252 for ; Thu, 5 Oct 2000 11:55:33 -0400 (EDT) Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjpn04858 for ; Thu, 5 Oct 2000 15:55:32 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA15088 for mpls@uu.net; Thu, 5 Oct 2000 11:55:32 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjpn05620 for ; Thu, 5 Oct 2000 15:55:06 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjpn18714 for ; Thu, 5 Oct 2000 15:53:48 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjjpn14698 for ; Thu, 5 Oct 2000 15:53:48 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA08222; Thu, 5 Oct 2000 08:52:43 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 08:57:10 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C99C5@BBY1EXM01> From: Shahram Davari To: "'Porotsky Sergey'" , "'Vishal.Sharma@tellabs.com'" , mpls@UU.NET Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt Date: Thu, 5 Oct 2000 08:57:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EE4.EB2C94C4" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C02EE4.EB2C94C4 Content-Type: text/plain Hi Sergey, I think when Vishal says "the source waits for the IP routing to converge, he does not necessarily mean normal OSPF/IS-IS, rather the TE extended OSPF/IS-IS, which could then be used for explicit routing. Regards, -Shahram -----Original Message----- From: Porotsky Sergey [mailto:Sergey.Porotsky@ecitele.com] Sent: Thursday, October 05, 2000 7:09 AM To: 'Vishal.Sharma@tellabs.com'; mpls@UU.NET; Porotsky Sergey Cc: alchiu@att.com; bcain@baynetworks.com; Ben.Mack-Crane@tellabs.com; Changcheng.Huang@sce.carleton.ca; fiffi@nortelnetworks.com; jamoussi@nortelnetworks.com; jonweil@nortelnetworks.com; ken.owens@tellabs.com; loa.andersson@nortelnetworks.com; scivanlar@coreon.net; Srinivas.Makam@tellabs.com Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt [Porotsky Sergey] Vishal Hi, and thanks for your answer. See my comments below. Regards, Sergey. [Vishal] I mentioned the FIS as one possibility to intimate the affected source(s) of a failure that requires their intervention. It does not mean that the source(s) will begin recovery immediately on receipt of the message. They will, as you observe, take care of planned rerouting before initiating reroute recovery. In fact for the reroute recovery to be reliable, they would have to wait for the routing tables to converge. (Otherwise, an alternate route picked by the source might need to be changed again once the tables converge.) As regards the explosion of the RNT tables, that would depend on the number and granularity of the LSPs in the network. In fact, that is why, our assumption was that re-route recovery works in conjunction with IP routing protocols, and has to wait for them to converge. In that case, no special notification to the sources is needed. They learn all they need to via the routing updates. The RSVP Tear-Down message itself may not reach the desired source, if the routing tables haven't converged, so I am not sure that that would be a useful way to intimate the source. (Note that the FIS message uses a preconfigured reverse path, that does not depend on L3 routing tables.) [Porotsky Sergey] OK. You are correct, for re-routing based on IP/OSPF routing protocol it isn't necessary to use both FIS and Tear-Down. But why do you want to use IP routing and don't use Explicit Path Selection for re-rerouting? I think, that for pre-planned re-routing we MUST to use Explicit Route (pre-defined before failure) and also for on-demand re-rerouting we SHOULD use Explicit Routing - at least for Traffic Engineering Goals. ------_=_NextPart_001_01C02EE4.EB2C94C4 Content-Type: text/html RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt
Hi Sergey,
 
I think when Vishal says "the source waits for the IP routing to converge, he does not necessarily mean normal OSPF/IS-IS, rather the TE extended OSPF/IS-IS, which could then be used for explicit routing.
 
 
Regards,
-Shahram
 
-----Original Message-----
From: Porotsky Sergey [mailto:Sergey.Porotsky@ecitele.com]
Sent: Thursday, October 05, 2000 7:09 AM
To: 'Vishal.Sharma@tellabs.com'; mpls@UU.NET; Porotsky Sergey
Cc: alchiu@att.com; bcain@baynetworks.com; Ben.Mack-Crane@tellabs.com; Changcheng.Huang@sce.carleton.ca; fiffi@nortelnetworks.com; jamoussi@nortelnetworks.com; jonweil@nortelnetworks.com; ken.owens@tellabs.com; loa.andersson@nortelnetworks.com; scivanlar@coreon.net; Srinivas.Makam@tellabs.com
Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt


    [Porotsky Sergey]  Vishal Hi, and thanks for your answer. See my comments below. Regards, Sergey.

    [Vishal]
    I mentioned the FIS as one possibility to intimate the affected
    source(s) of a
    failure that requires their intervention. It does not mean that the
    source(s) will
    begin recovery immediately on receipt of the message. They will, as you
    observe,
    take care of planned rerouting before initiating reroute recovery. In
    fact for
    the reroute recovery to be reliable, they would have to wait for the
    routing tables
    to converge. (Otherwise, an alternate route picked by the source might
    need to be
    changed again once the tables converge.)

    As regards the explosion of the RNT tables, that would depend on the
    number and
    granularity of the LSPs in the network. In fact, that is why, our
    assumption
    was that re-route recovery works in conjunction with IP routing
    protocols, and
    has to wait for them to converge. In that case, no special notification
    to
    the sources is needed. They learn all they need to via the routing
    updates.

    The RSVP Tear-Down message itself may not reach the desired source, if
    the
    routing tables haven't converged, so I am not sure that that would be a
    useful way to intimate the source. (Note that the FIS message uses
    a preconfigured reverse path, that does not depend on L3 routing
    tables.)

    [Porotsky Sergey]  OK. You are correct, for re-routing based on  IP/OSPF routing protocol it isn't necessary to use both FIS and Tear-Down. But why do you want to use IP routing and don't use Explicit Path Selection for re-rerouting? I think, that for pre-planned re-routing we MUST to use Explicit Route (pre-defined before failure) and also for on-demand re-rerouting we SHOULD use Explicit Routing - at least for Traffic Engineering Goals.


------_=_NextPart_001_01C02EE4.EB2C94C4-- From owner-mpls@UU.NET Thu Oct 5 12:24:43 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02535 for ; Thu, 5 Oct 2000 12:24:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjpp19566; Thu, 5 Oct 2000 16:23:34 GMT Received: by mail-control.mail.uu.net id QQjjpp19362 for mpls-outgoing; Thu, 5 Oct 2000 16:23:10 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjpp19357 for ; Thu, 5 Oct 2000 16:23:09 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjpp23276 for ; Thu, 5 Oct 2000 16:22:46 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjpp09727 for ; Thu, 5 Oct 2000 16:22:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA19391 for mpls@uu.net; Thu, 5 Oct 2000 12:22:44 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjpp19321 for ; Thu, 5 Oct 2000 16:22:19 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjpp02123 for ; Thu, 5 Oct 2000 12:22:02 -0400 (EDT) Received: from qnsgs000.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: qnsgs000.nortelnetworks.com [47.211.0.31]) id QQjjpp15768 for ; Thu, 5 Oct 2000 16:22:01 GMT Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Thu, 5 Oct 2000 17:05:45 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00m.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4JRF1NPS; Thu, 5 Oct 2000 17:05:42 +0100 Received: from nortelnetworks.com (LANDERSS [141.251.192.193]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TX7Q5JZH; Thu, 5 Oct 2000 18:05:41 +0200 Message-ID: <39DCA673.E4E29860@nortelnetworks.com> Date: Thu, 05 Oct 2000 18:04:03 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: "Loa Andersson" Organization: Nortel Networks - Routing Architecture Lab X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ramesh Bhandari CC: Vishal.Sharma@tellabs.com, mpls@UU.NET, Sergey.Porotsky@ecitele.com, alchiu@att.com, bcain@BayNetworks.COM, Ben.Mack-Crane@tellabs.com, Changcheng.Huang@sce.carleton.ca, "Fiffi Hellstrand" , "Bilel Jamoussi" , "Jon Weil" , ken.owens@tellabs.com, scivanlar@coreon.net, Srinivas.Makam@tellabs.com Subject: Re: Comments draft-ietf-mpls-recovery-frmwork-00.txt References: <39DC982F.A7D3EE21@hotair.hobl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ramesh, if you need to restore thousands or 10's or even 100's of thousands of LSPs it will certainly take time, even it is not as easy multiply the time to set up one LSP with the number of LSPs. You have to do something else, e.g. do everything with one aaction. /Loa Ramesh Bhandari wrote: > > Is the MPLS-based recovery scheme really scalable and conducive to fast > restoration? Imagine a catastrophic failure like a fiber cut, in which > thousands of LSP's are lost. Are these all resorable in the time frame (tens > of ms) you are targeting? > > Vishal.Sharma@tellabs.com wrote: > > > Sergey, > > > > Thanks for your comments. My responses are inline. > > > > -Vishal > > > > > -----Original Message----- > > > From: Sergey.Porotsky@ecitele.com [mailto:Sergey.Porotsky@ecitele.com] > > > Sent: Wednesday, October 04, 2000 9:08 AM > > > To: Vishal Sharma /trc,its > > > Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt > > > > > > > > > Hi Vishal, > > Thanks for your answer. Please see my comments and further questions > > below. With best regards, Sergey. > > > > <> > > > > > > > > 1. In section 1.3 you have wrote : > > > "I. MPLS-based recovery mechanisms should facilitate fast (10?s of > > ms) > > > recovery times." > > > I agree, that it is necessary and it is possible to support > > > for protection > > > mechanisms. But is it really to support for rerouting > > > schemes, in which the > > > recovery path is not pre-established ? > > > > If I understand your question, you are asking whether the 10s of ms > > objective holds also for the case where one uses reroute recovery. > > Please note that we specify the 10s of ms as an _objective or goal_ > > for protection/recovery schemes, as opposed to making it a requirement. > > Not all of the schemes may meet > > this goal. In particular, reroute recovery schemes, where the > > recovery path is not pre-established may take longer to recover > > the working traffic. > > > > [Porotsky Sergey] OK. I fully agree with you. But what do you think, > > what are REALL requirements for rerouting scheme recovery time? > > > > I don't know that there is one answer to this question. The REAL > > requirements > > are obviously to get the recovery done as soon as possible. The actual > > constraints > > will be set by the application or provider that chooses to use reroute > > recovery. > > If reroute recovery depends on the convergence of the routing protocols > > (as we > > have assumed), then the time is theoretically indeterminate! In > > practice, it may > > happen in a few tens of milliseconds to a few minutes depending on the > > network. > > > > > 3. In section 2.3.1 is written: > > > "Rerouting - a recovery mechanism in which the recovery path or path > > > segments are created dynamically after the detection of a fault on > > the > > > working path." > > > Notion "rerouting" usually is used not only for recovery. For > > example, > > > ATMForum uses both notions hard-rerouting > > > (break-before-make)for recovery > > > and soft-rerouting (make-before-break)for re-arrangement. > > > > The draft, as written, does not, strictly speaking, have a notion of > > "soft rerouting" in it, since we felt that that is not a notion that > > is related > > to protection or recovery. We were using "rerouting" always in the > > context > > of "hard rerouting." The notion of optimizing a path is partially > > addressed in the draft under "dynamic re-routing cycle" in Section > > 2.2.3. > > Do you think that we need to talk about "soft rerouting" in the draft? > > > > [Porotsky Sergey] NO. You are right, soft-rerouting is outscope of > > your draft. > > > > > > <> > > > > > 5. In section 3.6 is written: > > > "Fault Notification: Protection switching relies...the node > > > should send out > > > a notification of the fault by transmitting a FIS to those of > > > its upstream > > > LSRs..." > > > What we have to use for notification on the Rerouting Scheme > > > - also FIS or > > > other mechanisms? > > > > The implicit assumption in our description of the reroute scheme was > > that the nodes affected by the fault learn of the fault via changes > > to the routing updates. I suppose it is possible, even in the > > reroute case, to have the affected nodes (PSLs) be notified > > by some means other than routing. In that case, an FIS message > > would be one way to do so. > > > > [Porotsky Sergey] I think, that FIS using for on-demand rerouting has > > many drawbacks: > > > > On-demand rerouting does not require very fast recovery. First, after > > receiving Notification Message, the Source has to wait some hold-off > > time to successfully finish Pre-Planned Rerouting. Second, On-Demand > > Rerouting scheme requires some (not very low) time both for Backup > > Route Selection and Backup LSP Setup (CAC, Bandwidth Reservation, etc.) > > > > FISs are sent by means of RNT using. If RNT is used for all LSPs (both > > supported of protection and restoration), RNT tables will be too large > > and so FIS messages for protection-LSP should not send for Source very > > fast. > > > > In differ for Protection, Rerouting tools have to free all resources, > > used for failed LSP. > > Therefore, in any case it is necessary to send RSVP Tear-Down messages. > > To use network resources more effectively and to improve Restoration > > Ratio, it seems prove to release resources of failed LSPs before > > establishment of backup LSPs. > > What do you think about RSVP Tear-Down Message using for failure > > notification on rerouting schemes ? > > > > [Vishal] > > I mentioned the FIS as one possibility to intimate the affected > > source(s) of a > > failure that requires their intervention. It does not mean that the > > source(s) will > > begin recovery immediately on receipt of the message. They will, as you > > observe, > > take care of planned rerouting before initiating reroute recovery. In > > fact for > > the reroute recovery to be reliable, they would have to wait for the > > routing tables > > to converge. (Otherwise, an alternate route picked by the source might > > need to be > > changed again once the tables converge.) > > > > As regards the explosion of the RNT tables, that would depend on the > > number and > > granularity of the LSPs in the network. In fact, that is why, our > > assumption > > was that re-route recovery works in conjunction with IP routing > > protocols, and > > has to wait for them to converge. In that case, no special notification > > to > > the sources is needed. They learn all they need to via the routing > > updates. > > > > The RSVP Tear-Down message itself may not reach the desired source, if > > the > > routing tables haven't converged, so I am not sure that that would be a > > useful way to intimate the source. (Note that the FIS message uses > > a preconfigured reverse path, that does not depend on L3 routing > > tables.) -- Loa Andersson Director Routing Architecture Lab, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Thu Oct 5 12:32:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02691 for ; Thu, 5 Oct 2000 12:32:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjpq02186; Thu, 5 Oct 2000 16:30:42 GMT Received: by mail-control.mail.uu.net id QQjjpq19846 for mpls-outgoing; Thu, 5 Oct 2000 16:30:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjpp19801 for ; Thu, 5 Oct 2000 16:29:56 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjpp03588 for ; Thu, 5 Oct 2000 12:29:45 -0400 (EDT) Received: from kcmso1.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso1.att.com [192.128.133.69]) id QQjjpp18790 for ; Thu, 5 Oct 2000 16:29:45 GMT Received: from gab200r1.ems.att.com ([135.37.94.32]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id MAA25481; Thu, 5 Oct 2000 12:29:41 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id MAA12332; Thu, 5 Oct 2000 12:31:43 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 12:29:40 -0400 Message-ID: <1B08859602C8D211B66F0000C0769CFA03A94FCF@njc240po03.mt.att.com> From: "Ash, Gerald R (Jerry), ALCOO" To: "'Olivier Dugeon'" Cc: "Ash, Gerald R (Jerry), ALCOO" , mpls@UU.NET Subject: RE: draft-ietf-mpls-crlsp-modify-01.txt Date: Thu, 5 Oct 2000 12:29:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Status: 1. Completed WG last call: May, 2000. 2. Requested status from WG chairs and AD: June, 2000 (no response received as yet) 3. Will resubmit draft with new dates. Thanks, Jerry Ash >-----Original Message----- >From: Olivier Dugeon [mailto:Olivier.Dugeon@rd.francetelecom.fr] >Sent: Thursday, October 05, 2000 11:10 AM >To: mpls@UU.NET >Subject: draft-ietf-mpls-crlsp-modify-01.txt > >Hello All, > >Apologize if i miss this information. I would like to know what are the >status of the draft about CR-LSP modification. I saw that it has expired >since September 2000. > >Any info ? > >Thanks, > >Olivier >-- > FTR&D/DAC/CPN > Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.fr > 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 > F-22307 LANNION | Fax: +(33) 2 96 05 18 52 From owner-mpls@UU.NET Thu Oct 5 12:38:32 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02839 for ; Thu, 5 Oct 2000 12:38:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjpq23513; Thu, 5 Oct 2000 16:37:42 GMT Received: by mail-control.mail.uu.net id QQjjpq20213 for mpls-outgoing; Thu, 5 Oct 2000 16:37:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjpq20207 for ; Thu, 5 Oct 2000 16:37:11 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjpq04630 for ; Thu, 5 Oct 2000 12:37:10 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQjjpq22138 for ; Thu, 5 Oct 2000 16:37:08 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <4K2DA1RN>; Thu, 5 Oct 2000 09:37:24 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6625D8AA3@ICARIAN> From: Eric Gray To: "'Abhijit'" Cc: mpls@UU.NET Subject: RE: meaning of word propagating in LDP draft, Date: Thu, 5 Oct 2000 09:37:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Abhijit, In all cases where a "Propagating" variable is set, it is passed to "Prepare_Label_Mapping_Attributes". This argument is used in step PMpA.11 and is significant in determining whether or not to propagate a label mapping with a known hop-count. Naturally, you can use a variable with a different name, or even a completely different approach as long as the resulting behavior in your implementation reduces to an equivalent of LDP defined procedures. -- Eric Gray > -----Original Message----- > From: Abhijit [mailto:gabhijit@ee.iitb.ernet.in] > Sent: Wednesday, October 04, 2000 11:07 PM > To: mpls@UU.NET > Subject: meaning of word propagating in LDP draft, > > > > > Hi all, > > After going thr' LDP draft, its still not very clear to me > what exactly is > the use of the term "Propagating" as explained in Appendices > 1 & 2. Is it > necessary to use this variable in an implemntation? If so why? > > Thanks and regards, > > -abhijit > From owner-mpls@UU.NET Thu Oct 5 14:15:59 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04281 for ; Thu, 5 Oct 2000 14:15:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjpw10649; Thu, 5 Oct 2000 18:14:02 GMT Received: by mail-control.mail.uu.net id QQjjpw20371 for mpls-outgoing; Thu, 5 Oct 2000 18:13:41 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjpw20365 for ; Thu, 5 Oct 2000 18:13:30 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjpw16249 for ; Thu, 5 Oct 2000 14:13:15 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQjjpw05964 for ; Thu, 5 Oct 2000 18:13:15 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <4K2DAFHY>; Thu, 5 Oct 2000 11:13:36 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6625D8AA5@ICARIAN> From: Eric Gray To: curtis@avici.com Cc: Bala Rajagopalan , Michel Redondo Ferrero , mpls@UU.NET Subject: RE: MPLS/BGP routing question Date: Thu, 5 Oct 2000 11:13:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Curtis, Please see below. Curtis Villamizar wrote: ... ... > > For example, optical switches will definitely NOT run IBGP with the > Internet routers. They run an IGP and MPLS (plus LMP) but not BGP. > (In any reasonably sane network). > This is a confusing statement, mostly because it's not clear what you mean by "Internet routers", "optical switches" and "sane" networks. If, by "Internet routers", you mean routers outside of your AS, then the first statement is true but not new and useful information about optical switches. Nobody runs iBGP with routers external to their AS. But, then again, they do not run an IGP with them either - so I suspect that this is not your meaning. If you mean AS boundary routers, then the next question I have to ask is what do you mean by "optical switch". If you mean a box with only optical interfaces that does switching and not routing, then - again - the statement, with regard to iBGP at least, is true and not especially interesting. If it doesn't do routing, then it doesn't do routing. Yawn. But your assertion that they run MPLS and an IGP seems to indicate that this is not what you mean. If, however, you mean a box with only optical interfaces which is "packet aware" and participates in some form of routing, then I have to ask which particular flavor of "sane" you are referring to. For example, I believe that it may be hard to distinguish an AS boundary router with all optical interfaces from a packet aware optical switch - at least in some cases. In the case of an all optical AS boundary router, it is more "sane" to run iBGP than it is to - for example - import Internet routes into an IGP. If ASBRs run iBGP, they must be talking to other boxes also running iBGP. If the ASBR is all optical, then chances are good that they will be talking iBGP to neighboring optical switches - at least in some types of "sane" networks. So, I seem to have missed your point. Can you elucidate? -- Eric Gray From owner-mpls@UU.NET Thu Oct 5 15:11:49 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05295 for ; Thu, 5 Oct 2000 15:11:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqa18350; Thu, 5 Oct 2000 19:09:55 GMT Received: by mail-control.mail.uu.net id QQjjqa06207 for mpls-outgoing; Thu, 5 Oct 2000 19:09:20 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjqa06197 for ; Thu, 5 Oct 2000 19:09:08 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqa27979 for ; Thu, 5 Oct 2000 15:08:31 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjjqa06530 for ; Thu, 5 Oct 2000 19:08:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA22771 for ; Thu, 5 Oct 2000 12:08:55 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA01608 for mpls@uu.net; Thu, 5 Oct 2000 15:08:28 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjpu05926 for ; Thu, 5 Oct 2000 17:34:54 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjpu07543 for ; Thu, 5 Oct 2000 17:34:11 GMT Received: from outside.whiterocknetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 64-48-28-18.customer.algx.net [64.48.28.18]) id QQjjpu13911 for ; Thu, 5 Oct 2000 17:34:11 GMT Received: from [192.168.1.220] by outside.whiterocknetworks.com for mpls@uu.net id MAA22745; Thu Oct 5 12:34:07 2000 Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id <4KJ8WDBQ>; Thu, 5 Oct 2000 12:31:17 -0500 Message-ID: <758F0C2C951CD411B15300D0B74444652489B9@192-168-1-220.customer.algx.net> Subject: Interface ID in kompella-unnum-02 Date: Thu, 5 Oct 2000 12:31:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" To: "'mpls@uu.net'" From: "Raftelis, Mike" Sender: owner-mpls@UU.NET Precedence: bulk Hello, In draft-kompella-mpls-unnum-02.txt, the interface ID field is shown to be 16 bits. Previous e-mails have suggested that the size be increased to 32 bits to match the SNMP ifIndex size. Can this be increased? We could have ifIndex values that are larger than 16 bits. Also, the Reverse interface ID TLV suggested in Alan Kullberg's "unum-02 comments" e-mail sounds great to people implementing CR-LDP, except for the size of the interface ID field. Mike Raftelis From owner-mpls@UU.NET Thu Oct 5 15:26:17 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05573 for ; Thu, 5 Oct 2000 15:26:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqb08023; Thu, 5 Oct 2000 19:24:26 GMT Received: by mail-control.mail.uu.net id QQjjqb07410 for mpls-outgoing; Thu, 5 Oct 2000 19:23:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjqb07403 for ; Thu, 5 Oct 2000 19:23:48 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjqb02206 for ; Thu, 5 Oct 2000 15:23:06 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqb02830 for ; Thu, 5 Oct 2000 19:22:36 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA16844 for mpls@uu.net; Thu, 5 Oct 2000 15:22:35 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjqb07358 for ; Thu, 5 Oct 2000 19:22:09 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjqb13562 for ; Thu, 5 Oct 2000 19:21:50 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjjqb04637 for ; Thu, 5 Oct 2000 19:21:50 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA24664; Thu, 5 Oct 2000 12:21:48 -0700 (PDT) Message-Id: <200010051921.MAA24664@omega.cisco.com> To: "Raftelis, Mike" cc: "'mpls@uu.net'" Subject: Re: Interface ID in kompella-unnum-02 In-reply-to: Your message of "Thu, 05 Oct 2000 12:31:16 CDT." <758F0C2C951CD411B15300D0B74444652489B9@192-168-1-220.customer.algx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24661.970773708.1@cisco.com> Date: Thu, 05 Oct 2000 12:21:48 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Mike, > Hello, > In draft-kompella-mpls-unnum-02.txt, the interface ID field is shown > to be 16 bits. Previous e-mails have suggested that the size be increased > to 32 bits to match the SNMP ifIndex size. Can this be increased? Please bear in mind that the interface index (interface ID) is carried not just in RSVP/CR-LDP, but in OSPF as well. In OSPF with unnumbered links interface ID is carried in the same field as a plain IP address. At the same time one still need to be able to distinguish between the case when this field carries an IP address and the case when this field carries an interface ID. So if we allow interface ID to be 32 bits, then when this field carries the value 33620225, is that an IP address (2.1.1.1) or an interface ID (33620225) ? Yakov. From owner-mpls@UU.NET Thu Oct 5 15:34:46 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05702 for ; Thu, 5 Oct 2000 15:34:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqc24022; Thu, 5 Oct 2000 19:34:05 GMT Received: by mail-control.mail.uu.net id QQjjqc08304 for mpls-outgoing; Thu, 5 Oct 2000 19:33:40 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjqc08296 for ; Thu, 5 Oct 2000 19:33:35 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjqc04062 for ; Thu, 5 Oct 2000 15:33:16 -0400 (EDT) Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjjqc19558 for ; Thu, 5 Oct 2000 19:33:16 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA01888; Thu, 5 Oct 2000 12:33:11 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id MAA01059; Thu, 5 Oct 2000 12:33:10 -0700 (PDT) Date: Thu, 5 Oct 2000 12:33:10 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010051933.MAA01059@kummer.juniper.net> To: mpls@UU.NET, Mraftelis@WhiteRockNetworks.com Subject: Re: Interface ID in kompella-unnum-02 Sender: owner-mpls@UU.NET Precedence: bulk Hi, > In draft-kompella-mpls-unnum-02.txt, the interface ID field is shown > to be 16 bits. Previous e-mails have suggested that the size be increased > to 32 bits to match the SNMP ifIndex size. Can this be increased? 16 bits should be enough to number all interfaces on a box. If it isn't, you have other much more serious problems (IS-IS and OSPF cannot even carry the information (this is not even going into the scaling issues)). If you do get to the point where you have more than a few thousand interfaces on a box, you probably really should be considering bundling; this will reduce the number of interfaces from the routing protocols point-of-view to as few as the number of adjacent nodes. Then number the bundles, not the actual interfaces. > We could have ifIndex values that are larger than 16 bits. We hereby resolve to remove all text that suggests using the SNMP ifIndex for interface indices :-) The only requirement for interface indices is that indices generated by a node are unique, and that the routing and signalling modules use the same number for an interface. If your ifIndexes are larger than 16 bits, don't use them, generate new indices. Note that the requirements for SNMP indices are much stronger than for interface indices: they need to remain stable, reusing them can be an issue, etc., which is why ifIndexes tend to grow beyond 2^16. Note too that the interface index cannot be made bigger than 2^24; this is so that the distinction between IP addresses and interface indices is clear. Given that, and given the fact the SNMP ifIndexes can be 32 bits, ifIndexes are ruled out as potential interface indices. Kireeti. From owner-mpls@UU.NET Thu Oct 5 16:11:22 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06191 for ; Thu, 5 Oct 2000 16:11:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqe00477; Thu, 5 Oct 2000 20:10:16 GMT Received: by mail-control.mail.uu.net id QQjjqe22385 for mpls-outgoing; Thu, 5 Oct 2000 20:09:39 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjqe22376 for ; Thu, 5 Oct 2000 20:09:21 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQjjqe10259 for ; Thu, 5 Oct 2000 16:08:47 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqe28640 for ; Thu, 5 Oct 2000 20:08:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA23811 for mpls@uu.net; Thu, 5 Oct 2000 16:08:46 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjqe22314 for ; Thu, 5 Oct 2000 20:08:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQjjqe10105 for ; Thu, 5 Oct 2000 16:07:53 -0400 (EDT) Received: from funnel.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjjqe03563 for ; Thu, 5 Oct 2000 20:07:38 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA14181; Thu, 5 Oct 2000 16:07:33 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-207.cisco.com [161.44.134.207]) by bucket.cisco.com (Mirapoint) with ESMTP id AAL28464; Thu, 5 Oct 2000 16:07:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20001005155723.00b74c90@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Oct 2000 16:07:06 -0400 To: Kireeti Kompella , mpls@UU.NET, Mraftelis@WhiteRockNetworks.com From: "Thomas D. Nadeau" Subject: Re: Interface ID in kompella-unnum-02 In-Reply-To: <200010051933.MAA01059@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, > > In draft-kompella-mpls-unnum-02.txt, the interface ID field is shown > > to be 16 bits. Previous e-mails have suggested that the size be increased > > to 32 bits to match the SNMP ifIndex size. Can this be increased? > >16 bits should be enough to number all interfaces on a box. If >it isn't, you have other much more serious problems (IS-IS and OSPF >cannot even carry the information (this is not even going into the >scaling issues)). If you do get to the point where you have more >than a few thousand interfaces on a box, you probably really should >be considering bundling; this will reduce the number of interfaces >from the routing protocols point-of-view to as few as the number of >adjacent nodes. Then number the bundles, not the actual interfaces. Not necessarily. As I and Keith M. pointed out, it is perfectly valid for an implementation to keep track of the last ifIndex used and continue up from there after each reboot. So, even on the box you described above as being well behaved, it is perfectly reasonable (and legal) to see ifIndexes which exceed 16 bits. > > We could have ifIndex values that are larger than 16 bits. > >We hereby resolve to remove all text that suggests using the SNMP >ifIndex for interface indices :-) The only requirement for interface >indices is that indices generated by a node are unique, and that the >routing and signalling modules use the same number for an interface. >If your ifIndexes are larger than 16 bits, don't use them, generate >new indices. This is really not a good idea from a management perspective, especially since all of the MIBs I know of that manage any type of interface (including all of the MPLS MIBs) rely on the ifIndex as indexes for many tables. How does one find the interface if it does not correspond to the ifIndex in the Interfaces MIB? >Note that the requirements for SNMP indices are much stronger than >for interface indices: they need to remain stable, reusing them can >be an issue, etc., which is why ifIndexes tend to grow beyond 2^16. > >Note too that the interface index cannot be made bigger than 2^24; >this is so that the distinction between IP addresses and interface >indices is clear. Given that, and given the fact the SNMP ifIndexes >can be 32 bits, ifIndexes are ruled out as potential interface >indices. Personally, this seems like a flaw in the design. The type ifIndex has been around for quite a long time. I don't see how the ifIndex in OSPF/ISIS was allowed to use a different size while claiming that one could put use an ifIndex from the Interfaces MIB. --tom From owner-mpls@UU.NET Thu Oct 5 16:17:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06274 for ; Thu, 5 Oct 2000 16:17:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqf05033; Thu, 5 Oct 2000 20:15:46 GMT Received: by mail-control.mail.uu.net id QQjjqf23064 for mpls-outgoing; Thu, 5 Oct 2000 20:15:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjqe22982 for ; Thu, 5 Oct 2000 20:14:59 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqe11187 for ; Thu, 5 Oct 2000 16:14:19 -0400 (EDT) Received: from outside.whiterocknetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 64-48-28-18.customer.algx.net [64.48.28.18]) id QQjjqe03070 for ; Thu, 5 Oct 2000 20:14:19 GMT Received: from [192.168.1.220] by outside.whiterocknetworks.com for mpls@uu.net id PAA07085; Thu Oct 5 15:14:19 2000 Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id <4KJ8WDHY>; Thu, 5 Oct 2000 15:11:28 -0500 Message-ID: <758F0C2C951CD411B15300D0B744446503BF51@192-168-1-220.customer.algx.net> Subject: Re: Interface ID in kompella-unnum-02 Date: Thu, 5 Oct 2000 15:11:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" To: "'mpls@uu.net'" From: "Connell, Jeff" Sender: owner-mpls@UU.NET Precedence: bulk I may be wrong but.. The two values are never used in the same field without any other indication, right? In a router-LSA, the router-ID is the IP of the router, and if the link type is point-to-point, then this is indicated with the type field in the link information. The Link Data field can either be a network mask(type 2 or 3) or an ifIndex (type 1). (p133 RFC2328) Where else is the ifIndex used in OSPF? Jeff. -----Original Message----- From: Yakov Rekhter [mailto:yakov@cisco.com] Sent: Thursday, October 05, 2000 2:22 PM To: Raftelis, Mike Cc: 'mpls@uu.net' Subject: Re: Interface ID in kompella-unnum-02 Mike, > Hello, > In draft-kompella-mpls-unnum-02.txt, the interface ID field is shown > to be 16 bits. Previous e-mails have suggested that the size be increased > to 32 bits to match the SNMP ifIndex size. Can this be increased? Please bear in mind that the interface index (interface ID) is carried not just in RSVP/CR-LDP, but in OSPF as well. In OSPF with unnumbered links interface ID is carried in the same field as a plain IP address. At the same time one still need to be able to distinguish between the case when this field carries an IP address and the case when this field carries an interface ID. So if we allow interface ID to be 32 bits, then when this field carries the value 33620225, is that an IP address (2.1.1.1) or an interface ID (33620225) ? Yakov. From owner-mpls@UU.NET Thu Oct 5 16:28:19 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06389 for ; Thu, 5 Oct 2000 16:28:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqf10166; Thu, 5 Oct 2000 20:27:34 GMT Received: by mail-control.mail.uu.net id QQjjqf24423 for mpls-outgoing; Thu, 5 Oct 2000 20:27:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjqf24411 for ; Thu, 5 Oct 2000 20:26:56 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqf13132 for ; Thu, 5 Oct 2000 16:26:34 -0400 (EDT) Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqf14207 for ; Thu, 5 Oct 2000 20:26:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA27468 for mpls@uu.net; Thu, 5 Oct 2000 16:26:32 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjqf24308 for ; Thu, 5 Oct 2000 20:26:08 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjqf05586 for ; Thu, 5 Oct 2000 20:24:51 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjjqf25217 for ; Thu, 5 Oct 2000 20:24:51 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA08361; Thu, 5 Oct 2000 13:24:47 -0700 (PDT) Message-ID: <39DCE38E.55F1459D@pluris.com> Date: Thu, 05 Oct 2000 13:24:47 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Yakov Rekhter CC: "Raftelis, Mike" , "'mpls@uu.net'" Subject: Re: Interface ID in kompella-unnum-02 References: <200010051921.MAA24664@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can we add one more bit to the message to indicate whether this is an ifindex vs IP address? Bora Yakov Rekhter wrote: > Mike, > > > Hello, > > In draft-kompella-mpls-unnum-02.txt, the interface ID field is shown > > to be 16 bits. Previous e-mails have suggested that the size be increased > > to 32 bits to match the SNMP ifIndex size. Can this be increased? > > Please bear in mind that the interface index (interface ID) is carried > not just in RSVP/CR-LDP, but in OSPF as well. > > In OSPF with unnumbered links interface ID is carried in the same field > as a plain IP address. At the same time one still need to be able to > distinguish between the case when this field carries an IP address and > the case when this field carries an interface ID. So if we allow interface > ID to be 32 bits, then when this field carries the value 33620225, is > that an IP address (2.1.1.1) or an interface ID (33620225) ? > > Yakov. From owner-mpls@UU.NET Thu Oct 5 16:35:25 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06466 for ; Thu, 5 Oct 2000 16:35:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqg06589; Thu, 5 Oct 2000 20:33:34 GMT Received: by mail-control.mail.uu.net id QQjjqg24801 for mpls-outgoing; Thu, 5 Oct 2000 20:33:01 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjqg24796 for ; Thu, 5 Oct 2000 20:32:57 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqg21549 for ; Thu, 5 Oct 2000 20:31:51 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqg26554 for ; Thu, 5 Oct 2000 20:31:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA28685 for mpls@uu.net; Thu, 5 Oct 2000 16:31:50 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjqg24687 for ; Thu, 5 Oct 2000 20:31:22 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqg18941 for ; Thu, 5 Oct 2000 20:30:43 GMT Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjjqg23989 for ; Thu, 5 Oct 2000 20:30:42 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA02771; Thu, 5 Oct 2000 13:30:41 -0700 (PDT) Message-Id: <200010052030.NAA02771@omega.cisco.com> To: "Connell, Jeff" cc: "'mpls@uu.net'" Subject: Re: Interface ID in kompella-unnum-02 In-reply-to: Your message of "Thu, 05 Oct 2000 15:11:28 CDT." <758F0C2C951CD411B15300D0B744446503BF51@192-168-1-220.customer.algx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2769.970777840.1@cisco.com> Date: Thu, 05 Oct 2000 13:30:41 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Jeff, > I may be wrong but.. > > The two values are never used in the same field without any other > indication, right? > > In a router-LSA, the router-ID is the IP of the router, and if the link type > is point-to-point, then this is indicated with the type field in the link > information. The Link Data field can either be a network mask(type 2 or 3) > or an ifIndex (type 1). (p133 RFC2328) Where else is the ifIndex used in > OSPF? For numbered p2p links (type 1) the Link Data field "specifies the IP interface address of the associated router interface" (p128 RFC2328). Yakov. From owner-mpls@UU.NET Thu Oct 5 16:44:52 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06582 for ; Thu, 5 Oct 2000 16:44:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqg10212; Thu, 5 Oct 2000 20:42:56 GMT Received: by mail-control.mail.uu.net id QQjjqg25574 for mpls-outgoing; Thu, 5 Oct 2000 20:42:27 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjqg25568 for ; Thu, 5 Oct 2000 20:42:22 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqg13418 for ; Thu, 5 Oct 2000 20:41:32 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqg17979 for ; Thu, 5 Oct 2000 20:41:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA00529 for mpls@uu.net; Thu, 5 Oct 2000 16:41:31 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjqg25372 for ; Thu, 5 Oct 2000 20:41:13 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqg17208 for ; Thu, 5 Oct 2000 16:40:58 -0400 (EDT) Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjjqg16905 for ; Thu, 5 Oct 2000 20:40:58 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA04240; Thu, 5 Oct 2000 13:40:56 -0700 (PDT) Message-Id: <200010052040.NAA04240@omega.cisco.com> To: "Thomas D. Nadeau" cc: kireeti@juniper.net, mpls@UU.NET, Mraftelis@WhiteRockNetworks.com Subject: Re: Interface ID in kompella-unnum-02 In-reply-to: Your message of "Thu, 05 Oct 2000 16:07:06 EDT." <4.3.2.7.2.20001005155723.00b74c90@bucket.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4237.970778456.1@cisco.com> Date: Thu, 05 Oct 2000 13:40:56 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Tom, [clipped...] > This is really not a good idea from a management perspective, > especially since all of the MIBs I know of that manage any > type of interface (including all of the MPLS MIBs) rely on the > ifIndex as indexes for many tables. How does one find the interface if > it does not correspond to the ifIndex in the Interfaces MIB? > > >Note that the requirements for SNMP indices are much stronger than > >for interface indices: they need to remain stable, reusing them can > >be an issue, etc., which is why ifIndexes tend to grow beyond 2^16. > > > >Note too that the interface index cannot be made bigger than 2^24; > >this is so that the distinction between IP addresses and interface > >indices is clear. Given that, and given the fact the SNMP ifIndexes > >can be 32 bits, ifIndexes are ruled out as potential interface > >indices. > > Personally, this seems like a flaw in the design. Feel free to go to the OSPF WG, and convince them to change OSPF to address what you perceived as "a flaw in the design". > The type ifIndex has been around for quite a long time. I don't see > how the ifIndex in OSPF/ISIS was allowed to use a different size while > claiming that one could put use an ifIndex from the Interfaces MIB. water under the bridge. Yakov. From owner-mpls@UU.NET Thu Oct 5 17:30:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07283 for ; Thu, 5 Oct 2000 17:30:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqj18399; Thu, 5 Oct 2000 21:29:46 GMT Received: by mail-control.mail.uu.net id QQjjqj11158 for mpls-outgoing; Thu, 5 Oct 2000 21:29:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjqj11151 for ; Thu, 5 Oct 2000 21:29:16 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqj23949 for ; Thu, 5 Oct 2000 17:29:13 -0400 (EDT) Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqj18956 for ; Thu, 5 Oct 2000 21:29:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA06855 for mpls@uu.net; Thu, 5 Oct 2000 17:29:12 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjqj11124 for ; Thu, 5 Oct 2000 21:28:50 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqj22892 for ; Thu, 5 Oct 2000 17:28:20 -0400 (EDT) Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqj17833 for ; Thu, 5 Oct 2000 21:28:19 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA06780 for ; Thu, 5 Oct 2000 17:28:17 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA09447 for ; Thu, 5 Oct 2000 17:28:17 -0400 (EDT) Message-Id: <200010052128.RAA09447@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Draft Minutes from Pittsburgh Date: Thu, 05 Oct 2000 17:28:17 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Minutes MPLS WG , Pittsburgh, Aug 2000 ====================================== Wednesday 9:00 - 11:30 1. A Banerjee kompella-mpls-ospf-extensions-00.txt kompella-mpls-ospf-extensions-00.txt These drafts specify extensions to the IS-IS/OSPF routing protocols in support of Multiprotocol Lambda Switching (MPL(ambda)S). In particular they specify TLVs describing the capabilities of links which can be used and signaled with gerenalized MPLS signaling. Proposal: Propose that drafts be accepted as WG document. George (as chair): Those drafts should actually be progressed as WG document in ISIS and OSPF WGs. They were presented in MPLS WG because they relate directly to documents that are the subject of MPLS. Banerjee: agreed. Will progress through ISIS and OSPF WGs. 2. Mannie mannie-mpls-sdh-ospf-isis-00 This draft specifies and suggests extensions to the OSPF and IS-IS routing protocols in order to support the routing of dynamically established SDH/SONET circuits using the MPLS architecture. It builds upon existing OSPF/ISIS extensions, proposing TLVs for routing of SDH and SONET circuits. It also proposes Bundling for scalability (see below). It also addresses interworking between SDH and SONET. An important challenge is to achieve the optimal balance between the amount of information need to make accurate routing decisions and the cost of advertising that information. There can be many "holes" fragmenting the capacity. Possible solutions: - advertise exactly what's allocated-->optimum but very large overhead - advertise min and max--> small overhead but difficult to optimize - propose compromise: advertise per type of signal what is available Some further challenges remain (e.g. scalability, factoring time constraints,..) Conclusion: - need to find compromise between optimum routing and scalability constraints of ISIS/OSPF Authors: will integrate OSPF/ISIS extensions with drafts to go to ISIS/OSPF WGs Ping: - this is a lot of info to advertise. Should some info not be distributed via SNMP or Policy otherwise it won't scale? Mannie: - Yes. There is a question as to whether ISIS/OSPF are the right protocols for all that. May be possible in small areas. Plan to do some simulations. 3. Bundling Two drafts were presented, kompella-mpls-bundle-02 and rs-optical-bundling-00. Disposition was deferred until both drafts were presented. Kompella kompella-mpls-bundle-02 This draft proposes bundling at the "protocol" level. This is necessary for routing scalability. Bundling at Layer 1/2, while scalable, defeats the purpose. A bundle does not make a bigger link of smaller links. It is simply a means to advertise many links more efficiently. The draft proposes a notion of Max LSP bandwidth as a means of masking the actual bandwidths on particular links. The Max LSP bandwidth is simply the bandwidth of the largest reservation that could be made at this point in time at a particular priority. Bundling can be used with Forwarding Adjacencies, and with unnumbered links. Also presented were the procedures associated with the use of Link Bundle and use of Max LSP Bw by Constraint Based Routing. Proposal: make this a WG document George (as chair): need first to get consensus on the approach and then split into different document for the different WGs. Curtis V: the LSP max bandwidth should depend on the LSP type(L3PID) because in some case you can split an LSP over the multiple links. Xxx: does this approach take into account delay? George: links with different delays have to be in different bundle. Saha rs-optical-bundling-00 The draft describes the issues that arise when optical links are bundled, and proposes a rule for bundling optical links. This work is complementary to the work of kompella-mpls-bundle-02. It proposes that Bundle be divided into sub-bundles (aka Bundle Groups). Kireeti: sub-bundle don't buy you much compared to TE bundle approach. They were useful with unnumbered links but this is supported with TE bundle. After a brief discussion, it was agreed that there was general consensus on using the approach outlined in the kompella draft without adding sub-bundles. New drafts for the appropriate work groups will be drafted. 4. Ashwood-Smith ashwood-generalized-mpls-signaling-00 http://www.labn.net/docs/gmpls.pdf has the presentation slides. In Adelaide a number of drafts on this subject that were presented. The authors of those drafts agreed to work together to produce framework, signaling and routing drafts. This draft represents a consolidation of the signaling aspects. GMPLS signaling involves extensions to RSVP-TE/CR-LDP to support traditional statistically multiplexed, time division, frequency division and space division-multiplexed paths. This draft describes a generalized label structure (generalized label request, generalized label, suggested label and label set) for MPLS and new functions: bi- directional LSP establishment, a generalized notification mechanism and ingress/egress binding. Generalized label request specifies the LSP encoding type, link protection type and G-PID. The generalized label travels in the RESV/Mapping message. It also supports traditional statistically muxed labels. It consists of a Link ID and Label. The Suggested Label is a generalized label that is given by an upstream node to a downstream node in a PATH/Request message. The downstream node should try to use this label and pass the same label back in the Mapping/RESV message. The Label Set is attached by an upstream to a Request/PATH message and is used to restrict the choice of the downstream node's label to this set. It is literally a set of generalized label objects. Lou Berger presented the new functions that are driven by generalized switching requirements. The bidirectional LSP is established by passing an upstream label in the Request/PATH message. There is a possibility of contention for the same label when both sides can allocate for the same direction. The notification function expedites notification of non-adjacent nodes of LSP events. E.g. may notify ingress of LSP failure to reduce latency of end-to-end failure recovery. Egress control enables the ingress of an LSP to control egress termination. This may be used to splice LSPs. A new "Egress Label" subobject has been defined. Going forward, the authors will: - investigate a better way to signal "LSP Encoding TLV" - verify SONET/SDH label formats - allow selection of time slots and lambdas via ERO - minor editorial and other fixes - incorporate feedback from this meeting Once the functionality is stable, they will split the draft to separate the functional description from protocol formats. Lou: proposal to accept this as WG document. George (as chair): Proposed to the group to accept as WG document. The document was accepted as a WG document. No objections from the floor. Floor: suggest to collaborate with ITU on Waveband definition Peter AS: 100% agreed 5. Guo sorrento-rsvp-bi-osp-00 This draft describes motivations for bidirectional setup of Optical paths: - faster set-up - optical continuity It proposes a proposal to reduce "contention" window to 1 hop (through ordering of labels). Proposal: move this into the generalized mpls signaling draft (in particular incorporate the pair-wise label allocation) Jonathan Lang: the contention window is actually removed with the "label suggestion" or "label set" capabilities of generalized mpls signaling. So the proposal to reduce the contention window is no longer useful. George (as chair): continue discussion on mailing list about whether some material from sorrento-rsvp-bi-osp-00 should go into generalized mpls signaling. 6. Bala bala-mpls-optical-uni-signaling-00 This draft reflects work at the OIF. This draft addresses the "domain services" model for an optical network. Under this model, the optical network provides a set of well-defined services to clients (IP and others). The signaling and routing interface between the client and optical networks is referred to as the User-Network Interface (UNI). This draft describes the services provided over the UNI, and the requirements on any signaling protocol used to invoke the services. It considers both direct and indirect interfaces. It defines abstract UNI messages and associated parameters The objective in presenting this work here is to: - Guide development of MPLambaS protocols - Harmonize extensions with OIF Conclusion: - identifies a MPLambdaS subset to allow support of a simple UNI which can later be expanded - note that the draft reflects ongoing work in the OIF and is still work in progress Bala: where does this draft belong? George (as chair): It is useful to have information from the OIF presented here. The draft itself is not something to adopt here. Rather it should be reflected into the actual MPLS WG drafts (i.e. extensions to RSVP-TE and CR-LDP for UNI). We encourage you to keep bringing up-to-date information on status of OIF work as guidance to this group. Ping P: this is similar to RSVP-to-ATM, and UNI concept is not useful Bala: this is not quite the same thing as ATM, and UNI is useful to define interface requirements. 7. Aboulmagd aboulmagd-mpls-ldp-optical-uni-00 Create, Delete, Modify and Status Enquiry actions are possible across the O-UNI. This draft argues that LDP already has well defined messages to support the O-UNI and there is no need to invent yet another protocol. A proposal was made to consider this draft as a WG document. Xxx: a comment was made that if the IETF is going to follow the OIF's recommendations, and the OIF was expecting to introduce major changes to the definition of the UNI. So this is definitely work-in-progress at the OIF. Ross Callon: what is the relationship to the generalized signaling draft? Osama responded that they plan on using as many of the mechanisms specified in that draft as possible and the intent was not duplicate work. Peter Ashwood-Smith stated that it is good idea to adopt the document as a WG document. Lou Berger: recommended coordination with the generalized draft. The document was accepted as a WG document without objection. 8. Lang lang-mpls-lmp-01 Why link management: The control channel may be on a different medium/link than the component links being controlled. LMP includes control channel management, link connectivity verification, link property correlation and fault isolation. The presentation described the major changes from the -00 version of the draft. The proposal was made to advance the draft to WG document status. Greg Bernstein: wanted to do link verification and fault management differently for SONET than what is specified in LMP. He wanted to know whether we should change the applicability statement for the LMP draft. George said that this should be explicitly stated in the document. The document was unanimously adopted as a WG work item. 9. Nadeau nadeau-mpls-packet-classifier-mib-01 The goal is to provide FEC to NHLFE mapping for MPLS LSRs. This is motivated by customer requirements to specify how packets enter the MPLS domain. The new version is based on comments on the mailing list, requesting simplifications. The ClassifierTable defines rules to compare against incoming packets and an action to be taken on matching packets. The PerfTable contains performance statistics on packet classifiers on a per interface table. Tom asked that the MPLS WG adopt this draft a WG work item. The request was approved without objection. Thursday 9:00 - 11:30 10. Le Faucher ietf-mpls-diff-ext-06 First last call on version -05 resulted in a number of comments. These have been addressed in the -06 version. Second last call resulted in one comment on the list related to backward compatibility with LSPs established with pre-Diff-Ext RSVP QoS. A compromise solution was worked out on the mailing list. Francois presented the details of this solution. Francois proposed that we incorporate the text of the resolution in version -07 and he believes that the document is ready to be sent to the ADs for IESG last call. There were no comments or questions. 11. Le Faucher lefaucheur-diff-te-reqts-00 lefaucheur-diff-te-ext-00 Requirements for support of Diff-Serv-aware MPLS TE The requirements draft was presented in the TE WG; the authors are driving corresponding protocols extensions in the respective WGs (MPLS, OSPF, IS-IS). Current MPLS TE performs constraint based routing on a single bandwidth constraint. With Diffserv, there are additional requirements to ensure the QoS of each class. These constraints cannot be enforced by current TE model based on a single bandwidth constraint. This requires extensions to current IGPs to propagate per-class information. The question was raised whether this information would place a burden on IGP scalability. The proposal suggests to aggregate a group of classes into a class-type for scalability improvements in IGP flooding. ISIS/OSPF Requirements - minimize impact on scalability - Constraint based routing should be able to enforce different Max Reservable BW for each class type and retains existing concept of preemption - CBR should enforce different Max Reservable BW for each Class Type AND enforce an Aggregate Max Reservable BW - Support for up to 3 additional Class Types - IGPs to only advertise the subset of CTs actually used RSVP/CR-LDP Requirements - Signal CT at tunnel establishment - Backward Compatibility CBR Reqs - CBR to take into account different unreserved bw for each CT - CBR may also take into account other constraints for each CT Francois then went through the protocol extensions to RSVP, CR-LDP. Then he made the proposal that the MPLS WG hosts the work on RSVP-TE, CR-LDP and MPLS MIB extensions. The Requirements would be worked on the TE WG. He also proposed that MPLS accept the reqts-00.txt as a WG document until it is better homed, and the RSVP/CR-LDP/MIB material of ext-00.txt as WG document. The first part of the proposal was accepted by the WG. Dave Oran asked that the proposal be posted to the Routing Discussion group. The group also agreed to accept the RSVP/CR-LDP/MIB material as a WG work item. The final proposal regarding accepting the -reqts-00.txt was also accepted, based on the understanding that this may get rearranged once the work gets distributed among the appropriate work groups. Curtis asked whether the drafts need to be dissected. Francois responded that the OSPF and IS-IS extensions need to be broken off into a separate draft. 12. Sharma draft-makam-mpls-recovery-frmwrk-01.txt This draft provides a framework for MPLS recovery. It also proposes some evaluation criteria for solutions. The draft has been evolving for some time. This is the latest update. Proposal: to accept as WG document on track towards Informational RFC. George (as chair): There may be a broader-scope document on recovery as part of the new Routing Area/Control Plane WG. This document applies only to MPLS. However there is material in this document that would be appropriate for a broader-scope document. Dinesh B: there are a few inconsistencies/redundancies in draft. Will discuss on list. Dave O (AD): what is meant by "extensible to Optical" in draft? George (as chair): just means that the kind of definitions/procedures could be reused in a separate document for Optical Dave O: please send comment on what work belongs where on the routing area list. The draft was accepted as a WG document. 11. Sharma Path protection Two related drafts were presented. The first describes the mechanisms. The second describes protocol extentions for RSVP-TE. The primary mechanism is the use of a Reverse Notification Tree (RNT) which is a set of LSP in the reverse direction which merge together as they intersect on their path to the head end of the tunnels. A. draft-chang-mpls-path-protection-01.txt Changes since last version: - Better defined scope, motivations... - Completed the features to provide complete solution - recognized that solution works for both physically and virtually merged LSPs - reduced number of timers - ideas for future extensions: - mesh based protection, pre-qualified protection - priority, preemption - unify ideas for notification mechanisms B. draft-chang-mpls-path-protection-ext-00.txt New attribute for EXPLICIT_Route object for path setup and RNT config Added LABEL_REQUEST object to existing messages Open Issues: - where to encode protection options Proposal: - move Mechanism draft to WG document - merge RSVP-TE extensions draft with existing RSVP-TE spec xxx: concern with reverse notification tree for failure notification because itself can be subject to failure Sharma: there is no activity involved in maintaining the reverse notification tree. It is only states in the hops. Xxx: so we cannot reliably know if the reverse notification tree is actually up or not. Ping: why define new messages than PathErr or ResvErr? Sharma: see draft. In particular there is not enough space in error field. Ping: doesn't see why it cannot be achieved via existing messages with new codes. Kireeti: would like to think more on scheme (eg scalability) before it is accepted George (as chair): More discussion to take place before making this a WG document. Since we cannot spend more time on this today, the discussion is to be continued on the list. 12. Matthews brittain-mpls-ldp-ft-00 LDP extensions for Fault Tolerance: Within an LSR, want to switch from one LDP stack to another LDP stack without affecting data flow. Specific examples of applicability are for software upgrade, and for failure-handling such as switching to a backup control processor. Solution: - Let old TCP connection die - establish new TCP conn and indicate "continue old session".. defines : - Sequence numbers and Ack (for Fault Tolerant LSPs) - Re-sending missed messages Optional extension to LDP, negotiated as session initialization time Proposal: - that draft be accepted as WG document Dave O: did you look at SCTP for transport of LDP rather than TCP? Xxx: there has been discussion on list concluding that SCTP was not mature. Dave O: would have concluded differently. Let's talk. Eric R: we shouldn't change the underlying transport protocol for LDP for which TCP has been standardized for a long time. Xxx: do we need to standardize such mechanisms which achieve Fault Tolerance inside a box? cannot inside-the-box mechanisms achieve FT? Phillip M: makes FT a lot simpler, very hard to achieve FT with TCP The draft accepted as WG document without objection. 13. Reichmeyer franr-mpls-cops-00 COPS usage for MPLS/TE Kick off policy discussion took place in the MPLS WG in Adelaide. Not a lot of interest then. This draft provides more details to see if there is more interest now in MPLS WG. The draft describes the application of the COPS for Provisioning COPS-PR) protocol for managing TE. Just to manage TE: - tunnel set-up - classification of packets onto tunnels - LSP tunnel perf monitoring (eg if LSP more than 80% full, setup another,...) - Notification Policy Management Model: - COPS-RSVP or COPS-PR? - needs to work for RSVPTE and CRLDP - policy-wise RSVPTE different from RSVP Solution proposed in draft is based on COPS-PR. May not be the best model. Describes: - COPS-MPLS model (with PDP) - exchange between PDP and LSR - policy on a per-interface basis Proposal: - is there interest in the WG - adopt as WG draft George: - policy is not in our charter - should be driven top-down from the policy Eric R: this does not achieve anything that cannot be achieved by existing mechanism (eg SNMP) Reichmeyer: it optimizes such control Curtis: TE in real world does not need policy Brian Carpenter: from IAB, there is not a stable language to specify PIB yet so it does not make sense to specify a PIB for different applications until such language is stable enough. Draft is not accepted as WG document. Declerc schrijvp-mpls-end-to-end-auth-01 Objective is to achieve end-to-end Auth between Label Edge Routers. Two procedures (and associated TLVs) described: - challenge - digital certificate Proposal: - adopt draft as WG document Dave O: let's assume you have security mechanisms on intermediate LSRs. Do you need to set-up e2e authorization in situations where you don't have transitive trust relationship with intermediate LSRs? Floor: Yes, it is needed Xxx: agree that there is a need for e2e auth. Would prefer a solution that would not require message to go 2ways. Declerc: 2nd method achieves that Vijay (as Chair): There is agreement in room that this is appropriate item of work for WG. More discussion on mailing list on solutions before making it a WG document. 14. Iwata fujita-mpls-crldp-crankback-01 Crankback useful for rerouting upon setup blocking and for restoration of failed LSP Changes from previous draft include discussion (in section 2) of explicit vs implicit rerouting indication. Discuss some limits of implicit indication (in some cases does not give sufficient info to achieve rerouting) Proposes that Explicit notification be used, with following information encoded in new Codepoint of Status TLV - where blocking occurs (link ID) - whether alternate routing should be attempted Proposal: - accept draft as WG document for crankback extension to CR-LDP, OR - merge with mpls-cr-ldp-00.txt Billel: not clear what you achieve that cannot be done via te-feed. Iwata: te-feed is limited intra-area Crankback draft was accepted as a WG document without objection. 15. Ashwood-Smith daft-ietf-mpls-te-feed-01 This draft aims at improving topology database accuracy with LSP feed-back. Bandwidth information is fed back to upstream nodes during LSP set-up and set-up failure. The draft was first presented in Oslo, and was accepted as WG document. Two type of comments: - do not re-advertise info that you learned through feed-back --> this is agreed and addressed now - questions about race conditions. Act ---> it actually doesn't matter who win the race only works within single area, there is room for other mechanisms that work inter-area (such as crankback) Future: - could extend for Diff-Serv-aware capability - could incorporate some comments from mannie et al xxx: would it not be useful to feed update info in both directions. Peter AS: evaluated ideas to send feed-back in both directions and also to snoop on feed-back on intermediate nodes. Simulation showed that these other variations did not add much. 16. Peter AS paraschiv-mpls-lsp-query-00 LSP Query for LDP/CR-LDP. Provide extensive information on established LSPs (path, label at each hop, free bw at each hop, merge points, future:delay estimates...) Adds a Query Object, with a flag for each info requested. Query could travel on Label Request or Query Message. Query Reply traveling on both Query Reply message and Label Mapping message Proposal: - to accept as WG document - to be used to accumulate LSP and CRLDP query requirements and protocols (eg ASON/Optical) Eric Gray: have you considered what happens if an LSR does not support this? Peter AS: no but it should be addressed. Draft accepted as WG document without objection. 17. Theimer theimer-tcrtp-mpls-00 Tunneling Compressed RTP in MPLS. Targeted for VoIP Trunking from GW to GW. Started from work in AVT to transport compressed RTP in L2TP. Tunneling Compressed RTP in MPLS has benefits over L2TP approach: - better overhead - remove header processing overhead - get MPLS QoS benefits - get MPLS protection benefits There are existing proposals for Header Compression with MPLS. This draft focuses on end-2-end compression. End-2-end Compression has many benefits over hop-by-hop. The solution proposed in draft achieves 80-90% compression but is fairly complex. By contrast, draft-swallow-,... achieves 52% but is simpler. Operations: - use a pair of unidirectional LSPs or use bidirectional LSP setup if/when supported, - defines a mechanisms to establish compression over LSP - apply path constraints to get low-loss - signaling extensions to RSVP-TE Some issues: - state synchronization in case of packet loss, should be avoided by path-constraints - complexity is no worse than hop-by-hop - possible reordering Proposal: - it should become a WG document Andy: points out that draft-Martini provides a mechanisms for transport of PPP over MPLS that can be used. Dave O: although processing is same between e2e and hop-by-hop it would be spent in different locations which matters. Lou B: there is a need for both e2e and hop-by-hop anyway. The draft was accepted as a work group draft. 18. Berger ietf-mpls-hdr-comp-over-ppp-00 ietf-mpls-hdr-comp-00 Changes from Adelaide: - Draft-name - resolved a bit naming collision - draft does not assume or preclude support of CRTP enhancements Again the end-to-end and hop-by-hop approaches are useful: one is CPU intensive and efficient, one is simple and less efficient. Vijay: had felt that in Adelaide although it was not stated, it was implied that this draft were accepted as WG document. Lou: thought it was said but it is not clear in the minutes anyway. The drafts are now accepted as WG document. 19. Leu leu-mpls-ldp-label-aggregation-00 The motivation for this draft is to conserve the number of LSPs needed in a network by aggregating multiple FECs over a single label. Thus a single LSP carries multiple FECs. This is particularly useful in ATM since the number of available LSPs may be limited. Proposal: - accept as WG document Curtis: cannot merge LSPs/FECs with different QoS/Diff-Serv Leu: agreed. Vijay: could you not achieve this via a new FEC (eg BGP Next Hop) Peter AS: could it be implemented in the Linux implementation to demonstrate the benefits. Ross C: this was discussed some time ago in the context of LDP and it was concluded that you could achieve that by only advertising the address of the egress router. Chairs: More discussion on the list required to clarify applicability and demo implementation would be very useful. Until it's utility can be demonstrated, the document is not accepted. From owner-mpls@UU.NET Thu Oct 5 18:14:05 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07741 for ; Thu, 5 Oct 2000 18:14:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqm17006; Thu, 5 Oct 2000 22:12:49 GMT Received: by mail-control.mail.uu.net id QQjjqm25423 for mpls-outgoing; Thu, 5 Oct 2000 22:12:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjqm25418 for ; Thu, 5 Oct 2000 22:12:16 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjqm29770 for ; Thu, 5 Oct 2000 18:12:14 -0400 (EDT) Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjjqm14122 for ; Thu, 5 Oct 2000 22:12:14 GMT Received: from tellium.com (node1.tellium.com [151.198.92.15]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e95M4mm18201; Thu, 5 Oct 2000 18:04:48 -0400 (EDT) Message-ID: <39DD0A4D.F4E820D6@tellium.com> Date: Thu, 05 Oct 2000 18:10:05 -0500 From: Debanjan Saha Organization: Tellium Optical Systems X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: George Swallow CC: mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: <200010052128.RAA09447@lir.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > 3. Bundling < stuff deleted> > Kompella kompella-mpls-bundle-02 > Saha rs-optical-bundling-00 > < stuff deleted > > After a brief discussion, it was agreed that there was general > consensus on using the approach outlined in the kompella draft without > adding sub-bundles. New drafts for the appropriate work groups will > be drafted. > I don't remember any such consensus on using the approach outlined in the kompella draft. Regards, Debanjan -- Debanjan Saha Phone: 732-923-4264 Senior Network Architect Fax: 732-923-9804 Tellium Optical Systems http://www.tellium.com From owner-mpls@UU.NET Thu Oct 5 18:28:21 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07901 for ; Thu, 5 Oct 2000 18:28:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqn15508; Thu, 5 Oct 2000 22:27:18 GMT Received: by mail-control.mail.uu.net id QQjjqn26419 for mpls-outgoing; Thu, 5 Oct 2000 22:26:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjqn26408 for ; Thu, 5 Oct 2000 22:26:24 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqn01337 for ; Thu, 5 Oct 2000 18:26:14 -0400 (EDT) Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqn05402 for ; Thu, 5 Oct 2000 22:26:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA13173 for mpls@uu.net; Thu, 5 Oct 2000 18:26:13 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjqn26279 for ; Thu, 5 Oct 2000 22:25:40 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqn08539 for ; Thu, 5 Oct 2000 22:24:35 GMT Received: from lumen.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjjqn03267 for ; Thu, 5 Oct 2000 22:24:35 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id <4GPVT84P>; Thu, 5 Oct 2000 15:24:31 -0700 Message-ID: From: John Drake To: "'Debanjan Saha'" , George Swallow Cc: mpls@UU.NET Subject: RE: Draft Minutes from Pittsburgh Date: Thu, 5 Oct 2000 15:24:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02F1B.032D3250" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C02F1B.032D3250 Content-Type: text/plain; charset="iso-8859-1" Debanjan, I remember George making this statement as his assessment of the presentations and subsequent discussion, and I don't remember anyone challenging George on it. Thanks, John -----Original Message----- From: Debanjan Saha [mailto:dsaha@tellium.com] Sent: Thursday, October 05, 2000 4:10 PM To: George Swallow Cc: mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh > > 3. Bundling < stuff deleted> > Kompella kompella-mpls-bundle-02 > Saha rs-optical-bundling-00 > < stuff deleted > > After a brief discussion, it was agreed that there was general > consensus on using the approach outlined in the kompella draft without > adding sub-bundles. New drafts for the appropriate work groups will > be drafted. > I don't remember any such consensus on using the approach outlined in the kompella draft. Regards, Debanjan -- Debanjan Saha Phone: 732-923-4264 Senior Network Architect Fax: 732-923-9804 Tellium Optical Systems http://www.tellium.com ------_=_NextPart_001_01C02F1B.032D3250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Draft Minutes from Pittsburgh

Debanjan,

I remember George making this statement as his = assessment of the presentations and subsequent discussion, and I don't = remember anyone challenging George on it.

Thanks,

John


-----Original Message-----
From: Debanjan Saha [mailto:dsaha@tellium.com]
Sent: Thursday, October 05, 2000 4:10 PM
To: George Swallow
Cc: mpls@UU.NET
Subject: Re: Draft Minutes from Pittsburgh





>
> 3.  Bundling

  < stuff deleted>

> Kompella    = kompella-mpls-bundle-02
> Saha        = rs-optical-bundling-00
>
   < stuff deleted >

> After a brief discussion, it was agreed that = there was general
> consensus on using the approach outlined in the = kompella draft without
> adding sub-bundles.  New drafts for the = appropriate work groups will
> be drafted.
>

I don't remember any such consensus on using the = approach outlined
in the kompella draft.

Regards,
Debanjan

--
Debanjan = Saha           &n= bsp;           &n= bsp; Phone: 732-923-4264
Senior Network = Architect          &nb= sp;   Fax:   732-923-9804
Tellium Optical = Systems           = ;    http://www.tellium.com

------_=_NextPart_001_01C02F1B.032D3250-- From owner-mpls@UU.NET Thu Oct 5 18:30:40 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07968 for ; Thu, 5 Oct 2000 18:30:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqn10609; Thu, 5 Oct 2000 22:29:56 GMT Received: by mail-control.mail.uu.net id QQjjqn26586 for mpls-outgoing; Thu, 5 Oct 2000 22:29:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjqn26578 for ; Thu, 5 Oct 2000 22:29:36 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjqn01749 for ; Thu, 5 Oct 2000 18:29:19 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQjjqn09651 for ; Thu, 5 Oct 2000 22:29:19 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <4K2DA2HM>; Thu, 5 Oct 2000 15:29:40 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6625D8AA7@ICARIAN> From: Eric Gray To: "'George Swallow'" Cc: mpls@UU.NET Subject: RE: Draft Minutes from Pittsburgh Date: Thu, 5 Oct 2000 15:29:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk George, One quick comment on the draft minutes. > --- --- > > Minutes MPLS WG , Pittsburgh, Aug 2000 > ====================================== > > > Wednesday 9:00 - 11:30 > > > 1. A Banerjee kompella-mpls-ospf-extensions-00.txt > kompella-mpls-ospf-extensions-00.txt I think one of these should have been "-isis-", right? > > --- --- From owner-mpls@UU.NET Thu Oct 5 19:03:24 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08548 for ; Thu, 5 Oct 2000 19:03:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqq20292; Thu, 5 Oct 2000 23:01:43 GMT Received: by mail-control.mail.uu.net id QQjjqq03707 for mpls-outgoing; Thu, 5 Oct 2000 23:01:17 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjqq03619 for ; Thu, 5 Oct 2000 23:01:15 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqq05204 for ; Thu, 5 Oct 2000 19:01:08 -0400 (EDT) Received: from field.videotron.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: field.videotron.net [205.151.222.108]) id QQjjqq02112 for ; Thu, 5 Oct 2000 23:01:08 GMT Received: from MartinPicard ([24.202.8.238]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with SMTP id <0G1Z0029BBXV7U@field.videotron.net> for mpls@UU.NET; Thu, 5 Oct 2000 19:01:07 -0400 (EDT) Date: Thu, 05 Oct 2000 18:53:57 -0400 From: Martin Picard Subject: F/R & ATM over MPLS To: mpls@UU.NET Message-id: <002401c02f1f$25508720$ee08ca18@videotron.ca> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Priority: 3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, A while back, I heard that F/R and ATM could be transparently carried over an MPLS network. Is this feasible, available ? How does it work ? Why would you do it ? Thanks in advance. Martin From owner-mpls@UU.NET Thu Oct 5 19:11:32 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08642 for ; Thu, 5 Oct 2000 19:11:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqq21433; Thu, 5 Oct 2000 23:09:50 GMT Received: by mail-control.mail.uu.net id QQjjqq10344 for mpls-outgoing; Thu, 5 Oct 2000 23:09:30 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjqq10337 for ; Thu, 5 Oct 2000 23:09:17 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqq05938 for ; Thu, 5 Oct 2000 19:09:14 -0400 (EDT) Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqq20039 for ; Thu, 5 Oct 2000 23:09:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA17665 for mpls@uu.net; Thu, 5 Oct 2000 19:09:13 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjqq10323 for ; Thu, 5 Oct 2000 23:08:48 GMT Received: from cmr0.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqq05671 for ; Thu, 5 Oct 2000 19:08:31 -0400 (EDT) Received: from ce-nfs-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjjqq18400 for ; Thu, 5 Oct 2000 23:08:30 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA28025; Thu, 5 Oct 2000 16:08:21 -0700 (PDT) Date: Thu, 5 Oct 2000 16:02:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <17668.001005@cisco.com> To: "Connell, Jeff" CC: "'mpls@uu.net'" Subject: Re: Interface ID in kompella-unnum-02 In-reply-To: <758F0C2C951CD411B15300D0B744446503BF51@192-168-1-220.customer.algx.net> References: <758F0C2C951CD411B15300D0B744446503BF51@192-168-1-220.customer.algx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jeff, > I may be wrong but.. > The two values are never used in the same field without any other > indication, right? Wrong. For p2p interfaces we have link-type set to 1, but we set link ID to IP addr of the interface or its ifIndex depending on whether it's numbered or not. Alex. > In a router-LSA, the router-ID is the IP of the router, and if the link type > is point-to-point, then this is indicated with the type field in the link > information. The Link Data field can either be a network mask(type 2 or 3) > or an ifIndex (type 1). (p133 RFC2328) Where else is the ifIndex used in > OSPF? > Jeff. > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@cisco.com] > Sent: Thursday, October 05, 2000 2:22 PM > To: Raftelis, Mike > Cc: 'mpls@uu.net' > Subject: Re: Interface ID in kompella-unnum-02 > Mike, >> Hello, >> In draft-kompella-mpls-unnum-02.txt, the interface ID field is shown >> to be 16 bits. Previous e-mails have suggested that the size be increased >> to 32 bits to match the SNMP ifIndex size. Can this be increased? > Please bear in mind that the interface index (interface ID) is carried > not just in RSVP/CR-LDP, but in OSPF as well. > In OSPF with unnumbered links interface ID is carried in the same field > as a plain IP address. At the same time one still need to be able to > distinguish between the case when this field carries an IP address and > the case when this field carries an interface ID. So if we allow interface > ID to be 32 bits, then when this field carries the value 33620225, is > that an IP address (2.1.1.1) or an interface ID (33620225) ? > Yakov. From owner-mpls@UU.NET Thu Oct 5 19:18:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08755 for ; Thu, 5 Oct 2000 19:18:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqr13642; Thu, 5 Oct 2000 23:16:56 GMT Received: by mail-control.mail.uu.net id QQjjqr11162 for mpls-outgoing; Thu, 5 Oct 2000 23:16:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjqr11157 for ; Thu, 5 Oct 2000 23:16:25 GMT Received: from cmr0.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqr06256 for ; Thu, 5 Oct 2000 19:15:17 -0400 (EDT) Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqr02278 for ; Thu, 5 Oct 2000 23:15:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA18486 for mpls@uu.net; Thu, 5 Oct 2000 19:15:16 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjqq10810 for ; Thu, 5 Oct 2000 23:14:56 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqq06496 for ; Thu, 5 Oct 2000 19:14:42 -0400 (EDT) Received: from ce-nfs-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjjqq01052 for ; Thu, 5 Oct 2000 23:14:41 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA02218; Thu, 5 Oct 2000 16:14:35 -0700 (PDT) Date: Thu, 5 Oct 2000 16:08:53 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <3672.001005@cisco.com> To: Alex Zinin CC: "Connell, Jeff" , "'mpls@uu.net'" Subject: Re: Interface ID in kompella-unnum-02 In-reply-To: <17668.001005@cisco.com> References: <17668.001005@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Jeff, >> I may be wrong but.. >> The two values are never used in the same field without any other >> indication, right? > Wrong. > For p2p interfaces we have link-type set to 1, but > we set link ID to IP addr of the interface or its ifIndex I meant link data. Alex. > depending on whether it's numbered or not. > Alex. >> In a router-LSA, the router-ID is the IP of the router, and if the link type >> is point-to-point, then this is indicated with the type field in the link >> information. The Link Data field can either be a network mask(type 2 or 3) >> or an ifIndex (type 1). (p133 RFC2328) Where else is the ifIndex used in >> OSPF? From owner-mpls@UU.NET Thu Oct 5 19:42:27 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08916 for ; Thu, 5 Oct 2000 19:42:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqs06138; Thu, 5 Oct 2000 23:41:39 GMT Received: by mail-control.mail.uu.net id QQjjqs12437 for mpls-outgoing; Thu, 5 Oct 2000 23:41:07 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjqs12372 for ; Thu, 5 Oct 2000 23:40:51 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqs04987 for ; Thu, 5 Oct 2000 23:40:48 GMT Received: from alpha.tellium.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjjqs04981 for ; Thu, 5 Oct 2000 23:40:47 GMT Received: from tellium.com (node1.tellium.com [151.198.92.15]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e95NXIm21517; Thu, 5 Oct 2000 19:33:18 -0400 (EDT) Message-ID: <39DD118B.3B3929F3@tellium.com> Date: Thu, 05 Oct 2000 19:40:59 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Drake CC: "'Debanjan Saha'" , George Swallow , mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: Content-Type: multipart/alternative; boundary="------------67591628929FFD327268FBA2" Sender: owner-mpls@UU.NET Precedence: bulk --------------67591628929FFD327268FBA2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, It's hard to recall what exactly happened, but we do believe that this topic deserves further discussion. Especially since previously unstated support for OSPF flooding optimization are now part of the overall picture of bundling proposed by draft-kompella. I hope we can do this in the upcoming meeting. Regards, Bala John Drake wrote: > > > Debanjan, > > I remember George making this statement as his assessment of the > presentations and subsequent discussion, and I don't remember anyone > challenging George on it. > > Thanks, > > John > > -----Original Message----- > From: Debanjan Saha [mailto:dsaha@tellium.com] > Sent: Thursday, October 05, 2000 4:10 PM > To: George Swallow > Cc: mpls@UU.NET > Subject: Re: Draft Minutes from Pittsburgh > > > > > > > > 3. Bundling > > < stuff deleted> > > > Kompella kompella-mpls-bundle-02 > > Saha rs-optical-bundling-00 > > > < stuff deleted > > > > After a brief discussion, it was agreed that there was general > > consensus on using the approach outlined in the kompella draft > without > > adding sub-bundles. New drafts for the appropriate work groups will > > > be drafted. > > > > I don't remember any such consensus on using the approach outlined > in the kompella draft. > > Regards, > Debanjan > > -- > Debanjan Saha Phone: 732-923-4264 > Senior Network Architect Fax: 732-923-9804 > Tellium Optical Systems http://www.tellium.com -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com --------------67591628929FFD327268FBA2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

It's hard to recall what exactly happened, but we do believe
that this topic deserves further discussion. Especially since
previously unstated support for OSPF flooding optimization
are now part of the overall picture of bundling proposed
by draft-kompella. I hope we can do this in the upcoming
meeting.

Regards,

Bala

John Drake wrote:

 

Debanjan,

I remember George making this statement as his assessment of the presentations and subsequent discussion, and I don't remember anyone challenging George on it.

Thanks,

John

-----Original Message-----
From: Debanjan Saha [mailto:dsaha@tellium.com]
Sent: Thursday, October 05, 2000 4:10 PM
To: George Swallow
Cc: mpls@UU.NET
Subject: Re: Draft Minutes from Pittsburgh
 
 
 

>
> 3.  Bundling

  < stuff deleted>

> Kompella    kompella-mpls-bundle-02
> Saha        rs-optical-bundling-00
>
   < stuff deleted >

> After a brief discussion, it was agreed that there was general
> consensus on using the approach outlined in the kompella draft without
> adding sub-bundles.  New drafts for the appropriate work groups will
> be drafted.
>

I don't remember any such consensus on using the approach outlined
in the kompella draft.

Regards,
Debanjan

--
Debanjan Saha                         Phone: 732-923-4264
Senior Network Architect              Fax:   732-923-9804
Tellium Optical Systems               http://www.tellium.com

--

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: braja@tellium.com
  --------------67591628929FFD327268FBA2-- From owner-mpls@UU.NET Thu Oct 5 19:45:09 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08928 for ; Thu, 5 Oct 2000 19:45:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqs14526; Thu, 5 Oct 2000 23:44:30 GMT Received: by mail-control.mail.uu.net id QQjjqs12682 for mpls-outgoing; Thu, 5 Oct 2000 23:44:09 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjqs12677 for ; Thu, 5 Oct 2000 23:44:05 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqs12119 for ; Thu, 5 Oct 2000 23:43:54 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqs09246 for ; Thu, 5 Oct 2000 23:43:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA21119 for mpls@uu.net; Thu, 5 Oct 2000 19:43:53 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjqs12647 for ; Thu, 5 Oct 2000 23:43:32 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqs08151 for ; Thu, 5 Oct 2000 23:42:09 GMT Received: from ce-nfs-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjjqs06973 for ; Thu, 5 Oct 2000 23:42:09 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA22176; Thu, 5 Oct 2000 16:42:06 -0700 (PDT) Date: Thu, 5 Oct 2000 16:36:23 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <19691.001005@cisco.com> To: "Thomas D. Nadeau" CC: Kireeti Kompella , mpls@UU.NET, Mraftelis@WhiteRockNetworks.com Subject: Re: Interface ID in kompella-unnum-02 In-reply-To: <4.3.2.7.2.20001005155723.00b74c90@bucket.cisco.com> References: <4.3.2.7.2.20001005155723.00b74c90@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thomas, >>Note too that the interface index cannot be made bigger than 2^24; >>this is so that the distinction between IP addresses and interface >>indices is clear. Given that, and given the fact the SNMP ifIndexes >>can be 32 bits, ifIndexes are ruled out as potential interface >>indices. > Personally, this seems like a flaw in the design. The type > ifIndex has been around for quite a long time. I don't see how > the ifIndex in OSPF/ISIS was allowed to use a different size > while claiming that one could put use an ifIndex from the Interfaces > MIB. I don't want confusion here, so let's clarify a bit. ifIndex is 32-bit, so is the Link Data field in OSPF router-LSA. So OSPF is fine, actually. You won't find "IfIndex" in ISIS spec :) But in fact we're not much concerned about legacy OSPF/ISIS, we should be talking about TE extensions. And they also use 32 bits. So, the size is fine again :) Alex. From owner-mpls@UU.NET Thu Oct 5 19:55:16 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09108 for ; Thu, 5 Oct 2000 19:55:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjqt07020; Thu, 5 Oct 2000 23:54:28 GMT Received: by mail-control.mail.uu.net id QQjjqt13409 for mpls-outgoing; Thu, 5 Oct 2000 23:54:09 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjqt13402 for ; Thu, 5 Oct 2000 23:54:08 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjqt03731 for ; Thu, 5 Oct 2000 23:53:55 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjqt21928 for ; Thu, 5 Oct 2000 23:53:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA22353 for mpls@uu.net; Thu, 5 Oct 2000 19:53:54 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjqt13384 for ; Thu, 5 Oct 2000 23:53:27 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjqt09642 for ; Thu, 5 Oct 2000 19:53:16 -0400 (EDT) Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjjqt04264 for ; Thu, 5 Oct 2000 23:53:15 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA29063; Thu, 5 Oct 2000 16:53:13 -0700 (PDT) Message-Id: <200010052353.QAA29063@omega.cisco.com> To: Martin Picard cc: mpls@UU.NET Subject: Re: F/R & ATM over MPLS In-reply-to: Your message of "Thu, 05 Oct 2000 18:53:57 EDT." <002401c02f1f$25508720$ee08ca18@videotron.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29061.970789992.1@cisco.com> Date: Thu, 05 Oct 2000 16:53:12 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Martin, > A while back, I heard that F/R and ATM could > be transparently carried over an MPLS network. > Is this feasible, available ? yes to both. > How does it work ? see draft-martini-l2circuit-trans-mpls-03.txt. Yakov. From owner-mpls@UU.NET Fri Oct 6 00:33:57 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13141 for ; Fri, 6 Oct 2000 00:33:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjrm12791; Fri, 6 Oct 2000 04:33:15 GMT Received: by mail-control.mail.uu.net id QQjjrm25969 for mpls-outgoing; Fri, 6 Oct 2000 04:32:59 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjrm25964 for ; Fri, 6 Oct 2000 04:32:48 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjrm03219 for ; Fri, 6 Oct 2000 00:32:34 -0400 (EDT) Received: from gateway.ntu.edu.sg by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.1.127]) id QQjjrm12269 for ; Fri, 6 Oct 2000 04:32:33 GMT Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id <4C3BTM4Y>; Fri, 6 Oct 2000 12:31:21 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE01FDD100@exchange4.ntu.edu.sg> From: Shen Gangxiang To: "'mpls@uu.net'" Cc: "'jplang@calient.net'" Subject: Some questions on Link Management Protocol (LMP) Draft-lang-mpls- lmp-01.txt Date: Fri, 6 Oct 2000 12:31:19 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, folks, I have some questions on the draft: Some questions on Link Management Protocol (LMP) Draft-lang-mpls-lmp-01.txt (Note that if I have missed some information which has been discussed before, please kindly point out.) 1. In the Section 4.2.1. Parameter Negotiation Let's consider the situation that both the local node and the remote node send the HelloConfig messages at the same time. If so some rules (e.g. the one according to the value of CCId) are needed to decide which HelloConfig message will be effective. 2. In the Section 4.2.3 Control channel switchover As pointed out, "Control channels may need to be switched as a result of a control channel failure or for administration purposes (e.g., routine fiber maintenance, reverting back to a primary control channel, etc.)...." and "To ensure that both nodes switch to the backup control channel successfully, both the local and remote nodes MUST transmit messages over both the primary and backup control channels until the switchover is successful. Messages on the primary control channel MUST have the ControlChannelSwitchover flag set to 1 and MUST not increment the TxSeqNum (even upon the receipt of a Hello message with the current TxSeqNum reflected in the RcvSeqNum field)...". I guess that this "control channel switchover" mechanism may not be suitable for the situation of "control channel failure", because if the primary control channel fails (e.g. terminated), it may not be able to transmit the information of "ControlChannelSwitchover flag". 4. In Section 4.2.4. Taking a link down administratively I guess that some more details are required to be looked into if something wrong happens to the control channel when two nodes are exchanging the LinkDown=1 message. 3. In Page 10, "When the Test message is detected at a node, .......and EndVerifyAck message MUST be sent." As proposed, the component channels are tested one by one. I wonder why we don't test them at the same time. By doing this, at least we can save the time consumed by the tests. Many thanks for comments! Gangxiang From owner-mpls@UU.NET Fri Oct 6 08:50:46 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00706 for ; Fri, 6 Oct 2000 08:50:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjst07618; Fri, 6 Oct 2000 12:49:33 GMT Received: by mail-control.mail.uu.net id QQjjst24009 for mpls-outgoing; Fri, 6 Oct 2000 12:49:16 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjst24004 for ; Fri, 6 Oct 2000 12:49:10 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjst14334 for ; Fri, 6 Oct 2000 12:49:02 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjst09560 for ; Fri, 6 Oct 2000 12:49:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA01200 for mpls@uu.net; Fri, 6 Oct 2000 08:49:01 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjst23991 for ; Fri, 6 Oct 2000 12:48:24 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjst11070 for ; Fri, 6 Oct 2000 08:48:13 -0400 (EDT) Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjst08403 for ; Fri, 6 Oct 2000 12:48:12 GMT Received: from cisco.com (broberts-u10.cisco.com [161.44.135.42]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA01091; Fri, 6 Oct 2000 08:48:11 -0400 (EDT) Message-ID: <39DDCA0A.2626B024@cisco.com> Date: Fri, 06 Oct 2000 08:48:10 -0400 From: Barbara Roberts X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Martin Picard CC: mpls@UU.NET Subject: Re: F/R & ATM over MPLS References: <002401c02f1f$25508720$ee08ca18@videotron.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Martin, Yes, ATM (aal5snap) over MPLS is available. Cisco recently sold it with the latest 12.0ST release. Contact Thomas McKinney Cisco Systems, Chelmsford, MA. email: tmckinne@cisco.com. He is the Software Manager for the MPLS project here. In the past we have had Fr over MPLS but that was not sold with the recent release. Best regards, Barbara Roberts Software Engineer (Test) Cisco Systems Chelmsford, MA > Hi, > > A while back, I heard that F/R and ATM could > be transparently carried over an MPLS network. > Is this feasible, available ? > How does it work ? > Why would you do it ? > > Thanks in advance. > Martin From owner-mpls@UU.NET Fri Oct 6 09:16:15 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02951 for ; Fri, 6 Oct 2000 09:16:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjsu13663; Fri, 6 Oct 2000 13:14:38 GMT Received: by mail-control.mail.uu.net id QQjjsu07812 for mpls-outgoing; Fri, 6 Oct 2000 13:14:16 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjsu07772 for ; Fri, 6 Oct 2000 13:14:06 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjsu17225 for ; Fri, 6 Oct 2000 09:13:41 -0400 (EDT) Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjsu13228 for ; Fri, 6 Oct 2000 13:13:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA03925 for mpls@uu.net; Fri, 6 Oct 2000 09:13:40 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjsu07654 for ; Fri, 6 Oct 2000 13:13:19 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjsu09779 for ; Fri, 6 Oct 2000 13:12:56 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjjsu09634 for ; Fri, 6 Oct 2000 13:12:56 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA16272; Fri, 6 Oct 2000 09:12:54 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAL33082; Fri, 6 Oct 2000 09:12:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20001006091131.02425cc0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Oct 2000 09:12:39 -0400 To: Alex Zinin From: "Thomas D. Nadeau" Subject: Re: Interface ID in kompella-unnum-02 Cc: Kireeti Kompella , mpls@UU.NET, Mraftelis@WhiteRockNetworks.com In-Reply-To: <19691.001005@cisco.com> References: <4.3.2.7.2.20001005155723.00b74c90@bucket.cisco.com> <4.3.2.7.2.20001005155723.00b74c90@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Alex, >Thomas, > > >>Note too that the interface index cannot be made bigger than 2^24; > >>this is so that the distinction between IP addresses and interface > >>indices is clear. Given that, and given the fact the SNMP ifIndexes > >>can be 32 bits, ifIndexes are ruled out as potential interface > >>indices. > > > Personally, this seems like a flaw in the design. The type > > ifIndex has been around for quite a long time. I don't see how > > the ifIndex in OSPF/ISIS was allowed to use a different size > > while claiming that one could put use an ifIndex from the Interfaces > > MIB. > >I don't want confusion here, Neither do I. *) >ifIndex is 32-bit, so is the Link Data field in OSPF router-LSA. >So OSPF is fine, actually. You won't find "IfIndex" in ISIS >spec :) > >But in fact we're not much concerned about legacy OSPF/ISIS, >we should be talking about TE extensions. And they also use 32 bits. >So, the size is fine again :) Okay, perhaps I misunderstood the original question. Thanks for the clarification. --Tom From owner-mpls@UU.NET Fri Oct 6 11:18:17 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06152 for ; Fri, 6 Oct 2000 11:18:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjtd21260; Fri, 6 Oct 2000 15:17:09 GMT Received: by mail-control.mail.uu.net id QQjjtd13891 for mpls-outgoing; Fri, 6 Oct 2000 15:16:35 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjtd13855 for ; Fri, 6 Oct 2000 15:16:21 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjtc05623 for ; Fri, 6 Oct 2000 11:14:31 -0400 (EDT) Received: from lux.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQjjtc04567 for ; Fri, 6 Oct 2000 15:14:31 GMT Received: by lux.chromisys.com with Internet Mail Service (5.5.2650.21) id <4B1P6BJM>; Fri, 6 Oct 2000 08:14:31 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CED5F@lux.chromisys.com> From: Jonathan Lang To: "'Shen Gangxiang'" , "'mpls@uu.net'" Subject: RE: Some questions on Link Management Protocol (LMP) Draft-lang-m pls- lmp-01.txt Date: Fri, 6 Oct 2000 08:14:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Gangxiang, Thanks for the comments. Please see responses inline. Also, please note that the current published version of the draft is draft-ietf-mpls-lmp-00.txt. -Jonathan > -----Original Message----- > From: Shen Gangxiang [mailto:EGXShen@ntu.edu.sg] > Sent: Thursday, October 05, 2000 9:31 PM > To: 'mpls@uu.net' > Cc: Jonathan Lang > Subject: Some questions on Link Management Protocol (LMP) > Draft-lang-mpls- lmp-01.txt > > > Hi, folks, > > I have some questions on the draft: Some questions on Link Management > Protocol (LMP) Draft-lang-mpls-lmp-01.txt > > (Note that if I have missed some information which has been discussed > before, please kindly point out.) > > 1. In the Section 4.2.1. Parameter Negotiation > Let's consider the situation that both the local node and the remote node > send the HelloConfig messages at the same time. If so some rules (e.g. the > one according to the value of CCId) are needed to decide which HelloConfig > message will be effective. You are correct. A rule (based on nodeId) is being added to the next version of the draft. > > 2. In the Section 4.2.3 Control channel switchover > As pointed out, "Control channels may need to be switched as a result of a > control channel failure or for administration purposes (e.g., routine fiber > maintenance, reverting back to a primary control channel, etc.)...." and "To > ensure that both nodes switch to the backup control channel successfully, > both the local and remote nodes MUST transmit messages over both the primary > and backup control channels until the switchover is successful. Messages on > the primary control channel MUST have the ControlChannelSwitchover flag set > to 1 and MUST not increment the TxSeqNum (even upon the receipt of a Hello > message with the current TxSeqNum reflected in the RcvSeqNum field)...". > I guess that this "control channel switchover" mechanism may not be suitable > for the situation of "control channel failure", because if the primary > control channel fails (e.g. terminated), it may not be able to transmit the > information of "ControlChannelSwitchover flag". yes. If a control channel has failed, a node may not be able to transmit a Hello message with the Switchover flag. However, there are many failure cases where such a procedure is beneficial. For example, if a node is not receiving Hello messages from his neighbor but his neighbor is able to receive messages from him, the above mechanism will expedite the switchover process. The above mechanism is also useful for switching over a control channel administratively. > 4. In Section 4.2.4. Taking a link down administratively > I guess that some more details are required to be looked into if something > wrong happens to the control channel when two nodes are exchanging the LinkDown=1 message. If the control channel fails before the LinkDown procedure is completed, the control channel failure procedure will be initiated. Once a failover is complete, the LinkDown procedure can be completed. > 3. In Page 10, "When the Test message is detected at a node, > .......and EndVerifyAck message MUST be sent." > As proposed, the component channels are tested one by one. I > wonder why we don't test them at the same time. By doing this, at least we > can save the time consumed by the tests. The protocol does not limit the testing of the component links to be one-by-one. They can certainly be tested in parallel. > Many thanks for comments! > Gangxiang > > > > > From owner-mpls@UU.NET Fri Oct 6 12:20:38 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07456 for ; Fri, 6 Oct 2000 12:20:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjth13867; Fri, 6 Oct 2000 16:19:51 GMT Received: by mail-control.mail.uu.net id QQjjth02631 for mpls-outgoing; Fri, 6 Oct 2000 16:19:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjth02626 for ; Fri, 6 Oct 2000 16:19:10 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjth14179 for ; Fri, 6 Oct 2000 12:15:48 -0400 (EDT) Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjjth08178 for ; Fri, 6 Oct 2000 16:15:44 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA74106; Fri, 6 Oct 2000 12:12:10 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200010061612.MAA74106@workhorse.fictitious.org> To: Eric Gray cc: curtis@avici.com, Bala Rajagopalan , Michel Redondo Ferrero , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS/BGP routing question In-reply-to: Your message of "Thu, 05 Oct 2000 11:13:35 PDT." <4611AD058694D4118FD5009027B0A6625D8AA5@ICARIAN> Date: Fri, 06 Oct 2000 12:12:09 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk Eric, In message <4611AD058694D4118FD5009027B0A6625D8AA5@ICARIAN>, Eric Gray writes: > Curtis, > > Please see below. > > Curtis Villamizar wrote: > ... ... > > > > For example, optical switches will definitely NOT run IBGP with the > > Internet routers. They run an IGP and MPLS (plus LMP) but not BGP. > > (In any reasonably sane network). > > [...] > > So, I seem to have missed your point. Can you elucidate? Within an AS there is no strict need for any interior MPLS capable device to run IBGP if there are MPLS LSPs between any two non-interior (border) devices. An interior device is one which has no EBGP peers. A non-interior does have EBGP peers and is usually called a border router. Stating the obvious: You only run IBGP wtih peers in your own AS. You only run EBGP with peers outside your own AS. The only potential reason to run IBGP is so that the interior routers have full Internet routes and can handle ICMP and traffic to the local device without resorting to a default route to a border. Optical switches are not known for the robustness of their BGP implementations if they have BGP implementations at all. They may also have more important things to do with their CPU cycles given that they do no externalrouting at all. It would seem to be a relly bad idea to run IBGP to the optical switches. I hope that was more clear. Curtis From owner-mpls@UU.NET Fri Oct 6 12:45:57 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08044 for ; Fri, 6 Oct 2000 12:45:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjti27423; Fri, 6 Oct 2000 16:44:43 GMT Received: by mail-control.mail.uu.net id QQjjti04419 for mpls-outgoing; Fri, 6 Oct 2000 16:44:18 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjti04412 for ; Fri, 6 Oct 2000 16:44:11 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjti17858 for ; Fri, 6 Oct 2000 12:43:51 -0400 (EDT) Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjjti08079 for ; Fri, 6 Oct 2000 16:43:49 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA74379; Fri, 6 Oct 2000 12:40:28 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200010061640.MAA74379@workhorse.fictitious.org> To: Fred Baker cc: Randy Bush , Ping Pan , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Any SPs using QoS ??? In-reply-to: Your message of "Fri, 29 Sep 2000 15:07:24 +0200." <5.0.0.25.2.20000929150628.0274b540@flipper> Date: Fri, 06 Oct 2000 12:40:28 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.0.0.25.2.20000929150628.0274b540@flipper>, Fred Baker writes: > At 01:08 PM 9/28/00 -0700, Randy Bush wrote: > >this has appeal. but ecn looks much simpler. > > Is ECN something that you would consider pushing toward standardization? I > like it, but I'm looking for operator feedback, and some (notably Juha) > distrust a mechanism that trusts the host. It should at least go through as experimental but preferably as proposed standard. Shouldn't the ECN WG get Cc'd? Curtis ps - Juha doesn't have to turn it on if he doesn't trust it. From owner-mpls@UU.NET Fri Oct 6 14:23:42 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10029 for ; Fri, 6 Oct 2000 14:23:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjtp01680; Fri, 6 Oct 2000 18:22:56 GMT Received: by mail-control.mail.uu.net id QQjjtp05670 for mpls-outgoing; Fri, 6 Oct 2000 18:22:29 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjjtp05662 for ; Fri, 6 Oct 2000 18:22:25 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjtp00812 for ; Fri, 6 Oct 2000 18:19:12 GMT Received: from rly-ip02.mx.aol.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip02.mx.aol.com [152.163.225.160]) id QQjjtp21444 for ; Fri, 6 Oct 2000 18:19:12 GMT Received: from tot-wb.proxy.aol.com (tot-wb.proxy.aol.com [205.188.192.131]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id OAA11495; Fri, 6 Oct 2000 14:19:09 -0400 (EDT) Received: from cs.columbia.edu (AC8B1784.ipt.aol.com [172.139.23.132]) by tot-wb.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e96IJ7A25140; Fri, 6 Oct 2000 14:19:07 -0400 (EDT) Message-ID: <39DE15F9.5BC28D95@cs.columbia.edu> Date: Fri, 06 Oct 2000 14:12:09 -0400 From: Ping Pan X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: Fred Baker , Randy Bush , mpls@UU.NET Subject: Re: Any SPs using QoS ??? References: <200010061640.MAA74379@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPPan@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > In message <5.0.0.25.2.20000929150628.0274b540@flipper>, Fred Baker writes: > > At 01:08 PM 9/28/00 -0700, Randy Bush wrote: > > >this has appeal. but ecn looks much simpler. > > > > Is ECN something that you would consider pushing toward standardization? I > > like it, but I'm looking for operator feedback, and some (notably Juha) > > distrust a mechanism that trusts the host. > > It should at least go through as experimental but preferably as > proposed standard. Shouldn't the ECN WG get Cc'd? > > Curtis > > ps - Juha doesn't have to turn it on if he doesn't trust it. Please educate me here. Is the idea of ENC similar to that of FECN and BECN in Frame Relay? That is, upon congestion notification, end nodes start to slow down packet transmission. Many routers today happen to be the "end nodes". They generally use GRE encapsulation to support user's traffic (such as delay-sensitive SNA data). Supporting ECN would mean that the edge routers must (re)implement congestion avoidance mechanism for encapsulated packets, is that correct? Do you think this may cause deployment problem? Or maybe all routers have such capability already. -- Ping Pan http://www.cs.columbia.edu/~pingpan From owner-mpls@UU.NET Fri Oct 6 16:00:10 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11857 for ; Fri, 6 Oct 2000 16:00:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjtv04607; Fri, 6 Oct 2000 19:59:19 GMT Received: by mail-control.mail.uu.net id QQjjtv26319 for mpls-outgoing; Fri, 6 Oct 2000 19:58:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjjtv26302 for ; Fri, 6 Oct 2000 19:58:42 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjtv13827 for ; Fri, 6 Oct 2000 15:58:28 -0400 (EDT) Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjjtv03238 for ; Fri, 6 Oct 2000 19:58:24 GMT Received: from tellium.com (node1.tellium.com [151.198.92.15]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e96JokF26570; Fri, 6 Oct 2000 15:50:47 -0400 (EDT) Message-ID: <39DE2EE1.17C53BC2@tellium.com> Date: Fri, 06 Oct 2000 15:58:26 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: Eric Gray , Michel Redondo Ferrero , mpls@UU.NET Subject: Re: MPLS/BGP routing question References: <200010061612.MAA74106@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Curtis Villamizar wrote: > > > > > Optical switches are not known for the robustness of their BGP > implementations if they have BGP implementations at all. They may > also have more important things to do with their CPU cycles given that > they do no externalrouting at all. It would seem to be a relly bad > idea to run IBGP to the optical switches. > > I hope that was more clear. Absolutely not. It's certainly seems possible to have a scenario where optical edge switches run E-BGP with router clients to provide reachability information. Whether the optical network is a separate AS or a sub-AS is another issue. What's wrong with this? Bala -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Fri Oct 6 17:19:38 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13092 for ; Fri, 6 Oct 2000 17:19:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjub19173; Fri, 6 Oct 2000 21:19:01 GMT Received: by mail-control.mail.uu.net id QQjjub24913 for mpls-outgoing; Fri, 6 Oct 2000 21:18:37 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjjub24908 for ; Fri, 6 Oct 2000 21:18:30 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjub11198 for ; Fri, 6 Oct 2000 17:18:23 -0400 (EDT) Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjub18173 for ; Fri, 6 Oct 2000 21:18:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA14387 for mpls@uu.net; Fri, 6 Oct 2000 17:18:22 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjub24888 for ; Fri, 6 Oct 2000 21:18:06 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjub23716 for ; Fri, 6 Oct 2000 17:16:46 -0400 (EDT) Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjub15996 for ; Fri, 6 Oct 2000 21:16:45 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA14189; Fri, 6 Oct 2000 17:16:44 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA04968; Fri, 6 Oct 2000 17:16:44 -0400 (EDT) Message-Id: <200010062116.RAA04968@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Eric Gray cc: "'George Swallow'" , mpls@UU.NET, swallow@cisco.com Subject: Re: Draft Minutes from Pittsburgh In-reply-to: Your message of "Thu, 05 Oct 2000 15:29:40 PDT." <4611AD058694D4118FD5009027B0A6625D8AA7@ICARIAN> Date: Fri, 06 Oct 2000 17:16:44 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk >> kompella-mpls-ospf-extensions-00.txt > >I think one of these should have been "-isis-", right? Thanks. Will fix. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Oct 6 21:28:13 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16226 for ; Fri, 6 Oct 2000 21:28:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjuq11480; Sat, 7 Oct 2000 01:06:00 GMT Received: by mail-control.mail.uu.net id QQjjuq24003 for mpls-outgoing; Sat, 7 Oct 2000 01:05:18 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjuq23994 for ; Sat, 7 Oct 2000 01:05:02 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjuq01922 for ; Sat, 7 Oct 2000 01:03:43 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjuq09626 for ; Sat, 7 Oct 2000 01:03:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA29744 for mpls@uu.net; Fri, 6 Oct 2000 21:03:42 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjuq23480 for ; Sat, 7 Oct 2000 01:03:11 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjuq00560 for ; Sat, 7 Oct 2000 01:03:08 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjjuq14074 for ; Sat, 7 Oct 2000 01:03:08 GMT Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA13724; Fri, 6 Oct 2000 18:02:00 -0700 (PDT) Message-Id: <5.0.0.25.2.20001006171326.02664150@flipper> X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Oct 2000 17:13:47 -0700 To: curtis@avici.com From: Fred Baker Subject: Re: Any SPs using QoS ??? Cc: Randy Bush , Ping Pan , mpls@UU.NET In-Reply-To: <200010061640.MAA74379@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 12:40 PM 10/6/00 -0400, Curtis Villamizar wrote: >It should at least go through as experimental but preferably as >proposed standard. Shouldn't the ECN WG get Cc'd? it *is* experimental. I think the argument is towards PS From owner-mpls@UU.NET Fri Oct 6 22:37:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18460 for ; Fri, 6 Oct 2000 22:37:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjuw11374; Sat, 7 Oct 2000 02:36:38 GMT Received: by mail-control.mail.uu.net id QQjjuw11118 for mpls-outgoing; Sat, 7 Oct 2000 02:36:07 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjjuw11057 for ; Sat, 7 Oct 2000 02:35:59 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjjuw18942 for ; Fri, 6 Oct 2000 22:35:55 -0400 (EDT) Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjjuw19653 for ; Sat, 7 Oct 2000 02:35:54 GMT Received: from juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA11836; Fri, 6 Oct 2000 19:35:47 -0700 (PDT) Message-Id: <200010070235.TAA11836@red.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Bala Rajagopalan Cc: mpls@UU.NET Subject: Re: draft-kompella-mpls-bundle-03.txt In-Reply-To: Your message of "Mon, 02 Oct 2000 11:08:27 EDT." <39D8A4EB.625868D5@tellium.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Oct 2000 19:35:47 -0700 From: Kireeti Kompella Sender: owner-mpls@UU.NET Precedence: bulk Hi Bala, > Debanjan Saha and myself are submitting > a revised version of our bundling draft, draft-rs-optical-bundling-01.txt. Do you have an ETA for this? Thanks, Kireeti. From owner-mpls@UU.NET Fri Oct 6 22:52:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18593 for ; Fri, 6 Oct 2000 22:52:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjuq17624; Sat, 7 Oct 2000 01:05:55 GMT Received: by mail-control.mail.uu.net id QQjjuq24004 for mpls-outgoing; Sat, 7 Oct 2000 01:05:19 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjuq23993 for ; Sat, 7 Oct 2000 01:05:02 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjuq02642 for ; Sat, 7 Oct 2000 01:04:02 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjjuq10012 for ; Sat, 7 Oct 2000 01:04:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA29763 for mpls@uu.net; Fri, 6 Oct 2000 21:04:01 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjjuq23537 for ; Sat, 7 Oct 2000 01:03:28 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjuq28648 for ; Fri, 6 Oct 2000 21:03:17 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjjuq14266 for ; Sat, 7 Oct 2000 01:03:17 GMT Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA13727; Fri, 6 Oct 2000 18:02:02 -0700 (PDT) Message-Id: <5.0.0.25.2.20001006171418.01ef2eb0@flipper> X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Oct 2000 17:15:28 -0700 To: Ping Pan From: Fred Baker Subject: Re: Any SPs using QoS ??? Cc: curtis@avici.com, Randy Bush , mpls@UU.NET In-Reply-To: <39DE15F9.5BC28D95@cs.columbia.edu> References: <200010061640.MAA74379@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk it means that under configuration control the routers should implement RED not only by dropping, but by marking traffic, and end hosts should do certain things including responding to the mark in a congestion avoiding manner. From owner-mpls@UU.NET Sat Oct 7 01:06:03 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20440 for ; Sat, 7 Oct 2000 01:06:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjjvg24297; Sat, 7 Oct 2000 05:05:19 GMT Received: by mail-control.mail.uu.net id QQjjvg22922 for mpls-outgoing; Sat, 7 Oct 2000 05:04:55 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjvg22913 for ; Sat, 7 Oct 2000 05:04:48 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjjvg15957 for ; Sat, 7 Oct 2000 05:04:34 GMT Received: from mail3.ntu.edu.sg by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.1.91]) id QQjjvg23130 for ; Sat, 7 Oct 2000 05:04:33 GMT Received: by mail3.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id ; Sat, 7 Oct 2000 13:04:21 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE01FDD105@exchange4.ntu.edu.sg> From: Shen Gangxiang To: "'mpls@uu.net'" Cc: "'petera@nortelnetworks.com'" Subject: Some questions on Ganeralized MPLS-Singalling Function Descriptio n draft-ashwood-generalized-mpls-signalling-00.txt Date: Sat, 7 Oct 2000 13:04:20 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In section 3.1.1, LSP Encoding Type:16 bits What is the meaning of "Clear" in the "Encoding" column? What is the difference between "SONET's OC-" and "Clear's OC-"? Why don't add another type "Fiber" after "Photonic Waveband", since we may also switch the whole traffic on a fiber? Gangxiang From owner-mpls@UU.NET Sun Oct 8 20:20:03 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12336 for ; Sun, 8 Oct 2000 20:20:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkbx24449; Mon, 9 Oct 2000 00:19:14 GMT Received: by mail-control.mail.uu.net id QQjkbx23597 for mpls-outgoing; Mon, 9 Oct 2000 00:18:57 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkbx23591 for ; Mon, 9 Oct 2000 00:18:48 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkbx21595 for ; Mon, 9 Oct 2000 00:18:23 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkbx12960 for ; Mon, 9 Oct 2000 00:18:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA22159 for mpls@uu.net; Sun, 8 Oct 2000 20:18:21 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkbx23557 for ; Mon, 9 Oct 2000 00:17:49 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkbx18278 for ; Mon, 9 Oct 2000 00:16:42 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjkbx20744 for ; Mon, 9 Oct 2000 00:16:41 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA28609; Sun, 8 Oct 2000 17:16:46 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA03905; Sun, 8 Oct 2000 17:16:19 -0700 (PDT) Message-ID: <39E10E41.DF8C1972@cisco.com> Date: Sun, 08 Oct 2000 17:16:01 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: Bala Rajagopalan , curtis@avici.com, Eric Gray , Michel Redondo Ferrero Subject: Re: MPLS/BGP routing question References: <200010061612.MAA74106@workhorse.fictitious.org> <39DE2EE1.17C53BC2@tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sorry for being late ... Two comments: 1. A lot of people mentioned that there is no need to run IBGP on core routers with mpls-vpns or just prefix/tunnel based mpls in the core. That is true but only for _unicast_ traffic. One I think quite important point is no one has mentioned that if one is providing global multicast service full table in every router is needed for RPF check. This will hold until one comes with good proposal & implementation of mpls for multicast. Now said this there are two ways to keep rolling until this happens: * Keep the ipv4 ibgp there, automatically populating routing table & forwarding table with 85K entires which may not be used at all for forwarding * Turn existing ipv4 ibgp mesh into multicast-BGP full mesh and propagate the full table for the purpose of m-cast RPF check while not "waist" RIBs/FIBs RAM space. 2. Satoru Matsushima said: > When a LSP of PE to PE broken, BGP has no way of LSP broken. > I think this is one of most seriously problem of BGP/MPLS VPN. Not true when we are talking about prefix based LSPs. If you are using prefix based LSPs they will disappear only if ip route to bgp next hop will disappear what in turn will cause bgp route withdrawn (invalid bgp next hop) at a periodic scanner. If there is no route - you will not be able to route anyway - no miracles here. If you are talking about tunnel based LSPs (TE for example) - you have got what you have configured. I would advise caution configuring your network this way and I don't think this particular case can justify calling a mpls-vpn architecture as a "serious problem". R. From owner-mpls@UU.NET Sun Oct 8 20:27:31 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12371 for ; Sun, 8 Oct 2000 20:27:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkbx23732; Mon, 9 Oct 2000 00:26:29 GMT Received: by mail-control.mail.uu.net id QQjkbx23957 for mpls-outgoing; Mon, 9 Oct 2000 00:25:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjkbx23950 for ; Mon, 9 Oct 2000 00:25:51 GMT Received: from cmr0.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkbx11107 for ; Sun, 8 Oct 2000 20:25:41 -0400 (EDT) Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkbx22596 for ; Mon, 9 Oct 2000 00:25:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA22717 for mpls@uu.net; Sun, 8 Oct 2000 20:25:40 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjkbx23926 for ; Mon, 9 Oct 2000 00:25:11 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkbx11081 for ; Sun, 8 Oct 2000 20:24:57 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjkbx02879 for ; Mon, 9 Oct 2000 00:24:56 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA00374; Sun, 8 Oct 2000 17:25:21 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA03913; Sun, 8 Oct 2000 17:24:55 -0700 (PDT) Message-ID: <39E11045.7759389B@cisco.com> Date: Sun, 08 Oct 2000 17:24:37 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kluwer, M.H." CC: "'mpls@uu.net'" Subject: Re: carrier's carrier BGP/MPLS VPNs References: <59063B5B4D98D311BC0D0001FA7E4522032F9157@l04.research.kpn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit It's comming ... R. > > Hi all, does anyone know what the status of the implementation (and other > activities) of the carrier's carrier capability as described in the IETF RFC > 2547bis (BGP/MPLS VPNs). > > Thanks in advance ! > > Michael From owner-mpls@UU.NET Sun Oct 8 21:31:45 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12837 for ; Sun, 8 Oct 2000 21:31:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkby04472; Mon, 9 Oct 2000 00:31:09 GMT Received: by mail-control.mail.uu.net id QQjkby24290 for mpls-outgoing; Mon, 9 Oct 2000 00:30:50 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjkby24285 for ; Mon, 9 Oct 2000 00:30:46 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkby29440 for ; Sun, 8 Oct 2000 20:30:42 -0400 (EDT) Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkby29279 for ; Mon, 9 Oct 2000 00:30:41 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA23262 for mpls@uu.net; Sun, 8 Oct 2000 20:30:41 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkby24274 for ; Mon, 9 Oct 2000 00:30:16 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkbx17691 for ; Mon, 9 Oct 2000 00:29:54 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjkbx10043 for ; Mon, 9 Oct 2000 00:29:54 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA01597; Sun, 8 Oct 2000 17:30:19 -0700 (PDT) Received: from cisco.com (robert@rraszuk-dsl2.cisco.com [10.19.31.91]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA03917; Sun, 8 Oct 2000 17:29:52 -0700 (PDT) Message-ID: <39E1116E.CF7CC9CE@cisco.com> Date: Sun, 08 Oct 2000 17:29:34 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: yulu CC: mpls@UU.NET Subject: Re: a question about multicast in mpls vpn? References: <001501c028e5$d5a5ab40$494e74ca@yulu.zsu.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The global multicast works just fine in pararel to mpls-vpns which "affect" only unicast forwarding. The multicast for mpls-vpns is currently being worked on. You should see a draft on this (at least one way of doing it) comming soon. R. > Hi all: > I am doing research in multicast on MPLS VPN.I have read RFC > 2547,and a few related papers.But I can't understand how to implement > multicast in MPLS VPN.Is there anyone who is also interested in this > direction?Please give me some suggestions.You can contact me > directly.My mailing address is lucy_yu@163.net > lucy > > From owner-mpls@UU.NET Mon Oct 9 00:48:24 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16138 for ; Mon, 9 Oct 2000 00:48:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkcp12439; Mon, 9 Oct 2000 04:48:22 GMT Received: by mail-control.mail.uu.net id QQjkcp24181 for mpls-outgoing; Mon, 9 Oct 2000 04:47:58 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjkcp24176 for ; Mon, 9 Oct 2000 04:47:57 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkcp01364 for ; Mon, 9 Oct 2000 00:47:55 -0400 (EDT) Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkcp14770 for ; Mon, 9 Oct 2000 04:47:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA03932 for mpls@uu.net; Mon, 9 Oct 2000 00:47:54 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjkcp24164 for ; Mon, 9 Oct 2000 04:47:26 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkcp20040 for ; Mon, 9 Oct 2000 00:47:15 -0400 (EDT) Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjkcp10969 for ; Mon, 9 Oct 2000 04:47:15 GMT Received: from sj-dial-2-83.cisco.com (sj-dial-2-83.cisco.com [10.19.226.84]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA02381; Sun, 8 Oct 2000 21:46:52 -0700 (PDT) Date: Sun, 8 Oct 2000 21:41:03 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <8903.001008@cisco.com> To: Bala Rajagopalan CC: curtis@avici.com, Eric Gray , Michel Redondo Ferrero , mpls@UU.NET Subject: Re: MPLS/BGP routing question In-reply-To: <39DE2EE1.17C53BC2@tellium.com> References: <39DE2EE1.17C53BC2@tellium.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bala, Note that with today BGP that border OXC will be the next-hop for all IP prefixes it announces to the client via the e-BGP session. This means that the client does not really know much about the egress point per prefix and hence where it should establish LSPs across the optical transport network unless we add a kind of "suggested next-hop" BGP attribute as a part of optical UNI (I don't think it makes sense to run e-BGP in the peer model) to inform the client about the egress points. I think Curtis' point is that OXCs do not really need to have BGP routes in their routing table for normal operation of circuit provisioning protocols. Alex. >> Optical switches are not known for the robustness of their BGP >> implementations if they have BGP implementations at all. They may >> also have more important things to do with their CPU cycles given that >> they do no externalrouting at all. It would seem to be a relly bad >> idea to run IBGP to the optical switches. >> >> I hope that was more clear. > Absolutely not. It's certainly seems possible to have > a scenario where optical edge switches run E-BGP > with router clients to provide reachability information. Whether > the optical network is a separate AS or a sub-AS is another issue. > What's wrong with this? > Bala > -- > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com From owner-mpls@UU.NET Mon Oct 9 07:27:04 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01263 for ; Mon, 9 Oct 2000 07:27:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkdp20345; Mon, 9 Oct 2000 11:27:03 GMT Received: by mail-control.mail.uu.net id QQjkdp05563 for mpls-outgoing; Mon, 9 Oct 2000 11:26:40 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkdp05558 for ; Mon, 9 Oct 2000 11:26:36 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkdp01695 for ; Mon, 9 Oct 2000 11:26:00 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjkdp09873 for ; Mon, 9 Oct 2000 11:25:57 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 09 Oct 2000 16:58:03 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA10680; Mon, 9 Oct 2000 16:42:43 +0530 Reply-To: From: "Manikantan S" To: , Subject: LDP - TCP MD5 digest support Date: Mon, 9 Oct 2000 16:51:13 +0530 Message-Id: <000c01c031e3$094dba40$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello can someone clarify the following doubt(s). TCP MD5 signature option has been suggested for providing security to the LDP-TCP sessions in the LDP draft. A reference to RFC 2385 (Protection of BGP Sessions via the TCP MD5 Signature Option) has also been made. My doubt/confusions are 1) Is the MD5 digest calculation to be done at the TCP level? (I assume it is not to be done at the LDP level, as the entire set of TCP Options - if any, that will appear in the TCP header will not be known at the LDP level) 2) If the digest is to be done at the TCP level, is there a standard socket option which will enable the MD5 option to be enabled and to pass on the password information too associated with the Session? Thanks in advance with best regards mani From owner-mpls@UU.NET Mon Oct 9 08:49:20 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02976 for ; Mon, 9 Oct 2000 08:49:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkdv18341; Mon, 9 Oct 2000 12:49:14 GMT Received: by mail-control.mail.uu.net id QQjkdv21939 for mpls-outgoing; Mon, 9 Oct 2000 12:48:40 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkdv21929 for ; Mon, 9 Oct 2000 12:48:35 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkdv28992 for ; Mon, 9 Oct 2000 12:47:41 GMT Received: from siso_server.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: user178.s146.samsung.co.kr [203.241.146.178]) id QQjkdv02198 for ; Mon, 9 Oct 2000 12:47:39 GMT Received: by SISO_SERVER with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Oct 2000 18:18:51 +0530 Message-ID: From: Sridhar To: "'mpls@uu.net'" Subject: Different access for MPLS/BGP VPN hosts Date: Mon, 9 Oct 2000 18:18:42 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hello, Can anybody tell me how we will be able to use both public network and VPN at the same time from a single host? Or is it that at a time we can use only VPN and will not be able to use Public network from that system? If we are able to use both of them at the same time then how will we identify the session in the CE router? Please refer to the following figure for more information From owner-mpls@UU.NET Mon Oct 9 09:43:04 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04008 for ; Mon, 9 Oct 2000 09:43:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkdy06054; Mon, 9 Oct 2000 13:43:04 GMT Received: by mail-control.mail.uu.net id QQjkdy06495 for mpls-outgoing; Mon, 9 Oct 2000 13:42:21 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkdy06489 for ; Mon, 9 Oct 2000 13:42:21 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkdy13981 for ; Mon, 9 Oct 2000 13:41:08 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkdy24706 for ; Mon, 9 Oct 2000 13:41:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA26863 for mpls@uu.net; Mon, 9 Oct 2000 09:41:07 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjkdy06305 for ; Mon, 9 Oct 2000 13:40:25 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkdy04903 for ; Mon, 9 Oct 2000 09:40:17 -0400 (EDT) Received: from exchsrv1.cosinecom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjkdy01644 for ; Mon, 9 Oct 2000 13:40:16 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Oct 2000 06:39:09 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29111DB8DC@exchsrv1.cosinecom.com> From: Jieyun Jessica Yu To: "'Sridhar'" , "'mpls@uu.net'" Subject: RE: Different access for MPLS/BGP VPN hosts Date: Mon, 9 Oct 2000 06:39:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C031F6.49FEE010" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C031F6.49FEE010 Content-Type: text/plain; charset="iso-8859-1" Some VPN routers is able to identify if a packet is destined to public Internet or VPN by looking at the destination address of a packet. Then it will send the packet to the public internet or VPN accordingly. By the way, nbvpn@bbo.com is probably more appropriate to send this kind of vpn related message rather than mpls mailing list. cheers! --Jessica -----Original Message----- From: Sridhar [mailto:sridhar@samsung.co.kr] Sent: Monday, October 09, 2000 5:49 AM To: 'mpls@uu.net' Subject: Different access for MPLS/BGP VPN hosts Hello, Can anybody tell me how we will be able to use both public network and VPN at the same time from a single host? Or is it that at a time we can use only VPN and will not be able to use Public network from that system? If we are able to use both of them at the same time then how will we identify the session in the CE router? Please refer to the following figure for more information ------_=_NextPart_001_01C031F6.49FEE010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Different access for MPLS/BGP VPN hosts

Some VPN routers is able to identify if a packet is = destined to public Internet or VPN by looking at the destination = address of a packet. Then it will send the packet to the public = internet or VPN accordingly.

By the way, nbvpn@bbo.com is probably more = appropriate to send this kind of vpn related message rather than mpls = mailing list.

cheers!

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   --Jessica
-----Original Message-----
From: Sridhar [mailto:sridhar@samsung.co.kr]<= /FONT>
Sent: Monday, October 09, 2000 5:49 AM
To: 'mpls@uu.net'
Subject: Different access for MPLS/BGP VPN = hosts


Hello,

Can anybody tell me how we will be able to use both = public network and VPN
at the same time from a single host?
        =         =         =         Or
is it that at a time we can use only VPN and will = not be able to use Public
network from that system?

If we are able to use both of them at the same time = then how will we
identify the session in the CE router?

Please refer to the following figure for more = information

------_=_NextPart_001_01C031F6.49FEE010-- From owner-mpls@UU.NET Mon Oct 9 10:00:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04246 for ; Mon, 9 Oct 2000 10:00:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkea09565; Mon, 9 Oct 2000 14:00:57 GMT Received: by mail-control.mail.uu.net id QQjkea09811 for mpls-outgoing; Mon, 9 Oct 2000 14:00:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjkea09777 for ; Mon, 9 Oct 2000 14:00:19 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkea07709 for ; Mon, 9 Oct 2000 10:00:13 -0400 (EDT) Received: from siso_server.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.244.219.1]) id QQjkea08339 for ; Mon, 9 Oct 2000 14:00:10 GMT Received: by SISO_SERVER with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Oct 2000 19:31:21 +0530 Message-ID: From: Sridhar To: "'mpls@uu.net'" Subject: MPLS/BGP VPN - public access & Private access together Date: Mon, 9 Oct 2000 19:31:18 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, This diagram is the case described in MPLS - Technology and applications by Yakov Rekhter and Bruce Davis in Page Number 242/244 |-------| |-------| |-------| |-------| |-------| |-------| | VPN A |__| CE1 |___| PE 1 | | PE 2 |___| CE2 |__| VPN A | | HOST | | | | | | | | | | Host | |-------| |-------| |-------| |-------| |-------| |-------| | | | | |-------| | | | | |-------| | VPN B |______| | | |______| VPN B | | Host | | | | Host | |-------| |-------| |-------| |-------| | P 1 |_____| P 2 | | | | | |-------| |-------| If CE1 is not supporting MPLS then it will be sending the traffic to PE with the same label for both VPNs (VPN A and VPN B). Can anybody tell me how a host in VPN A will be able to use both public network and VPN at the same time from a single host? Or is it that at a time we can use only VPN and will not be able to use Public network from that system? If we are able to use both of them at the same time then how will PE identify that it is not a VPN session? Thanks in Advance, Sridhar From owner-mpls@UU.NET Mon Oct 9 10:21:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04619 for ; Mon, 9 Oct 2000 10:21:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkeb07432; Mon, 9 Oct 2000 14:21:19 GMT Received: by mail-control.mail.uu.net id QQjkeb21291 for mpls-outgoing; Mon, 9 Oct 2000 14:20:44 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkeb21286 for ; Mon, 9 Oct 2000 14:20:44 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkeb13581 for ; Mon, 9 Oct 2000 14:20:14 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkeb17470 for ; Mon, 9 Oct 2000 14:20:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA02405 for mpls@uu.net; Mon, 9 Oct 2000 10:20:13 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjkeb21251 for ; Mon, 9 Oct 2000 14:19:59 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkeb09892 for ; Mon, 9 Oct 2000 10:16:44 -0400 (EDT) Received: from p-mail2.cnet.fr by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQjkeb00967 for ; Mon, 9 Oct 2000 14:16:43 GMT Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <4JWLYAPM>; Mon, 9 Oct 2000 16:15:51 +0200 Message-ID: <98388C05D464D111B61800805F150416015B9A2F@p-ibis.issy.cnet.fr> From: GUESDON Herve FTRD/DAC/ISS To: "'Sridhar'" , "'mpls@uu.net'" , "'nbvpn@bbo.com'" Subject: RE: MPLS/BGP VPN - public access & Private access together Date: Mon, 9 Oct 2000 16:15:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA04619 Sridhar I suppose that you want to build a Network Based VPN using the RFC2547 architecture. In that architecture, providing a public (Internet) access to a VPN is describe in draft-rosen-rfc2547bis-02.txt. Note that you can apply these designs using the Virtual Router architecture (draft-ouldbrahim-vpn-vr-01.txt). I aggree with Jesica that this discussion has to take place in the nbvpn@bbo.com mailing list and not in the mpls one. You can find the nbvpn mailing-list and drafts at http://nbvpn.francetelecom.com/ Regards herve **************************************************************** Hervé Guesdon DAC/CPN/RRI Research and Development Engineer IP Routing and VPN lab France Télécom - R&D 38-40 rue du Général-Leclerc 92794 Issy Moulineaux Cedex 9 France phone : +33.1.45.29.43.74 fax : +33.1.45.29.54.11 **************************************************************** "L'avenir c'est du passé en préparation." >-----Message d'origine----- >De : Sridhar [mailto:sridhar@samsung.co.kr] >Envoyé : lundi 9 octobre 2000 16:01 >À : 'mpls@uu.net' >Objet : MPLS/BGP VPN - public access & Private access together > > >Hello, > >This diagram is the case described in MPLS - Technology and >applications by >Yakov Rekhter and Bruce Davis in Page Number 242/244 > > >|-------| |-------| |-------| |-------| |-------| |-------| >| VPN A |__| CE1 |___| PE 1 | | PE 2 |___| CE2 |__| VPN A | >| HOST | | | | | | | | | | Host | >|-------| |-------| |-------| |-------| |-------| |-------| > | | | | >|-------| | | | | |-------| >| VPN B |______| | | |______| VPN B | >| Host | | | | Host | >|-------| |-------| |-------| |-------| > | P 1 |_____| P 2 | > | | | | > |-------| |-------| > >If CE1 is not supporting MPLS then it will be sending the >traffic to PE with >the same label for both VPNs (VPN A and VPN B). > >Can anybody tell me how a host in VPN A will be able to use both public >network and VPN at the same time from a single host? > Or >is it that at a time we can use only VPN and will not be able >to use Public >network from that system? > >If we are able to use both of them at the same time then how will PE >identify that it is not a VPN session? > >Thanks in Advance, >Sridhar > From owner-mpls@UU.NET Mon Oct 9 10:46:23 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05003 for ; Mon, 9 Oct 2000 10:46:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjked11600; Mon, 9 Oct 2000 14:46:24 GMT Received: by mail-control.mail.uu.net id QQjked24207 for mpls-outgoing; Mon, 9 Oct 2000 14:45:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjked24191 for ; Mon, 9 Oct 2000 14:45:32 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjked14097 for ; Mon, 9 Oct 2000 10:45:14 -0400 (EDT) Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjked04051 for ; Mon, 9 Oct 2000 14:45:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA06043 for mpls@uu.net; Mon, 9 Oct 2000 10:45:12 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjkec23929 for ; Mon, 9 Oct 2000 14:44:32 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkec13919 for ; Mon, 9 Oct 2000 10:44:09 -0400 (EDT) Received: from exchsrv1.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjkec20149 for ; Mon, 9 Oct 2000 14:44:08 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Oct 2000 07:43:01 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29111DB8DE@exchsrv1.cosinecom.com> From: Jieyun Jessica Yu To: "'raszuk@cisco.com'" , mpls@UU.NET Cc: Bala Rajagopalan , curtis@avici.com, Eric Gray , Michel Redondo Ferrero Subject: RE: MPLS/BGP routing question Date: Mon, 9 Oct 2000 07:42:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C031FF.3374D490" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C031FF.3374D490 Content-Type: text/plain; charset="iso-8859-1" Robert Raszuk said: >2. Satoru Matsushima said: >> When a LSP of PE to PE broken, BGP has no way of LSP broken. >> I think this is one of most seriously problem of BGP/MPLS VPN. >Not true when we are talking about prefix based LSPs. If you are using >prefix based LSPs they will disappear only if ip route to bgp next hop >will disappear what in turn will cause bgp route withdrawn (invalid bgp >next hop) at a periodic scanner. If there is no route - you will not be >able to route anyway - no miracles here. I think the black-hole senario Satoru described can happen in prefix based LSPs. The BGP next hop is learned via IGP so if for some reason the IGP is up but the mpls tunnel fail to established, the blackhole would happen. In this case, the RR will still pass the route to the PE via IBGP because it has no idea te LSP is broken and the PE will still install routes from the RR since the bgp next hop learned via IGP is there. The question is how likely this will happen in operation. For that, Eric and Satoru had an exchange which I will include below. This is sort of similar to the situation of Route Server (RS) serving at the NAPs where FDDI or gigaE were used. NAP is a facility where ISPs routers connect directly via a common media such as FDDI in elary days or others and exchange routing information via BGP. To improve scalability, instead of having all ISP routers BGP peer with each other (full mesh peering), a RS is used to pass the information so each ISP router just needs to peer with the RS. The problem encountered was that somehow the layer2 connection lost between a pair of routers while the RS won't know (if can since it is not in the data pass) it and still passing routes between them. As a result, it causes traffic blackholing. When I was involved in RS operation, it happened more than what anticipated. So it is hard to say definitely this is not going to (or goig to) happen in the MPLS VPN situation until we have more operational experiences. --Jessica The exchange between Eric R. and Satoru: on 00.9.30 0:32 AM, Eric Rosen at erosen@cisco.com wrote: > > Matsushima> When a LSP of PE to PE broken, BGP has no way of LSP broken. > Matsushima> Then, BGP keep up of VPN routes and VPN traffic going to black > Matsushima> hole, until LSP available. > > Matsushima> As a result, VPN customer can not back up their traffic to any > Matsushima> link. > > Matsushima> I think this is one of most seriously problem of BGP/MPLS VPN. > > The situation you are worried about is where there is IGP connectivity > between the edges, but for some reason labeled packets cannot make it from > one edge to another. Yes, exactly. > I guess we don't really see this as a realistic failure > scenario. Sure, buggy software could cause this, but there's a million ways > in which buggy software could cause undetected packet loss. > I think that LSP failure was caused by not only buggy software but also oparation failure. For example, i) erase a interface as LDP ID ;-< , ii) routes summarization failure on ospf area,... IMO, BGP which on PE should has some way to know of LSP failure. This is for customer. -- Satoru Matsushima ------_=_NextPart_001_01C031FF.3374D490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS/BGP routing question

Robert Raszuk said:

>2. Satoru Matsushima said:

>> When a LSP of PE to PE broken, BGP has no = way of LSP broken.
>> I think this is one of most seriously = problem of BGP/MPLS VPN.

>Not true when we are talking about prefix based = LSPs. If you are using
>prefix based LSPs they will disappear only if ip = route to bgp next hop
>will disappear what in turn will cause bgp route = withdrawn (invalid bgp
>next hop) at a periodic scanner. If there is no = route - you will not be
>able to route anyway - no miracles here.

I think the black-hole senario Satoru described can = happen in prefix based LSPs. The BGP next hop is learned via IGP so if = for some reason the IGP is up but the mpls tunnel fail to established, = the blackhole would happen. In this case, the RR will still pass the = route to the PE via IBGP because it has no idea te LSP is broken and = the PE will still install routes from the RR since the bgp next hop = learned via IGP is there.

The question is how likely this will happen in = operation. For that, Eric and Satoru had an exchange which I will = include below.

This is sort of similar to the situation of Route = Server (RS) serving at the NAPs where FDDI or gigaE were used. NAP is a = facility where ISPs routers connect directly via a common media such as = FDDI in elary days or others and exchange routing information via BGP. = To improve scalability, instead of having all ISP routers BGP peer with = each other (full mesh peering), a RS is used to pass the information so = each ISP router just needs to peer with the RS. The problem encountered = was that somehow the layer2 connection lost between a pair of routers = while the RS won't know (if can since it is not in the data pass) it = and still passing routes between them. As a result, it causes traffic = blackholing. When I was involved in RS operation, it happened more than = what anticipated. So it is hard to say definitely this is not going to = (or goig to) happen in the MPLS VPN situation until we have more = operational experiences.

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;            = --Jessica


The exchange between Eric R. and Satoru:

on 00.9.30 0:32 AM, Eric Rosen at erosen@cisco.com = wrote:

>
> Matsushima> When a  LSP of PE to  = PE broken, BGP  has no way of  LSP broken.
> Matsushima> Then, BGP keep  up of VPN = routes and VPN  traffic going to black
> Matsushima> hole, until LSP = available.
>
> Matsushima> As a result,  VPN customer = can not back up  their traffic to any
> Matsushima> link.
>
> Matsushima> I think this is one of most = seriously problem of BGP/MPLS VPN.
>
> The  situation you  are worried  = about is  where there  is  IGP connectivity
> between the edges,  but for some reason = labeled packets  cannot make it from
> one edge to another.

Yes, exactly.

> I guess we don't really see this as a realistic = failure
> scenario.  Sure, buggy software could = cause this, but there's a million ways
> in which buggy software could cause undetected = packet loss.
>

I think that LSP failure was caused by not only buggy = software but also
oparation failure.
For example, i) erase a interface as LDP ID ;-< , = ii) routes summarization
failure on ospf area,...

IMO, BGP which on PE should has some way to know of = LSP failure.
This is for customer.

--
Satoru Matsushima

------_=_NextPart_001_01C031FF.3374D490-- From owner-mpls@UU.NET Mon Oct 9 10:53:20 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05102 for ; Mon, 9 Oct 2000 10:53:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjked03200; Mon, 9 Oct 2000 14:53:20 GMT Received: by mail-control.mail.uu.net id QQjked24905 for mpls-outgoing; Mon, 9 Oct 2000 14:52:46 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjked24881 for ; Mon, 9 Oct 2000 14:52:34 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjked22024 for ; Mon, 9 Oct 2000 10:52:30 -0400 (EDT) Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjked01999 for ; Mon, 9 Oct 2000 14:52:30 GMT Received: from tellium.com (node1.tellium.com [151.198.92.15]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e99Eir724070; Mon, 9 Oct 2000 10:44:53 -0400 (EDT) Message-ID: <39E1DBAF.44334F05@tellium.com> Date: Mon, 09 Oct 2000 10:52:32 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Eric Gray , Michel Redondo Ferrero , mpls@UU.NET Subject: Re: MPLS/BGP routing question References: <39DE2EE1.17C53BC2@tellium.com> <8903.001008@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Alex, Alex Zinin wrote: > Bala, > > Note that with today BGP that border OXC will be the next-hop > for all IP prefixes it announces to the client via the e-BGP > session. This means that the client does not really know > much about the egress point per prefix and hence where it should > establish LSPs across the optical transport network unless we > add a kind of "suggested next-hop" BGP attribute as a part > of optical UNI (I don't think it makes sense to run e-BGP > in the peer model) to inform the client about the egress > points. What you say about egress point is true. This is in fact what we had proposed in our draft, draft-prs-optical-routing-00.ps (.txt). > > > I think Curtis' point is that OXCs do not really need to > have BGP routes in their routing table for normal operation > of circuit provisioning protocols. Unless someone explains what Curtis means, it's hard to get the point (usually). {A reluctant :-) here may be added if desired.} Bala > > > Alex. > > >> Optical switches are not known for the robustness of their BGP > >> implementations if they have BGP implementations at all. They may > >> also have more important things to do with their CPU cycles given that > >> they do no externalrouting at all. It would seem to be a relly bad > >> idea to run IBGP to the optical switches. > >> > >> I hope that was more clear. > > > Absolutely not. It's certainly seems possible to have > > a scenario where optical edge switches run E-BGP > > with router clients to provide reachability information. Whether > > the optical network is a separate AS or a sub-AS is another issue. > > What's wrong with this? > > > Bala > > > -- > > > Bala Rajagopalan > > Tellium, Inc. > > 2 Crescent Place > > P.O. Box 901 > > Oceanport, NJ 07757-0901 > > Tel: (732) 923-4237 > > Fax: (732) 923-9804 > > Email: braja@tellium.com -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Mon Oct 9 10:56:46 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05149 for ; Mon, 9 Oct 2000 10:56:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjked28773; Mon, 9 Oct 2000 14:56:46 GMT Received: by mail-control.mail.uu.net id QQjked25380 for mpls-outgoing; Mon, 9 Oct 2000 14:56:30 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjked25361 for ; Mon, 9 Oct 2000 14:56:21 GMT Received: from cmr0.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjked22549 for ; Mon, 9 Oct 2000 10:56:07 -0400 (EDT) Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjked27211 for ; Mon, 9 Oct 2000 14:56:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA08296 for mpls@uu.net; Mon, 9 Oct 2000 10:56:05 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjked25194 for ; Mon, 9 Oct 2000 14:55:34 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjked15782 for ; Mon, 9 Oct 2000 10:55:20 -0400 (EDT) Received: from exchsrv1.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjked06250 for ; Mon, 9 Oct 2000 14:55:19 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Oct 2000 07:54:12 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29111DB8DF@exchsrv1.cosinecom.com> From: Jieyun Jessica Yu To: "'GUESDON Herve FTRD/DAC/ISS'" , "'Sridhar'" , "'mpls@uu.net'" , "'nbvpn@bbo.com'" Subject: RE: MPLS/BGP VPN - public access & Private access together Date: Mon, 9 Oct 2000 07:54:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03200.C8226520" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03200.C8226520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to clarify, the one implementation I mentioned in my earlier = message is VPN implemented with IPsec VR model.=20 cheers! --Jessica -----Original Message----- From: GUESDON Herve FTRD/DAC/ISS [mailto:herve.guesdon@rd.francetelecom.fr] Sent: Monday, October 09, 2000 7:16 AM To: 'Sridhar'; 'mpls@uu.net'; 'nbvpn@bbo.com' Subject: RE: MPLS/BGP VPN - public access & Private access together Sridhar=20 I suppose that you want to build a Network Based VPN using the RFC2547 architecture. In that architecture, providing a public (Internet) = access to a VPN is describe in draft-rosen-rfc2547bis-02.txt. Note that you can = apply these designs using the Virtual Router architecture (draft-ouldbrahim-vpn-vr-01.txt). I aggree with Jesica that this discussion has to take place in the nbvpn@bbo.com mailing list and not in the mpls one. You can find the = nbvpn mailing-list and drafts at http://nbvpn.francetelecom.com/ Regards herve **************************************************************** Herv=E9 Guesdon DAC/CPN/RRI Research and Development Engineer IP Routing and VPN lab France T=E9l=E9com - R&D 38-40 rue du G=E9n=E9ral-Leclerc =20 92794 Issy Moulineaux Cedex 9 France phone : +33.1.45.29.43.74 fax : +33.1.45.29.54.11 **************************************************************** "L'avenir c'est du pass=E9 en pr=E9paration." >-----Message d'origine----- >De : Sridhar [mailto:sridhar@samsung.co.kr] >Envoy=E9 : lundi 9 octobre 2000 16:01 >=C0 : 'mpls@uu.net' >Objet : MPLS/BGP VPN - public access & Private access together > > >Hello, > >This diagram is the case described in MPLS - Technology and=20 >applications by >Yakov Rekhter and Bruce Davis in Page Number 242/244 > > >|-------| |-------| |-------| |-------| |-------| |-------| >| VPN A |__| CE1 |___| PE 1 | | PE 2 |___| CE2 |__| VPN A | >| HOST | | | | | | | | | | Host | >|-------| |-------| |-------| |-------| |-------| |-------| > | | | | >|-------| | | | | |-------| >| VPN B |______| | | |______| VPN B | >| Host | | | | Host | >|-------| |-------| |-------| |-------| > | P 1 |_____| P 2 | > | | | | > |-------| |-------| > >If CE1 is not supporting MPLS then it will be sending the=20 >traffic to PE with >the same label for both VPNs (VPN A and VPN B). > >Can anybody tell me how a host in VPN A will be able to use both = public >network and VPN at the same time from a single host?=20 > Or=20 >is it that at a time we can use only VPN and will not be able=20 >to use Public >network from that system? > >If we are able to use both of them at the same time then how will PE >identify that it is not a VPN session? > >Thanks in Advance, >Sridhar > ------_=_NextPart_001_01C03200.C8226520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS/BGP VPN - public access & Private access = together

Just to clarify, the one implementation I mentioned = in my earlier message is VPN implemented with IPsec VR model.

cheers!
          &nb= sp;       --Jessica

-----Original Message-----
From: GUESDON Herve FTRD/DAC/ISS
[mailto:herve.guesdon@r= d.francetelecom.fr]
Sent: Monday, October 09, 2000 7:16 AM
To: 'Sridhar'; 'mpls@uu.net'; 'nbvpn@bbo.com'
Subject: RE: MPLS/BGP VPN - public access & = Private access together


Sridhar

I suppose that you want to build a Network Based VPN = using the RFC2547
architecture. In that architecture, providing a = public (Internet) access to
a VPN is describe in draft-rosen-rfc2547bis-02.txt. = Note that you can apply
these designs using the Virtual Router = architecture
(draft-ouldbrahim-vpn-vr-01.txt).

I aggree with Jesica that this discussion has to take = place in the
nbvpn@bbo.com mailing list and not in the mpls one. = You can find the nbvpn
mailing-list and drafts at http://nbvpn.francetelecom.com/

Regards

herve


***************************************************************= *
Herv=E9 = Guesdon           = ;            = ;            = ; DAC/CPN/RRI
Research and Development Engineer
IP Routing and VPN lab
France T=E9l=E9com - R&D
38-40 rue du G=E9n=E9ral-Leclerc 
92794 Issy Moulineaux Cedex 9  France
phone : +33.1.45.29.43.74  fax : = +33.1.45.29.54.11
***************************************************************= *

"L'avenir c'est du pass=E9 en = pr=E9paration."


>-----Message d'origine-----
>De : Sridhar [mailto:sridhar@samsung.co.kr]<= /FONT>
>Envoy=E9 : lundi 9 octobre 2000 16:01
>=C0 : 'mpls@uu.net'
>Objet : MPLS/BGP VPN - public access & = Private access together
>
>
>Hello,
>
>This diagram is the case described in MPLS - = Technology and
>applications by
>Yakov Rekhter and Bruce Davis in Page Number = 242/244
>
>
>|-------|  |-------|   = |-------|     |-------|   |-------|  = |-------|
>| VPN A |__| CE1   |___| PE 1  = |     | PE 2  |___| CE2   |__| VPN A = |
>| HOST  |  = |       |   = |       |     = |       |   = |       |  | Host  |
>|-------|  |-------|   = |-------|     |-------|   |-------|  = |-------|
>          = ;     = |           = |            = |            = |
>|-------|      = |           = |            = |            = |      |-------|
>| VPN B = |______|           = |            = |            = |______| VPN B |
>| Host  = |            = ;      = |            = |            = ;       | Host  |
>|-------|        &n= bsp;     |-------|     = |-------|          &nb= sp;   |-------|
>          = ;            = ; | P 1   |_____|  P 2  |
>          = ;            = ; |       |     = |       |
>          = ;            = ; |-------|     |-------|
>
>If CE1 is not supporting MPLS then it will be = sending the
>traffic to PE with
>the same label for both VPNs (VPN A and VPN = B).
>
>Can anybody tell me how a host in VPN A will be = able to use both public
>network and VPN at the same time from a single = host?
>       =         =         =         Or
>is it that at a time we can use only VPN and = will not be able
>to use Public
>network from that system?
>
>If we are able to use both of them at the same = time then how will PE
>identify that it is not a VPN session?
>
>Thanks in Advance,
>Sridhar
>

------_=_NextPart_001_01C03200.C8226520-- From owner-mpls@UU.NET Mon Oct 9 13:09:41 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06999 for ; Mon, 9 Oct 2000 13:09:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkem10245; Mon, 9 Oct 2000 17:09:40 GMT Received: by mail-control.mail.uu.net id QQjkem10922 for mpls-outgoing; Mon, 9 Oct 2000 17:09:07 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkem10916 for ; Mon, 9 Oct 2000 17:09:00 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkem04048 for ; Mon, 9 Oct 2000 17:08:52 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkem21811 for ; Mon, 9 Oct 2000 17:08:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA27447 for mpls@uu.net; Mon, 9 Oct 2000 13:08:51 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjkem10829 for ; Mon, 9 Oct 2000 17:08:13 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkem11796 for ; Mon, 9 Oct 2000 13:08:05 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjkem07722 for ; Mon, 9 Oct 2000 17:08:04 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA27077; Mon, 9 Oct 2000 10:08:06 -0700 (PDT) Received: from cisco.com (warsaw.cisco.com [171.69.71.119]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA04309; Mon, 9 Oct 2000 10:08:03 -0700 (PDT) Message-ID: <39E267B8.DA822F39@cisco.com> Date: Mon, 09 Oct 2000 17:50:00 -0700 From: Robert Raszuk Reply-To: rraszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Terminology Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit While talking to a lot of people about mpls applications (or even watching this alias or drafts :) I see a lot of confusion about calling different kinds of label switched paths as LSPs. The problem with this is that all of them have very different characteristics - based on very different control planes used to established them - with only one common part (in the first two at least) imposed label shim(s) into ip unicast packet. I think about a year ago Lou presented clear separation: * prefix based LSPs - those established based on the routes (carried by IGPs), MP-BGP, PIM etc ... * tunnel based LSPs - those established by extensions to RSVP or by CR-LDP. Now we also cold add third type: * optical LSPs - established by MPLambda based control plane in optical domains I personally hate acronyms, but maybe to avoid any further confusion we could append one letter to the LSP itself and start using P-LSP, T-LSPs or O-LSPs to clearly indicate what we are talking about ? If somebody has better suggestions feel free to propose. I just don't know anymore what one means by term "mpls tunnel". R. From owner-mpls@UU.NET Mon Oct 9 13:24:15 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07199 for ; Mon, 9 Oct 2000 13:24:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjken20543; Mon, 9 Oct 2000 17:24:15 GMT Received: by mail-control.mail.uu.net id QQjken12841 for mpls-outgoing; Mon, 9 Oct 2000 17:23:50 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjken12836 for ; Mon, 9 Oct 2000 17:23:42 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjken14997 for ; Mon, 9 Oct 2000 13:23:27 -0400 (EDT) Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjken16772 for ; Mon, 9 Oct 2000 17:23:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA29731 for mpls@uu.net; Mon, 9 Oct 2000 13:23:26 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjken12329 for ; Mon, 9 Oct 2000 17:21:25 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjken15586 for ; Mon, 9 Oct 2000 17:21:22 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjken14782 for ; Mon, 9 Oct 2000 17:21:20 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA29969; Mon, 9 Oct 2000 10:21:45 -0700 (PDT) Received: from cisco.com (warsaw.cisco.com [171.69.71.119]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA04314; Mon, 9 Oct 2000 10:21:19 -0700 (PDT) Message-ID: <39E26AD4.7C532412@cisco.com> Date: Mon, 09 Oct 2000 18:03:16 -0700 From: Robert Raszuk Reply-To: rraszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Grenville Armitage CC: mpls@UU.NET Subject: Re: Terminology References: <39E267B8.DA822F39@cisco.com> <39E1FD24.33E63C3E@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Grenville, > on what basis an LSP is established > doesn't really change how it behaves From operational expereince with them for a decent time I see that it really does change how it behavies depending on how it got setup/build. Of course in steady state both are fine and doing the same, but when things start to melt or break that is when you see big differences. R. > Grenville Armitage wrote: > > Robert Raszuk wrote: > [..] > > I just don't know anymore > > what one means by term "mpls tunnel". > > generically an LSP is always a tunnel of sorts, since the > IP header of the MPLS payload is thereby always hidden from > the intermediate LSR hops. on what basis an LSP is established > doesn't really change how it behaves as a form of 'tunnel' > in the data path.... > > gja From owner-mpls@UU.NET Mon Oct 9 13:42:23 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07471 for ; Mon, 9 Oct 2000 13:42:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkeo16891; Mon, 9 Oct 2000 17:42:23 GMT Received: by mail-control.mail.uu.net id QQjkeo14087 for mpls-outgoing; Mon, 9 Oct 2000 17:41:54 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkeo14082 for ; Mon, 9 Oct 2000 17:41:51 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkeo21091 for ; Mon, 9 Oct 2000 17:41:41 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkeo17038 for ; Mon, 9 Oct 2000 17:41:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA02735 for mpls@uu.net; Mon, 9 Oct 2000 13:41:39 -0400 (EDT) Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjkeo13981 for ; Mon, 9 Oct 2000 17:41:30 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkeo16606 for ; Mon, 9 Oct 2000 13:41:27 -0400 (EDT) Received: from nova.tx.fnc.fujitsu.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nova.tx.fnc.fujitsu.com [167.254.254.131]) id QQjkeo16542 for ; Mon, 9 Oct 2000 17:41:26 GMT Received: from miranda.tx.fnc.fujitsu.com (localhost [127.0.0.1]) by nova.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id MAA21239 for ; Mon, 9 Oct 2000 12:41:25 -0500 (CDT) Received: from tdd144146.tx.fnc.fujitsu.com (tdd144146.tddeng00.fnts.com [167.254.144.146]) by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22196 for ; Mon, 9 Oct 2000 12:41:25 -0500 (CDT) Received: from fnc.fujitsu.com (localhost [127.0.0.1]) by tdd144146.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id MAA27431 for ; Mon, 9 Oct 2000 12:41:25 -0500 (CDT) Message-ID: <39E20345.7E7FF1D5@fnc.fujitsu.com> Date: Mon, 09 Oct 2000 12:41:25 -0500 From: "(Eddie) Tzu Cheng Young" X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit auth 3b2aa3af subscribe mpls Tzu.Young@fnc.fujitsu.com From owner-mpls@UU.NET Mon Oct 9 13:53:33 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07555 for ; Mon, 9 Oct 2000 13:53:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkep13414; Mon, 9 Oct 2000 17:53:33 GMT Received: by mail-control.mail.uu.net id QQjkep14942 for mpls-outgoing; Mon, 9 Oct 2000 17:53:14 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjkep14937 for ; Mon, 9 Oct 2000 17:53:04 GMT Received: from cmr1.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkep19007 for ; Mon, 9 Oct 2000 13:53:00 -0400 (EDT) Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkep12414 for ; Mon, 9 Oct 2000 17:52:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA05168 for mpls@uu.net; Mon, 9 Oct 2000 13:52:58 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkep14926 for ; Mon, 9 Oct 2000 17:52:34 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkep27327 for ; Mon, 9 Oct 2000 17:52:01 GMT Received: from dirty.research.bell-labs.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQjkep00401 for ; Mon, 9 Oct 2000 17:52:01 GMT Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Oct 9 13:50:50 EDT 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Mon Oct 9 13:50:50 EDT 2000 Received: from research.bell-labs.com (ex-vpn70.pa.bell-labs.com [135.250.1.70]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAV25489 (AUTH gja); Mon, 9 Oct 2000 10:50:47 -0700 (PDT) Message-ID: <39E2059A.16421311@research.bell-labs.com> Date: Mon, 09 Oct 2000 10:51:22 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rraszuk@cisco.com CC: mpls@UU.NET Subject: Re: Terminology References: <39E267B8.DA822F39@cisco.com> <39E1FD24.33E63C3E@research.bell-labs.com> <39E26AD4.7C532412@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit robert, aside from the (lack of)ethics associated with reposting private email back to the list, please at least do me the courtesy of taking my comments in context. quite clearly i made a restricted observation - viz. when the LSPs are up they essentially function as tunnels since the inside packets are isolated from the intermediate LSRs' forwarding machinery. gja Robert Raszuk wrote: > > Grenville, > > > on what basis an LSP is established > > doesn't really change how it behaves > > >From operational expereince with them for a decent time I see that it > really does change how it behavies depending on how it got setup/build. > Of course in steady state both are fine and doing the same, but when > things start to melt or break that is when you see big differences. > > R. > > > Grenville Armitage wrote: > > > > Robert Raszuk wrote: > > [..] > > > I just don't know anymore > > > what one means by term "mpls tunnel". > > > > generically an LSP is always a tunnel of sorts, since the > > IP header of the MPLS payload is thereby always hidden from > > the intermediate LSR hops. on what basis an LSP is established > > doesn't really change how it behaves as a form of 'tunnel' > > in the data path.... > > > > gja -- ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Mon Oct 9 14:01:48 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07645 for ; Mon, 9 Oct 2000 14:01:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkeq13965; Mon, 9 Oct 2000 18:01:48 GMT Received: by mail-control.mail.uu.net id QQjkeq19322 for mpls-outgoing; Mon, 9 Oct 2000 18:01:30 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjkeq18539 for ; Mon, 9 Oct 2000 18:01:14 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkeq19490 for ; Mon, 9 Oct 2000 14:00:59 -0400 (EDT) Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkeq27035 for ; Mon, 9 Oct 2000 18:00:58 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA06879 for mpls@uu.net; Mon, 9 Oct 2000 14:00:58 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkeq18274 for ; Mon, 9 Oct 2000 18:00:47 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkeq17708 for ; Mon, 9 Oct 2000 18:00:37 GMT Received: from nova.tx.fnc.fujitsu.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nova.tx.fnc.fujitsu.com [167.254.254.131]) id QQjkeq26372 for ; Mon, 9 Oct 2000 18:00:36 GMT Received: from miranda.tx.fnc.fujitsu.com (localhost [127.0.0.1]) by nova.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id NAA22605 for ; Mon, 9 Oct 2000 13:00:36 -0500 (CDT) Received: from tdd144146.tx.fnc.fujitsu.com (tdd144146.tddeng00.fnts.com [167.254.144.146]) by miranda.tx.fnc.fujitsu.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23580 for ; Mon, 9 Oct 2000 13:00:35 -0500 (CDT) Received: from fnc.fujitsu.com (localhost [127.0.0.1]) by tdd144146.tx.fnc.fujitsu.com (8.8.8+Sun/8.8.8) with ESMTP id NAA27464 for ; Mon, 9 Oct 2000 13:00:35 -0500 (CDT) Message-ID: <39E207C3.76C9F87@fnc.fujitsu.com> Date: Mon, 09 Oct 2000 13:00:35 -0500 From: "(Eddie) Tzu Cheng Young" X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit auth 3b2aa3af subscribe mpls Tzu.Young@fnc.fujitsu.com From owner-mpls@UU.NET Mon Oct 9 14:56:00 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08181 for ; Mon, 9 Oct 2000 14:56:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjket13185; Mon, 9 Oct 2000 18:56:00 GMT Received: by mail-control.mail.uu.net id QQjket00546 for mpls-outgoing; Mon, 9 Oct 2000 18:55:28 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjket00541 for ; Mon, 9 Oct 2000 18:55:26 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjket23396 for ; Mon, 9 Oct 2000 18:54:56 GMT Received: from nfl.METERA.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.114.212.50]) id QQjket07164 for ; Mon, 9 Oct 2000 18:54:56 GMT Received: from slapshot.metera.com ([12.19.1.154]) by nfl.METERA.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4MQB1D85; Mon, 9 Oct 2000 13:52:16 -0500 Received: from slrams.metera.com (slrams [12.19.1.159]) by slapshot.metera.com (8.9.3+Sun/8.9.1) with ESMTP id NAA17266 for ; Mon, 9 Oct 2000 13:54:55 -0500 (CDT) Received: from metera.com (localhost [127.0.0.1]) by slrams.metera.com (8.9.3+Sun/8.9.1) with ESMTP id NAA01050 for ; Mon, 9 Oct 2000 13:54:54 -0500 (CDT) Message-ID: <39E2147E.B098CA65@metera.com> Date: Mon, 09 Oct 2000 13:54:54 -0500 From: Nimer Yaseen X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "'mpls@UU.NET'" Subject: Questions Content-Type: multipart/mixed; boundary="------------A77F6FC52D0D69E682C260FD" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------A77F6FC52D0D69E682C260FD Content-Type: multipart/alternative; boundary="------------C6485905604479589A871DB2" --------------C6485905604479589A871DB2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does any body have any information about the QoS hose model ? Based on rfc2547, does the PE have to be compliant with RFC1812 in terms of ICMP messages? Thanks, Nimer -- Nimer Yaseen Metera Networks Inc. Software Engineer 1202 Richardson DR, nimer.yaseen@metera.com Richardson, TX 75080 469-330-1705 (O) 972-669-8346(F) www.metera.com --------------C6485905604479589A871DB2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Does any body have any information about the QoS hose model ?
Based on rfc2547, does the PE have to be compliant with RFC1812  in terms of ICMP messages?

Thanks,

Nimer 

-- 
Nimer Yaseen                           Metera Networks Inc.
Software Engineer                      1202 Richardson DR,
nimer.yaseen@metera.com                Richardson, TX 75080
469-330-1705 (O)    972-669-8346(F)    www.metera.com
  --------------C6485905604479589A871DB2-- --------------A77F6FC52D0D69E682C260FD Content-Type: text/x-vcard; charset=us-ascii; name="nimer.yaseen.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Nimer Yaseen Content-Disposition: attachment; filename="nimer.yaseen.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Yaseen;Nimer x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:nimer.yaseen@metera.com title:Software Engineer x-mozilla-cpt:;-16944 fn:Nimer Yaseen end:vcard --------------A77F6FC52D0D69E682C260FD-- From owner-mpls@UU.NET Mon Oct 9 19:37:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11303 for ; Mon, 9 Oct 2000 19:37:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkfm08089; Mon, 9 Oct 2000 23:37:32 GMT Received: by mail-control.mail.uu.net id QQjkfm20598 for mpls-outgoing; Mon, 9 Oct 2000 23:37:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjkfm20593 for ; Mon, 9 Oct 2000 23:37:01 GMT Received: from cmr2.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkfm29549 for ; Mon, 9 Oct 2000 19:36:59 -0400 (EDT) Received: from mail.cs.umn.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cs.umn.edu [128.101.32.200]) id QQjkfm07279 for ; Mon, 9 Oct 2000 23:36:59 GMT Received: from galaxy.cs.umn.edu (epkumar@galaxy.cs.umn.edu [128.101.35.162]) by mail.cs.umn.edu (8.9.3/8.9.3) with ESMTP id SAA17477 for ; Mon, 9 Oct 2000 18:36:58 -0500 (CDT) Date: Mon, 9 Oct 2000 18:36:57 -0500 (CDT) From: Pranoop Erasani To: mpls@UU.NET Subject: Abt. installation of MPLS patch from wisconsin by james leu! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I'm trying to install the MPLS patch along with the linuy-2.4.0-test7 kernel . I followed the instructions in the QUICK.START and executed mplsadm command to create a label space on interface "eth0". But I didn't see the files "mpls_in" , "mpls_out" in the /proc/net directory. Am I missing something ?? The patch got installed correctly. How do I check that labels are being inserted before the IP header. Any help in this regard would be greatly appreciated ! Thanks, Pranoop From owner-mpls@UU.NET Mon Oct 9 21:28:26 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12286 for ; Mon, 9 Oct 2000 21:28:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkft07052; Tue, 10 Oct 2000 01:28:27 GMT Received: by mail-control.mail.uu.net id QQjkft19508 for mpls-outgoing; Tue, 10 Oct 2000 01:27:51 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjkft19499 for ; Tue, 10 Oct 2000 01:27:39 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkft14497 for ; Mon, 9 Oct 2000 21:27:38 -0400 (EDT) Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkft04686 for ; Tue, 10 Oct 2000 01:27:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA23886 for mpls@uu.net; Mon, 9 Oct 2000 21:27:37 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkft19489 for ; Tue, 10 Oct 2000 01:27:20 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkft26146 for ; Tue, 10 Oct 2000 01:27:18 GMT Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjkft15399 for ; Tue, 10 Oct 2000 01:27:17 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA04655; Mon, 9 Oct 2000 18:27:15 -0700 (PDT) Date: Mon, 9 Oct 2000 18:21:25 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <18764.001009@cisco.com> To: ospf@discuss.microsoft.com, "'ISISWG'" , "'mpls@UU.NET'" Subject: draft-ietf-zinin-flood-opt-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, The new version of the flooding optimization draft has been submitted to the IETF directories today. So far, it is available at the following URL: http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-01.txt Regards, -- Alex Zinin From owner-mpls@UU.NET Tue Oct 10 01:55:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22399 for ; Tue, 10 Oct 2000 01:55:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkgl14240; Tue, 10 Oct 2000 05:55:05 GMT Received: by mail-control.mail.uu.net id QQjkgl19800 for mpls-outgoing; Tue, 10 Oct 2000 05:54:33 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkgl19793 for ; Tue, 10 Oct 2000 05:54:25 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkgl29386 for ; Tue, 10 Oct 2000 05:54:22 GMT Received: from www.netlabs.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: www.netlabs.net [216.116.128.3]) id QQjkgl12256 for ; Tue, 10 Oct 2000 05:54:22 GMT Received: from console (arni.netlabs.net [216.116.143.247]) by www.netlabs.net (8.9.3/8.9.3) with SMTP id BAA24764; Tue, 10 Oct 2000 01:56:23 -0400 (EDT) Message-ID: <00e001c0327e$e5db5a80$0a02a8c0@itl.ispsoft.com> From: "Arni Raghu" To: "Pranoop Erasani" , References: Subject: Re: Abt. installation of MPLS patch from wisconsin by james leu! Date: Tue, 10 Oct 2000 01:56:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am not sure if this is the right mailing list..maybe mpls-ops..pls move this thread there..for now I am replying on this mailing list.. answering you question..are u sure you are using the patched kernel..?? pls check you kernel symbols to ensure this..do u see any mpls in the kernel synmols at all.. also showing us how you ran mplsadm would sure help.. Use ethereal to see if you packets are being labeled.. hth, A > > Hi, > > I'm trying to install the MPLS patch along with the linuy-2.4.0-test7 > kernel . > I followed the instructions in the QUICK.START and executed mplsadm > command to create a label space on interface "eth0". But I didn't see the > files "mpls_in" , "mpls_out" in the /proc/net directory. Am I missing > something ?? > > The patch got installed correctly. How do I check that labels are being > inserted before the IP header. > Any help in this regard would be greatly appreciated ! > > Thanks, > Pranoop > > > From owner-mpls@UU.NET Tue Oct 10 06:43:14 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00811 for ; Tue, 10 Oct 2000 06:43:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkhe08938; Tue, 10 Oct 2000 10:42:47 GMT Received: by mail-control.mail.uu.net id QQjkhe02683 for mpls-outgoing; Tue, 10 Oct 2000 10:42:25 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkhe02678 for ; Tue, 10 Oct 2000 10:42:18 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkhe21848 for ; Tue, 10 Oct 2000 10:42:00 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkhe03535 for ; Tue, 10 Oct 2000 10:41:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA19324 for mpls@uu.net; Tue, 10 Oct 2000 06:41:58 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkhe02662 for ; Tue, 10 Oct 2000 10:41:37 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkhe17694 for ; Tue, 10 Oct 2000 10:40:12 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjkhe05755 for ; Tue, 10 Oct 2000 10:40:11 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00748; Tue, 10 Oct 2000 06:40:10 -0400 (EDT) Message-Id: <200010101040.GAA00748@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-crlsp-modify-02.txt Date: Tue, 10 Oct 2000 06:40:10 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : LSP Modification Using CR-LDP Author(s) : J. Ash, Y. Lee, P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, L. Li Filename : draft-ietf-mpls-crlsp-modify-02.txt Pages : 10 Date : 09-Oct-00 After a CR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP [2]. This contribution presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP using CR-LDP [3] without service interruption. The LSP modification feature can be supported by CR-LDP by use of the _modify_ value for the _action indicator flag_ in the LSPID TLV [3]. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-crlsp-modify-02.txt 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-crlsp-modify-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-crlsp-modify-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001009132335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crlsp-modify-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crlsp-modify-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001009132335.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Oct 10 10:14:49 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04547 for ; Tue, 10 Oct 2000 10:14:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkhs06717; Tue, 10 Oct 2000 14:14:23 GMT Received: by mail-control.mail.uu.net id QQjkhs00643 for mpls-outgoing; Tue, 10 Oct 2000 14:14:04 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkhs00630 for ; Tue, 10 Oct 2000 14:13:55 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkhs07787 for ; Tue, 10 Oct 2000 14:13:54 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjkhs03426 for ; Tue, 10 Oct 2000 14:13:53 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA24898 for ; Tue, 10 Oct 2000 07:14:19 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA18513 for mpls@uu.net; Tue, 10 Oct 2000 10:13:52 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjjud27004 for ; Fri, 6 Oct 2000 21:51:42 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjjud09635 for ; Fri, 6 Oct 2000 21:51:36 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f243.law7.hotmail.com [216.33.237.243]) id QQjjud25707 for ; Fri, 6 Oct 2000 21:51:36 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 6 Oct 2000 14:51:35 -0700 Received: from 4.22.157.70 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 06 Oct 2000 21:51:35 GMT X-Originating-IP: [4.22.157.70] From: "ge ge" To: mpls@UU.NET Date: Fri, 06 Oct 2000 21:51:35 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Oct 2000 21:51:35.0599 (UTC) FILETIME=[98E8F3F0:01C02FDF] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am looking for documents on interworking between ATM and MPLS networks, especially, documents on interworking without IP lookup at an ingress LSR. Thanks. Hao Che _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Wed Oct 11 03:56:25 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04433 for ; Wed, 11 Oct 2000 03:56:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkkl05094; Wed, 11 Oct 2000 07:55:58 GMT Received: by mail-control.mail.uu.net id QQjkkl07599 for mpls-outgoing; Wed, 11 Oct 2000 07:55:37 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjkkl07594 for ; Wed, 11 Oct 2000 07:55:26 GMT Received: from cmr0.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkkl27629 for ; Wed, 11 Oct 2000 03:55:13 -0400 (EDT) Received: from p-mail2.cnet.fr by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQjkkl00061 for ; Wed, 11 Oct 2000 07:55:13 GMT Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <4JWLYT0B>; Wed, 11 Oct 2000 09:54:59 +0200 Received: from rd.francetelecom.fr (lat4074.lannion.cnet.fr [161.104.15.15]) by l-mhs1.lannion.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4V4QFZ16; Wed, 11 Oct 2000 09:53:32 +0200 Message-ID: <39E41CB4.A32DB274@rd.francetelecom.fr> Date: Wed, 11 Oct 2000 09:54:28 +0200 From: Olivier Dugeon Organization: France Telecom R&D X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-9mdksmp i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: mpls@UU.NET Subject: Comment on draft-ietf-mpls-crlsp-modify-02 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, In section 4.1 : "Ri assigns a new label for the Label Request Message." I think this is necessary only for re-routing i.e. ER-TLV changes. For over traffic parameters modification, i think it's preferable to keep the existing label. Because the route doesn't change, it's more simple to keep the existing label (which reflect the path of the LSPID) than change label. Then, you doesn't need to send a Label Release Message. But, to ensure a three-way handshake of the protocol, it must be safe to send a Notification Message instead of a Release Message in this context to confirm the modification by ingress LSR. In this fashion, crlsp modification is much closer than it can be possible with RM Cells (Ressource Management Cells) in ATM network. In section 9 : Why references of crldp and ldp are not up to date ? Where i can find draft-ash-qos-routing-00.txt ? is the same as draft-ash-te-qos-routing-01.txt ? Thanks, Olivier -- FTR&D/DAC/CPN Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.fr 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 F-22307 LANNION | Fax: +(33) 2 96 05 18 52 From owner-mpls@UU.NET Wed Oct 11 06:49:09 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06035 for ; Wed, 11 Oct 2000 06:49:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkkx13435; Wed, 11 Oct 2000 10:48:41 GMT Received: by mail-control.mail.uu.net id QQjkkx21659 for mpls-outgoing; Wed, 11 Oct 2000 10:48:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjkkx21654 for ; Wed, 11 Oct 2000 10:48:13 GMT Received: from cmr0.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkkx14599 for ; Wed, 11 Oct 2000 06:48:11 -0400 (EDT) Received: from mail3.ntu.edu.sg by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.1.91]) id QQjkkx21890 for ; Wed, 11 Oct 2000 10:48:09 GMT Received: by mail3.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 18:47:44 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE01FDD10F@exchange4.ntu.edu.sg> From: Shen Gangxiang To: "'Olivier Dugeon '" , "'mpls@UU.NET '" Subject: RE: Comment on draft-ietf-mpls-crlsp-modify-02 Date: Wed, 11 Oct 2000 18:47:53 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I agree with Olivier's point. Gangxiang -----Original Message----- From: Olivier Dugeon To: mpls@UU.NET Sent: 11/10/00 3:54 PM Subject: Comment on draft-ietf-mpls-crlsp-modify-02 Hi all, In section 4.1 : "Ri assigns a new label for the Label Request Message." I think this is necessary only for re-routing i.e. ER-TLV changes. For over traffic parameters modification, i think it's preferable to keep the existing label. Because the route doesn't change, it's more simple to keep the existing label (which reflect the path of the LSPID) than change label. Then, you doesn't need to send a Label Release Message. But, to ensure a three-way handshake of the protocol, it must be safe to send a Notification Message instead of a Release Message in this context to confirm the modification by ingress LSR. In this fashion, crlsp modification is much closer than it can be possible with RM Cells (Ressource Management Cells) in ATM network. In section 9 : Why references of crldp and ldp are not up to date ? Where i can find draft-ash-qos-routing-00.txt ? is the same as draft-ash-te-qos-routing-01.txt ? Thanks, Olivier -- FTR&D/DAC/CPN Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.fr 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 F-22307 LANNION | Fax: +(33) 2 96 05 18 52 From owner-mpls@UU.NET Wed Oct 11 09:38:44 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10486 for ; Wed, 11 Oct 2000 09:38:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkli29401; Wed, 11 Oct 2000 13:38:10 GMT Received: by mail-control.mail.uu.net id QQjkli05833 for mpls-outgoing; Wed, 11 Oct 2000 13:37:45 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkli05827 for ; Wed, 11 Oct 2000 13:37:38 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkli25516 for ; Wed, 11 Oct 2000 13:36:49 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f195.pav1.hotmail.com [64.4.31.195]) id QQjkli19993 for ; Wed, 11 Oct 2000 13:36:48 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Oct 2000 06:36:48 -0700 Received: from 209.244.212.196 by pv1fd.pav1.hotmail.msn.com with HTTP; Wed, 11 Oct 2000 13:36:47 GMT X-Originating-IP: [209.244.212.196] From: "Ghassen Ben Brahim" To: mpls@UU.NET Subject: OSPF implementation Date: Wed, 11 Oct 2000 13:36:47 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2000 13:36:48.0151 (UTC) FILETIME=[4DE0A270:01C03388] Sender: owner-mpls@UU.NET Precedence: bulk Hello everybody We are currently looking for a complete implementation of OSPF ported to VxWorks.. I appreciate if anybody can provide me with a list of vendors providing this product. Thanks _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Wed Oct 11 10:47:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12064 for ; Wed, 11 Oct 2000 10:47:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkln07626; Wed, 11 Oct 2000 14:46:46 GMT Received: by mail-control.mail.uu.net id QQjkln24674 for mpls-outgoing; Wed, 11 Oct 2000 14:46:21 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQjkln24633 for ; Wed, 11 Oct 2000 14:46:15 GMT Received: from cmr2.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkln10473 for ; Wed, 11 Oct 2000 10:46:07 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjkln05359 for ; Wed, 11 Oct 2000 14:46:06 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA14342 for ; Wed, 11 Oct 2000 07:46:09 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA23007 for mpls@uu.net; Wed, 11 Oct 2000 10:46:04 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQjkjd07943 for ; Tue, 10 Oct 2000 23:29:31 GMT Received: from cmr0.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkjd23002 for ; Tue, 10 Oct 2000 19:29:18 -0400 (EDT) Received: from intersecttechnologies.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: server57.aitcom.net [208.234.0.13]) id QQjkjd26987 for ; Tue, 10 Oct 2000 23:29:18 GMT Received: from intersecttechnologies.com ([63.227.81.81]) by intersecttechnologies.com (8.8.8/8.8.5) with ESMTP id TAA28944; Tue, 10 Oct 2000 19:29:15 -0400 Message-ID: <39E3A612.FE411AF5@intersecttechnologies.com> Date: Tue, 10 Oct 2000 16:28:18 -0700 From: Xiaohui Zhang X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, xzhang@intersecttechnologies.com Subject: MPLS WG mailing list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: Kindly let me know where I can find the examples of MPLS LSP Setup or simulation besides the example in draft-ietf-mpls-lsr-mib-06. Thanks for the help. Xiaohui Zhang Intersect Technologies 2030 E Broadway Blvd. Tucson AZ 85719 voice: 520-670-9414 From owner-mpls@UU.NET Wed Oct 11 11:20:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12940 for ; Wed, 11 Oct 2000 11:20:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjklp19098; Wed, 11 Oct 2000 15:19:33 GMT Received: by mail-control.mail.uu.net id QQjklp08546 for mpls-outgoing; Wed, 11 Oct 2000 15:19:09 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQjklp08541 for ; Wed, 11 Oct 2000 15:19:02 GMT Received: from cmr1.ash.ops.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjklp15830 for ; Wed, 11 Oct 2000 11:18:45 -0400 (EDT) Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjklp17761 for ; Wed, 11 Oct 2000 15:18:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA21957 for mpls@uu.net; Wed, 11 Oct 2000 11:18:41 -0400 (EDT) Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQjklp08512 for ; Wed, 11 Oct 2000 15:17:58 GMT Received: from cmr0.ash.ops.us.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjklp14567 for ; Wed, 11 Oct 2000 11:17:08 -0400 (EDT) Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjklp09009 for ; Wed, 11 Oct 2000 15:17:08 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id <4W19MW5A>; Wed, 11 Oct 2000 16:17:06 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA45E@monk.datcon.co.uk> From: Adrian Farrel To: mpls@UU.NET Cc: egray@zaffire.com, philipma@nortelnetworks.com, Paul Brittain , rhthomas@cisco.com Subject: draft-ietf-mpls-ldp-ft-00.txt Date: Wed, 11 Oct 2000 16:17:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I have just sent a copy of this draft to the Internet-Drafts editor for publication. It is substantially unchanged from draft-brittain-mpls-ldp-ft-00.txt that was accepted as a Working Group draft in Pittsburgh. The only changes are corrections of minor typographical errors. If you are impatient for a copy, you can find it at http://www.dataconnection.com/download/draft-ietf-mpls-ldp-ft-00.txt We propose addressing the following list of issues in the next cycle. - Add brief section on TCP failure notification and detection. - Clarify that messages carrying the FT protection TLV do NOT themselves need to be secured, but that the state change must be secured to the backup before the Ack is sent. - Add a status code to indicate "Expected FT Protection TLV Absent". - Mention Address Message in introductory sections. - Consideration of failure to setup the TCP session the first time (minor editorial). - Section explaining which failure cases are permanent and which temporary. - Acknowledgement of Notify Label Resources Available. - Clarify sequence number wrapping. - Add example to show temporary shutdown As always, the comments of the group would be welcomed. Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Oct 11 15:57:25 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20179 for ; Wed, 11 Oct 2000 15:57:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkmh24827; Wed, 11 Oct 2000 19:56:53 GMT Received: by mail-control.mail.uu.net id QQjkmh19124 for mpls-outgoing; Wed, 11 Oct 2000 19:56:25 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkmh19117 for ; Wed, 11 Oct 2000 19:56:15 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkmh04244 for ; Wed, 11 Oct 2000 19:56:10 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkmh23393 for ; Wed, 11 Oct 2000 19:56:10 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA27059 for mpls@uu.net; Wed, 11 Oct 2000 15:56:09 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkmh19083 for ; Wed, 11 Oct 2000 19:55:48 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkmh02265 for ; Wed, 11 Oct 2000 19:55:20 GMT Received: from coltrane.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjkmh21807 for ; Wed, 11 Oct 2000 19:55:19 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id <4W19MX28>; Wed, 11 Oct 2000 20:55:18 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA47F@monk.datcon.co.uk> From: Adrian Farrel To: Olivier Dugeon , mpls@UU.NET Subject: RE: Comment on draft-ietf-mpls-crlsp-modify-02 Date: Wed, 11 Oct 2000 20:55:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Olivier, You make a good point, and ideally this is what would be done. We would need to define the procedure for propagating the second Label Request (this is quite easy to define), since the current LDP spec allows the second LSR to say "I have a label for that FEC" and simply return a Label Mapping. Note, however, that it will not always be possible to provide the increased bandwidth using the same label. In this case the existing modify function will be required. Further, I don't believe there is anything in the modify draft that prohibits the use of the same label on both the initial and the modified LSP. Regards, Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Olivier Dugeon [mailto:Olivier.Dugeon@rd.francetelecom.fr] >Sent: Wednesday, October 11, 2000 8:54 AM >To: mpls@UU.NET >Subject: Comment on draft-ietf-mpls-crlsp-modify-02 > > >Hi all, > >In section 4.1 : "Ri assigns a new label for the Label Request >Message." > >I think this is necessary only for re-routing i.e. ER-TLV changes. For >over traffic parameters modification, i think it's preferable to keep >the existing label. Because the route doesn't change, it's more simple >to keep the existing label (which reflect the path of the LSPID) than >change label. Then, you doesn't need to send a Label Release Message. >But, to ensure a three-way handshake of the protocol, it must >be safe to >send a Notification Message instead of a Release Message in >this context >to confirm the modification by ingress LSR. > >In this fashion, crlsp modification is much closer than it can be >possible with RM Cells (Ressource Management Cells) in ATM network. > >In section 9 : > >Why references of crldp and ldp are not up to date ? Where i can find >draft-ash-qos-routing-00.txt ? is the same as >draft-ash-te-qos-routing-01.txt ? > >Thanks, > >Olivier >-- > FTR&D/DAC/CPN > Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.fr > 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 > F-22307 LANNION | Fax: +(33) 2 96 05 18 52 > From owner-mpls@UU.NET Wed Oct 11 17:59:44 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22694 for ; Wed, 11 Oct 2000 17:59:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkmp17713; Wed, 11 Oct 2000 21:59:03 GMT Received: by mail-control.mail.uu.net id QQjkmp23892 for mpls-outgoing; Wed, 11 Oct 2000 21:58:21 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkmp23873 for ; Wed, 11 Oct 2000 21:58:14 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkmp28932 for ; Wed, 11 Oct 2000 21:56:37 GMT Received: from bgslc02.TBG.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQjkmp05750 for ; Wed, 11 Oct 2000 21:56:37 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id <43TAPTRG>; Wed, 11 Oct 2000 15:40:52 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE7EA9E47@BGSLC02> From: Irwin Lazar To: mpls@UU.NET, mpls-ops@mplsrc.com Subject: MPLScon 2001 - CFP Date: Wed, 11 Oct 2000 15:40:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C033CB.EC04F760" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C033CB.EC04F760 Content-Type: text/plain; charset="iso-8859-1" Just a quick reminder, presentation abstracts for MPLScon 2001, to be held March 26-29 in San Jose CA, are due by November 15, 2000. The call for presentations for this event is available at http://www.mplsrc.com/MPLSconCFP.pdf We are especially interested in receiving proposols on the following topics: MPL(ambda)S - protocols and methods, deployment examples, case studies on future service offerings MPLS Interoperability Testing - Field Reports MPLS Implementation case studies (covering traffic engineering, QoS, VPN, and network management) MPLS support for QoS Case studies on implementing MPLS in an ATM environment Please see the CFP for other topics. If you have any questions, please contact me at ilazar@tbg.com . Thanks, Irwin Irwin Lazar Conference Director, MPLScon 2001 March 26-29, Wyndham Hotel, San Jose, CA ilazar@tbg.com ------_=_NextPart_001_01C033CB.EC04F760 Content-Type: text/html; charset="iso-8859-1"
Just a quick reminder, presentation abstracts for MPLScon 2001, to be held March 26-29 in San Jose CA, are due by November 15, 2000.  The call for presentations for this event is available at http://www.mplsrc.com/MPLSconCFP.pdf
 
We are especially interested in receiving proposols on the following topics:
 
MPL(ambda)S - protocols and methods, deployment examples, case studies on future service offerings
MPLS Interoperability Testing - Field Reports
MPLS Implementation case studies (covering traffic engineering, QoS, VPN, and network management)
MPLS support for QoS
Case studies on implementing MPLS in an ATM environment
 
Please see the CFP for other topics.  If you have any questions, please contact me at ilazar@tbg.com.
 
Thanks,
Irwin
 
Irwin Lazar
Conference Director, MPLScon 2001
March 26-29, Wyndham Hotel, San Jose, CA
------_=_NextPart_001_01C033CB.EC04F760-- From owner-mpls@UU.NET Wed Oct 11 18:11:20 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22831 for ; Wed, 11 Oct 2000 18:11:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkmq29335; Wed, 11 Oct 2000 22:11:03 GMT Received: by mail-control.mail.uu.net id QQjkmq05992 for mpls-outgoing; Wed, 11 Oct 2000 22:10:41 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkmq05986 for ; Wed, 11 Oct 2000 22:10:37 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkmq24561 for ; Wed, 11 Oct 2000 22:10:31 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkmq28414 for ; Wed, 11 Oct 2000 22:10:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA15218 for mpls@uu.net; Wed, 11 Oct 2000 18:10:30 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkmq05953 for ; Wed, 11 Oct 2000 22:10:01 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkmq29944 for ; Wed, 11 Oct 2000 22:09:44 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkmq27137 for ; Wed, 11 Oct 2000 22:09:43 GMT Received: from lir.cisco.com (lir-hme0.cisco.com [171.69.204.20]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA15106; Wed, 11 Oct 2000 18:09:42 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id SAA16520; Wed, 11 Oct 2000 18:09:42 -0400 (EDT) Message-Id: <200010112209.SAA16520@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Bala Rajagopalan cc: John Drake , "'Debanjan Saha'" , George Swallow , mpls@UU.NET, swallow@cisco.com Subject: Re: Draft Minutes from Pittsburgh In-reply-to: Your message of "Thu, 05 Oct 2000 19:40:59 EDT." <39DD118B.3B3929F3@tellium.com> Date: Wed, 11 Oct 2000 18:09:42 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Bala - > It's hard to recall what exactly happened, My own recollection agrees exactly with what Francois captured in the minutes and John Drake stated on the list. So consensus was reached. > but we do believe > that this topic deserves further discussion. Especially since > previously unstated support for OSPF flooding optimization > are now part of the overall picture of bundling proposed > by draft-kompella. I hope we can do this in the upcoming > meeting. We're always open to further discussion. I would suggest that you not wait until December for it. The list is a fine place for such a discussion. In the mean time we also need to make progress. So the consensus we reached is the consensus. It can be revisited of course. But as far as progessing drafts, I'm expecting the authors of the kompella draft to issue a draft with just the signalling aspects as a WG draft or drafts depending on whether they decide to have a single document or one for each of RSVP and LDP. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Oct 11 22:49:35 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28560 for ; Wed, 11 Oct 2000 22:49:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjknj26888; Thu, 12 Oct 2000 02:49:14 GMT Received: by mail-control.mail.uu.net id QQjknj08927 for mpls-outgoing; Thu, 12 Oct 2000 02:48:49 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjknj08922 for ; Thu, 12 Oct 2000 02:48:42 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjknj08825 for ; Thu, 12 Oct 2000 02:48:30 GMT Received: from jumpstart.maplenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.111.208.202]) id QQjknj24489 for ; Thu, 12 Oct 2000 02:48:30 GMT Received: from sjainlt (dhcp-129 [192.168.10.129]) by jumpstart.maplenetworks.com (8.11.0/8.11.0) with SMTP id e9C2lvo13333; Wed, 11 Oct 2000 19:47:57 -0700 (PDT) Message-ID: <018b01c033f6$fa29f900$810aa8c0@maplenetworks.com> From: "Sudhanshu Jain" To: , "Yakov Rekhter" , , , Cc: Subject: Query on draft-ietf-mpls-label-encaps Date: Wed, 11 Oct 2000 19:49:00 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0188_01C033BC.4D01B680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0188_01C033BC.4D01B680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, In draft-ietf-mpls-label-encaps-08.txt, in section 2.1 language has = been changed to .... i. A value of 0 represents the "IPv4 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header. From draft-ietf-mpls-label-encaps-07.txt, in section 2.1 .... i. A value of 0 represents the "IPv4 Explicit NULL Label". This label value is only legal when it is the sole label stack entry. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header. =20 Same stands for the bullet (iii). Does it mean, Label 0 and Label 2 are used to carry Protocol type=20 at the "bottom of the label stack" in case of tunnel traffic?=20 Is it the standard way to carry the protocol type in MPLS Tunnel = traffic? Thanks, -Sudhanshu ------=_NextPart_000_0188_01C033BC.4D01B680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
   In=20 draft-ietf-mpls-label-encaps-08.txt, in section 2.1 language has=20 been
   changed to=20 ....

          &= nbsp;  =20 i. A value of 0 represents the "IPv4 Explicit NULL=20 Label".
          &n= bsp;     =20 This label value is only legal at the bottom of=20 the
           =      =20 label stack.  It indicates that the label stack must=20 be
           &= nbsp;    =20 popped, and the forwarding of the packet must then=20 be
           &= nbsp;    =20 based on the IPv4 header.


   From=20 draft-ietf-mpls-label-encaps-07.txt, in section 2.1=20 ....

          &= nbsp;  =20 i. A value of 0 represents the "IPv4 Explicit NULL=20 Label".
          &n= bsp;     =20 This label value is only legal when it is the=20 sole
           = ;     =20 label stack entry.  It indicates that the label=20 stack
          &nbs= p;     =20 must be popped, and the forwarding of the packet=20 must
           = ;     =20 then be based on the IPv4 header.

 
  Same stands = for the=20 bullet (iii).

  Does it mean, Label 0 and Label 2 are used = to carry=20 Protocol type
  at the "bottom of the label stack" in case of = tunnel=20 traffic?

  Is it the standard way to carry the protocol = type in=20 MPLS Tunnel traffic?
Thanks,
-Sudhanshu

 
------=_NextPart_000_0188_01C033BC.4D01B680-- From owner-mpls@UU.NET Wed Oct 11 23:57:04 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29448 for ; Wed, 11 Oct 2000 23:57:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjknn25565; Thu, 12 Oct 2000 03:56:42 GMT Received: by mail-control.mail.uu.net id QQjknn24118 for mpls-outgoing; Thu, 12 Oct 2000 03:56:10 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjknn24103 for ; Thu, 12 Oct 2000 03:56:07 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjknn14328 for ; Thu, 12 Oct 2000 03:55:20 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjknn25017 for ; Thu, 12 Oct 2000 03:55:19 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id XAA09085; Wed, 11 Oct 2000 23:54:46 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200010120354.XAA09085@workhorse.fictitious.org> To: "Sudhanshu Jain" cc: erosen@cisco.com, "Yakov Rekhter" , dtappen@cisco.com, tli@procket.com, dino@procket.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Query on draft-ietf-mpls-label-encaps In-reply-to: Your message of "Wed, 11 Oct 2000 19:49:00 PDT." <018b01c033f6$fa29f900$810aa8c0@maplenetworks.com> Date: Wed, 11 Oct 2000 23:54:46 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <018b01c033f6$fa29f900$810aa8c0@maplenetworks.com>, "Sudhanshu Jain" writes: > This is a multi-part message in MIME format. > > ------=_NextPart_000_0188_01C033BC.4D01B680 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi All, > In draft-ietf-mpls-label-encaps-08.txt, in section 2.1 language has = > been > changed to .... > > i. A value of 0 represents the "IPv4 Explicit NULL Label". > This label value is only legal at the bottom of the > label stack. It indicates that the label stack must be > popped, and the forwarding of the packet must then be > based on the IPv4 header. > > > From draft-ietf-mpls-label-encaps-07.txt, in section 2.1 .... > > i. A value of 0 represents the "IPv4 Explicit NULL Label". > This label value is only legal when it is the sole > label stack entry. It indicates that the label stack > must be popped, and the forwarding of the packet must > then be based on the IPv4 header. > > =20 > Same stands for the bullet (iii). > > Does it mean, Label 0 and Label 2 are used to carry Protocol type=20 > at the "bottom of the label stack" in case of tunnel traffic?=20 > > Is it the standard way to carry the protocol type in MPLS Tunnel = > traffic? > > Thanks, > -Sudhanshu Sudhanshu, The last phrase in this paragraph should be reworded to say that it will be forwarded based on the protocol type specified in the L3PID when the tunnel was set, for example IPv4 or IPv6. Note to authors: Remove the last the words, "on the IPv4 header" and replace with "on the underlying payload's header". You could also add a sentence "The protocol type of the underlying header is determined by signaling that occurs at LSP setup time". The use of L3PID to determine payload protocol identifier is definitely a good candidate for an FAQ. The signaling of L3PID is specified in section 4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-07.txt. Curtis From owner-mpls@UU.NET Thu Oct 12 04:43:36 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14079 for ; Thu, 12 Oct 2000 04:43:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkog10325; Thu, 12 Oct 2000 08:42:54 GMT Received: by mail-control.mail.uu.net id QQjkog07239 for mpls-outgoing; Thu, 12 Oct 2000 08:42:35 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkog07234 for ; Thu, 12 Oct 2000 08:42:25 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkog22370 for ; Thu, 12 Oct 2000 08:41:40 GMT Received: from gateway.ntu.edu.sg by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gateway.ntu.edu.sg [155.69.1.127]) id QQjkog06809 for ; Thu, 12 Oct 2000 08:41:26 GMT Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id <4Q6VFHQ4>; Thu, 12 Oct 2000 16:40:53 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE035AFE5D@exchange4.ntu.edu.sg> From: Shen Gangxiang To: Adrian Farrel Cc: mpls@UU.NET Subject: Some comments on draft-ietf-mpls-ldp-ft-00.txt Date: Thu, 12 Oct 2000 16:40:44 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Adrian, Thanks for your draft! I have some doubts on this draft: 1. Draft uses FT Protection TLV to secure the FT message. However, in LDP specification, there is a field Message ID in each LDP message. It seems that there is some redundancy on this ID inforamtion. I guess it is possible to dirctly use the Message ID field to secure those FT messages. 2. After sender sends an FT message, it will receive an ACk message from the reciever as a confirmation. Following this rule, we may further consider some special situations: (a) TCP connection between LSRs is working properly, but some FT messages can't be confirmed because their receiver can't send back the corresponding ACK messages due to some other reasons rather than TCP disconnection. (For example, in CR-LDP, peer A sends a Label Request message L1 to peer B, but peer B can't ACK it because peer B's downstream can't provide Label Mapping message due to something wrong) (b)In a Label Request message with FT sequence number S, there could be more than one FECs, e.g. {FEC1, FEC2,...,FECn}. For these FECs, the mapping labels may arrive at the node at the different time, and some labels may even not be able to arrive due to the reasons like in (a). So how should we deal with such a kind of situation? How will we send the ACK sequence number? Many thanks for any comment! Gangxiang From owner-mpls@UU.NET Thu Oct 12 05:03:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14188 for ; Thu, 12 Oct 2000 05:03:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkoi07653; Thu, 12 Oct 2000 09:03:26 GMT Received: by mail-control.mail.uu.net id QQjkoi18990 for mpls-outgoing; Thu, 12 Oct 2000 09:02:55 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkoi17151 for ; Thu, 12 Oct 2000 09:02:40 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkoi10531 for ; Thu, 12 Oct 2000 09:02:06 GMT Received: from exchange.satyam.net.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.144.12.32]) id QQjkoi01003 for ; Thu, 12 Oct 2000 09:02:03 GMT Received: from hqbng01ex01.mindtree.com ([202.144.95.250]) by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id OAA05473 for ; Thu, 12 Oct 2000 14:29:44 +0530 Received: by hqbng01ex01.mindtree.com with Internet Mail Service (5.5.2650.21) id <4J5597ZX>; Thu, 12 Oct 2000 14:31:43 +0530 Message-ID: From: Suvarna Singh To: mpls@UU.NET Subject: Query on draft-ietf-mpls-ldp-state-03.txt Date: Thu, 12 Oct 2000 14:31:42 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0342B.0AAC2C37" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0342B.0AAC2C37 Content-Type: text/plain; charset="iso-8859-1" Hi all, In draft-ietf-mpls-ldp-state-03.txt under section 3.1.5.2, under State: RESPONSE_AWAITED Event: LDP Mapping New State: ESTABLISHED Actions: 1) If the LSP is triggered by the local router (Trigger Control Block Pointer is not zero), send event 'Internal LSP UP' to the Trigger control block Could anyone please explain what this action exactly means.... thanks in advance, suvarna Suvarna Singh Software Engineer Mindtree House, #88, Gandhi Bazaar Main Road Basavangudi Bangalore-560004 Tel : 6528333-1028 ------_=_NextPart_001_01C0342B.0AAC2C37 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Query on draft-ietf-mpls-ldp-state-03.txt

Hi all,
         In = draft-ietf-mpls-ldp-state-03.txt under section 3.1.5.2, under

State:  RESPONSE_AWAITED

Event:  LDP Mapping

New = State:      ESTABLISHED

Actions:

1) If the LSP is triggered by the = local router (Trigger Control Block Pointer is not zero), send event = 'Internal LSP UP'  to the Trigger control block

Could anyone please explain what this = action exactly means....

thanks in advance,
suvarna

Suvarna = Singh
Software = Engineer
Mindtree House, = #88,
Gandhi Bazaar Main = Road
Basavangudi
Bangalore-560004
Tel : = 6528333-1028

------_=_NextPart_001_01C0342B.0AAC2C37-- From owner-mpls@UU.NET Thu Oct 12 05:35:01 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15409 for ; Thu, 12 Oct 2000 05:35:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkok26625; Thu, 12 Oct 2000 09:34:47 GMT Received: by mail-control.mail.uu.net id QQjkok21653 for mpls-outgoing; Thu, 12 Oct 2000 09:34:28 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkok21648 for ; Thu, 12 Oct 2000 09:34:19 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkok24014 for ; Thu, 12 Oct 2000 09:32:51 GMT Received: from mailhost.iitb.ac.in by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQjkok10539 for ; Thu, 12 Oct 2000 09:32:45 GMT Received: (qmail 25159 invoked from network); 12 Oct 2000 09:36:07 -0000 Received: from bhairav.ee.iitb.ernet.in (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 12 Oct 2000 09:36:07 -0000 Received: from localhost (gabhijit@localhost) by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id PAA16449 for ; Thu, 12 Oct 2000 15:00:25 +0530 (IST) Date: Thu, 12 Oct 2000 15:00:25 +0530 (IST) From: Abhijit To: mpls@UU.NET Subject: Wildcard Fec question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk In the LDP draft, for the encoding of wildcard Fec, The value specified is No value; i.e. 0 value octates. Does this mean 1. There should not be anything apart from fecType or 2. Values of all other things like address family etc. be '0'. This is not quite clear. Can anyone throw some light on it? -abhijit From owner-mpls@UU.NET Thu Oct 12 07:13:40 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20122 for ; Thu, 12 Oct 2000 07:13:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkoq25825; Thu, 12 Oct 2000 11:12:39 GMT Received: by mail-control.mail.uu.net id QQjkoq20229 for mpls-outgoing; Thu, 12 Oct 2000 11:12:16 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkoq20224 for ; Thu, 12 Oct 2000 11:12:11 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkoq11974 for ; Thu, 12 Oct 2000 11:12:00 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkoq28229 for ; Thu, 12 Oct 2000 11:11:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA00527 for mpls@uu.net; Thu, 12 Oct 2000 07:11:59 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkoq20199 for ; Thu, 12 Oct 2000 11:11:42 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkoq14495 for ; Thu, 12 Oct 2000 11:11:11 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjkoq26594 for ; Thu, 12 Oct 2000 11:11:10 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id EAA16602; Thu, 12 Oct 2000 04:11:09 -0700 (PDT) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id HAA05016; Thu, 12 Oct 2000 07:11:08 -0400 (EDT) Message-Id: <200010121111.HAA05016@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: Abhijit cc: mpls@UU.NET Subject: Re: Wildcard Fec question In-reply-to: Your message of "Thu, 12 Oct 2000 15:00:25 +0530." Date: Thu, 12 Oct 2000 07:11:08 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Abhijit > In the LDP draft, for the encoding of wildcard Fec, The value specified is > No value; i.e. 0 value octates. > > Does this mean > > 1. There should not be anything apart from fecType or > 2. Values of all other things like address family etc. be '0'. The text: FEC Element Type Value type name Wildcard 0x01 No value; i.e., 0 value octets; means that the Wildcard FEC Element is encoded as a single octet with value is 0x01. Bob > This is not quite clear. Can anyone throw some light on it? From owner-mpls@UU.NET Thu Oct 12 08:08:23 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22464 for ; Thu, 12 Oct 2000 08:08:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkou08675; Thu, 12 Oct 2000 12:07:45 GMT Received: by mail-control.mail.uu.net id QQjkou04680 for mpls-outgoing; Thu, 12 Oct 2000 12:07:11 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkou04653 for ; Thu, 12 Oct 2000 12:06:57 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkou21353 for ; Thu, 12 Oct 2000 12:06:55 GMT Received: from cad.zju.edu.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [210.32.131.2]) id QQjkou23865 for ; Thu, 12 Oct 2000 12:06:52 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 310; Thu, 12 Oct 2000 20:06:41 +0800 Message-ID: <39E5A946.9B40DFAB@cad.zju.edu.cn> Date: Thu, 12 Oct 2000 20:06:30 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ge ge CC: mpls@UU.NET Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I'm trying to integrate IP MPLS over ATM , and find it's very interesting to directly use ATM as find way to transfer payload. But still not clear on how they can be integrated without routing decision at LER . James Shen > Hi, > > I am looking for documents on interworking between ATM and MPLS networks, > especially, documents on interworking without IP lookup at an > ingress LSR. Thanks. > > Hao Che > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. From owner-mpls@UU.NET Thu Oct 12 10:13:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26374 for ; Thu, 12 Oct 2000 10:13:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkpc19202; Thu, 12 Oct 2000 14:12:45 GMT Received: by mail-control.mail.uu.net id QQjkpc07740 for mpls-outgoing; Thu, 12 Oct 2000 14:12:17 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkpc07729 for ; Thu, 12 Oct 2000 14:12:11 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkpc14765 for ; Thu, 12 Oct 2000 14:10:50 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjkpc16481 for ; Thu, 12 Oct 2000 14:10:50 GMT Received: from tellium.com ([192.168.24.225]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9CE3HL10229; Thu, 12 Oct 2000 10:03:17 -0400 (EDT) Message-ID: <39E5C659.FFDE20C0@tellium.com> Date: Thu, 12 Oct 2000 10:10:33 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: John Drake , "'Debanjan Saha'" , mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: <200010112209.SAA16520@lir.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, George Swallow wrote: > > but we do believe > > that this topic deserves further discussion. Especially since > > previously unstated support for OSPF flooding optimization > > are now part of the overall picture of bundling proposed > > by draft-kompella. I hope we can do this in the upcoming > > meeting. > > We're always open to further discussion. I would suggest that you not > wait until December for it. The list is a fine place for such a > discussion. I agree. > > > In the mean time we also need to make progress. So the consensus we > reached is the consensus. It can be revisited of course. But as far > as progessing drafts, I'm expecting the authors of the kompella draft > to issue a draft with just the signalling aspects as a WG draft or > drafts depending on whether they decide to have a single document or > one for each of RSVP and LDP. This statement is contradictory. If we're going to revisit, why issue a working group draft before finishing the discussion? W.r.t consensus, I don't believe enough information was available at the last meeting to make a decision on proceeding with the Kompella draft as a WG draft, specifically, the need for flooding optitimization with the propsoed bundling approach. I don't mind if a decision on this is made after another round of discussions on the mailing list prior to the next meeting. Regards, Bala > > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Oct 12 15:33:20 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04662 for ; Thu, 12 Oct 2000 15:33:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkpp22869; Thu, 12 Oct 2000 17:20:14 GMT Received: by mail-control.mail.uu.net id QQjkpp03203 for mpls-outgoing; Thu, 12 Oct 2000 17:19:55 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkpp03198 for ; Thu, 12 Oct 2000 17:19:50 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkpp15145 for ; Thu, 12 Oct 2000 17:18:23 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkpp18379 for ; Thu, 12 Oct 2000 17:18:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA10531 for mpls@uu.net; Thu, 12 Oct 2000 13:18:22 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkpp03097 for ; Thu, 12 Oct 2000 17:18:03 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkpp05595 for ; Thu, 12 Oct 2000 17:15:34 GMT Received: from coltrane.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjkpp13490 for ; Thu, 12 Oct 2000 17:15:33 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id <4W19MZD2>; Thu, 12 Oct 2000 18:15:28 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA4CF@monk.datcon.co.uk> From: Adrian Farrel To: Shen Gangxiang Cc: mpls@UU.NET Subject: RE: Some comments on draft-ietf-mpls-ldp-ft-00.txt Date: Thu, 12 Oct 2000 18:15:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Gangxiang, Thanks for your interest in this draft. >Thanks for your draft! I have some doubts on this draft: > >1. Draft uses FT Protection TLV to secure the FT message. >However, in LDP specification, there is a field Message ID >in each LDP message. It seems that there is some redundancy >on this ID inforamtion. I guess it is possible to dirctly >use the Message ID field to secure those FT messages. For LDP FT we require ... An LDP peer maintains a separate FT sequence number for each LDP session it participates in. The FT Sequence number is incremented by one for each FT LDP message (i.e. containing the FT Protection TLV) issued by this LSR on the FT LDP session with which the FT sequence number is associated. That is, the FT sequence number has meaning at both ends of the session. Message ID in LDP has no such limitations ... Message ID 32-bit value used to identify this message. Used by the sending LSR to facilitate identifying notification messages that may apply to this message. An LSR sending a notification message in response to this message should include this Message Id in the Status TLV carried by the notification message; see Section "Notification Message". Thus Message ID is not suitable. >2. After sender sends an FT message, it will receive an ACk >message from the reciever as a confirmation. Following this >rule, we may further consider some special situations: >(a) TCP connection between LSRs is working properly, but some >FT messages can't be confirmed because their receiver can't send >back the corresponding ACK messages due to some other reasons >rather than TCP disconnection. >(For example, in CR-LDP, peer A sends a Label Request message >L1 to peer B, but peer B can't ACK it because peer B's >downstream can't provide Label Mapping message due to something >wrong) Ack'ing a message does NOT imply that it has been processed with allocation of labels etc. That is what Label Mapping is for. The Ack simply confirms that the message has been received and secured in such a way that its effect can be recreated on recovery. This might involve storing the message in flash or it might involve processing the message to completion and replicating the control blocks (or anything else you care to name - it is an implementation choice). >(b)In a Label Request message with FT sequence number S, there >could be more than one FECs, e.g. {FEC1, FEC2,...,FECn}. For >these FECs, the mapping labels may arrive at the node at the >different time, and some labels may even not be able to arrive >due to the reasons like in (a). So how should we deal with such >a kind of situation? How will we send the ACK sequence number? As above. You Ack the message not the FEC. Ack the Label Request when you receive it. Later when you have sent the Label Request onwards, you receive Label Mappings and process them as normal. We are not changing the basic protocol in anyway, simply adding a handshake. Regards, Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Fri Oct 13 10:47:10 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06869 for ; Fri, 13 Oct 2000 10:47:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjksx18176; Fri, 13 Oct 2000 14:46:40 GMT Received: by mail-control.mail.uu.net id QQjksx27004 for mpls-outgoing; Fri, 13 Oct 2000 14:46:05 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjksx26964 for ; Fri, 13 Oct 2000 14:46:00 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkrt27832 for ; Fri, 13 Oct 2000 07:22:10 GMT Received: from cad.zju.edu.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [210.32.131.2]) id QQjkrt01619 for ; Fri, 13 Oct 2000 07:22:03 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 326 for ; Fri, 13 Oct 2000 15:21:54 +0800 Message-ID: <39E6B807.FFB847F@cad.zju.edu.cn> Date: Fri, 13 Oct 2000 15:21:43 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: MPLS over ATM Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I'm trying to integrate IP over ATM using MPLS. But I'm not sure the routing procedure in such a environment. Is that the only items to choose between MPOA and standard IP over ATM? If it is, where can I find some document on building up a QoS channel over ATM according MPLS's description? Thanks. James Shen email: jshen@cad.zju.edu.cn ******************************************************************** * * * The sunshine of life is made up of very little beams that is bright all the time . * * * ******************************************************************** From owner-mpls@UU.NET Fri Oct 13 10:47:27 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06889 for ; Fri, 13 Oct 2000 10:47:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjksx07338; Fri, 13 Oct 2000 14:46:51 GMT Received: by mail-control.mail.uu.net id QQjksx27005 for mpls-outgoing; Fri, 13 Oct 2000 14:46:06 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjksx26943 for ; Fri, 13 Oct 2000 14:45:45 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkra14310 for ; Fri, 13 Oct 2000 02:35:29 GMT Received: from jumpstart.maplenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.111.208.202]) id QQjkpq15027 for ; Thu, 12 Oct 2000 17:42:30 GMT Received: from sjainlt (dhcp-129 [192.168.10.129]) by jumpstart.maplenetworks.com (8.11.0/8.11.0) with SMTP id e9CHffo24670; Thu, 12 Oct 2000 10:41:41 -0700 (PDT) Message-ID: <01ea01c03473$d462c4e0$810aa8c0@maplenetworks.com> From: "Sudhanshu Jain" To: Cc: , "Yakov Rekhter" , , , , , References: <200010120354.XAA09085@workhorse.fictitious.org> Subject: Re: Query on draft-ietf-mpls-label-encaps Date: Thu, 12 Oct 2000 10:42:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Curtis, Thanks for the response. L3PID is the what used in setting up tunnel which are protocol aware. But if a tunnel is being setup as a fat pipe, ( e.g. L3PID is not present at setup time). Is it possible for such a tunnel to carry multiprotocols via using 0 or 2 label at the bottom of the stack? Is there any existing implementation which carry multi protocol over single tunnel? If so, how do they carry protocol information end-to-end? Thanks, -Sudhanshu ----- Original Message ----- From: Curtis Villamizar To: Sudhanshu Jain Cc: ; Yakov Rekhter ; ; ; ; Sent: Wednesday, October 11, 2000 8:54 PM Subject: Re: Query on draft-ietf-mpls-label-encaps > > In message <018b01c033f6$fa29f900$810aa8c0@maplenetworks.com>, "Sudhanshu Jain" > writes: > > This is a multi-part message in MIME format. > > > > ------=_NextPart_000_0188_01C033BC.4D01B680 > > Content-Type: text/plain; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > Hi All, > > In draft-ietf-mpls-label-encaps-08.txt, in section 2.1 language has = > > been > > changed to .... > > > > i. A value of 0 represents the "IPv4 Explicit NULL Label". > > This label value is only legal at the bottom of the > > label stack. It indicates that the label stack must be > > popped, and the forwarding of the packet must then be > > based on the IPv4 header. > > > > > > From draft-ietf-mpls-label-encaps-07.txt, in section 2.1 .... > > > > i. A value of 0 represents the "IPv4 Explicit NULL Label". > > This label value is only legal when it is the sole > > label stack entry. It indicates that the label stack > > must be popped, and the forwarding of the packet must > > then be based on the IPv4 header. > > > > =20 > > Same stands for the bullet (iii). > > > > Does it mean, Label 0 and Label 2 are used to carry Protocol type=20 > > at the "bottom of the label stack" in case of tunnel traffic?=20 > > > > Is it the standard way to carry the protocol type in MPLS Tunnel = > > traffic? > > > > Thanks, > > -Sudhanshu > > > Sudhanshu, > > The last phrase in this paragraph should be reworded to say that it > will be forwarded based on the protocol type specified in the L3PID > when the tunnel was set, for example IPv4 or IPv6. > > Note to authors: > > Remove the last the words, "on the IPv4 header" and replace with "on > the underlying payload's header". You could also add a sentence > "The protocol type of the underlying header is determined by > signaling that occurs at LSP setup time". > > The use of L3PID to determine payload protocol identifier is > definitely a good candidate for an FAQ. The signaling of L3PID is > specified in section 4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-07.txt. > > Curtis > From owner-mpls@UU.NET Fri Oct 13 10:48:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06924 for ; Fri, 13 Oct 2000 10:48:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjksx23274; Fri, 13 Oct 2000 14:48:27 GMT Received: by mail-control.mail.uu.net id QQjksx27159 for mpls-outgoing; Fri, 13 Oct 2000 14:47:39 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjksx27052 for ; Fri, 13 Oct 2000 14:46:39 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkqb22758 for ; Thu, 12 Oct 2000 20:25:41 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjkqb04707 for ; Thu, 12 Oct 2000 20:25:40 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA22183 for ; Thu, 12 Oct 2000 13:25:39 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA03622 for mpls@uu.net; Thu, 12 Oct 2000 16:25:38 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkmy05691 for ; Thu, 12 Oct 2000 00:03:02 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkmy25918 for ; Thu, 12 Oct 2000 00:02:42 GMT Received: from kosh.narus.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kosh.narus.com [64.240.193.204]) id QQjkmy24822 for ; Thu, 12 Oct 2000 00:02:42 GMT Received: from hermes.narus.com (narus.com [192.168.1.222]) by kosh.narus.com (8.9.3/8.9.3) with ESMTP id QAA04337; Wed, 11 Oct 2000 16:14:46 -0700 Received: by hermes.narus.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 17:02:42 -0700 Message-ID: From: Samantha Quadros To: "'mpls@uu.net'" Cc: "'mpls-ops@mplsrc.com'" Subject: Packet types Date: Wed, 11 Oct 2000 17:02:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi all I was just wondering if there are certain kinds of packets in which you can't insert MPLS lables. I know traditionally you can insert labels in IP packets but what about 802.3 packets and ARP packets. Samantha From owner-mpls@UU.NET Fri Oct 13 10:49:07 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06954 for ; Fri, 13 Oct 2000 10:49:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjksx11149; Fri, 13 Oct 2000 14:48:40 GMT Received: by mail-control.mail.uu.net id QQjksx27201 for mpls-outgoing; Fri, 13 Oct 2000 14:48:05 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjksx27188 for ; Fri, 13 Oct 2000 14:47:55 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkqc25849 for ; Thu, 12 Oct 2000 20:39:01 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjkqc25556 for ; Thu, 12 Oct 2000 20:39:00 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA23908; Thu, 12 Oct 2000 13:39:02 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA03676; Thu, 12 Oct 2000 16:38:58 -0400 (EDT) Message-Id: <200010122038.QAA03676@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: "Sudhanshu Jain" cc: "Yakov Rekhter" , dtappen@cisco.com, tli@procket.com, dino@procket.com, mpls@UU.NET Subject: Re: Query on draft-ietf-mpls-label-encaps In-reply-to: Your message of Wed, 11 Oct 2000 19:49:00 -0700. <018b01c033f6$fa29f900$810aa8c0@maplenetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 12 Oct 2000 16:38:58 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk > Does it mean, Label 0 and Label 2 are used to carry Protocol type at the > "bottom of the label stack" in case of tunnel traffic? No, the cited paragraph means neither more nor less than it says. There is no requirement that the bottom of the stack ever have an explicit null. It would not be legitimate to write code which presumes that it does. > Is it the standard way to carry the protocol type in MPLS Tunnel traffic? No. From owner-mpls@UU.NET Fri Oct 13 10:52:51 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07046 for ; Fri, 13 Oct 2000 10:52:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjksx25703; Fri, 13 Oct 2000 14:49:23 GMT Received: by mail-control.mail.uu.net id QQjksx27186 for mpls-outgoing; Fri, 13 Oct 2000 14:47:54 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjksx27114 for ; Fri, 13 Oct 2000 14:47:31 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkqm20132 for ; Thu, 12 Oct 2000 23:09:02 GMT Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQjkqm13922 for ; Thu, 12 Oct 2000 23:09:01 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <4NGKW5MM>; Thu, 12 Oct 2000 16:09:35 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6625D8AE1@ICARIAN> From: Eric Gray To: "'Suvarna Singh'" Cc: mpls@UU.NET Subject: RE: Query on draft-ietf-mpls-ldp-state-03.txt Date: Thu, 12 Oct 2000 16:09:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C034A1.7C448C20" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C034A1.7C448C20 Content-Type: text/plain; charset="iso-8859-1" Suvarna, There are basically two things that would cause an LSR to send a Label Request message: either a new label is required to satisfy a Label Request it has itself received from another LSR peer or a new label is required based on some form of "internal" determination. An example of an "internal" determination is if the LSR is the ingress to an LSP that will be established for Traffic Engineering. The two causes have in common that some event provoked a need for a new label and closure requires a response to that event. If a label was requested to satisfy a Label Request from another LSR peer (or peers), then the response is to return a Label Mapping to that (or those) peer(s). If the Label Request was intended to satisfy some "internal" need, then the source of the triggering event needs to be notified. Note that the term "internal" is relative to the LSR's state machine as specified. The actual event that occurred internally may have itself been provoked by an external stimuli (example: NMS activity). Another way to look at it is that the "trigger control block pointer" may - in some implementations - be a simple pointer to a specific call-back function that was registered at the time that the LSP setup was initiated. This makes the description general enough that it could apply to almost any cause of LSP setup - including downstream LSP setup in response to an upstream request. What sorts of "internal" triggers might apply within an implementation is entirely an implementation issue and outside of the scope of the draft. Hopefully, one of these explanations was helpful. -- Eric Gray -----Original Message----- From: Suvarna Singh [mailto:suvarna_singh@mindtree.com] Sent: Thursday, October 12, 2000 2:02 AM To: mpls@UU.NET Subject: Query on draft-ietf-mpls-ldp-state-03.txt Hi all, In draft-ietf-mpls-ldp-state-03.txt under section 3.1.5.2, under State: RESPONSE_AWAITED Event: LDP Mapping New State: ESTABLISHED Actions: 1) If the LSP is triggered by the local router (Trigger Control Block Pointer is not zero), send event 'Internal LSP UP' to the Trigger control block Could anyone please explain what this action exactly means.... thanks in advance, suvarna Suvarna Singh Software Engineer Mindtree House, #88, Gandhi Bazaar Main Road Basavangudi Bangalore-560004 Tel : 6528333-1028 ------_=_NextPart_001_01C034A1.7C448C20 Content-Type: text/html; charset="iso-8859-1" Query on draft-ietf-mpls-ldp-state-03.txt
Suvarna,
 
    There are basically two things that would cause an LSR
to send a Label Request message: either a new label is
required to satisfy a Label Request it has itself received
from another LSR peer or a new label is required based on
some form of "internal" determination.  An example of an
"internal" determination is if the LSR is the ingress to an
LSP that will be established for Traffic Engineering.  The
two causes have in common that some event provoked a
need for a new label and closure requires a response to that
event.
 
    If a label was requested to satisfy a Label Request from
another LSR peer (or peers), then the response is to return a
Label Mapping to that (or those) peer(s).  If the Label Request
was intended to satisfy some "internal" need, then the source
of the triggering event needs to be notified.
 
    Note that the term "internal" is relative to the LSR's state
machine as specified.  The actual event that occurred internally
may have itself been provoked by an external stimuli (example:
NMS activity).
 
    Another way to look at it is that the "trigger control block
pointer" may - in some implementations - be a simple pointer
to a specific call-back function that was registered at the time
that the LSP setup was initiated.  This makes the description
general enough that it could apply to almost any cause of LSP
setup - including downstream LSP setup in response to an
upstream request.  What sorts of "internal" triggers might apply
within an implementation is entirely an implementation issue
and outside of the scope of the draft.
 
    Hopefully, one of these explanations was helpful.
 
--
Eric Gray
-----Original Message-----
From: Suvarna Singh [mailto:suvarna_singh@mindtree.com]
Sent: Thursday, October 12, 2000 2:02 AM
To: mpls@UU.NET
Subject: Query on draft-ietf-mpls-ldp-state-03.txt

Hi all,
         In draft-ietf-mpls-ldp-state-03.txt under section 3.1.5.2, under

State:  RESPONSE_AWAITED

Event:  LDP Mapping

New State:      ESTABLISHED

Actions:

1) If the LSP is triggered by the local router (Trigger Control Block Pointer is not zero), send event 'Internal LSP UP'  to the Trigger control block

Could anyone please explain what this action exactly means....

thanks in advance,
suvarna

Suvarna Singh
Software Engineer
Mindtree House, #88,
Gandhi Bazaar Main Road
Basavangudi
Bangalore-560004
Tel : 6528333-1028

------_=_NextPart_001_01C034A1.7C448C20-- From owner-mpls@UU.NET Fri Oct 13 10:56:41 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07126 for ; Fri, 13 Oct 2000 10:56:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjksx02832; Fri, 13 Oct 2000 14:48:40 GMT Received: by mail-control.mail.uu.net id QQjksx27166 for mpls-outgoing; Fri, 13 Oct 2000 14:47:43 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjksx27053 for ; Fri, 13 Oct 2000 14:46:39 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkqb24199 for ; Thu, 12 Oct 2000 20:26:11 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjkqb05627 for ; Thu, 12 Oct 2000 20:26:07 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA22590 for ; Thu, 12 Oct 2000 13:26:07 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA03626 for mpls@uu.net; Thu, 12 Oct 2000 16:26:05 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjknc21792 for ; Thu, 12 Oct 2000 01:13:04 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjknc02062 for ; Thu, 12 Oct 2000 01:12:58 GMT Received: from force10networks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQjknc02050 for ; Thu, 12 Oct 2000 01:12:58 GMT Received: from pc2101 by force10networks.com (8.8.8+Sun/ncore-main9-99) id SAA05704; Wed, 11 Oct 2000 18:12:54 -0700 (PDT) From: "Rajeev Manur" To: "'Samantha Quadros'" , Cc: Subject: RE: Packet types Date: Wed, 11 Oct 2000 18:12:52 -0700 Message-ID: <06f85737f674f4e395e3013470ec1df239e51049@force10networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <"l221QD.A.XpG.q-P55"@host.secure4-hosting.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS standard does'nt restrict you in this regard. Basically you can label any packet as long as the egress LSR knows how to interpret/forward the payload after poping the MPLS label. Unless otherwise specified via signalling or configuration, egress LSR tries to interpret the payload as IP packet. with regards, Rajeev -----Original Message----- From: Samantha Quadros [mailto:SQuadros@narus.com] Sent: Wednesday, October 11, 2000 5:03 PM To: 'mpls@uu.net' Cc: 'mpls-ops@mplsrc.com' Subject: Packet types Hi all I was just wondering if there are certain kinds of packets in which you can't insert MPLS lables. I know traditionally you can insert labels in IP packets but what about 802.3 packets and ARP packets. Samantha ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Fri Oct 13 11:16:19 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07467 for ; Fri, 13 Oct 2000 11:16:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjksz20353; Fri, 13 Oct 2000 15:16:01 GMT Received: by mail-control.mail.uu.net id QQjksz10849 for mpls-outgoing; Fri, 13 Oct 2000 15:15:20 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjksz10791 for ; Fri, 13 Oct 2000 15:15:08 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjksy00472 for ; Fri, 13 Oct 2000 15:14:21 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjksy01688 for ; Fri, 13 Oct 2000 15:14:21 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18562 for ; Fri, 13 Oct 2000 11:14:18 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00360 for ; Fri, 13 Oct 2000 11:14:21 -0400 (EDT) Message-ID: <39E726EB.80A61E9A@marconi.com> Date: Fri, 13 Oct 2000 11:14:51 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Query on draft-ietf-mpls-label-encaps References: <200010120354.XAA09085@workhorse.fictitious.org> <01ea01c03473$d462c4e0$810aa8c0@maplenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sudhanshu Jain wrote: > > L3PID is the what used in setting up tunnel which are protocol aware. > > But if a tunnel is being setup as a fat pipe, ( e.g. L3PID is not > present at setup time). > > Is it possible for such a tunnel to carry multiprotocols via using 0 > or 2 label at the bottom of the stack? > > Is there any existing implementation which carry multi protocol over > single tunnel? If so, how do they carry protocol information > end-to-end? Doing this is very problematic. Eventually, the data will have to leave the MPLS tunnel. When it does, some kind of L3PID information must exist, in order to place it in the L2 header of the network beyond the tunnel. If multiple packets in the tunnel have different L3PIDs, how will the egress router be able to properly generate the L2 header? In the ATM world, wrappers like AAL5 are used to carry this kind of information. IMO, the only good way to carry multiple L3 protocols in a single LSP is to wrap the packets in something that can carry the protocol ID on a per-packet basis. If such a thing would be done, then (from MPLS's perspective), the tunnel would be carrying packets all of one type - the wrapper's type. Whatever code on the ingress/egress that exists to add/remove these wrappers would then be responsible for preserving the per-packet L3PID information. (Is there a draft for this? I don't know. If people really want to run multiple protocols in one tunnel, then such a draft would be useful so that different implementations can interoperate.) -- David From owner-mpls@UU.NET Fri Oct 13 12:36:04 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08898 for ; Fri, 13 Oct 2000 12:36:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkte15062; Fri, 13 Oct 2000 16:35:36 GMT Received: by mail-control.mail.uu.net id QQjkte27882 for mpls-outgoing; Fri, 13 Oct 2000 16:35:11 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkte27875 for ; Fri, 13 Oct 2000 16:35:03 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkte10929 for ; Fri, 13 Oct 2000 16:34:41 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjkte06684 for ; Fri, 13 Oct 2000 16:34:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA05051 for mpls@uu.net; Fri, 13 Oct 2000 12:34:39 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkte27852 for ; Fri, 13 Oct 2000 16:34:21 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkte22680 for ; Fri, 13 Oct 2000 16:34:02 GMT Received: from dirty.research.bell-labs.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQjkte22732 for ; Fri, 13 Oct 2000 16:34:01 GMT Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Oct 13 12:33:41 EDT 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Fri Oct 13 12:33:40 EDT 2000 Received: from research.bell-labs.com (ex-vpn70.pa.bell-labs.com [135.250.1.70]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAV31553 (AUTH gja); Fri, 13 Oct 2000 09:33:38 -0700 (PDT) Message-ID: <39E73987.24F16126@research.bell-labs.com> Date: Fri, 13 Oct 2000 09:34:15 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: mpls@UU.NET Subject: Re: Query on draft-ietf-mpls-label-encaps References: <200010120354.XAA09085@workhorse.fictitious.org> <01ea01c03473$d462c4e0$810aa8c0@maplenetworks.com> <39E726EB.80A61E9A@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David Charlap wrote: [..] > In the ATM world, wrappers like AAL5 are used to carry this kind of > information. AAL5 doesn't carry protocol muxing info per se, it requires additional overhead such as LLC/SNAP headers. Which (as you correctly allude) would solve the original poster's problem too. cheers, gja From owner-mpls@UU.NET Fri Oct 13 12:40:01 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09011 for ; Fri, 13 Oct 2000 12:40:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkte13488; Fri, 13 Oct 2000 16:39:38 GMT Received: by mail-control.mail.uu.net id QQjkte28109 for mpls-outgoing; Fri, 13 Oct 2000 16:39:12 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjkte28104 for ; Fri, 13 Oct 2000 16:39:06 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjkte20715 for ; Fri, 13 Oct 2000 16:38:49 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjkte00079 for ; Fri, 13 Oct 2000 16:38:48 GMT Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP; Fri, 13 Oct 2000 17:37:39 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <41BMRQN4>; Fri, 13 Oct 2000 17:37:34 +0100 Message-ID: To: david.charlap@marconi.com, mpls@UU.NET Subject: RE: Query on draft-ietf-mpls-label-encaps Date: Fri, 13 Oct 2000 17:37:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk David Charlap wrote: > Sudhanshu Jain wrote: > > > > L3PID is the what used in setting up tunnel which are protocol aware. > > > > But if a tunnel is being setup as a fat pipe, ( e.g. L3PID is not > > present at setup time). > > > > Is it possible for such a tunnel to carry multiprotocols via using 0 > > or 2 label at the bottom of the stack? > > > > Is there any existing implementation which carry multi protocol over > > single tunnel? If so, how do they carry protocol information > > end-to-end? > > Doing this is very problematic. > > Eventually, the data will have to leave the MPLS tunnel. When it does, > some kind of L3PID information must exist, in order to place it in the > L2 header of the network beyond the tunnel. If multiple packets in the > tunnel have different L3PIDs, how will the egress router be able to > properly generate the L2 header? > > In the ATM world, wrappers like AAL5 are used to carry this kind of > information. > > IMO, the only good way to carry multiple L3 protocols in a single LSP is > to wrap the packets in something that can carry the protocol ID on a > per-packet basis. > > > If such a thing would be done, then (from MPLS's perspective), the > tunnel would be carrying packets all of one type - the wrapper's type. > Whatever code on the ingress/egress that exists to add/remove these > wrappers would then be responsible for preserving the per-packet L3PID > information. > > (Is there a draft for this? I don't know. If people really want to run > multiple protocols in one tunnel, then such a draft would be useful so > that different implementations can interoperate.) > NH=> We will also need to address this issue for an MPLS layer OAM function (let alone a generic client layer layer identification). I had a discussion some time ago on the list on the need for a protocol ID field in the MPLS LSP header based on this OAM requirement. I would argue (and I know several supported this) that the TTL field is overkill at 8 bits and we could have made better use of this field...at least for OAM pkt identification. Further, because of the client/server relationship that ought to be adhered to between layer networks, one should not be making any assumption about server layer (in this TTL case) latent hop counts. That is, a link connection (ie 1-hop) in a LSP at level N (ie the client) is a trail (= unknown number of hops from client perspective) in an LSP at level N+1 (ie the server). This relationship (ie server layer trails = client layer links) can recurse several times, and it is a well-known/specifed functional arch feature of transport networks (see G.805). The only consensus I could reach on the list for the OAM issue was to create a new 'special label' (in addition to the 4 currently specified/reserved in the encaps ID). This is not a very elegant solution and creates restrictions, eg normal forwarding label stack has to be increased by 1 when an OAM pkt is sent (but this is not very often), and it complicates any attempt to define a user-plane-based route-trace capability....something we will now probably abandon in the OAM ID, at least for the time being. So yes, a protocol ID field would have been jolly useful even for an OAM requirement, but I guess its too late now. I can at least find a solution for (very basic) OAM, but this does not help you. Note - There is a key difference between OAM pkt identification and client protocol identifications. The former applies to all LSPs at any level, whereas the latter is only relevant in the highest level of LSP, ie below the top LSP, all subsequent lower LSP must have 'MPLS' as their client layer protocol. Neil From owner-mpls@UU.NET Fri Oct 13 13:01:01 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09304 for ; Fri, 13 Oct 2000 13:01:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjktg03661; Fri, 13 Oct 2000 17:00:27 GMT Received: by mail-control.mail.uu.net id QQjktg29261 for mpls-outgoing; Fri, 13 Oct 2000 17:00:01 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjktf29177 for ; Fri, 13 Oct 2000 16:59:59 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjktf22902 for ; Fri, 13 Oct 2000 16:58:56 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjktf09749 for ; Fri, 13 Oct 2000 16:58:55 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Fri, 13 Oct 2000 17:59:51 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id <4H57R1JP>; Fri, 13 Oct 2000 17:58:14 +0100 Message-ID: To: gja@research.bell-labs.com, david.charlap@marconi.com Cc: mpls@UU.NET Subject: RE: Query on draft-ietf-mpls-label-encaps Date: Fri, 13 Oct 2000 17:58:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk gja wrote: > David Charlap wrote: > [..] > > In the ATM world, wrappers like AAL5 are used to carry this kind of > > information. > > AAL5 doesn't carry protocol muxing info per se, it requires additional > overhead such as LLC/SNAP headers. Which (as you correctly allude) > would solve the original poster's problem too. > > cheers, > gja > NH=> I agree Grenville that this is one way to deal with this. But the immediate observation is that this creates a new network layer somewhere between the shim header and the payload, and so one is led to ask "if people think this is really needed then why was this not part of the basic MPLS O/H in the 1st place?" I have my own views on this, and I am sure others do....but from a slightly different angle, the fewer protocols that natively interface with applications the better, eg VoXX, gives an O(n^2/2) gateway problem across user/control/management planes....quite horrible when you count up what XX could be. neil From owner-mpls@UU.NET Fri Oct 13 21:45:57 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14983 for ; Fri, 13 Oct 2000 21:45:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkuo04682; Sat, 14 Oct 2000 01:44:55 GMT Received: by mail-control.mail.uu.net id QQjkuo15323 for mpls-outgoing; Sat, 14 Oct 2000 01:44:24 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkuo15318 for ; Sat, 14 Oct 2000 01:44:22 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkuo07542 for ; Sat, 14 Oct 2000 01:43:55 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjkuo29476 for ; Sat, 14 Oct 2000 01:43:54 GMT Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id SAA26439; Fri, 13 Oct 2000 18:43:53 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id <4NCAADLC>; Fri, 13 Oct 2000 18:43:54 -0700 Message-ID: From: Puneet Agarwal To: "'erosen@cisco.com'" , "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: bug in draft-ietf-mpls-label-encaps-08 Date: Fri, 13 Oct 2000 18:43:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Looks like "draft-ietf-mpls-label-encaps-08.txt" is inconsistent with hierarchical tunnels. On pg 5 it states: i. A value of 0 represents the "IPv4 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header. My understanding was that when a LSR got a label 3 from the egress LSR during signaling, if the LSR was able to do a pop then it would perform a penultimate hop pop otherwise it would just swap the incoming label with label 0 and then the egress LSR would do the actual pop. However, the draft states that the label 0 is only valid at the bottom of the stack. This implies that to support hierarchical tunnels one of 2 conditions have to be true: (a) All LSRs supporting hierarchical tunnels, need to support PHP (so they never swap label 0 on the stack) OR (b) The "label value is only legal at the bottom of the label stack" constraint should be removed from the draft for label 0. Since support for PHP is not a requirement for LSRs, the draft should be updated to remove the constraint for label 0, to support hierarchical tunnels. -Puneet From owner-mpls@UU.NET Fri Oct 13 23:53:34 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17185 for ; Fri, 13 Oct 2000 23:53:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkux15262; Sat, 14 Oct 2000 03:53:15 GMT Received: by mail-control.mail.uu.net id QQjkux15542 for mpls-outgoing; Sat, 14 Oct 2000 03:52:56 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkux15536 for ; Sat, 14 Oct 2000 03:52:52 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjkux10882 for ; Sat, 14 Oct 2000 03:52:41 GMT Received: from gateway.ntu.edu.sg by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gateway.ntu.edu.sg [155.69.1.127]) id QQjkux20583 for ; Sat, 14 Oct 2000 03:52:40 GMT Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id <4Q6VGDL8>; Sat, 14 Oct 2000 11:52:16 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE035AFF50@exchange4.ntu.edu.sg> From: Shen Gangxiang To: David Charlap , mpls@UU.NET Subject: RE: Query on draft-ietf-mpls-label-encaps Date: Sat, 14 Oct 2000 11:52:10 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Sudhanshu Jain wrote: > > L3PID is the what used in setting up tunnel which are protocol aware. > > But if a tunnel is being setup as a fat pipe, ( e.g. L3PID is not > present at setup time). > > Is it possible for such a tunnel to carry multiprotocols via using 0 > or 2 label at the bottom of the stack? > > Is there any existing implementation which carry multi protocol over > single tunnel? If so, how do they carry protocol information > end-to-end? David worte: Doing this is very problematic. Eventually, the data will have to leave the MPLS tunnel. When it does, some kind of L3PID information must exist, in order to place it in the L2 header of the network beyond the tunnel. If multiple packets in the tunnel have different L3PIDs, how will the egress router be able to properly generate the L2 header? As pointed out by the draft, "the identity of the network layer protocol must be inferable from the value of the label which is popped from the bottom of the stack, possibly along with the contents of the network layer header itself", so based on this, we may recognize the upper layer protocols. As to how to generate the L2 header, I think it is up to if the egress router can support such a kind of function. Gangxiang From owner-mpls@UU.NET Sat Oct 14 01:03:18 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17755 for ; Sat, 14 Oct 2000 01:03:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkvc13052; Sat, 14 Oct 2000 05:02:48 GMT Received: by mail-control.mail.uu.net id QQjkvc06994 for mpls-outgoing; Sat, 14 Oct 2000 05:02:16 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkvc06917 for ; Sat, 14 Oct 2000 05:02:09 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkvc18458 for ; Sat, 14 Oct 2000 05:00:51 GMT Received: from exchsrv1.cosinecom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjkvc06973 for ; Sat, 14 Oct 2000 05:00:50 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 13 Oct 2000 21:59:40 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29110BDA00@exchsrv1.cosinecom.com> From: Anoop Ghanwani To: "'Puneet Agarwal'" , "'erosen@cisco.com'" , "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: RE: bug in draft-ietf-mpls-label-encaps-08 Date: Fri, 13 Oct 2000 21:59:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0359B.8CEC3FF0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0359B.8CEC3FF0 Content-Type: text/plain; charset="ISO-8859-1" I don't think that intended use of the Explicit NULL labels is to get around the inability of a router to pop labels, but I could be wrong. The Explicit NULL labels are used when the penultimate router doesn't want to do IP forwarding of data packets and there is no label distribution protocol (RSVP, CR-LDP, LDP) running between the penultimate and ultimate hops for whatever reason. In fact, earlier versions of the encaps draft used to say that such a label is valid only when it is the sole entry in the label stack. I don't know why that statement was removed. -Anoop > -----Original Message----- > From: Puneet Agarwal [mailto:puneet@pluris.com] > Sent: Friday, October 13, 2000 6:44 PM > To: 'erosen@cisco.com'; 'mpls@uu.net'; 'tappan@cisco.com'; > 'yakov@cisco.com' > Subject: bug in draft-ietf-mpls-label-encaps-08 > > > Looks like "draft-ietf-mpls-label-encaps-08.txt" is inconsistent with > hierarchical tunnels. > > On pg 5 it states: > i. A value of 0 represents the "IPv4 Explicit > NULL Label". > This label value is only legal at the bottom of the > label stack. It indicates that the label > stack must be > popped, and the forwarding of the packet must then be > based on the IPv4 header. > > My understanding was that when a LSR got a label 3 from the > egress LSR > during signaling, if the LSR was able to do a pop then it > would perform a > penultimate hop pop otherwise it would just swap the incoming > label with > label 0 and then the egress LSR would do the actual pop. > > However, the draft states that the label 0 is only valid at > the bottom of > the stack. This implies that to support hierarchical tunnels one of 2 > conditions have to be true: > > (a) All LSRs supporting hierarchical tunnels, need to support > PHP (so they > never swap label 0 on the stack) > > OR > > (b) The "label value is only legal at the bottom of the label stack" > constraint should be removed from the draft for label 0. > > Since support for PHP is not a requirement for LSRs, the > draft should be > updated to remove the constraint for label 0, to support hierarchical > tunnels. > > -Puneet > ------_=_NextPart_001_01C0359B.8CEC3FF0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: bug in draft-ietf-mpls-label-encaps-08

I don't think that intended use of the Explicit = NULL
labels is to get around the inability of a = router
to pop labels, but I could be wrong.

The Explicit NULL labels are used when the = penultimate
router doesn't want to do IP forwarding of data = packets and
there is no label distribution protocol (RSVP, = CR-LDP, LDP)
running between the penultimate and ultimate hops = for whatever
reason.  In fact, earlier versions of the = encaps draft
used to say that such a label is valid only when it = is
the sole entry in the label stack.  I don't = know why
that statement was removed.

-Anoop

> -----Original Message-----
> From: Puneet Agarwal [mailto:puneet@pluris.com]
> Sent: Friday, October 13, 2000 6:44 PM
> To: 'erosen@cisco.com'; 'mpls@uu.net'; = 'tappan@cisco.com';
> 'yakov@cisco.com'
> Subject: bug in = draft-ietf-mpls-label-encaps-08
>
>
> Looks like = "draft-ietf-mpls-label-encaps-08.txt" is inconsistent = with
> hierarchical tunnels.
>
> On pg 5 it states:
>          = ;     i. A value of 0 represents the "IPv4 = Explicit
> NULL Label".
>          = ;        This label value is only = legal at the bottom of the
>          = ;        label stack.  It = indicates that the label
> stack must be
>          = ;        popped, and the forwarding = of the packet must then be
>          = ;        based on the IPv4 = header.
>
>  My understanding was that when a LSR got = a label 3 from the
> egress LSR
> during signaling, if the LSR was able to do a = pop then it
> would perform a
> penultimate hop pop otherwise it would just = swap the incoming
> label with
> label 0 and then the egress LSR would do the = actual pop.
>
> However, the draft states that the label 0 is = only valid at
> the bottom of
> the stack. This implies that to support = hierarchical tunnels one of 2
> conditions have to be true:
>
> (a) All LSRs supporting hierarchical tunnels, = need to support
> PHP (so they
> never swap label 0 on the stack)
>
> OR
>
> (b) The "label value is only legal at the = bottom of the label stack"
> constraint should be removed from the draft for = label 0.
>
> Since support for PHP is not a requirement for = LSRs, the
> draft should be
> updated to remove the constraint for label 0, = to support hierarchical
> tunnels.
>
> -Puneet
>

------_=_NextPart_001_01C0359B.8CEC3FF0-- From owner-mpls@UU.NET Sat Oct 14 06:10:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01779 for ; Sat, 14 Oct 2000 06:10:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjkvw21602; Sat, 14 Oct 2000 10:09:41 GMT Received: by mail-control.mail.uu.net id QQjkvw25237 for mpls-outgoing; Sat, 14 Oct 2000 10:09:17 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjkvw25232 for ; Sat, 14 Oct 2000 10:09:14 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjkvw25757 for ; Sat, 14 Oct 2000 10:08:19 GMT Received: from mail3.ntu.edu.sg by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.1.91]) id QQjkvw01067 for ; Sat, 14 Oct 2000 10:08:18 GMT Received: by mail3.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id ; Sat, 14 Oct 2000 18:07:58 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE035AFF68@exchange4.ntu.edu.sg> From: Shen Gangxiang To: mpls@UU.NET Subject: Queries on Signaling requirements at the optical UNI, draft-bala- mpls-optical-uni-signalling-00.txt Date: Sat, 14 Oct 2000 18:07:43 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, folks, I have a query on the draft: Signaling requirements at the optical UNI, draft-bala-mpls-optical-uni-signalling-00.txt When a UNI-C sends a Light-path Create Request to a UNI-N, the message uses (1) Source termination Point, IP address, (2) Destination termination Point, IP address, (3) Source termination point, port, Channel, Sub-Channel, and (4) Destination termination point, port, Channel, Sub-Channel to identify the exact source and destination addresses of the lightpath. To achieve this, this means that the UNI-C must have the information on the reachable IP addresses of all OXCs (i.e. IP addresses that can be accessed by an OXC). Based on this information, UNI-C decides the destination OXC and its logical interface of the lightpath. If these address information could be exchanged between UNI-C and UNI-N through "neighbor discovery" procedure, this approach of course can work. However, I wonder if we could use the IP addresses of the initiating and terminating UNI-Cs to substitute those information in (1)-(4). The detail suggestion is as follows: using the "neighbor discovery" procedure, we register the client IP address and user group identifier with the optical network, then the optical network employs IGP protocol to flooding these address-reachable information around the network; each time when an OXC receive a Lightpath Create Request that includes the IP addresses of the initiating and terminating UNI-Cs, it calculates the route for the lightpath and then trigger the signaling process to build up it. After the light-path is established successfully, the OXCs in the both terminations inform their corresponding UNI-Cs on this event. With such a modification, the optical network will look like a black-box except some interfaces to communicate with UNI-Cs. Moreover, there will be less information exchanged on UNI interface. Above is my idea. If it is not so correct, please kindly point out. Thanks! Gangxiang From owner-mpls@UU.NET Sun Oct 15 13:08:53 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09261 for ; Sun, 15 Oct 2000 13:08:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlaq27164; Sun, 15 Oct 2000 17:08:02 GMT Received: by mail-control.mail.uu.net id QQjlaq02046 for mpls-outgoing; Sun, 15 Oct 2000 17:07:40 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlaq02038 for ; Sun, 15 Oct 2000 17:07:31 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlaq06241 for ; Sun, 15 Oct 2000 17:06:34 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlaq20814 for ; Sun, 15 Oct 2000 17:06:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA13783 for mpls@uu.net; Sun, 15 Oct 2000 13:06:32 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlaq01891 for ; Sun, 15 Oct 2000 17:06:07 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlaq05046 for ; Sun, 15 Oct 2000 17:06:04 GMT Received: from procyon.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjlaq24556 for ; Sun, 15 Oct 2000 17:06:03 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA14683; Sun, 15 Oct 2000 10:06:02 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <46LFDTAA>; Sun, 15 Oct 2000 10:11:00 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C99E7@BBY1EXM01> From: Shahram Davari To: "'Puneet Agarwal'" , "'erosen@cisco.com'" , "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: RE: bug in draft-ietf-mpls-label-encaps-08 Date: Sun, 15 Oct 2000 10:11:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Puneet, > -----Original Message----- > From: Puneet Agarwal [mailto:puneet@pluris.com] > Sent: Friday, October 13, 2000 9:44 PM > To: 'erosen@cisco.com'; 'mpls@uu.net'; 'tappan@cisco.com'; > 'yakov@cisco.com' > Subject: bug in draft-ietf-mpls-label-encaps-08 > > > Looks like "draft-ietf-mpls-label-encaps-08.txt" is inconsistent with > hierarchical tunnels. > > On pg 5 it states: > i. A value of 0 represents the "IPv4 Explicit > NULL Label". > This label value is only legal at the bottom of the > label stack. It indicates that the label > stack must be > popped, and the forwarding of the packet must then be > based on the IPv4 header. > > My understanding was that when a LSR got a label 3 from the > egress LSR > during signaling, if the LSR was able to do a pop then it > would perform a > penultimate hop pop Correct. otherwise it would just swap the incoming > label with > label 0 and then the egress LSR would do the actual pop. This is only true if the label is the bottom most label in the stack. Otherwise a normal label swapping will be done at penultimate hop, and since the ultimate (egress) LSR knows it is the egress LSR, it could pop the swapped label. The reason is that in case the label is the bottom most label, the egress LSR could possibly use the explicit null label to determine the L3PID (i.e., 0 -> IPV4, 2-> IPV6). While this property is not needed when the LSR is not the terminating point of all LSPs. > > However, the draft states that the label 0 is only valid at > the bottom of > the stack. This implies that to support hierarchical tunnels one of 2 > conditions have to be true: > > (a) All LSRs supporting hierarchical tunnels, need to support > PHP (so they > never swap label 0 on the stack) > > OR > > (b) The "label value is only legal at the bottom of the label stack" > constraint should be removed from the draft for label 0. Regards, -Shahram > > Since support for PHP is not a requirement for LSRs, the > draft should be > updated to remove the constraint for label 0, to support hierarchical > tunnels. > > -Puneet > From owner-mpls@UU.NET Sun Oct 15 13:09:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09277 for ; Sun, 15 Oct 2000 13:09:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlaq24765; Sun, 15 Oct 2000 17:09:30 GMT Received: by mail-control.mail.uu.net id QQjlaq02094 for mpls-outgoing; Sun, 15 Oct 2000 17:08:59 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlaq02081 for ; Sun, 15 Oct 2000 17:08:43 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlaq25875 for ; Sun, 15 Oct 2000 17:07:53 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlaq22475 for ; Sun, 15 Oct 2000 17:07:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA13836 for mpls@uu.net; Sun, 15 Oct 2000 13:07:52 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlaq02037 for ; Sun, 15 Oct 2000 17:07:31 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlaq06103 for ; Sun, 15 Oct 2000 17:06:30 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjlaq22181 for ; Sun, 15 Oct 2000 17:06:30 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA14671; Sun, 15 Oct 2000 10:05:42 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <46LFDS08>; Sun, 15 Oct 2000 10:10:40 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C99E6@BBY1EXM01> From: Shahram Davari To: "'curtis@avici.com'" , Sudhanshu Jain Cc: erosen@cisco.com, Yakov Rekhter , dtappen@cisco.com, tli@procket.com, dino@procket.com, mpls@UU.NET Subject: RE: Query on draft-ietf-mpls-label-encaps Date: Sun, 15 Oct 2000 10:10:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, Although you are right in saying that L3PID could determine the L3, but this is limited only to REVP-TE. CR-LDP does not have such a field in its label request, and besides this is not required by label-encaps draft. So I think that the current IPV4/IPV6 explicit null labels are needed to addresses the scenarios in which L3PID does not exist (such as CR-LDP case). Regards, -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Wednesday, October 11, 2000 11:55 PM > To: Sudhanshu Jain > Cc: erosen@cisco.com; Yakov Rekhter; dtappen@cisco.com; > tli@procket.com; > dino@procket.com; mpls@UU.NET > Subject: Re: Query on draft-ietf-mpls-label-encaps > > > > In message > <018b01c033f6$fa29f900$810aa8c0@maplenetworks.com>, "Sudhanshu Jain" > writes: > > This is a multi-part message in MIME format. > > > > ------=_NextPart_000_0188_01C033BC.4D01B680 > > Content-Type: text/plain; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > Hi All, > > In draft-ietf-mpls-label-encaps-08.txt, in section 2.1 > language has = > > been > > changed to .... > > > > i. A value of 0 represents the "IPv4 Explicit > NULL Label". > > This label value is only legal at the bottom of the > > label stack. It indicates that the label > stack must be > > popped, and the forwarding of the packet > must then be > > based on the IPv4 header. > > > > > > From draft-ietf-mpls-label-encaps-07.txt, in section 2.1 .... > > > > i. A value of 0 represents the "IPv4 Explicit > NULL Label". > > This label value is only legal when it is the sole > > label stack entry. It indicates that the > label stack > > must be popped, and the forwarding of the > packet must > > then be based on the IPv4 header. > > > > =20 > > Same stands for the bullet (iii). > > > > Does it mean, Label 0 and Label 2 are used to carry > Protocol type=20 > > at the "bottom of the label stack" in case of tunnel traffic?=20 > > > > Is it the standard way to carry the protocol type in MPLS Tunnel = > > traffic? > > > > Thanks, > > -Sudhanshu > > > Sudhanshu, > > The last phrase in this paragraph should be reworded to say that it > will be forwarded based on the protocol type specified in the L3PID > when the tunnel was set, for example IPv4 or IPv6. > > Note to authors: > > Remove the last the words, "on the IPv4 header" and replace with "on > the underlying payload's header". You could also add a sentence > "The protocol type of the underlying header is determined by > signaling that occurs at LSP setup time". > > The use of L3PID to determine payload protocol identifier is > definitely a good candidate for an FAQ. The signaling of L3PID is > specified in section 4.2 of draft-ietf-mpls-rsvp-lsp-tunnel-07.txt. > > Curtis > From owner-mpls@UU.NET Sun Oct 15 13:19:58 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09316 for ; Sun, 15 Oct 2000 13:19:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlar07755; Sun, 15 Oct 2000 17:19:41 GMT Received: by mail-control.mail.uu.net id QQjlar02840 for mpls-outgoing; Sun, 15 Oct 2000 17:19:22 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlar02835 for ; Sun, 15 Oct 2000 17:19:13 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlar20061 for ; Sun, 15 Oct 2000 17:18:25 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlar06066 for ; Sun, 15 Oct 2000 17:18:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA15064 for mpls@uu.net; Sun, 15 Oct 2000 13:18:24 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlar02801 for ; Sun, 15 Oct 2000 17:17:58 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlar27762 for ; Sun, 15 Oct 2000 17:15:41 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjlar06295 for ; Sun, 15 Oct 2000 17:15:41 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA14768; Sun, 15 Oct 2000 10:12:00 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <46LFDTAN>; Sun, 15 Oct 2000 10:16:58 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C99E8@BBY1EXM01> From: Shahram Davari To: "'Anoop Ghanwani'" , "'Puneet Agarwal'" , "'erosen@cisco.com'" , "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: RE: bug in draft-ietf-mpls-label-encaps-08 Date: Sun, 15 Oct 2000 10:16:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C036CB.B8DF6304" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C036CB.B8DF6304 Content-Type: text/plain; charset="iso-8859-1" Hi Anoop, -----Original Message----- From: Anoop Ghanwani [mailto:anoop@cosinecom.com] Sent: Saturday, October 14, 2000 1:00 AM To: 'Puneet Agarwal'; 'erosen@cisco.com'; 'mpls@uu.net'; 'tappan@cisco.com'; 'yakov@cisco.com' Subject: RE: bug in draft-ietf-mpls-label-encaps-08 I don't think that intended use of the Explicit NULL labels is to get around the inability of a router to pop labels, but I could be wrong. The Explicit NULL labels are used when the penultimate router doesn't want to do IP forwarding of data packets and there is no label distribution protocol (RSVP, CR-LDP, LDP) running between the penultimate and ultimate hops for whatever reason. In fact, earlier versions of the encaps draft used to say that such a label is valid only when it is the sole entry in the label stack. I don't know why that statement was removed. As you said, the earlier versions of this draft required the explicit null label to be the sole label entry in the stack. The reason it was removed was due to hierarchical routing scenarios as shown below: A-----B-------C-------D-------E - X1 X2 X3 - Y1 0 0 0 - Assume LSP1 is the outer tunnel: B-C-D-E, and its labels are X1-X2-X3. Now assume LSP1 is carrying an inner LSP called LSP2 which consists of A-E link. If "B" as the penultimate hop of LSP2 wants to use the explicit null label, it could swap Y1 by 0, and then it could push label X1 on top of it. At the egress "E", label X3 will be popped, because E knows it is the egress of LSP1, and label 0 will also be popped and the packet will be routed as IPV4. As you can see in this example label 0 is not the sole label entry. Regards, -Shahram -Anoop > -----Original Message----- > From: Puneet Agarwal [ mailto:puneet@pluris.com ] > Sent: Friday, October 13, 2000 6:44 PM > To: 'erosen@cisco.com'; 'mpls@uu.net'; 'tappan@cisco.com'; > 'yakov@cisco.com' > Subject: bug in draft-ietf-mpls-label-encaps-08 > > > Looks like "draft-ietf-mpls-label-encaps-08.txt" is inconsistent with > hierarchical tunnels. > > On pg 5 it states: > i. A value of 0 represents the "IPv4 Explicit > NULL Label". > This label value is only legal at the bottom of the > label stack. It indicates that the label > stack must be > popped, and the forwarding of the packet must then be > based on the IPv4 header. > > My understanding was that when a LSR got a label 3 from the > egress LSR > during signaling, if the LSR was able to do a pop then it > would perform a > penultimate hop pop otherwise it would just swap the incoming > label with > label 0 and then the egress LSR would do the actual pop. > > However, the draft states that the label 0 is only valid at > the bottom of > the stack. This implies that to support hierarchical tunnels one of 2 > conditions have to be true: > > (a) All LSRs supporting hierarchical tunnels, need to support > PHP (so they > never swap label 0 on the stack) > > OR > > (b) The "label value is only legal at the bottom of the label stack" > constraint should be removed from the draft for label 0. > > Since support for PHP is not a requirement for LSRs, the > draft should be > updated to remove the constraint for label 0, to support hierarchical > tunnels. > > -Puneet > ------_=_NextPart_001_01C036CB.B8DF6304 Content-Type: text/html; charset="iso-8859-1" RE: bug in draft-ietf-mpls-label-encaps-08
Hi Anoop,
-----Original Message-----
From: Anoop Ghanwani [mailto:anoop@cosinecom.com]
Sent: Saturday, October 14, 2000 1:00 AM
To: 'Puneet Agarwal'; 'erosen@cisco.com'; 'mpls@uu.net'; 'tappan@cisco.com'; 'yakov@cisco.com'
Subject: RE: bug in draft-ietf-mpls-label-encaps-08


I don't think that intended use of the Explicit NULL
labels is to get around the inability of a router
to pop labels, but I could be wrong.

The Explicit NULL labels are used when the penultimate
router doesn't want to do IP forwarding of data packets and
there is no label distribution protocol (RSVP, CR-LDP, LDP)
running between the penultimate and ultimate hops for whatever
reason.   

 In fact, earlier versions of the encaps draft
used to say that such a label is valid only when it is
the sole entry in the label stack.  I don't know why
that statement was removed.  

 As you said, the earlier versions of this draft required the explicit null label to be the sole label entry in the stack. The reason it was removed was due to hierarchical routing scenarios as shown below:

 

A-----B-------C-------D-------E

-      X1      X2      X3      -

Y1    0      0        0       -

Assume LSP1 is the outer tunnel: B-C-D-E, and its labels are X1-X2-X3. Now assume LSP1 is carrying an inner LSP called LSP2 which consists of A-E link. If "B" as the penultimate hop of LSP2 wants to use the explicit null label, it could swap Y1 by 0, and then it could push label X1 on top of it. At the egress "E", label X3 will be popped, because E knows it is the egress of LSP1, and label 0 will also be popped and the packet will be routed as IPV4. As you can see in this example label 0 is not the sole label entry.

  

 Regards,

-Shahram

-Anoop

> -----Original Message-----
> From: Puneet Agarwal [mailto:puneet@pluris.com]
> Sent: Friday, October 13, 2000 6:44 PM
> To: 'erosen@cisco.com'; 'mpls@uu.net'; 'tappan@cisco.com';
> 'yakov@cisco.com'
> Subject: bug in draft-ietf-mpls-label-encaps-08
>
>
> Looks like "draft-ietf-mpls-label-encaps-08.txt" is inconsistent with
> hierarchical tunnels.
>
> On pg 5 it states:
>               i. A value of 0 represents the "IPv4 Explicit
> NULL Label".
>                  This label value is only legal at the bottom of the
>                  label stack.  It indicates that the label
> stack must be
>                  popped, and the forwarding of the packet must then be
>                  based on the IPv4 header.
>
>  My understanding was that when a LSR got a label 3 from the
> egress LSR
> during signaling, if the LSR was able to do a pop then it
> would perform a
> penultimate hop pop otherwise it would just swap the incoming
> label with
> label 0 and then the egress LSR would do the actual pop.
>
> However, the draft states that the label 0 is only valid at
> the bottom of
> the stack. This implies that to support hierarchical tunnels one of 2
> conditions have to be true:
>
> (a) All LSRs supporting hierarchical tunnels, need to support
> PHP (so they
> never swap label 0 on the stack)
>
> OR
>
> (b) The "label value is only legal at the bottom of the label stack"
> constraint should be removed from the draft for label 0.
>
> Since support for PHP is not a requirement for LSRs, the
> draft should be
> updated to remove the constraint for label 0, to support hierarchical
> tunnels.
>
> -Puneet
>

------_=_NextPart_001_01C036CB.B8DF6304-- From owner-mpls@UU.NET Mon Oct 16 06:38:16 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01661 for ; Mon, 16 Oct 2000 06:38:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjldi17188; Mon, 16 Oct 2000 10:37:31 GMT Received: by mail-control.mail.uu.net id QQjldi04628 for mpls-outgoing; Mon, 16 Oct 2000 10:37:04 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjldi04623 for ; Mon, 16 Oct 2000 10:37:03 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjldi20736 for ; Mon, 16 Oct 2000 10:36:08 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjldi00692 for ; Mon, 16 Oct 2000 10:36:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA20191 for mpls@uu.net; Mon, 16 Oct 2000 06:36:07 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjldi04483 for ; Mon, 16 Oct 2000 10:35:48 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjldi19397 for ; Mon, 16 Oct 2000 10:35:34 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjldi20078 for ; Mon, 16 Oct 2000 10:35:30 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01562; Mon, 16 Oct 2000 06:35:29 -0400 (EDT) Message-Id: <200010161035.GAA01562@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-ft-00.txt Date: Mon, 16 Oct 2000 06:35:29 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Fault Tolerance for LDP and CR-LDP Author(s) : A. Farrel, P. Brittain, P. Matthews, E. Gray Filename : draft-ietf-mpls-ldp-ft-00.txt Pages : 28 Date : 13-Oct-00 MPLS systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the switching hardware and TCP, are implementation specific. This document identifies issues in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements to the LDP specification to ease such FT LSR implementations. The extensions described here are equally applicable to CR-LDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ft-00.txt 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-ldp-ft-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-ft-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001013145133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-ft-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-ft-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001013145133.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Oct 16 09:10:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04565 for ; Mon, 16 Oct 2000 09:10:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlds06642; Mon, 16 Oct 2000 13:10:24 GMT Received: by mail-control.mail.uu.net id QQjlds18126 for mpls-outgoing; Mon, 16 Oct 2000 13:09:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlds18099 for ; Mon, 16 Oct 2000 13:09:37 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlds21204 for ; Mon, 16 Oct 2000 13:09:15 GMT Received: from neptune.telecomm.tadiran.co.il by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tadiran.co.il [194.90.248.2]) id QQjlds02687 for ; Mon, 16 Oct 2000 13:09:12 GMT Received: from oranus.ecitele.com (oranus [10.115.11.180]) by neptune.telecomm.tadiran.co.il (8.9.3/8.9.3) with ESMTP id PAA08364; Mon, 16 Oct 2000 15:03:51 +0200 (IST) Received: by oranus.ecitele.com with Internet Mail Service (5.5.2650.21) id <4MHSAKFR>; Mon, 16 Oct 2000 15:08:47 +0300 Message-ID: From: Porotsky Sergey To: "'mpls@UU.NET'" , "'flefauch@cisco.com'" Subject: Unreserved Bandwidth for Class-Type on Date: Mon, 16 Oct 2000 15:08:44 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03769.D4A2B2A0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03769.D4A2B2A0 Content-Type: text/plain > Hello, Francois. > Thanks for this draft, it gets us real possibilities to use "DiffServ > oriented" distributed explicit path selection. I understand, that > calculations of the "Unreserved Bandwidth for Class Type" is outscope of > your draft. But may be you (or somebody else) can recommend me some > drafts, articles, etc., about MPLS Admission Control for EF and AF LSPs ? > How intermediate LSR has to calculate Effective Bandwidth for current > (established) LSP from its RSVP/LDP traffic parameters? > Regards, Sergey. > -------------------------------------------------------------------------- > Sergey.Porotsky@ecitele.com Tel. (972-3)926 1258 > Fax. (972-3)926 1630 > 16 Martin Gehl St., > Sergey Porotsky P.O.B. 500, > Transport Networks Division Petach-Tikva 49104, > ECI Telecom LTD Israel > ------------------------------------------------------------------------- > ------_=_NextPart_001_01C03769.D4A2B2A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Unreserved Bandwidth for Class-Type on = <draft-lefaucheur-diff-te-ext-00.txt>

Hello, Francois.
Thanks for this draft, it gets us = real possibilities to  use "DiffServ oriented" = distributed explicit path selection. I understand, that calculations of = the "Unreserved Bandwidth for Class Type" is outscope of your = draft. But may be you (or somebody else) can recommend me some drafts, = articles, etc., about  MPLS Admission Control for EF and AF LSPs ? = How intermediate LSR has to calculate Effective Bandwidth for current = (established) LSP from its RSVP/LDP traffic parameters? =    

Regards, Sergey.
---------------------------------------------------------= -----------------
Sergey.Porotsky@ecitele.com    Tel. = (972-3)926 1258
         &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   Fax. (972-3)926 1630
         &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   16 Martin Gehl St.,
Sergey Porotsky                   &nb= sp;        P.O.B. 500,
Transport Networks = Division          = Petach-Tikva 49104,
ECI Telecom = LTD           &nb= sp;           &nb= sp; Israel
---------------------------------------------------------= ----------------

------_=_NextPart_001_01C03769.D4A2B2A0-- From owner-mpls@UU.NET Mon Oct 16 09:42:57 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05469 for ; Mon, 16 Oct 2000 09:42:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjldu06451; Mon, 16 Oct 2000 13:42:24 GMT Received: by mail-control.mail.uu.net id QQjldu20623 for mpls-outgoing; Mon, 16 Oct 2000 13:41:50 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjldu20618 for ; Mon, 16 Oct 2000 13:41:46 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjldu06607 for ; Mon, 16 Oct 2000 13:41:04 GMT Received: from ertpg14e1.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ertpg14e1.nortelnetworks.com [47.234.0.35]) id QQjldu04428 for ; Mon, 16 Oct 2000 13:41:03 GMT Received: from zcard00n.ca.nortel.com by ertpg14e1.nortelnetworks.com; Mon, 16 Oct 2000 09:35:39 -0400 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 45VPW4G3; Mon, 16 Oct 2000 09:35:36 -0400 Received: from americasm01.nt.com (wcars0v1.ca.nortel.com [47.14.98.167]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T5XGQLQ1; Mon, 16 Oct 2000 09:35:34 -0400 Message-ID: <39EB0426.E5966F46@americasm01.nt.com> Date: Mon, 16 Oct 2000 09:35:34 -0400 From: "Darek Skalecki" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Porotsky Sergey CC: "'mpls@UU.NET'" , "'flefauch@cisco.com'" Subject: Re: Unreserved Bandwidth for Class-Type on References: Content-Type: multipart/alternative; boundary="------------26CD64E91A022C9059AA804A" Sender: owner-mpls@UU.NET Precedence: bulk --------------26CD64E91A022C9059AA804A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Porotsky Sergey wrote: > > > Hello, Francois. > Thanks for this draft, it gets us real possibilities to use "DiffServ > oriented" distributed explicit path selection. I understand, that > calculations of the "Unreserved Bandwidth for Class Type" is outscope > of your draft. But may be you (or somebody else) can recommend me some > drafts, articles, etc., about MPLS Admission Control for EF and AF > LSPs ? How intermediate LSR has to calculate Effective Bandwidth for > current (established) LSP from its RSVP/LDP traffic parameters? Since CR-LDP uses ATM-style traffic parameters you may want to dig up some ATM documents that describe how to convert PDR, SDR, etc into effective bandwidth. Darek > > > Regards, Sergey. > > ------------------------------------------------------------------------- > > Sergey.Porotsky@ecitele.com Tel. (972-3)926 1258 > Fax. (972-3)926 1630 > 16 Martin Gehl St., > Sergey Porotsky P.O.B. 500, > Transport Networks Division Petach-Tikva 49104, > ECI Telecom LTD Israel > > ------------------------------------------------------------------------ -- Darek Skalecki Nortel (613) 765-2252 --------------26CD64E91A022C9059AA804A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Porotsky Sergey wrote:
 

Hello, Francois.
Thanks for this draft, it gets us real possibilities to  use "DiffServ oriented" distributed explicit path selection. I understand, that calculations of the "Unreserved Bandwidth for Class Type" is outscope of your draft. But may be you (or somebody else) can recommend me some drafts, articles, etc., about  MPLS Admission Control for EF and AF LSPs ? How intermediate LSR has to calculate Effective Bandwidth for current (established) LSP from its RSVP/LDP traffic parameters?

Since CR-LDP uses ATM-style traffic parameters you may want to dig up some ATM documents that describe how to convert PDR, SDR, etc into effective bandwidth.

Darek

 

Regards, Sergey.
--------------------------------------------------------------------------
Sergey.Porotsky@ecitele.com    Tel. (972-3)926 1258
                                                 Fax. (972-3)926 1630
                                                 16 Martin Gehl St.,
Sergey Porotsky                            P.O.B. 500,
Transport Networks Division          Petach-Tikva 49104,
ECI Telecom LTD                         Israel
-------------------------------------------------------------------------

-- 
Darek Skalecki
Nortel 
(613) 765-2252
  --------------26CD64E91A022C9059AA804A-- From owner-mpls@UU.NET Mon Oct 16 09:46:44 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05559 for ; Mon, 16 Oct 2000 09:46:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjldv02519; Mon, 16 Oct 2000 13:45:53 GMT Received: by mail-control.mail.uu.net id QQjldv20993 for mpls-outgoing; Mon, 16 Oct 2000 13:45:06 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjldu20786 for ; Mon, 16 Oct 2000 13:44:56 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjldu26018 for ; Mon, 16 Oct 2000 13:44:00 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjldu25898 for ; Mon, 16 Oct 2000 13:43:30 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA33597; Mon, 16 Oct 2000 09:32:27 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200010161332.JAA33597@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@avici.com'" , Sudhanshu Jain , erosen@cisco.com, Yakov Rekhter , dtappen@cisco.com, tli@procket.com, dino@procket.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Query on draft-ietf-mpls-label-encaps In-reply-to: Your message of "Sun, 15 Oct 2000 10:10:40 PDT." <9DC5E2ABE65BD54CA9088DA3194461D6010C99E6@BBY1EXM01> Date: Mon, 16 Oct 2000 09:32:27 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <9DC5E2ABE65BD54CA9088DA3194461D6010C99E6@BBY1EXM01>, Shahram Davari writes: > Hi Curtis, > > Although you are right in saying that L3PID could determine the L3, but this > is limited only to REVP-TE. CR-LDP does not have such a field in its label > request, and besides this is not required by label-encaps draft. Does anyone use CRLDP? :-) > So I think that the current IPV4/IPV6 explicit null labels are needed to > addresses the scenarios in which L3PID does not exist (such as CR-LDP case). > > Regards, > -Shahram CRLDP needs to get fixed to carry an L3PID. Generalized MPLS has a G-PID which is redundant for RSVP but fixes the CR-LDP problem. Curtis From owner-mpls@UU.NET Mon Oct 16 10:11:08 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06056 for ; Mon, 16 Oct 2000 10:11:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjldw16682; Mon, 16 Oct 2000 14:10:35 GMT Received: by mail-control.mail.uu.net id QQjldw03858 for mpls-outgoing; Mon, 16 Oct 2000 14:10:04 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjldw03832 for ; Mon, 16 Oct 2000 14:09:56 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjldw27343 for ; Mon, 16 Oct 2000 14:09:40 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjldw15292 for ; Mon, 16 Oct 2000 14:09:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA06656 for mpls@uu.net; Mon, 16 Oct 2000 10:09:39 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjldw03819 for ; Mon, 16 Oct 2000 14:09:22 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjldw24598 for ; Mon, 16 Oct 2000 14:08:28 GMT Received: from ogma.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjldw09083 for ; Mon, 16 Oct 2000 14:08:28 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 83637190; Mon, 16 Oct 2000 16:08:27 +0200 (MET DST) Received: from flefauch-8kcdt.cisco.com (nice-dhcp28.cisco.com [144.254.60.50]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA19429; Mon, 16 Oct 2000 16:08:26 +0200 (MET DST) Message-Id: <200010161408.QAA19429@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 16 Oct 2000 16:10:46 +0200 To: "Darek Skalecki" From: Francois Le Faucheur Subject: Re: Unreserved Bandwidth for Class-Type on Cc: Porotsky Sergey , "'mpls@UU.NET'" , "'flefauch@cisco.com'" , acharny@europe.cisco.com, jtw@lcs.mit.edu In-Reply-To: <39EB0426.E5966F46@americasm01.nt.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Sergey, Have you looked into the work from the ISSLL Working Group work on mapping Int-Serv flows over Diff-Serv cloud? This is work in progress but its scope encompasses the aspects of admission control over EF/AF PHBs to achieve given end-to-end QoS commitments (Guaranteed Service, Controlled Load). Specifically, I am thinking of , Integrated Service Mappings for Differentiated Services Networks. Francois At 09:35 16/10/2000 -0400, Darek Skalecki wrote: > > Porotsky Sergey wrote: >> >> >> >> Hello, Francois. >> Thanks for this draft, it gets us real possibilities to use "DiffServ >> oriented" distributed explicit path selection. I understand, that >> calculations of the "Unreserved Bandwidth for Class Type" is outscope of >> your draft. But may be you (or somebody else) can recommend me some drafts, >> articles, etc., about MPLS Admission Control for EF and AF LSPs ? How >> intermediate LSR has to calculate Effective Bandwidth for current >> (established) LSP from its RSVP/LDP traffic parameters? > > Since CR-LDP uses ATM-style traffic parameters you may want to dig up some > ATM documents that describe how to convert PDR, SDR, etc into effective > bandwidth. > > Darek >> >> >> >> Regards, Sergey. >> -------------------------------------------------------------------------- >> Sergey.Porotsky@ecitele.com Tel. (972-3)926 1258 >> Fax. (972-3)926 1630 >> 16 Martin Gehl St., >> Sergey Porotsky P.O.B. 500, >> Transport Networks Division Petach-Tikva 49104, >> ECI Telecom LTD Israel >> ------------------------------------------------------------------------- > > > -- > Darek Skalecki> Nortel > (613) 765-2252>  
> > From owner-mpls@UU.NET Mon Oct 16 10:32:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06397 for ; Mon, 16 Oct 2000 10:32:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjldy07541; Mon, 16 Oct 2000 14:31:53 GMT Received: by mail-control.mail.uu.net id QQjldy05735 for mpls-outgoing; Mon, 16 Oct 2000 14:30:58 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjldy05727 for ; Mon, 16 Oct 2000 14:30:55 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjldx00133 for ; Mon, 16 Oct 2000 14:29:30 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjldx14253 for ; Mon, 16 Oct 2000 14:29:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA12987 for ; Mon, 16 Oct 2000 07:29:29 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA08143 for mpls@uu.net; Mon, 16 Oct 2000 10:29:28 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlcf21343 for ; Mon, 16 Oct 2000 03:29:31 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlcf16126 for ; Mon, 16 Oct 2000 03:29:15 GMT Received: from sina.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.106.187.168]) id QQjlcf02646 for ; Mon, 16 Oct 2000 03:29:14 GMT Received: (qmail 6111 invoked by uid 99); 16 Oct 2000 03:31:27 -0000 Message-ID: <20001016033127.6110.qmail@sina.com> From: scl197241 To: mpls@UU.NET Subject: Please help me Date: Mon Oct 16 03:31:27 2000 Content-Type: multipart/mixed; boundary="----------9716670876024SINAEMAIL---" Sender: owner-mpls@UU.NET Precedence: bulk ------------9716670876024SINAEMAIL--- Content-Disposition: inline Content-Type: text/plain;charset="gb2312" Content-Transfer-Encoding: binary Sir: Would you please tell me how an extended discovery mechanism to implement which is used to locate LSRs that are not directly connected at the link level? Thank you very much. shichunli ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ÐÂÀËÍƳö°ÂÔ˶ÌÐÅÏ¢ÊÖ»úµã²¥·þÎñ http://sms.sina.com.cn/ ------------9716670876024SINAEMAIL--- Content-Disposition: attachment; Content-Type: message/rfc822; Return-Path: scl197241 From: scl197241 To: 80712@371.net Subject: Please help me Date: Mon Oct 16 02:07:12 2000 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Disposition-Notification-To: scl197241 MIME-Version: 1.0 Sir: Would you please tell me how an extended discovery mechanism to implement which is used to locate LSRs that are not directly connected at the link level? Thank you very much. shichunli ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn ÐÂÀËÍƳö°ÂÔ˶ÌÐÅÏ¢ÊÖ»úµã²¥·þÎñ http://sms.sina.com.cn/------------9716670876024SINAEMAIL----- ------------9716670876024SINAEMAIL----- From owner-mpls@UU.NET Mon Oct 16 11:02:38 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07049 for ; Mon, 16 Oct 2000 11:02:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlea28174; Mon, 16 Oct 2000 15:01:24 GMT Received: by mail-control.mail.uu.net id QQjlea10614 for mpls-outgoing; Mon, 16 Oct 2000 15:00:50 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlea10316 for ; Mon, 16 Oct 2000 15:00:40 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjldz23295 for ; Mon, 16 Oct 2000 14:59:20 GMT Received: from hoemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQjldz17395 for ; Mon, 16 Oct 2000 14:59:20 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA12115 for ; Mon, 16 Oct 2000 10:59:19 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA12104; Mon, 16 Oct 2000 10:59:19 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA09664; Mon, 16 Oct 2000 10:59:17 -0400 (EDT) Message-ID: <39EB17C4.16DDB6F6@lucent.com> Date: Mon, 16 Oct 2000 10:59:16 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Shen Gangxiang CC: mpls@UU.NET Subject: Re: Queries on Signaling requirements at the optical UNI, draft-bala-mpls-optical-uni-signalling-00.txt References: <9985F17605D2D21192D80008C75DE4BE035AFF68@exchange4.ntu.edu.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gangxiang, It's a good idea. Actually, it has been used by some ATM vendors for IP/ATM address resolution. Yet, there are several other address resolution mechanisms. There is no need to specify the solution in the UNI signaling specification (recommendations are always welcomed). Different vendors may choose different ways within their own cloud. Regards, Yangguang Shen Gangxiang wrote: > > Hi, folks, > > I have a query on the draft: Signaling requirements at the optical UNI, > draft-bala-mpls-optical-uni-signalling-00.txt > > When a UNI-C sends a Light-path Create Request to a UNI-N, the message uses > (1) Source termination Point, IP address, (2) Destination termination Point, > IP address, (3) Source termination point, port, Channel, Sub-Channel, and > (4) Destination termination point, port, Channel, Sub-Channel to identify > the exact source and destination addresses of the lightpath. To achieve > this, this means that the UNI-C must have the information on the reachable > IP addresses of all OXCs (i.e. IP addresses that can be accessed by an OXC). > Based on this information, UNI-C decides the destination OXC and its logical > interface of the lightpath. If these address information could be exchanged > between UNI-C and UNI-N through "neighbor discovery" procedure, this > approach of course can work. > > However, I wonder if we could use the IP addresses of the initiating and > terminating UNI-Cs to substitute those information in (1)-(4). The detail > suggestion is as follows: using the "neighbor discovery" procedure, we > register the client IP address and user group identifier with the optical > network, then the optical network employs IGP protocol to flooding these > address-reachable information around the network; each time when an OXC > receive a Lightpath Create Request that includes the IP addresses of the > initiating and terminating UNI-Cs, it calculates the route for the lightpath > and then trigger the signaling process to build up it. After the light-path > is established successfully, the OXCs in the both terminations inform their > corresponding UNI-Cs on this event. > > With such a modification, the optical network will look like a black-box > except some interfaces to communicate with UNI-Cs. Moreover, there will be > less information exchanged on UNI interface. > > Above is my idea. If it is not so correct, please kindly point out. Thanks! > > Gangxiang From owner-mpls@UU.NET Mon Oct 16 11:40:03 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08026 for ; Mon, 16 Oct 2000 11:40:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlec00380; Mon, 16 Oct 2000 15:39:23 GMT Received: by mail-control.mail.uu.net id QQjlec24017 for mpls-outgoing; Mon, 16 Oct 2000 15:38:57 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlec24008 for ; Mon, 16 Oct 2000 15:38:52 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlec13278 for ; Mon, 16 Oct 2000 15:38:26 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjlec28939 for ; Mon, 16 Oct 2000 15:38:22 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA34302; Mon, 16 Oct 2000 11:36:21 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200010161536.LAA34302@workhorse.fictitious.org> To: Ping Pan cc: curtis@avici.com, Fred Baker , Randy Bush , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Any SPs using QoS ??? In-reply-to: Your message of "Fri, 06 Oct 2000 14:12:09 EDT." <39DE15F9.5BC28D95@cs.columbia.edu> Date: Mon, 16 Oct 2000 11:36:21 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <39DE15F9.5BC28D95@cs.columbia.edu>, Ping Pan writes: > Curtis Villamizar wrote: > > > > In message <5.0.0.25.2.20000929150628.0274b540@flipper>, Fred Baker writes: > > > At 01:08 PM 9/28/00 -0700, Randy Bush wrote: > > > >this has appeal. but ecn looks much simpler. > > > > > > Is ECN something that you would consider pushing toward standardization? > I > > > like it, but I'm looking for operator feedback, and some (notably Juha) > > > distrust a mechanism that trusts the host. > > > > It should at least go through as experimental but preferably as > > proposed standard. Shouldn't the ECN WG get Cc'd? > > > > Curtis > > > > ps - Juha doesn't have to turn it on if he doesn't trust it. > > Please educate me here. Is the idea of ENC similar to that of FECN and > BECN in Frame Relay? That is, upon congestion notification, end nodes > start to slow down packet transmission. Many routers today happen to be > the "end nodes". They generally use GRE encapsulation to support user's > traffic (such as delay-sensitive SNA data). Supporting ECN would mean > that the edge routers must (re)implement congestion avoidance mechanism > for encapsulated packets, is that correct? Do you think this may cause > deployment problem? Or maybe all routers have such capability already. ECN is not like FECN and BECN. ECN is used for end-to-end congestion avoidance (TCP). The ECN ECT (ECN capable transport) bit is used to indicate that the end systems are ECN capable and using ECN. The CE (congestion experienced) bit is set by routers in place of a drop to indicate that a drop would have occurred. TCP is expected to react as if a drop has ocurred, but the retransmission is avoided. Discussions of how to penalize hosts that fake ECT and then don't back off is a lengthy topic. Curtis From owner-mpls@UU.NET Mon Oct 16 12:09:37 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08953 for ; Mon, 16 Oct 2000 12:09:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlee09718; Mon, 16 Oct 2000 16:09:01 GMT Received: by mail-control.mail.uu.net id QQjlee07978 for mpls-outgoing; Mon, 16 Oct 2000 16:08:15 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlee07925 for ; Mon, 16 Oct 2000 16:07:55 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlee19972 for ; Mon, 16 Oct 2000 16:07:26 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjlee22018 for ; Mon, 16 Oct 2000 16:07:25 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA34437; Mon, 16 Oct 2000 12:05:49 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200010161605.MAA34437@workhorse.fictitious.org> To: Bala Rajagopalan cc: George Swallow , John Drake , "'Debanjan Saha'" , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Draft Minutes from Pittsburgh In-reply-to: Your message of "Thu, 12 Oct 2000 10:10:33 EDT." <39E5C659.FFDE20C0@tellium.com> Date: Mon, 16 Oct 2000 12:05:49 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <39E5C659.FFDE20C0@tellium.com>, Bala Rajagopalan writes: > > > > In the mean time we also need to make progress. So the consensus we > > reached is the consensus. It can be revisited of course. But as far > > as progessing drafts, I'm expecting the authors of the kompella draft > > to issue a draft with just the signalling aspects as a WG draft or > > drafts depending on whether they decide to have a single document or > > one for each of RSVP and LDP. > > This statement is contradictory. If we're going to revisit, why issue a > working group draft before finishing the discussion? > > W.r.t consensus, I don't believe enough information was available > at the last meeting to make a decision on proceeding with the Kompella > draft as a WG draft, specifically, the need for flooding optitimization > with the propsoed bundling approach. I don't mind if a decision on this > is made after another round of discussions on the mailing list prior to > the next meeting. > > Regards, > > Bala Bala, I remember there being consensus at Pittsburgh on making the Kompella bundles draft a WG item. Use of the flooding optitimization is one means of improving the efficiency of the IGP and is a separate issue. Both the bundles and the flooding optitimization can stand alone. Neither one depends on the other. If used together they may complement each other but use of either one separately is possible and useful. I don't see that any changes are required to the bundles draft to accommodate the flooding optitimization. If changes are required, please point them out. Curtis From owner-mpls@UU.NET Mon Oct 16 13:10:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10837 for ; Mon, 16 Oct 2000 13:10:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlei29728; Mon, 16 Oct 2000 17:09:27 GMT Received: by mail-control.mail.uu.net id QQjlei23251 for mpls-outgoing; Mon, 16 Oct 2000 17:09:08 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlei23227 for ; Mon, 16 Oct 2000 17:08:57 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlei15858 for ; Mon, 16 Oct 2000 17:07:58 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjlei27514 for ; Mon, 16 Oct 2000 17:07:57 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA17568; Mon, 16 Oct 2000 10:07:56 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA09413; Mon, 16 Oct 2000 13:07:54 -0400 (EDT) Message-Id: <200010161707.NAA09413@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Puneet Agarwal cc: "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: Re: bug in draft-ietf-mpls-label-encaps-08 In-reply-to: Your message of Fri, 13 Oct 2000 18:43:45 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Mon, 16 Oct 2000 13:07:54 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Puneet> My understanding was that when a LSR got a label 3 from the egress Puneet> LSR during signaling, if the LSR was able to do a pop then it would Puneet> perform a penultimate hop pop otherwise it would just swap the Puneet> incoming label with label 0 and then the egress LSR would do the Puneet> actual pop. I don't think this understanding accords with section 4.1.5 of draft-ietf- mpls-arch-07.txt: "... a binding of Implicit NULL may be distributed only to LSRs which can support that function." From owner-mpls@UU.NET Mon Oct 16 13:25:57 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11311 for ; Mon, 16 Oct 2000 13:25:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlej22173; Mon, 16 Oct 2000 17:25:12 GMT Received: by mail-control.mail.uu.net id QQjlej25014 for mpls-outgoing; Mon, 16 Oct 2000 17:24:48 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlej24999 for ; Mon, 16 Oct 2000 17:24:36 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlej07171 for ; Mon, 16 Oct 2000 17:24:25 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlej08467 for ; Mon, 16 Oct 2000 17:24:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA04807 for mpls@uu.net; Mon, 16 Oct 2000 13:24:24 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlej24972 for ; Mon, 16 Oct 2000 17:23:53 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlej21934 for ; Mon, 16 Oct 2000 17:23:22 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjlej19613 for ; Mon, 16 Oct 2000 17:23:22 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA20547; Mon, 16 Oct 2000 10:23:20 -0700 (PDT) Message-ID: <39EB3988.9353FC9F@pluris.com> Date: Mon, 16 Oct 2000 10:23:20 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: erosen@cisco.com CC: Puneet Agarwal , "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: Re: bug in draft-ietf-mpls-label-encaps-08 References: <200010161707.NAA09413@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Unfortunately, this is the way we observe Implicit Null being used in the field. Also, I have not seen a negotiation mechanism for RSVP-TE for PHP support. I also think that the arch spec may contradict the label encaps spec. Bora Eric Rosen wrote: > Puneet> My understanding was that when a LSR got a label 3 from the egress > Puneet> LSR during signaling, if the LSR was able to do a pop then it would > Puneet> perform a penultimate hop pop otherwise it would just swap the > Puneet> incoming label with label 0 and then the egress LSR would do the > Puneet> actual pop. > > I don't think this understanding accords with section 4.1.5 of draft-ietf- > mpls-arch-07.txt: > > "... a binding of Implicit NULL may be distributed only > to LSRs which can support that function." From owner-mpls@UU.NET Mon Oct 16 13:40:10 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11641 for ; Mon, 16 Oct 2000 13:40:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlek04587; Mon, 16 Oct 2000 17:39:50 GMT Received: by mail-control.mail.uu.net id QQjlek26794 for mpls-outgoing; Mon, 16 Oct 2000 17:39:28 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlek26768 for ; Mon, 16 Oct 2000 17:39:24 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlek09325 for ; Mon, 16 Oct 2000 17:37:43 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlek26862 for ; Mon, 16 Oct 2000 17:37:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA07088 for mpls@uu.net; Mon, 16 Oct 2000 13:37:42 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlek26582 for ; Mon, 16 Oct 2000 17:37:24 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlek24407 for ; Mon, 16 Oct 2000 17:37:01 GMT Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjlek00571 for ; Mon, 16 Oct 2000 17:37:00 GMT Received: from sj-dial-1-80.cisco.com (sj-dial-1-80.cisco.com [171.68.179.81]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA11982; Mon, 16 Oct 2000 10:36:05 -0700 (PDT) Date: Mon, 16 Oct 2000 10:30:08 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <11437.001016@cisco.com> To: Curtis Villamizar CC: Bala Rajagopalan , curtis@avici.com, George Swallow , John Drake , "'Debanjan Saha'" , mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh In-reply-To: <200010161605.MAA34437@workhorse.fictitious.org> References: <200010161605.MAA34437@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Agree 100%. We have 3 techniques that are somewhat related, but yet orthogonal: 1. Link bundling 2. Control channel[s] for link bundles (LMP) 3. IGP flooding optimizations Link bundling allows to summarize the TE information. LMP allows to minimize the number of adjacencies per bundle (note that LMP will not have to be implemented on each type of links), and flooding optimizations minimize overhead traffic over parallel adjacencies. Alex. Monday, October 16, 2000, 9:05 AM, Curtis Villamizar wrote: > Bala, > I remember there being consensus at Pittsburgh on making the Kompella > bundles draft a WG item. > Use of the flooding optitimization is one means of improving the > efficiency of the IGP and is a separate issue. > Both the bundles and the flooding optitimization can stand alone. > Neither one depends on the other. If used together they may > complement each other but use of either one separately is possible and > useful. > I don't see that any changes are required to the bundles draft to > accommodate the flooding optitimization. If changes are required, > please point them out. > Curtis From owner-mpls@UU.NET Mon Oct 16 13:45:36 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11744 for ; Mon, 16 Oct 2000 13:45:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlel22873; Mon, 16 Oct 2000 17:45:11 GMT Received: by mail-control.mail.uu.net id QQjlek27215 for mpls-outgoing; Mon, 16 Oct 2000 17:44:28 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlek27206 for ; Mon, 16 Oct 2000 17:44:21 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlek24444 for ; Mon, 16 Oct 2000 17:43:56 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlek05410 for ; Mon, 16 Oct 2000 17:43:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA08366 for mpls@uu.net; Mon, 16 Oct 2000 13:43:55 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlek27101 for ; Mon, 16 Oct 2000 17:43:39 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlek22386 for ; Mon, 16 Oct 2000 17:43:03 GMT Received: from procyon.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjlek04182 for ; Mon, 16 Oct 2000 17:43:02 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA11324; Mon, 16 Oct 2000 10:41:15 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <46LFD706>; Mon, 16 Oct 2000 10:46:13 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C99F1@BBY1EXM01> From: Shahram Davari To: "'curtis@avici.com'" Cc: Sudhanshu Jain , erosen@cisco.com, Yakov Rekhter , dtappen@cisco.com, tli@procket.com, dino@procket.com, mpls@UU.NET Subject: RE: Query on draft-ietf-mpls-label-encaps Date: Mon, 16 Oct 2000 10:46:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Curtis, The egress node of an LSP, knows that it is the egress of that LSP. So the penultimate node could basically swap the top label with any label (not just 0, 2) and the egress LSR (knowing that it is egress point)could pop it. So my questions are: 1) Why do we need explicit null labels? 2) Why do we have two explicit null labels 0 and 2? Regards, -Shahram > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, October 16, 2000 9:32 AM > To: Shahram Davari > Cc: 'curtis@avici.com'; Sudhanshu Jain; erosen@cisco.com; > Yakov Rekhter; > dtappen@cisco.com; tli@procket.com; dino@procket.com; mpls@UU.NET > Subject: Re: Query on draft-ietf-mpls-label-encaps > > > > In message > <9DC5E2ABE65BD54CA9088DA3194461D6010C99E6@BBY1EXM01>, Shahram Davari > writes: > > Hi Curtis, > > > > Although you are right in saying that L3PID could determine > the L3, but this > > is limited only to REVP-TE. CR-LDP does not have such a > field in its label > > request, and besides this is not required by label-encaps draft. > > Does anyone use CRLDP? :-) > > > So I think that the current IPV4/IPV6 explicit null labels > are needed to > > addresses the scenarios in which L3PID does not exist (such > as CR-LDP case). > > > > Regards, > > -Shahram > > CRLDP needs to get fixed to carry an L3PID. > > Generalized MPLS has a G-PID which is redundant for RSVP but fixes the > CR-LDP problem. > > Curtis > From owner-mpls@UU.NET Mon Oct 16 13:47:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11782 for ; Mon, 16 Oct 2000 13:47:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlel25732; Mon, 16 Oct 2000 17:46:47 GMT Received: by mail-control.mail.uu.net id QQjlel27434 for mpls-outgoing; Mon, 16 Oct 2000 17:45:32 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlel27426 for ; Mon, 16 Oct 2000 17:45:18 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlek12923 for ; Mon, 16 Oct 2000 17:44:43 GMT Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQjlek11167 for ; Mon, 16 Oct 2000 17:44:41 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <48XXD2TS>; Mon, 16 Oct 2000 10:45:22 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6625D8AF3@ICARIAN> From: Eric Gray To: "'Bora Akyol'" , erosen@cisco.com Cc: Puneet Agarwal , "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: RE: bug in draft-ietf-mpls-label-encaps-08 Date: Mon, 16 Oct 2000 10:45:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Bora, There is always a brute force negotiation mechanism: the upstream LSR that does not support PHP can simply refuse to do so - perhaps sending an appropriate error message. The procedure for this is spelled out in section 4.1.1.2 of RSVP-TE - "4.1.1.2. Upstream A node uses the label carried in the LABEL object as the outgoing label associated with the sender. The router allocates a new label and binds it to the incoming interface of this session/sender. This is the same interface that the router uses to forward Resv messages to the previous hops. Several circumstance can lead to an unacceptable label. ... 2. The implicit null label was assigned, but the node is not capable of doing a penultimate pop for the associated L3PID ... In any of these events the node send a ResvErr message with an error code of 'routing problem' and an error value of 'unacceptable label value'." -- Eric Gray > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Monday, October 16, 2000 10:23 AM > To: erosen@cisco.com > Cc: Puneet Agarwal; 'mpls@uu.net'; 'tappan@cisco.com'; > 'yakov@cisco.com' > Subject: Re: bug in draft-ietf-mpls-label-encaps-08 > > > Eric > > Unfortunately, this is the way we observe Implicit Null being > used in the field. > Also, I have not seen a negotiation mechanism for RSVP-TE for > PHP support. > > I also think that the arch spec may contradict the label encaps spec. > > Bora > > > Eric Rosen wrote: > > > Puneet> My understanding was that when a LSR got a label > 3 from the egress > > Puneet> LSR during signaling, if the LSR was able to do a > pop then it would > > Puneet> perform a penultimate hop pop otherwise it > would just swap the > > Puneet> incoming label with label 0 and then the egress > LSR would do the > > Puneet> actual pop. > > > > I don't think this understanding accords with section > 4.1.5 of draft-ietf- > > mpls-arch-07.txt: > > > > "... a binding of Implicit NULL may be distributed only > > to LSRs which can support that function." > From owner-mpls@UU.NET Mon Oct 16 14:03:21 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12134 for ; Mon, 16 Oct 2000 14:03:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlem07052; Mon, 16 Oct 2000 18:03:08 GMT Received: by mail-control.mail.uu.net id QQjlem05089 for mpls-outgoing; Mon, 16 Oct 2000 18:02:50 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlem04736 for ; Mon, 16 Oct 2000 18:02:40 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlem24578 for ; Mon, 16 Oct 2000 18:02:00 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjlem01794 for ; Mon, 16 Oct 2000 18:01:57 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA35270; Mon, 16 Oct 2000 13:59:49 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200010161759.NAA35270@workhorse.fictitious.org> To: Shahram Davari cc: "'curtis@avici.com'" , Sudhanshu Jain , erosen@cisco.com, Yakov Rekhter , dtappen@cisco.com, tli@procket.com, dino@procket.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Query on draft-ietf-mpls-label-encaps In-reply-to: Your message of "Mon, 16 Oct 2000 10:46:07 PDT." <9DC5E2ABE65BD54CA9088DA3194461D6010C99F1@BBY1EXM01> Date: Mon, 16 Oct 2000 13:59:49 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <9DC5E2ABE65BD54CA9088DA3194461D6010C99F1@BBY1EXM01>, Shahram Davari writes: > Hi Curtis, > > The egress node of an LSP, knows that it is the egress of that LSP. So the > penultimate node could basically swap the top label with any label (not just > 0, 2) and the egress LSR (knowing that it is egress point)could pop it. So > my questions are: > > 1) Why do we need explicit null labels? > 2) Why do we have two explicit null labels 0 and 2? > > Regards, > -Shahram Whether "we" need these depends on who "we" is. Some routers cannot forward at full line rate if they have to do a lookup to determin that they have to POP a label and then do a second lookup on the underlying protocol. These routers need to send label 0 or 3 for IPv4 and 2 or 3 for IPv6. If they would rather special case 0 and 2 in hardware and do the appropriate lookup, they can. I don't see that these do any harm. Just leaving label 3 in place as a signaling convention and dropping 0 and 2 would be OK by me. I don't see a compelling reason to drop them since supporting them is almost trivial. Curtis From owner-mpls@UU.NET Mon Oct 16 14:09:16 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12270 for ; Mon, 16 Oct 2000 14:09:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlem15730; Mon, 16 Oct 2000 18:09:02 GMT Received: by mail-control.mail.uu.net id QQjlem09710 for mpls-outgoing; Mon, 16 Oct 2000 18:08:30 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlem09686 for ; Mon, 16 Oct 2000 18:08:20 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlem08692 for ; Mon, 16 Oct 2000 18:07:53 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlem10252 for ; Mon, 16 Oct 2000 18:07:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA13300 for mpls@uu.net; Mon, 16 Oct 2000 14:07:52 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlem09588 for ; Mon, 16 Oct 2000 18:07:16 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlem06119 for ; Mon, 16 Oct 2000 18:06:51 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjlem28418 for ; Mon, 16 Oct 2000 18:06:50 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA21687; Mon, 16 Oct 2000 11:06:46 -0700 (PDT) Message-ID: <39EB43B6.34EA17CE@pluris.com> Date: Mon, 16 Oct 2000 11:06:46 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Eric Gray CC: erosen@cisco.com, Puneet Agarwal , "'mpls@uu.net'" Subject: Re: bug in draft-ietf-mpls-label-encaps-08 References: <4611AD058694D4118FD5009027B0A6625D8AF3@ICARIAN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yes But this is a bit too brute for my taste. The fact is that people are using Implicit and Explicit NULL labels in the manner originally described and it would be nice to acknowledge that. Bora Eric Gray wrote: > Bora, > > There is always a brute force negotiation > mechanism: the upstream LSR that does not support > PHP can simply refuse to do so - perhaps sending > an appropriate error message. The procedure for > this is spelled out in section 4.1.1.2 of RSVP-TE > - > > "4.1.1.2. Upstream > > A node uses the label carried in the LABEL object as the outgoing > label associated with the sender. The router allocates a new label > and binds it to the incoming interface of this session/sender. This > is the same interface that the router uses to forward Resv messages > to the previous hops. > > Several circumstance can lead to an unacceptable label. > ... > 2. The implicit null label was assigned, but the node is not > capable of doing a penultimate pop for the associated L3PID > ... > In any of these events the node send a ResvErr message with an error > code of 'routing problem' and an error value of 'unacceptable label > value'." > > -- > Eric Gray > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > Sent: Monday, October 16, 2000 10:23 AM > > To: erosen@cisco.com > > Cc: Puneet Agarwal; 'mpls@uu.net'; 'tappan@cisco.com'; > > 'yakov@cisco.com' > > Subject: Re: bug in draft-ietf-mpls-label-encaps-08 > > > > > > Eric > > > > Unfortunately, this is the way we observe Implicit Null being > > used in the field. > > Also, I have not seen a negotiation mechanism for RSVP-TE for > > PHP support. > > > > I also think that the arch spec may contradict the label encaps spec. > > > > Bora > > > > > > Eric Rosen wrote: > > > > > Puneet> My understanding was that when a LSR got a label > > 3 from the egress > > > Puneet> LSR during signaling, if the LSR was able to do a > > pop then it would > > > Puneet> perform a penultimate hop pop otherwise it > > would just swap the > > > Puneet> incoming label with label 0 and then the egress > > LSR would do the > > > Puneet> actual pop. > > > > > > I don't think this understanding accords with section > > 4.1.5 of draft-ietf- > > > mpls-arch-07.txt: > > > > > > "... a binding of Implicit NULL may be distributed only > > > to LSRs which can support that function." > > From owner-mpls@UU.NET Mon Oct 16 15:05:52 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13680 for ; Mon, 16 Oct 2000 15:05:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjleq25687; Mon, 16 Oct 2000 19:05:14 GMT Received: by mail-control.mail.uu.net id QQjleq24897 for mpls-outgoing; Mon, 16 Oct 2000 19:04:32 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjleq24879 for ; Mon, 16 Oct 2000 19:04:19 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjleq23509 for ; Mon, 16 Oct 2000 19:04:03 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjleq24051 for ; Mon, 16 Oct 2000 19:04:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA09982; Mon, 16 Oct 2000 12:04:02 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA09678; Mon, 16 Oct 2000 15:04:01 -0400 (EDT) Message-Id: <200010161904.PAA09678@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Bora Akyol cc: Puneet Agarwal , "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: Re: bug in draft-ietf-mpls-label-encaps-08 In-reply-to: Your message of Mon, 16 Oct 2000 10:23:20 -0700. <39EB3988.9353FC9F@pluris.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Mon, 16 Oct 2000 15:04:00 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Bora> I also think that the arch spec may contradict the label encaps spec. Gee, maybe the primary author of the arch spec should meet with the primary author of the encaps spec and talk this out ;-) Actually, I don't believe the encaps spec says anything whatsoever about when you are supposed (or not supposed to) bind Implicit Null to a FEC. Nor does the arch spec say anything about Explicit Null. So I don't see what the contradiction would be. Bora> I have not seen a negotiation mechanism for RSVP-TE for PHP support. Whether the various label distribution protocols contain all the necessary mechanisms is an orthogonal issue. Puneet> My understanding was that when a LSR got a label 3 from the egress Puneet> LSR during signaling, if the LSR was able to do a pop then it would Puneet> perform a penultimate hop pop otherwise it would just swap the Puneet> incoming label with label 0 and then the egress LSR would do the Puneet> actual pop. Eric> I don't think this understanding accords with section 4.1.5 of Eric> draft-ietf-mpls-arch-07.txt Bora> this is the way we observe Implicit Null being used in the field. I've heard of various strange modes of operation having to do with php, implicit null, and explicit null, but I hadn't heard of this one. However, the procedure should work, as long as the label in question is at the bottom of the stack, and is likely to work in other cases as well. If you happen to have a system which can't do php connected to a system which can't refrain from using Implicit Null, this makes for a good workaround. At least, until you run into a system which can't handle Explicit Null. The fact that a prohibited procedure works could be considered a deficiency in the specs, or it could be considered to be a case of "be liberal in what you accept, conservative in what you send". Bora> The fact is that people are using Implicit and Explicit NULL labels in Bora> the manner originally described and it would be nice to acknowledge Bora> that. At some point, we should do a survey of the implementations and see what they do. If there are a number of mutually interworking implementations which do not follow the spec, then of course it makes sense to modify the spec to bring those implementations into compliance. From owner-mpls@UU.NET Mon Oct 16 15:18:20 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13931 for ; Mon, 16 Oct 2000 15:18:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjler14201; Mon, 16 Oct 2000 19:18:10 GMT Received: by mail-control.mail.uu.net id QQjler26224 for mpls-outgoing; Mon, 16 Oct 2000 19:17:33 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjler26219 for ; Mon, 16 Oct 2000 19:17:17 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjler23050 for ; Mon, 16 Oct 2000 19:16:23 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjler24135 for ; Mon, 16 Oct 2000 19:16:23 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA13771; Mon, 16 Oct 2000 12:16:26 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA09700; Mon, 16 Oct 2000 15:16:21 -0400 (EDT) Message-Id: <200010161916.PAA09700@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: David Charlap cc: mpls@UU.NET Subject: Re: Query on draft-ietf-mpls-label-encaps In-reply-to: Your message of Fri, 13 Oct 2000 11:14:51 -0400. <39E726EB.80A61E9A@marconi.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Mon, 16 Oct 2000 15:16:21 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> IMO, the only good way to carry multiple L3 protocols in a single LSP David> is to wrap the packets in something that can carry the protocol ID on David> a per-packet basis. ... David> (Is there a draft for this? I don't know. If people really want to run David> multiple protocols in one tunnel, then such a draft would be useful so David> that different implementations can interoperate.) See, e.g, draft-martini-l2circuit-trans-mpls-03.txt. From owner-mpls@UU.NET Mon Oct 16 16:01:08 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15079 for ; Mon, 16 Oct 2000 16:01:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjleu03301; Mon, 16 Oct 2000 20:00:46 GMT Received: by mail-control.mail.uu.net id QQjleu29425 for mpls-outgoing; Mon, 16 Oct 2000 20:00:02 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlet29342 for ; Mon, 16 Oct 2000 19:59:59 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlet17492 for ; Mon, 16 Oct 2000 19:58:47 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlet29919 for ; Mon, 16 Oct 2000 19:58:46 GMT Received: from tellium.com ([192.168.24.187]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9GJpBk14916; Mon, 16 Oct 2000 15:51:11 -0400 (EDT) Message-ID: <39EB5DF2.D573413B@tellium.com> Date: Mon, 16 Oct 2000 15:58:42 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: curtis@avici.com, mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: <200010161605.MAA34437@workhorse.fictitious.org> <11437.001016@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I agree that bundling and flooding optimization are separate mechanisms. But if a particular bundling scheme necessarily results in multiple adjacencies, then flooding optimization would be adviced. Of course, a claim can always be made that flooding opt. is optional and orthogonal, but if it is not used in this case, I don't see its utility. Thus, IMO, draft-kompella-mpls-bundle... creates a neccesity for flooding opt.Furthermore, this bundling approach requires the support for multiple unnumbered links (bundles), (i.e., draft-kompella-mpls-unnumbered-xx.txt.) Now, the bundling scheme proposed in our draft addresses SRLG-based bundling, and it results in a single adjacency. For optical network applications, this obviates a need for any type of flooding optimization. And, there is no need to support extensions for multiple unnumbered links. In esssence, the simple device of link groups eliminates the need for two other extensions, one in routing, another in signaling. Other than this, the parameter descriptions in our draft are pretty straightforward, link type descriptions that suit SONET link types. Our bundling proposal doesn't preclude the use of separate bundle for each link group (along with support for flooding opt., and multiple unnumbered bundles). In this sense, our proposal is more flexible. I really don't see why there should be an objection to it. Regards, Bala Alex Zinin wrote: > Agree 100%. > > We have 3 techniques that are somewhat related, but yet orthogonal: > > 1. Link bundling > 2. Control channel[s] for link bundles (LMP) > 3. IGP flooding optimizations > > Link bundling allows to summarize the TE information. > LMP allows to minimize the number of adjacencies per bundle > (note that LMP will not have to be implemented on each type > of links), and flooding optimizations minimize overhead traffic > over parallel adjacencies. > > Alex. > > Monday, October 16, 2000, 9:05 AM, Curtis Villamizar wrote: > > > Bala, > > > I remember there being consensus at Pittsburgh on making the Kompella > > bundles draft a WG item. > > > Use of the flooding optitimization is one means of improving the > > efficiency of the IGP and is a separate issue. > > > Both the bundles and the flooding optitimization can stand alone. > > Neither one depends on the other. If used together they may > > complement each other but use of either one separately is possible and > > useful. > > > I don't see that any changes are required to the bundles draft to > > accommodate the flooding optitimization. If changes are required, > > please point them out. > > > Curtis -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Mon Oct 16 16:29:15 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15563 for ; Mon, 16 Oct 2000 16:29:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlev08989; Mon, 16 Oct 2000 20:28:57 GMT Received: by mail-control.mail.uu.net id QQjlev12869 for mpls-outgoing; Mon, 16 Oct 2000 20:28:10 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlev12861 for ; Mon, 16 Oct 2000 20:28:09 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlev08994 for ; Mon, 16 Oct 2000 20:26:26 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjlev15140 for ; Mon, 16 Oct 2000 20:26:25 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Mon, 16 Oct 2000 21:25:51 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <4MC56TRY>; Mon, 16 Oct 2000 21:25:43 +0100 Message-ID: To: EGray@zaffire.com, akyol@pluris.com, erosen@cisco.com Cc: mpls@UU.NET Subject: RE: bug in draft-ietf-mpls-label-encaps-08 Date: Mon, 16 Oct 2000 21:25:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric Gray wrote (snipped): > There is always a brute force negotiation > mechanism: the upstream LSR that does not support > PHP can simply refuse to do so - perhaps sending > an appropriate error message. The procedure for > this is spelled out in section 4.1.1.2 of RSVP-TE > NH=> I can think of one other brute force mechanism........PHP is not allowed. This also addresses this architectural conundrum: Q - when is a trail not a trail? A - when PHP is used. I have yet to hear some killer reason why PHP is so useful that we must have it (other than the expedient 2 label look-up issue), but I can certainly see some problems with it, eg where to site OAM functions to detect defects and take consequent actions (eg send FDI/BDI and client/server adapatation of FDI between nested LSPs), fix end-point for restoration, where to set avial/QoS registers, etc. All these functions need to know where the trail termination point is and hence where the appropriate functional processing is located. To have an unclear datum for the trail termination function is architecturally not acceptable. In the mpls-arch ID it says (in section 3.16) 'From an architectural perspective, this [ie PHP] is perfectly appropriate.' I fundamentally disagree with this statement *from an architectural perspective*. One cannot have LSP OH being arbitrarily assigned for processing at different points - irespective of whether one agrees that the assigned OH is appropriate/sufficient. And this is clearly demonstated by the following passage from Yakov's textbook (p 133) on MPLS that explains (I assume) the initial rationale for these special labels: "The explicit null labels are used in cases where a label encapsulation is needed but no valid label is required. This might be done, for example, to retain the Exp fields for QoS purposes on the last hop of an LSP, even though no label is required by the last hop." neil From owner-mpls@UU.NET Mon Oct 16 17:10:27 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16352 for ; Mon, 16 Oct 2000 17:10:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjley15609; Mon, 16 Oct 2000 21:09:57 GMT Received: by mail-control.mail.uu.net id QQjley28612 for mpls-outgoing; Mon, 16 Oct 2000 21:09:15 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjley28597 for ; Mon, 16 Oct 2000 21:09:11 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjley04312 for ; Mon, 16 Oct 2000 21:08:46 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjley16675 for ; Mon, 16 Oct 2000 21:08:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA11133 for mpls@uu.net; Mon, 16 Oct 2000 17:08:44 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjley28416 for ; Mon, 16 Oct 2000 21:08:25 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjley01785 for ; Mon, 16 Oct 2000 21:07:42 GMT Received: from omega.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjley21862 for ; Mon, 16 Oct 2000 21:07:38 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA15027; Mon, 16 Oct 2000 14:07:22 -0700 (PDT) Message-Id: <200010162107.OAA15027@omega.cisco.com> To: Bala Rajagopalan cc: Alex Zinin , curtis@avici.com, mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh In-reply-to: Your message of "Mon, 16 Oct 2000 15:58:42 EDT." <39EB5DF2.D573413B@tellium.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15025.971730442.1@cisco.com> Date: Mon, 16 Oct 2000 14:07:22 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Bala, > I agree that bundling and flooding optimization are separate > mechanisms. But if a particular bundling scheme necessarily results in > multiple adjacencies, then flooding optimization would be adviced. Of > course, a claim can always be made that flooding opt. is optional and > orthogonal, but if it is not used in this case, I don't see its utility. > Thus, IMO, draft-kompella-mpls-bundle... creates a neccesity > for flooding opt.Furthermore, this bundling approach > requires the support for multiple unnumbered links (bundles), > (i.e., draft-kompella-mpls-unnumbered-xx.txt.) draft-kompella-mpls-bundle does *not* require multiple adjacencies. With draft-kompella-mpls-bundle one *may* create multiple adjacencies if one doesn't want to aggregate information about SRLGs and/or administrative constraints (affinities), or different TE metric. > Now, the bundling scheme proposed in our draft addresses > SRLG-based bundling, and it results in a single adjacency. Your proposal does *not* guarantees only a single adjacency, as if different component links have different administrative constraints (affinities) and/or different TE metric, and aggregation of the administrative constraints is undesirable, then with your proposal one would have to have multiple adjacencies. > For optical network applications, this obviates a need for > any type of flooding optimization. And, there is no need to > support extensions for multiple unnumbered links. In esssence, > the simple device of link groups eliminates the need for two > other extensions, one in routing, another in signaling. > > Other than this, the parameter descriptions in our draft are > pretty straightforward, link type descriptions that suit SONET > link types. > > Our bundling proposal doesn't preclude the use of separate > bundle for each link group (along with support for > flooding opt., and multiple unnumbered bundles). In this sense, our > proposal is more flexible. I really don't > see why there should be an objection to it. In one sentence, because draft-kompella- can do everything that your proposal can do and more. On the other hand, your proposal can do only a subset of what draft-kompella- can do. For more details see below: 1. Your proposal doesn't have the needed information. For example, it doesn't have Max LSP b/w per priority. Another example, your proposal doesn't say how signalling could pick up a component link within a particular link group. 2. Your proposal introduces duplication information (information already present elsewhere, like Link Encoding Type, min reservable b/w, max reservable b/w (already present in draft-isis-gmpls-extensions-00.txt) 3. Your proposal results in flooding of information that doesn't change (as when change occurs within just one link group, the whole bundled link that includes all the link groups is flooded), thus creating (for no good reasons) an additional load on the routing system. 4. Your proposal doesn't eliminate the need to implement reducing flooding (via flood optimization), as we need to allow for multiple bundled links between a pair of LSRs. 5. Your proposal doesn't support bundling of non-optical links. Yakov. From owner-mpls@UU.NET Mon Oct 16 17:34:59 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16686 for ; Mon, 16 Oct 2000 17:34:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlfa02938; Mon, 16 Oct 2000 21:34:38 GMT Received: by mail-control.mail.uu.net id QQjlfa01763 for mpls-outgoing; Mon, 16 Oct 2000 21:34:16 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlfa01758 for ; Mon, 16 Oct 2000 21:34:14 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlfa19820 for ; Mon, 16 Oct 2000 21:33:03 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlfa23069 for ; Mon, 16 Oct 2000 21:33:01 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA14232 for mpls@uu.net; Mon, 16 Oct 2000 17:33:00 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlfa01659 for ; Mon, 16 Oct 2000 21:32:28 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlfa01935 for ; Mon, 16 Oct 2000 21:32:23 GMT Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjlfa22111 for ; Mon, 16 Oct 2000 21:32:23 GMT Received: from sj-dial-1-18.cisco.com (sj-dial-1-18.cisco.com [171.68.179.19]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA22962; Mon, 16 Oct 2000 14:32:11 -0700 (PDT) Date: Mon, 16 Oct 2000 14:26:14 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <19601.001016@cisco.com> To: Bala Rajagopalan CC: curtis@avici.com, mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh In-reply-To: <39EB5DF2.D573413B@tellium.com> References: <39EB5DF2.D573413B@tellium.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bala, In addition to what Yakov said, I wanted to emphasize that draft-kompella-mpls-unnum introduces a generic mechanism (not specific to link bundles) to perform announcement of and LSP signaling across unnumbered links, which is necessary regardless of whether you bundle or not. -- Alex Zinin Monday, October 16, 2000, 12:58 PM, Bala Rajagopalan wrote: > Hello, > I agree that bundling and flooding optimization are separate > mechanisms. But if a particular bundling scheme necessarily results in multiple > adjacencies, then flooding optimization would be adviced. Of course, > a claim can always be made that flooding opt. is optional and > orthogonal, but if it is not used in this case, I don't see its utility. > Thus, IMO, draft-kompella-mpls-bundle... creates a neccesity > for flooding opt.Furthermore, this bundling approach > requires the support for multiple unnumbered links (bundles), > (i.e., draft-kompella-mpls-unnumbered-xx.txt.) > Now, the bundling scheme proposed in our draft addresses > SRLG-based bundling, and it results in a single adjacency. > For optical network applications, this obviates a need for > any type of flooding optimization. And, there is no need to > support extensions for multiple unnumbered links. In esssence, > the simple device of link groups eliminates the need for two > other extensions, one in routing, another in signaling. > Other than this, the parameter descriptions in our draft are > pretty straightforward, link type descriptions that suit SONET > link types. > Our bundling proposal doesn't preclude the use of separate > bundle for each link group (along with support for > flooding opt., and multiple unnumbered bundles). In this sense, our > proposal is more flexible. I really don't > see why there should be an objection to it. > Regards, > Bala > Alex Zinin wrote: >> Agree 100%. >> >> We have 3 techniques that are somewhat related, but yet orthogonal: >> >> 1. Link bundling >> 2. Control channel[s] for link bundles (LMP) >> 3. IGP flooding optimizations >> >> Link bundling allows to summarize the TE information. >> LMP allows to minimize the number of adjacencies per bundle >> (note that LMP will not have to be implemented on each type >> of links), and flooding optimizations minimize overhead traffic >> over parallel adjacencies. >> >> Alex. >> >> Monday, October 16, 2000, 9:05 AM, Curtis Villamizar wrote: >> >> > Bala, >> >> > I remember there being consensus at Pittsburgh on making the Kompella >> > bundles draft a WG item. >> >> > Use of the flooding optitimization is one means of improving the >> > efficiency of the IGP and is a separate issue. >> >> > Both the bundles and the flooding optitimization can stand alone. >> > Neither one depends on the other. If used together they may >> > complement each other but use of either one separately is possible and >> > useful. >> >> > I don't see that any changes are required to the bundles draft to >> > accommodate the flooding optitimization. If changes are required, >> > please point them out. >> >> > Curtis > -- > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com From owner-mpls@UU.NET Mon Oct 16 17:52:43 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16853 for ; Mon, 16 Oct 2000 17:52:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlfb28807; Mon, 16 Oct 2000 21:52:16 GMT Received: by mail-control.mail.uu.net id QQjlfb03053 for mpls-outgoing; Mon, 16 Oct 2000 21:51:56 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlfb03029 for ; Mon, 16 Oct 2000 21:51:48 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlfb17551 for ; Mon, 16 Oct 2000 21:51:37 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlfb22573 for ; Mon, 16 Oct 2000 21:51:37 GMT Received: from tellium.com ([192.168.24.187]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9GLi3420629; Mon, 16 Oct 2000 17:44:03 -0400 (EDT) Message-ID: <39EB7866.E46E1D5@tellium.com> Date: Mon, 16 Oct 2000 17:51:34 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: <200010162107.OAA15027@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I'm glad we're getting into some substantive debate on this. Sorry if there is any repetetion below. Yakov Rekhter wrote: > Bala, > > > draft-kompella-mpls-bundle does *not* require multiple adjacencies. > With draft-kompella-mpls-bundle one *may* create multiple adjacencies > if one doesn't want to aggregate information about SRLGs and/or > administrative constraints (affinities), or different TE metric. I submit that you have to create multiple adjacencies if you want to bundle according to link type, SRLGs etc. If you're saying that you can ignore these and create a single bundle, I'm afraid you're completely ignoring our needs. > > > Your proposal does *not* guarantees only a single adjacency, as if > different component links have different administrative constraints > (affinities) and/or different TE metric, and aggregation of the > administrative constraints is undesirable, then with your proposal one > would have to have multiple adjacencies. Or multiple link groups within a bundle, thus maintaining a single adjacency. > > > > In one sentence, because draft-kompella- can do everything that your > proposal can do and more. On the other hand, your proposal can do only > a subset of what draft-kompella- can do. If the first sentence is really the case, we'd be glad to go with your proposal. But I'm not convinced this is true. > > > For more details see below: > > 1. Your proposal doesn't have the needed information. > For example, it doesn't have Max LSP b/w per priority. Another > example, your proposal doesn't say how signalling could pick up a > component link within a particular link group. I agree. The priority feature hasn't been a priority for us so far. But this is just a matter of adding a field in link groups (our need will be to distinguish between working and "extra" traffic only, not a range of priorities). Anyway, this doesn't argue against having link groups. As far signaling, yes, the draft omits to mention that the ERO must carry the advertised link group id for each hop. > > > 2. Your proposal introduces duplication information (information > already present elsewhere, like Link Encoding Type, min reservable b/w, > max reservable b/w (already present in draft-isis-gmpls-extensions-00.txt) I don't understand this point. Link encoding has been defined elsewhere (source referenced), and max and min are also described by the encoding type (i.e., values such as oc-48, etc) in our draft. Anyway, we're defining the usage of these parameters in bundling. > > > 3. Your proposal results in flooding of information that doesn't change > (as when change occurs within just one link group, the whole bundled > link that includes all the link groups is flooded), thus creating > (for no good reasons) an additional load on the routing system. As we note, the frequency of flooding doesn't change, whether you bundle a link group as a separate bundle or include it as part of a larger bundle. The size of announced information increases, but it doesn't seem to be a practical concern with optical link types (which are few). > > > 4. Your proposal doesn't eliminate the need to implement reducing > flooding (via flood optimization), as we need to allow for > multiple bundled links between a pair of LSRs. If you do maintain multiple bundles (by not capturing all the information in link groups), yes, flooding must be reduced. But you don't have to have multiple bundles. > > > 5. Your proposal doesn't support bundling of non-optical links. This may be the case for some features, but our draft's title is indeed "Link bundling in optical networks". In the end, I see the real need from our part as the ability to be more detailed in SRLG specification, plus a grouping of links according to link types within a bundle. If your bundling proposal can include these features, we'd be happy to endorse it. Regards, Bala > > > Yakov. -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Mon Oct 16 17:56:09 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16876 for ; Mon, 16 Oct 2000 17:56:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlfb29012; Mon, 16 Oct 2000 21:55:49 GMT Received: by mail-control.mail.uu.net id QQjlfb03510 for mpls-outgoing; Mon, 16 Oct 2000 21:55:16 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlfb03460 for ; Mon, 16 Oct 2000 21:55:02 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlfb12117 for ; Mon, 16 Oct 2000 21:54:57 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlfb27766 for ; Mon, 16 Oct 2000 21:54:57 GMT Received: from tellium.com ([192.168.24.187]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9GLlN420789; Mon, 16 Oct 2000 17:47:24 -0400 (EDT) Message-ID: <39EB792E.C96E8BEA@tellium.com> Date: Mon, 16 Oct 2000 17:54:54 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: <39EB5DF2.D573413B@tellium.com> <19601.001016@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, As with flooding opt., I agree that draft-kompella-mpls-unnum introduces a useful mechanism independent of bundling. My point was that it may become a necessity when multiple bundles are formed between neighbors and several of them are unnumbered. From the point of view of installing only the minimum set of capabilities, I don't want to implement another mechanism in my OXCs to support bundling. Regards, Bala Alex Zinin wrote: > Bala, > > In addition to what Yakov said, I wanted to emphasize that > draft-kompella-mpls-unnum introduces a generic mechanism > (not specific to link bundles) to perform announcement of > and LSP signaling across unnumbered links, which is > necessary regardless of whether you bundle or not. > > -- > Alex Zinin > > Monday, October 16, 2000, 12:58 PM, Bala Rajagopalan wrote: > > > Hello, > > > I agree that bundling and flooding optimization are separate > > mechanisms. But if a particular bundling scheme necessarily results in multiple > > adjacencies, then flooding optimization would be adviced. Of course, > > a claim can always be made that flooding opt. is optional and > > orthogonal, but if it is not used in this case, I don't see its utility. > > Thus, IMO, draft-kompella-mpls-bundle... creates a neccesity > > for flooding opt.Furthermore, this bundling approach > > requires the support for multiple unnumbered links (bundles), > > (i.e., draft-kompella-mpls-unnumbered-xx.txt.) > > > Now, the bundling scheme proposed in our draft addresses > > SRLG-based bundling, and it results in a single adjacency. > > For optical network applications, this obviates a need for > > any type of flooding optimization. And, there is no need to > > support extensions for multiple unnumbered links. In esssence, > > the simple device of link groups eliminates the need for two > > other extensions, one in routing, another in signaling. > > > Other than this, the parameter descriptions in our draft are > > pretty straightforward, link type descriptions that suit SONET > > link types. > > > Our bundling proposal doesn't preclude the use of separate > > bundle for each link group (along with support for > > flooding opt., and multiple unnumbered bundles). In this sense, our > > proposal is more flexible. I really don't > > see why there should be an objection to it. > > > Regards, > > > Bala > > > Alex Zinin wrote: > > >> Agree 100%. > >> > >> We have 3 techniques that are somewhat related, but yet orthogonal: > >> > >> 1. Link bundling > >> 2. Control channel[s] for link bundles (LMP) > >> 3. IGP flooding optimizations > >> > >> Link bundling allows to summarize the TE information. > >> LMP allows to minimize the number of adjacencies per bundle > >> (note that LMP will not have to be implemented on each type > >> of links), and flooding optimizations minimize overhead traffic > >> over parallel adjacencies. > >> > >> Alex. > >> > >> Monday, October 16, 2000, 9:05 AM, Curtis Villamizar wrote: > >> > >> > Bala, > >> > >> > I remember there being consensus at Pittsburgh on making the Kompella > >> > bundles draft a WG item. > >> > >> > Use of the flooding optitimization is one means of improving the > >> > efficiency of the IGP and is a separate issue. > >> > >> > Both the bundles and the flooding optitimization can stand alone. > >> > Neither one depends on the other. If used together they may > >> > complement each other but use of either one separately is possible and > >> > useful. > >> > >> > I don't see that any changes are required to the bundles draft to > >> > accommodate the flooding optitimization. If changes are required, > >> > please point them out. > >> > >> > Curtis > > > -- > > > Bala Rajagopalan > > Tellium, Inc. > > 2 Crescent Place > > P.O. Box 901 > > Oceanport, NJ 07757-0901 > > Tel: (732) 923-4237 > > Fax: (732) 923-9804 > > Email: braja@tellium.com -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Mon Oct 16 19:48:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17645 for ; Mon, 16 Oct 2000 19:48:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlfj07280; Mon, 16 Oct 2000 23:48:28 GMT Received: by mail-control.mail.uu.net id QQjlfj06783 for mpls-outgoing; Mon, 16 Oct 2000 23:48:09 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlfj06763 for ; Mon, 16 Oct 2000 23:47:57 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlfj23851 for ; Mon, 16 Oct 2000 23:47:49 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjlfj01977 for ; Mon, 16 Oct 2000 23:47:48 GMT Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA01187; Mon, 16 Oct 2000 16:47:19 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id <4NCAAG5J>; Mon, 16 Oct 2000 16:47:19 -0700 Message-ID: From: Puneet Agarwal To: "'Shahram Davari'" , Puneet Agarwal , "'erosen@cisco.com'" , "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: RE: bug in draft-ietf-mpls-label-encaps-08 Date: Mon, 16 Oct 2000 16:47:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, Please see comments below. >-----Original Message----- >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >Sent: Sunday, October 15, 2000 10:11 AM >To: 'Puneet Agarwal'; 'erosen@cisco.com'; 'mpls@uu.net'; >'tappan@cisco.com'; 'yakov@cisco.com' >Subject: RE: bug in draft-ietf-mpls-label-encaps-08 > > >Hi Puneet, > > >> -----Original Message----- >> From: Puneet Agarwal [mailto:puneet@pluris.com] >> Sent: Friday, October 13, 2000 9:44 PM >> To: 'erosen@cisco.com'; 'mpls@uu.net'; 'tappan@cisco.com'; >> 'yakov@cisco.com' >> Subject: bug in draft-ietf-mpls-label-encaps-08 >> >> >> Looks like "draft-ietf-mpls-label-encaps-08.txt" is inconsistent with >> hierarchical tunnels. >> >> On pg 5 it states: >> i. A value of 0 represents the "IPv4 Explicit >> NULL Label". >> This label value is only legal at the bottom of the >> label stack. It indicates that the label >> stack must be >> popped, and the forwarding of the packet >must then be >> based on the IPv4 header. >> >> My understanding was that when a LSR got a label 3 from the >> egress LSR >> during signaling, if the LSR was able to do a pop then it >> would perform a >> penultimate hop pop > >Correct. > > otherwise it would just swap the incoming >> label with >> label 0 and then the egress LSR would do the actual pop. > >This is only true if the label is the bottom most label in the stack. >Otherwise a normal label swapping will be done at penultimate >hop, and since >the ultimate (egress) LSR knows it is the egress LSR, it could pop the >swapped label. "normal label swapping" cannot be done in the case you described at the penultimate LSR as there is no legal label to swap. The penultimate LSR cannot swap label 3 (as it is forbidden) onto the packet. At the time of the LSP setup, the penultimate LSR has no knowledge if there will be an inner LSP or not - so it does not know whether to reject the PHP request (signalled via reception of label 3) during LSP setup. One way out of this conundrum would be a change to the signaling protocol(s). The egress LSR could send two labels to the penultimate LSR for the same LSP: (a) label 3 - this is to inform the penultimate LSR to do the PHP if it can pop. Alternatively, instead of sending "label 3" to ask for PHP, the signaling protocol could use other means to ask for PHP. (b) swap label - To be used in the case that penultimate LSR cannot pop. This would actually eliminate the need for labels 0 and 2 as label (b) should have all the information needed by egress LSR to determine the enscapsulated protocol type. Thanks. -Puneet > >The reason is that in case the label is the bottom most label, >the egress >LSR could possibly use the explicit null label to determine >the L3PID (i.e., >0 -> IPV4, 2-> IPV6). While this property is not needed when >the LSR is not >the terminating point of all LSPs. > >> >> However, the draft states that the label 0 is only valid at >> the bottom of >> the stack. This implies that to support hierarchical tunnels one of 2 >> conditions have to be true: >> >> (a) All LSRs supporting hierarchical tunnels, need to support >> PHP (so they >> never swap label 0 on the stack) >> >> OR >> >> (b) The "label value is only legal at the bottom of the label stack" >> constraint should be removed from the draft for label 0. > >Regards, > >-Shahram > >> > >> Since support for PHP is not a requirement for LSRs, the >> draft should be >> updated to remove the constraint for label 0, to support hierarchical >> tunnels. >> >> -Puneet >> > From owner-mpls@UU.NET Mon Oct 16 21:18:59 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18259 for ; Mon, 16 Oct 2000 21:18:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlfp29696; Tue, 17 Oct 2000 01:18:42 GMT Received: by mail-control.mail.uu.net id QQjlfp05316 for mpls-outgoing; Tue, 17 Oct 2000 01:18:06 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlfp05307 for ; Tue, 17 Oct 2000 01:17:59 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlfp18189 for ; Tue, 17 Oct 2000 01:15:55 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlfp07458 for ; Tue, 17 Oct 2000 01:15:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA02979 for mpls@uu.net; Mon, 16 Oct 2000 21:15:53 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlfp05025 for ; Tue, 17 Oct 2000 01:15:18 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlfo02394 for ; Tue, 17 Oct 2000 01:14:18 GMT Received: from viva.vivacenet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: w005.z208036016.sjc-ca.dsl.cnc.net [208.36.16.5]) id QQjlfo05434 for ; Tue, 17 Oct 2000 01:14:16 GMT Received: from AMALIS.vivacenetworks.com [10.2.1.96] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id A7F3C650460; Mon, 16 Oct 2000 18:14:27 -0700 Message-Id: <4.3.2.7.2.20001016204541.02d51338@viva.vivacenet.com> X-Sender: Andy.Malis@10.2.0.5 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 16 Oct 2000 21:14:09 -0400 To: kireeti@juniper.net From: "Andrew G. Malis" Subject: draft-kompella-mpls-l2vpn-00.txt Cc: Andy.Malis@vivacenetworks.com, mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, Given that there is little application difference between your draft and draft-martini-l2circuit-trans-mpls-03.txt, I'm curious why you didn't just build upon it rather than start from scratch. Certainly draft-martini-... didn't go as far as you did regarding on the procedures for building sets of L2 connections into VPNs, but it has much more detail on the basics, including encapsulation, label stacking, and LDP/RSVP-TE interactions. Some things are also missing from your draft. draft-martini... handled some cases that you haven't included, such as the need in some cases to include a L2 length field. It also includes how to signal the association of L2 identifiers, such as DLCIs, VPI/VCIs, etc, with particular LSPs, and the mechanics of such an association weren't immediately obvious in your draft other than handwaving. Finally, it's important to include the details on how to interface to the appropriate L2 status signaling, such as FR LMI/PVC status signaling, and ATM OAM. I didn't see that in your draft at all. I noticed at least one obvious bug in your spec - for FR, you completely strip out the DLCI octets. However, there is not only address information in those octets, but the C/R, DE, BECN, and FECN bits. FR standards require that these be transported unchanged through a network. Dropping C/R in particular will break FRADs and other non-IP FR applications. I highly suggest that you give draft-martini-.... another look. I for one would be happy to work with you on including what's already been specified there in your own draft, either by reference or by inclusion. There's no reason to reinvent the wheel. Thanks, Andy ________________________________________________________________________ Andrew G. Malis Andy.Malis@vivacenetworks.com phone:408-383-7223 Vivace Networks/2730 Orchard Parkway/San Jose, CA 95134/fax:408-904-4748 http://www.vivacenetworks.com From owner-mpls@UU.NET Mon Oct 16 22:28:21 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19590 for ; Mon, 16 Oct 2000 22:28:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlft11694; Tue, 17 Oct 2000 02:27:41 GMT Received: by mail-control.mail.uu.net id QQjlft22164 for mpls-outgoing; Tue, 17 Oct 2000 02:27:23 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlft22150 for ; Tue, 17 Oct 2000 02:27:21 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlft20328 for ; Tue, 17 Oct 2000 02:26:36 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjlft27341 for ; Tue, 17 Oct 2000 02:26:35 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA26040; Mon, 16 Oct 2000 19:26:30 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id TAA06448; Mon, 16 Oct 2000 19:26:30 -0700 (PDT) Date: Mon, 16 Oct 2000 19:26:30 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010170226.TAA06448@kummer.juniper.net> To: braja@tellium.com, yakov@cisco.com Subject: Re: Draft Minutes from Pittsburgh Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Bala, > Yakov Rekhter wrote: > > > Bala, > > > > > > draft-kompella-mpls-bundle does *not* require multiple adjacencies. > > With draft-kompella-mpls-bundle one *may* create multiple adjacencies > > if one doesn't want to aggregate information about SRLGs and/or > > administrative constraints (affinities), or different TE metric. > > I submit that you have to create multiple adjacencies if you want > to bundle according to link type, SRLGs etc. If you're saying that > you can ignore these and create a single bundle, I'm afraid you're > completely ignoring our needs. Let's take this in two steps: draft-kompella- does not *require* multiple adjacencies. It's a choice the user makes. If they want a single bundle with mixed link types and SRLGs, they can. Otherwise they can create a bundle for each link type and SRLG set. If the user decides to create multiple bundles, they may choose to do flooding optimization also. This is recommended, not required. In fact, depending on how you implement bundling and control channels, flood optimization might not even be necessary. With your proposal: 1) a user *must* have multiple link groups, even if they don't care about separate link types or SRLGs. 2) if a single link group changes, the entire bundle must be readvertised. This is as bad as flooding all the multiple bundles. However, the design of link groups offers no scope for optimization analogous to flooding optimization. > > Your proposal does *not* guarantees only a single adjacency, as if > > different component links have different administrative constraints > > (affinities) and/or different TE metric, and aggregation of the > > administrative constraints is undesirable, then with your proposal one > > would have to have multiple adjacencies. > > Or multiple link groups within a bundle, thus maintaining a single > adjacency. You missed Yakov's point: if ports 1-10 have metric 12, ports 11-20 have metric 15, ports 21-30 have metric 18, you need three bundles. These cannot be link groups within a bundle, as link groups share the metric of the bundle. Same with affinities. > > In one sentence, because draft-kompella- can do everything that your > > proposal can do and more. On the other hand, your proposal can do only > > a subset of what draft-kompella- can do. > > If the first sentence is really the case, we'd be glad to go with your > proposal. But I'm not convinced this is true. However, in all of the following, the only thing that you say that your draft has that ours doesn't is: > In the end, I see the real need from our part as the ability to > be more detailed in SRLG specification, plus a grouping of links > according to link types within a bundle. If your bundling proposal can > include these features, we'd be happy to endorse it. There is nothing in draft-kompella- that precludes bundling just the links that share SRLG sets or link types or whatever. So, this draft is clearly a superset of draft-rs-. The only (non)issue is flooding. On the other hand, draft-rs- introduces a new mechanism that adds no value, has the downside that the flooded information is potentially much greater (without recourse to optimization), and in the end does not remove the need for multiple parallel bundles between a pair of LSRs (OXCs). Furthermore, draft-rs- is specific to optical links, whereas draft-kompella- is more general purpose; and while this may be your stated goal, a more general solution is clearly preferable to a more specific one. Kireeti. From owner-mpls@UU.NET Tue Oct 17 00:15:22 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21758 for ; Tue, 17 Oct 2000 00:15:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlga18457; Tue, 17 Oct 2000 04:14:52 GMT Received: by mail-control.mail.uu.net id QQjlga23088 for mpls-outgoing; Tue, 17 Oct 2000 04:14:24 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlga23083 for ; Tue, 17 Oct 2000 04:14:22 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlga15073 for ; Tue, 17 Oct 2000 04:13:37 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjlga16860 for ; Tue, 17 Oct 2000 04:13:36 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id VAA02245; Mon, 16 Oct 2000 21:13:36 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id VAA06635; Mon, 16 Oct 2000 21:13:36 -0700 (PDT) Date: Mon, 16 Oct 2000 21:13:36 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010170413.VAA06635@kummer.juniper.net> To: Andy.Malis@vivacenetworks.com, kireeti@juniper.net Subject: Re: draft-kompella-mpls-l2vpn-00.txt Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Andy, > Given that there is little application difference between your draft and > draft-martini-l2circuit-trans-mpls-03.txt, I'm curious why you didn't just > build upon it rather than start from scratch. Certainly draft-martini-... > didn't go as far as you did regarding on the procedures for building sets > of L2 connections into VPNs, but it has much more detail on the basics, > including encapsulation, label stacking, and LDP/RSVP-TE interactions. Actually, you might be missing some history, especially if you are under the impression that draft-martini predates draft-kompella-... Yes, draft-martini does predate draft-kompella. However, the notion of FR/ATM transport over MPLS has been _shipping_ in certain routers for nearly two years now. The notion of label stacking for such transport has been discussed internally for over a year, and communicated to one of your co-authors over a year ago ... which is not to say that they didn't think of it themselves, or that yet others didn't. Finally, draft-kompella was discussed with one of your co-authors almost two months ago; and at the time we suggested merging. The co-author had reservations. You should ask him for more background. Note that the main point of draft-kompella is not simply transport of layer 2 frames, but simplifying the configuration needed for such a scheme. Our approach is so much simpler from a configuration point of view: if there are n "sites" that want FR connections, you need not configure (n-1) separate connections at each PE, a single statement suffices. Your co-author's argument was that in his case, n was small (2 or 3) which negated the advantages of draft-kompella. However, we have several customers who like this approach, and for whom n >> 1. Further note that encapsulation and label stacking are covered briefly in section 4.4; this section will be expanded and more details supplied in a later version. > Some things are also missing from your draft. draft-martini... handled > some cases that you haven't included, such as the need in some cases to > include a L2 length field. We didn't see a need for this. However, we are always open to input. > It also includes how to signal the association > of L2 identifiers, such as DLCIs, VPI/VCIs, etc, with particular LSPs, and > the mechanics of such an association weren't immediately obvious in your > draft other than handwaving. You may call a fairly detailed algorithm and examples "handwaving". That's your prerogative. However, several folks have both read and understood the method, to the extent of pointing out typos and offering improvements. If you have specific questions about the algorithm in section 4.3.1, please let us know, and we'll be happy to provide more details or explanations. > Finally, it's important to include the > details on how to interface to the appropriate L2 status signaling, such as > FR LMI/PVC status signaling, and ATM OAM. I didn't see that in your draft > at all. You haven't read carefully, if you say that this isn't there "at all". I agree that there isn't a lot of detail; there will be more in a future version. Meanwhile, see end of section 4.2; step 7 of the algorithm of section 4.3.1; and the following paragraph. > I noticed at least one obvious bug in your spec - for FR, you completely > strip out the DLCI octets. However, there is not only address information > in those octets, but the C/R, DE, BECN, and FECN bits. FR standards > require that these be transported unchanged through a network. Dropping > C/R in particular will break FRADs and other non-IP FR applications. Perhaps. We do this in our current implementation, and this is deployed and works very well, and we have seen no complaints. If this is an issue, we will work to resolve it. I am no Frame Relay expert while you certainly are, so I appreciate your comments. In particular, DE is under consideration; FECN and BECN are also being considered. However, the point of stripping/switching the DLCI is very important: independence in DLCI numbering at both ends of the circuit. This is of crucial importance to several of our customers, especially in a VPN environment. If C/R, DE, BECN, and FECN bits must be preserved, we will carry them; but switching the DLCI is a must. > I highly suggest that you give draft-martini-.... another look. I for one > would be happy to work with you on including what's already been specified > there in your own draft, either by reference or by inclusion. There's no > reason to reinvent the wheel. Like I said, talk to your co-authors and get a better understanding of the history of this topic. We think draft-kompella is a more complete solution; your opinion may differ. We'll let the appropriate WG decide; hopefully, customers (service providers) will provide guidance as well. Kireeti. From owner-mpls@UU.NET Tue Oct 17 02:34:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05335 for ; Tue, 17 Oct 2000 02:34:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlgk05498; Tue, 17 Oct 2000 06:34:03 GMT Received: by mail-control.mail.uu.net id QQjlgk26876 for mpls-outgoing; Tue, 17 Oct 2000 06:33:44 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlgk26865 for ; Tue, 17 Oct 2000 06:33:38 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlgk27638 for ; Tue, 17 Oct 2000 06:33:13 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjlgk12993 for ; Tue, 17 Oct 2000 06:33:10 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 17 Oct 2000 12:06:01 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA32354 for ; Tue, 17 Oct 2000 11:51:07 +0530 Reply-To: From: "Manikantan S" To: Subject: clarification in draft-ietf-mpls-ldp-mib-07.txt Date: Tue, 17 Oct 2000 11:58:02 +0530 Message-Id: <000101c03803$6755afa0$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello I have the following doubt in . Can someone please clarify me. Thanks. 1) mplsLdpEntityTable provides support for the creation of an LDP entity at an LSR. In MplsLdpEntityEntry there exists MIB objects for configuring a Targeted peer associated with the LDP entity. My understanding/assumption was that a LDP Entity can have one or more Targeted peers. Suppose if the LDP entity has more than one Targeted peer, how this be configured? Should a new LDP entity be created for each Targeted Peer that is accessible from an LSR? 2) The second paragraph - (reproduced below ) in section 3.7.1 is incomplete and hence bit confusing. --------- The 'mplsLdpEntityFailedInitSessionTrapEnable' object is used to enable or disable the sending of the If enabled, then this trap is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ---> not clear sent when the 'mplsLdpEntityFailedInitSessionThreshold' is exceeded. This notification should indicate to the operator that there may be a misconfigured mplsLdpEntityEntry because the session associated with this Entity is not being established, and the Entity keeps trying to establish the session. A side effect of this situation is that a row in the mplsLdpSessionTable may not be reaching the operational state as indicated by the ^^^^^^^^^^^^^ ---> Sentence not ended. ------ thanks in advance with best regards mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com ----------------------------------------- From owner-mpls@UU.NET Tue Oct 17 10:06:35 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12272 for ; Tue, 17 Oct 2000 10:06:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlho20581; Tue, 17 Oct 2000 14:05:50 GMT Received: by mail-control.mail.uu.net id QQjlho00023 for mpls-outgoing; Tue, 17 Oct 2000 14:05:25 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlho00017 for ; Tue, 17 Oct 2000 14:05:23 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlho11434 for ; Tue, 17 Oct 2000 14:05:11 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjlho19637 for ; Tue, 17 Oct 2000 14:05:11 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA28293 for ; Tue, 17 Oct 2000 10:05:11 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA28288; Tue, 17 Oct 2000 10:05:10 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA08645; Tue, 17 Oct 2000 10:05:07 -0400 (EDT) Message-ID: <39EC5C93.798B3E42@lucent.com> Date: Tue, 17 Oct 2000 10:05:07 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: braja@tellium.com, yakov@cisco.com, mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: <200010170226.TAA06448@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Our definition for bundle (it's been there for years without being exposed, sorry for the delay): "A logical link or bundle is defined as a collection of physical links (link connections) that share the same attributes (physical attributes and logical attributes) between two adjacent network elements. Link connections with a bundle are equivalent for routing purposes. However, the notion of equivalence is not fixed. The purpose is to balance network operation performance and control plane scalability. The granularity of bundling can range from physical tributary to node and even to AS." Two key purposes for bundling: 1)flooding optimization 2)path selection (the result of path selection is in bundle level) Neighbors may need multiple adjacencies (not necessary). For example, two OXCs have 20 OC48 links and 30 OC192 links between. They may be assigned as two bundles. Explicit routing should decide which bundle to choose. Again, bundle has granularity issue. The control of the granularity is up to service provider. Thanks, Yangguang Kireeti Kompella wrote: > > Hi Bala, > > > Yakov Rekhter wrote: > > > > > Bala, > > > > > > > > > draft-kompella-mpls-bundle does *not* require multiple adjacencies. > > > With draft-kompella-mpls-bundle one *may* create multiple adjacencies > > > if one doesn't want to aggregate information about SRLGs and/or > > > administrative constraints (affinities), or different TE metric. > > > > I submit that you have to create multiple adjacencies if you want > > to bundle according to link type, SRLGs etc. If you're saying that > > you can ignore these and create a single bundle, I'm afraid you're > > completely ignoring our needs. > > Let's take this in two steps: draft-kompella- does not *require* > multiple adjacencies. It's a choice the user makes. If they want > a single bundle with mixed link types and SRLGs, they can. Otherwise > they can create a bundle for each link type and SRLG set. > > If the user decides to create multiple bundles, they may choose to do > flooding optimization also. This is recommended, not required. In > fact, depending on how you implement bundling and control channels, > flood optimization might not even be necessary. > > With your proposal: > 1) a user *must* have multiple link groups, even if they don't care > about separate link types or SRLGs. > 2) if a single link group changes, the entire bundle must be > readvertised. This is as bad as flooding all the multiple bundles. > However, the design of link groups offers no scope for optimization > analogous to flooding optimization. > > > > Your proposal does *not* guarantees only a single adjacency, as if > > > different component links have different administrative constraints > > > (affinities) and/or different TE metric, and aggregation of the > > > administrative constraints is undesirable, then with your proposal one > > > would have to have multiple adjacencies. > > > > Or multiple link groups within a bundle, thus maintaining a single > > adjacency. > > You missed Yakov's point: if ports 1-10 have metric 12, ports 11-20 > have metric 15, ports 21-30 have metric 18, you need three bundles. > These cannot be link groups within a bundle, as link groups share the > metric of the bundle. Same with affinities. > > > > In one sentence, because draft-kompella- can do everything that your > > > proposal can do and more. On the other hand, your proposal can do only > > > a subset of what draft-kompella- can do. > > > > If the first sentence is really the case, we'd be glad to go with your > > proposal. But I'm not convinced this is true. > > However, in all of the following, the only thing that you say that > your draft has that ours doesn't is: > > > In the end, I see the real need from our part as the ability to > > be more detailed in SRLG specification, plus a grouping of links > > according to link types within a bundle. If your bundling proposal can > > include these features, we'd be happy to endorse it. > > There is nothing in draft-kompella- that precludes bundling just > the links that share SRLG sets or link types or whatever. So, this > draft is clearly a superset of draft-rs-. The only (non)issue is > flooding. > > On the other hand, draft-rs- introduces a new mechanism that adds no > value, has the downside that the flooded information is potentially > much greater (without recourse to optimization), and in the end does > not remove the need for multiple parallel bundles between a pair of > LSRs (OXCs). > > Furthermore, draft-rs- is specific to optical links, whereas > draft-kompella- is more general purpose; and while this may be your > stated goal, a more general solution is clearly preferable to a more > specific one. > > Kireeti. From owner-mpls@UU.NET Tue Oct 17 10:20:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12589 for ; Tue, 17 Oct 2000 10:20:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlhp09935; Tue, 17 Oct 2000 14:19:41 GMT Received: by mail-control.mail.uu.net id QQjlhp01435 for mpls-outgoing; Tue, 17 Oct 2000 14:19:00 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlhp01425 for ; Tue, 17 Oct 2000 14:18:54 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlhp10989 for ; Tue, 17 Oct 2000 14:18:26 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlhp08082 for ; Tue, 17 Oct 2000 14:18:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA16734 for mpls@uu.net; Tue, 17 Oct 2000 10:18:24 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlhp01350 for ; Tue, 17 Oct 2000 14:17:38 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlhp10134 for ; Tue, 17 Oct 2000 14:16:55 GMT Received: from brixcorp2.brixnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.91.233.5]) id QQjlhp21381 for ; Tue, 17 Oct 2000 14:16:55 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id <4YLXC433>; Tue, 17 Oct 2000 10:16:55 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AEFA2@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'manis@future.futsoft.com'" , mpls@UU.NET Subject: RE: clarification in draft-ietf-mpls-ldp-mib-07.txt Date: Tue, 17 Oct 2000 10:16:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Manikantan S [mailto:manis@future.futsoft.com] > Sent: Tuesday, October 17, 2000 2:28 AM > To: mpls@UU.NET > Subject: clarification in draft-ietf-mpls-ldp-mib-07.txt > > > Hello > > I have the following doubt in . > > Can someone please clarify me. Thanks. > > 1) mplsLdpEntityTable provides support for the creation of an > LDP entity at > an LSR. In MplsLdpEntityEntry there exists MIB objects for > configuring a > Targeted peer associated with the LDP entity. > > My understanding/assumption was that a LDP Entity can have one or more > Targeted peers. Suppose if the LDP entity has more than one > Targeted peer, > how this be configured? Should a new LDP entity be created > for each Targeted > Peer that is accessible from an LSR? > Hello, There should be an entry in the LDP entity table (mplsLdpEntityTable) for each potential Session that you want to set up. If using Targetted Hello's then that would mean one as it would be to a specific address (or essentially a specific next-hop Peer). > > 2) The second paragraph - (reproduced below ) in section > 3.7.1 is incomplete > and hence bit confusing. > > --------- > The 'mplsLdpEntityFailedInitSessionTrapEnable' object is used to > enable or disable the sending of the If enabled, then this trap is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ yes, it should have or "disable the sending of the mplsLdpEntityFailedInitSessionThresholdExceeded trap. If enabled..." > ---> > not clear > sent when the 'mplsLdpEntityFailedInitSessionThreshold' is > exceeded. > This notification should indicate to the operator that > there may be a > misconfigured mplsLdpEntityEntry because the session > associated with > this Entity is not being established, and the Entity keeps > trying to > establish the session. A side effect of this situation is > that a row > in the mplsLdpSessionTable may not be reaching the > operational state > as indicated by the > ^^^^^^^^^^^^^ ---> Sentence not ended. "mplsLdpSessionState." Sorry about that. Not sure why it didn't make it into the draft. It is correct in the nroff version but not in the text. -Thanks, Joan > ------ > > thanks in advance > with best regards > mani > ----------------------------------------- > S.Manikantan > Future Software Limited > 480-481, Anna Salai, > Nandanam, Chennai, India. > Zip (PIN CODE) : 600 035 > Phone : 91-44-4330550 > Fax : 91-44-4344157 > email : manis@future.futsoft.com > ----------------------------------------- > From owner-mpls@UU.NET Tue Oct 17 10:39:23 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13091 for ; Tue, 17 Oct 2000 10:39:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlhq26198; Tue, 17 Oct 2000 14:38:34 GMT Received: by mail-control.mail.uu.net id QQjlhq03274 for mpls-outgoing; Tue, 17 Oct 2000 14:38:16 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlhq03268 for ; Tue, 17 Oct 2000 14:38:15 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlhq23514 for ; Tue, 17 Oct 2000 14:35:45 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlhq02273 for ; Tue, 17 Oct 2000 14:35:45 GMT Received: from tellium.com ([192.168.24.185]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9HES6415205; Tue, 17 Oct 2000 10:28:07 -0400 (EDT) Message-ID: <39EC58A8.A939457@tellium.com> Date: Tue, 17 Oct 2000 09:48:24 -0400 From: Debanjan Saha X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: braja@tellium.com, yakov@cisco.com, mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: <200010170226.TAA06448@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kireeti, Kireeti Kompella wrote: > > > I submit that you have to create multiple adjacencies if you want > > to bundle according to link type, SRLGs etc. If you're saying that > > you can ignore these and create a single bundle, I'm afraid you're > > completely ignoring our needs. > > Let's take this in two steps: draft-kompella- does not *require* > multiple adjacencies. It's a choice the user makes. If they want > a single bundle with mixed link types and SRLGs, they can. Otherwise > they can create a bundle for each link type and SRLG set. The problem is that if the users create a single bundle with mixed link type and SRLGs as per draft-komplella, all information regarding the SRLGs and link types are lost. That's clearly not acceptable in our operating environment. So, it's not really a matter of choice. > If the user decides to create multiple bundles, they may choose to do > flooding optimization also. This is recommended, not required. draft-rs .. allows you to have the same effect even without flooding optimization. > In fact, depending on how you implement bundling and control channels, > flood optimization might not even be necessary. Is this going to be yet another draft :-) > With your proposal: > 1) a user *must* have multiple link groups, even if they don't care > about separate link types or SRLGs. Don't know about your application, but it is really important to capture link type and SRLG information in optical networks. > 2) if a single link group changes, the entire bundle must be > readvertised. This is as bad as flooding all the multiple bundles. > However, the design of link groups offers no scope for optimization > analogous to flooding optimization. draft-rs.. allows you to create multiple bundles, each containing one (or more) link groups. So, this statement is not accurate. > Furthermore, draft-rs- is specific to optical links, whereas > draft-kompella- is more general purpose; and while this may be your > stated goal, a more general solution is clearly preferable to a more > specific one. I will be happy to call draft-kompella a "general purpose" solution when it can adequately address the requirements for bundling optical links. If we are really seeking a more general purpose solution, what is your objection to merging the two drafts and allow for multiple link groups within a bundle. The users will still have the option to create multiple adjacencies the way dratf-kompella suggests. They will also have the option to create a single adjacency the way we prefer. Regards, Debanjan From owner-mpls@UU.NET Tue Oct 17 11:13:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13846 for ; Tue, 17 Oct 2000 11:13:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlhs24640; Tue, 17 Oct 2000 15:12:54 GMT Received: by mail-control.mail.uu.net id QQjlhs18199 for mpls-outgoing; Tue, 17 Oct 2000 15:12:17 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlhs18123 for ; Tue, 17 Oct 2000 15:12:14 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlhs14638 for ; Tue, 17 Oct 2000 15:11:23 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlhs22296 for ; Tue, 17 Oct 2000 15:11:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA25668 for mpls@uu.net; Tue, 17 Oct 2000 11:11:21 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlhs17819 for ; Tue, 17 Oct 2000 15:10:38 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlhs12507 for ; Tue, 17 Oct 2000 15:09:22 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjlhs01211 for ; Tue, 17 Oct 2000 15:09:22 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA00425; Tue, 17 Oct 2000 08:08:49 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id <46LF1MA8>; Tue, 17 Oct 2000 08:13:47 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C99F9@BBY1EXM01> From: Shahram Davari To: "'Puneet Agarwal'" , "'erosen@cisco.com'" , "'mpls@uu.net'" , "'tappan@cisco.com'" , "'yakov@cisco.com'" Subject: RE: bug in draft-ietf-mpls-label-encaps-08 Date: Tue, 17 Oct 2000 08:13:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Puneet, As was mentioned by Arch. draft and others: "A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so." The explicit null label is not in any case a reply to implicit null label. Regards, -Shahram > -----Original Message----- > From: Puneet Agarwal [mailto:puneet@pluris.com] > Sent: Monday, October 16, 2000 7:47 PM > To: Shahram Davari; Puneet Agarwal; 'erosen@cisco.com'; 'mpls@uu.net'; > 'tappan@cisco.com'; 'yakov@cisco.com' > Subject: RE: bug in draft-ietf-mpls-label-encaps-08 > > > Hi Shahram, > > Please see comments below. > > >-----Original Message----- > >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >Sent: Sunday, October 15, 2000 10:11 AM > >To: 'Puneet Agarwal'; 'erosen@cisco.com'; 'mpls@uu.net'; > >'tappan@cisco.com'; 'yakov@cisco.com' > >Subject: RE: bug in draft-ietf-mpls-label-encaps-08 > > > > > >Hi Puneet, > > > > > >> -----Original Message----- > >> From: Puneet Agarwal [mailto:puneet@pluris.com] > >> Sent: Friday, October 13, 2000 9:44 PM > >> To: 'erosen@cisco.com'; 'mpls@uu.net'; 'tappan@cisco.com'; > >> 'yakov@cisco.com' > >> Subject: bug in draft-ietf-mpls-label-encaps-08 > >> > >> > >> Looks like "draft-ietf-mpls-label-encaps-08.txt" is > inconsistent with > >> hierarchical tunnels. > >> > >> On pg 5 it states: > >> i. A value of 0 represents the "IPv4 Explicit > >> NULL Label". > >> This label value is only legal at the > bottom of the > >> label stack. It indicates that the label > >> stack must be > >> popped, and the forwarding of the packet > >must then be > >> based on the IPv4 header. > >> > >> My understanding was that when a LSR got a label 3 from the > >> egress LSR > >> during signaling, if the LSR was able to do a pop then it > >> would perform a > >> penultimate hop pop > > > >Correct. > > > > otherwise it would just swap the incoming > >> label with > >> label 0 and then the egress LSR would do the actual pop. > > > >This is only true if the label is the bottom most label in the stack. > >Otherwise a normal label swapping will be done at penultimate > >hop, and since > >the ultimate (egress) LSR knows it is the egress LSR, it > could pop the > >swapped label. > > "normal label swapping" cannot be done in the case you described at > the penultimate LSR as there is no legal label to swap. The > penultimate > LSR cannot swap label 3 (as it is forbidden) onto the packet. > At the time of the LSP setup, the penultimate LSR has no knowledge if > there will be an inner LSP or not - so it does not know > whether to reject > the > PHP request (signalled via reception of label 3) during LSP setup. > > One way out of this conundrum would be a change to the signaling > protocol(s). > The egress LSR could send two labels to the penultimate LSR > for the same > LSP: > (a) label 3 - this is to inform the penultimate LSR to do the > PHP if it can > pop. > Alternatively, instead of sending "label 3" to ask for PHP, the > signaling > protocol could use other means to ask for PHP. > > (b) swap label - To be used in the case that penultimate LSR > cannot pop. > > This would actually eliminate the need for labels 0 and 2 as label (b) > should > have all the information needed by egress LSR to determine > the enscapsulated > protocol type. > > Thanks. > > -Puneet > > > >The reason is that in case the label is the bottom most label, > >the egress > >LSR could possibly use the explicit null label to determine > >the L3PID (i.e., > >0 -> IPV4, 2-> IPV6). While this property is not needed when > >the LSR is not > >the terminating point of all LSPs. > > > >> > >> However, the draft states that the label 0 is only valid at > >> the bottom of > >> the stack. This implies that to support hierarchical > tunnels one of 2 > >> conditions have to be true: > >> > >> (a) All LSRs supporting hierarchical tunnels, need to support > >> PHP (so they > >> never swap label 0 on the stack) > >> > >> OR > >> > >> (b) The "label value is only legal at the bottom of the > label stack" > >> constraint should be removed from the draft for label 0. > > > >Regards, > > > >-Shahram > > > >> > > > >> Since support for PHP is not a requirement for LSRs, the > >> draft should be > >> updated to remove the constraint for label 0, to support > hierarchical > >> tunnels. > >> > >> -Puneet > >> > > > From owner-mpls@UU.NET Tue Oct 17 11:47:07 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14720 for ; Tue, 17 Oct 2000 11:47:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlhv28329; Tue, 17 Oct 2000 15:46:37 GMT Received: by mail-control.mail.uu.net id QQjlhv21872 for mpls-outgoing; Tue, 17 Oct 2000 15:45:54 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlhv21833 for ; Tue, 17 Oct 2000 15:45:40 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlhv06635 for ; Tue, 17 Oct 2000 15:45:04 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlhv12358 for ; Tue, 17 Oct 2000 15:45:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA01234 for mpls@uu.net; Tue, 17 Oct 2000 11:45:02 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlhu21573 for ; Tue, 17 Oct 2000 15:44:39 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlhu04291 for ; Tue, 17 Oct 2000 15:44:05 GMT Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQjlhu10817 for ; Tue, 17 Oct 2000 15:44:04 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id e9HFhfW05082; Tue, 17 Oct 2000 18:43:41 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14828.29613.90462.178303@lohi.eng.telia.fi> Date: Tue, 17 Oct 2000 18:43:41 +0300 (EEST) To: Jesus Rodriguez Stuart Cc: "Metz, E.T." , "'GUESDON Herve FTRD/DAC/ISS'" , "'S.Matsushima'" , erosen@cisco.com, mpls@UU.NET Subject: MPLS/BGP VPNs - Bandwith Reservation In-Reply-To: <39DAAAFF.E8A8375@telefonica.com.pe> References: <59063B5B4D98D311BC0D0001FA7E45220316A4F1@l04.research.kpn.com> <39DAAAFF.E8A8375@telefonica.com.pe> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jesus Rodriguez Stuart writes: > If I have 2 PEs with 10 CEs in one of them and 20 in the other. All of CEs > belong to a same IP-VPN. How can I Reserve Bandwith between the two PEs for > this IP-VPN, also How can I reserve Bandwith for diferent class of service > (Premium, Standard) between the PEs for the IP-VPN. > The same question If we have many VPNs . my answer is to use profiles and conservative admission control instead of making explicit reservation over the core. regarding traffic classes, the packets need to be marked with appropriate diffserv code points. -- juha From owner-mpls@UU.NET Tue Oct 17 11:53:23 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14975 for ; Tue, 17 Oct 2000 11:53:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlhv07371; Tue, 17 Oct 2000 15:52:49 GMT Received: by mail-control.mail.uu.net id QQjlhv22610 for mpls-outgoing; Tue, 17 Oct 2000 15:51:59 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlhv22592 for ; Tue, 17 Oct 2000 15:51:41 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlhv18088 for ; Tue, 17 Oct 2000 15:49:52 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjlhv03217 for ; Tue, 17 Oct 2000 15:49:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA23417; Tue, 17 Oct 2000 08:49:54 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA02908; Tue, 17 Oct 2000 11:49:49 -0400 (EDT) Message-Id: <200010171549.LAA02908@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Kireeti Kompella cc: Andy.Malis@vivacenetworks.com, mpls@UU.NET Subject: Re: draft-kompella-mpls-l2vpn-00.txt In-reply-to: Your message of Mon, 16 Oct 2000 21:13:36 -0700. <200010170413.VAA06635@kummer.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 17 Oct 2000 11:49:49 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Kireeti> Actually, you might be missing some history, especially if you are Kireeti> under the impression that draft-martini predates draft-kompella-... Kireeti> Yes, draft-martini does predate draft-kompella. Well, that clears that up. Kireeti> However, the notion of FR/ATM transport over MPLS has been Kireeti> _shipping_ in certain routers for nearly two years now. The notion Kireeti> of label stacking for such transport has been discussed internally Kireeti> for over a year, and communicated to one of your co-authors over a Kireeti> year ago The basic design described in draft-martini was certainly developed earlier than that, though there's no way you could have known that. So if your point is that you are innocent of having "reinvented the wheel", I would agree; if your point is that you think you've been plagiarized, well, that is not correct. From owner-mpls@UU.NET Tue Oct 17 12:06:05 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15294 for ; Tue, 17 Oct 2000 12:06:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlhw26533; Tue, 17 Oct 2000 16:05:25 GMT Received: by mail-control.mail.uu.net id QQjlhw04439 for mpls-outgoing; Tue, 17 Oct 2000 16:05:01 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlhw04413 for ; Tue, 17 Oct 2000 16:04:48 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlhw21643 for ; Tue, 17 Oct 2000 16:03:53 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlhw12607 for ; Tue, 17 Oct 2000 16:03:53 GMT Received: from tellium.com ([192.168.24.98]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9HFuH419966; Tue, 17 Oct 2000 11:56:17 -0400 (EDT) Message-ID: <39EC7866.76B83D5E@tellium.com> Date: Tue, 17 Oct 2000 12:03:50 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: yakov@cisco.com, mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: <200010170226.TAA06448@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Kireeti Kompella wrote: > Let's take this in two steps: draft-kompella- does not *require* > multiple adjacencies. It's a choice the user makes. If they want > a single bundle with mixed link types and SRLGs, they can. Otherwise > they can create a bundle for each link type and SRLG set. If you read our draft carefully, the requirement is NOT to mix link types and SRLG information. I don't want to create multiple bundles (and hence adjacencies) doing this. The bottom line is, your proposal does not support this. The only way to do this under your proposal is to necessarily create multiple bundles, and then incur the added complexity of flooding opt. This is the point I'm trying to communicate. > > > With your proposal: > 1) a user *must* have multiple link groups, even if they don't care > about separate link types or SRLGs. > 2) if a single link group changes, the entire bundle must be > readvertised. This is as bad as flooding all the multiple bundles. > However, the design of link groups offers no scope for optimization > analogous to flooding optimization. Our proposal addresses specific requirements as outlined in the draft. So, your point (1) is of no relevance. Furthermore, (2) is a weak point. Advertising an entire bundle vs just a link group that's bundled separately doesn't change the frequency, but the size of LSAs. And, the whole idea is that I don't want to implement an OSPF flooding opt. just to support bundling. > > > > > > > Or multiple link groups within a bundle, thus maintaining a single > > adjacency. > > You missed Yakov's point: if ports 1-10 have metric 12, ports 11-20 > have metric 15, ports 21-30 have metric 18, you need three bundles. > These cannot be link groups within a bundle, as link groups share the > metric of the bundle. Same with affinities. You're generalizing too much here, beyond our requirements. In any case, if such metrics are needed, then link groups can be formed based on the metric. > > > > > However, in all of the following, the only thing that you say that > your draft has that ours doesn't is: > > > In the end, I see the real need from our part as the ability to > > be more detailed in SRLG specification, plus a grouping of links > > according to link types within a bundle. If your bundling proposal can > > include these features, we'd be happy to endorse it. But this is the point of our draft! > > > There is nothing in draft-kompella- that precludes bundling just > the links that share SRLG sets or link types or whatever. So, this > draft is clearly a superset of draft-rs-. The only (non)issue is > flooding. At the risk of being repetetious, we're not denying that you could bundle based on any criterion using draft-kompella. All we're saying is that we don't want to create multiple adjacencies doing this. It's a simple matter of adding link groups to your bundling proposal and we'll be happy. > > > > On the other hand, draft-rs- introduces a new mechanism that adds no > value, has the downside that the flooded information is potentially > much greater (without recourse to optimization), and in the end does > not remove the need for multiple parallel bundles between a pair of > LSRs (OXCs). draft-rs addresses a specific set of requirements. Whether that adds "value" is subjective, depending on what the application is. To us, your draft (+ flooding opt, multiple unnumbered link support) doesn't give the value for the amount of work involved in implementing it in the specific environment we're interested in. Your last statement about multiple bundles is not true at all in the environment described in our draft. > > > Furthermore, draft-rs- is specific to optical links, whereas > draft-kompella- is more general purpose; and while this may be your > stated goal, a more general solution is clearly preferable to a more > specific one. Preferrable to who? A solution that addresses the problem in our specific environment in a circuitous way is not very exciting for us, just because it addresses bundling in the genereal MPLS environment also. The essential idea of our draft is to describe the specific requirements in optical networks. In fact, some of the requirements you have incorporated in your draft are not important to us, and the way bandwidth is described in your proposal is not natural for our application. We're willing to put up with all this if you can add link groups as a feature. I think this is a reasonable compromise. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Tue Oct 17 12:38:52 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16091 for ; Tue, 17 Oct 2000 12:38:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlhy25839; Tue, 17 Oct 2000 16:38:18 GMT Received: by mail-control.mail.uu.net id QQjlhy08145 for mpls-outgoing; Tue, 17 Oct 2000 16:38:00 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlhy08131 for ; Tue, 17 Oct 2000 16:37:50 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlhy02107 for ; Tue, 17 Oct 2000 16:33:43 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjlhy07195 for ; Tue, 17 Oct 2000 16:33:42 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA19987; Tue, 17 Oct 2000 09:33:42 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id JAA08150; Tue, 17 Oct 2000 09:33:42 -0700 (PDT) Date: Tue, 17 Oct 2000 09:33:42 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010171633.JAA08150@kummer.juniper.net> To: erosen@cisco.com Subject: Re: draft-kompella-mpls-l2vpn-00.txt Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, > Kireeti> Actually, you might be missing some history, especially if you are > Kireeti> under the impression that draft-martini predates draft-kompella-... > Kireeti> Yes, draft-martini does predate draft-kompella. > > Well, that clears that up. :-) > Kireeti> However, the notion of FR/ATM transport over MPLS has been > Kireeti> _shipping_ in certain routers for nearly two years now. The notion > Kireeti> of label stacking for such transport has been discussed internally > Kireeti> for over a year, and communicated to one of your co-authors over a > Kireeti> year ago > > The basic design described in draft-martini was certainly developed earlier > than that, though there's no way you could have known that. That was the point I was trying to make. > So if your point is that you are innocent of having "reinvented the wheel", > I would agree; Thank you. > if your point is that you think you've been plagiarized, > well, that is not correct. Sorry if I gave that impression; I do not think I/we have been plagiarized. I'm just saying that the ideas underlying layer 2 transport (and label stacking for such) have been around a long time (for some definition of "long"), and were arrived at independently by several parties; and that we were one of those parties. Kireeti. From owner-mpls@UU.NET Tue Oct 17 12:54:02 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16619 for ; Tue, 17 Oct 2000 12:54:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlhz05671; Tue, 17 Oct 2000 16:53:33 GMT Received: by mail-control.mail.uu.net id QQjlhz09615 for mpls-outgoing; Tue, 17 Oct 2000 16:53:00 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlhz09585 for ; Tue, 17 Oct 2000 16:52:49 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlhz15552 for ; Tue, 17 Oct 2000 16:52:37 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjlhz24841 for ; Tue, 17 Oct 2000 16:52:37 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA18774 for ; Tue, 17 Oct 2000 09:52:39 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA03276 for mpls@uu.net; Tue, 17 Oct 2000 12:52:33 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlgy28213 for ; Tue, 17 Oct 2000 10:04:39 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlgy19162 for ; Tue, 17 Oct 2000 10:04:01 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f122.pav1.hotmail.com [64.4.31.122]) id QQjlgy08824 for ; Tue, 17 Oct 2000 10:04:01 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Oct 2000 03:04:00 -0700 Received: from 212.143.109.178 by pv1fd.pav1.hotmail.msn.com with HTTP; Tue, 17 Oct 2000 10:04:00 GMT X-Originating-IP: [212.143.109.178] From: "Yaron Raz" To: mpls@UU.NET Subject: MPLS over Ethernet formating Date: Tue, 17 Oct 2000 12:04:00 IST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Oct 2000 10:04:00.0626 (UTC) FILETIME=[92516D20:01C03821] Sender: owner-mpls@UU.NET Precedence: bulk As I understand, when running MPLS on top of Ethernet, the ETH frame format should be: DA, SA, Ethertype (of MPLS), shim header, L3 data. This means that the original Ethertype of a packet is lost. How can the egress LSR perform the forwarding, if it doesn't have the L3 protocol of the packets? Is there a standard way to transport the originalEthertype along the LSP? Thanks, Yaron _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Tue Oct 17 12:54:04 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16630 for ; Tue, 17 Oct 2000 12:54:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlhz20465; Tue, 17 Oct 2000 16:53:31 GMT Received: by mail-control.mail.uu.net id QQjlhz09605 for mpls-outgoing; Tue, 17 Oct 2000 16:52:58 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlhz09584 for ; Tue, 17 Oct 2000 16:52:49 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlhz15379 for ; Tue, 17 Oct 2000 16:52:33 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjlhz24738 for ; Tue, 17 Oct 2000 16:52:32 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA18685 for ; Tue, 17 Oct 2000 09:52:35 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA03272 for mpls@uu.net; Tue, 17 Oct 2000 12:52:30 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlfw06281 for ; Tue, 17 Oct 2000 03:07:22 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlfw25653 for ; Tue, 17 Oct 2000 03:07:11 GMT Received: from ms1.yeah.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.106.185.101]) id QQjlfw09450 for ; Tue, 17 Oct 2000 03:07:10 GMT Received: by ms1.yeah.net (Postfix, from userid 60001) id 262DB1CB6BCAC; Tue, 17 Oct 2000 11:07:08 +0800 (CST) MIME-Version: 1.0 Message-Id: <39EBC25C.18606@ms1> Date: Tue, 17 Oct 2000 11:07:08 +0800 (CST) From: "truename" To: weigang@makesys.com Cc: mpls@UU.NET X-Priority: 3 X-Originating-IP: [202.111.8.14] Sender: owner-mpls@UU.NET Precedence: bulk Content-Type: text/plain; charset=unknown-8bit X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQjlhz20465 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16630 Hi,sir, From the material, I can see that an LSR periodically sends LDP Targeted Hellos to a specific addressin order to engage in LDP Extended Discovery mechanism. LDP Targeted Hellos are sent as UDP packets addressed to the well-known LDP discovery port at the specific address. But now I still don't know what is the meaning "the specific address" and how "the specific address" is acquired. Can you give me your opinion? Thank you. Shichunli »¶Ó­Ê¹ÓÃÍøÒ×ÐÂÒ»´úËÑË÷ÒýÇæ http://search.163.com ÍøÒ×ÒýÇæ--Íø¾Û×ÊѶ¶¯Á¦£¡ From owner-mpls@UU.NET Tue Oct 17 13:28:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17359 for ; Tue, 17 Oct 2000 13:28:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlib14857; Tue, 17 Oct 2000 17:27:43 GMT Received: by mail-control.mail.uu.net id QQjlib23879 for mpls-outgoing; Tue, 17 Oct 2000 17:27:12 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlib23871 for ; Tue, 17 Oct 2000 17:27:09 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlib22454 for ; Tue, 17 Oct 2000 17:26:50 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjlib13094 for ; Tue, 17 Oct 2000 17:26:44 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA44836; Tue, 17 Oct 2000 13:24:56 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200010171724.NAA44836@workhorse.fictitious.org> To: Yakov Rekhter cc: "Thomas D. Nadeau" , kireeti@juniper.net, mpls@UU.NET, Mraftelis@WhiteRockNetworks.com Reply-To: curtis@avici.com Subject: Re: Interface ID in kompella-unnum-02 In-reply-to: Your message of "Thu, 05 Oct 2000 13:40:56 PDT." <200010052040.NAA04240@omega.cisco.com> Date: Tue, 17 Oct 2000 13:24:56 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200010052040.NAA04240@omega.cisco.com>, Yakov Rekhter writes: > Tom, > > [clipped...] > > > This is really not a good idea from a management perspective, > > especially since all of the MIBs I know of that manage any > > type of interface (including all of the MPLS MIBs) rely on the > > ifIndex as indexes for many tables. How does one find the interface if > > it does not correspond to the ifIndex in the Interfaces MIB? > > > > >Note that the requirements for SNMP indices are much stronger than > > >for interface indices: they need to remain stable, reusing them can > > >be an issue, etc., which is why ifIndexes tend to grow beyond 2^16. > > > > > >Note too that the interface index cannot be made bigger than 2^24; > > >this is so that the distinction between IP addresses and interface > > >indices is clear. Given that, and given the fact the SNMP ifIndexes > > >can be 32 bits, ifIndexes are ruled out as potential interface > > >indices. > > > > Personally, this seems like a flaw in the design. > > Feel free to go to the OSPF WG, and convince them to change OSPF to > address what you perceived as "a flaw in the design". > > > The type ifIndex has been around for quite a long time. I don't see > > how the ifIndex in OSPF/ISIS was allowed to use a different size while > > claiming that one could put use an ifIndex from the Interfaces MIB. > > water under the bridge. > > Yakov. Yakov, This may be a scalability or management limitation. Our routers already are designed to accommodate 560 slots (14 40 slot bays) and will support 1120 slots in the future. Each slot may have 16 ports or may have switched or channelized interfaces. [btw- yes we've tested routers with more than 40 slots but not 14 loaded bays]. We currently number composite links (tm), which is our layer 2 bundles with ifindex values over 2^16 so that we can avoid the number space used for physical interfaces. We will also number switched or channelized virtual interfaces (sub-interfaces) in this upper number space. Its nice to be able to go from bay/slot/interface to physical interface. It is also nice not to have to add an additional more dynamically allocated number space that is mapped to and from the ifindex number space just because kompella-unnum-02 decided 16 bits was plenty when it really wasn't. Code can handle this easily but from a management standpoint this is going to be a pain. We can fit into the OSPF 24 bit limit but 16 is too tight. It is not necessary to make these numbers 16 bits. Or at least I haven't seen an argument other than "these are not SNMP or OSPF ifindexes". Curtis From owner-mpls@UU.NET Tue Oct 17 13:46:47 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17694 for ; Tue, 17 Oct 2000 13:46:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlid29449; Tue, 17 Oct 2000 17:46:12 GMT Received: by mail-control.mail.uu.net id QQjlid25569 for mpls-outgoing; Tue, 17 Oct 2000 17:45:32 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlid25564 for ; Tue, 17 Oct 2000 17:45:28 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlic18912 for ; Tue, 17 Oct 2000 17:44:19 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjlic12471 for ; Tue, 17 Oct 2000 17:44:17 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA26381; Tue, 17 Oct 2000 10:44:16 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA08399; Tue, 17 Oct 2000 10:44:15 -0700 (PDT) Date: Tue, 17 Oct 2000 10:44:15 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010171744.KAA08399@kummer.juniper.net> To: braja@tellium.com, kireeti@juniper.net Subject: Re: Draft Minutes from Pittsburgh Cc: mpls@UU.NET, yakov@cisco.com Sender: owner-mpls@UU.NET Precedence: bulk Hi Bala, As the mail is getting repetitious, I will address only a few points. I would invite others to participate; so far, the argument has gone back and forth between the authors of the drafts, who are understandably biased (apart from one comment from Curtis | > 1. draft-kompella-mpls-bundling-02.txt for bundling description | > 2. draft-zinin-flood-opt-00.txt for ospf flooding optimization when | > there are multiple bundles between the same pair of nodes. | > 3. draft-kompella-mpls-unnum-01.txt for specifying component | > links in ERO | | IMHO 2 is not required therefore your more complex bundling scheme | adds litte or no value. apropos link groups (if you want the full mail, I'll post it), and a general statement of support from John Drake). > > You missed Yakov's point: if ports 1-10 have metric 12, ports 11-20 > > have metric 15, ports 21-30 have metric 18, you need three bundles. > > These cannot be link groups within a bundle, as link groups share the > > metric of the bundle. Same with affinities. > > You're generalizing too much here, beyond our requirements. In any case, if > such metrics are needed, then link groups can be formed based on the > metric. Perhaps you should read RFC 2702. TE metrics and affinities are a big part of MPLS/TE; if they are beyond your requirements, you should have a chat with service providers that have implemented MPLS/TE. > > On the other hand, draft-rs- introduces a new mechanism that adds no > > value, has the downside that the flooded information is potentially > > much greater (without recourse to optimization), and in the end does > > not remove the need for multiple parallel bundles between a pair of > > LSRs (OXCs). > > draft-rs addresses a specific set of requirements. Whether that adds > "value" is subjective, depending on what the application is. You're sidestepping the issue. The point is that "link groups" don't add value. At best, they appear to remove the need for flood optimization; however, since multiple bundles are needed anyway, this is a false notion. > To us, your > draft (+ flooding opt, multiple unnumbered link support) > doesn't give the value for the amount of work involved in implementing > it in the specific environment we're interested in. Your last statement about > multiple bundles is not true at all in the environment described in our > draft. Does your "specific environment" include other boxes from other vendors that you would interoperate with? Are the vendors of these boxes of the same opinion? It would be good to hear from them. Kireeti. From owner-mpls@UU.NET Tue Oct 17 13:59:54 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18162 for ; Tue, 17 Oct 2000 13:59:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlid08416; Tue, 17 Oct 2000 17:59:08 GMT Received: by mail-control.mail.uu.net id QQjlid26621 for mpls-outgoing; Tue, 17 Oct 2000 17:58:42 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlid26613 for ; Tue, 17 Oct 2000 17:58:35 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlid20226 for ; Tue, 17 Oct 2000 17:57:16 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjlid05424 for ; Tue, 17 Oct 2000 17:57:14 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id XAA22664; Tue, 17 Oct 2000 23:25:30 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id XAA17556; Tue, 17 Oct 2000 23:27:04 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Tue, 17 Oct 2000 23:27:04 +0530 (IST) From: Ramanjaneyulu Y T To: Yaron Raz cc: mpls@UU.NET Subject: Re: MPLS over Ethernet formating In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Egress LSR forwards packet to L3 based on last label which it pops. So last label indicate type of L3 protocol. Depending upon this label egress LSR forwards to corrsponding L3 layer. If I am wrong pls correct me. Regards Ramanjaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ------------------------------------------------------------------------------ Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@123india.com BANGALORE - 560012 | kingytr@excite.com PH: 91 - 80 - 3092622 ( HOSTEL ) | 91 - 80 - 3092658 ( HFCL LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- From owner-mpls@UU.NET Tue Oct 17 14:29:39 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18805 for ; Tue, 17 Oct 2000 14:29:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlif22091; Tue, 17 Oct 2000 18:28:58 GMT Received: by mail-control.mail.uu.net id QQjlif10540 for mpls-outgoing; Tue, 17 Oct 2000 18:28:25 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlif10449 for ; Tue, 17 Oct 2000 18:27:51 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlif13364 for ; Tue, 17 Oct 2000 18:26:52 GMT Received: from rout-LRC-01.lrc.deene.ufu.br by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: rout-lrc-01.lrc.deene.ufu.br [200.19.152.13]) id QQjlif26639 for ; Tue, 17 Oct 2000 18:26:48 GMT Received: from lrc.deene.ufu.br (200.19.148.192) by rout-LRC-01.lrc.deene.ufu.br (EMWAC SMTPRS 0.80) with SMTP id ; Tue, 17 Oct 2000 16:31:24 -0200 Message-ID: <39EC9B1F.A95FBE6E@lrc.deene.ufu.br> Date: Tue, 17 Oct 2000 16:31:59 -0200 From: Daniela Cunha X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Label Granularity Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Do you know where I can get more information about Label Granularity? Thank you very much Daniela From owner-mpls@UU.NET Tue Oct 17 14:36:18 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18930 for ; Tue, 17 Oct 2000 14:36:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlig04369; Tue, 17 Oct 2000 18:35:35 GMT Received: by mail-control.mail.uu.net id QQjlig11410 for mpls-outgoing; Tue, 17 Oct 2000 18:35:16 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlig11395 for ; Tue, 17 Oct 2000 18:35:04 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlif19365 for ; Tue, 17 Oct 2000 18:29:18 GMT Received: from cowansville.acbm.qc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjlif01030 for ; Tue, 17 Oct 2000 18:29:16 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca; Tue, 17 Oct 2000 14:29:01 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id <4GAKAX21>; Tue, 17 Oct 2000 14:29:17 -0400 Message-ID: <91E486361D4CD311B3140060089A882556A44B@hermes.hyperchip.com> From: Eyad Saheb To: "'Yaron Raz'" Cc: "'mpls@UU.NET'" Subject: RE: MPLS over Ethernet formating Date: Tue, 17 Oct 2000 14:29:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03868.2728E680" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03868.2728E680 Content-Type: text/plain; charset="iso-8859-1" From my understanding, the L3 protocol should/could be inferred from the last label (or by configuration in the router ex. always assume L3 to be IP). For example, a label value of 0 represents IPv4, 2 represents IPv6, etc... -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yaron Raz Sent: Tuesday, October 17, 2000 8:04 AM To: mpls@UU.NET Subject: MPLS over Ethernet formating As I understand, when running MPLS on top of Ethernet, the ETH frame format should be: DA, SA, Ethertype (of MPLS), shim header, L3 data. This means that the original Ethertype of a packet is lost. How can the egress LSR perform the forwarding, if it doesn't have the L3 protocol of the packets? Is there a standard way to transport the originalEthertype along the LSP? Thanks, Yaron _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. ------_=_NextPart_001_01C03868.2728E680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS over Ethernet formating

From my understanding, the L3 protocol should/could = be inferred from the last label (or by configuration in the router ex. = always assume L3 to be IP).  For example, a label value of 0 = represents IPv4, 2 represents IPv6, etc...

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Yaron Raz
Sent: Tuesday, October 17, 2000 8:04 AM
To: mpls@UU.NET
Subject: MPLS over Ethernet formating


As I understand, when running MPLS on top of = Ethernet, the ETH frame format
should be:
DA, SA, Ethertype (of MPLS), shim header, L3 = data.
This means that the original Ethertype of a packet = is lost.
How can the egress LSR perform the forwarding, if it = doesn't have the L3
protocol of the packets?
Is there a standard way to transport the = originalEthertype along the LSP?

Thanks,
Yaron
_______________________________________________________________= __________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own = public profile at
http://profiles.msn.com.

------_=_NextPart_001_01C03868.2728E680-- From owner-mpls@UU.NET Tue Oct 17 14:37:57 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18974 for ; Tue, 17 Oct 2000 14:37:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlig14769; Tue, 17 Oct 2000 18:37:19 GMT Received: by mail-control.mail.uu.net id QQjlig11652 for mpls-outgoing; Tue, 17 Oct 2000 18:36:56 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlig11641 for ; Tue, 17 Oct 2000 18:36:47 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlig02430 for ; Tue, 17 Oct 2000 18:35:14 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjlig11337 for ; Tue, 17 Oct 2000 18:35:11 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id AAA22970; Wed, 18 Oct 2000 00:03:28 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id AAA17660; Wed, 18 Oct 2000 00:05:07 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Wed, 18 Oct 2000 00:05:07 +0530 (IST) From: Ramanjaneyulu Y T To: Daniela Cunha cc: mpls@UU.NET Subject: Re: Label Granularity In-Reply-To: <39EC9B1F.A95FBE6E@lrc.deene.ufu.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > Hi, > > Do you know where I can get more information about Label Granularity? pls refer MPLS framework draft and architecture draft for more details. The following are the links to drafts http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-05.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-arch-07.txt > > Thank you very much > Daniela > From owner-mpls@UU.NET Tue Oct 17 14:41:12 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19070 for ; Tue, 17 Oct 2000 14:41:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlig20671; Tue, 17 Oct 2000 18:40:50 GMT Received: by mail-control.mail.uu.net id QQjlig11905 for mpls-outgoing; Tue, 17 Oct 2000 18:40:28 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlig11898 for ; Tue, 17 Oct 2000 18:40:25 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlig02072 for ; Tue, 17 Oct 2000 18:39:38 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlig18497 for ; Tue, 17 Oct 2000 18:39:37 GMT Received: from tellium.com ([192.168.24.98]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9HIW3u28894; Tue, 17 Oct 2000 14:32:03 -0400 (EDT) Message-ID: <39EC9CE8.3EB161D2@tellium.com> Date: Tue, 17 Oct 2000 14:39:36 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh References: <200010171744.KAA08399@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti: Kireeti Kompella wrote: > Hi Bala, > > I would invite others to participate; so far, the argument has gone > back and forth between the authors of the drafts, who are > understandably biased (apart from one comment from Curtis I welcome participation from others too. I'd especially like to hear from those with an optical network perspective. > > > Perhaps you should read RFC 2702. TE metrics and affinities are a > big part of MPLS/TE; if they are beyond your requirements, you should > have a chat with service providers that have implemented MPLS/TE. Let me first say that I have had the previlege of reading RFC 2702. Presently, routing schemes being designed for optical transport networks are essentially proprietary in the manner in which paths are computed. This includes whether and how metrics and other parameters (per 2702) are assigned for links. I'm interested in knowing if you have chatted with any service provider who wants to support all the MPLS/TE capabilities as per 2702 in optical transport networks. Because, I haven't heard any such requirement. In any case, you can always form link groups based on metrics or any other tag. > > > > > On the other hand, draft-rs- introduces a new mechanism that adds no > > > value, has the downside that the flooded information is potentially > > > much greater (without recourse to optimization), and in the end does > > > not remove the need for multiple parallel bundles between a pair of > > > LSRs (OXCs). > > > > draft-rs addresses a specific set of requirements. Whether that adds > > "value" is subjective, depending on what the application is. > > You're sidestepping the issue. The point is that "link groups" don't > add value. At best, they appear to remove the need for flood > optimization; however, since multiple bundles are needed anyway, this > is a false notion. You're indeed getting repetetious here. > > > > To us, your > > draft (+ flooding opt, multiple unnumbered link support) > > doesn't give the value for the amount of work involved in implementing > > it in the specific environment we're interested in. Your last statement about > > multiple bundles is not true at all in the environment described in our > > draft. > > Does your "specific environment" include other boxes from other > vendors that you would interoperate with? Are the vendors of these > boxes of the same opinion? It would be good to hear from them. I think the issue is of relevance to other vendors in our space. Right now, I can only speak for ourselves. At this point, I don't know how many people (especially with optical orientation) have read your drafts and endorse them whole-heartedly. It'd be good hear from those too. Regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Tue Oct 17 14:55:05 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19254 for ; Tue, 17 Oct 2000 14:55:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlih10598; Tue, 17 Oct 2000 18:54:30 GMT Received: by mail-control.mail.uu.net id QQjlih13197 for mpls-outgoing; Tue, 17 Oct 2000 18:54:08 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlih13191 for ; Tue, 17 Oct 2000 18:54:02 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlih10682 for ; Tue, 17 Oct 2000 18:52:40 GMT Received: from rout-LRC-01.lrc.deene.ufu.br by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: rout-lrc-01.lrc.deene.ufu.br [200.19.152.13]) id QQjlih07986 for ; Tue, 17 Oct 2000 18:52:38 GMT Received: from lrc.deene.ufu.br (200.19.148.192) by rout-LRC-01.lrc.deene.ufu.br (EMWAC SMTPRS 0.80) with SMTP id ; Tue, 17 Oct 2000 16:57:09 -0200 Message-ID: <39ECA123.2EF1B270@lrc.deene.ufu.br> Date: Tue, 17 Oct 2000 16:57:40 -0200 From: Daniela Cunha X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Label Granularity References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Hi, I wasn't so specific on the email before. I wanna know more details about label granularity for FEC? DO you know where I can find? Thank you Daniela From owner-mpls@UU.NET Tue Oct 17 15:49:50 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20065 for ; Tue, 17 Oct 2000 15:49:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlil03303; Tue, 17 Oct 2000 19:49:27 GMT Received: by mail-control.mail.uu.net id QQjlil28675 for mpls-outgoing; Tue, 17 Oct 2000 19:48:47 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlil28668 for ; Tue, 17 Oct 2000 19:48:44 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlil00644 for ; Tue, 17 Oct 2000 19:48:04 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlil01328 for ; Tue, 17 Oct 2000 19:48:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA14321 for mpls@uu.net; Tue, 17 Oct 2000 15:48:02 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlil28598 for ; Tue, 17 Oct 2000 19:47:09 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlil03388 for ; Tue, 17 Oct 2000 19:46:20 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjlil28780 for ; Tue, 17 Oct 2000 19:46:20 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA00571; Tue, 17 Oct 2000 12:46:10 -0700 (PDT) Message-ID: <39ECAC82.2321BC0C@pluris.com> Date: Tue, 17 Oct 2000 12:46:10 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Eyad Saheb CC: "'Yaron Raz'" , "'mpls@UU.NET'" Subject: Re: MPLS over Ethernet formating References: <91E486361D4CD311B3140060089A882556A44B@hermes.hyperchip.com> Content-Type: multipart/alternative; boundary="------------5FFB26D8A8808149EF573531" Sender: owner-mpls@UU.NET Precedence: bulk --------------5FFB26D8A8808149EF573531 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For RSVP-TE, the L3 PID is carried as part of signaling. For LDP and CR-LDP, the protocol can signal a last hop label value of 0 or 2; or one can use configuration. Eyad Saheb wrote: > > > From my understanding, the L3 protocol should/could be inferred from the last > label (or by configuration in the router ex. always assume L3 to be IP). For > example, a label value of 0 represents IPv4, 2 represents IPv6, etc... > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yaron Raz > Sent: Tuesday, October 17, 2000 8:04 AM > To: mpls@UU.NET > Subject: MPLS over Ethernet formating > > As I understand, when running MPLS on top of Ethernet, the ETH frame format > should be: > DA, SA, Ethertype (of MPLS), shim header, L3 data. > This means that the original Ethertype of a packet is lost. > How can the egress LSR perform the forwarding, if it doesn't have the L3 > protocol of the packets? > Is there a standard way to transport the originalEthertype along the LSP? > > Thanks, > Yaron > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. --------------5FFB26D8A8808149EF573531 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit For RSVP-TE, the L3 PID is carried as part of signaling.

For LDP and CR-LDP, the protocol can signal a last hop label value of 0 or 2; or one can use configuration.
 

Eyad Saheb wrote:

 

From my understanding, the L3 protocol should/could be inferred from the last label (or by configuration in the router ex. always assume L3 to be IP).  For example, a label value of 0 represents IPv4, 2 represents IPv6, etc...

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Yaron Raz
Sent: Tuesday, October 17, 2000 8:04 AM
To: mpls@UU.NET
Subject: MPLS over Ethernet formating

As I understand, when running MPLS on top of Ethernet, the ETH frame format
should be:
DA, SA, Ethertype (of MPLS), shim header, L3 data.
This means that the original Ethertype of a packet is lost.
How can the egress LSR perform the forwarding, if it doesn't have the L3
protocol of the packets?
Is there a standard way to transport the originalEthertype along the LSP?

Thanks,
Yaron
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.

--------------5FFB26D8A8808149EF573531-- From owner-mpls@UU.NET Tue Oct 17 16:49:01 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20887 for ; Tue, 17 Oct 2000 16:49:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlip28492; Tue, 17 Oct 2000 20:48:44 GMT Received: by mail-control.mail.uu.net id QQjlip15858 for mpls-outgoing; Tue, 17 Oct 2000 20:48:11 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlip15828 for ; Tue, 17 Oct 2000 20:47:53 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlip22999 for ; Tue, 17 Oct 2000 20:47:53 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe27.law10.hotmail.com [64.4.14.84]) id QQjlip29903 for ; Tue, 17 Oct 2000 20:47:53 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Oct 2000 13:47:52 -0700 X-Originating-IP: [12.124.181.202] From: "Frank Hujber" To: "MPLS Group" Subject: Re: Draft Minutes From Pittsburgh Date: Tue, 17 Oct 2000 16:49:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: X-OriginalArrivalTime: 17 Oct 2000 20:47:52.0701 (UTC) FILETIME=[84D442D0:01C0387B] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bala, Kireeti, et al, My perspective is naive, but as I understand it, the current proposals require a control link to "overlay" an optical link exactly, and for the control path(s) to be associated with groups of optical links according to their characteristics (i.e. bandwidth - OC-48 vs OC-192). Some of us in the optical world, growing from the telephony (SONET/SDH) world do NOT assume that this overlay occurs. We prefer to offer the provider (in my case, my customer) to have management networks that are not the same as the transport networks. This is because in-band signaling is not yet available (though OIF is working on it) and because providers may not want to dedicate a wavelength to relatively low-speed management traffic. I'm new to this forum, and I'm sure this was explained months ago. So if this is repetitious, I apologize. Frank Hujber fhujber@hotmail.com From owner-mpls@UU.NET Tue Oct 17 17:15:27 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21449 for ; Tue, 17 Oct 2000 17:15:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjliq10550; Tue, 17 Oct 2000 21:14:57 GMT Received: by mail-control.mail.uu.net id QQjliq29335 for mpls-outgoing; Tue, 17 Oct 2000 21:14:24 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjliq29322 for ; Tue, 17 Oct 2000 21:14:15 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjliq27933 for ; Tue, 17 Oct 2000 21:13:30 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjliq04347 for ; Tue, 17 Oct 2000 21:13:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA27934 for mpls@uu.net; Tue, 17 Oct 2000 17:13:29 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjliq29233 for ; Tue, 17 Oct 2000 21:12:47 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjliq21146 for ; Tue, 17 Oct 2000 21:11:10 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjliq00955 for ; Tue, 17 Oct 2000 21:11:10 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA04499; Tue, 17 Oct 2000 14:11:02 -0700 (PDT) Message-Id: <200010172111.OAA04499@omega.cisco.com> To: curtis@avici.com cc: mpls@UU.NET, Mraftelis@WhiteRockNetworks.com Subject: Re: Interface ID in kompella-unnum-02 In-reply-to: Your message of "Tue, 17 Oct 2000 13:24:56 EDT." <200010171724.NAA44836@workhorse.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4497.971817061.1@cisco.com> Date: Tue, 17 Oct 2000 14:11:02 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Curtis, [clipped...] > Yakov, > > This may be a scalability or management limitation. Our routers > already are designed to accommodate 560 slots (14 40 slot bays) and > will support 1120 slots in the future. Each slot may have 16 ports or > may have switched or channelized interfaces. [btw- yes we've tested > routers with more than 40 slots but not 14 loaded bays]. > > We currently number composite links (tm), which is our layer 2 bundles > with ifindex values over 2^16 so that we can avoid the number space > used for physical interfaces. We will also number switched or > channelized virtual interfaces (sub-interfaces) in this upper number > space. > > Its nice to be able to go from bay/slot/interface to physical > interface. It is also nice not to have to add an additional more > dynamically allocated number space that is mapped to and from the > ifindex number space just because kompella-unnum-02 decided 16 bits > was plenty when it really wasn't. Code can handle this easily but > from a management standpoint this is going to be a pain. > > We can fit into the OSPF 24 bit limit but 16 is too tight. It is not > necessary to make these numbers 16 bits. Or at least I haven't seen > an argument other than "these are not SNMP or OSPF ifindexes". The next revision of the Internet Drafts on unnumbered interfaces, on link bundling, and on TE extensions for ISIS and OSPF will support 32 bits for both Interface ID (in unnumbered and in TE extensions) and Component Interface ID (in link bundling). Yakov. From owner-mpls@UU.NET Tue Oct 17 17:31:54 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21566 for ; Tue, 17 Oct 2000 17:31:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlis05614; Tue, 17 Oct 2000 21:31:36 GMT Received: by mail-control.mail.uu.net id QQjlis01151 for mpls-outgoing; Tue, 17 Oct 2000 21:31:05 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlis01140 for ; Tue, 17 Oct 2000 21:30:57 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlir09691 for ; Tue, 17 Oct 2000 21:29:53 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlir02475 for ; Tue, 17 Oct 2000 21:29:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA00502 for mpls@uu.net; Tue, 17 Oct 2000 17:29:51 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlir00921 for ; Tue, 17 Oct 2000 21:29:25 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlir29315 for ; Tue, 17 Oct 2000 21:26:13 GMT Received: from zrtps06s.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQjlir22948 for ; Tue, 17 Oct 2000 21:26:11 GMT Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 17 Oct 2000 17:25:52 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRBB6X>; Tue, 17 Oct 2000 17:25:51 -0400 Message-ID: From: "Dinesh Mohan" To: "'mpls@uu.net'" Subject: MPLS MIBs Related Questions Date: Tue, 17 Oct 2000 17:25:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03880.D13821A0" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03880.D13821A0 Content-Type: text/plain; charset="iso-8859-1" I have recently started looking at MPLS Mibs. I have following observations/questions on the following two MIBS: 1. MPLS TE MIB LSR1 ----> LSR2 -----> LSR4 + + ----> LSR3 ------ A tunnel from Ip(lsr1) to Ip(lsr2) might have two path instances: [Ip(lsr1), Ip(lsr2), Ip(lsr4)] and [Ip(lsr1), Ip(lsr3), Ip(lsr4)] - should mplsTunnelTable on LSR2 have an entry for tunnel instance 1 and LSR3 have an entry for tunnel instance 2? - If yes, should LSR2 and LSR3 maintain mplsTunnelHopTable and mplsTunnelARHopTable entries for these tunnel instances? - Is it possible to indicate which tunnel instance is primary, secondary and backup other than indicating different mplsTunnelInstancePriority values? - If currently Instance 1 [lsr1, lsr2, lsr4] is active [adminStatus=up & operStatus=up] and it goes down, is mplsTunnelDown expected from all three nodes lsr1, lsr2 and lsr4? - Also LSP now gets routed to Instance 2 [lsr1, lsr3, lsr4]. Does it mean all three nodes should emit mplsTunnelUp traps? - In above two scenarios, should mplsTunnelRerouted trap be genrated as well? If yes, by which LSRs? - in mplsTunnelSessionAttributes how is localProtectionAvailable value different than fastReroute option? - How is mplsTunnelLocalProtectInUse in mplsTunnelTable different than mplsTunnelSessionAttribute's LocalProtectionAvailable value? - MplsTunnelHopAddrType [ipv4, ipv6, asNumber or lspid]. This indicates the next hop be IP, AsNumber or LSP-ID but mplsOutSegmentNextHopType in mplsOutSegmentTable of MPLS LSR MIB? - mplsTunnelARHopAddrType in mplsTunnelARHopTable has Ipv4, Ipv6 and AsNumber as possible values. Why does it not include LspId value which is specified for mplsTunnelHopAddrType? - What does IsPinned value for mplsTunnelSessionAttribute indicate? ["indicates if the loosely-routed hops of this tunnel are to be pinned"] - Are there any semantics associted to mplsXCLspId in mplsXCTable i.e. on all LSRs would this ID would remain the same for cross-connection entries for this tunnel instance? If yes, how is this achieved in manually provisioned vs signalled setup of LSPs? Also does this value correspond in any way to mplsTunnelName or instance in the MPLS TE Mib? 2. MPLS FTN MIB: - FTN currently seem to support only IP over MPLS. How would it deal with ATM over MPLS? - FTN does not support mapping TOS bits in IP Header to LSPs i.e. how does it support Diffserv? - What is the difference between "redirect to LSP" vs "redirect to Tunnel" in mplsFTNAction object in mplsFTNTable? - Question related to mplsFTNMapTable: When mplsFTNMapIfIndex=0, the FTN is applicable to all interfaces. With the following scenario: if1 ----| | | LSR | if2 ----| | If ftn1, ftn2, ftn3 and ftn4 are defined in mplsFTNTable with mplsFTNIndex=1,2,3 & 4 respectively. And requirement is to apply ftn1 and ftn2 on all interfaces but apply ftn3 on if1 in order ftn1, ftn2, ftn3 while apply ftn4 on if2 in order ftn1, ftn4 and ftn2, the mplsFTNMapTable is unable to capture this. entries for mplsFTNMapTable will be: mplsFTNMapIfIndex 0 0 if1 if2 mplsFTNMapPrevIndex 0 ftn1 ftn2 ftn1 mplsFTNMapCurrIndex ftn1 ftn2 ftn3 ftn4 In this case either mplsFTNMapEntry [0, ftn1, ftn2] meets requirement for if1but not for if2? Dinesh Mohan ------_=_NextPart_001_01C03880.D13821A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS MIBs Related Questions

I have recently started looking at = MPLS Mibs. I have following observations/questions on the following two = MIBS:

1. MPLS TE MIB

 LSR1 ----> LSR2 -----> = LSR4
      = +            = ;         +
        ----> LSR3 = ------

A tunnel from Ip(lsr1) to Ip(lsr2) = might have two path instances: [Ip(lsr1), Ip(lsr2), Ip(lsr4)] and = [Ip(lsr1), Ip(lsr3), Ip(lsr4)]

- should mplsTunnelTable on LSR2 have = an entry for tunnel instance 1 and LSR3 have an entry for tunnel = instance 2?
- If yes, should LSR2 and LSR3 = maintain mplsTunnelHopTable and mplsTunnelARHopTable entries for these = tunnel instances?
- Is it possible to indicate which = tunnel instance is primary, secondary and backup other than indicating = different mplsTunnelInstancePriority values?

- If currently Instance 1 [lsr1, lsr2, = lsr4] is active [adminStatus=3Dup & operStatus=3Dup] and it goes = down, is mplsTunnelDown expected from all three nodes lsr1, lsr2 and = lsr4?

- Also LSP now gets routed to Instance = 2 [lsr1, lsr3, lsr4]. Does it mean all three nodes should emit = mplsTunnelUp traps?

- In above two scenarios, should = mplsTunnelRerouted trap be genrated as well? If yes, by which = LSRs?

- in mplsTunnelSessionAttributes how = is localProtectionAvailable value different than fastReroute = option?
- How is mplsTunnelLocalProtectInUse = in mplsTunnelTable different than mplsTunnelSessionAttribute's = LocalProtectionAvailable value?

- MplsTunnelHopAddrType [ipv4, ipv6, = asNumber or lspid]. This indicates the next hop be IP, AsNumber or = LSP-ID but
  mplsOutSegmentNextHopType in = mplsOutSegmentTable of MPLS LSR MIB?
- mplsTunnelARHopAddrType in = mplsTunnelARHopTable has Ipv4, Ipv6 and AsNumber as possible values. = Why does it not include LspId value which is specified for = mplsTunnelHopAddrType?

- What does IsPinned value for = mplsTunnelSessionAttribute indicate? ["indicates if the = loosely-routed hops of this tunnel are to be pinned"]

- Are there any semantics associted to = mplsXCLspId in mplsXCTable i.e. on all LSRs would this ID would remain = the same for cross-connection entries for this tunnel instance? If yes, = how is this achieved in manually provisioned vs signalled setup of = LSPs? Also does this value correspond in any way to mplsTunnelName or = instance in the MPLS TE Mib?


2. MPLS FTN MIB:

- FTN currently seem to support only = IP over MPLS. How would it deal with ATM over MPLS?
- FTN does not support mapping TOS = bits in IP Header to LSPs i.e. how does it support Diffserv?
- What is the difference between = "redirect to LSP" vs "redirect to Tunnel" in  = mplsFTNAction object in mplsFTNTable?
- Question related to = mplsFTNMapTable:
When mplsFTNMapIfIndex=3D0, the FTN = is applicable to all interfaces. With the following scenario:
 
  if1 = ----|          |
          | = LSR   |
  if2 = ----|          |

If ftn1, ftn2, ftn3 and ftn4 are = defined in mplsFTNTable with mplsFTNIndex=3D1,2,3 & 4 respectively. = And requirement is to apply ftn1 and ftn2 on all interfaces but apply = ftn3 on if1 in order ftn1, ftn2, ftn3 while apply ftn4 on if2 in order = ftn1, ftn4 and ftn2, the mplsFTNMapTable is unable to capture this. = entries for mplsFTNMapTable will be:

 
  = mplsFTNMapIfIndex       = 0      0     = if1   if2
  mplsFTNMapPrevIndex  = 0      ftn1  ftn2  ftn1
  mplsFTNMapCurrIndex  = ftn1   ftn2  ftn3  ftn4

In this case either mplsFTNMapEntry = [0, ftn1, ftn2] meets requirement for if1but not for if2?

Dinesh Mohan

------_=_NextPart_001_01C03880.D13821A0-- From owner-mpls@UU.NET Tue Oct 17 17:32:38 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21578 for ; Tue, 17 Oct 2000 17:32:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlis06771; Tue, 17 Oct 2000 21:32:27 GMT Received: by mail-control.mail.uu.net id QQjlis01246 for mpls-outgoing; Tue, 17 Oct 2000 21:32:07 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlis01240 for ; Tue, 17 Oct 2000 21:32:04 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlir09413 for ; Tue, 17 Oct 2000 21:29:48 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjlir07609 for ; Tue, 17 Oct 2000 21:29:47 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA17264; Tue, 17 Oct 2000 14:29:46 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id OAA09160; Tue, 17 Oct 2000 14:29:46 -0700 (PDT) Date: Tue, 17 Oct 2000 14:29:46 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010172129.OAA09160@kummer.juniper.net> To: fhujber@hotmail.com, mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh Sender: owner-mpls@UU.NET Precedence: bulk Hi Frank, > My perspective is naive, but as I understand it, the current proposals > require a control link to "overlay" an optical link exactly, and for the > control path(s) to be associated with groups of optical links according to > their characteristics (i.e. bandwidth - OC-48 vs OC-192). > Some of us in the optical world, growing from the telephony (SONET/SDH) > world do NOT assume that this overlay occurs. We prefer to offer the > provider (in my case, my customer) to have management networks that are not > the same as the transport networks. This is because in-band signaling is not > yet available (though OIF is working on it) and because providers may not > want to dedicate a wavelength to relatively low-speed management traffic. We have the notion of separate control channels and data paths in many drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. Kireeti. From owner-mpls@UU.NET Tue Oct 17 17:57:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21770 for ; Tue, 17 Oct 2000 17:57:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlit13435; Tue, 17 Oct 2000 21:56:50 GMT Received: by mail-control.mail.uu.net id QQjlit03379 for mpls-outgoing; Tue, 17 Oct 2000 21:56:19 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlit03367 for ; Tue, 17 Oct 2000 21:56:12 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlit12332 for ; Tue, 17 Oct 2000 21:55:55 GMT From: Vishal.Sharma@tellabs.com Received: from mx2.tellabs.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQjlit21715 for ; Tue, 17 Oct 2000 21:55:54 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id QAA06666; Tue, 17 Oct 2000 16:55:53 -0500 (CDT) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA20637; Tue, 17 Oct 2000 16:55:53 -0500 (CDT) X-OpenMail-Hops: 1 Date: Tue, 17 Oct 2000 16:55:52 -0500 Message-Id: Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh MIME-Version: 1.0 TO: fhujber@hotmail.com, kireeti@juniper.net, mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 17 Oct 2000 16:55:52 -0500" Sender: owner-mpls@UU.NET Precedence: bulk Keereti, I believe what Frank is talking about is not merely the separation of the control channel(s) from the data channels, but rather a more general notion of non-associated out-of-band signaling. -Vishal > -----Original Message----- > From: kireeti@juniper.net [mailto:kireeti@juniper.net] > Sent: Tuesday, October 17, 2000 5:30 PM > To: fhujber@hotmail.com; mpls@UU.NET > Subject: Re: Draft Minutes From Pittsburgh > > > Hi Frank, > > > My perspective is naive, but as I understand it, the > current proposals > > require a control link to "overlay" an optical link > exactly, and for the > > control path(s) to be associated with groups of optical > links according to > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). > > > Some of us in the optical world, growing from the telephony > (SONET/SDH) > > world do NOT assume that this overlay occurs. We prefer to offer the > > provider (in my case, my customer) to have management > networks that are not > > the same as the transport networks. This is because in-band > signaling is not > > yet available (though OIF is working on it) and because > providers may not > > want to dedicate a wavelength to relatively low-speed > management traffic. > > We have the notion of separate control channels and data paths in many > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. > > Kireeti. > From owner-mpls@UU.NET Tue Oct 17 17:58:26 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21792 for ; Tue, 17 Oct 2000 17:58:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlit15523; Tue, 17 Oct 2000 21:58:10 GMT Received: by mail-control.mail.uu.net id QQjlit03626 for mpls-outgoing; Tue, 17 Oct 2000 21:57:42 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlit03602 for ; Tue, 17 Oct 2000 21:57:39 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlit15045 for ; Tue, 17 Oct 2000 21:57:03 GMT Received: from alpha.tellium.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlit25086 for ; Tue, 17 Oct 2000 21:57:03 GMT Received: from tellium.com ([192.168.24.98]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9HLnRu09144; Tue, 17 Oct 2000 17:49:27 -0400 (EDT) Message-ID: <39ECCB2A.CCE083B4@tellium.com> Date: Tue, 17 Oct 2000 17:56:59 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: fhujber@hotmail.com, mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh References: <200010172129.OAA09160@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > Hi Frank, > > > My perspective is naive, but as I understand it, the current proposals > > require a control link to "overlay" an optical link exactly, and for the > > control path(s) to be associated with groups of optical links according to > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). > > > Some of us in the optical world, growing from the telephony (SONET/SDH) > > world do NOT assume that this overlay occurs. We prefer to offer the > > provider (in my case, my customer) to have management networks that are not > > the same as the transport networks. This is because in-band signaling is not > > yet available (though OIF is working on it) and because providers may not > > want to dedicate a wavelength to relatively low-speed management traffic. > > We have the notion of separate control channels and data paths in many > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. > This is still an overlay per link (or bundle) as described above. None of the optical IDs that I know of have dealt with a separate control network of the telephony sort (including LMP). The reason is that we're advocating an IP control plane much like that between routers. So every OXC must talk to each of its neighbors directly. Hence the overlaid control. Regards, Bala -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Tue Oct 17 18:00:15 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21813 for ; Tue, 17 Oct 2000 18:00:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjliu18643; Tue, 17 Oct 2000 22:00:06 GMT Received: by mail-control.mail.uu.net id QQjlit03845 for mpls-outgoing; Tue, 17 Oct 2000 21:59:41 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlit03834 for ; Tue, 17 Oct 2000 21:59:35 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlit19475 for ; Tue, 17 Oct 2000 21:58:55 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjlit16694 for ; Tue, 17 Oct 2000 21:58:55 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA12056 for ; Tue, 17 Oct 2000 17:58:54 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA12007; Tue, 17 Oct 2000 17:58:50 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA07144; Tue, 17 Oct 2000 17:58:48 -0400 (EDT) Message-ID: <39ECCB97.B0E3B4D8@lucent.com> Date: Tue, 17 Oct 2000 17:58:47 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: fhujber@hotmail.com, mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh References: <200010172129.OAA09160@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, One implication Frank hinted is that: For A----B, even there could be many bundles between A and B, there needs only one control channel (no need for physical channel, a TCP session is enough) between them. Bundle in circuit network is different from "interface" in IP network in the sense that a bundle can be included in one LSA, but only send to neighbor once. I hope this is agreed. Thanks, Yangguang Kireeti Kompella wrote: > > Hi Frank, > > > My perspective is naive, but as I understand it, the current proposals > > require a control link to "overlay" an optical link exactly, and for the > > control path(s) to be associated with groups of optical links according to > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). > > > Some of us in the optical world, growing from the telephony (SONET/SDH) > > world do NOT assume that this overlay occurs. We prefer to offer the > > provider (in my case, my customer) to have management networks that are not > > the same as the transport networks. This is because in-band signaling is not > > yet available (though OIF is working on it) and because providers may not > > want to dedicate a wavelength to relatively low-speed management traffic. > > We have the notion of separate control channels and data paths in many > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. > > Kireeti. From owner-mpls@UU.NET Tue Oct 17 18:05:49 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21849 for ; Tue, 17 Oct 2000 18:05:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjliu20355; Tue, 17 Oct 2000 22:05:36 GMT Received: by mail-control.mail.uu.net id QQjliu15648 for mpls-outgoing; Tue, 17 Oct 2000 22:05:02 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjliu15508 for ; Tue, 17 Oct 2000 22:04:55 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjliu02057 for ; Tue, 17 Oct 2000 22:04:18 GMT Received: from alpha.tellium.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjliu16473 for ; Tue, 17 Oct 2000 22:04:17 GMT Received: from tellium.com ([192.168.24.98]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9HLuhu09543; Tue, 17 Oct 2000 17:56:43 -0400 (EDT) Message-ID: <39ECCCDE.E56D7931@tellium.com> Date: Tue, 17 Oct 2000 18:04:14 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Yangguang Xu CC: mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh References: <200010172129.OAA09160@kummer.juniper.net> <39ECCB97.B0E3B4D8@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This is exactly what link groups accomplish, i.e., a single adjacency between OXCs with multiple link groups (or sub-bundles). Bala Yangguang Xu wrote: > Kireeti, > > One implication Frank hinted is that: > > For A----B, even there could be many bundles between A and B, there needs only > one control channel (no need for physical channel, a TCP session is enough) > between them. Bundle in circuit network is different from "interface" in IP > network in the sense that a bundle can be included in one LSA, but only send to > neighbor once. > > I hope this is agreed. > > Thanks, > > Yangguang > > Kireeti Kompella wrote: > > > > Hi Frank, > > > > > My perspective is naive, but as I understand it, the current proposals > > > require a control link to "overlay" an optical link exactly, and for the > > > control path(s) to be associated with groups of optical links according to > > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). > > > > > Some of us in the optical world, growing from the telephony (SONET/SDH) > > > world do NOT assume that this overlay occurs. We prefer to offer the > > > provider (in my case, my customer) to have management networks that are not > > > the same as the transport networks. This is because in-band signaling is not > > > yet available (though OIF is working on it) and because providers may not > > > want to dedicate a wavelength to relatively low-speed management traffic. > > > > We have the notion of separate control channels and data paths in many > > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. > > > > Kireeti. -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Tue Oct 17 18:31:21 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22065 for ; Tue, 17 Oct 2000 18:31:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjliv14543; Tue, 17 Oct 2000 22:18:15 GMT Received: by mail-control.mail.uu.net id QQjliv17700 for mpls-outgoing; Tue, 17 Oct 2000 22:17:52 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjliv17690 for ; Tue, 17 Oct 2000 22:17:44 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjliv01263 for ; Tue, 17 Oct 2000 22:16:43 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjliv12273 for ; Tue, 17 Oct 2000 22:16:43 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA23413 for ; Tue, 17 Oct 2000 18:16:42 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA23409; Tue, 17 Oct 2000 18:16:42 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA09550; Tue, 17 Oct 2000 18:16:39 -0400 (EDT) Message-ID: <39ECCFC7.808FAEF9@lucent.com> Date: Tue, 17 Oct 2000 18:16:39 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Vishal.Sharma@tellabs.com CC: fhujber@hotmail.com, kireeti@juniper.net, mpls@UU.NET Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, This general notion is correct and it is against the very basic assumption of IP network where control traffic is mixed together with data traffic. In circuit switched network, there should be no assumption about the relation of data plane topology and control plane topology at all. For two NEs to talk, you don't need a dedicated control link. You only need a TCP session for a NE pair, not only a whatever bundle. Cheers, Yangguang Vishal.Sharma@tellabs.com wrote: > > Keereti, > > I believe what Frank is talking about is not merely the separation > of the control channel(s) from the data channels, but rather a more > general notion of non-associated out-of-band signaling. > > -Vishal > > > -----Original Message----- > > From: kireeti@juniper.net [mailto:kireeti@juniper.net] > > Sent: Tuesday, October 17, 2000 5:30 PM > > To: fhujber@hotmail.com; mpls@UU.NET > > Subject: Re: Draft Minutes From Pittsburgh > > > > > > Hi Frank, > > > > > My perspective is naive, but as I understand it, the > > current proposals > > > require a control link to "overlay" an optical link > > exactly, and for the > > > control path(s) to be associated with groups of optical > > links according to > > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). > > > > > Some of us in the optical world, growing from the telephony > > (SONET/SDH) > > > world do NOT assume that this overlay occurs. We prefer to offer the > > > provider (in my case, my customer) to have management > > networks that are not > > > the same as the transport networks. This is because in-band > > signaling is not > > > yet available (though OIF is working on it) and because > > providers may not > > > want to dedicate a wavelength to relatively low-speed > > management traffic. > > > > We have the notion of separate control channels and data paths in many > > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. > > > > Kireeti. > > From owner-mpls@UU.NET Wed Oct 18 01:00:16 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29487 for ; Wed, 18 Oct 2000 01:00:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjljw19026; Wed, 18 Oct 2000 05:00:01 GMT Received: by mail-control.mail.uu.net id QQjljv06273 for mpls-outgoing; Wed, 18 Oct 2000 04:59:35 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjljv06268 for ; Wed, 18 Oct 2000 04:59:34 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjljv09926 for ; Wed, 18 Oct 2000 04:58:24 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjljv08776 for ; Wed, 18 Oct 2000 04:58:24 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id VAA05853; Tue, 17 Oct 2000 21:58:20 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id VAA10475; Tue, 17 Oct 2000 21:58:18 -0700 (PDT) Date: Tue, 17 Oct 2000 21:58:18 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010180458.VAA10475@kummer.juniper.net> To: kireeti@juniper.net, xuyg@lucent.com Subject: Re: Draft Minutes From Pittsburgh Cc: fhujber@hotmail.com, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Yangguang, > One implication Frank hinted is that: > > For A----B, even there could be many bundles between A and B, there needs only > one control channel (no need for physical channel, a TCP session is enough) > between them. Bundle in circuit network is different from "interface" in IP > network in the sense that a bundle can be included in one LSA, but only send to > neighbor once. You have a good point. In section 3.2 of the bundling document, it says that a bundle must have a control channel, but is not very clear that multiple bundles can share a control channel. We will make this clearer in the next revision. Meanwhile, let me say this explicitly: between a pair of GLSRs (i.e., LSRs, OXCs, SXCs, ...), the requirement is that there must be at least one control channel; the requirement is *not* one per bundle. Corresponding to this control channel, one routing adjacency is needed. The routing module can generate LSAs for all the bundle(s) assigned to a control channel when both the control channel adjacency is up and the bundles are up (LMP can be used to say when the bundles are up). If a bundle changes, the LSA corresponding to that bundle alone is re-flooded. This addresses the issue of flood optimization: having multiple bundles does *not* mean having multiple adjacencies, so flooding optimization is not a requirement. Kireeti. From owner-mpls@UU.NET Wed Oct 18 02:21:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12422 for ; Wed, 18 Oct 2000 02:21:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjljs08816; Wed, 18 Oct 2000 04:07:46 GMT Received: by mail-control.mail.uu.net id QQjljs03397 for mpls-outgoing; Wed, 18 Oct 2000 04:07:13 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjljs03384 for ; Wed, 18 Oct 2000 04:07:02 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjljs13820 for ; Wed, 18 Oct 2000 04:06:34 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjljs22844 for ; Wed, 18 Oct 2000 04:06:31 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 18 Oct 2000 09:38:21 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA24382; Wed, 18 Oct 2000 09:24:17 +0530 Reply-To: From: "Manikantan S" To: "'truename'" , Cc: Subject: RE: Date: Wed, 18 Oct 2000 09:31:12 +0530 Message-Id: <001701c038b8$0e8c7d80$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <39EBC25C.18606@ms1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQjljs08816 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12422 Hello Shichunli The specific address means the LSR's IP address, the LSR which is the target peer. This address can be configured by the Manager using the MIB objects "mplsLdpEntityTargetedPeer, mplsLdpEntityTargetedPeerAddrType, mplsLdpEntityTargetedPeerAddr" associated with an LdpEntity in the mplsLdpEntityTable. This Target peer address(es) can also be dynamically learnt with the local policy from OSPF or BGP. regards mani -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of truename Sent: Tuesday, 17 October 2000 8:37 AM To: weigang@makesys.com Cc: mpls@uu.net Subject: Hi,sir, From the material, I can see that an LSR periodically sends LDP Targeted Hellos to a specific addressin order to engage in LDP Extended Discovery mechanism. LDP Targeted Hellos are sent as UDP packets addressed to the well-known LDP discovery port at the specific address. But now I still don't know what is the meaning "the specific address" and how "the specific address" is acquired. Can you give me your opinion? Thank you. Shichunli »¶Ó­Ê¹ÓÃÍøÒ×ÐÂÒ»´úËÑË÷ÒýÇæ http://search.163.com ÍøÒ×ÒýÇæ--Íø¾Û×ÊѶ¶¯Á¦£¡ From owner-mpls@UU.NET Wed Oct 18 08:12:39 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17059 for ; Wed, 18 Oct 2000 08:12:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlky26519; Wed, 18 Oct 2000 12:12:22 GMT Received: by mail-control.mail.uu.net id QQjlky29790 for mpls-outgoing; Wed, 18 Oct 2000 12:11:57 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlky29773 for ; Wed, 18 Oct 2000 12:11:50 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlky12128 for ; Wed, 18 Oct 2000 12:11:36 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe8.law10.hotmail.com [64.4.14.112]) id QQjlky17695 for ; Wed, 18 Oct 2000 12:11:36 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 18 Oct 2000 05:11:35 -0700 X-Originating-IP: [24.189.146.213] From: "Frank Hujber" To: "Kireeti Kompella" , Cc: References: <200010180458.VAA10475@kummer.juniper.net> Subject: Re: Draft Minutes From Pittsburgh Date: Wed, 18 Oct 2000 07:11:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 18 Oct 2000 12:11:35.0764 (UTC) FILETIME=[8F8C8940:01C038FC] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, et al, Consider three routers as a small segment of a larger optical network, A, B, and C. A and B areOXCs and are directly connected by a DWDM with some number of lightpaths. However, their control plane connection is through C, which is a pure IP router, not an OXC. We've made the (painful) assumption that the customer/provider has such demand for his lightpaths that he does not want to sacrifice a wavelength for control. It would seem possible to manage optical links A-to-B with a LSP A-to-C-to-B as along as A and B knew their optical connectivity and C knew that it was not part of the optical path. We do regard this as a degerate case, but one that we must (here in NJ) be prepared to support. Frank Hujber fhujber@hotmail.com ----- Original Message ----- From: "Kireeti Kompella" To: ; Cc: ; Sent: Wednesday, October 18, 2000 12:58 AM Subject: Re: Draft Minutes From Pittsburgh > Hi Yangguang, > > > One implication Frank hinted is that: > > > > For A----B, even there could be many bundles between A and B, there needs only > > one control channel (no need for physical channel, a TCP session is enough) > > between them. Bundle in circuit network is different from "interface" in IP > > network in the sense that a bundle can be included in one LSA, but only send to > > neighbor once. > > You have a good point. In section 3.2 of the bundling document, it > says that a bundle must have a control channel, but is not very > clear that multiple bundles can share a control channel. We will > make this clearer in the next revision. > > Meanwhile, let me say this explicitly: between a pair of GLSRs (i.e., > LSRs, OXCs, SXCs, ...), the requirement is that there must be at > least one control channel; the requirement is *not* one per bundle. > Corresponding to this control channel, one routing adjacency is > needed. > > The routing module can generate LSAs for all the bundle(s) assigned > to a control channel when both the control channel adjacency is up > and the bundles are up (LMP can be used to say when the bundles are > up). If a bundle changes, the LSA corresponding to that bundle alone > is re-flooded. > > This addresses the issue of flood optimization: having multiple > bundles does *not* mean having multiple adjacencies, so flooding > optimization is not a requirement. > > Kireeti. > From owner-mpls@UU.NET Wed Oct 18 08:34:17 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17767 for ; Wed, 18 Oct 2000 08:34:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlla17537; Wed, 18 Oct 2000 12:33:59 GMT Received: by mail-control.mail.uu.net id QQjlla01221 for mpls-outgoing; Wed, 18 Oct 2000 12:33:37 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlla01215 for ; Wed, 18 Oct 2000 12:33:33 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlla02076 for ; Wed, 18 Oct 2000 12:32:54 GMT Received: from exchange.satyam.net.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.144.12.32]) id QQjlla23447 for ; Wed, 18 Oct 2000 12:32:51 GMT Received: from hqbng01ex01.mindtree.com ([202.144.95.250]) by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id SAA06406 for ; Wed, 18 Oct 2000 18:00:38 +0530 Received: by hqbng01ex01.mindtree.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 18:02:17 +0530 Message-ID: From: Murali Krishna Policharla To: mpls@UU.NET Subject: Re: state transition in session Initialization Date: Wed, 18 Oct 2000 18:02:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C038FF.73579629" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C038FF.73579629 Content-Type: text/plain; charset="iso-8859-1" Hi, this question is pertaining to draft can any body explain me the significance of each state ie. NON-EXISTENT, INITIALIZED, OPEREC, OPENSENT, OPERATIONAL. thanks in advance murali krishna p. ------_=_NextPart_001_01C038FF.73579629 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: state transition in session Initialization

Hi,
        this question is pertaining to draft <draft-ietf-mpls-ldp-08.txt>
    can any body = explain me the significance of each state ie. NON-EXISTENT, INITIALIZED, = OPEREC, OPENSENT, OPERATIONAL.


thanks in advance =
murali krishna = p.

------_=_NextPart_001_01C038FF.73579629-- From owner-mpls@UU.NET Wed Oct 18 08:38:00 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17916 for ; Wed, 18 Oct 2000 08:38:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlla23287; Wed, 18 Oct 2000 12:37:49 GMT Received: by mail-control.mail.uu.net id QQjlla01446 for mpls-outgoing; Wed, 18 Oct 2000 12:37:17 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlla01437 for ; Wed, 18 Oct 2000 12:37:07 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlla16956 for ; Wed, 18 Oct 2000 12:36:14 GMT Received: from exchange.satyam.net.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.144.12.32]) id QQjlla02499 for ; Wed, 18 Oct 2000 12:36:08 GMT Received: from hqbng01ex01.mindtree.com ([202.144.95.250]) by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id SAA06604 for ; Wed, 18 Oct 2000 18:03:54 +0530 Received: by hqbng01ex01.mindtree.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 18:05:33 +0530 Message-ID: From: Murali Krishna Policharla To: mpls@UU.NET Subject: question on mpls Date: Wed, 18 Oct 2000 18:05:32 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C038FF.E7F82C06" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C038FF.E7F82C06 Content-Type: text/plain; charset="iso-8859-1" Hi, i want to know how to implement in identifying an LSR as upstrem LSR or downstream LSR thanks in advance murali krishna P. ------_=_NextPart_001_01C038FF.E7F82C06 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable question on mpls

Hi,
     i want to = know how to implement in identifying an  LSR  as upstrem LSR or downstream = LSR



thanks in = advance
murali krishna = P.

------_=_NextPart_001_01C038FF.E7F82C06-- From owner-mpls@UU.NET Wed Oct 18 08:39:43 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17944 for ; Wed, 18 Oct 2000 08:39:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlla07431; Wed, 18 Oct 2000 12:37:51 GMT Received: by mail-control.mail.uu.net id QQjlla01451 for mpls-outgoing; Wed, 18 Oct 2000 12:37:21 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlla01439 for ; Wed, 18 Oct 2000 12:37:08 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlla18414 for ; Wed, 18 Oct 2000 12:36:52 GMT Received: from exchange.satyam.net.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.144.12.32]) id QQjlla12757 for ; Wed, 18 Oct 2000 12:36:49 GMT Received: from hqbng01ex01.mindtree.com ([202.144.95.250]) by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id SAA06656 for ; Wed, 18 Oct 2000 18:04:37 +0530 Received: by hqbng01ex01.mindtree.com with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 18:06:15 +0530 Message-ID: From: Murali Krishna Policharla To: mpls@UU.NET Subject: state transition diagram in session Initialization Date: Wed, 18 Oct 2000 18:06:14 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03900.00EDAACE" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03900.00EDAACE Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Murali Krishna Policharla [mailto:murali_krishna@mindtree.com] Sent: Wednesday, October 18, 2000 6:02 PM To: mpls@UU.NET Subject: Re: state transition in session Initialization Hi, this question is pertaining to draft can any body explain me the significance of each state ie. NON-EXISTENT, INITIALIZED, OPEREC, OPENSENT, OPERATIONAL. thanks in advance murali krishna p. ------_=_NextPart_001_01C03900.00EDAACE Content-Type: text/html; charset="iso-8859-1" Re: state transition in session Initialization
 
-----Original Message-----
From: Murali Krishna Policharla [mailto:murali_krishna@mindtree.com]
Sent: Wednesday, October 18, 2000 6:02 PM
To: mpls@UU.NET
Subject: Re: state transition in session Initialization

Hi,
        this question is pertaining to draft <draft-ietf-mpls-ldp-08.txt>
    can any body explain me the significance of each state ie. NON-EXISTENT, INITIALIZED, OPEREC, OPENSENT, OPERATIONAL.


thanks in advance
murali krishna p.

------_=_NextPart_001_01C03900.00EDAACE-- From owner-mpls@UU.NET Wed Oct 18 09:38:02 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19509 for ; Wed, 18 Oct 2000 09:38:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlle14195; Wed, 18 Oct 2000 13:37:28 GMT Received: by mail-control.mail.uu.net id QQjlle16565 for mpls-outgoing; Wed, 18 Oct 2000 13:36:55 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlle16558 for ; Wed, 18 Oct 2000 13:36:48 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlle29113 for ; Wed, 18 Oct 2000 13:35:04 GMT Received: from hoemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQjlle17112 for ; Wed, 18 Oct 2000 13:35:04 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA24331 for ; Wed, 18 Oct 2000 09:35:04 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA24319; Wed, 18 Oct 2000 09:35:03 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA17271; Wed, 18 Oct 2000 09:35:01 -0400 (EDT) Message-ID: <39EDA704.5D4E9E4B@lucent.com> Date: Wed, 18 Oct 2000 09:35:00 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: fhujber@hotmail.com, mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh References: <200010180458.VAA10475@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, Thanks, please see my comment below: > > Meanwhile, let me say this explicitly: between a pair of GLSRs (i.e., > LSRs, OXCs, SXCs, ...), the requirement is that there must be at > least one control channel; the requirement is *not* one per bundle. > Corresponding to this control channel, one routing adjacency is > needed. > The key point is that routing adjacency in circuit switched network data plane has nothing to do with control channels (the control plane). At least there shouldn't be any assumption about their co-existence. For each routing adjacency (in data plane), you only need a TCP session as Frank hinted. Not necessary a physical control channel. > The routing module can generate LSAs for all the bundle(s) assigned > to a control channel when both the control channel adjacency is up > and the bundles are up (LMP can be used to say when the bundles are > up). If a bundle changes, the LSA corresponding to that bundle alone > is re-flooded. > I agree your point of flooding control. BTW, I had a feeling that LMP suggest control channel for each bundle. (I read it long time ago, can't remember exactly). If this is the case, it's simply not right. For example, a OXC has 10 neighbors, between each neighbor there are 2 bundles, then do you need 20 control channels? NO! Bundle has nothing to do with control channel. > This addresses the issue of flood optimization: having multiple > bundles does *not* mean having multiple adjacencies, so flooding > optimization is not a requirement. Agree, > > Kireeti. From owner-mpls@UU.NET Wed Oct 18 10:10:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20377 for ; Wed, 18 Oct 2000 10:10:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllg24308; Wed, 18 Oct 2000 14:10:31 GMT Received: by mail-control.mail.uu.net id QQjllg00627 for mpls-outgoing; Wed, 18 Oct 2000 14:09:56 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllg00622 for ; Wed, 18 Oct 2000 14:09:53 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllg19157 for ; Wed, 18 Oct 2000 14:08:47 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjllg28486 for ; Wed, 18 Oct 2000 14:08:46 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id XAA23386; Wed, 18 Oct 2000 23:09:41 +0900 (KST) X-OpenMail-Hops: 2 Date: Wed, 18 Oct 2000 23:08:55 +0900 Message-Id: In-Reply-To: Subject: (Reply) question on mpls MIME-Version: 1.0 TO: mpls@UU.NET, murali_krishna@mindtree.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Wed, 18 Oct 2000 22:32:23 +0900" ;Modification-Date="Wed, 18 Oct 2000 23:08:51 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi murali, When ur FEC is indirectly learnt by ur routing protocol then ur LSR becomes Ingress and it will try to estalish an LSP with the egress(LER for that FEC) of the FEC When the FEC is learnt dicectly then UR LSR becomes the egress and .... take the senario ;;;; R1------R2------R3 when R2 receives a Labelequest from R1, then R2 takes R1 as Upstream peer and R3 as DownSp.....and there will be an LSP from R1 to R3 If R2 receives LblReq from R3....R3 will become upstream in this case (for an LSP from R3 to R1)...and R1 will be downstream. Hope it will help u. Seenu >Hi, > i want to know how to implement in identifying an LSR as upstrem LSR or downstream LSR > >thanks in advance >murali krishna P. From owner-mpls@UU.NET Wed Oct 18 10:44:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20955 for ; Wed, 18 Oct 2000 10:44:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlli06806; Wed, 18 Oct 2000 14:34:15 GMT Received: by mail-control.mail.uu.net id QQjlli03189 for mpls-outgoing; Wed, 18 Oct 2000 14:33:44 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlli03175 for ; Wed, 18 Oct 2000 14:33:34 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlli12630 for ; Wed, 18 Oct 2000 14:32:48 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjlli02480 for ; Wed, 18 Oct 2000 14:32:28 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id XAA15292; Wed, 18 Oct 2000 23:32:20 +0900 (KST) X-OpenMail-Hops: 2 Date: Wed, 18 Oct 2000 23:31:34 +0900 Message-Id: In-Reply-To: <39EB008D.A483017C@fnc.fujitsu.com> Subject: (Reply) label release/withdraw MIME-Version: 1.0 TO: mpls@UU.NET, Paul.Kwan@fnc.fujitsu.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Wed, 18 Oct 2000 23:14:58 +0900" ;Modification-Date="Wed, 18 Oct 2000 23:31:29 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Paul, Downstream LSR sends a Lbl withdraw msg to the upstream peer to withdraw a label for FEC. But it won't remove the mapping (label) from the switching matrix. Once it receives a LblRelease message from the upstream peer (which would have removed the label from the swithing matrix after receiving the Label withdraw message from the downstream peer) it releases the label from the switching matrix.... So.... If I am wrong pls correct me Seenu From owner-mpls@UU.NET Wed Oct 18 10:58:54 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21249 for ; Wed, 18 Oct 2000 10:58:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllj18849; Wed, 18 Oct 2000 14:58:40 GMT Received: by mail-control.mail.uu.net id QQjllj05376 for mpls-outgoing; Wed, 18 Oct 2000 14:58:11 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllj05364 for ; Wed, 18 Oct 2000 14:58:08 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllj06469 for ; Wed, 18 Oct 2000 14:55:48 GMT Received: from alpha.tellium.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjllj24607 for ; Wed, 18 Oct 2000 14:55:48 GMT Received: from tellium.com ([192.168.24.75]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9IEmCu05658; Wed, 18 Oct 2000 10:48:12 -0400 (EDT) Message-ID: <39EDB9F1.9A12B3F0@tellium.com> Date: Wed, 18 Oct 2000 10:55:45 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh References: <200010180458.VAA10475@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti: I think we're beginning to reach some convergence here. Kireeti Kompella wrote: > > > You have a good point. In section 3.2 of the bundling document, it > says that a bundle must have a control channel, but is not very > clear that multiple bundles can share a control channel. We will > make this clearer in the next revision. I have had private discussions with Jonathan about this in the context of LMP. Specifically, I wanted to remove the one-to-one association between control channels and bundles, and make it possible to have a single control channel for multiple bundles. LMP presently doesn't support this. > > > Meanwhile, let me say this explicitly: between a pair of GLSRs (i.e., > LSRs, OXCs, SXCs, ...), the requirement is that there must be at > least one control channel; the requirement is *not* one per bundle. > Corresponding to this control channel, one routing adjacency is > needed. But if you use LMP underneath, you WILL get multiple control channels (and hence multiple adjacencies). The single adjacency is the entire rationale for our proposal (leaving aside more straightforward parameters for SONET links). If you can incorporate this feature in your proposal, it'd be close to our proposal. However, the LMP spec needs to change. (I had indicated specific changes in LMP messages for this to Jonathan). > > > The routing module can generate LSAs for all the bundle(s) assigned > to a control channel when both the control channel adjacency is up > and the bundles are up (LMP can be used to say when the bundles are > up). If a bundle changes, the LSA corresponding to that bundle alone > is re-flooded. The details need to be provided for this. > > > This addresses the issue of flood optimization: having multiple > bundles does *not* mean having multiple adjacencies, so flooding > optimization is not a requirement. My contention is that this is not at all evident from your present set of drafts (and LMP). And, this is the chief contribution of our draft. If you can incorporate the support for single control channel for multiple bundles, and provide more details on how adjacencies are maintained, flooding procedures, etc, we'd be happy to consider the resulting draft. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Wed Oct 18 10:59:59 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21272 for ; Wed, 18 Oct 2000 10:59:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllj00413; Wed, 18 Oct 2000 14:59:43 GMT Received: by mail-control.mail.uu.net id QQjllj05468 for mpls-outgoing; Wed, 18 Oct 2000 14:59:10 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjllj05462 for ; Wed, 18 Oct 2000 14:59:08 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllj10337 for ; Wed, 18 Oct 2000 14:58:21 GMT From: Vishal.Sharma@tellabs.com Received: from mx2.tellabs.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQjllj28330 for ; Wed, 18 Oct 2000 14:58:21 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id JAA28980; Wed, 18 Oct 2000 09:58:19 -0500 (CDT) Received: from localhost (root@localhost) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA04909; Wed, 18 Oct 2000 09:58:20 -0500 (CDT) X-OpenMail-Hops: 1 Date: Wed, 18 Oct 2000 09:58:19 -0500 Message-Id: Subject: RE: Draft Minutes From Pittsburgh MIME-Version: 1.0 TO: fhujber@hotmail.com, kireeti@juniper.net, xuyg@lucent.com CC: mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Wed, 18 Oct 2000 09:58:19 -0500" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: fhujber@hotmail.com [mailto:fhujber@hotmail.com] > Sent: Wednesday, October 18, 2000 7:12 AM > To: kireeti@juniper.net; xuyg@lucent.com > Cc: mpls@UU.NET > Subject: Re: Draft Minutes From Pittsburgh > > > Kireeti, et al, > > Consider three routers as a small segment of a larger optical > network, A, B, > and C. A and B areOXCs and are directly connected by a DWDM > with some number > of lightpaths. However, their control plane connection is > through C, which > is a pure IP router, not an OXC. We've made the (painful) > assumption that > the customer/provider has such demand for his lightpaths that > he does not > want to sacrifice a wavelength for control. It would seem > possible to manage > optical links A-to-B with a LSP A-to-C-to-B as along as A and > B knew their > optical connectivity and C knew that it was not part of the > optical path. Keereti, Yuangguang, Frank, Isn't this precisely out-of-band non-associated signaling? (The signaling between OXCs A and B happens via an LSP that goes through C, and does not share resources with the data channel [fibers, lightpaths] between A and B, so it's out of band. Moreover, the topology of the signaling path does not coincide with that of the data path, so the signaling path is "not associated" with the data path.) Thanks, -Vishal > ----- Original Message ----- > From: "Kireeti Kompella" > To: ; > Cc: ; > Sent: Wednesday, October 18, 2000 12:58 AM > Subject: Re: Draft Minutes From Pittsburgh > > > > Hi Yangguang, > > > > > One implication Frank hinted is that: > > > > > > For A----B, even there could be many bundles between A > and B, there > needs only > > > one control channel (no need for physical channel, a TCP > session is > enough) > > > between them. Bundle in circuit network is different from > "interface" in > IP > > > network in the sense that a bundle can be included in one > LSA, but only > send to > > > neighbor once. > > > > You have a good point. In section 3.2 of the bundling document, it > > says that a bundle must have a control channel, but is not very > > clear that multiple bundles can share a control channel. We will > > make this clearer in the next revision. > > > > Meanwhile, let me say this explicitly: between a pair of > GLSRs (i.e., > > LSRs, OXCs, SXCs, ...), the requirement is that there must be at > > least one control channel; the requirement is *not* one per bundle. > > Corresponding to this control channel, one routing adjacency is > > needed. > > > > The routing module can generate LSAs for all the bundle(s) assigned > > to a control channel when both the control channel adjacency is up > > and the bundles are up (LMP can be used to say when the bundles are > > up). If a bundle changes, the LSA corresponding to that > bundle alone > > is re-flooded. > > > > This addresses the issue of flood optimization: having multiple > > bundles does *not* mean having multiple adjacencies, so flooding > > optimization is not a requirement. > > > > Kireeti. > > > From owner-mpls@UU.NET Wed Oct 18 11:05:29 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21380 for ; Wed, 18 Oct 2000 11:05:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllk08656; Wed, 18 Oct 2000 15:05:07 GMT Received: by mail-control.mail.uu.net id QQjllk12413 for mpls-outgoing; Wed, 18 Oct 2000 15:04:33 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllk12387 for ; Wed, 18 Oct 2000 15:04:16 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllk25776 for ; Wed, 18 Oct 2000 15:03:50 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjllk06751 for ; Wed, 18 Oct 2000 15:03:49 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id AAA15389; Thu, 19 Oct 2000 00:04:48 +0900 (KST) X-OpenMail-Hops: 2 Date: Thu, 19 Oct 2000 00:04:01 +0900 Message-Id: In-Reply-To: <01C03784.B41723C0.mohanvak@future.futsoft.com> Subject: (Reply) Hi seenu MIME-Version: 1.0 TO: mpls@UU.NET, mohanvak@future.futsoft.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Wed, 18 Oct 2000 23:40:51 +0900" ;Modification-Date="Thu, 19 Oct 2000 00:03:47 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi mohan, Sorry for a late reply. Take the case where an LSR has sent a No_Lbl_Resources notification to the peers that have requested for a label. When Labels are available the LSR sends first a Lbl_Resources_Available notification and then sends a Label_Mapping msg. See in this case, instead of sending two messages seperately, y can't u include the Status code ( Lbl_Resources_Available) in the label mapping msg itself, which takes less time compared to the earlier one (since processing of a msg takes more time than a TLV). Anyway if an LSR is not ready to handle that tlv it can always ignore it (draft-notifocation msg) Take one more case : An upstream peer has detected a loop, so first it will send a loop_detected_noti and then sends a Lbl_release msg. In this case also, u can include Status_tlv in the Lbl_Release msg So depending on the situation it will reduces the computation. Hope it will help u. regards Seenu > In the ldp-11 draft ,it's given that the status TLV > can be included in ldp messages which need not be > notif. > I feel there is a situation like the LSP got preempted, > which is a defined new status code, in such case it's helpful. > But do u think it's helpful in adding the status TLV > which ceratinly increases the processing at each node. From owner-mpls@UU.NET Wed Oct 18 12:20:11 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24910 for ; Wed, 18 Oct 2000 12:20:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllp29693; Wed, 18 Oct 2000 16:19:34 GMT Received: by mail-control.mail.uu.net id QQjllp05742 for mpls-outgoing; Wed, 18 Oct 2000 16:19:05 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllp05736 for ; Wed, 18 Oct 2000 16:19:02 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllp13206 for ; Wed, 18 Oct 2000 16:15:30 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjllp23113 for ; Wed, 18 Oct 2000 16:15:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA29190 for mpls@uu.net; Wed, 18 Oct 2000 12:15:29 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllp05380 for ; Wed, 18 Oct 2000 16:15:06 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllo08860 for ; Wed, 18 Oct 2000 16:13:36 GMT Received: from ce-nfs-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjllo20432 for ; Wed, 18 Oct 2000 16:13:36 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA17900; Wed, 18 Oct 2000 09:09:16 -0700 (PDT) Date: Wed, 18 Oct 2000 09:03:17 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <9377.001018@cisco.com> To: Yangguang Xu CC: Vishal.Sharma@tellabs.com, fhujber@hotmail.com, kireeti@juniper.net, mpls@UU.NET Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: <39ECCFC7.808FAEF9@lucent.com> References: <39ECCFC7.808FAEF9@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yangguang, I wouldn't oversimplify this. Don't forget about IGPs and signaling. -- Alex Zinin Tuesday, October 17, 2000, 3:16 PM, Yangguang Xu wrote: > Hi, > This general notion is correct and it is against the very basic assumption of IP > network where control traffic is mixed together with data traffic. > In circuit switched network, there should be no assumption about the relation of > data plane topology and control plane topology at all. For two NEs to talk, you > don't need a dedicated control link. You only need a TCP session for a NE pair, > not only a whatever bundle. > Cheers, > Yangguang > Vishal.Sharma@tellabs.com wrote: >> >> Keereti, >> >> I believe what Frank is talking about is not merely the separation >> of the control channel(s) from the data channels, but rather a more >> general notion of non-associated out-of-band signaling. >> >> -Vishal >> >> > -----Original Message----- >> > From: kireeti@juniper.net [mailto:kireeti@juniper.net] >> > Sent: Tuesday, October 17, 2000 5:30 PM >> > To: fhujber@hotmail.com; mpls@UU.NET >> > Subject: Re: Draft Minutes From Pittsburgh >> > >> > >> > Hi Frank, >> > >> > > My perspective is naive, but as I understand it, the >> > current proposals >> > > require a control link to "overlay" an optical link >> > exactly, and for the >> > > control path(s) to be associated with groups of optical >> > links according to >> > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). >> > >> > > Some of us in the optical world, growing from the telephony >> > (SONET/SDH) >> > > world do NOT assume that this overlay occurs. We prefer to offer the >> > > provider (in my case, my customer) to have management >> > networks that are not >> > > the same as the transport networks. This is because in-band >> > signaling is not >> > > yet available (though OIF is working on it) and because >> > providers may not >> > > want to dedicate a wavelength to relatively low-speed >> > management traffic. >> > >> > We have the notion of separate control channels and data paths in many >> > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. >> > >> > Kireeti. >> > From owner-mpls@UU.NET Wed Oct 18 12:49:40 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29078 for ; Wed, 18 Oct 2000 12:49:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllr26972; Wed, 18 Oct 2000 16:49:08 GMT Received: by mail-control.mail.uu.net id QQjllr08201 for mpls-outgoing; Wed, 18 Oct 2000 16:48:45 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllr08194 for ; Wed, 18 Oct 2000 16:48:39 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjllr29269 for ; Wed, 18 Oct 2000 16:48:05 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjllr25327 for ; Wed, 18 Oct 2000 16:48:03 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA01268; Wed, 18 Oct 2000 09:48:02 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id JAA12354; Wed, 18 Oct 2000 09:48:01 -0700 (PDT) Date: Wed, 18 Oct 2000 09:48:01 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010181648.JAA12354@kummer.juniper.net> To: kireeti@juniper.net, xuyg@lucent.com Subject: Re: Draft Minutes From Pittsburgh Cc: fhujber@hotmail.com, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk > The key point is that routing adjacency in circuit switched network data plane > has nothing to do with control channels (the control plane). At least there > shouldn't be any assumption about their co-existence. Actually, there is a one-to-one correspondence (for GMPLS, anyway): one routing adjacency for each control channel. There is the issue of OSPF-incapable OXCs. In this case, there may be a proxy intelligent device that handles OSPF/signalling/LMP; however, that device still needs to have an OSPF adjacency, so the problem doesn't go away, it just moves to this device. However, here what you say may apply: the OXC may just need a simple TCP session to the proxy device, depending on their (private) API. > For each routing adjacency (in data plane), you only need a TCP session as Frank > hinted. Not necessary a physical control channel. You don't need a physical control channel, but you do need more than a TCP session. You need a routing adjacency (OSPF doesn't run over TCP, and certainly ISIS doesn't), a path for signalling messages and (probably) a path for LMP control messages. Fortunately, a GRE tunnel will do exactly this. > BTW, I had a feeling that LMP suggest control channel for each bundle. (I read > it long time ago, can't remember exactly). If this is the case, it's simply not > right. For example, a OXC has 10 neighbors, between each neighbor there are 2 > bundles, then do you need 20 control channels? NO! The next rev of LMP will address this issue. We basically realized that this is an issue for fast Hellos, failover and OSPF, but this applies to signalling as well. So, we'll try to bring this down to one control channel per pair of neighboring GLSRs. Kireeti. From owner-mpls@UU.NET Wed Oct 18 13:18:03 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02707 for ; Wed, 18 Oct 2000 13:18:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllt22137; Wed, 18 Oct 2000 17:17:31 GMT Received: by mail-control.mail.uu.net id QQjllt22197 for mpls-outgoing; Wed, 18 Oct 2000 17:16:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjllt22182 for ; Wed, 18 Oct 2000 17:16:30 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlls16899 for ; Wed, 18 Oct 2000 17:13:49 GMT Received: from auemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQjlls02036 for ; Wed, 18 Oct 2000 17:13:48 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA16709 for ; Wed, 18 Oct 2000 13:13:48 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA16697; Wed, 18 Oct 2000 13:13:47 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA02582; Wed, 18 Oct 2000 13:13:41 -0400 (EDT) Message-ID: <39EDDA43.14F5AA3A@lucent.com> Date: Wed, 18 Oct 2000 13:13:39 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: mpls@UU.NET Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh References: <39ECCFC7.808FAEF9@lucent.com> <9377.001018@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alex, I wasn't simplifying it. Indeed, I make it more complicated and generic. IGP and signaling shouldn't make invalid assumptions either. Circuit switched transport network is different from IP network. Yangguang Alex Zinin wrote: > > Yangguang, > > I wouldn't oversimplify this. > Don't forget about IGPs and signaling. > > -- > Alex Zinin > > Tuesday, October 17, 2000, 3:16 PM, Yangguang Xu wrote: > > > Hi, > > > This general notion is correct and it is against the very basic assumption of IP > > network where control traffic is mixed together with data traffic. > > > In circuit switched network, there should be no assumption about the relation of > > data plane topology and control plane topology at all. For two NEs to talk, you > > don't need a dedicated control link. You only need a TCP session for a NE pair, > > not only a whatever bundle. > > > Cheers, > > > Yangguang > > > Vishal.Sharma@tellabs.com wrote: > >> > >> Keereti, > >> > >> I believe what Frank is talking about is not merely the separation > >> of the control channel(s) from the data channels, but rather a more > >> general notion of non-associated out-of-band signaling. > >> > >> -Vishal > >> > >> > -----Original Message----- > >> > From: kireeti@juniper.net [mailto:kireeti@juniper.net] > >> > Sent: Tuesday, October 17, 2000 5:30 PM > >> > To: fhujber@hotmail.com; mpls@UU.NET > >> > Subject: Re: Draft Minutes From Pittsburgh > >> > > >> > > >> > Hi Frank, > >> > > >> > > My perspective is naive, but as I understand it, the > >> > current proposals > >> > > require a control link to "overlay" an optical link > >> > exactly, and for the > >> > > control path(s) to be associated with groups of optical > >> > links according to > >> > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). > >> > > >> > > Some of us in the optical world, growing from the telephony > >> > (SONET/SDH) > >> > > world do NOT assume that this overlay occurs. We prefer to offer the > >> > > provider (in my case, my customer) to have management > >> > networks that are not > >> > > the same as the transport networks. This is because in-band > >> > signaling is not > >> > > yet available (though OIF is working on it) and because > >> > providers may not > >> > > want to dedicate a wavelength to relatively low-speed > >> > management traffic. > >> > > >> > We have the notion of separate control channels and data paths in many > >> > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. > >> > > >> > Kireeti. > >> > From owner-mpls@UU.NET Wed Oct 18 13:37:07 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05326 for ; Wed, 18 Oct 2000 13:37:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllu27384; Wed, 18 Oct 2000 17:36:42 GMT Received: by mail-control.mail.uu.net id QQjllu04588 for mpls-outgoing; Wed, 18 Oct 2000 17:36:03 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllu04574 for ; Wed, 18 Oct 2000 17:35:58 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjllu19088 for ; Wed, 18 Oct 2000 17:33:49 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjllu01485 for ; Wed, 18 Oct 2000 17:33:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA11183 for mpls@uu.net; Wed, 18 Oct 2000 13:33:48 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjllu04209 for ; Wed, 18 Oct 2000 17:33:08 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllu28983 for ; Wed, 18 Oct 2000 17:32:18 GMT Received: from lumen.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjllu14161 for ; Wed, 18 Oct 2000 17:32:12 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id <4YY6ZHFZ>; Wed, 18 Oct 2000 10:32:10 -0700 Message-ID: From: John Drake To: "'Frank Hujber'" , Kireeti Kompella , xuyg@lucent.com Cc: mpls@UU.NET Subject: RE: Draft Minutes From Pittsburgh Date: Wed, 18 Oct 2000 10:32:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Frank, Control channels between adjacent GMPLS devices may be direct lambdas or fibers. They may also be IP tunnels, GRE tunnels, or LSPs, across a router network. This is fairly well understood and spelled out in the LMP draft as well as the other drafts (or should have been). There's no issue doing what you describe. Thanks, John -----Original Message----- From: Frank Hujber [mailto:fhujber@hotmail.com] Sent: Wednesday, October 18, 2000 4:12 AM To: Kireeti Kompella; xuyg@lucent.com Cc: mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh Kireeti, et al, Consider three routers as a small segment of a larger optical network, A, B, and C. A and B areOXCs and are directly connected by a DWDM with some number of lightpaths. However, their control plane connection is through C, which is a pure IP router, not an OXC. We've made the (painful) assumption that the customer/provider has such demand for his lightpaths that he does not want to sacrifice a wavelength for control. It would seem possible to manage optical links A-to-B with a LSP A-to-C-to-B as along as A and B knew their optical connectivity and C knew that it was not part of the optical path. We do regard this as a degerate case, but one that we must (here in NJ) be prepared to support. Frank Hujber fhujber@hotmail.com ----- Original Message ----- From: "Kireeti Kompella" To: ; Cc: ; Sent: Wednesday, October 18, 2000 12:58 AM Subject: Re: Draft Minutes From Pittsburgh > Hi Yangguang, > > > One implication Frank hinted is that: > > > > For A----B, even there could be many bundles between A and B, there needs only > > one control channel (no need for physical channel, a TCP session is enough) > > between them. Bundle in circuit network is different from "interface" in IP > > network in the sense that a bundle can be included in one LSA, but only send to > > neighbor once. > > You have a good point. In section 3.2 of the bundling document, it > says that a bundle must have a control channel, but is not very > clear that multiple bundles can share a control channel. We will > make this clearer in the next revision. > > Meanwhile, let me say this explicitly: between a pair of GLSRs (i.e., > LSRs, OXCs, SXCs, ...), the requirement is that there must be at > least one control channel; the requirement is *not* one per bundle. > Corresponding to this control channel, one routing adjacency is > needed. > > The routing module can generate LSAs for all the bundle(s) assigned > to a control channel when both the control channel adjacency is up > and the bundles are up (LMP can be used to say when the bundles are > up). If a bundle changes, the LSA corresponding to that bundle alone > is re-flooded. > > This addresses the issue of flood optimization: having multiple > bundles does *not* mean having multiple adjacencies, so flooding > optimization is not a requirement. > > Kireeti. > From owner-mpls@UU.NET Wed Oct 18 13:39:40 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05639 for ; Wed, 18 Oct 2000 13:39:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllu09437; Wed, 18 Oct 2000 17:39:21 GMT Received: by mail-control.mail.uu.net id QQjllu04844 for mpls-outgoing; Wed, 18 Oct 2000 17:38:47 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllu04829 for ; Wed, 18 Oct 2000 17:38:37 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjllu27958 for ; Wed, 18 Oct 2000 17:37:38 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjllu06858 for ; Wed, 18 Oct 2000 17:37:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA11809 for mpls@uu.net; Wed, 18 Oct 2000 13:37:37 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjllu04611 for ; Wed, 18 Oct 2000 17:36:28 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjllu06673 for ; Wed, 18 Oct 2000 17:35:42 GMT Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjllu18938 for ; Wed, 18 Oct 2000 17:35:42 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA29848; Wed, 18 Oct 2000 10:35:40 -0700 (PDT) Date: Wed, 18 Oct 2000 10:29:41 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <10437.001018@cisco.com> To: Yangguang Xu CC: mpls@UU.NET Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: <39EDDA43.14F5AA3A@lucent.com> References: <39EDDA43.14F5AA3A@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yangguang, > Alex, > I wasn't simplifying it. Indeed, I make it more complicated and generic. IGP and > signaling shouldn't make invalid assumptions either. Circuit switched transport > network is different from IP network. Do you mind explaining how you expect the two components to work over a TCP connection btw non-adjacent routers? Thanks, Alex. > Yangguang > Alex Zinin wrote: >> >> Yangguang, >> >> I wouldn't oversimplify this. >> Don't forget about IGPs and signaling. >> >> -- >> Alex Zinin >> >> Tuesday, October 17, 2000, 3:16 PM, Yangguang Xu wrote: >> >> > Hi, >> >> > This general notion is correct and it is against the very basic assumption of IP >> > network where control traffic is mixed together with data traffic. >> >> > In circuit switched network, there should be no assumption about the relation of >> > data plane topology and control plane topology at all. For two NEs to talk, you >> > don't need a dedicated control link. You only need a TCP session for a NE pair, >> > not only a whatever bundle. >> >> > Cheers, >> >> > Yangguang >> >> > Vishal.Sharma@tellabs.com wrote: >> >> >> >> Keereti, >> >> >> >> I believe what Frank is talking about is not merely the separation >> >> of the control channel(s) from the data channels, but rather a more >> >> general notion of non-associated out-of-band signaling. >> >> >> >> -Vishal >> >> >> >> > -----Original Message----- >> >> > From: kireeti@juniper.net [mailto:kireeti@juniper.net] >> >> > Sent: Tuesday, October 17, 2000 5:30 PM >> >> > To: fhujber@hotmail.com; mpls@UU.NET >> >> > Subject: Re: Draft Minutes From Pittsburgh >> >> > >> >> > >> >> > Hi Frank, >> >> > >> >> > > My perspective is naive, but as I understand it, the >> >> > current proposals >> >> > > require a control link to "overlay" an optical link >> >> > exactly, and for the >> >> > > control path(s) to be associated with groups of optical >> >> > links according to >> >> > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). >> >> > >> >> > > Some of us in the optical world, growing from the telephony >> >> > (SONET/SDH) >> >> > > world do NOT assume that this overlay occurs. We prefer to offer the >> >> > > provider (in my case, my customer) to have management >> >> > networks that are not >> >> > > the same as the transport networks. This is because in-band >> >> > signaling is not >> >> > > yet available (though OIF is working on it) and because >> >> > providers may not >> >> > > want to dedicate a wavelength to relatively low-speed >> >> > management traffic. >> >> > >> >> > We have the notion of separate control channels and data paths in many >> >> > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. >> >> > >> >> > Kireeti. >> >> > From owner-mpls@UU.NET Wed Oct 18 13:59:26 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08022 for ; Wed, 18 Oct 2000 13:59:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllv22530; Wed, 18 Oct 2000 17:58:55 GMT Received: by mail-control.mail.uu.net id QQjllv06662 for mpls-outgoing; Wed, 18 Oct 2000 17:58:30 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllv06657 for ; Wed, 18 Oct 2000 17:58:28 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjllv14368 for ; Wed, 18 Oct 2000 17:57:39 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjllv28713 for ; Wed, 18 Oct 2000 17:57:38 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA01514 for ; Wed, 18 Oct 2000 13:57:38 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA01506; Wed, 18 Oct 2000 13:57:37 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA10642; Wed, 18 Oct 2000 13:57:36 -0400 (EDT) Message-ID: <39EDE48E.4AB31D81@lucent.com> Date: Wed, 18 Oct 2000 13:57:35 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh References: <200010181648.JAA12354@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, I guess I didn't address clearly about using TCP session. There are two ways to distribute transport network topology. Either way has pros and cons. 1) Piggyback through standard OSPF Opaque LSA If we want to apply OSPF/ISIS, CR-LDP/RSVP directly to circuit switched transport network, you are absolutely right. There should be a one-to-one correspondence of routing adjacency and control channel. However, there is a fundamental problem here, folks (including me) always try to apply existing protocols directly to other applications. Protocols are always designed for a certain problem with unique features, assumptions and requirement. For other "similar" problems which may have different assumptions and requirement, "Here it is and use it" isn't always a good solution. We should first understand the correct assumption and requirements of optical network and then tune routing and signaling protocols for them. Using existing solutions, protocols to define problem, application and assumption seems to be not quite right. 2) An independent application You don't need a dedicated control channel in this case. A TCP session is enough. Thanks, Yangguang Kireeti Kompella wrote: > > > The key point is that routing adjacency in circuit switched network data plane > > has nothing to do with control channels (the control plane). At least there > > shouldn't be any assumption about their co-existence. > > Actually, there is a one-to-one correspondence (for GMPLS, anyway): > one routing adjacency for each control channel. > > There is the issue of OSPF-incapable OXCs. In this case, there may > be a proxy intelligent device that handles OSPF/signalling/LMP; > however, that device still needs to have an OSPF adjacency, so the > problem doesn't go away, it just moves to this device. However, here > what you say may apply: the OXC may just need a simple TCP session to > the proxy device, depending on their (private) API. > > > For each routing adjacency (in data plane), you only need a TCP session as Frank > > hinted. Not necessary a physical control channel. > > You don't need a physical control channel, but you do need more than > a TCP session. You need a routing adjacency (OSPF doesn't run over > TCP, and certainly ISIS doesn't), a path for signalling messages and > (probably) a path for LMP control messages. Fortunately, a GRE tunnel > will do exactly this. > > > BTW, I had a feeling that LMP suggest control channel for each bundle. (I read > > it long time ago, can't remember exactly). If this is the case, it's simply not > > right. For example, a OXC has 10 neighbors, between each neighbor there are 2 > > bundles, then do you need 20 control channels? NO! > > The next rev of LMP will address this issue. We basically realized > that this is an issue for fast Hellos, failover and OSPF, but this > applies to signalling as well. So, we'll try to bring this down to > one control channel per pair of neighboring GLSRs. > > Kireeti. From owner-mpls@UU.NET Wed Oct 18 14:06:42 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08919 for ; Wed, 18 Oct 2000 14:06:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllw03026; Wed, 18 Oct 2000 18:05:57 GMT Received: by mail-control.mail.uu.net id QQjllw18535 for mpls-outgoing; Wed, 18 Oct 2000 18:05:31 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjllw18523 for ; Wed, 18 Oct 2000 18:05:24 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjllw14650 for ; Wed, 18 Oct 2000 18:05:18 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjllw20468 for ; Wed, 18 Oct 2000 18:05:17 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA11124 for ; Wed, 18 Oct 2000 14:05:17 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA11112; Wed, 18 Oct 2000 14:05:17 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA13229; Wed, 18 Oct 2000 14:05:15 -0400 (EDT) Message-ID: <39EDE656.189CEFC1@lucent.com> Date: Wed, 18 Oct 2000 14:05:10 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: mpls@UU.NET, Kireeti Kompella Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh References: <39EDDA43.14F5AA3A@lucent.com> <10437.001018@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alex, When using independent application to distribute optical topology, a TCP session is enough. If we want to apply OSPF directly, we can set up a FA-LSP between two NEs that are adjacent in their transport(data) plane but not adjacent in their control plane. Either way, you don't need a dedicated physical control channel. Thanks, Yangguang Alex Zinin wrote: > > Yangguang, > > > Alex, > > I wasn't simplifying it. Indeed, I make it more complicated and generic. IGP and > > signaling shouldn't make invalid assumptions either. Circuit switched transport > > network is different from IP network. > > Do you mind explaining how you expect the two components to work over > a TCP connection btw non-adjacent routers? > > Thanks, > > Alex. > > > Yangguang > > > Alex Zinin wrote: > >> > >> Yangguang, > >> > >> I wouldn't oversimplify this. > >> Don't forget about IGPs and signaling. > >> > >> -- > >> Alex Zinin > >> > >> Tuesday, October 17, 2000, 3:16 PM, Yangguang Xu wrote: > >> > >> > Hi, > >> > >> > This general notion is correct and it is against the very basic assumption of IP > >> > network where control traffic is mixed together with data traffic. > >> > >> > In circuit switched network, there should be no assumption about the relation of > >> > data plane topology and control plane topology at all. For two NEs to talk, you > >> > don't need a dedicated control link. You only need a TCP session for a NE pair, > >> > not only a whatever bundle. > >> > >> > Cheers, > >> > >> > Yangguang > >> > >> > Vishal.Sharma@tellabs.com wrote: > >> >> > >> >> Keereti, > >> >> > >> >> I believe what Frank is talking about is not merely the separation > >> >> of the control channel(s) from the data channels, but rather a more > >> >> general notion of non-associated out-of-band signaling. > >> >> > >> >> -Vishal > >> >> > >> >> > -----Original Message----- > >> >> > From: kireeti@juniper.net [mailto:kireeti@juniper.net] > >> >> > Sent: Tuesday, October 17, 2000 5:30 PM > >> >> > To: fhujber@hotmail.com; mpls@UU.NET > >> >> > Subject: Re: Draft Minutes From Pittsburgh > >> >> > > >> >> > > >> >> > Hi Frank, > >> >> > > >> >> > > My perspective is naive, but as I understand it, the > >> >> > current proposals > >> >> > > require a control link to "overlay" an optical link > >> >> > exactly, and for the > >> >> > > control path(s) to be associated with groups of optical > >> >> > links according to > >> >> > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). > >> >> > > >> >> > > Some of us in the optical world, growing from the telephony > >> >> > (SONET/SDH) > >> >> > > world do NOT assume that this overlay occurs. We prefer to offer the > >> >> > > provider (in my case, my customer) to have management > >> >> > networks that are not > >> >> > > the same as the transport networks. This is because in-band > >> >> > signaling is not > >> >> > > yet available (though OIF is working on it) and because > >> >> > providers may not > >> >> > > want to dedicate a wavelength to relatively low-speed > >> >> > management traffic. > >> >> > > >> >> > We have the notion of separate control channels and data paths in many > >> >> > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. > >> >> > > >> >> > Kireeti. > >> >> > From owner-mpls@UU.NET Wed Oct 18 14:13:52 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09814 for ; Wed, 18 Oct 2000 14:13:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllw29176; Wed, 18 Oct 2000 18:13:06 GMT Received: by mail-control.mail.uu.net id QQjllw19730 for mpls-outgoing; Wed, 18 Oct 2000 18:12:43 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllw19722 for ; Wed, 18 Oct 2000 18:12:39 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjllw20477 for ; Wed, 18 Oct 2000 18:12:17 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjllw09914 for ; Wed, 18 Oct 2000 18:12:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA19105 for mpls@uu.net; Wed, 18 Oct 2000 14:12:16 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjllw19515 for ; Wed, 18 Oct 2000 18:11:49 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjllw29970 for ; Wed, 18 Oct 2000 18:11:39 GMT Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjllw12513 for ; Wed, 18 Oct 2000 18:11:38 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA04798; Wed, 18 Oct 2000 11:11:32 -0700 (PDT) Date: Wed, 18 Oct 2000 11:05:33 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <7462.001018@cisco.com> To: Yangguang Xu CC: Kireeti Kompella , mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh In-reply-To: <39EDE48E.4AB31D81@lucent.com> References: <39EDE48E.4AB31D81@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yangguang, One thing that seems interesting to me in the context of optical networks is potential possibility to prune the topology of IGP adjacencies to minimally necessary (e.g., redundant spanning tree), while still announcing TE information about all optical links. The state of the links would be defined with protocols like LMP or mechanisms integrated into lower layers. This is possible because in case of p2p links (valid for ONs), we do not use IGP topology database for CSPF. However, we do use it in other networks when calculate the paths through multi-access segments. -- Alex Zinin Wednesday, October 18, 2000, 10:57 AM, Yangguang Xu wrote: > Kireeti, > I guess I didn't address clearly about using TCP session. > There are two ways to distribute transport network topology. Either way has pros > and cons. > 1) Piggyback through standard OSPF Opaque LSA > If we want to apply OSPF/ISIS, CR-LDP/RSVP directly to circuit switched > transport network, you are absolutely right. There should be a one-to-one > correspondence of routing adjacency and control channel. > However, there is a fundamental problem here, folks (including me) always try > to apply existing protocols directly to other applications. Protocols are always > designed for a certain problem with unique features, assumptions and > requirement. For other "similar" problems which may have different assumptions > and requirement, "Here it is and use it" isn't always a good solution. We should > first understand the correct assumption and requirements of optical network and > then tune routing and signaling protocols for them. > Using existing solutions, protocols to define problem, application and > assumption seems to be not quite right. > 2) An independent application > You don't need a dedicated control channel in this case. A TCP session is > enough. > Thanks, > Yangguang > Kireeti Kompella wrote: >> >> > The key point is that routing adjacency in circuit switched network data plane >> > has nothing to do with control channels (the control plane). At least there >> > shouldn't be any assumption about their co-existence. >> >> Actually, there is a one-to-one correspondence (for GMPLS, anyway): >> one routing adjacency for each control channel. >> >> There is the issue of OSPF-incapable OXCs. In this case, there may >> be a proxy intelligent device that handles OSPF/signalling/LMP; >> however, that device still needs to have an OSPF adjacency, so the >> problem doesn't go away, it just moves to this device. However, here >> what you say may apply: the OXC may just need a simple TCP session to >> the proxy device, depending on their (private) API. >> >> > For each routing adjacency (in data plane), you only need a TCP session as Frank >> > hinted. Not necessary a physical control channel. >> >> You don't need a physical control channel, but you do need more than >> a TCP session. You need a routing adjacency (OSPF doesn't run over >> TCP, and certainly ISIS doesn't), a path for signalling messages and >> (probably) a path for LMP control messages. Fortunately, a GRE tunnel >> will do exactly this. >> >> > BTW, I had a feeling that LMP suggest control channel for each bundle. (I read >> > it long time ago, can't remember exactly). If this is the case, it's simply not >> > right. For example, a OXC has 10 neighbors, between each neighbor there are 2 >> > bundles, then do you need 20 control channels? NO! >> >> The next rev of LMP will address this issue. We basically realized >> that this is an issue for fast Hellos, failover and OSPF, but this >> applies to signalling as well. So, we'll try to bring this down to >> one control channel per pair of neighboring GLSRs. >> >> Kireeti. From owner-mpls@UU.NET Wed Oct 18 14:21:04 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10720 for ; Wed, 18 Oct 2000 14:21:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllx25685; Wed, 18 Oct 2000 18:20:34 GMT Received: by mail-control.mail.uu.net id QQjllx20469 for mpls-outgoing; Wed, 18 Oct 2000 18:20:02 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjllx20449 for ; Wed, 18 Oct 2000 18:19:49 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjllx15367 for ; Wed, 18 Oct 2000 18:18:40 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjllx27983 for ; Wed, 18 Oct 2000 18:18:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA20496 for mpls@uu.net; Wed, 18 Oct 2000 14:18:35 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjllx20348 for ; Wed, 18 Oct 2000 18:18:06 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllx10971 for ; Wed, 18 Oct 2000 18:16:28 GMT Received: from lumen.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjllx04016 for ; Wed, 18 Oct 2000 18:16:26 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id <4YY6ZHLG>; Wed, 18 Oct 2000 11:16:21 -0700 Message-ID: From: John Drake To: "'Yangguang Xu'" , Kireeti Kompella Cc: mpls@UU.NET Subject: RE: Draft Minutes From Pittsburgh Date: Wed, 18 Oct 2000 11:16:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yangguang, Have you been following the work on Generalized MPLS (nee MPL(ambda)S) which has been going on since late last year? As I said in my note to Frank, we already do what you're describing (to the extent that I understand what you're describing), we just don't use a TCP session; instead an IP, GRE, or IPSec tunnel, or an LSP is used. As Kireeti points out, there are practical problems associated with using a TCP session. Thanks, John -----Original Message----- From: Yangguang Xu [mailto:xuyg@lucent.com] Sent: Wednesday, October 18, 2000 10:58 AM To: Kireeti Kompella Cc: mpls@UU.NET Subject: Re: Draft Minutes From Pittsburgh Kireeti, I guess I didn't address clearly about using TCP session. There are two ways to distribute transport network topology. Either way has pros and cons. 1) Piggyback through standard OSPF Opaque LSA If we want to apply OSPF/ISIS, CR-LDP/RSVP directly to circuit switched transport network, you are absolutely right. There should be a one-to-one correspondence of routing adjacency and control channel. However, there is a fundamental problem here, folks (including me) always try to apply existing protocols directly to other applications. Protocols are always designed for a certain problem with unique features, assumptions and requirement. For other "similar" problems which may have different assumptions and requirement, "Here it is and use it" isn't always a good solution. We should first understand the correct assumption and requirements of optical network and then tune routing and signaling protocols for them. Using existing solutions, protocols to define problem, application and assumption seems to be not quite right. 2) An independent application You don't need a dedicated control channel in this case. A TCP session is enough. Thanks, Yangguang Kireeti Kompella wrote: > > > The key point is that routing adjacency in circuit switched network data plane > > has nothing to do with control channels (the control plane). At least there > > shouldn't be any assumption about their co-existence. > > Actually, there is a one-to-one correspondence (for GMPLS, anyway): > one routing adjacency for each control channel. > > There is the issue of OSPF-incapable OXCs. In this case, there may > be a proxy intelligent device that handles OSPF/signalling/LMP; > however, that device still needs to have an OSPF adjacency, so the > problem doesn't go away, it just moves to this device. However, here > what you say may apply: the OXC may just need a simple TCP session to > the proxy device, depending on their (private) API. > > > For each routing adjacency (in data plane), you only need a TCP session as Frank > > hinted. Not necessary a physical control channel. > > You don't need a physical control channel, but you do need more than > a TCP session. You need a routing adjacency (OSPF doesn't run over > TCP, and certainly ISIS doesn't), a path for signalling messages and > (probably) a path for LMP control messages. Fortunately, a GRE tunnel > will do exactly this. > > > BTW, I had a feeling that LMP suggest control channel for each bundle. (I read > > it long time ago, can't remember exactly). If this is the case, it's simply not > > right. For example, a OXC has 10 neighbors, between each neighbor there are 2 > > bundles, then do you need 20 control channels? NO! > > The next rev of LMP will address this issue. We basically realized > that this is an issue for fast Hellos, failover and OSPF, but this > applies to signalling as well. So, we'll try to bring this down to > one control channel per pair of neighboring GLSRs. > > Kireeti. From owner-mpls@UU.NET Wed Oct 18 14:24:31 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11149 for ; Wed, 18 Oct 2000 14:24:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllx13263; Wed, 18 Oct 2000 18:23:47 GMT Received: by mail-control.mail.uu.net id QQjllx20762 for mpls-outgoing; Wed, 18 Oct 2000 18:23:24 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllx20754 for ; Wed, 18 Oct 2000 18:23:15 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjllx11317 for ; Wed, 18 Oct 2000 18:21:34 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjllx06727 for ; Wed, 18 Oct 2000 18:21:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA20994 for mpls@uu.net; Wed, 18 Oct 2000 14:21:33 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllx20482 for ; Wed, 18 Oct 2000 18:20:17 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjllx01953 for ; Wed, 18 Oct 2000 18:17:25 GMT Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjllx20492 for ; Wed, 18 Oct 2000 18:17:25 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA10030; Wed, 18 Oct 2000 11:17:18 -0700 (PDT) Date: Wed, 18 Oct 2000 11:11:20 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <18466.001018@cisco.com> To: Yangguang Xu CC: mpls@UU.NET, Kireeti Kompella Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: <39EDE656.189CEFC1@lucent.com> References: <39EDE656.189CEFC1@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yangguang, Wednesday, October 18, 2000, 11:05 AM, Yangguang Xu wrote: > Alex, > When using independent application to distribute optical topology, a TCP session > is enough. Got it. It was a more generic comment. > If we want to apply OSPF directly, we can set up a FA-LSP between two NEs that > are adjacent in their transport(data) plane but not adjacent in their control > plane. The purpose of FAs is exactly the opposite---announce an LSP as a topological entity without establishing a control adjacency over it. I believe you mean just an LSP. Thanks, Alex. > Either way, you don't need a dedicated physical control channel. > Thanks, > Yangguang > Alex Zinin wrote: >> >> Yangguang, >> >> > Alex, >> > I wasn't simplifying it. Indeed, I make it more complicated and generic. IGP and >> > signaling shouldn't make invalid assumptions either. Circuit switched transport >> > network is different from IP network. >> >> Do you mind explaining how you expect the two components to work over >> a TCP connection btw non-adjacent routers? >> >> Thanks, >> >> Alex. >> >> > Yangguang >> >> > Alex Zinin wrote: >> >> >> >> Yangguang, >> >> >> >> I wouldn't oversimplify this. >> >> Don't forget about IGPs and signaling. >> >> >> >> -- >> >> Alex Zinin >> >> >> >> Tuesday, October 17, 2000, 3:16 PM, Yangguang Xu wrote: >> >> >> >> > Hi, >> >> >> >> > This general notion is correct and it is against the very basic assumption of IP >> >> > network where control traffic is mixed together with data traffic. >> >> >> >> > In circuit switched network, there should be no assumption about the relation of >> >> > data plane topology and control plane topology at all. For two NEs to talk, you >> >> > don't need a dedicated control link. You only need a TCP session for a NE pair, >> >> > not only a whatever bundle. >> >> >> >> > Cheers, >> >> >> >> > Yangguang >> >> >> >> > Vishal.Sharma@tellabs.com wrote: >> >> >> >> >> >> Keereti, >> >> >> >> >> >> I believe what Frank is talking about is not merely the separation >> >> >> of the control channel(s) from the data channels, but rather a more >> >> >> general notion of non-associated out-of-band signaling. >> >> >> >> >> >> -Vishal >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: kireeti@juniper.net [mailto:kireeti@juniper.net] >> >> >> > Sent: Tuesday, October 17, 2000 5:30 PM >> >> >> > To: fhujber@hotmail.com; mpls@UU.NET >> >> >> > Subject: Re: Draft Minutes From Pittsburgh >> >> >> > >> >> >> > >> >> >> > Hi Frank, >> >> >> > >> >> >> > > My perspective is naive, but as I understand it, the >> >> >> > current proposals >> >> >> > > require a control link to "overlay" an optical link >> >> >> > exactly, and for the >> >> >> > > control path(s) to be associated with groups of optical >> >> >> > links according to >> >> >> > > their characteristics (i.e. bandwidth - OC-48 vs OC-192). >> >> >> > >> >> >> > > Some of us in the optical world, growing from the telephony >> >> >> > (SONET/SDH) >> >> >> > > world do NOT assume that this overlay occurs. We prefer to offer the >> >> >> > > provider (in my case, my customer) to have management >> >> >> > networks that are not >> >> >> > > the same as the transport networks. This is because in-band >> >> >> > signaling is not >> >> >> > > yet available (though OIF is working on it) and because >> >> >> > providers may not >> >> >> > > want to dedicate a wavelength to relatively low-speed >> >> >> > management traffic. >> >> >> > >> >> >> > We have the notion of separate control channels and data paths in many >> >> >> > drafts. See draft-ietf-mpls-lmp-00.txt for a brief description. >> >> >> > >> >> >> > Kireeti. >> >> >> > From owner-mpls@UU.NET Wed Oct 18 14:31:54 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12152 for ; Wed, 18 Oct 2000 14:31:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllo10535; Wed, 18 Oct 2000 16:07:10 GMT Received: by mail-control.mail.uu.net id QQjllo04276 for mpls-outgoing; Wed, 18 Oct 2000 16:06:35 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllo04248 for ; Wed, 18 Oct 2000 16:06:24 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllo19441 for ; Wed, 18 Oct 2000 16:05:20 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjllo07846 for ; Wed, 18 Oct 2000 16:05:19 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA27505 for mpls@uu.net; Wed, 18 Oct 2000 12:05:19 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllo01276 for ; Wed, 18 Oct 2000 16:03:37 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjllo07643 for ; Wed, 18 Oct 2000 16:00:20 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjllo12489 for ; Wed, 18 Oct 2000 16:00:19 GMT Received: from p7020-img-nt.cisco.com ([64.104.42.22]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA10737; Wed, 18 Oct 2000 08:58:59 -0700 (PDT) Message-Id: <5.0.0.25.2.20001018192123.03506690@flipper> X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 18 Oct 2000 19:25:33 -0700 To: curtis@avici.com From: Fred Baker Subject: Re: Any SPs using QoS ??? Cc: Ping Pan , curtis@avici.com, Randy Bush , mpls@UU.NET In-Reply-To: <200010161536.LAA34302@workhorse.fictitious.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:36 AM 10/16/00 -0400, Curtis Villamizar wrote: >ECN is not like FECN and BECN. ECN is used for end-to-end congestion >avoidance (TCP). The ECN ECT (ECN capable transport) bit is used to >indicate that the end systems are ECN capable and using ECN. The CE >(congestion experienced) bit is set by routers in place of a drop to >indicate that a drop would have occurred. TCP is expected to react as >if a drop has ocurred, but the retransmission is avoided. Actually, I would argue that it is a lot like FECN. The model for FECN (proposed by Goldstein as I recall) was that it would be received by a Frame Relay DTE, and be copied into an option in CLNS. CLNS would then deliver it to the receiving TP-4, which would implement the DEC Bit algorithm to attempt to adapt transmission rate to the knee (as opposed to the cliff) of the power curve. In the ECN case, we have a network layer protocol rather than a link layer protocol, but again the idea is that congestion would be sensed en route and reported by the network layer (IP) to the receiving transport (TCP), which would take very similar actions to accomplish the same goal. From owner-mpls@UU.NET Wed Oct 18 14:43:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13692 for ; Wed, 18 Oct 2000 14:43:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlly14763; Wed, 18 Oct 2000 18:42:36 GMT Received: by mail-control.mail.uu.net id QQjlly22140 for mpls-outgoing; Wed, 18 Oct 2000 18:42:04 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlly22129 for ; Wed, 18 Oct 2000 18:41:57 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlly07180 for ; Wed, 18 Oct 2000 18:41:28 GMT Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQjlly27779 for ; Wed, 18 Oct 2000 18:41:28 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <48XX1BHA>; Wed, 18 Oct 2000 11:42:07 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6625D8B30@ICARIAN> From: Eric Gray To: "MPLS Mailing List (E-mail)" Subject: RE: bug in draft-ietf-mpls-label-encaps-08 Date: Wed, 18 Oct 2000 11:42:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Folks, Discussion on this topic has convinced me that there is a flaw in the MPLS specifications - though I do not think it should be fixed in the encaps draft. It seems that some people have concluded that the intention behind defining the explicit NULL labels was to allow them to be used by an implementation that does not support PHP. It is - in retrospect - easy to see why this might concluded since it is difficult otherwise to be able to explain why the explicit NULL labels were defined at all. Without some implied use for these labels, their value is implementation specific and the need to specify them nil. This is a problem, however, because other people have assumed that the implementation that is not able to support PHP will refuse implicit NULL labels. Making this assumption is useful to those implementations that rely on PHP because a reasonable work-around for having an upstream peer that does not support PHP is to allocate a label from a special set (similar to the explicit NULL labels) - but with the added value of being able to assign specific labels from this set that help in the forwarding process as well. As an example, there may be different sets of special labels corresponding to each possible output port. If the upstream LSR simply takes the implicit NULL label signaled and turns it into a corresponding explicit NULL label in an NHLFE, then the downstream LSR does not get an explicit notification of the fact that the upstream LSR will not be doing PHP. This ambiguity should be cleared up. One possible place to do this would be in the MPLS architecture draft. -- Eric Gray From owner-mpls@UU.NET Wed Oct 18 14:58:08 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16286 for ; Wed, 18 Oct 2000 14:58:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjllz05679; Wed, 18 Oct 2000 18:56:40 GMT Received: by mail-control.mail.uu.net id QQjllz23516 for mpls-outgoing; Wed, 18 Oct 2000 18:56:01 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjllz23494 for ; Wed, 18 Oct 2000 18:55:50 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjllz07967 for ; Wed, 18 Oct 2000 18:55:08 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjllz05619 for ; Wed, 18 Oct 2000 18:55:07 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA27496 for mpls@uu.net; Wed, 18 Oct 2000 14:55:06 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjllz23442 for ; Wed, 18 Oct 2000 18:54:28 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjllz28905 for ; Wed, 18 Oct 2000 18:54:03 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjllz01748 for ; Wed, 18 Oct 2000 18:54:03 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA08195 for ; Wed, 18 Oct 2000 11:54:02 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 11:59:01 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A07@BBY1EXM01> From: Shahram Davari To: "'MPLS@UU.net'" Subject: Traffic TLV in CR-LDP Date: Wed, 18 Oct 2000 11:59:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I was wondering why the traffic TLV of CR-LDP has so many parameters: PDR, PBS, CDR, CBS, EBS. According to CRLDP, (PDR, PBS) and (CDR, CBS) and (CDR, EBS) define 3 Token buckets. While what we need for different scenarios are: 1) For GS (Intserv) we need only 2 TBs. 2) For CLS (Intserv) we need only one TB. 3) For EF (Diffserv) we need only one TB. 4) For AF (Diffserv) we need only 2 TBs. Don't you think one of the (PBS or EBS) parameters is extra? If so which one should be used by an LSR? Regards, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 From owner-mpls@UU.NET Wed Oct 18 15:11:47 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18521 for ; Wed, 18 Oct 2000 15:11:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlma22048; Wed, 18 Oct 2000 19:11:21 GMT Received: by mail-control.mail.uu.net id QQjlma06317 for mpls-outgoing; Wed, 18 Oct 2000 19:10:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlma06309 for ; Wed, 18 Oct 2000 19:10:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlma24985 for ; Wed, 18 Oct 2000 19:10:30 GMT From: pasi.vaananen@nokia.com Received: from mgw-x2.nokia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mgw-x2.nokia.com [131.228.20.22]) id QQjlma26787 for ; Wed, 18 Oct 2000 19:10:29 GMT Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9IJ9sP26995; Wed, 18 Oct 2000 22:09:54 +0300 (EET DST) Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id <483HLN45>; Wed, 18 Oct 2000 14:06:12 -0500 Message-ID: To: Shahram_Davari@pmc-sierra.com, MPLS@UU.NET Subject: RE: Traffic TLV in CR-LDP Date: Wed, 18 Oct 2000 14:02:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > I was wondering why the traffic TLV of CR-LDP has so many parameters: > > PDR, PBS, CDR, CBS, EBS. > > According to CRLDP, (PDR, PBS) and (CDR, CBS) and (CDR, EBS) > define 3 Token > buckets. While what we need for different scenarios are: > > 1) For GS (Intserv) we need only 2 TBs. > 2) For CLS (Intserv) we need only one TB. > 3) For EF (Diffserv) we need only one TB. > 4) For AF (Diffserv) we need only 2 TBs. > > Don't you think one of the (PBS or EBS) parameters is extra? > If so which one should be used by an LSR? I think that these were originally quite similar to parameters to Juha's single-rate & two-rate three color markers, that have been published as (informational ?) documents. Pasi From owner-mpls@UU.NET Wed Oct 18 15:21:08 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19642 for ; Wed, 18 Oct 2000 15:21:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlmb12514; Wed, 18 Oct 2000 19:20:04 GMT Received: by mail-control.mail.uu.net id QQjlmb07493 for mpls-outgoing; Wed, 18 Oct 2000 19:19:32 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlmb07479 for ; Wed, 18 Oct 2000 19:19:26 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlmb01364 for ; Wed, 18 Oct 2000 19:18:59 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlmb09379 for ; Wed, 18 Oct 2000 19:18:58 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA02044 for mpls@uu.net; Wed, 18 Oct 2000 15:18:57 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlmb07422 for ; Wed, 18 Oct 2000 19:18:31 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlma17671 for ; Wed, 18 Oct 2000 19:14:41 GMT Received: from procyon.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjlma27500 for ; Wed, 18 Oct 2000 19:14:41 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id MAA10315; Wed, 18 Oct 2000 12:14:33 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 12:19:32 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A08@BBY1EXM01> From: Shahram Davari To: "'pasi.vaananen@nokia.com'" , MPLS@UU.NET Subject: RE: Traffic TLV in CR-LDP Date: Wed, 18 Oct 2000 12:19:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Pasi, > -----Original Message----- > From: pasi.vaananen@nokia.com [mailto:pasi.vaananen@nokia.com] > Sent: Wednesday, October 18, 2000 3:03 PM > To: Shahram Davari; MPLS@UU.NET > Subject: RE: Traffic TLV in CR-LDP > > > > I was wondering why the traffic TLV of CR-LDP has so many > parameters: > > > > PDR, PBS, CDR, CBS, EBS. > > > > According to CRLDP, (PDR, PBS) and (CDR, CBS) and (CDR, EBS) > > define 3 Token > > buckets. While what we need for different scenarios are: > > > > 1) For GS (Intserv) we need only 2 TBs. > > 2) For CLS (Intserv) we need only one TB. > > 3) For EF (Diffserv) we need only one TB. > > 4) For AF (Diffserv) we need only 2 TBs. > > > > Don't you think one of the (PBS or EBS) parameters is extra? > > If so which one should be used by an LSR? > > I think that these were originally quite similar to parameters > to Juha's single-rate & two-rate three color markers, that have > been published as (informational ?) documents. > > Pasi I know. But only one of them (eitehr srTCM or trTCM) is required, not both. How should a node find which one is requested? Note that these two metering scheme look very similar, but they are not identical. Regards, -Shahram > From owner-mpls@UU.NET Wed Oct 18 16:37:22 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28588 for ; Wed, 18 Oct 2000 16:37:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlmg16633; Wed, 18 Oct 2000 20:36:41 GMT Received: by mail-control.mail.uu.net id QQjlmg06205 for mpls-outgoing; Wed, 18 Oct 2000 20:36:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlmg06139 for ; Wed, 18 Oct 2000 20:36:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlmg17027 for ; Wed, 18 Oct 2000 20:36:07 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlmg11347 for ; Wed, 18 Oct 2000 20:36:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA13997 for mpls@uu.net; Wed, 18 Oct 2000 16:36:05 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlmg06051 for ; Wed, 18 Oct 2000 20:35:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlmg12982 for ; Wed, 18 Oct 2000 20:34:10 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjlmg16446 for ; Wed, 18 Oct 2000 20:34:09 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA05240; Wed, 18 Oct 2000 13:34:07 -0700 (PDT) Message-ID: <39EE093E.F8F31F20@pluris.com> Date: Wed, 18 Oct 2000 13:34:06 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Eric Gray CC: "MPLS Mailing List (E-mail)" Subject: Re: bug in draft-ietf-mpls-label-encaps-08 References: <4611AD058694D4118FD5009027B0A6625D8B30@ICARIAN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This is exactly what I said before. I believe that there is one implementation out there that does exactly what you wrote below and it is not ours. Bora Eric Gray wrote: > Folks, > > Discussion on this topic has convinced me > that there is a flaw in the MPLS specifications > - though I do not think it should be fixed in > the encaps draft. > > It seems that some people have concluded > that the intention behind defining the explicit > NULL labels was to allow them to be used by an > implementation that does not support PHP. It > is - in retrospect - easy to see why this might > concluded since it is difficult otherwise to be > able to explain why the explicit NULL labels > were defined at all. Without some implied use > for these labels, their value is implementation > specific and the need to specify them nil. > > This is a problem, however, because other > people have assumed that the implementation that > is not able to support PHP will refuse implicit > NULL labels. Making this assumption is useful > to those implementations that rely on PHP because > a reasonable work-around for having an upstream > peer that does not support PHP is to allocate a > label from a special set (similar to the explicit > NULL labels) - but with the added value of being > able to assign specific labels from this set that > help in the forwarding process as well. As an > example, there may be different sets of special > labels corresponding to each possible output > port. If the upstream LSR simply takes the > implicit NULL label signaled and turns it into > a corresponding explicit NULL label in an NHLFE, > then the downstream LSR does not get an explicit > notification of the fact that the upstream LSR > will not be doing PHP. > > This ambiguity should be cleared up. One > possible place to do this would be in the MPLS > architecture draft. > > -- > Eric Gray From owner-mpls@UU.NET Wed Oct 18 17:51:25 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07615 for ; Wed, 18 Oct 2000 17:51:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlml14446; Wed, 18 Oct 2000 21:50:52 GMT Received: by mail-control.mail.uu.net id QQjlml05271 for mpls-outgoing; Wed, 18 Oct 2000 21:50:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlml05259 for ; Wed, 18 Oct 2000 21:50:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlml05247 for ; Wed, 18 Oct 2000 21:50:05 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjlml13035 for ; Wed, 18 Oct 2000 21:50:01 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA58289; Wed, 18 Oct 2000 17:47:41 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200010182147.RAA58289@workhorse.fictitious.org> To: Fred Baker cc: curtis@avici.com, Ping Pan , Randy Bush , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Any SPs using QoS ??? In-reply-to: Your message of "Wed, 18 Oct 2000 19:25:33 PDT." <5.0.0.25.2.20001018192123.03506690@flipper> Date: Wed, 18 Oct 2000 17:47:40 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <5.0.0.25.2.20001018192123.03506690@flipper>, Fred Baker writes: > At 11:36 AM 10/16/00 -0400, Curtis Villamizar wrote: > >ECN is not like FECN and BECN. ECN is used for end-to-end congestion > >avoidance (TCP). The ECN ECT (ECN capable transport) bit is used to > >indicate that the end systems are ECN capable and using ECN. The CE > >(congestion experienced) bit is set by routers in place of a drop to > >indicate that a drop would have occurred. TCP is expected to react as > >if a drop has ocurred, but the retransmission is avoided. > > Actually, I would argue that it is a lot like FECN. The model for FECN > (proposed by Goldstein as I recall) was that it would be received by a > Frame Relay DTE, and be copied into an option in CLNS. CLNS would then > deliver it to the receiving TP-4, which would implement the DEC Bit > algorithm to attempt to adapt transmission rate to the knee (as opposed to > the cliff) of the power curve. DECBIT worked terribly. Are you arguing that IP ECN is like FECN only it works? > In the ECN case, we have a network layer protocol rather than a link layer > protocol, but again the idea is that congestion would be sensed en route > and reported by the network layer (IP) to the receiving transport (TCP), > which would take very similar actions to accomplish the same goal. The link layer was intended to be edge to edge, not end to end. This is the major difference and the reason that MPLS LSRs should not try to somehow spoof ECN. Curtis ps - I think we're off topic for MPLS. IMHO Experimental is fine for now, though Randy seems to disagree. From owner-mpls@UU.NET Wed Oct 18 19:14:19 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16751 for ; Wed, 18 Oct 2000 19:14:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlmq16987; Wed, 18 Oct 2000 23:14:01 GMT Received: by mail-control.mail.uu.net id QQjlmq06890 for mpls-outgoing; Wed, 18 Oct 2000 23:13:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlmq06881 for ; Wed, 18 Oct 2000 23:13:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlmq24110 for ; Wed, 18 Oct 2000 23:12:32 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjlmq12705 for ; Wed, 18 Oct 2000 23:12:32 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Thu, 19 Oct 2000 00:13:41 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id ; Thu, 19 Oct 2000 00:11:54 +0100 Message-ID: To: azinin@cisco.com, xuyg@lucent.com Cc: Vishal.Sharma@tellabs.com, fhujber@hotmail.com, kireeti@juniper.net, mpls@UU.NET Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 00:08:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Alex Zinn wrote: >I wouldn't oversimplify this [NH=> that is, against this statement from Yangguang "In circuit switched network, there should be no assumption about the relation of data plane topology and control plane topology at all."] Don't forget about IGPs and signaling. Alex can you please expand on what you mean by this....taking the following into account line of reasonong? - the OTN is cct-sw/CO/client-layer PDU-structure transparent - the OTN has no practical buffers - IP, ATM, FR, SDH, or whatever is irrelevant as far as the OTN user-plane is concerned. - "server layer trails (in an OTN) = client layer links", and networks operators *will* have to support multiple client layers for a very long time...including some large BW servives directly off the L1 fabric. - above implies no congruent addressing between any pair of client layers or any client layer and the OTN........this implies that the addresing scheme used by the OTN is not related to any clients (ie not from the same addressing space in terms of possible trail connectivity at layer network access points) - it therefore follows (at least to many I speak to who are working on OTN topics) that the signalling protocol and the routing/discovery protocol used in the OTN can be chosen as 'best of breed' to suit its nature, ie cct-sw/CO/user-plane transparent. Obviously different people will have different views of what is best-of-breed here.......and this has not to my knowledge has not even been openly debated so far. - further, the signalling network of the OTN needs to be designed with very high availability/survivability requirements. To achieve this its topology and operating mode are a completely independent facet to how the user-plane is specified for the normal 'client traffic'. regards, neil From owner-mpls@UU.NET Wed Oct 18 20:13:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23193 for ; Wed, 18 Oct 2000 20:13:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlmu16803; Thu, 19 Oct 2000 00:13:26 GMT Received: by mail-control.mail.uu.net id QQjlmu22915 for mpls-outgoing; Thu, 19 Oct 2000 00:12:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlmu22899 for ; Thu, 19 Oct 2000 00:12:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlmu00379 for ; Thu, 19 Oct 2000 00:11:01 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlmu15947 for ; Thu, 19 Oct 2000 00:11:00 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA07484 for mpls@uu.net; Wed, 18 Oct 2000 20:11:00 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlmu22561 for ; Thu, 19 Oct 2000 00:10:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlmu06289 for ; Thu, 19 Oct 2000 00:08:14 GMT Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjlmu09250 for ; Thu, 19 Oct 2000 00:08:13 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA22035; Wed, 18 Oct 2000 17:08:08 -0700 (PDT) Date: Wed, 18 Oct 2000 17:02:05 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <2709.001018@cisco.com> To: neil.2.harrison@bt.com CC: xuyg@lucent.com, Vishal.Sharma@tellabs.com, fhujber@hotmail.com, kireeti@juniper.net, mpls@UU.NET Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, Wednesday, October 18, 2000, 4:08 PM, neil.2.harrison@bt.com wrote: > Alex Zinn wrote: >>I wouldn't oversimplify this [NH=> that is, against this statement from > Yangguang "In circuit switched network, there should be no assumption about > the relation of data plane topology and control plane topology at all."] > Don't forget about IGPs and signaling. > Alex can you please expand on what you mean by this....taking the following > into account line of reasonong? I believe it was explained in the thread quite thoroughly already. In short, we have protocols in the generalized MPLS control plane that will not work over a TCP connection, but will require direct connectivity (through a physical link, LSP, or a GRE tunnel) between boxes. See my comments below as well. > - the OTN is cct-sw/CO/client-layer PDU-structure transparent > - the OTN has no practical buffers There's no requirement for buffering of transit traffic. However, in the case where control channels are allocated from the same pool of fibers (or lambdas), an optical box will have to be able to terminate them. This is also a requirement if you want to implement LMP link testing. > - IP, ATM, FR, SDH, or whatever is irrelevant as far as the OTN > user-plane is concerned. Well... If you use OTN in the overlay model with no dynamic circuit provisioning, then yes. If OTN is a part of your network (i.e., peer model is used) or if dynamic lightpath provisioning is required, then IP becomes very much relevant, since (as far as we are talking about generalized MPLS or MPLambdaS) OTN nodes are going to use IP/MPLS-TE control plane (or its rudimentary version in case of UNI). > - "server layer trails (in an OTN) = client layer links", and networks > operators *will* have to support multiple client layers for a very long > time...including some large BW servives directly off the L1 fabric. Not sure I follow the logic here. Can you elaborate a bit. > - above implies no congruent addressing between any pair of client > layers or any client layer and the OTN........this implies that the > addresing scheme used by the OTN is not related to any clients (ie not from > the same addressing space in terms of possible trail connectivity at layer > network access points) Correct. It does not mean, however, that we need to invent another addressing system. > - it therefore follows (at least to many I speak to who are working on > OTN topics) that the signalling protocol and the routing/discovery protocol > used in the OTN can be chosen as 'best of breed' to suit its nature, ie > cct-sw/CO/user-plane transparent. Obviously different people will have > different views of what is best-of-breed here.......and this has not to my > knowledge has not even been openly debated so far. I believe it has been discussed in a number of forums for quite a long time by now and the de facto consensus is that MPLS-TE control plane with required extensions is the one to go with, where one of the reasons is the presence of implemented and standardized protocols and interoperability. It does not mean, of course, that somebody can develop their own set of proprietary protocols ;) > - further, the signalling network of the OTN needs to be designed with > very high availability/survivability requirements. Right, and this is what IP routing provides us with. > To achieve this its > topology and operating mode are a completely independent facet to how the > user-plane is specified for the normal 'client traffic'. Correct, but again, this does not mean we have to invent another set of protocols. Regards, Alex. From owner-mpls@UU.NET Wed Oct 18 20:46:11 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26809 for ; Wed, 18 Oct 2000 20:46:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlmx05621; Thu, 19 Oct 2000 00:45:44 GMT Received: by mail-control.mail.uu.net id QQjlmw24919 for mpls-outgoing; Thu, 19 Oct 2000 00:44:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlmw24911 for ; Thu, 19 Oct 2000 00:44:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlmw01919 for ; Thu, 19 Oct 2000 00:44:02 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjlmw29484 for ; Thu, 19 Oct 2000 00:44:02 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Thu, 19 Oct 2000 01:43:55 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id <4C8FPQQN>; Thu, 19 Oct 2000 01:43:41 +0100 Message-ID: To: azinin@cisco.com Cc: mpls@UU.NET Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 01:43:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Alex, You asked: > > - "server layer trails (in an OTN) = client layer links", and > networks > > operators *will* have to support multiple client layers for a very long > > time...including some large BW servives directly off the L1 fabric. > > Not sure I follow the logic here. Can you elaborate a bit. > This is a really important point. It is a fundamental characteristic of a layered network architecture. It (and other functional modelling concepts of layered networks) are more fully described in G.805 (ITU) and also in some text books like: - 'Global Information Networking' Varma et al. Artech - Broadband Networking' Reid & Sexton. Artech In essence, if I want to create a topology at some arbitrary layer (in some technology) I can do this by connecting boxes with links to form some sort of graph......this is the simplistic box diagram approach. But each of these links can be provided by a lower layer network, which is itself a topology of boxes and links. And this process recurses until we hit the 'duct'....which is the lowest layer network of all (and which, BTW, determines a bound on the inherited availability performance of all higher layers). Hence, a link connection between 2 nodes at layer N is a small segment of a large trail at layer N. The trail end points in layer N are closely bound to the access points which are the addressable entities of layer N, ie the entities between which we need to determine routing between at layer N. But *each* of the link connections at layer N will generally be provided by a trail at Layer N-1. Hence, the addressable access points of the trail at layer N-1 are clearly not the same as those at Layer N. I have tried to show this nested inter-layer trail relationship below (0 = trail termination point/addressable location of layer network, (X) = switching point in layer network): <----------------------------------Trail at layer N------------------------> 0-----------(X)---------------(X)-----------------------(X)----------------0 / <---------------------> \ / link connection at N \ / \ 0--------(X)---------(X)-----------0 <----trail at N-1---------------> / \ / \ / \ 0 -----(X)----(X)----0 <---trails at N-2-----> / \ / \ etc to duct BTW nested LSPs also fit this model.......but this has not been recognised yet. Neil From owner-mpls@UU.NET Wed Oct 18 21:19:18 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00454 for ; Wed, 18 Oct 2000 21:19:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlmz22969; Thu, 19 Oct 2000 01:18:34 GMT Received: by mail-control.mail.uu.net id QQjlmz09010 for mpls-outgoing; Thu, 19 Oct 2000 01:18:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlmz09005 for ; Thu, 19 Oct 2000 01:18:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlmz02757 for ; Thu, 19 Oct 2000 01:17:56 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlmz19221 for ; Thu, 19 Oct 2000 01:17:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA12635 for mpls@uu.net; Wed, 18 Oct 2000 21:17:55 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlmz08973 for ; Thu, 19 Oct 2000 01:17:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlmz08253 for ; Thu, 19 Oct 2000 01:16:57 GMT Received: from lumen.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjlmz17878 for ; Thu, 19 Oct 2000 01:16:52 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id <4YY6Z2NB>; Wed, 18 Oct 2000 18:16:50 -0700 Message-ID: From: John Drake To: "'neil.2.harrison@bt.com'" , azinin@cisco.com Cc: mpls@UU.NET Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Wed, 18 Oct 2000 18:16:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Neil, I'm not sure how you justify the second half of this assertion. Clearly the authors of the relevant I-Ds as well as other interested parties have recognized the first part of your assertion since the GMPLS work began. Thanks, John -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Wednesday, October 18, 2000 5:44 PM To: azinin@cisco.com Cc: mpls@UU.NET Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh SNIP BTW nested LSPs also fit this model.......but this has not been recognised yet. Neil From owner-mpls@UU.NET Wed Oct 18 22:51:53 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12576 for ; Wed, 18 Oct 2000 22:51:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlnf22194; Thu, 19 Oct 2000 02:51:39 GMT Received: by mail-control.mail.uu.net id QQjlnf27436 for mpls-outgoing; Thu, 19 Oct 2000 02:51:12 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlnf27404 for ; Thu, 19 Oct 2000 02:51:08 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlnf25623 for ; Thu, 19 Oct 2000 02:49:58 GMT Received: from auemlsrv.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQjlnf10972 for ; Thu, 19 Oct 2000 02:49:58 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA03455 for ; Wed, 18 Oct 2000 22:49:57 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id WAA03438; Wed, 18 Oct 2000 22:49:56 -0400 (EDT) Received: from lucent.com ([135.13.45.66]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id WAA02082; Wed, 18 Oct 2000 22:49:53 -0400 (EDT) Message-ID: <39EE614E.F4350AE6@lucent.com> Date: Wed, 18 Oct 2000 22:49:50 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: neil.2.harrison@bt.com, jplang@calient.net, kireeti@juniper.net, mpls@UU.NET Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh References: <2709.001018@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alex, I thought about it. It's actually not true. > > I believe it was explained in the thread quite thoroughly already. > In short, we have protocols in the generalized MPLS control plane > that will not work over a TCP connection, but will require direct > connectivity (through a physical link, LSP, or a GRE tunnel) between > boxes. > Our only concern is OSPF. For example, the transport plane is as below. A------------B | \ | | \ | | ------\ | | \ | C------------D The control plane can be: A------------B | | | C------------D Optical topology are discovered by LMP and disseminated through OSPF Opaque LSA. Even A and D has no direct connectivity in control plane, it still can get optical topology through C. I guess I shouldn't say TCP session (what I was thinking???). They only need IP reachability. This is true for both OSPF and LMP. Yangguang From owner-mpls@UU.NET Wed Oct 18 23:06:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14143 for ; Wed, 18 Oct 2000 23:06:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlng11209; Thu, 19 Oct 2000 03:05:50 GMT Received: by mail-control.mail.uu.net id QQjlng09699 for mpls-outgoing; Thu, 19 Oct 2000 03:05:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlng09687 for ; Thu, 19 Oct 2000 03:05:21 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlng04143 for ; Thu, 19 Oct 2000 03:03:16 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlng14101 for ; Thu, 19 Oct 2000 03:03:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA18564 for mpls@uu.net; Wed, 18 Oct 2000 23:03:15 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlng06876 for ; Thu, 19 Oct 2000 03:02:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlng02977 for ; Thu, 19 Oct 2000 03:02:50 GMT Received: from ce-nfs-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjlng07362 for ; Thu, 19 Oct 2000 03:02:49 GMT Received: from sj-dial-1-8.cisco.com (sj-dial-1-8.cisco.com [171.68.179.9]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA22883; Wed, 18 Oct 2000 20:02:44 -0700 (PDT) Date: Wed, 18 Oct 2000 19:56:32 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <5830.001018@cisco.com> To: neil.2.harrison@bt.com CC: mpls@UU.NET Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, >> > - "server layer trails (in an OTN) = client layer links", and >> networks >> > operators *will* have to support multiple client layers for a very long >> > time...including some large BW servives directly off the L1 fabric. >> >> Not sure I follow the logic here. Can you elaborate a bit. >> > This is a really important point. It is a fundamental > characteristic of a layered network architecture. Got it. I didn't realize what layers you meant. > BTW nested LSPs also fit this model.......but this has not been > recognised yet. It has been, actually. The forwarding adjacencies, LSP hierarchy and generalized MPLS are the mechanism to represent LSPs as links for higher layers, perform signaling of different types of LSPs and LSP nesting. Alex. From owner-mpls@UU.NET Wed Oct 18 23:37:49 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17989 for ; Wed, 18 Oct 2000 23:37:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlni24187; Thu, 19 Oct 2000 03:37:13 GMT Received: by mail-control.mail.uu.net id QQjlni12089 for mpls-outgoing; Thu, 19 Oct 2000 03:36:50 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlni12084 for ; Thu, 19 Oct 2000 03:36:30 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlni18749 for ; Thu, 19 Oct 2000 03:33:56 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlni24831 for ; Thu, 19 Oct 2000 03:33:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA20457 for mpls@uu.net; Wed, 18 Oct 2000 23:33:55 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlni11915 for ; Thu, 19 Oct 2000 03:33:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlni23344 for ; Thu, 19 Oct 2000 03:33:13 GMT Received: from ce-nfs-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjlni18030 for ; Thu, 19 Oct 2000 03:33:12 GMT Received: from sj-dial-1-8.cisco.com (sj-dial-1-8.cisco.com [171.68.179.9]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA05714; Wed, 18 Oct 2000 20:33:02 -0700 (PDT) Date: Wed, 18 Oct 2000 20:26:57 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <18852.001018@cisco.com> To: Yangguang Xu CC: neil.2.harrison@bt.com, jplang@calient.net, kireeti@juniper.net, mpls@UU.NET Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: <39EE614E.F4350AE6@lucent.com> References: <39EE614E.F4350AE6@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yangguang, > Alex, > I thought about it. It's actually not true. The whole thing is not true or something in particular? ;) >> I believe it was explained in the thread quite thoroughly already. >> In short, we have protocols in the generalized MPLS control plane >> that will not work over a TCP connection, but will require direct >> connectivity (through a physical link, LSP, or a GRE tunnel) between >> boxes. >> > Our only concern is OSPF. For example, the transport plane is as below. [...] > Optical topology are discovered by LMP and disseminated through OSPF Opaque LSA. > Even A and D has no direct connectivity in control plane, it still can get > optical topology through C. Just in case below ;) > Wednesday, October 18, 2000, 11:05 AM, Alex Zinin wrote: >> Yangguang, >> One thing that seems interesting to me in the context of optical >> networks is potential possibility to prune the topology of IGP >> adjacencies to minimally necessary (e.g., redundant spanning tree), >> while still announcing TE information about all optical links. >> The state of the links would be defined with protocols like LMP >> or mechanisms integrated into lower layers. This is possible >> because in case of p2p links (valid for ONs), we do not use >> IGP topology database for CSPF. However, we do use it in other >> networks when calculate the paths through multi-access segments. Note, however, that a) no connectivity between A & B, b) direct connectivity between A & B and c) a TCP session between A & B are three "a bit" different things. Also note, that this quite realistic to imagine a box with gmpls control plane but without LMP. Alex. From owner-mpls@UU.NET Thu Oct 19 05:29:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19365 for ; Thu, 19 Oct 2000 05:29:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlof13613; Thu, 19 Oct 2000 09:29:24 GMT Received: by mail-control.mail.uu.net id QQjlof11076 for mpls-outgoing; Thu, 19 Oct 2000 09:29:00 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlof11071 for ; Thu, 19 Oct 2000 09:28:52 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlof06525 for ; Thu, 19 Oct 2000 09:27:41 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjlof11284 for ; Thu, 19 Oct 2000 09:27:40 GMT Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP; Thu, 19 Oct 2000 10:21:42 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id ; Thu, 19 Oct 2000 10:21:36 +0100 Message-ID: To: jdrake@calient.net, azinin@cisco.com Cc: mpls@UU.NET Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 10:21:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk John Drake wrote: > I'm not sure how you justify the second half of this assertion. [NH=> that > BTW nested LSPs also fit this model.......but this has not been recognised > yet. ] > > Clearly the authors of the relevant I-Ds as well as other interested > parties have recognized the first part of your assertion since the > GMPLS work began. > NH=> This is based on requiring to have independence between layer networks and that overhead which is relevant only to a given layer network has fixed/known points of generation/termination. This is not so much an issue for GMPLS (ie a philosophy of a common control-plane across L1/2/3) but more about nested LSPs from a user-plane perspective and, specifically, the OH fields in the shim header. Let me give you 3 examples of what I mean, and all stem from the "server layer trails = client layer links" relationship between layer networks: - TTL: A link connection between 2 nodes in layer N is 1 hop in layer N. The fact that there may be a further LSP (ie trail), at layer N-1, serving this link connection and having its own X label swapping links connections should not be known to layer N. This relationship can recurse. One should therefore not try and predict the TTL at Layer N (in terms of some prior decrement for the single link connection) due to nested (latent) LSPs (and their hops) below it. This may become quite important when considering (future) inter-domain LSPs, eg when a private network running MPLS want to tunnel its LSPs across one or more intervening operator MPLS domains. Prior guessing of TTLs would also be a potential problem when one considers restoration, ie the server LSP hop count may change, but the client remains at 1 hop. In essence, the TTL of LSP N is relevant only to LSP N and should not make any assumptions about hops in any server LSPs. - Pipe vs Uniform model: Here I am considering the Exp bits. Again consider a private network tunnel across one of more operators networks. The private network may want to keep its own Exp LSP codings which may not have any relationship to how the operators use these bits. So all the private network may require from the operator(s) is some LSP SLA that covers some notions of 'effective LSP BW' and LSP survivability. - PHP: If an LSP is supposed to run across LSR1-2-3-4, but PHP is done at LSR 3 then this terminates the LSP header at LSR3. So in reality the trail does not extend to LSR4. This may cause some problems when one wants to associate consistent functional processing (ie defect handling, restoration between 2 points, client/server adaptation, etc) with a known trail termination point. John, I hope the above is clear as to what my concerns are. Which, in summary, can be stated as we really ought to have some rules governing where trail OH is generated and terminated and those rules ought to be employed consistently. Alex.....I also saw you tagged mail on this too this morning, wrt to saying that nested LSP has been thought about. I think you are talking about the control-plane aspacts (and I agree its has been here) whilst I am talking about the user-plane aspects here (in terms of where OH functionality is consistently generated/terminated and processed). Enjoyed the debate.....thanks for all comments. Neil > > From owner-mpls@UU.NET Thu Oct 19 06:20:15 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24731 for ; Thu, 19 Oct 2000 06:20:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjloj25733; Thu, 19 Oct 2000 10:20:04 GMT Received: by mail-control.mail.uu.net id QQjloj25692 for mpls-outgoing; Thu, 19 Oct 2000 10:19:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjloj25687 for ; Thu, 19 Oct 2000 10:19:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjloj13743 for ; Thu, 19 Oct 2000 10:18:52 GMT From: darren.freeland@bt.com Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjloj17170 for ; Thu, 19 Oct 2000 10:18:51 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by gollum (local) with ESMTP; Thu, 19 Oct 2000 10:55:40 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <4W3A9L75>; Thu, 19 Oct 2000 10:53:42 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C70D@mbtlipnt01.btlabs.bt.co.uk> To: azinin@cisco.com, neil.2.harrison@bt.com Cc: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 10:53:01 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Alex, >>> - "server layer trails (in an OTN) = client layer links", and >>> networks operators *will* have to support multiple client >>> layers for a very long time...including some large BW servives >>> directly off the L1 fabric. >>> >>> This is a really important point. It is a fundamental >>> characteristic of a layered network architecture. > > [AZ] Got it. I didn't realize what layers you meant. This is the first time I have actually seen anyone on the MPLS or IPO lists publicly acknowledge the "client layer links = server layer trails" fact. I assume then that you now also acknowledge the single control plane 'Peer' model as being impractical? Okay, using a single 'best of breed' routing protocol and a single 'best of breed' signalling protocol across the IP and optical layers may be feasible (I stress may), but it follows from the above simple concept (as Neil Harrison stated before) that the addresing scheme used by the optical layer cannot be related to any particular clients (ie not from the same addressing space in terms of possible trail connectivity at layer network access points). Sure this would not be the case if IP was the only client of the optical layer, but (*reality check*), operators WILL still be making most of their revenue from non-IP clients for a long time to come, and therefore an optical transport network WILL have to support multiple clients. Are we now seeing a realisation of this in the IETF? I think it's obvious that what was defined as the 'Overlay' model in draft-awduche-mpls-te-optical-02.txt and draft-many-ip-optical-framework-01.txt must be developed first. Cheers, Darren. From owner-mpls@UU.NET Thu Oct 19 08:13:26 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10918 for ; Thu, 19 Oct 2000 08:13:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjloq26348; Thu, 19 Oct 2000 12:12:59 GMT Received: by mail-control.mail.uu.net id QQjloq25223 for mpls-outgoing; Thu, 19 Oct 2000 12:12:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjloq25218 for ; Thu, 19 Oct 2000 12:12:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjloq02968 for ; Thu, 19 Oct 2000 12:12:20 GMT Received: from md4.vsnl.net.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: md4.vsnl.net.in [202.54.6.60]) id QQjloq25305 for ; Thu, 19 Oct 2000 12:12:17 GMT Received: from netlab.hcltech.com ([203.199.220.168]) by md4.vsnl.net.in (8.9.3/8.9.3) with ESMTP id RAA04509 for ; Thu, 19 Oct 2000 17:47:11 +0530 (IST) Received: from krish (krish [192.168.201.29]) by netlab.hcltech.com (8.9.3/8.9.3) with SMTP id RAA18421 for ; Thu, 19 Oct 2000 17:44:36 +0530 Date: Thu, 19 Oct 2000 17:44:36 +0530 Message-Id: <200010191214.RAA18421@netlab.hcltech.com> X-Sender: krish@203.197.145.66 X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mpls@UU.NET From: Srikrishnan Venkataraman Subject: draft-kompella-mpls-bundle(03) Sender: owner-mpls@UU.NET Precedence: bulk sec 3.2 if a component link is numbered, it says that he link has a dedicated control channel. reading further in the same paragraph, i get an impression that each numbered component link must have a dedicated control channel. please clarify?? also if in a bundle, i've a mix of numbered /un numbered component links, then all un-numbered links share a control channel. -krish From owner-mpls@UU.NET Thu Oct 19 12:06:07 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17629 for ; Thu, 19 Oct 2000 12:06:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpg06299; Thu, 19 Oct 2000 16:05:10 GMT Received: by mail-control.mail.uu.net id QQjlpg01091 for mpls-outgoing; Thu, 19 Oct 2000 16:04:41 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlpg01068 for ; Thu, 19 Oct 2000 16:04:40 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlpg18226 for ; Thu, 19 Oct 2000 16:04:28 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f125.law9.hotmail.com [64.4.9.125]) id QQjlpg09533 for ; Thu, 19 Oct 2000 16:04:28 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Oct 2000 09:04:27 -0700 Received: from 128.230.109.16 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 19 Oct 2000 16:04:27 GMT X-Originating-IP: [128.230.109.16] From: "Mike Badil" To: mpls@UU.NET Subject: Traffic engineering and RSVP Date: Thu, 19 Oct 2000 12:04:27 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Oct 2000 16:04:27.0390 (UTC) FILETIME=[41B339E0:01C039E6] Sender: owner-mpls@UU.NET Precedence: bulk Hi I confused when I read traffic engineering with MPLS. My question is: MPLS is combination of layer 2 swithing and layer 3 routing. Traffic eng. is part of layer 3. In MPLS route(LSP) is established in advance according to the constraints. in other word, instead of choosing shortest path, it choose the path which satisfy its requirments, and to make link utulization better. In order to have done this with MPLS there are some works which say that OSPF,IS-IS can be modified by adding constraint to it. That is clear so far, I wondering that whether we can have those traffic engineering conditions be satisfied by other tech. For example; RSVP-Intserv set up route in advance also. If we use extended OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, we can choose the path which satisfy our constraints instead of choosing Shortest path. Link load balancing can be done as in MPLS. So most of traffic engineering requirements will be satisfied.(let don't consider scalibility problem with RSVP now). Or it can work any other technology which use RSVP. What am I missing here? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Thu Oct 19 12:17:14 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19701 for ; Thu, 19 Oct 2000 12:17:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlph12129; Thu, 19 Oct 2000 16:16:21 GMT Received: by mail-control.mail.uu.net id QQjlph03245 for mpls-outgoing; Thu, 19 Oct 2000 16:16:01 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlph03217 for ; Thu, 19 Oct 2000 16:15:49 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlph13808 for ; Thu, 19 Oct 2000 16:15:25 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlph05306 for ; Thu, 19 Oct 2000 16:15:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA13646 for mpls@uu.net; Thu, 19 Oct 2000 12:15:24 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlpg02757 for ; Thu, 19 Oct 2000 16:14:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlpg23391 for ; Thu, 19 Oct 2000 16:14:20 GMT Received: from ce-nfs-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjlpg08968 for ; Thu, 19 Oct 2000 16:14:20 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA20901; Thu, 19 Oct 2000 09:14:17 -0700 (PDT) Date: Thu, 19 Oct 2000 09:08:17 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <1380.001019@cisco.com> To: darren.freeland@bt.com CC: neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: <71DA16F18D32D2119A1D0000F8FE9A940920C70D@mbtlipnt01.btlabs.bt.co.uk> References: <71DA16F18D32D2119A1D0000F8FE9A940920C70D@mbtlipnt01.btlabs.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Darren! > Hi Alex, >>>> - "server layer trails (in an OTN) = client layer links", and >>>> networks operators *will* have to support multiple client >>>> layers for a very long time...including some large BW servives >>>> directly off the L1 fabric. >>>> >>>> This is a really important point. It is a fundamental >>>> characteristic of a layered network architecture. >> >> [AZ] Got it. I didn't realize what layers you meant. > This is the first time I have actually seen anyone on the MPLS or IPO lists > publicly acknowledge the "client layer links = server layer trails" fact. I think this was quite clear. If you establish an LSP across your optical network, it will look like a link to your client. > I assume then that you now also acknowledge the single control plane 'Peer' > model as being impractical? Wrong assumption. > Okay, using a single 'best of breed' routing > protocol Wrong assumption (OSPF+ISIS). > and a single 'best of breed' signalling protocol Wrong assumption (RSVP-TE + CR-LDP). > across the IP and > optical layers may be feasible (I stress may), but it follows from the above > simple concept (as Neil Harrison stated before) that the addresing scheme > used by the optical layer cannot be related to any particular clients (ie > not from the same addressing space in terms of possible trail connectivity > at layer network access points). Wrong assumption. I does not have to be related, but it can. > Sure this would not be the case if IP was > the only client of the optical layer, but (*reality check*), operators WILL > still be making most of their revenue from non-IP clients for a long time to > come, and therefore an optical transport network WILL have to support > multiple clients. Do you mean there is a contradiction with the work currently being done? > Are we now seeing a realisation of this in the IETF? I think it's obvious > that what was defined as the 'Overlay' model in > draft-awduche-mpls-te-optical-02.txt and > draft-many-ip-optical-framework-01.txt must be developed first. I would say we should develop the OTN control plane first. Regards, Alex. From owner-mpls@UU.NET Thu Oct 19 12:20:50 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20467 for ; Thu, 19 Oct 2000 12:20:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlph02487; Thu, 19 Oct 2000 16:20:18 GMT Received: by mail-control.mail.uu.net id QQjlph03713 for mpls-outgoing; Thu, 19 Oct 2000 16:19:51 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlph03704 for ; Thu, 19 Oct 2000 16:19:43 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlph21752 for ; Thu, 19 Oct 2000 16:18:51 GMT Received: from server.nayna.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) id QQjlph16173 for ; Thu, 19 Oct 2000 16:18:51 GMT Received: from nayna.com (sonicwall [64.145.162.226]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id JAA17444; Thu, 19 Oct 2000 09:18:49 -0700 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be nayna.com Message-ID: <39EF0348.E0867574@nayna.com> Date: Thu, 19 Oct 2000 09:20:56 -0500 From: Sudheer Dharanikota X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Badil CC: mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: Content-Type: multipart/mixed; boundary="------------1424D84CCAA587F16A3FF9BA" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------1424D84CCAA587F16A3FF9BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Badil wrote: > > Hi > > I confused when I read traffic engineering with MPLS. > > My question is: > > MPLS is combination of layer 2 swithing and layer 3 routing. Traffic eng. is > part of layer 3. In MPLS route(LSP) is established in advance according to > the constraints. in other word, instead of choosing shortest path, it choose > the path which satisfy its requirments, and to make link utulization better. > In order to have done this with MPLS there are some works which say that > OSPF,IS-IS can be modified by adding constraint to it. > > That is clear so far, > > I wondering that whether we can have those traffic engineering conditions be > satisfied by other tech. > > For example; RSVP-Intserv set up route in advance also. If we use extended > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > we can choose the path which satisfy our constraints instead of choosing > Shortest path. Link load balancing can be done as in MPLS. So most of > traffic engineering requirements will be satisfied.(let don't consider > scalibility problem with RSVP now). Or it can work any other technology > which use RSVP. > The problem is in applying filter at every node to make sure your IP packet is following the selected path. Hence data path becomes slow. - sudheer > What am I missing here? > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. --------------1424D84CCAA587F16A3FF9BA Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dharanikota;Sudheer tel;cell:408-829-8812 tel;work:408-956-8000 X357 x-mozilla-html:TRUE org:Nayna Networks adr:;;;;;; version:2.1 email;internet:sudheer@nayna.com fn:Sudheer Dharanikota end:vcard --------------1424D84CCAA587F16A3FF9BA-- From owner-mpls@UU.NET Thu Oct 19 12:21:58 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20699 for ; Thu, 19 Oct 2000 12:21:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlph19722; Thu, 19 Oct 2000 16:21:18 GMT Received: by mail-control.mail.uu.net id QQjlph03920 for mpls-outgoing; Thu, 19 Oct 2000 16:20:50 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlph03915 for ; Thu, 19 Oct 2000 16:20:42 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlph21256 for ; Thu, 19 Oct 2000 16:20:26 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlph20508 for ; Thu, 19 Oct 2000 16:20:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA14752 for mpls@uu.net; Thu, 19 Oct 2000 12:20:24 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlph03715 for ; Thu, 19 Oct 2000 16:19:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlph09145 for ; Thu, 19 Oct 2000 16:19:24 GMT Received: from lumen.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjlph16937 for ; Thu, 19 Oct 2000 16:19:22 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id <4YY6ZJ1C>; Thu, 19 Oct 2000 09:19:21 -0700 Message-ID: From: John Drake To: "'darren.freeland@bt.com'" , azinin@cisco.com, neil.2.harrison@bt.com Cc: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 09:19:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Darren, GMPLS allows, but does not require, multiple types of hierarchically related LSPs to exist in a single instance of a link state database. If a network owner decides to have MPLS devices supporting multiple types of LSPs in the same instance of a link state database, then his network is an instantiation the peer model. From my perspective, the focus of the peer model is to facilitate how a network owner constructs his network most efficiently and not how he represents it to his customers. The latter is typically done using multiple service definitions. For example, a few years ago, one would build an IP service using routers mesh connected in an overlay on top of a PNNI transport network. This was perceived as an exquisitely painful way of doing things and led directly to the development of MPLS. I.e., extend the IP control plane to support traffic engineering and then have the ATM switches implement MPLS. This eliminates the artificial overlay boundary between IP routers and ATM switches. (On the other hand, there would still be operational benefits to using MPLS to control the ATM switches even if the network owner wished to maintain this overlay boundary.) GMPLS just extends this concept to encompass other types of transport networks. Thanks, John -----Original Message----- From: darren.freeland@bt.com [mailto:darren.freeland@bt.com] Sent: Thursday, October 19, 2000 2:53 AM To: azinin@cisco.com; neil.2.harrison@bt.com Cc: mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Hi Alex, >>> - "server layer trails (in an OTN) = client layer links", and >>> networks operators *will* have to support multiple client >>> layers for a very long time...including some large BW servives >>> directly off the L1 fabric. >>> >>> This is a really important point. It is a fundamental >>> characteristic of a layered network architecture. > > [AZ] Got it. I didn't realize what layers you meant. This is the first time I have actually seen anyone on the MPLS or IPO lists publicly acknowledge the "client layer links = server layer trails" fact. I assume then that you now also acknowledge the single control plane 'Peer' model as being impractical? Okay, using a single 'best of breed' routing protocol and a single 'best of breed' signalling protocol across the IP and optical layers may be feasible (I stress may), but it follows from the above simple concept (as Neil Harrison stated before) that the addresing scheme used by the optical layer cannot be related to any particular clients (ie not from the same addressing space in terms of possible trail connectivity at layer network access points). Sure this would not be the case if IP was the only client of the optical layer, but (*reality check*), operators WILL still be making most of their revenue from non-IP clients for a long time to come, and therefore an optical transport network WILL have to support multiple clients. Are we now seeing a realisation of this in the IETF? I think it's obvious that what was defined as the 'Overlay' model in draft-awduche-mpls-te-optical-02.txt and draft-many-ip-optical-framework-01.txt must be developed first. Cheers, Darren. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Thu Oct 19 12:43:26 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25372 for ; Thu, 19 Oct 2000 12:43:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpi04825; Thu, 19 Oct 2000 16:42:43 GMT Received: by mail-control.mail.uu.net id QQjlpi05484 for mpls-outgoing; Thu, 19 Oct 2000 16:42:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlpi05476 for ; Thu, 19 Oct 2000 16:42:21 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlpi17638 for ; Thu, 19 Oct 2000 16:41:46 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlpi24678 for ; Thu, 19 Oct 2000 16:41:46 GMT Received: from tellium.com ([192.168.24.222]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9JGY4q01468; Thu, 19 Oct 2000 12:34:04 -0400 (EDT) Message-ID: <39EF2443.B6974EC2@tellium.com> Date: Thu, 19 Oct 2000 12:41:39 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Drake CC: "'darren.freeland@bt.com'" , azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, John Drake wrote: > > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) In the case of IP over optical, I would just like to add that once you do have an IP-centric control plane within optical networks, you could have routing between IP and optical network that in fact supports the overlay model, alleviating the scalability concerns that arise with IP over ATM model described above. It's then a question of the coupling between the IP and optical control planes. This can be as loose or tight as you want, for example, supporting a UNI that separates the control planes, or the peer model without any separation. I do agree that if you considered other types of clients, the peer model constructs don't seem practical. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Oct 19 13:01:07 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29288 for ; Thu, 19 Oct 2000 13:01:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpk27433; Thu, 19 Oct 2000 17:00:16 GMT Received: by mail-control.mail.uu.net id QQjlpj06830 for mpls-outgoing; Thu, 19 Oct 2000 16:59:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlpj06819 for ; Thu, 19 Oct 2000 16:59:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlpj09760 for ; Thu, 19 Oct 2000 16:59:08 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlpj25079 for ; Thu, 19 Oct 2000 16:59:07 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA21226 for mpls@uu.net; Thu, 19 Oct 2000 12:59:07 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlpj06752 for ; Thu, 19 Oct 2000 16:58:39 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlpj23564 for ; Thu, 19 Oct 2000 16:58:31 GMT Received: from lumen.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjlpj14671 for ; Thu, 19 Oct 2000 16:58:30 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id <4YY6ZJ2S>; Thu, 19 Oct 2000 09:58:28 -0700 Message-ID: From: John Drake To: "'Bala Rajagopalan'" Cc: "'darren.freeland@bt.com'" , azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 09:58:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Bala, I think that there's a big difference between the service interface offered to a user (aka the front end) and the interface that a service device uses to attach to the rest of the network (aka the back end). There's no reason why the back end couldn't be GMPLS in peer mode even if the front end was something silly like ATM UNI. Thanks, John -----Original Message----- From: Bala Rajagopalan [mailto:braja@tellium.com] Sent: Thursday, October 19, 2000 9:42 AM To: John Drake Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh Hello, John Drake wrote: > > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) In the case of IP over optical, I would just like to add that once you do have an IP-centric control plane within optical networks, you could have routing between IP and optical network that in fact supports the overlay model, alleviating the scalability concerns that arise with IP over ATM model described above. It's then a question of the coupling between the IP and optical control planes. This can be as loose or tight as you want, for example, supporting a UNI that separates the control planes, or the peer model without any separation. I do agree that if you considered other types of clients, the peer model constructs don't seem practical. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Oct 19 13:01:28 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29371 for ; Thu, 19 Oct 2000 13:01:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpk18560; Thu, 19 Oct 2000 17:00:56 GMT Received: by mail-control.mail.uu.net id QQjlpk08776 for mpls-outgoing; Thu, 19 Oct 2000 17:00:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlpk08759 for ; Thu, 19 Oct 2000 17:00:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlpj12399 for ; Thu, 19 Oct 2000 16:59:31 GMT From: darren.freeland@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjlpj25875 for ; Thu, 19 Oct 2000 16:59:31 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Thu, 19 Oct 2000 17:52:16 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Thu, 19 Oct 2000 17:52:19 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C719@mbtlipnt01.btlabs.bt.co.uk> To: azinin@cisco.com Cc: neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 17:51:03 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Alex, > If you establish an LSP across your > optical network, it will look like a link to your client. Indeed - so we agree that the link could consist of a number of trails in the server layer. Which means that addressing cannot be congruent across client and server layers. Which means that your single control plane 'Peer' model is impractical in a multi-client environment. I don't see how you can agree on the 1st part but not on the 2nd. Maybe I'm missing something, if so please explain. >>> Okay, using a single 'best of breed' routing >>> protocol > > Wrong assumption (OSPF+ISIS). >>> and a single 'best of breed' signalling protocol > > Wrong assumption (RSVP-TE + CR-LDP). This is something that I haven't understood since I began following IETF work. Right from the outset, it has been assumed that these particular IP routing and signalling protocols will be used for the optical layer control plane. As far as I can see, these assumptions were made before any consideration was given to the requirements of the optical layer. If I am wrong, then why aren't these requirements documented in an internet draft? Don't get me wrong, I am not saying that these protocols (with appropriate extensions of course) are not up to the job - whether they will be or not is not the point here. What I am saying is that IETF work on the optical layer has started out by saying "these are the answers" before having fully asked the questions. That apart, I would also question your choice of control plane facets given that there is no relationship between IP and OTN user planes. Note that ITU-T are developing the OTN user plane in G.709. In which IP packets will be treated as any other client and carried with a defined frame structure. >>> it follows from the above simple concept >>> that the addresing scheme used by the optical layer >>> cannot be related to any particular clients (ie not from >>> the same addressing space in terms of possible trail >>> connectivity at layer network access points). > > Wrong assumption. > I does not have to be related, but it can. If an operator wants his optical transport network to be single client, then yes it can be related. This would be your 'Peer' model. As an operator, I do not want my OTN to be single client. Therefore I do not want congruent addressing across my OTN and ANY client layer. I'm sure I'm not the only one who holds this view. >>> Sure this would not be the case if IP was >>> the only client of the optical layer, but (*reality check*), operators WILL >>> still be making most of their revenue from non-IP clients for a long time to >>> come, and therefore an optical transport network WILL have to support >>> multiple clients. > > Do you mean there is a contradiction with > the work currently being done? Do you mean that the work currently being done supports an OTN that can't have multiple clients? As an operator with many clients and not just IP, I can't support that. > I would say we should develop the OTN control plane first. Indeed :) Wouldn't it be logical to have a defined set of requirements from which the control could be developed though? Sure would make life a lot easier. Regards, Darren. -------------------------------------------- > Disclaimer > > "The information and statements in this > email are supplied and made in good faith > and without prejudice. They do not > represent BT's only or final view or > position and are subject to any change > that BT may wish to make (including a > complete reversal). BT will not be liable > for any action you take or not take based > upon the contents of this email". -------------------------------------------- From owner-mpls@UU.NET Thu Oct 19 13:30:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03416 for ; Thu, 19 Oct 2000 13:30:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpl16560; Thu, 19 Oct 2000 17:29:33 GMT Received: by mail-control.mail.uu.net id QQjlpl20969 for mpls-outgoing; Thu, 19 Oct 2000 17:29:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlpl20963 for ; Thu, 19 Oct 2000 17:28:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlpl07340 for ; Thu, 19 Oct 2000 17:27:06 GMT From: darren.freeland@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjlpl12507 for ; Thu, 19 Oct 2000 17:27:06 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Thu, 19 Oct 2000 18:22:27 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <4W3A9ZDL>; Thu, 19 Oct 2000 18:21:53 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C71E@mbtlipnt01.btlabs.bt.co.uk> To: jdrake@calient.net, braja@tellium.com Cc: azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 18:21:05 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi John, At the risk of sounding repetitous ... >> There's no reason why the back >> end couldn't be GMPLS in peer mode I believe there is a reason. And I've yet to be convinced otherwise by anyone. The way I see it, peer model = single control plane. Single control plane = common addressing, signalling, & routing. Common addressing = only possible if the OTN has a single client. This has been explained in the recent "server layer trails = client layer links" links discussions => i.e. common addressing not possible in a multi-client OTN => i.e. peer model impractical in a multi-client OTN. I think this fundamental issue has to be recognised. Regards, Darren. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: 19 October 2000 17:58 To: 'Bala Rajagopalan' Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Bala, I think that there's a big difference between the service interface offered to a user (aka the front end) and the interface that a service device uses to attach to the rest of the network (aka the back end). There's no reason why the back end couldn't be GMPLS in peer mode even if the front end was something silly like ATM UNI. Thanks, John -----Original Message----- From: Bala Rajagopalan [mailto:braja@tellium.com] Sent: Thursday, October 19, 2000 9:42 AM To: John Drake Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh Hello, John Drake wrote: > > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) In the case of IP over optical, I would just like to add that once you do have an IP-centric control plane within optical networks, you could have routing between IP and optical network that in fact supports the overlay model, alleviating the scalability concerns that arise with IP over ATM model described above. It's then a question of the coupling between the IP and optical control planes. This can be as loose or tight as you want, for example, supporting a UNI that separates the control planes, or the peer model without any separation. I do agree that if you considered other types of clients, the peer model constructs don't seem practical. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Oct 19 13:30:18 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03457 for ; Thu, 19 Oct 2000 13:30:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpl01307; Thu, 19 Oct 2000 17:29:21 GMT Received: by mail-control.mail.uu.net id QQjlpl20960 for mpls-outgoing; Thu, 19 Oct 2000 17:28:59 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlpl20930 for ; Thu, 19 Oct 2000 17:28:47 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlpl21188 for ; Thu, 19 Oct 2000 17:27:26 GMT From: darren.freeland@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjlpl10438 for ; Thu, 19 Oct 2000 17:27:25 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 19 Oct 2000 18:15:24 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Thu, 19 Oct 2000 18:15:22 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C71D@mbtlipnt01.btlabs.bt.co.uk> To: braja@tellium.com, jdrake@calient.net Cc: azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 18:14:07 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Bala, I agree totally with what you said. I think I perhaps gave the impression to Alex and John that I am against an IP-centric control plane. This is not the case - I'm not against any type of control plane just yet. My first point is that we have to fully understand the requirements of the optical layer before we decide upon which protocols to use for it. My second point is as you stated - the peer model is impractical for an operator who wants to have a multi-client OTN (whether the control plane is IP-centric or not). I would like to see some more debate on both these points, because I'm sure there are many keeping quite who have strong views on both. Regards, Darren. -----Original Message----- From: Bala Rajagopalan [mailto:braja@tellium.com] Sent: 19 October 2000 17:42 To: John Drake Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh Hello, John Drake wrote: > > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) In the case of IP over optical, I would just like to add that once you do have an IP-centric control plane within optical networks, you could have routing between IP and optical network that in fact supports the overlay model, alleviating the scalability concerns that arise with IP over ATM model described above. It's then a question of the coupling between the IP and optical control planes. This can be as loose or tight as you want, for example, supporting a UNI that separates the control planes, or the peer model without any separation. I do agree that if you considered other types of clients, the peer model constructs don't seem practical. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Thu Oct 19 13:36:49 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04310 for ; Thu, 19 Oct 2000 13:36:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpm11102; Thu, 19 Oct 2000 17:35:41 GMT Received: by mail-control.mail.uu.net id QQjlpm21296 for mpls-outgoing; Thu, 19 Oct 2000 17:34:58 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlpm21291 for ; Thu, 19 Oct 2000 17:34:50 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlpm08951 for ; Thu, 19 Oct 2000 17:31:06 GMT Received: from alemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQjlpm04411 for ; Thu, 19 Oct 2000 17:31:06 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA05728 for ; Thu, 19 Oct 2000 13:31:05 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA05718 for ; Thu, 19 Oct 2000 13:31:05 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA29835; Thu, 19 Oct 2000 13:31:04 -0400 (EDT) Message-ID: <39EF2FD8.87AAFA17@lucent.com> Date: Thu, 19 Oct 2000 13:31:04 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Should peer/overaly model the choice of service providers according to their business models? Yangguang John Drake wrote: > > Darren, > > GMPLS allows, but does not require, multiple types of hierarchically related > LSPs to exist in a single instance of a link state database. If a network > owner decides to have MPLS devices supporting multiple types of LSPs in the > same instance of a link state database, then his network is an instantiation > the peer model. > > From my perspective, the focus of the peer model is to facilitate how a > network owner constructs his network most efficiently and not how he > represents it to his customers. The latter is typically done using multiple > service definitions. > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) > > GMPLS just extends this concept to encompass other types of transport > networks. > > Thanks, > > John > > -----Original Message----- > From: darren.freeland@bt.com [mailto:darren.freeland@bt.com] > Sent: Thursday, October 19, 2000 2:53 AM > To: azinin@cisco.com; neil.2.harrison@bt.com > Cc: mpls@UU.NET; ip-optical@lists.bell-labs.com > Subject: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes > From Pittsburgh > > Hi Alex, > > >>> - "server layer trails (in an OTN) = client layer links", and > >>> networks operators *will* have to support multiple client > >>> layers for a very long time...including some large BW servives > >>> directly off the L1 fabric. > >>> > >>> This is a really important point. It is a fundamental > >>> characteristic of a layered network architecture. > > > > [AZ] Got it. I didn't realize what layers you meant. > > This is the first time I have actually seen anyone on the MPLS or IPO lists > publicly acknowledge the "client layer links = server layer trails" fact. I > assume then that you now also acknowledge the single control plane 'Peer' > model as being impractical? Okay, using a single 'best of breed' routing > protocol and a single 'best of breed' signalling protocol across the IP and > optical layers may be feasible (I stress may), but it follows from the above > simple concept (as Neil Harrison stated before) that the addresing scheme > used by the optical layer cannot be related to any particular clients (ie > not from the same addressing space in terms of possible trail connectivity > at layer network access points). Sure this would not be the case if IP was > the only client of the optical layer, but (*reality check*), operators WILL > still be making most of their revenue from non-IP clients for a long time to > come, and therefore an optical transport network WILL have to support > multiple clients. > > Are we now seeing a realisation of this in the IETF? I think it's obvious > that what was defined as the 'Overlay' model in > draft-awduche-mpls-te-optical-02.txt and > draft-many-ip-optical-framework-01.txt must be developed first. > > Cheers, > Darren. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Thu Oct 19 13:42:01 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05091 for ; Thu, 19 Oct 2000 13:42:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpm05386; Thu, 19 Oct 2000 17:41:26 GMT Received: by mail-control.mail.uu.net id QQjlpm21539 for mpls-outgoing; Thu, 19 Oct 2000 17:40:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlpm21531 for ; Thu, 19 Oct 2000 17:40:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlpm04907 for ; Thu, 19 Oct 2000 17:36:48 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlpm13048 for ; Thu, 19 Oct 2000 17:36:47 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA28147 for mpls@uu.net; Thu, 19 Oct 2000 13:36:46 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlpm21433 for ; Thu, 19 Oct 2000 17:36:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlpm26146 for ; Thu, 19 Oct 2000 17:33:26 GMT Received: from lumen.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjlpm23357 for ; Thu, 19 Oct 2000 17:33:25 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id <4YY6ZJNT>; Thu, 19 Oct 2000 10:33:23 -0700 Message-ID: From: John Drake To: "'darren.freeland@bt.com'" , braja@tellium.com Cc: azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 10:33:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Whatever -----Original Message----- From: darren.freeland@bt.com [mailto:darren.freeland@bt.com] Sent: Thursday, October 19, 2000 10:21 AM To: John Drake; braja@tellium.com Cc: azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Hi John, At the risk of sounding repetitous ... >> There's no reason why the back >> end couldn't be GMPLS in peer mode I believe there is a reason. And I've yet to be convinced otherwise by anyone. The way I see it, peer model = single control plane. Single control plane = common addressing, signalling, & routing. Common addressing = only possible if the OTN has a single client. This has been explained in the recent "server layer trails = client layer links" links discussions => i.e. common addressing not possible in a multi-client OTN => i.e. peer model impractical in a multi-client OTN. I think this fundamental issue has to be recognised. Regards, Darren. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: 19 October 2000 17:58 To: 'Bala Rajagopalan' Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Bala, I think that there's a big difference between the service interface offered to a user (aka the front end) and the interface that a service device uses to attach to the rest of the network (aka the back end). There's no reason why the back end couldn't be GMPLS in peer mode even if the front end was something silly like ATM UNI. Thanks, John -----Original Message----- From: Bala Rajagopalan [mailto:braja@tellium.com] Sent: Thursday, October 19, 2000 9:42 AM To: John Drake Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh Hello, John Drake wrote: > > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) In the case of IP over optical, I would just like to add that once you do have an IP-centric control plane within optical networks, you could have routing between IP and optical network that in fact supports the overlay model, alleviating the scalability concerns that arise with IP over ATM model described above. It's then a question of the coupling between the IP and optical control planes. This can be as loose or tight as you want, for example, supporting a UNI that separates the control planes, or the peer model without any separation. I do agree that if you considered other types of clients, the peer model constructs don't seem practical. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Oct 19 13:53:28 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06577 for ; Thu, 19 Oct 2000 13:53:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpn22068; Thu, 19 Oct 2000 17:52:21 GMT Received: by mail-control.mail.uu.net id QQjlpn22564 for mpls-outgoing; Thu, 19 Oct 2000 17:51:47 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlpn22557 for ; Thu, 19 Oct 2000 17:51:46 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlpn05899 for ; Thu, 19 Oct 2000 17:50:32 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlpn16538 for ; Thu, 19 Oct 2000 17:50:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA01109 for mpls@uu.net; Thu, 19 Oct 2000 13:50:31 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlpn22368 for ; Thu, 19 Oct 2000 17:49:55 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlpn27579 for ; Thu, 19 Oct 2000 17:46:33 GMT Received: from lumen.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjlpn12655 for ; Thu, 19 Oct 2000 17:46:32 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id <4YY6ZJPR>; Thu, 19 Oct 2000 10:46:30 -0700 Message-ID: From: John Drake To: "'darren.freeland@bt.com'" , braja@tellium.com Cc: azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 10:46:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Upon reflection, it appears that you're equating the peer model with snake handling -----Original Message----- From: darren.freeland@bt.com [mailto:darren.freeland@bt.com] Sent: Thursday, October 19, 2000 10:21 AM To: John Drake; braja@tellium.com Cc: azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Hi John, At the risk of sounding repetitous ... >> There's no reason why the back >> end couldn't be GMPLS in peer mode I believe there is a reason. And I've yet to be convinced otherwise by anyone. The way I see it, peer model = single control plane. Single control plane = common addressing, signalling, & routing. Common addressing = only possible if the OTN has a single client. This has been explained in the recent "server layer trails = client layer links" links discussions => i.e. common addressing not possible in a multi-client OTN => i.e. peer model impractical in a multi-client OTN. I think this fundamental issue has to be recognised. Regards, Darren. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: 19 October 2000 17:58 To: 'Bala Rajagopalan' Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Bala, I think that there's a big difference between the service interface offered to a user (aka the front end) and the interface that a service device uses to attach to the rest of the network (aka the back end). There's no reason why the back end couldn't be GMPLS in peer mode even if the front end was something silly like ATM UNI. Thanks, John -----Original Message----- From: Bala Rajagopalan [mailto:braja@tellium.com] Sent: Thursday, October 19, 2000 9:42 AM To: John Drake Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh Hello, John Drake wrote: > > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) In the case of IP over optical, I would just like to add that once you do have an IP-centric control plane within optical networks, you could have routing between IP and optical network that in fact supports the overlay model, alleviating the scalability concerns that arise with IP over ATM model described above. It's then a question of the coupling between the IP and optical control planes. This can be as loose or tight as you want, for example, supporting a UNI that separates the control planes, or the peer model without any separation. I do agree that if you considered other types of clients, the peer model constructs don't seem practical. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Oct 19 13:57:04 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07054 for ; Thu, 19 Oct 2000 13:57:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpn15394; Thu, 19 Oct 2000 17:56:34 GMT Received: by mail-control.mail.uu.net id QQjlpn22815 for mpls-outgoing; Thu, 19 Oct 2000 17:56:08 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlpn22808 for ; Thu, 19 Oct 2000 17:56:01 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlpn27562 for ; Thu, 19 Oct 2000 17:55:36 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjlpn13585 for ; Thu, 19 Oct 2000 17:55:35 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA14208; Thu, 19 Oct 2000 10:55:27 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA17513; Thu, 19 Oct 2000 10:55:27 -0700 (PDT) Date: Thu, 19 Oct 2000 10:55:27 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010191755.KAA17513@kummer.juniper.net> To: braja@tellium.com, darren.freeland@bt.com, jdrake@calient.net Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Cc: azinin@cisco.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, neil.2.harrison@bt.com Sender: owner-mpls@UU.NET Precedence: bulk > I believe there is a reason. And I've yet to be convinced otherwise by > anyone. The way I see it, peer model = single control plane. Single > control plane = common addressing, signalling, & routing. Common addressing > = only possible if the OTN has a single client. I don't agree with this last statement: why is this the case? I see a perfectly viable network with a single control plane for "internal use" AND a UNI interface for other "external" clients. Partition the lambdas in the optical network into "for internal use" and "for external use", if that's what is required -- use some policy mechanism, or do it by configuration. If the "external clients" are IP-based, just don't share your addresses with them. In today's IP networks, IGP addresses are not shared across external BGP sessions. Or use IGP areas to isolate addresses. However, the point of GMPLS is NOT a peer model. It is an IP-based control plane, leveraging existing work, and the flexibility of a peer or overlay or hybrid model. Kireeti. From owner-mpls@UU.NET Thu Oct 19 13:58:00 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07155 for ; Thu, 19 Oct 2000 13:58:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpn17717; Thu, 19 Oct 2000 17:57:41 GMT Received: by mail-control.mail.uu.net id QQjlpn22911 for mpls-outgoing; Thu, 19 Oct 2000 17:57:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlpn22897 for ; Thu, 19 Oct 2000 17:57:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlpn25827 for ; Thu, 19 Oct 2000 17:56:32 GMT Received: from netmail2.alcatel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hosta833.alcatel.com [128.251.168.51]) id QQjlpn27141 for ; Thu, 19 Oct 2000 17:56:31 GMT Received: from relay2.usa.alcatel.com (relay2.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA24327 for ; Thu, 19 Oct 2000 12:55:40 -0500 (CDT) Received: from postal.adn.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id MAA05723 for ; Thu, 19 Oct 2000 12:56:26 -0500 (CDT) Received: from adn.alcatel.com ([143.209.82.96]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA6D06; Thu, 19 Oct 2000 14:06:05 -0400 Message-ID: <39EF4032.3323A3DE@adn.alcatel.com> Date: Thu, 19 Oct 2000 13:40:51 -0500 From: Olivier Duroyon Organization: Alcatel X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: darren.freeland@bt.com CC: jdrake@calient.net, braja@tellium.com, azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh References: <71DA16F18D32D2119A1D0000F8FE9A940920C71E@mbtlipnt01.btlabs.bt.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Darren, I think you made your point clear. But John's last mail explained the different options and one should cover some of your concerns. > >> There's no reason why the back > >> end couldn't be GMPLS in peer mode Sure, or ATM PNNI, or a centralized management entity. > I believe there is a reason. And I've yet to be convinced otherwise by > anyone. The way I see it, peer model = single control plane. Single > control plane = common addressing, signalling, & routing. Common addressing > = only possible if the OTN has a single client. Why do you say that? -case of IP clients: ISPs are connected together using BGP and nevertheless, they are representing different administrative entities. They just need to register to get an IP address range. -case of non-IP clients: The Optical UNI is here defined to break (if needed) the layers between the administrative entities and be able to support the case where the server layer trail is different than the client layer link. > This has been explained in > the recent "server layer trails = client layer links" links discussions => > i.e. common addressing not possible in a multi-client OTN => i.e. peer model > impractical in a multi-client OTN. I think this fundamental issue has to be > recognised. I would say that your are always referring only to the peer model without UNI support at the edge. And this is limitating the peer model capabilities. Regards, Olivier Duroyon Alcatel USA (703) 654 8605 > > > Regards, > Darren. > > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: 19 October 2000 17:58 > To: 'Bala Rajagopalan' > Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; > mpls@UU.NET; ip-optical@lists.bell-labs.com > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft > Minutes From Pittsburgh > > Bala, > > I think that there's a big difference between the service interface offered > to a user (aka the front end) and the interface that a service device uses > to attach to the rest of the network (aka the back end). There's no reason > why the back end couldn't be GMPLS in peer mode even if the front end was > something silly like ATM UNI. > > Thanks, > > John > > -----Original Message----- > From: Bala Rajagopalan [mailto:braja@tellium.com] > Sent: Thursday, October 19, 2000 9:42 AM > To: John Drake > Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; > mpls@UU.NET; ip-optical@lists.bell-labs.com > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft > MinutesFrom Pittsburgh > > Hello, > > John Drake wrote: > > > > > > > For example, a few years ago, one would build an IP service using routers > > mesh connected in an overlay on top of a PNNI transport network. This > was > > perceived as an exquisitely painful way of doing things and led directly > to > > the development of MPLS. I.e., extend the IP control plane to support > > traffic engineering and then have the ATM switches implement MPLS. This > > eliminates the artificial overlay boundary between IP routers and ATM > > switches. (On the other hand, there would still be operational benefits > to > > using MPLS to control the ATM switches even if the network owner wished to > > maintain this overlay boundary.) > > In the case of IP over optical, > I would just like to add that once you do have an IP-centric control > plane within optical networks, you could have routing between IP and > optical network that in fact supports the overlay model, alleviating the > scalability concerns that arise with IP over ATM model described above. > > It's then a question of the coupling between the IP and optical control > planes. This can be as loose or tight as you want, for example, supporting > a UNI that separates the control planes, or the peer model without any > separation. > > I do agree that if you considered other types of clients, the > peer model constructs don't seem practical. > > regards, > > -- > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Thu Oct 19 13:59:18 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07346 for ; Thu, 19 Oct 2000 13:59:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpn19768; Thu, 19 Oct 2000 17:58:38 GMT Received: by mail-control.mail.uu.net id QQjlpn23033 for mpls-outgoing; Thu, 19 Oct 2000 17:58:13 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlpn22986 for ; Thu, 19 Oct 2000 17:57:56 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlpn20884 for ; Thu, 19 Oct 2000 17:57:19 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlpn06282 for ; Thu, 19 Oct 2000 17:57:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA02655 for mpls@uu.net; Thu, 19 Oct 2000 13:57:18 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlpn22875 for ; Thu, 19 Oct 2000 17:56:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlpn26459 for ; Thu, 19 Oct 2000 17:55:31 GMT Received: from stl-smtpout-01.boeing.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: stl-smtpout-01.boeing.com [12.13.247.21]) id QQjlpn13481 for ; Thu, 19 Oct 2000 17:55:31 GMT Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA26949 for ; Thu, 19 Oct 2000 12:55:30 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id MAA00614 for ; Thu, 19 Oct 2000 12:55:29 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Thu, 19 Oct 2000 12:55:26 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 13:55:26 -0400 Message-Id: <4102273CEB77D211869200805FE6F593018C5AE3@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'darren.freeland@bt.com'" Cc: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 13:55:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Seems to me, Darren, that most in the IETF _do_ expect the OTN to have primarily one client: IP. This would also track with other efforts, such as diffserv, enum, and VoIP, in which any non-IP-centric signaling is relegated to the edges (or up in the layer structure, such as H.323). Wasn't the biggest problem with ATM deployment that its clients were almost exclusively IP, while its signaling structure was absolutely not? The early adopters were not what had been intended by design, IMO. In the late 1980s, maybe traffic loads were not favoring IP. The common wisdom now is that they do favor IP. Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: darren.freeland@bt.com [mailto:darren.freeland@bt.com] > > Hi John, > > At the risk of sounding repetitous ... > > >> There's no reason why the back > >> end couldn't be GMPLS in peer mode > > I believe there is a reason. And I've yet to be convinced > otherwise by > anyone. The way I see it, peer model = single control plane. Single > control plane = common addressing, signalling, & routing. > Common addressing > = only possible if the OTN has a single client. This has > been explained in > the recent "server layer trails = client layer links" links > discussions => > i.e. common addressing not possible in a multi-client OTN => > i.e. peer model > impractical in a multi-client OTN. I think this fundamental > issue has to be > recognised. > > Regards, > Darren. From owner-mpls@UU.NET Thu Oct 19 14:01:05 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07600 for ; Thu, 19 Oct 2000 14:01:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpn02058; Thu, 19 Oct 2000 17:59:46 GMT Received: by mail-control.mail.uu.net id QQjlpn23137 for mpls-outgoing; Thu, 19 Oct 2000 17:59:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlpn23119 for ; Thu, 19 Oct 2000 17:59:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlpn06163 for ; Thu, 19 Oct 2000 17:58:38 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlpn10178 for ; Thu, 19 Oct 2000 17:58:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA03134 for mpls@uu.net; Thu, 19 Oct 2000 13:58:37 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlpn22987 for ; Thu, 19 Oct 2000 17:57:56 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlpn20096 for ; Thu, 19 Oct 2000 17:56:58 GMT Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjlpn16287 for ; Thu, 19 Oct 2000 17:56:58 GMT Received: from dhcp-171-69-55-197.cisco.com (dhcp-171-69-55-197.cisco.com [171.69.55.197]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA25529; Thu, 19 Oct 2000 10:56:55 -0700 (PDT) Date: Thu, 19 Oct 2000 10:50:47 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <2451.001019@cisco.com> To: darren.freeland@bt.com CC: neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: <71DA16F18D32D2119A1D0000F8FE9A940920C719@mbtlipnt01.btlabs.bt.co.uk> References: <71DA16F18D32D2119A1D0000F8FE9A940920C719@mbtlipnt01.btlabs.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit darren, >> If you establish an LSP across your >> optical network, it will look like a link to your client. > Indeed - so we agree that the link could consist of a number of trails in > the server layer. Which means that addressing cannot be congruent across > client and server layers. Again, it does not have to (in general), but it can be congruent. I think this is where we disagree. > Which means that your single control plane 'Peer' > model is impractical in a multi-client environment. I don't see how you can > agree on the 1st part but not on the 2nd. Maybe I'm missing something, if > so please explain. You said: > I assume then that you now also acknowledge the single control plane > 'Peer' > model as being impractical? I.e., you sounded like the peer model is impractical at all. I cannot agree with this, of course. >>>> and a single 'best of breed' signalling protocol >> Wrong assumption (RSVP-TE + CR-LDP). > This is something that I haven't understood since I began following IETF > work. Right from the outset, it has been assumed that these particular IP > routing and signalling protocols will be used for the optical layer control > plane. As far as I can see, these assumptions were made before any > consideration was given to the requirements of the optical layer. If I am > wrong, then why aren't these requirements documented in an internet draft? > Don't get me wrong, I am not saying that these protocols (with appropriate > extensions of course) are not up to the job - whether they will be or not is > not the point here. What I am saying is that IETF work on the optical layer > has started out by saying "these are the answers" before having fully asked > the questions. Don't want to expand the discussion in this direction, but I believe we do have framework documents. I simple search for IDs would help, I guess. > That apart, I would also question your choice of control plane facets given > that there is no relationship between IP and OTN user planes. Note that > ITU-T are developing the OTN user plane in G.709. In which IP packets will > be treated as any other client and carried with a defined frame structure. Cool. >> Wrong assumption. >> I does not have to be related, but it can. > If an operator wants his optical transport network to be single client, then > yes it can be related. This would be your 'Peer' model. As an operator, I > do not want my OTN to be single client. Therefore I do not want congruent > addressing across my OTN and ANY client layer. I'm sure I'm not the only > one who holds this view. OK, so why don't you just use the overlay model? >> Do you mean there is a contradiction with >> the work currently being done? > Do you mean that the work currently being done supports an OTN that can't > have multiple clients? Do you mean that the overlay model will not be able to support multiple clients? Alex. From owner-mpls@UU.NET Thu Oct 19 16:45:02 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07263 for ; Thu, 19 Oct 2000 16:45:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlpy04998; Thu, 19 Oct 2000 20:44:23 GMT Received: by mail-control.mail.uu.net id QQjlpy20858 for mpls-outgoing; Thu, 19 Oct 2000 20:43:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlpy20848 for ; Thu, 19 Oct 2000 20:43:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlpy16068 for ; Thu, 19 Oct 2000 20:42:45 GMT Received: from server.nayna.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) id QQjlpy23089 for ; Thu, 19 Oct 2000 20:42:44 GMT Received: from nayna.com (sonicwall [64.145.162.226]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA28544; Thu, 19 Oct 2000 13:42:36 -0700 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be nayna.com Message-ID: <39EF4114.E34C6401@nayna.com> Date: Thu, 19 Oct 2000 13:44:37 -0500 From: Sudheer Dharanikota X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rajeev Manur CC: Mike Badil , mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: <7df439c67cc3e994a54787ff1ea79b3739ef4182@force10networks.com> Content-Type: multipart/mixed; boundary="------------7087EAEF3E826E930D8F3B55" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------7087EAEF3E826E930D8F3B55 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes sir.. you are missing many things. TE is mainly used for core. In core nobody in right mind will do 5 tuple lookup on the the Ip packet :-) - sudheer Rajeev Manur wrote: > > see below... > > -----Original Message----- > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > Sent: Thursday, October 19, 2000 7:21 AM > To: Mike Badil > Cc: mpls@UU.NET > Subject: Re: Traffic engineering and RSVP > > Mike Badil wrote: > > > > Hi > > > > I confused when I read traffic engineering with MPLS. > > > > My question is: > > > > MPLS is combination of layer 2 swithing and layer 3 routing. Traffic eng. > is > > part of layer 3. In MPLS route(LSP) is established in advance according to > > the constraints. in other word, instead of choosing shortest path, it > choose > > the path which satisfy its requirments, and to make link utulization > better. > > In order to have done this with MPLS there are some works which say that > > OSPF,IS-IS can be modified by adding constraint to it. > > > > That is clear so far, > > > > I wondering that whether we can have those traffic engineering conditions > be > > satisfied by other tech. > > > > For example; RSVP-Intserv set up route in advance also. If we use extended > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > > we can choose the path which satisfy our constraints instead of choosing > > Shortest path. Link load balancing can be done as in MPLS. So most of > > traffic engineering requirements will be satisfied.(let don't consider > > scalibility problem with RSVP now). Or it can work any other technology > > which use RSVP. > > > > The problem is in applying filter at every node to make sure your IP > packet > is following the selected path. Hence data path becomes slow. > > RAJEEV> I thought almost all the boxes today perform complete packet > processing at line-rate with or without the application of packet filters. I > don't see the relevence of the above statment. Am i missing anything.. > > - sudheer > > > What am I missing here? > > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > > Share information about yourself, create your own public profile at > > http://profiles.msn.com. --------------7087EAEF3E826E930D8F3B55 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dharanikota;Sudheer tel;cell:408-829-8812 tel;work:408-956-8000 X357 x-mozilla-html:TRUE org:Nayna Networks adr:;;;;;; version:2.1 email;internet:sudheer@nayna.com fn:Sudheer Dharanikota end:vcard --------------7087EAEF3E826E930D8F3B55-- From owner-mpls@UU.NET Thu Oct 19 17:14:04 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10487 for ; Thu, 19 Oct 2000 17:14:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqa07255; Thu, 19 Oct 2000 21:13:42 GMT Received: by mail-control.mail.uu.net id QQjlqa04622 for mpls-outgoing; Thu, 19 Oct 2000 21:13:09 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlqa04614 for ; Thu, 19 Oct 2000 21:13:02 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlqa06962 for ; Thu, 19 Oct 2000 21:10:36 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlqa14834 for ; Thu, 19 Oct 2000 21:10:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA01325 for mpls@uu.net; Thu, 19 Oct 2000 17:10:34 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlqa04179 for ; Thu, 19 Oct 2000 21:10:07 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlqa03519 for ; Thu, 19 Oct 2000 21:09:06 GMT Received: from force10networks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQjlqa01478 for ; Thu, 19 Oct 2000 21:09:06 GMT Received: from pc2101 by force10networks.com (8.8.8+Sun/ncore-main9-99) id OAA08451; Thu, 19 Oct 2000 14:08:55 -0700 (PDT) From: "Rajeev Manur" To: "'Sudheer Dharanikota'" , "Rajeev Manur" Cc: "Mike Badil" , Subject: RE: Traffic engineering and RSVP Date: Thu, 19 Oct 2000 14:08:51 -0700 Message-ID: <2cc395ba3ea2621cc6bd76adb5827a3c39ef632b@force10networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <39EF4114.E34C6401@nayna.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit see below -----Original Message----- From: Sudheer Dharanikota [mailto:sudheer@nayna.com] Sent: Thursday, October 19, 2000 11:45 AM To: Rajeev Manur Cc: Mike Badil; mpls@UU.NET Subject: Re: Traffic engineering and RSVP Yes sir.. you are missing many things. TE is mainly used for core. In core nobody in right mind will do 5 tuple lookup on the the Ip packet :-) RAJEEV> I never said anybody would or would not do 5 tuple lkup in the core. All i am saying is that your statement "Hence data path becomes slow" does not make any sense, because as far as i know today's packet processors can handle this without affecting the line-rate performance.. with regards, Rajeev. - sudheer Rajeev Manur wrote: > > see below... > > -----Original Message----- > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > Sent: Thursday, October 19, 2000 7:21 AM > To: Mike Badil > Cc: mpls@UU.NET > Subject: Re: Traffic engineering and RSVP > > Mike Badil wrote: > > > > Hi > > > > I confused when I read traffic engineering with MPLS. > > > > My question is: > > > > MPLS is combination of layer 2 swithing and layer 3 routing. Traffic eng. > is > > part of layer 3. In MPLS route(LSP) is established in advance according to > > the constraints. in other word, instead of choosing shortest path, it > choose > > the path which satisfy its requirments, and to make link utulization > better. > > In order to have done this with MPLS there are some works which say that > > OSPF,IS-IS can be modified by adding constraint to it. > > > > That is clear so far, > > > > I wondering that whether we can have those traffic engineering conditions > be > > satisfied by other tech. > > > > For example; RSVP-Intserv set up route in advance also. If we use extended > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > > we can choose the path which satisfy our constraints instead of choosing > > Shortest path. Link load balancing can be done as in MPLS. So most of > > traffic engineering requirements will be satisfied.(let don't consider > > scalibility problem with RSVP now). Or it can work any other technology > > which use RSVP. > > > > The problem is in applying filter at every node to make sure your IP > packet > is following the selected path. Hence data path becomes slow. > > RAJEEV> I thought almost all the boxes today perform complete packet > processing at line-rate with or without the application of packet filters. I > don't see the relevence of the above statment. Am i missing anything.. > > - sudheer > > > What am I missing here? > > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > > Share information about yourself, create your own public profile at > > http://profiles.msn.com. From owner-mpls@UU.NET Thu Oct 19 17:37:27 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12972 for ; Thu, 19 Oct 2000 17:37:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqc16403; Thu, 19 Oct 2000 21:37:08 GMT Received: by mail-control.mail.uu.net id QQjlqc06995 for mpls-outgoing; Thu, 19 Oct 2000 21:36:42 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlqc06987 for ; Thu, 19 Oct 2000 21:36:36 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlqc00455 for ; Thu, 19 Oct 2000 21:35:41 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjlqc08568 for ; Thu, 19 Oct 2000 21:35:40 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA29851 for ; Thu, 19 Oct 2000 17:35:37 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA07112 for ; Thu, 19 Oct 2000 17:35:40 -0400 (EDT) Message-ID: <39EF6927.C26E47A@marconi.com> Date: Thu, 19 Oct 2000 17:35:35 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: <2cc395ba3ea2621cc6bd76adb5827a3c39ef632b@force10networks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Rajeev Manur wrote: > > I never said anybody would or would not do 5 tuple lkup in the core. > All i am saying is that your statement "Hence data path becomes slow" > does not make any sense, because as far as i know today's packet > processors can handle this without affecting the line-rate > performance.. What do you define as "line rate"? OC-3? OC-12? OC-48? OC-192? Faster? And how many ports per switching fabric? 4? 16? 256? more? No matter how fast the chips in your switching/routing processor can do 5-tuple lookups, there are environments where they are not fast enough. And these environments are what you typically find in the core of major networks. Customers are looking for ever-increasing line rates, and increasing port densities. And their demands are increasing faster than the ability of chip vendors to implement IP routing-table lookups. Especially if those lookups involve more than just matching destination addresses. -- David From owner-mpls@UU.NET Thu Oct 19 17:55:33 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14924 for ; Thu, 19 Oct 2000 17:55:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqd10510; Thu, 19 Oct 2000 21:55:15 GMT Received: by mail-control.mail.uu.net id QQjlqd08515 for mpls-outgoing; Thu, 19 Oct 2000 21:54:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlqd08510 for ; Thu, 19 Oct 2000 21:54:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlqd07390 for ; Thu, 19 Oct 2000 21:53:14 GMT Received: from icarian.ZAFFIRE.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjlqd02743 for ; Thu, 19 Oct 2000 21:53:14 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <48XX1J2D>; Thu, 19 Oct 2000 14:53:55 -0700 Message-ID: <4611AD058694D4118FD5009027B0A66273A780@ICARIAN> From: Paul Joseph To: "'Bala Rajagopalan'" , John Drake Cc: "'darren.freeland@bt.com'" , azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 14:53:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Bala Rajagopalan [mailto:braja@tellium.com] > Sent: Thursday, October 19, 2000 9:42 AM > To: John Drake > Cc: 'darren.freeland@bt.com'; azinin@cisco.com; > neil.2.harrison@bt.com; > mpls@UU.NET; ip-optical@lists.bell-labs.com > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft > MinutesFrom Pittsburgh > > > > In the case of IP over optical, > I would just like to add that once you do have an IP-centric control > plane within optical networks, you could have routing between IP and > optical network that in fact supports the overlay model, > alleviating the > scalability concerns that arise with IP over ATM model > described above. > > It's then a question of the coupling between the IP and > optical control > planes. This can be as loose or tight as you want, for > example, supporting > a UNI that separates the control planes, or the peer model > without any > separation. Not sure what you mean here - terminology seems all different - MPLS in itself separates the control plane from the user plane - that fact that we use an IP control plane with an Optical or ATM data plane makes that evident - the peer model is a peering at the IP level and the UNI just provides a form of signalling between the 2 peers - so they are one and the same thing - once you have decided to use MPLS. Paul > > I do agree that if you considered other types of clients, the > peer model constructs don't seem practical. > > regards, > > -- > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > From owner-mpls@UU.NET Thu Oct 19 18:54:08 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21327 for ; Thu, 19 Oct 2000 18:54:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqh19755; Thu, 19 Oct 2000 22:53:23 GMT Received: by mail-control.mail.uu.net id QQjlqh25848 for mpls-outgoing; Thu, 19 Oct 2000 22:52:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlqh25839 for ; Thu, 19 Oct 2000 22:52:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlqh23238 for ; Thu, 19 Oct 2000 22:52:37 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjlqh07301 for ; Thu, 19 Oct 2000 22:52:37 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Thu, 19 Oct 2000 23:53:33 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <41BM5Q1Q>; Thu, 19 Oct 2000 23:52:05 +0100 Message-ID: To: jdrake@calient.net, darren.freeland@bt.com, braja@tellium.com Cc: azinin@cisco.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 23:52:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk John, You wrote: > Upon reflection, it appears that you're equating the peer model with snake > handling > NH=> Can I suggest you go and have a chat to with those actually responsible for P&L in operators, ie not the R&D bits....now this *is* snake handling! I think this may give you a good insight of the commercial reality as to why we can't ignore the support (and not just short-term) of various types of client networks. Unfortunately I don't think you will hear these people speaking on the list, so you would have to seek them out. I am however, somewhat surprised by the lack of operator's comments on the list........maybe they are not tuned-in or maybe they are and don't care (and, if so, then so be it)? Neil From owner-mpls@UU.NET Thu Oct 19 18:55:06 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21453 for ; Thu, 19 Oct 2000 18:55:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqh12539; Thu, 19 Oct 2000 22:54:19 GMT Received: by mail-control.mail.uu.net id QQjlqh25875 for mpls-outgoing; Thu, 19 Oct 2000 22:53:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlqh25864 for ; Thu, 19 Oct 2000 22:53:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlqh24016 for ; Thu, 19 Oct 2000 22:52:53 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjlqh08158 for ; Thu, 19 Oct 2000 22:52:52 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Thu, 19 Oct 2000 23:52:11 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id <4C8FR3KG>; Thu, 19 Oct 2000 23:51:58 +0100 Message-ID: To: kireeti@juniper.net, braja@tellium.com, darren.freeland@bt.com, jdrake@calient.net Cc: azinin@cisco.com, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Thu, 19 Oct 2000 23:52:07 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Kireeti observed: > However, the point of GMPLS is NOT a peer model. It is an IP-based > control plane, leveraging existing work, and the flexibility of a > peer or overlay or hybrid model. > The basic argument you are making here Kireeti (and one I saw John Drake advocate) is that it makes sense not to re-invent the control-plane (which has been the case historically) for every new user-plane technology/PDU-type. I strongly agree with this view. However, exactly *which* control-plane aspects one should use is a different question....and this is essentially the point Darren Freeland was making, and against which (it appears) some have already make decisions as to what is the right solution without any real debate of the 'requirements'. I have also tried to make the point (using technical arguments, and not very successfully it seems) that there are *commercial* issues at play here and we are not dealing with some greenfield site where an idealistic solution is viable (even if right, and I am not sure it is)....the simple fact is that operators like BT will have to support many types of different client layer. Ergo, a peer model for operators like ourselves is not currently a viable option....it's as simple as that. Now lets return to the more technical aspects and arguments, since we still have a duty (as engineers) to be forward looking and evaluate proposals on their technical merits...even if accountants control the near/medium-term. John (Drake) used the ATM/IP (and the mess of MPOA) as analogous to the IP/OTN case....so the argument then develops into 'let's use the same (control-plane) solution for everything' (which is essentially the GMPLS philosophy). The assumption in GMPLS is that the key facets of an (historical) IP control-plane (ie v4 addressing, RSVP signalling (OK CR_LDP too.....maybe even better for OTN) and an IGP such as OSPF) are the *right* choices for an OTN (or indeed everything). I could now use a great deal of BW up explaining why ATM/IP and OTN/IP are very different animals.......so I will be as brief as I can be, and I apologise to any left wondering why I made any of the following points (come back to me off-line if you need the detail): In the ATM/IP case there are compelling reasons to unify the control-plane with the concept of MPLS....such as: - to avoid the VoXX N^/2 type of gateway problem across user/control/management/oss planes - to unite a CO and CNLS transfer mode.....though currently the CO aspect is network-only (so-called control-driven LSPs) due to, quite correctly, the current predominant type of Internet traffic, ie short-holding WWW.......but this may not always be the case, esp when clever applications people start thinking how to use all the BW that the OTN will provide........think video and possibly long-holding interactive sessions. This could radically alter the required/dominant transfer mode, and indeed the role of MPLS. {Aside: This could also solve the QoS issues as a by-product, however it requires an open-mind to see the possibilities. Hint: The only 2 truly scalable networks I am aware of (both proved by existence) are the PSTN and the Internet} - to unify the addressing (the other 3 key facets of the control-plane, ie routing/discovery technique, signalling protocol and the special requirements of the signalling network itself are secondary to addressing)......this is really why MPOA could never work (the details are clearly more complex than I hint at here, but the essential problem is a lack of address unification). IP and ATM as user-plane PDUs have quite a lot in common (esp at AAL level): - application interfacing - relatively fast time-constants wrt to network demand changes......and within this issue is the problem of TE - small granularity user-plane PDU structures....allows concepts of buffers and differential serving treatment of PDUs But as we go down the server layer stack the time-constants change, ie they increase. The slowest time-constants are associated with the duct network...and this really is a network and it is a very important one. This is the ultimate expression of real TE (wireless/radio people might argue with this, but the 'environment of physical occupancy' is the essential feature) and this is where the availability bound of all client layers is determined. The OTN we should note, is just above the duct network, ie it is dealing in coarse BW granularities and longish time-constants (compared to its finer BW granularity client layers). So what are the essential features of the *user-plane* of the OTN? - no practical buffering....so we can forget IP, ATM, FR, or indeed any type of binary frame/packet/cell/PDU structure as being *an essential driver*. Or, perhaps put another more obvious way, the OTN doesn't do DiffServ. - it is CO/cct-sw and user-plane transparent....so it can't identify PDU boundaries (I have heard some people say this about ATM, but the PTI of the cell O/H in AAL5 does this) - it will have (for commercial reasons) lots of legacy/new client networks, and indeed peer coarse managed BW services, it will have to support....and customers will also demand this, let alone being an operator *must have*. So what does this mean wrt to its control-plane? - well its addressing clearly has to be disjoint from any client addressing space ('server layer trails = client layer links'). v4 is already creaking in the IP layer. v4 has also had to learn the lessons of aggregation and the need for routing and topology to have close linkages (ie CIDR and users having to take address stems from ISPs) So why would v4 be an 'obvious' choice for the OTN? - we are dealing with a CO/cct-sw fabric whose clients, in terms of PDU structure, are almost irrelevant....so what is the best signalling protocol for this environment? It is certainly not clear to me, and I think many others, why RSVP would come out tops in any such evaluation. - routing/discovery.......I'm not sure what is best here for the OTN. But there is much to be learnt from both the Internet world and the Telephony world on what would be the best solution here. Though I have to say here that I would want this restricted to an OTN layer problem since I simply don't understand how, in an environment of multiple clients, I can have any (for want of a better expression) a 'distributed/unified routing/discovery protocol across multiple layers'...and with all the scalability/client-priority/etc issues this throws up. So, in conclusion, to say that 'an IP control plane' (whatever that actually means) is appropriate for the OTN simply does not compute with me at the present time based on my own analysis of the problem-space. Neil From owner-mpls@UU.NET Thu Oct 19 19:22:25 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25418 for ; Thu, 19 Oct 2000 19:22:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqj08110; Thu, 19 Oct 2000 23:22:01 GMT Received: by mail-control.mail.uu.net id QQjlqj10053 for mpls-outgoing; Thu, 19 Oct 2000 23:21:38 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlqj10009 for ; Thu, 19 Oct 2000 23:21:32 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlqj29440 for ; Thu, 19 Oct 2000 23:20:09 GMT Received: from cowansville.acbm.qc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjlqj02843 for ; Thu, 19 Oct 2000 23:20:09 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca for ; Thu, 19 Oct 2000 19:19:41 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id <4GAKAYTL>; Thu, 19 Oct 2000 19:20:12 -0400 Message-ID: <91E486361D4CD311B3140060089A882556A47D@hermes.hyperchip.com> From: Eyad Saheb To: "'mpls@UU.NET'" Subject: RE: Traffic engineering and RSVP Date: Thu, 19 Oct 2000 19:20:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03A23.20DE4D80" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03A23.20DE4D80 Content-Type: text/plain; charset="iso-8859-1" >>-----Original Message----- >>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David >>Charlap >>Sent: Thursday, October 19, 2000 5:36 PM >>To: mpls@UU.NET >>Subject: Re: Traffic engineering and RSVP >> >> >>Rajeev Manur wrote: >> >> I never said anybody would or would not do 5 tuple lkup in the core. >> All i am saying is that your statement "Hence data path becomes slow" >> does not make any sense, because as far as i know today's packet >> processors can handle this without affecting the line-rate >> performance.. > >What do you define as "line rate"? > >OC-3? OC-12? OC-48? OC-192? Faster? > >And how many ports per switching fabric? 4? 16? 256? more? > >No matter how fast the chips in your switching/routing processor can do >5-tuple lookups, there are environments where they are not fast enough. >And these environments are what you typically find in the core of major >networks. > >Customers are looking for ever-increasing line rates, and increasing >port densities. And their demands are increasing faster than the >ability of chip vendors to implement IP routing-table lookups. >Especially if those lookups involve more than just matching destination >addresses. > >-- David I have to concur. 5-tuple lkups have their limitations, not the least of which is speed. Doing "TE" the way that Mike Badil suggested would also make the other benefits of MPLS harder to do (ex. tunneling, n->1 fast path protection, etc...). Eyad ------_=_NextPart_001_01C03A23.20DE4D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Traffic engineering and RSVP

>>-----Original Message-----
>>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of David
>>Charlap
>>Sent: Thursday, October 19, 2000 5:36 = PM
>>To: mpls@UU.NET
>>Subject: Re: Traffic engineering and = RSVP
>>
>>
>>Rajeev Manur wrote:
>>
>> I never said anybody would or would not do = 5 tuple lkup in the core.
>> All i am saying is that your statement = "Hence data path becomes slow"
>> does not make any sense, because as far as = i know today's packet
>> processors can handle this without = affecting the line-rate
>> performance..
>
>What do you define as "line = rate"?
>
>OC-3?  OC-12?  OC-48?  = OC-192?  Faster?
>
>And how many ports per switching fabric?  = 4? 16? 256? more?
>
>No matter how fast the chips in your = switching/routing processor can do
>5-tuple lookups, there are environments where = they are not fast enough.
>And these environments are what you typically = find in the core of major
>networks.
>
>Customers are looking for ever-increasing line = rates, and increasing
>port densities.  And their demands are = increasing faster than the
>ability of chip vendors to implement IP = routing-table lookups.
>Especially if those lookups involve more than = just matching destination
>addresses.
>
>-- David

I have to concur.  5-tuple lkups have their = limitations, not the least of which is speed.  Doing = "TE" the way that Mike Badil suggested would also make the = other benefits of MPLS harder to do (ex. tunneling, n->1 fast path = protection, etc...).

Eyad

------_=_NextPart_001_01C03A23.20DE4D80-- From owner-mpls@UU.NET Thu Oct 19 19:23:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25585 for ; Thu, 19 Oct 2000 19:23:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqj29848; Thu, 19 Oct 2000 23:23:31 GMT Received: by mail-control.mail.uu.net id QQjlqj10144 for mpls-outgoing; Thu, 19 Oct 2000 23:22:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlqj10118 for ; Thu, 19 Oct 2000 23:22:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlqj18624 for ; Thu, 19 Oct 2000 23:21:33 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlqj20184 for ; Thu, 19 Oct 2000 23:21:32 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA15855 for mpls@uu.net; Thu, 19 Oct 2000 19:21:31 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlqj09911 for ; Thu, 19 Oct 2000 23:21:07 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlqj26586 for ; Thu, 19 Oct 2000 23:20:47 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjlqj04657 for ; Thu, 19 Oct 2000 23:20:47 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA08438; Thu, 19 Oct 2000 16:20:45 -0700 (PDT) Message-ID: <39EF81CD.5948029B@pluris.com> Date: Thu, 19 Oct 2000 16:20:45 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Sudheer Dharanikota CC: mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: <7df439c67cc3e994a54787ff1ea79b3739ef4182@force10networks.com> <39EF4114.E34C6401@nayna.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I would not jump on this so fast, there is at least one router out there that can do line rate 5-tuple lookups for many, many rules. Just because **you** don't know how to do it, doesn't mean it can't be done. Bora Sudheer Dharanikota wrote: > Yes sir.. you are missing many things. > > TE is mainly used for core. In core nobody in right mind > will do 5 tuple lookup on the the Ip packet :-) > > - sudheer > > Rajeev Manur wrote: > > > > see below... > > > > -----Original Message----- > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > Sent: Thursday, October 19, 2000 7:21 AM > > To: Mike Badil > > Cc: mpls@UU.NET > > Subject: Re: Traffic engineering and RSVP > > > > Mike Badil wrote: > > > > > > Hi > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > My question is: > > > > > > MPLS is combination of layer 2 swithing and layer 3 routing. Traffic eng. > > is > > > part of layer 3. In MPLS route(LSP) is established in advance according to > > > the constraints. in other word, instead of choosing shortest path, it > > choose > > > the path which satisfy its requirments, and to make link utulization > > better. > > > In order to have done this with MPLS there are some works which say that > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > That is clear so far, > > > > > > I wondering that whether we can have those traffic engineering conditions > > be > > > satisfied by other tech. > > > > > > For example; RSVP-Intserv set up route in advance also. If we use extended > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > > > we can choose the path which satisfy our constraints instead of choosing > > > Shortest path. Link load balancing can be done as in MPLS. So most of > > > traffic engineering requirements will be satisfied.(let don't consider > > > scalibility problem with RSVP now). Or it can work any other technology > > > which use RSVP. > > > > > > > The problem is in applying filter at every node to make sure your IP > > packet > > is following the selected path. Hence data path becomes slow. > > > > RAJEEV> I thought almost all the boxes today perform complete packet > > processing at line-rate with or without the application of packet filters. I > > don't see the relevence of the above statment. Am i missing anything.. > > > > - sudheer > > > > > What am I missing here? > > > > > > _________________________________________________________________________ > > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > > > > Share information about yourself, create your own public profile at > > > http://profiles.msn.com. From owner-mpls@UU.NET Thu Oct 19 20:28:46 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02764 for ; Thu, 19 Oct 2000 20:28:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqn24763; Fri, 20 Oct 2000 00:28:25 GMT Received: by mail-control.mail.uu.net id QQjlqn27272 for mpls-outgoing; Fri, 20 Oct 2000 00:27:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlqn27255 for ; Fri, 20 Oct 2000 00:27:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlqn25093 for ; Fri, 20 Oct 2000 00:27:21 GMT Received: from cod.ece.ucdavis.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cod.ece.ucdavis.edu [169.237.32.89]) id QQjlqn27864 for ; Fri, 20 Oct 2000 00:27:21 GMT Received: from localhost (wswen@localhost) by cod.ece.ucdavis.edu (8.8.7/8.8.7) with ESMTP id RAA13807; Thu, 19 Oct 2000 17:26:56 -0700 (PDT) Date: Thu, 19 Oct 2000 17:26:56 -0700 (PDT) From: Wushao Wen To: Bora Akyol cc: Sudheer Dharanikota , mpls@UU.NET Subject: Re: Traffic engineering and RSVP In-Reply-To: <39EF81CD.5948029B@pluris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk In fact, I think the discussion here missed something on the the basic operation of the IP network. To send a data packet from a source to a destination, we need to refer to two components--the information carried inside the packet and a routing tabel (or switching table). Because the conventional IP network's routing is based on the destination address, if we want to route the packet via an explicit path, it is necessary for the IP header to carry some additional information. IP uses optional header to carry the explicit route information so that the router inside the network can process the explicit route request instead of the destination-based routing. However, the processing overhead for such optional header is prohibiting high and it is not a very good solution for traffic engineering. Without MPLS, evern though we can use OSPF or other link-state routing protocol to distribute the routing information, and use the RSVP or other protocols to reserved the network resource, it can not eliminate the requirement of the data packet to carrry the explicit route information. Otherwise, the data packet will not follow the explicit path. MPLS solve this problem by doing label swapping instead of the destination-based routing. Therefore, it is possible for a data packet to use a very short header to direct the router to send the packet to the pre-selected route. Wushao On Thu, 19 Oct 2000, Bora Akyol wrote: > I would not jump on this so fast, there is at least one router out there that can > do line rate 5-tuple lookups for many, many rules. > > Just because **you** don't know how to do it, doesn't mean it can't be done. > > Bora > > > > Sudheer Dharanikota wrote: > > > Yes sir.. you are missing many things. > > > > TE is mainly used for core. In core nobody in right mind > > will do 5 tuple lookup on the the Ip packet :-) > > > > - sudheer > > > > Rajeev Manur wrote: > > > > > > see below... > > > > > > -----Original Message----- > > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > > Sent: Thursday, October 19, 2000 7:21 AM > > > To: Mike Badil > > > Cc: mpls@UU.NET > > > Subject: Re: Traffic engineering and RSVP > > > > > > Mike Badil wrote: > > > > > > > > Hi > > > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > > > My question is: > > > > > > > > MPLS is combination of layer 2 swithing and layer 3 routing. Traffic eng. > > > is > > > > part of layer 3. In MPLS route(LSP) is established in advance according to > > > > the constraints. in other word, instead of choosing shortest path, it > > > choose > > > > the path which satisfy its requirments, and to make link utulization > > > better. > > > > In order to have done this with MPLS there are some works which say that > > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > > > That is clear so far, > > > > > > > > I wondering that whether we can have those traffic engineering conditions > > > be > > > > satisfied by other tech. > > > > > > > > For example; RSVP-Intserv set up route in advance also. If we use extended > > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > > > > we can choose the path which satisfy our constraints instead of choosing > > > > Shortest path. Link load balancing can be done as in MPLS. So most of > > > > traffic engineering requirements will be satisfied.(let don't consider > > > > scalibility problem with RSVP now). Or it can work any other technology > > > > which use RSVP. > > > > > > > > > > The problem is in applying filter at every node to make sure your IP > > > packet > > > is following the selected path. Hence data path becomes slow. > > > > > > RAJEEV> I thought almost all the boxes today perform complete packet > > > processing at line-rate with or without the application of packet filters. I > > > don't see the relevence of the above statment. Am i missing anything.. > > > > > > - sudheer > > > > > > > What am I missing here? > > > > > > > > _________________________________________________________________________ > > > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > > > > > > Share information about yourself, create your own public profile at > > > > http://profiles.msn.com. > From owner-mpls@UU.NET Thu Oct 19 21:01:51 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06406 for ; Thu, 19 Oct 2000 21:01:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqq13223; Fri, 20 Oct 2000 01:01:43 GMT Received: by mail-control.mail.uu.net id QQjlqq04478 for mpls-outgoing; Fri, 20 Oct 2000 01:01:13 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlqq04098 for ; Fri, 20 Oct 2000 01:01:06 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlqq04424 for ; Fri, 20 Oct 2000 01:00:40 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlqq25517 for ; Fri, 20 Oct 2000 01:00:40 GMT Received: from tellium.com ([192.168.24.249]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9K0r1O26020; Thu, 19 Oct 2000 20:53:01 -0400 (EDT) Message-ID: <39EF98FC.1E169440@tellium.com> Date: Thu, 19 Oct 2000 20:59:40 -0400 From: Debanjan Saha X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: Sudheer Dharanikota , mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: <7df439c67cc3e994a54787ff1ea79b3739ef4182@force10networks.com> <39EF4114.E34C6401@nayna.com> <39EF81CD.5948029B@pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: > I would not jump on this so fast, there is at least one router out there that can > do line rate 5-tuple lookups for many, many rules. Just curious -- what is the line rate and what does "many, many" stand for? :-) Regards, Debanjan From owner-mpls@UU.NET Thu Oct 19 21:07:54 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07078 for ; Thu, 19 Oct 2000 21:07:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlqq08169; Fri, 20 Oct 2000 01:07:29 GMT Received: by mail-control.mail.uu.net id QQjlqq11282 for mpls-outgoing; Fri, 20 Oct 2000 01:07:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlqq11268 for ; Fri, 20 Oct 2000 01:06:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlqq23124 for ; Fri, 20 Oct 2000 01:06:03 GMT Received: from icarian.ZAFFIRE.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjlqq03158 for ; Fri, 20 Oct 2000 01:06:02 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <48XX1K5P>; Thu, 19 Oct 2000 18:06:48 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6625D8B56@ICARIAN> From: Eric Gray To: "'Debanjan Saha'" , Bora Akyol Cc: Sudheer Dharanikota , mpls@UU.NET Subject: RE: Traffic engineering and RSVP Date: Thu, 19 Oct 2000 18:06:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Debanjan, Many, as we know, means "more than a few". Few means "more than a couple and less than many". Therefore, "many" means at least 4 and "many, many" equates to at least 16. Underwhelming, isn't it? :-) -- Eric Gray > -----Original Message----- > From: Debanjan Saha [mailto:dsaha@tellium.com] > Sent: Thursday, October 19, 2000 6:00 PM > To: Bora Akyol > Cc: Sudheer Dharanikota; mpls@UU.NET > Subject: Re: Traffic engineering and RSVP > > > > > Bora Akyol wrote: > > > I would not jump on this so fast, there is at least one > router out there that can > > do line rate 5-tuple lookups for many, many rules. > > Just curious -- what is the line rate and what does "many, > many" stand for? :-) > > Regards, > Debanjan > From owner-mpls@UU.NET Fri Oct 20 03:37:41 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17550 for ; Fri, 20 Oct 2000 03:37:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlrq13813; Fri, 20 Oct 2000 07:36:56 GMT Received: by mail-control.mail.uu.net id QQjlrq12667 for mpls-outgoing; Fri, 20 Oct 2000 07:36:19 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlrq12639 for ; Fri, 20 Oct 2000 07:36:15 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlrq25391 for ; Fri, 20 Oct 2000 07:36:05 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjlrq12518 for ; Fri, 20 Oct 2000 07:36:04 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Fri, 20 Oct 2000 08:28:59 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id ; Fri, 20 Oct 2000 08:28:49 +0100 Message-ID: To: azinin@cisco.com Cc: mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Fri, 20 Oct 2000 08:28:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk From Alex=> > Anybody minds if we take if off the list if the discussion > is not over yet? > I don't think the debate is *over*, indeed I don't think it has even begun properly.....but it needs other operator views, and not simply those discussing it so far who clearly hold stong convictions. I have had several private mails on this topic supporting the points I have made and I wish these people would state their positions openly.......however, one cannot force this, but without it I agree that continued debate on the list is somewhat futile (and not really what it should be used for). neil From owner-mpls@UU.NET Fri Oct 20 07:19:43 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20827 for ; Fri, 20 Oct 2000 07:19:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsf21426; Fri, 20 Oct 2000 11:19:15 GMT Received: by mail-control.mail.uu.net id QQjlsf11442 for mpls-outgoing; Fri, 20 Oct 2000 11:18:57 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlsf11437 for ; Fri, 20 Oct 2000 11:18:54 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlsf27981 for ; Fri, 20 Oct 2000 11:18:33 GMT From: darren.freeland@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjlsf18306 for ; Fri, 20 Oct 2000 11:18:33 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Fri, 20 Oct 2000 11:41:08 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Fri, 20 Oct 2000 11:41:06 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C722@mbtlipnt01.btlabs.bt.co.uk> To: kireeti@juniper.net Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET, neil.2.harrison@bt.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Fri, 20 Oct 2000 11:39:50 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, >> However, the point of GMPLS is NOT a peer model. It is an IP-based >> control plane, leveraging existing work, and the flexibility of a >> peer or overlay or hybrid model. Perhaps you missed my point. I didn't say the point of GMPLS is a peer model (I have read the draft) - I questioned the assumption that IP-centric control protocols will be appropriate for an optical (or indeed any) control plane. As far as I can see (having read the IPO framework, the MPLambdaS, and the Generalised MPLS drafts I hasten to add), this assumption has been made without giving full consideration to the requirements of the particular networks the protocols will be applied to. My interest is the OTN, so that's what I've been focussing on. The IPO framework document starts out in the introduction by saying that "there is wide consensus in the industry that the optical control plane should be IP-centric". I would question this 'wide consensus'. There is a few (very basic) requirements set out in the introduction, but nothing that justifies thoroughly the choice of IP-centric control protocols for the OTN. The MPL(ambda)S document does the same - we're told in the intro that the optical control plane will be based on the MPLS TE control plane model. The only justification that is given for this is the reuse of existing protocols. Cool - why not reuse PNNI then? I'm not advocating one or the other yet - what I am saying is that the requirements of the OTN (or any other network in the case of GMPLS) should be fully considered in the first place. The choice (and extensions) of control plane protocols should then be made to fit these requirements. The other problem I have with the MPL(ambda)S philosophy is its clear bias towards the 'peer' option. Sure, the 'overlay' option is described, but it is not fully discussed - we are simply told that "to understand the drawbacks of this approach ... one need look no further than the experience with IP over ATM". This is a whole discussion in itself which Neil Harrison has touched on in his reply to you. ATM is not the OTN. This aside, my point is that the peer model is clearly advocated over the overlay model - but there is no mention to the effect the peer model would have on an operator who has a multi-client environment. There is also a clear reluctance on this list to recognise the problems the peer model may bring. I think a new draft is in order, but I get the feeling many won't like it. Regards, Darren. From owner-mpls@UU.NET Fri Oct 20 07:21:48 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21124 for ; Fri, 20 Oct 2000 07:21:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsf23554; Fri, 20 Oct 2000 11:21:36 GMT Received: by mail-control.mail.uu.net id QQjlsf11530 for mpls-outgoing; Fri, 20 Oct 2000 11:20:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlsf11525 for ; Fri, 20 Oct 2000 11:20:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlsf03051 for ; Fri, 20 Oct 2000 11:18:34 GMT From: darren.freeland@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjlsf18327 for ; Fri, 20 Oct 2000 11:18:34 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Fri, 20 Oct 2000 11:44:41 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <4W3A0FXZ>; Fri, 20 Oct 2000 11:44:03 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C723@mbtlipnt01.btlabs.bt.co.uk> To: jdrake@calient.net Cc: neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Fri, 20 Oct 2000 11:43:19 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi John, Thanks for the intelligent replies. If you disagree with my observations, I'd be happier if you could give me an explanation as to why though. My current thinking is that the peer model is impractical in a multi-client OTN. Feel free to explain to me why that thinking is wrong. Regards, Darren. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: 19 October 2000 18:33 To: 'darren.freeland@bt.com'; braja@tellium.com Cc: azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Whatever -----Original Message----- From: darren.freeland@bt.com [mailto:darren.freeland@bt.com] Sent: Thursday, October 19, 2000 10:21 AM To: John Drake; braja@tellium.com Cc: azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Hi John, At the risk of sounding repetitous ... >> There's no reason why the back >> end couldn't be GMPLS in peer mode I believe there is a reason. And I've yet to be convinced otherwise by anyone. The way I see it, peer model = single control plane. Single control plane = common addressing, signalling, & routing. Common addressing = only possible if the OTN has a single client. This has been explained in the recent "server layer trails = client layer links" links discussions => i.e. common addressing not possible in a multi-client OTN => i.e. peer model impractical in a multi-client OTN. I think this fundamental issue has to be recognised. Regards, Darren. -----Original Message----- From: John Drake [mailto:jdrake@calient.net] Sent: 19 October 2000 17:58 To: 'Bala Rajagopalan' Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Bala, I think that there's a big difference between the service interface offered to a user (aka the front end) and the interface that a service device uses to attach to the rest of the network (aka the back end). There's no reason why the back end couldn't be GMPLS in peer mode even if the front end was something silly like ATM UNI. Thanks, John -----Original Message----- From: Bala Rajagopalan [mailto:braja@tellium.com] Sent: Thursday, October 19, 2000 9:42 AM To: John Drake Cc: 'darren.freeland@bt.com'; azinin@cisco.com; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh Hello, John Drake wrote: > > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) In the case of IP over optical, I would just like to add that once you do have an IP-centric control plane within optical networks, you could have routing between IP and optical network that in fact supports the overlay model, alleviating the scalability concerns that arise with IP over ATM model described above. It's then a question of the coupling between the IP and optical control planes. This can be as loose or tight as you want, for example, supporting a UNI that separates the control planes, or the peer model without any separation. I do agree that if you considered other types of clients, the peer model constructs don't seem practical. regards, -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Fri Oct 20 07:24:25 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21457 for ; Fri, 20 Oct 2000 07:24:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsf28208; Fri, 20 Oct 2000 11:24:11 GMT Received: by mail-control.mail.uu.net id QQjlsf11783 for mpls-outgoing; Fri, 20 Oct 2000 11:23:48 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlsf11773 for ; Fri, 20 Oct 2000 11:23:42 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlsf08133 for ; Fri, 20 Oct 2000 11:22:57 GMT From: darren.freeland@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjlsf07731 for ; Fri, 20 Oct 2000 11:22:56 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by gandalf (local) with ESMTP; Fri, 20 Oct 2000 11:52:24 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <4W3A0GD9>; Fri, 20 Oct 2000 11:51:50 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C724@mbtlipnt01.btlabs.bt.co.uk> To: xuyg@lucent.com Cc: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Fri, 20 Oct 2000 11:51:06 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Yangguang, Yes, perhaps the choice of overlay or peer model should be left to operators dependent on their business models. I recall that there was a draft from Lucent & Japan Telecom presented in Pittsburgh that touched on possible business models for the OTN (draft-hayata-ipo-carrier-needs). Perhaps these need to be included in a new draft that fully considers operator requirements for the optical layer ... Regards, Darren. -----Original Message----- From: Yangguang Xu [mailto:xuyg@lucent.com] Sent: 19 October 2000 18:31 To: mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh Hi, Should peer/overaly model the choice of service providers according to their business models? Yangguang John Drake wrote: > > Darren, > > GMPLS allows, but does not require, multiple types of hierarchically related > LSPs to exist in a single instance of a link state database. If a network > owner decides to have MPLS devices supporting multiple types of LSPs in the > same instance of a link state database, then his network is an instantiation > the peer model. > > From my perspective, the focus of the peer model is to facilitate how a > network owner constructs his network most efficiently and not how he > represents it to his customers. The latter is typically done using multiple > service definitions. > > For example, a few years ago, one would build an IP service using routers > mesh connected in an overlay on top of a PNNI transport network. This was > perceived as an exquisitely painful way of doing things and led directly to > the development of MPLS. I.e., extend the IP control plane to support > traffic engineering and then have the ATM switches implement MPLS. This > eliminates the artificial overlay boundary between IP routers and ATM > switches. (On the other hand, there would still be operational benefits to > using MPLS to control the ATM switches even if the network owner wished to > maintain this overlay boundary.) > > GMPLS just extends this concept to encompass other types of transport > networks. > > Thanks, > > John > > -----Original Message----- > From: darren.freeland@bt.com [mailto:darren.freeland@bt.com] > Sent: Thursday, October 19, 2000 2:53 AM > To: azinin@cisco.com; neil.2.harrison@bt.com > Cc: mpls@UU.NET; ip-optical@lists.bell-labs.com > Subject: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes > From Pittsburgh > > Hi Alex, > > >>> - "server layer trails (in an OTN) = client layer links", and > >>> networks operators *will* have to support multiple client > >>> layers for a very long time...including some large BW servives > >>> directly off the L1 fabric. > >>> > >>> This is a really important point. It is a fundamental > >>> characteristic of a layered network architecture. > > > > [AZ] Got it. I didn't realize what layers you meant. > > This is the first time I have actually seen anyone on the MPLS or IPO lists > publicly acknowledge the "client layer links = server layer trails" fact. I > assume then that you now also acknowledge the single control plane 'Peer' > model as being impractical? Okay, using a single 'best of breed' routing > protocol and a single 'best of breed' signalling protocol across the IP and > optical layers may be feasible (I stress may), but it follows from the above > simple concept (as Neil Harrison stated before) that the addresing scheme > used by the optical layer cannot be related to any particular clients (ie > not from the same addressing space in terms of possible trail connectivity > at layer network access points). Sure this would not be the case if IP was > the only client of the optical layer, but (*reality check*), operators WILL > still be making most of their revenue from non-IP clients for a long time to > come, and therefore an optical transport network WILL have to support > multiple clients. > > Are we now seeing a realisation of this in the IETF? I think it's obvious > that what was defined as the 'Overlay' model in > draft-awduche-mpls-te-optical-02.txt and > draft-many-ip-optical-framework-01.txt must be developed first. > > Cheers, > Darren. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Fri Oct 20 10:31:23 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23338 for ; Fri, 20 Oct 2000 10:31:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlss27595; Fri, 20 Oct 2000 14:30:34 GMT Received: by mail-control.mail.uu.net id QQjlss04635 for mpls-outgoing; Fri, 20 Oct 2000 14:30:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlss04630 for ; Fri, 20 Oct 2000 14:30:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlsr07309 for ; Fri, 20 Oct 2000 14:29:10 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjlsr25384 for ; Fri, 20 Oct 2000 14:29:09 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA17348 for ; Fri, 20 Oct 2000 07:29:13 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA04445 for mpls@uu.net; Fri, 20 Oct 2000 10:29:08 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlpz21268 for ; Thu, 19 Oct 2000 20:47:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlpz00510 for ; Thu, 19 Oct 2000 20:47:27 GMT Received: from acmex.gatech.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: acmex.gatech.edu [130.207.165.22]) id QQjlpz27466 for ; Thu, 19 Oct 2000 20:47:27 GMT Received: (from gte358s@localhost) by acmex.gatech.edu (8.9.2/8.9.2) id QAA06017 for mpls@uu.net; Thu, 19 Oct 2000 16:47:22 -0400 (EDT) From: Sung-eok Jeon Message-Id: <200010192047.QAA06017@acmex.gatech.edu> Subject: Is IP TOS field changed by LSR? To: mpls@UU.NET Date: Thu, 19 Oct 2000 16:47:22 -0400 (EDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dear Concerns, How are you doing? I and my friend are using the linux-mpls-ldp.pre7-0.200 to setup a MPLS network supporting serveral service classes. While we are trying to do setup our own network, we come upon a weird phenomenon. We think we observed that the TOS field of IP header is changed from LSR to LSR. Is it really true that the TOS field is modified from LSR to LSR? If the above is true? what is the reason? (I guess the front part of IP header might be used as a Label field. Is it right? ) ------------------------------------------------------------------------- The followings are what we are now trying to do : 1) Setup LSP( Source-LSR1-LSR2-Destination) 2) marking the TOS of IP header at LSR1. Because we want to support multiple services, we want to use the TOS field of the IP header. 3) Ping from source to destination and observe the packet content with Smartbit (between LSR1 and LSR2/ between LSR2 and destination). ==> Different TOS values according to different observing position. ------------------------------------------------------------------------- I hope some of you tell me if there is any mechanism modifying the TOS field of IP header in the program. If ture, Is there any other new version which does not change the TOS field? Thanks in advance. Sung-eok Jeon From owner-mpls@UU.NET Fri Oct 20 10:37:03 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24567 for ; Fri, 20 Oct 2000 10:37:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlss10213; Fri, 20 Oct 2000 14:36:42 GMT Received: by mail-control.mail.uu.net id QQjlss04957 for mpls-outgoing; Fri, 20 Oct 2000 14:36:11 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlss04896 for ; Fri, 20 Oct 2000 14:35:57 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlss04423 for ; Fri, 20 Oct 2000 14:35:34 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjlss08579 for ; Fri, 20 Oct 2000 14:35:33 GMT Received: from tellium.com ([192.168.24.187]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9KERoX16436; Fri, 20 Oct 2000 10:27:51 -0400 (EDT) Message-ID: <39F06570.FD3674A5@tellium.com> Date: Fri, 20 Oct 2000 10:32:00 -0500 From: Debanjan Saha Organization: Tellium Optical Systems X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: darren.freeland@bt.com CC: neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh References: <71DA16F18D32D2119A1D0000F8FE9A940920C723@mbtlipnt01.btlabs.bt.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Darren, darren.freeland@bt.com wrote: > My current thinking is that the peer model is impractical > in a multi-client OTN. That's my thinking too. Clearly, there are "faithfuls" out there who don't agree with this view :-) Debanjan -- Debanjan Saha Phone: 732-923-4264 Senior Network Architect Fax: 732-923-9804 Tellium Optical Systems http://www.tellium.com From owner-mpls@UU.NET Fri Oct 20 10:50:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27237 for ; Fri, 20 Oct 2000 10:50:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlst28974; Fri, 20 Oct 2000 14:49:53 GMT Received: by mail-control.mail.uu.net id QQjlst06007 for mpls-outgoing; Fri, 20 Oct 2000 14:49:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlst05997 for ; Fri, 20 Oct 2000 14:49:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlst05037 for ; Fri, 20 Oct 2000 14:48:22 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f308.law9.hotmail.com [64.4.8.183]) id QQjlst14481 for ; Fri, 20 Oct 2000 14:48:21 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Oct 2000 07:48:12 -0700 Received: from 24.164.190.173 by lw9fd.law9.hotmail.msn.com with HTTP; Fri, 20 Oct 2000 14:48:11 GMT X-Originating-IP: [24.164.190.173] From: "Mike Badil" To: wswen@ece.ucdavis.edu, mpls@UU.NET Subject: Re: Traffic engineering and RSVP Date: Fri, 20 Oct 2000 10:48:11 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Oct 2000 14:48:12.0172 (UTC) FILETIME=[C5121CC0:01C03AA4] Sender: owner-mpls@UU.NET Precedence: bulk Thanks eveybody for answer, see my comments below, >In fact, I think the discussion here missed something on the the basic >operation of the IP network. To send a data packet from a source to a >destination, we need to refer to two components--the >information carried inside the packet and a routing tabel (or switching >table). Because the >conventional IP network's routing is based on the destination address, if >we want to route the packet via an explicit path, it is necessary for the >IP header to carry some additional information. IP uses optional header to >carry the explicit route information so that the router inside the network >can process the explicit route request instead of the >destination-based routing. However, the processing overhead for such >optional header is prohibiting high and it is not a very good solution for >traffic engineering. ------------------------------------------------------------- Yes, I absulutly agree with you. So far it is very clear to me. ------------------------------------------------------- >Without MPLS, evern though we can use OSPF or other >link-state routing protocol to distribute the routing information, and use >the RSVP or other protocols to reserved the network resource, it >can not eliminate the requirement of the data packet to carrry the >explicit route information. Otherwise, the data packet will not follow the >explicit path. ------------------------------------------------------------------- But how does it happened in RSVP, it established the path first then forward packets over pre-established path. isn,t it explicit path? I know, since we don't use swithing it will be slower than in case of swithing(MPLS).But lets forget about scalibility of RSVP, since in RSVP the paths are pre-established, in first router which makes the decision I can choose same the path for RSVP and MPLS, because both can use same algorithm to calculate the path. but after that MPLS path will be faster than the RSVP path because it use swithing. My question is; when you say RSVP will not use the explicit path what you mean, what today's RSVP doing? I think it established the path first then all the packets belongs to same flow follow same path. If this case true, then by using RSVP for pre-established path, we can satisfy TE requirments, such as lightly loaded path, link utilization etc. Lets forget about scalibility and packet processing time at this moment. Thanks anyway > >MPLS solve this problem by doing label swapping instead of the >destination-based routing. Therefore, it is possible for a data packet to >use a >very short header to direct the router to send the packet to the >pre-selected route. > > >Wushao > >On Thu, 19 Oct 2000, Bora Akyol wrote: > > > I would not jump on this so fast, there is at least one router out there >that can > > do line rate 5-tuple lookups for many, many rules. > > > > Just because **you** don't know how to do it, doesn't mean it can't be >done. > > > > Bora > > > > > > > > Sudheer Dharanikota wrote: > > > > > Yes sir.. you are missing many things. > > > > > > TE is mainly used for core. In core nobody in right mind > > > will do 5 tuple lookup on the the Ip packet :-) > > > > > > - sudheer > > > > > > Rajeev Manur wrote: > > > > > > > > see below... > > > > > > > > -----Original Message----- > > > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > > > Sent: Thursday, October 19, 2000 7:21 AM > > > > To: Mike Badil > > > > Cc: mpls@UU.NET > > > > Subject: Re: Traffic engineering and RSVP > > > > > > > > Mike Badil wrote: > > > > > > > > > > Hi > > > > > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > > > > > My question is: > > > > > > > > > > MPLS is combination of layer 2 swithing and layer 3 routing. >Traffic eng. > > > > is > > > > > part of layer 3. In MPLS route(LSP) is established in advance >according to > > > > > the constraints. in other word, instead of choosing shortest path, >it > > > > choose > > > > > the path which satisfy its requirments, and to make link >utulization > > > > better. > > > > > In order to have done this with MPLS there are some works which >say that > > > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > > > > > That is clear so far, > > > > > > > > > > I wondering that whether we can have those traffic engineering >conditions > > > > be > > > > > satisfied by other tech. > > > > > > > > > > For example; RSVP-Intserv set up route in advance also. If we use >extended > > > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > > > > > we can choose the path which satisfy our constraints instead of >choosing > > > > > Shortest path. Link load balancing can be done as in MPLS. So most >of > > > > > traffic engineering requirements will be satisfied.(let don't >consider > > > > > scalibility problem with RSVP now). Or it can work any other >technology > > > > > which use RSVP. > > > > > > > > > > > > > The problem is in applying filter at every node to make sure your IP > > > > packet > > > > is following the selected path. Hence data path becomes slow. > > > > > > > > RAJEEV> I thought almost all the boxes today perform complete packet > > > > processing at line-rate with or without the application of packet >filters. I > > > > don't see the relevence of the above statment. Am i missing >anything.. > > > > > > > > - sudheer > > > > > > > > > What am I missing here? > > > > > > > > > > >_________________________________________________________________________ > > > > > Get Your Private, Free E-mail from MSN Hotmail at >http://www.hotmail.com. > > > > > > > > > > Share information about yourself, create your own public profile >at > > > > > http://profiles.msn.com. > > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Fri Oct 20 10:56:51 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28026 for ; Fri, 20 Oct 2000 10:56:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlst10117; Fri, 20 Oct 2000 14:56:10 GMT Received: by mail-control.mail.uu.net id QQjlst06345 for mpls-outgoing; Fri, 20 Oct 2000 14:55:37 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlst06340 for ; Fri, 20 Oct 2000 14:55:34 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlst09779 for ; Fri, 20 Oct 2000 14:54:38 GMT Received: from cowansville.acbm.qc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjlst07222 for ; Fri, 20 Oct 2000 14:54:29 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca; Fri, 20 Oct 2000 10:54:18 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id <4GAKAYY8>; Fri, 20 Oct 2000 10:54:14 -0400 Message-ID: <91E486361D4CD311B3140060089A882556A482@hermes.hyperchip.com> From: Eyad Saheb To: "'Sung-eok Jeon'" Cc: "'mpls@UU.NET'" Subject: RE: Is IP TOS field changed by LSR? Date: Fri, 20 Oct 2000 10:54:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03AA5.9CA7C770" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03AA5.9CA7C770 Content-Type: text/plain; charset="iso-8859-1" I'm not familiar with the LDP implementation on Linux, but MPLS should not be modifying anything above/behind the label (shim or not); that would defeat the Multi-Protocol aspect. ps. Why not use the EXP bits to differentiate service classes ? Using the IP TOS bits means you're going through the IP stack at each hop. Perhaps your problem is there. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Sung-eok Jeon Sent: Thursday, October 19, 2000 4:47 PM To: mpls@UU.NET Subject: Is IP TOS field changed by LSR? Dear Concerns, How are you doing? I and my friend are using the linux-mpls-ldp.pre7-0.200 to setup a MPLS network supporting serveral service classes. While we are trying to do setup our own network, we come upon a weird phenomenon. We think we observed that the TOS field of IP header is changed from LSR to LSR. Is it really true that the TOS field is modified from LSR to LSR? If the above is true? what is the reason? (I guess the front part of IP header might be used as a Label field. Is it right? ) ------------------------------------------------------------------------- The followings are what we are now trying to do : 1) Setup LSP( Source-LSR1-LSR2-Destination) 2) marking the TOS of IP header at LSR1. Because we want to support multiple services, we want to use the TOS field of the IP header. 3) Ping from source to destination and observe the packet content with Smartbit (between LSR1 and LSR2/ between LSR2 and destination). ==> Different TOS values according to different observing position. ------------------------------------------------------------------------- I hope some of you tell me if there is any mechanism modifying the TOS field of IP header in the program. If ture, Is there any other new version which does not change the TOS field? Thanks in advance. Sung-eok Jeon ------_=_NextPart_001_01C03AA5.9CA7C770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Is IP TOS field changed by LSR?

I'm not familiar with the LDP implementation on = Linux, but MPLS should not be modifying anything above/behind the label = (shim or not); that would defeat the Multi-Protocol aspect.

ps. Why not use the EXP bits to differentiate service = classes ?  Using the IP TOS bits means you're going through the IP = stack at each hop.  Perhaps your problem is there.

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Sung-eok
Jeon
Sent: Thursday, October 19, 2000 4:47 PM
To: mpls@UU.NET
Subject: Is IP TOS field changed by LSR?


Dear Concerns,

How are you doing?

I and my friend are using the = linux-mpls-ldp.pre7-0.200

to setup a MPLS network supporting serveral service = classes.

While we are trying to do setup our own network, =

we come upon a weird phenomenon.

We think we observed that the TOS field of IP header = is changed

from LSR to LSR.

Is it really true that the TOS field is modified from = LSR to LSR?

If the above is true? what is the reason?  =

(I guess the front part of IP header might be used as = a Label field.

 Is it right? )
 
---------------------------------------------------------------= ----------

The followings are what we are now trying to do = :

  
1) Setup LSP( Source-LSR1-LSR2-Destination)

2) marking the TOS of IP header at LSR1.

   Because we want to support multiple = services, we want to

   use the TOS field of the IP = header.

3) Ping from source to destination and observe the = packet content

   with Smartbit (between LSR1 and LSR2/ = between LSR2 and destination).


=3D=3D> Different TOS values according to = different observing position.

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

I hope some of you tell me if there is any mechanism = modifying

the TOS field of IP header in the program.

If ture, Is there any other new version which does = not change the TOS field? 

Thanks in advance.

Sung-eok Jeon 
 

------_=_NextPart_001_01C03AA5.9CA7C770-- From owner-mpls@UU.NET Fri Oct 20 11:15:30 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00663 for ; Fri, 20 Oct 2000 11:15:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsu06291; Fri, 20 Oct 2000 15:14:10 GMT Received: by mail-control.mail.uu.net id QQjlsu19434 for mpls-outgoing; Fri, 20 Oct 2000 15:13:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlsu19428 for ; Fri, 20 Oct 2000 15:13:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlsu19280 for ; Fri, 20 Oct 2000 15:13:20 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlsu05791 for ; Fri, 20 Oct 2000 15:13:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA21109 for mpls@uu.net; Fri, 20 Oct 2000 11:13:19 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlsu19385 for ; Fri, 20 Oct 2000 15:12:49 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlsu25798 for ; Fri, 20 Oct 2000 15:10:53 GMT Received: from procyon.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjlsu15878 for ; Fri, 20 Oct 2000 15:10:52 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA00971; Fri, 20 Oct 2000 08:10:20 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Oct 2000 08:15:34 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A15@BBY1EXM01> From: Shahram Davari To: "'Mike Badil'" , wswen@ece.ucdavis.edu, mpls@UU.NET Subject: RE: Traffic engineering and RSVP Date: Fri, 20 Oct 2000 08:15:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Mike, As you know RSVP uses hop-by-hop routing in which each hop independently computes the next hop. I think your confusion comes from the fact that in your RSVP example you are assuming that all nodes (even the interior nodes) are running the constraint based routing computation, so that there is no need for source routing (explicit routing), rather their hop-by-hop routing results the same path as the explicit route. This is in theory possible, but it requires massive computation by all the nodes. In comparison, MPLS requires the path computation be done only by one node (the ingress node) and then distribute the computed path to the downstream nodes. Regards, -Shahram > -----Original Message----- > From: Mike Badil [mailto:hasko10@hotmail.com] > Sent: Friday, October 20, 2000 10:48 AM > To: wswen@ece.ucdavis.edu; mpls@UU.NET > Subject: Re: Traffic engineering and RSVP > > > > Thanks eveybody for answer, > see my comments below, > > > > >In fact, I think the discussion here missed something on the > the basic > >operation of the IP network. To send a data packet from a source to a > >destination, we need to refer to two components--the > >information carried inside the packet and a routing tabel > (or switching > >table). Because the > >conventional IP network's routing is based on the > destination address, if > >we want to route the packet via an explicit path, it is > necessary for the > >IP header to carry some additional information. IP uses > optional header to > >carry the explicit route information so that the router > inside the network > >can process the explicit route request instead of the > >destination-based routing. However, the processing overhead for such > >optional header is prohibiting high and it is not a very > good solution for > >traffic engineering. > ------------------------------------------------------------- > Yes, I absulutly agree with you. So far it is very clear to me. > ------------------------------------------------------- > >Without MPLS, evern though we can use OSPF or other > >link-state routing protocol to distribute the routing > information, and use > >the RSVP or other protocols to reserved the network resource, it > >can not eliminate the requirement of the data packet to carrry the > >explicit route information. Otherwise, the data packet will > not follow the > >explicit path. > ------------------------------------------------------------------- > But how does it happened in RSVP, it established the path > first then forward > packets over pre-established path. isn,t it explicit path? > > I know, since we don't use swithing it will be slower than in case of > swithing(MPLS).But lets forget about scalibility of RSVP, > since in RSVP the > paths are pre-established, in first router which makes the > decision I can > choose same the path for RSVP and MPLS, because both can use > same algorithm > to calculate the path. but after that MPLS path will be > faster than the RSVP > path because it use swithing. > > My question is; when you say RSVP will not use the explicit > path what you > mean, what today's RSVP doing? I think it established the > path first then > all the packets belongs to same flow follow same path. If > this case true, > then by using RSVP for pre-established path, we can satisfy > TE requirments, > such as lightly loaded path, link utilization etc. > Lets forget about scalibility and packet processing time at > this moment. > > > Thanks anyway > > > >MPLS solve this problem by doing label swapping instead of the > >destination-based routing. Therefore, it is possible for a > data packet to > >use a > >very short header to direct the router to send the packet to the > >pre-selected route. > > > > > >Wushao > > > >On Thu, 19 Oct 2000, Bora Akyol wrote: > > > > > I would not jump on this so fast, there is at least one > router out there > >that can > > > do line rate 5-tuple lookups for many, many rules. > > > > > > Just because **you** don't know how to do it, doesn't > mean it can't be > >done. > > > > > > Bora > > > > > > > > > > > > Sudheer Dharanikota wrote: > > > > > > > Yes sir.. you are missing many things. > > > > > > > > TE is mainly used for core. In core nobody in right mind > > > > will do 5 tuple lookup on the the Ip packet :-) > > > > > > > > - sudheer > > > > > > > > Rajeev Manur wrote: > > > > > > > > > > see below... > > > > > > > > > > -----Original Message----- > > > > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > > > > Sent: Thursday, October 19, 2000 7:21 AM > > > > > To: Mike Badil > > > > > Cc: mpls@UU.NET > > > > > Subject: Re: Traffic engineering and RSVP > > > > > > > > > > Mike Badil wrote: > > > > > > > > > > > > Hi > > > > > > > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > > > > > > > My question is: > > > > > > > > > > > > MPLS is combination of layer 2 swithing and layer 3 > routing. > >Traffic eng. > > > > > is > > > > > > part of layer 3. In MPLS route(LSP) is established > in advance > >according to > > > > > > the constraints. in other word, instead of choosing > shortest path, > >it > > > > > choose > > > > > > the path which satisfy its requirments, and to make link > >utulization > > > > > better. > > > > > > In order to have done this with MPLS there are some > works which > >say that > > > > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > > > > > > > That is clear so far, > > > > > > > > > > > > I wondering that whether we can have those traffic > engineering > >conditions > > > > > be > > > > > > satisfied by other tech. > > > > > > > > > > > > For example; RSVP-Intserv set up route in advance > also. If we use > >extended > > > > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we > use in MPLS, > > > > > > we can choose the path which satisfy our > constraints instead of > >choosing > > > > > > Shortest path. Link load balancing can be done as > in MPLS. So most > >of > > > > > > traffic engineering requirements will be > satisfied.(let don't > >consider > > > > > > scalibility problem with RSVP now). Or it can work > any other > >technology > > > > > > which use RSVP. > > > > > > > > > > > > > > > > The problem is in applying filter at every node to > make sure your IP > > > > > packet > > > > > is following the selected path. Hence data path becomes slow. > > > > > > > > > > RAJEEV> I thought almost all the boxes today perform > complete packet > > > > > processing at line-rate with or without the > application of packet > >filters. I > > > > > don't see the relevence of the above statment. Am i missing > >anything.. > > > > > > > > > > - sudheer > > > > > > > > > > > What am I missing here? > > > > > > > > > > > > > >_____________________________________________________________ > ____________ > > > > > > Get Your Private, Free E-mail from MSN Hotmail at > >http://www.hotmail.com. > > > > > > > > > > > > Share information about yourself, create your own > public profile > >at > > > > > > http://profiles.msn.com. > > > > > > > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Fri Oct 20 11:47:42 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04617 for ; Fri, 20 Oct 2000 11:47:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsx07737; Fri, 20 Oct 2000 15:46:43 GMT Received: by mail-control.mail.uu.net id QQjlsx22045 for mpls-outgoing; Fri, 20 Oct 2000 15:45:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlsx22038 for ; Fri, 20 Oct 2000 15:45:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlsw29152 for ; Fri, 20 Oct 2000 15:43:47 GMT Received: from bass.ece.ucdavis.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bass.ece.ucdavis.edu [169.237.32.177]) id QQjlsw03309 for ; Fri, 20 Oct 2000 15:43:47 GMT Received: from localhost (wswen@localhost) by bass.ece.ucdavis.edu (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id IAA10907; Fri, 20 Oct 2000 08:43:12 -0700 (PDT) Date: Fri, 20 Oct 2000 08:43:12 -0700 (PDT) From: Wushao Wen To: Shahram Davari cc: "'Mike Badil'" , mpls@UU.NET Subject: RE: Traffic engineering and RSVP In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A15@BBY1EXM01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Yes. Shahram is right. In fact, the major task for RSVP is to reserve the necessary resource along the path for a connection. Explicit routing is not a concern of the RSVP. RSVP does not change the basic packet routing mechanism--analyze the packet header and then do destination-based routing to select the next hop. Sincerly, Wushao > > As you know RSVP uses hop-by-hop routing in which each hop independently > computes the next hop. > > I think your confusion comes from the fact that in your RSVP example you are > assuming that all nodes (even the interior nodes) are running the constraint > based routing computation, so that there is no need for source routing > (explicit routing), rather their hop-by-hop routing results the same path as > the explicit route. This is in theory possible, but it requires massive > computation by all the nodes. In comparison, MPLS requires the path > computation be done only by one node (the ingress node) and then distribute > the computed path to the downstream nodes. > > Regards, > -Shahram > > > -----Original Message----- > > From: Mike Badil [mailto:hasko10@hotmail.com] > > Sent: Friday, October 20, 2000 10:48 AM > > To: wswen@ece.ucdavis.edu; mpls@UU.NET > > Subject: Re: Traffic engineering and RSVP > > > > > > > > Thanks eveybody for answer, > > see my comments below, > > > > > > > > >In fact, I think the discussion here missed something on the > > the basic > > >operation of the IP network. To send a data packet from a source to a > > >destination, we need to refer to two components--the > > >information carried inside the packet and a routing tabel > > (or switching > > >table). Because the > > >conventional IP network's routing is based on the > > destination address, if > > >we want to route the packet via an explicit path, it is > > necessary for the > > >IP header to carry some additional information. IP uses > > optional header to > > >carry the explicit route information so that the router > > inside the network > > >can process the explicit route request instead of the > > >destination-based routing. However, the processing overhead for such > > >optional header is prohibiting high and it is not a very > > good solution for > > >traffic engineering. > > ------------------------------------------------------------- > > Yes, I absulutly agree with you. So far it is very clear to me. > > ------------------------------------------------------- > > >Without MPLS, evern though we can use OSPF or other > > >link-state routing protocol to distribute the routing > > information, and use > > >the RSVP or other protocols to reserved the network resource, it > > >can not eliminate the requirement of the data packet to carrry the > > >explicit route information. Otherwise, the data packet will > > not follow the > > >explicit path. > > ------------------------------------------------------------------- > > But how does it happened in RSVP, it established the path > > first then forward > > packets over pre-established path. isn,t it explicit path? > > > > I know, since we don't use swithing it will be slower than in case of > > swithing(MPLS).But lets forget about scalibility of RSVP, > > since in RSVP the > > paths are pre-established, in first router which makes the > > decision I can > > choose same the path for RSVP and MPLS, because both can use > > same algorithm > > to calculate the path. but after that MPLS path will be > > faster than the RSVP > > path because it use swithing. > > > > My question is; when you say RSVP will not use the explicit > > path what you > > mean, what today's RSVP doing? I think it established the > > path first then > > all the packets belongs to same flow follow same path. If > > this case true, > > then by using RSVP for pre-established path, we can satisfy > > TE requirments, > > such as lightly loaded path, link utilization etc. > > Lets forget about scalibility and packet processing time at > > this moment. > > > > > > Thanks anyway > > > > > >MPLS solve this problem by doing label swapping instead of the > > >destination-based routing. Therefore, it is possible for a > > data packet to > > >use a > > >very short header to direct the router to send the packet to the > > >pre-selected route. > > > > > > > > >Wushao > > > > > >On Thu, 19 Oct 2000, Bora Akyol wrote: > > > > > > > I would not jump on this so fast, there is at least one > > router out there > > >that can > > > > do line rate 5-tuple lookups for many, many rules. > > > > > > > > Just because **you** don't know how to do it, doesn't > > mean it can't be > > >done. > > > > > > > > Bora > > > > > > > > > > > > > > > > Sudheer Dharanikota wrote: > > > > > > > > > Yes sir.. you are missing many things. > > > > > > > > > > TE is mainly used for core. In core nobody in right mind > > > > > will do 5 tuple lookup on the the Ip packet :-) > > > > > > > > > > - sudheer > > > > > > > > > > Rajeev Manur wrote: > > > > > > > > > > > > see below... > > > > > > > > > > > > -----Original Message----- > > > > > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > > > > > Sent: Thursday, October 19, 2000 7:21 AM > > > > > > To: Mike Badil > > > > > > Cc: mpls@UU.NET > > > > > > Subject: Re: Traffic engineering and RSVP > > > > > > > > > > > > Mike Badil wrote: > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > > > > > > > > > My question is: > > > > > > > > > > > > > > MPLS is combination of layer 2 swithing and layer 3 > > routing. > > >Traffic eng. > > > > > > is > > > > > > > part of layer 3. In MPLS route(LSP) is established > > in advance > > >according to > > > > > > > the constraints. in other word, instead of choosing > > shortest path, > > >it > > > > > > choose > > > > > > > the path which satisfy its requirments, and to make link > > >utulization > > > > > > better. > > > > > > > In order to have done this with MPLS there are some > > works which > > >say that > > > > > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > > > > > > > > > That is clear so far, > > > > > > > > > > > > > > I wondering that whether we can have those traffic > > engineering > > >conditions > > > > > > be > > > > > > > satisfied by other tech. > > > > > > > > > > > > > > For example; RSVP-Intserv set up route in advance > > also. If we use > > >extended > > > > > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we > > use in MPLS, > > > > > > > we can choose the path which satisfy our > > constraints instead of > > >choosing > > > > > > > Shortest path. Link load balancing can be done as > > in MPLS. So most > > >of > > > > > > > traffic engineering requirements will be > > satisfied.(let don't > > >consider > > > > > > > scalibility problem with RSVP now). Or it can work > > any other > > >technology > > > > > > > which use RSVP. > > > > > > > > > > > > > > > > > > > The problem is in applying filter at every node to > > make sure your IP > > > > > > packet > > > > > > is following the selected path. Hence data path becomes slow. > > > > > > > > > > > > RAJEEV> I thought almost all the boxes today perform > > complete packet > > > > > > processing at line-rate with or without the > > application of packet > > >filters. I > > > > > > don't see the relevence of the above statment. Am i missing > > >anything.. > > > > > > > > > > > > - sudheer > > > > > > > > > > > > > What am I missing here? > > > > > > > > > > > > > > > > >_____________________________________________________________ > > ____________ > > > > > > > Get Your Private, Free E-mail from MSN Hotmail at > > >http://www.hotmail.com. > > > > > > > > > > > > > > Share information about yourself, create your own > > public profile > > >at > > > > > > > http://profiles.msn.com. > > > > > > > > > > > ______________________________________________________________ > > ___________ > > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. > From owner-mpls@UU.NET Fri Oct 20 11:56:24 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05752 for ; Fri, 20 Oct 2000 11:56:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsx01140; Fri, 20 Oct 2000 15:55:49 GMT Received: by mail-control.mail.uu.net id QQjlsx22665 for mpls-outgoing; Fri, 20 Oct 2000 15:55:27 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlsx22660 for ; Fri, 20 Oct 2000 15:55:23 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlsx22775 for ; Fri, 20 Oct 2000 15:49:31 GMT Received: from bass.ece.ucdavis.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bass.ece.ucdavis.edu [169.237.32.177]) id QQjlsx29086 for ; Fri, 20 Oct 2000 15:49:31 GMT Received: from localhost (wswen@localhost) by bass.ece.ucdavis.edu (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id IAA10935; Fri, 20 Oct 2000 08:49:18 -0700 (PDT) Date: Fri, 20 Oct 2000 08:49:16 -0700 (PDT) From: Wushao Wen To: Eyad Saheb cc: "'Sung-eok Jeon'" , "'mpls@UU.NET'" Subject: RE: Is IP TOS field changed by LSR? In-Reply-To: <91E486361D4CD311B3140060089A882556A482@hermes.hyperchip.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Please read my commments below. > I'm not familiar with the LDP implementation on Linux, but MPLS should not > be modifying anything above/behind the label (shim or not); that would > defeat the Multi-Protocol aspect. You are right. In the MPLS domain, the modification should only on shim label. > > ps. Why not use the EXP bits to differentiate service classes ? Using the > IP TOS bits means you're going through the IP stack at each hop. Perhaps > your problem is there. In fact, EXP is already suggested to be used for differentiate service classes. However, the IP header has six bits in TOS (eliminte 2 bits not used by differential service). So it is possible to use different labels for different service classes. Wushao > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Sung-eok > Jeon > Sent: Thursday, October 19, 2000 4:47 PM > To: mpls@UU.NET > Subject: Is IP TOS field changed by LSR? > > > Dear Concerns, > > How are you doing? > > I and my friend are using the linux-mpls-ldp.pre7-0.200 > > to setup a MPLS network supporting serveral service classes. > > While we are trying to do setup our own network, > > we come upon a weird phenomenon. > > We think we observed that the TOS field of IP header is changed > > from LSR to LSR. > > Is it really true that the TOS field is modified from LSR to LSR? > > If the above is true? what is the reason? > > (I guess the front part of IP header might be used as a Label field. > > Is it right? ) > > ------------------------------------------------------------------------- > > The followings are what we are now trying to do : > > > 1) Setup LSP( Source-LSR1-LSR2-Destination) > > 2) marking the TOS of IP header at LSR1. > > Because we want to support multiple services, we want to > > use the TOS field of the IP header. > > 3) Ping from source to destination and observe the packet content > > with Smartbit (between LSR1 and LSR2/ between LSR2 and destination). > > > ==> Different TOS values according to different observing position. > > ------------------------------------------------------------------------- > > I hope some of you tell me if there is any mechanism modifying > > the TOS field of IP header in the program. > > If ture, Is there any other new version which does not change the TOS field? > > > Thanks in advance. > > Sung-eok Jeon > > From owner-mpls@UU.NET Fri Oct 20 12:04:06 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06758 for ; Fri, 20 Oct 2000 12:04:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsy01003; Fri, 20 Oct 2000 16:03:03 GMT Received: by mail-control.mail.uu.net id QQjlsy29493 for mpls-outgoing; Fri, 20 Oct 2000 16:02:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlsy29059 for ; Fri, 20 Oct 2000 16:02:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlsy11791 for ; Fri, 20 Oct 2000 16:02:13 GMT Received: from server.nayna.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) id QQjlsy12503 for ; Fri, 20 Oct 2000 16:02:12 GMT Received: from nayna.com (sonicwall [64.145.162.226]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id JAA12503; Fri, 20 Oct 2000 09:02:04 -0700 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be nayna.com Message-ID: <39F050D8.4F66A3B8@nayna.com> Date: Fri, 20 Oct 2000 09:04:08 -0500 From: Sudheer Dharanikota X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rajeev Manur CC: Mike Badil , mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: <2cc395ba3ea2621cc6bd76adb5827a3c39ef632b@force10networks.com> Content-Type: multipart/mixed; boundary="------------69BDB0DDD71C0776F516E00F" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------69BDB0DDD71C0776F516E00F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rajeev: See below. Rajeev Manur wrote: > > see below > > -----Original Message----- > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > Sent: Thursday, October 19, 2000 11:45 AM > To: Rajeev Manur > Cc: Mike Badil; mpls@UU.NET > Subject: Re: Traffic engineering and RSVP > > Yes sir.. you are missing many things. > > TE is mainly used for core. In core nobody in right mind > will do 5 tuple lookup on the the Ip packet :-) > > RAJEEV> I never said anybody would or would not do 5 tuple lkup in the core. > All i am saying is that your statement "Hence data path becomes slow" does > not make any sense, because as far as i know today's packet processors can > handle this without affecting the line-rate performance.. Yes.. most of the router vendors have to do 5 tuple lookup for some reason or the other. But the following should be the considerations. From data plane point-of-view: 1. How many look ups do you want to do? 2. Does other routers in the same domain (or AS) do the same for the traffic (at line rate)? 3. What are the line rates we are talking about? From control plane point-of-view: 1. Does make sense to have the state kept for all these intserv conns? 2. Do we (being ISPs) have to care about the individual connections from the other ISPs? - sudheer > > with regards, > Rajeev. > > - sudheer > > Rajeev Manur wrote: > > > > see below... > > > > -----Original Message----- > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > Sent: Thursday, October 19, 2000 7:21 AM > > To: Mike Badil > > Cc: mpls@UU.NET > > Subject: Re: Traffic engineering and RSVP > > > > Mike Badil wrote: > > > > > > Hi > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > My question is: > > > > > > MPLS is combination of layer 2 swithing and layer 3 routing. Traffic > eng. > > is > > > part of layer 3. In MPLS route(LSP) is established in advance according > to > > > the constraints. in other word, instead of choosing shortest path, it > > choose > > > the path which satisfy its requirments, and to make link utulization > > better. > > > In order to have done this with MPLS there are some works which say that > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > That is clear so far, > > > > > > I wondering that whether we can have those traffic engineering > conditions > > be > > > satisfied by other tech. > > > > > > For example; RSVP-Intserv set up route in advance also. If we use > extended > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > > > we can choose the path which satisfy our constraints instead of choosing > > > Shortest path. Link load balancing can be done as in MPLS. So most of > > > traffic engineering requirements will be satisfied.(let don't consider > > > scalibility problem with RSVP now). Or it can work any other technology > > > which use RSVP. > > > > > > > The problem is in applying filter at every node to make sure your IP > > packet > > is following the selected path. Hence data path becomes slow. > > > > RAJEEV> I thought almost all the boxes today perform complete packet > > processing at line-rate with or without the application of packet filters. > I > > don't see the relevence of the above statment. Am i missing anything.. > > > > - sudheer > > > > > What am I missing here? > > > > > > > _________________________________________________________________________ > > > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > > > > > > Share information about yourself, create your own public profile at > > > http://profiles.msn.com. --------------69BDB0DDD71C0776F516E00F Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dharanikota;Sudheer tel;cell:408-829-8812 tel;work:408-956-8000 X357 x-mozilla-html:TRUE org:Nayna Networks adr:;;;;;; version:2.1 email;internet:sudheer@nayna.com fn:Sudheer Dharanikota end:vcard --------------69BDB0DDD71C0776F516E00F-- From owner-mpls@UU.NET Fri Oct 20 12:06:44 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07237 for ; Fri, 20 Oct 2000 12:06:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsy05017; Fri, 20 Oct 2000 16:05:35 GMT Received: by mail-control.mail.uu.net id QQjlsy04636 for mpls-outgoing; Fri, 20 Oct 2000 16:04:54 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlsy04624 for ; Fri, 20 Oct 2000 16:04:45 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlsy11422 for ; Fri, 20 Oct 2000 16:04:15 GMT Received: from cowansville.acbm.qc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjlsy24416 for ; Fri, 20 Oct 2000 16:04:12 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca; Fri, 20 Oct 2000 12:04:12 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id <4GAKAY5X>; Fri, 20 Oct 2000 12:03:45 -0400 Message-ID: <91E486361D4CD311B3140060089A882556A486@hermes.hyperchip.com> From: Eyad Saheb To: "'Wushao Wen'" Cc: "'mpls@uu.net'" Subject: RE: Is IP TOS field changed by LSR? Date: Fri, 20 Oct 2000 12:03:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03AAF.523B7510" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03AAF.523B7510 Content-Type: text/plain; charset="iso-8859-1" >> I'm not familiar with the LDP implementation on Linux, but MPLS should not >> be modifying anything above/behind the label (shim or not); that would >> defeat the Multi-Protocol aspect. > > You are right. In the MPLS domain, the modification should only on >shim label. > > >> ps. Why not use the EXP bits to differentiate service classes ? Using the >> IP TOS bits means you're going through the IP stack at each hop. Perhaps >> your problem is there. > >In fact, EXP is already suggested to be used for differentiate service >classes. I know, I wasn't inventing it. Just thought perhaps you were unaware. >However, the IP header has six bits in TOS (eliminte 2 bits not >used by differential service). So it is possible to use different labels >for different service classes. In my understanding, DiffServ over MPLS can be done two ways: L-LSPs, E-LSPs. L-LSPs seems to be what you're doing (using the label to infer service type). If this is the case, then you don't need to look at the IP header (you shouldn't be looking there anyways). Therefore, your network should provide different levels of service even if the IP header gets modified along the way (that seems to be a different story). Eyad ------_=_NextPart_001_01C03AAF.523B7510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Is IP TOS field changed by LSR?

>> I'm not familiar with the LDP implementation = on Linux, but MPLS should not
>> be modifying anything above/behind the = label (shim or not); that would
>> defeat the Multi-Protocol aspect.
>
> You are right.  In the MPLS domain, the = modification should only on
>shim label.
>
>
>> ps. Why not use the EXP bits to = differentiate service classes ?  Using the
>> IP TOS bits means you're going through the = IP stack at each hop.  Perhaps
>> your problem is there.
>
>In fact, EXP is already suggested to be used for = differentiate service
>classes.

        I know, I = wasn't inventing it.  Just thought perhaps you were = unaware.

>However, the IP header has six bits in TOS = (eliminte 2 bits not
>used by differential service). So it is possible = to use different labels
>for different service classes.
 
        In my = understanding, DiffServ over MPLS can be done two ways: L-LSPs,  = E-LSPs. L-LSPs seems to be what you're doing (using the label to infer = service type).  If this is the case, then you don't need to look = at the IP header (you shouldn't be looking there anyways).  = Therefore, your network should provide different levels of service even = if the IP header gets modified along the way (that seems to be a = different story).

Eyad

------_=_NextPart_001_01C03AAF.523B7510-- From owner-mpls@UU.NET Fri Oct 20 12:10:13 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07740 for ; Fri, 20 Oct 2000 12:10:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsy11755; Fri, 20 Oct 2000 16:09:40 GMT Received: by mail-control.mail.uu.net id QQjlsy05276 for mpls-outgoing; Fri, 20 Oct 2000 16:09:06 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlsy05225 for ; Fri, 20 Oct 2000 16:08:54 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlsy20825 for ; Fri, 20 Oct 2000 16:08:24 GMT Received: from server.nayna.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) id QQjlsy09506 for ; Fri, 20 Oct 2000 16:08:22 GMT Received: from nayna.com (sonicwall [64.145.162.226]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id JAA14243; Fri, 20 Oct 2000 09:08:20 -0700 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be nayna.com Message-ID: <39F05250.893891FE@nayna.com> Date: Fri, 20 Oct 2000 09:10:24 -0500 From: Sudheer Dharanikota X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol CC: mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: <7df439c67cc3e994a54787ff1ea79b3739ef4182@force10networks.com> <39EF4114.E34C6401@nayna.com> <39EF81CD.5948029B@pluris.com> Content-Type: multipart/mixed; boundary="------------2EECE3D66EA63B5BE6B6F760" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------2EECE3D66EA63B5BE6B6F760 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Good that there are routers who does the 5 tuple lookup for 1 million connections at line rate of OC-48 :-) But do we need them in the core? - sudheer Bora Akyol wrote: > > I would not jump on this so fast, there is at least one router out there that can > do line rate 5-tuple lookups for many, many rules. > > Just because **you** don't know how to do it, doesn't mean it can't be done. > > Bora > > Sudheer Dharanikota wrote: > > > Yes sir.. you are missing many things. > > > > TE is mainly used for core. In core nobody in right mind > > will do 5 tuple lookup on the the Ip packet :-) > > > > - sudheer > > > > Rajeev Manur wrote: > > > > > > see below... > > > > > > -----Original Message----- > > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > > Sent: Thursday, October 19, 2000 7:21 AM > > > To: Mike Badil > > > Cc: mpls@UU.NET > > > Subject: Re: Traffic engineering and RSVP > > > > > > Mike Badil wrote: > > > > > > > > Hi > > > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > > > My question is: > > > > > > > > MPLS is combination of layer 2 swithing and layer 3 routing. Traffic eng. > > > is > > > > part of layer 3. In MPLS route(LSP) is established in advance according to > > > > the constraints. in other word, instead of choosing shortest path, it > > > choose > > > > the path which satisfy its requirments, and to make link utulization > > > better. > > > > In order to have done this with MPLS there are some works which say that > > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > > > That is clear so far, > > > > > > > > I wondering that whether we can have those traffic engineering conditions > > > be > > > > satisfied by other tech. > > > > > > > > For example; RSVP-Intserv set up route in advance also. If we use extended > > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we use in MPLS, > > > > we can choose the path which satisfy our constraints instead of choosing > > > > Shortest path. Link load balancing can be done as in MPLS. So most of > > > > traffic engineering requirements will be satisfied.(let don't consider > > > > scalibility problem with RSVP now). Or it can work any other technology > > > > which use RSVP. > > > > > > > > > > The problem is in applying filter at every node to make sure your IP > > > packet > > > is following the selected path. Hence data path becomes slow. > > > > > > RAJEEV> I thought almost all the boxes today perform complete packet > > > processing at line-rate with or without the application of packet filters. I > > > don't see the relevence of the above statment. Am i missing anything.. > > > > > > - sudheer > > > > > > > What am I missing here? > > > > > > > > _________________________________________________________________________ > > > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > > > > > > Share information about yourself, create your own public profile at > > > > http://profiles.msn.com. --------------2EECE3D66EA63B5BE6B6F760 Content-Type: text/x-vcard; charset=us-ascii; name="sudheer.vcf" Content-Description: Card for Sudheer Dharanikota Content-Disposition: attachment; filename="sudheer.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dharanikota;Sudheer tel;cell:408-829-8812 tel;work:408-956-8000 X357 x-mozilla-html:TRUE org:Nayna Networks adr:;;;;;; version:2.1 email;internet:sudheer@nayna.com fn:Sudheer Dharanikota end:vcard --------------2EECE3D66EA63B5BE6B6F760-- From owner-mpls@UU.NET Fri Oct 20 12:20:45 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09022 for ; Fri, 20 Oct 2000 12:20:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsz25608; Fri, 20 Oct 2000 16:20:01 GMT Received: by mail-control.mail.uu.net id QQjlsz06346 for mpls-outgoing; Fri, 20 Oct 2000 16:19:34 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlsz06336 for ; Fri, 20 Oct 2000 16:19:31 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlsz00996 for ; Fri, 20 Oct 2000 16:19:10 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjlsz26189 for ; Fri, 20 Oct 2000 16:19:10 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA22851 for ; Fri, 20 Oct 2000 12:19:07 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA21245 for ; Fri, 20 Oct 2000 12:19:10 -0400 (EDT) Message-ID: <39F0707C.767F5EF6@marconi.com> Date: Fri, 20 Oct 2000 12:19:08 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Wushao Wen wrote: > > Yes. Shahram is right. In fact, the major task for RSVP is to reserve > the necessary resource along the path for a connection. Explicit > routing is not a concern of the RSVP. RSVP does not change the basic > packet routing mechanism--analyze the packet header and then do > destination-based routing to select the next hop. For straight RFC-2205 RSVP, yes. RSVP is not a routing protocol. It establishes reservations along whatever path the local routing tables will forward similarly-addressed data. With RSVP-TE (draft-ietf-mpls-rsvp-lsp-tunnel-*), however, this changes. The presence of an explicit route object forces RSVP to reserve bandwidth along the specified route instead of where the local routing table might otherwise dictate. And it must make certain that data packets for the session follow the reserved route instead of the route that the routing tables would otherwise use. (And when these data packets are classified by an MPLS label, we call the result an LSP.) In other words, while straight RSVP does not change the basic packet forwarding mechanism, RSVP-TE definitely does. -- David From owner-mpls@UU.NET Fri Oct 20 12:23:23 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09369 for ; Fri, 20 Oct 2000 12:23:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlsz01661; Fri, 20 Oct 2000 16:22:52 GMT Received: by mail-control.mail.uu.net id QQjlsz06868 for mpls-outgoing; Fri, 20 Oct 2000 16:22:25 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlsz06860 for ; Fri, 20 Oct 2000 16:22:17 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlsz19023 for ; Fri, 20 Oct 2000 16:20:48 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjlsz28523 for ; Fri, 20 Oct 2000 16:20:47 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA12935; Fri, 20 Oct 2000 09:20:44 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id JAA21132; Fri, 20 Oct 2000 09:20:44 -0700 (PDT) Date: Fri, 20 Oct 2000 09:20:44 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010201620.JAA21132@kummer.juniper.net> To: darren.freeland@bt.com, kireeti@juniper.net Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET, neil.2.harrison@bt.com Sender: owner-mpls@UU.NET Precedence: bulk Hi Darren, > Perhaps you missed my point. I didn't say the point of GMPLS is a peer > model (I have read the draft) - I questioned the assumption that IP-centric > control protocols will be appropriate for an optical (or indeed any) control > plane. Could you clarify what you mean by "IP-centric control protocols": a) IP control protocols (such as OSPF, RSVP, CR-LDP), or b) control protocols aimed at serving an IP infrastructure? > As far as I can see (having read the IPO framework, the MPLambdaS, > and the Generalised MPLS drafts I hasten to add), this assumption has been > made without giving full consideration to the requirements of the particular > networks the protocols will be applied to. My interest is the OTN, so > that's what I've been focussing on. Why I ask the above question is that there is a UNI based on IP control protocols (draft-gray-mpls-rsvp-oif-uni-ext-00.txt), which caters to non-IP uses of the OTN, and whose underlying model is the overlay model. This draft is in response to the *OIF*'s requirements for an optical UNI. So, if your objection is to the IP-centricity of the GMPLS approach (which is debatable), you may find the above UNI more suitable to your needs. However, if your objection is to the use of IP control protocols, that's a different issue. Note that the IETF is unlikely to be the right venue for discussing say PNNI as a control plane for the OTN. For what it's worth, the MPLS control plane is IP-based, but serves non-IP uses quite well. There is an upcoming foo-over-MPLS BOF that illustrates this point. [...] > I think a new draft is in order, Very possibly. > but I get the feeling many won't like it. That hardly matters. If it makes sense to service providers, the vendors will come around :-) One thing though is to better articulate what is broken with the current approach. If it's not the "peer vs. overlay" model that's the issue, then like you say, I've missed your point, and would like to understand what the real problem is. Kireeti. From owner-mpls@UU.NET Fri Oct 20 12:31:06 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10412 for ; Fri, 20 Oct 2000 12:31:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlta17078; Fri, 20 Oct 2000 16:30:40 GMT Received: by mail-control.mail.uu.net id QQjlta07633 for mpls-outgoing; Fri, 20 Oct 2000 16:30:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlta07602 for ; Fri, 20 Oct 2000 16:30:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlsz05381 for ; Fri, 20 Oct 2000 16:29:53 GMT Received: from eel.ece.ucdavis.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: eel.ece.ucdavis.edu [169.237.32.164]) id QQjlsz23195 for ; Fri, 20 Oct 2000 16:29:53 GMT Received: from localhost (wswen@localhost) by eel.ece.ucdavis.edu (8.8.7/8.8.7) with ESMTP id JAA24035; Fri, 20 Oct 2000 09:29:50 -0700 (PDT) Date: Fri, 20 Oct 2000 09:29:49 -0700 (PDT) From: Wushao Wen To: David Charlap cc: mpls@UU.NET Subject: Re: Traffic engineering and RSVP In-Reply-To: <39F0707C.767F5EF6@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, David, Sure you are right. What we started with is without the implementation of MPLS, what can RSVP do. This means that we can not use RSVP-TE. So for RSVP itself, it is an resource reservation protool without affecting the basic routing mechanism. The use of RSVP-TE must come together with MPLS, otherwise, RSVP-TE itself can not implement explicit routing. If we sent IP packet directly to the router, even though RSVP-TE was previous used, it wil not follow the explicit route. Correct me if I miss anything. Thanks! Wushao > Wushao Wen wrote: > > > > Yes. Shahram is right. In fact, the major task for RSVP is to reserve > > the necessary resource along the path for a connection. Explicit > > routing is not a concern of the RSVP. RSVP does not change the basic > > packet routing mechanism--analyze the packet header and then do > > destination-based routing to select the next hop. > > For straight RFC-2205 RSVP, yes. RSVP is not a routing protocol. It > establishes reservations along whatever path the local routing tables > will forward similarly-addressed data. > > With RSVP-TE (draft-ietf-mpls-rsvp-lsp-tunnel-*), however, this > changes. > The presence of an explicit route object forces RSVP to reserve > bandwidth along the specified route instead of where the local routing > table might otherwise dictate. And it must make certain that data > packets for the session follow the reserved route instead of the route > that the routing tables would otherwise use. (And when these data > packets are classified by an MPLS label, we call the result an LSP.) > > In other words, while straight RSVP does not change the basic packet > forwarding mechanism, RSVP-TE definitely does. > > -- David > From owner-mpls@UU.NET Fri Oct 20 12:36:14 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11144 for ; Fri, 20 Oct 2000 12:36:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlta00978; Fri, 20 Oct 2000 16:35:18 GMT Received: by mail-control.mail.uu.net id QQjlta08254 for mpls-outgoing; Fri, 20 Oct 2000 16:34:46 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlta08234 for ; Fri, 20 Oct 2000 16:34:28 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlta03647 for ; Fri, 20 Oct 2000 16:33:12 GMT Received: from srnex01.sd.osicom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: srnex01.sd.osicom.com [131.143.32.21]) id QQjlta16709 for ; Fri, 20 Oct 2000 16:33:11 GMT Received: by srnex01.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Oct 2000 09:24:27 -0700 Message-ID: <022A2DBC40A6D411967000D0B78892A61AB2AF@srnex01.sd.osicom.com> From: "Fu, James" To: "'darren.freeland@bt.com'" , kireeti@juniper.net Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET, neil.2.harrison@bt.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Fri, 20 Oct 2000 09:24:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03AB2.36BEAF70" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03AB2.36BEAF70 Content-Type: text/plain; charset="iso-8859-1" Darren: You have issued some concerns about the IP-centric control plane for optical networks. Some of them are legitimate questions. However, you tried too hard to convince everybody to agree with you in a whole. It won't happen. We suggest you take some concrete approaches rather than by questioning the whole thing. 1) IETF framework is kind of requirement that you are talking about. It is not perfect and is working in progress. We prefer you putting some addition requirement and enhancement into the framework. 2) IP centric control plane could borrow some Telecom ideas, like something positive from you and BT, etc. In reality, IP centric control plane is a very good choice, maybe not the best one. Sorrento Networks James Fu -----Original Message----- From: darren.freeland@bt.com [mailto:darren.freeland@bt.com] Sent: Friday, October 20, 2000 3:40 AM To: kireeti@juniper.net Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; neil.2.harrison@bt.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Hi Kireeti, >> However, the point of GMPLS is NOT a peer model. It is an IP-based >> control plane, leveraging existing work, and the flexibility of a >> peer or overlay or hybrid model. Perhaps you missed my point. I didn't say the point of GMPLS is a peer model (I have read the draft) - I questioned the assumption that IP-centric control protocols will be appropriate for an optical (or indeed any) control plane. As far as I can see (having read the IPO framework, the MPLambdaS, and the Generalised MPLS drafts I hasten to add), this assumption has been made without giving full consideration to the requirements of the particular networks the protocols will be applied to. My interest is the OTN, so that's what I've been focussing on. The IPO framework document starts out in the introduction by saying that "there is wide consensus in the industry that the optical control plane should be IP-centric". I would question this 'wide consensus'. There is a few (very basic) requirements set out in the introduction, but nothing that justifies thoroughly the choice of IP-centric control protocols for the OTN. The MPL(ambda)S document does the same - we're told in the intro that the optical control plane will be based on the MPLS TE control plane model. The only justification that is given for this is the reuse of existing protocols. Cool - why not reuse PNNI then? I'm not advocating one or the other yet - what I am saying is that the requirements of the OTN (or any other network in the case of GMPLS) should be fully considered in the first place. The choice (and extensions) of control plane protocols should then be made to fit these requirements. The other problem I have with the MPL(ambda)S philosophy is its clear bias towards the 'peer' option. Sure, the 'overlay' option is described, but it is not fully discussed - we are simply told that "to understand the drawbacks of this approach ... one need look no further than the experience with IP over ATM". This is a whole discussion in itself which Neil Harrison has touched on in his reply to you. ATM is not the OTN. This aside, my point is that the peer model is clearly advocated over the overlay model - but there is no mention to the effect the peer model would have on an operator who has a multi-client environment. There is also a clear reluctance on this list to recognise the problems the peer model may bring. I think a new draft is in order, but I get the feeling many won't like it. Regards, Darren. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical ------_=_NextPart_001_01C03AB2.36BEAF70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft = Minutes From Pittsburgh

Darren:
 
        You have = issued some concerns about the IP-centric control plane for optical = networks.  Some of them are legitimate questions. However, you = tried too hard to convince everybody to agree with you in a whole. It = won't happen.  We suggest you take some concrete approaches rather = than by questioning the whole thing.

1) IETF framework is kind of requirement that you are = talking about. It is not perfect and  is working in progress. We = prefer you putting some addition requirement and enhancement into the = framework.

2) IP centric control plane could borrow some Telecom = ideas, like something positive from you and BT, etc.

  In reality, IP centric control plane is a very = good choice, maybe not the best one.  

 

Sorrento Networks

James Fu


      
    

-----Original Message-----
From: darren.freeland@bt.com [mailto:darren.freeland@bt.com= ]
Sent: Friday, October 20, 2000 3:40 AM
To: kireeti@juniper.net
Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; = neil.2.harrison@bt.com
Subject: RE: [IP-Optical] RE: Optical link bundling. = Was Re: Draft
Minutes From Pittsburgh


Hi Kireeti,

>> However, the point of GMPLS is NOT a peer = model.  It is an IP-based
>> control plane, leveraging existing work, = and the flexibility of a
>> peer or overlay or hybrid model.

Perhaps you missed my point.  I didn't say the = point of GMPLS is a peer
model (I have read the draft) - I questioned the = assumption that IP-centric
control protocols will be appropriate for an optical = (or indeed any) control
plane.  As far as I can see (having read the = IPO framework, the MPLambdaS,
and the Generalised MPLS drafts I hasten to add), = this assumption has been
made without giving full consideration to the = requirements of the particular
networks the protocols will be applied to.  My = interest is the OTN, so
that's what I've been focussing on.

The IPO framework document starts out in the = introduction by saying that
"there is wide consensus in the industry that = the optical control plane
should be IP-centric".  I would question = this 'wide consensus'.  There is a
few (very basic) requirements set out in the = introduction, but nothing that
justifies thoroughly the choice of IP-centric = control protocols for the OTN.

The MPL(ambda)S document does the same - we're told = in the intro that the
optical control plane will be based on the MPLS TE = control plane model.  The
only justification that is given for this is the = reuse of existing
protocols.  Cool - why not reuse PNNI = then?  I'm not advocating one or the
other yet - what I am saying is that the = requirements of the OTN (or any
other network in the case of GMPLS) should be fully = considered in the first
place.  The choice (and extensions) of control = plane protocols should then
be made to fit these requirements.

The other problem I have with the MPL(ambda)S = philosophy is its clear bias
towards the 'peer' option.  Sure, the 'overlay' = option is described, but it
is not fully discussed - we are simply told that = "to understand the
drawbacks of this approach ... one need look no = further than the experience
with IP over ATM".  This is a whole = discussion in itself which Neil Harrison
has touched on in his reply to you.  ATM is not = the OTN.  This aside, my
point is that the peer model is clearly advocated = over the overlay model -
but there is no mention to the effect the peer model = would have on an
operator who has a multi-client environment.  = There is also a clear
reluctance on this list to recognise the problems = the peer model may bring.

I think a new draft is in order, but I get the = feeling many won't like it.

Regards,
Darren.

_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical=

------_=_NextPart_001_01C03AB2.36BEAF70-- From owner-mpls@UU.NET Fri Oct 20 12:49:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12664 for ; Fri, 20 Oct 2000 12:49:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltb19493; Fri, 20 Oct 2000 16:48:06 GMT Received: by mail-control.mail.uu.net id QQjltb09863 for mpls-outgoing; Fri, 20 Oct 2000 16:47:46 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjltb09850 for ; Fri, 20 Oct 2000 16:47:36 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjltb14573 for ; Fri, 20 Oct 2000 16:46:24 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjltb05252 for ; Fri, 20 Oct 2000 16:46:23 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24615; Fri, 20 Oct 2000 12:46:20 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26439; Fri, 20 Oct 2000 12:46:22 -0400 (EDT) Message-ID: <39F076DD.EB98DE3C@marconi.com> Date: Fri, 20 Oct 2000 12:46:21 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Wushao Wen CC: mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Wushao Wen wrote: > > Sure you are right. What we started with is without the implementation > of MPLS, what can RSVP do. This means that we can not use RSVP-TE. So > for RSVP itself, it is an resource reservation protool without > affecting the basic routing mechanism. Ah. OK. I must've missed the beginning of the thread. The only real concern with using straight RSVP is that it may be overkill, depending on your application. RSVP was designed to accomodate the presence of non-RSVP routers along the path, and many-to-many multicast sessions. If thse are not issues for you, you may prefer to use something lighter-weight for making reservations. > The use of RSVP-TE must come together with MPLS, otherwise, RSVP-TE > itself can not implement explicit routing. If we sent IP packet > directly to the router, even though RSVP-TE was previous used, it will > not follow the explicit route. > Correct me if I miss anything. Sounds about right. Note, however, that nothing in the RSVP-TE draft explicitly forbids the use of an explicit route object with non-LSP sessions. If someone would implement such support, the router would have to use the explicit route when forwarding packets that match the packet's 5-tuple (dest addr, src addr, protocol, dest port, src port). This could be done on some routers by adding policy-based routing information (possibly in conjunction with /32 routing table entries) in the router's forwarder. After all, a label is really just a mechanism to eliminate the need to re-classify data packets at every hop. But this is now well beyond the scope of MPLS. -- David From owner-mpls@UU.NET Fri Oct 20 12:56:53 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13664 for ; Fri, 20 Oct 2000 12:56:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltb05014; Fri, 20 Oct 2000 16:56:19 GMT Received: by mail-control.mail.uu.net id QQjltb10622 for mpls-outgoing; Fri, 20 Oct 2000 16:55:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjltb10613 for ; Fri, 20 Oct 2000 16:55:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjltb22099 for ; Fri, 20 Oct 2000 16:55:23 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjltb18087 for ; Fri, 20 Oct 2000 16:55:23 GMT Received: from tellium.com ([192.168.24.103]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9KGicX23841; Fri, 20 Oct 2000 12:44:38 -0400 (EDT) Message-ID: <39F0783D.DC2FF264@tellium.com> Date: Fri, 20 Oct 2000 12:52:13 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: darren.freeland@bt.com CC: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh References: <71DA16F18D32D2119A1D0000F8FE9A940920C722@mbtlipnt01.btlabs.bt.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: darren.freeland@bt.com wrote: > Hi Kireeti, > > >> However, the point of GMPLS is NOT a peer model. It is an IP-based > >> control plane, leveraging existing work, and the flexibility of a > >> peer or overlay or hybrid model. > > Perhaps you missed my point. I didn't say the point of GMPLS is a peer > model (I have read the draft) - I questioned the assumption that IP-centric > control protocols will be appropriate for an optical (or indeed any) control > plane. As far as I can see (having read the IPO framework, the MPLambdaS, > and the Generalised MPLS drafts I hasten to add), this assumption has been > made without giving full consideration to the requirements of the particular > networks the protocols will be applied to. My interest is the OTN, so > that's what I've been focussing on. Our practical experience so far (w.r.t product development) has been that IP centric control protocols are both appropriate and also practical for controlling dynamic provisioning. We are able to reuse available protocol implementations (of course, some degree of customization is needed). We have not found it suitable (yet) to utilize an IP-centric protocol for restoration under our tight time constraints. Note that this is a control plane inside a single vendor network. Models for multi-vendor interoperability using IP-centric protocols are still evolving, IMO. > > > The IPO framework document starts out in the introduction by saying that > "there is wide consensus in the industry that the optical control plane > should be IP-centric". I would question this 'wide consensus'. There is a > few (very basic) requirements set out in the introduction, but nothing that > justifies thoroughly the choice of IP-centric control protocols for the OTN. The statement on consensus is true to the degree that optical network equipment vendors would like to use IP-centric protocols for control within their network. As for requirements, there are three aspects. First, the requirements for control within a network: these are met by the IP-centric control plane in the view of many vendors (other than restoration for which IP-centric control may not be a choice for all vendors). Second, the requirements for controlling interoperability: the premise is that an IP-centric control plane will be suitable for this also. The debate is on the type of control and this centers on the peer and overlay. Finally, the service requirements: these are the least articulated requirements. There is some effort in the OIF to involve service providers in formulating these requirements, and these will be reflected in the IETF also. > > > The MPL(ambda)S document does the same - we're told in the intro that the > optical control plane will be based on the MPLS TE control plane model. The > only justification that is given for this is the reuse of existing > protocols. Cool - why not reuse PNNI then? I'm not advocating one or the > other yet - what I am saying is that the requirements of the OTN (or any > other network in the case of GMPLS) should be fully considered in the first > place. The choice (and extensions) of control plane protocols should then > be made to fit these requirements. The rationale for choosing an IP-centric control plane (as opposed to say, PNNI) is the focus on IP clients. I don't think there is any secret here. There is a hope that an IP-centric control plane inside an optical network would make it possible to achieve flexible interaction with IP client networks (leaving aside the peer and overlay issues for the moment). > > > The other problem I have with the MPL(ambda)S philosophy is its clear bias > towards the 'peer' option. Sure, the 'overlay' option is described, but it > is not fully discussed - we are simply told that "to understand the > drawbacks of this approach ... one need look no further than the experience > with IP over ATM". This is a whole discussion in itself which Neil Harrison > has touched on in his reply to you. ATM is not the OTN. This aside, my > point is that the peer model is clearly advocated over the overlay model - > but there is no mention to the effect the peer model would have on an > operator who has a multi-client environment. There is also a clear > reluctance on this list to recognise the problems the peer model may bring. I am personally not a fan of peer model, but I accept that there are many who believe in it strongly. I agree with you that no (optical) service provider (to my knowledge) has made a statement about deploying a service to IP clients using the peer model. Neither have I seen any statement from any network operator as to their intention on using the peer model for an IP-optical intranet. It has also not been quantified (in any scientific manner) what the traffic engineering advantages of the peer model are. But this is irrelevant now, since the signaling developments in GMPLS and OIF are towards using a common framework for peer and overlay models, with a path for evolution from overlay to peer. The IPO framework document has tended to be very balanced in its view with regard to the interoperability models and it describes the evolution approach. In particular, it describes how an IP-centric control plane in the optical network eases IP-optical interaction even for establishing overlays (under the routing models section). Regards. -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Fri Oct 20 13:01:41 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14247 for ; Fri, 20 Oct 2000 13:01:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltc14990; Fri, 20 Oct 2000 17:01:19 GMT Received: by mail-control.mail.uu.net id QQjltc14128 for mpls-outgoing; Fri, 20 Oct 2000 17:00:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjltc14076 for ; Fri, 20 Oct 2000 17:00:42 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjltb13120 for ; Fri, 20 Oct 2000 16:59:18 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjltb23806 for ; Fri, 20 Oct 2000 16:59:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA10399 for mpls@uu.net; Fri, 20 Oct 2000 12:59:17 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjltb11187 for ; Fri, 20 Oct 2000 16:58:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjltb14274 for ; Fri, 20 Oct 2000 16:58:04 GMT Received: from crufty.research.bell-labs.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQjltb21939 for ; Fri, 20 Oct 2000 16:58:03 GMT Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Fri Oct 20 12:56:17 EDT 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by scummy; Fri Oct 20 12:56:16 EDT 2000 Received: from research.bell-labs.com (ex-vpn76.pa.bell-labs.com [135.250.1.76]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAV40128 (AUTH gja); Fri, 20 Oct 2000 09:56:15 -0700 (PDT) Message-ID: <39F07958.C4DB347@research.bell-labs.com> Date: Fri, 20 Oct 2000 09:56:56 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh References: <71DA16F18D32D2119A1D0000F8FE9A940920C722@mbtlipnt01.btlabs.bt.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit darren.freeland@bt.com wrote: [..] > ATM is not the OTN. When MPLS first burst onto the ATM scene, there was much talk of being able to run ATM switches in a ships-in-the-night mode, partitioning the VCI/VPI space into blocks for allocation by PNNI and LDP(et al). The analogy with IP/ATM is pertinent in so far as we all thought ATM networks would be primarly built for other 'telco' services (migrating across from wherever...) and that IP would be just another client. For some ATM installations this was no doubt quite true, and the 'overlay' model a compelling solution. Yet for those people buying ATM gear primarily to haul IP traffic around their region(s), it seemed equally likely that optimizing the ATM control plane for a single 'client' (IP) was acceptable. I'm not sure it is constructive to insist there is an absolute either/or case to be made for IP/optics. Certainly for work coming out of the IETF environment it is hardly surprising the focus is on IP as the client layer. But this isn't the same as saying an OTN must be built as the IETF wants it. Ships-in-the-night is still feasible on boxes that switch lamdas, timeslots, ... cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Fri Oct 20 13:16:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15929 for ; Fri, 20 Oct 2000 13:16:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltd17577; Fri, 20 Oct 2000 17:16:18 GMT Received: by mail-control.mail.uu.net id QQjltd24638 for mpls-outgoing; Fri, 20 Oct 2000 17:15:46 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjltd24632 for ; Fri, 20 Oct 2000 17:15:44 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjltc11206 for ; Fri, 20 Oct 2000 17:14:44 GMT Received: from csa.iisc.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjltc24777 for ; Fri, 20 Oct 2000 17:14:41 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id WAA28481; Fri, 20 Oct 2000 22:42:52 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id WAA08568; Fri, 20 Oct 2000 22:44:35 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Fri, 20 Oct 2000 22:44:34 +0530 (IST) From: Gaitonde Anandprasanna To: seenu@samsung.co.kr cc: mpls@UU.NET, mohanvak@future.futsoft.com Subject: Re: (Reply) Hi seenu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I wanted to know whether the messages like Label withdraw/ Label release are as spcified by LDP or are the present in RSVP-TE also. The same case for No_Lbl_Resources notification message. Thanks in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_| Hi mohan, > > Sorry for a late reply. > > Take the case where an LSR has sent a No_Lbl_Resources notification to the peers that have requested for a label. > When Labels are available the LSR sends first a Lbl_Resources_Available notification and then sends a Label_Mapping msg. > See in this case, instead of sending two messages seperately, y can't u include the Status code ( Lbl_Resources_Available) in the > label mapping msg itself, which takes less time compared to the earlier one (since processing of a msg takes more time than a TLV). > Anyway if an LSR is not ready to handle that tlv it can always ignore it (draft-notifocation msg) > > Take one more case : An upstream peer has detected a loop, so first it will send a loop_detected_noti and then sends a Lbl_release msg. > In this case also, u can include Status_tlv in the Lbl_Release msg > > So depending on the situation it will reduces the computation. > > Hope it will help u. > > regards > Seenu > > > In the ldp-11 draft ,it's given that the status TLV > > can be included in ldp messages which need not be > > notif. > > I feel there is a situation like the LSP got preempted, > > which is a defined new status code, in such case it's helpful. > > > But do u think it's helpful in adding the status TLV > > which ceratinly increases the processing at each node. > From owner-mpls@UU.NET Fri Oct 20 13:26:59 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17103 for ; Fri, 20 Oct 2000 13:26:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltd12407; Fri, 20 Oct 2000 17:26:43 GMT Received: by mail-control.mail.uu.net id QQjltd25915 for mpls-outgoing; Fri, 20 Oct 2000 17:26:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjltd25892 for ; Fri, 20 Oct 2000 17:26:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjltd23173 for ; Fri, 20 Oct 2000 17:25:10 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjltd01077 for ; Fri, 20 Oct 2000 17:25:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA14901 for mpls@uu.net; Fri, 20 Oct 2000 13:25:09 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjltd25725 for ; Fri, 20 Oct 2000 17:24:43 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjltd03384 for ; Fri, 20 Oct 2000 17:24:10 GMT Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjltd08639 for ; Fri, 20 Oct 2000 17:24:10 GMT Received: from dhcp-171-69-55-24.cisco.com (dhcp-171-69-55-24.cisco.com [171.69.55.24]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA04262; Fri, 20 Oct 2000 10:24:06 -0700 (PDT) Date: Fri, 20 Oct 2000 10:18:04 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <15429.001020@cisco.com> To: neil.2.harrison@bt.com, darren.freeland@bt.com CC: mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, Darren: I think at this point, the discussion is indeed at a stage where no practical results are seen. So, maybe it would be more constructive if you document your assumptions, understanding of the current situation, required functionality and concerns you have. This would be very valuable, I guess, and would let people express their opinion. Such a document could serve as a basis for [hopefully] more productive discussion. If e-mail does not work out, I think we can always schedule a BOF-like meeting (not necessarily at an IETF one). Face-to-face always works better. Regards, Alex. > I don't think the debate is *over*, indeed I don't think it has even > begun properly.....but it needs other operator views, and not simply those > discussing it so far who clearly hold stong convictions. I have had several > private mails on this topic supporting the points I have made and I wish > these people would state their positions openly.......however, one cannot > force this, but without it I agree that continued debate on the list is > somewhat futile (and not really what it should be used for). > neil From owner-mpls@UU.NET Fri Oct 20 13:42:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18867 for ; Fri, 20 Oct 2000 13:42:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlte04234; Fri, 20 Oct 2000 17:41:21 GMT Received: by mail-control.mail.uu.net id QQjlte27348 for mpls-outgoing; Fri, 20 Oct 2000 17:40:46 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlte27337 for ; Fri, 20 Oct 2000 17:40:36 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlte09048 for ; Fri, 20 Oct 2000 17:39:55 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlte28569 for ; Fri, 20 Oct 2000 17:39:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA17390 for mpls@uu.net; Fri, 20 Oct 2000 13:39:53 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlte27240 for ; Fri, 20 Oct 2000 17:39:22 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlte06654 for ; Fri, 20 Oct 2000 17:38:54 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjlte26535 for ; Fri, 20 Oct 2000 17:38:54 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA14102; Fri, 20 Oct 2000 10:38:19 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Oct 2000 10:43:33 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A16@BBY1EXM01> From: Shahram Davari To: "'David Charlap'" , Wushao Wen Cc: mpls@UU.NET Subject: RE: Traffic engineering and RSVP Date: Fri, 20 Oct 2000 10:43:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi David, > > Note, however, that nothing in the RSVP-TE draft explicitly > forbids the > use of an explicit route object with non-LSP sessions. Label and Label-objects are mandatory in RSVP-TE. This means you have to use the RSVP-TE for MPLS purpose. Regards, -Shahram From owner-mpls@UU.NET Fri Oct 20 13:44:53 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19163 for ; Fri, 20 Oct 2000 13:44:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlte07243; Fri, 20 Oct 2000 17:44:04 GMT Received: by mail-control.mail.uu.net id QQjlte27737 for mpls-outgoing; Fri, 20 Oct 2000 17:43:29 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlte27723 for ; Fri, 20 Oct 2000 17:43:22 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlte19680 for ; Fri, 20 Oct 2000 17:42:17 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlte26981 for ; Fri, 20 Oct 2000 17:42:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA17743 for mpls@uu.net; Fri, 20 Oct 2000 13:42:15 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlte27512 for ; Fri, 20 Oct 2000 17:41:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlte09154 for ; Fri, 20 Oct 2000 17:40:16 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjlte29370 for ; Fri, 20 Oct 2000 17:40:16 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA14209; Fri, 20 Oct 2000 10:39:43 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Oct 2000 10:44:57 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9A17@BBY1EXM01> From: Shahram Davari To: "'David Charlap'" , Wushao Wen Cc: mpls@UU.NET Subject: RE: Traffic engineering and RSVP Date: Fri, 20 Oct 2000 10:44:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi David, > > Note, however, that nothing in the RSVP-TE draft explicitly > forbids the > use of an explicit route object with non-LSP sessions. Label-request and Label objects are mandatory in RSVP-TE. This means you have to use the RSVP-TE for MPLS purpose. Regards, -Shahram From owner-mpls@UU.NET Fri Oct 20 13:57:23 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20612 for ; Fri, 20 Oct 2000 13:57:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltf04209; Fri, 20 Oct 2000 17:56:42 GMT Received: by mail-control.mail.uu.net id QQjltf29058 for mpls-outgoing; Fri, 20 Oct 2000 17:56:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjltf29050 for ; Fri, 20 Oct 2000 17:56:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjltf11452 for ; Fri, 20 Oct 2000 17:55:24 GMT From: darren.freeland@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjltf27221 for ; Fri, 20 Oct 2000 17:55:23 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Fri, 20 Oct 2000 17:56:19 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Fri, 20 Oct 2000 17:56:21 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C733@mbtlipnt01.btlabs.bt.co.uk> To: kireeti@juniper.net Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET, neil.2.harrison@bt.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Fri, 20 Oct 2000 17:55:05 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, > Could you clarify what you mean by "IP-centric control protocols": > a) IP control protocols (such as OSPF, RSVP, CR-LDP), or > b) control protocols aimed at serving an IP infrastructure? I mean (a) - questioning the assumption that these will be used for the OTN control plane. I think it makes sense to fully consider OTN requirements before we decide upon which protocols will best meet these requirements. I don't believe that operators requirements have been discussed enough here to justify the assumption of (a) for the OTN. Note that I would also be questioning this if people were working on extensions to any other particular set of control protocols, without working to an agreed set of requirements! > Why I ask the above question is that there is a UNI based on IP > control protocols (draft-gray-mpls-rsvp-oif-uni-ext-00.txt), which > caters to non-IP uses of the OTN, and whose underlying model is the > overlay model. This draft is in response to the *OIF*'s requirements > for an optical UNI. I was not aware of this ID. Thanks. I will have a look at it when I'm back in the office Monday morning. > However, if your objection is to the use of IP control protocols, > that's a different issue. Note that the IETF is unlikely to be the > right venue for discussing say PNNI as a control plane for the OTN. I am not objecting to the use of any particular control protocols ... yet. My point is that we have to have more discussion on operators requirements before we can decide. > For what it's worth, the MPLS control plane is IP-based, but serves > non-IP uses quite well. There is an upcoming foo-over-MPLS BOF that > illustrates this point. I read the draft - looking forward to the BOF :) > That hardly matters. If it makes sense to service providers, the > vendors will come around :-) Thanks for the encouragement. I think I've made my point for now. I would like to hear (on the list) opinions from other vendors though. Otherwise, I'll keep quite(ish) until I have an ID to contribute :) > One thing though is to better articulate what is broken with the > current approach. If it's not the "peer vs. overlay" model that's > the issue, then like you say, I've missed your point, and would > like to understand what the real problem is. My first concern is as discussed above. My second is the validity of the peer model for an operator such as ourselves with multi-client requirements. I have noted the proposal highlighted by John Drake that we could have an overlay based model at the UNI, and a peer based one at the NNI. This is something I have to consider in more detail. I am still not convinced on common addressing across client and server layers ('server layer trails = client layer links'). If someone can convince me otherwise, I'm willing to listen. Have a good weekend. Darren. From owner-mpls@UU.NET Fri Oct 20 14:06:09 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21585 for ; Fri, 20 Oct 2000 14:06:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltg15741; Fri, 20 Oct 2000 18:05:14 GMT Received: by mail-control.mail.uu.net id QQjltg10078 for mpls-outgoing; Fri, 20 Oct 2000 18:04:53 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjltg09421 for ; Fri, 20 Oct 2000 18:04:41 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjltg08214 for ; Fri, 20 Oct 2000 18:03:57 GMT From: darren.freeland@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjltg17378 for ; Fri, 20 Oct 2000 18:03:57 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by gollum (local) with ESMTP; Fri, 20 Oct 2000 18:07:40 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <4W3A0S3B>; Fri, 20 Oct 2000 18:05:40 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C734@mbtlipnt01.btlabs.bt.co.uk> To: jfu@sorrentonet.com, kireeti@juniper.net Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET, neil.2.harrison@bt.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Fri, 20 Oct 2000 18:04:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03AB7.DF7B7490" Sender: owner-mpls@UU.NET Precedence: bulk ------_=_NextPart_001_01C03AB7.DF7B7490 Content-type: text/plain; charset="iso-8859-1" Hi James, > However, you tried too hard to convince everybody to agree > with you in a whole. It won't happen. I realise this :) > We suggest you take some concrete approaches rather than by questioning the whole thing. > 1) IETF framework is kind of requirement that you are talking about. It is not perfect and is working in progress. We prefer you putting some addition requirement and enhancement into the framework. 2) IP centric control plane could borrow some Telecom ideas, like something positive from you and BT, etc. Indeed. Watch this space. Enough from me for the time being though, it's now 6pm Friday night over here :) Regards, Darren. -----Original Message----- From: darren.freeland@bt.com [ mailto:darren.freeland@bt.com ] Sent: Friday, October 20, 2000 3:40 AM To: kireeti@juniper.net Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; neil.2.harrison@bt.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Hi Kireeti, >> However, the point of GMPLS is NOT a peer model. It is an IP-based >> control plane, leveraging existing work, and the flexibility of a >> peer or overlay or hybrid model. Perhaps you missed my point. I didn't say the point of GMPLS is a peer model (I have read the draft) - I questioned the assumption that IP-centric control protocols will be appropriate for an optical (or indeed any) control plane. As far as I can see (having read the IPO framework, the MPLambdaS, and the Generalised MPLS drafts I hasten to add), this assumption has been made without giving full consideration to the requirements of the particular networks the protocols will be applied to. My interest is the OTN, so that's what I've been focussing on. The IPO framework document starts out in the introduction by saying that "there is wide consensus in the industry that the optical control plane should be IP-centric". I would question this 'wide consensus'. There is a few (very basic) requirements set out in the introduction, but nothing that justifies thoroughly the choice of IP-centric control protocols for the OTN. The MPL(ambda)S document does the same - we're told in the intro that the optical control plane will be based on the MPLS TE control plane model. The only justification that is given for this is the reuse of existing protocols. Cool - why not reuse PNNI then? I'm not advocating one or the other yet - what I am saying is that the requirements of the OTN (or any other network in the case of GMPLS) should be fully considered in the first place. The choice (and extensions) of control plane protocols should then be made to fit these requirements. The other problem I have with the MPL(ambda)S philosophy is its clear bias towards the 'peer' option. Sure, the 'overlay' option is described, but it is not fully discussed - we are simply told that "to understand the drawbacks of this approach ... one need look no further than the experience with IP over ATM". This is a whole discussion in itself which Neil Harrison has touched on in his reply to you. ATM is not the OTN. This aside, my point is that the peer model is clearly advocated over the overlay model - but there is no mention to the effect the peer model would have on an operator who has a multi-client environment. There is also a clear reluctance on this list to recognise the problems the peer model may bring. I think a new draft is in order, but I get the feeling many won't like it. Regards, Darren. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical ------_=_NextPart_001_01C03AB7.DF7B7490 Content-type: text/html; charset="iso-8859-1" RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh
Hi James,
 
> However, you tried too hard to convince everybody to agree 
> with you in a whole. It won't happen. 
 
I realise this :)
 
> We suggest you take some concrete approaches rather than by questioning the whole thing. 
> 1) IETF framework is kind of requirement that you are talking about. It is not perfect and  is working in progress. We prefer you putting some addition requirement and enhancement into the framework. 
 2) IP centric control plane could borrow some Telecom ideas, like something positive from you and BT, etc.  
 
Indeed.  Watch this space.  Enough from me for the time being though, it's now 6pm Friday night over here :)
 
Regards,
 
Darren.       
    

-----Original Message-----
From: darren.freeland@bt.com [mailto:darren.freeland@bt.com]
Sent: Friday, October 20, 2000 3:40 AM
To: kireeti@juniper.net
Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; neil.2.harrison@bt.com
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft
Minutes From Pittsburgh


Hi Kireeti,

>> However, the point of GMPLS is NOT a peer model.  It is an IP-based
>> control plane, leveraging existing work, and the flexibility of a
>> peer or overlay or hybrid model.

Perhaps you missed my point.  I didn't say the point of GMPLS is a peer
model (I have read the draft) - I questioned the assumption that IP-centric
control protocols will be appropriate for an optical (or indeed any) control
plane.  As far as I can see (having read the IPO framework, the MPLambdaS,
and the Generalised MPLS drafts I hasten to add), this assumption has been
made without giving full consideration to the requirements of the particular
networks the protocols will be applied to.  My interest is the OTN, so
that's what I've been focussing on.

The IPO framework document starts out in the introduction by saying that
"there is wide consensus in the industry that the optical control plane
should be IP-centric".  I would question this 'wide consensus'.  There is a
few (very basic) requirements set out in the introduction, but nothing that
justifies thoroughly the choice of IP-centric control protocols for the OTN.

The MPL(ambda)S document does the same - we're told in the intro that the
optical control plane will be based on the MPLS TE control plane model.  The
only justification that is given for this is the reuse of existing
protocols.  Cool - why not reuse PNNI then?  I'm not advocating one or the
other yet - what I am saying is that the requirements of the OTN (or any
other network in the case of GMPLS) should be fully considered in the first
place.  The choice (and extensions) of control plane protocols should then
be made to fit these requirements.

The other problem I have with the MPL(ambda)S philosophy is its clear bias
towards the 'peer' option.  Sure, the 'overlay' option is described, but it
is not fully discussed - we are simply told that "to understand the
drawbacks of this approach ... one need look no further than the experience
with IP over ATM".  This is a whole discussion in itself which Neil Harrison
has touched on in his reply to you.  ATM is not the OTN.  This aside, my
point is that the peer model is clearly advocated over the overlay model -
but there is no mention to the effect the peer model would have on an
operator who has a multi-client environment.  There is also a clear
reluctance on this list to recognise the problems the peer model may bring.

I think a new draft is in order, but I get the feeling many won't like it.

Regards,
Darren.

_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical

------_=_NextPart_001_01C03AB7.DF7B7490-- From owner-mpls@UU.NET Fri Oct 20 14:27:30 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23987 for ; Fri, 20 Oct 2000 14:27:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlth06790; Fri, 20 Oct 2000 18:26:47 GMT Received: by mail-control.mail.uu.net id QQjlth13959 for mpls-outgoing; Fri, 20 Oct 2000 18:26:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlth13909 for ; Fri, 20 Oct 2000 18:26:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlth13892 for ; Fri, 20 Oct 2000 18:25:35 GMT Received: from zrtps06s.us.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQjlth21062 for ; Fri, 20 Oct 2000 18:25:35 GMT Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Fri, 20 Oct 2000 14:21:22 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRD70M>; Fri, 20 Oct 2000 14:21:18 -0400 Message-ID: <402CC1A33A3FD311A5A00000F8082A5F0266C849@zcrkp001.ca.nortel.com> From: "Osama Aboul-Magd" To: darren.freeland@bt.com, kireeti@juniper.net Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET, neil.2.harrison@bt.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Fri, 20 Oct 2000 14:21:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03AC2.84C826F0" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03AC2.84C826F0 Content-Type: text/plain; charset="iso-8859-1" You may also consider the draft on LDP extensions for optical UNI Why I ask the above question is that there is a UNI based on IP > control protocols (draft-gray-mpls-rsvp-oif-uni-ext-00.txt), which > caters to non-IP uses of the OTN, and whose underlying model is the > overlay model. This draft is in response to the *OIF*'s requirements > for an optical UNI. I was not aware of this ID. Thanks. I will have a look at it when I'm back in the office Monday morning. ------_=_NextPart_001_01C03AC2.84C826F0 Content-Type: text/html; charset="iso-8859-1" RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh

You may also consider the draft on LDP extensions for optical UNI <draft-mpls-aboulmagd-ldp-opical-uni-00.txt.

Regards;

Osama Aboul-Magd
ASON Standards and Architecture
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com


> Why I ask the above question is that there is a UNI based on IP
> control protocols (draft-gray-mpls-rsvp-oif-uni-ext-00.txt), which
> caters to non-IP uses of the OTN, and whose underlying model is the
> overlay model.  This draft is in response to the *OIF*'s requirements
> for an optical UNI.

I was not aware of this ID.  Thanks.  I will have a look at it when I'm back
in the office Monday morning.


------_=_NextPart_001_01C03AC2.84C826F0-- From owner-mpls@UU.NET Fri Oct 20 14:38:36 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25308 for ; Fri, 20 Oct 2000 14:38:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlti25078; Fri, 20 Oct 2000 18:37:46 GMT Received: by mail-control.mail.uu.net id QQjlti15274 for mpls-outgoing; Fri, 20 Oct 2000 18:37:13 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlti15267 for ; Fri, 20 Oct 2000 18:37:05 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlti21098 for ; Fri, 20 Oct 2000 18:36:59 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlti23243 for ; Fri, 20 Oct 2000 18:36:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA26893 for mpls@uu.net; Fri, 20 Oct 2000 14:36:58 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlti15230 for ; Fri, 20 Oct 2000 18:36:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlti12798 for ; Fri, 20 Oct 2000 18:34:53 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bounty.cisco.com [161.44.3.204]) id QQjlti19407 for ; Fri, 20 Oct 2000 18:34:53 GMT Received: from cisco.com (rtp7-dhcp-57-119.cisco.com [161.44.57.119]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA01685; Fri, 20 Oct 2000 14:34:38 -0400 (EDT) Message-ID: <39F0908F.B356DF9B@cisco.com> Date: Fri, 20 Oct 2000 14:36:00 -0400 From: Sanjeev Rampal X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Grenville Armitage CC: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh References: <71DA16F18D32D2119A1D0000F8FE9A940920C722@mbtlipnt01.btlabs.bt.co.uk> <39F07958.C4DB347@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Even if we only care about IP clients, other issues (stemming from the fact that ATM switches can peer into per-packet (cell) headers, do merge operations etc) could impact the peer versus overlay issue perhaps differently in the ATM than in the optical case ... Grenville Armitage wrote: > darren.freeland@bt.com wrote: > [..] > > ATM is not the OTN. > > When MPLS first burst onto the ATM scene, there was much talk of being > able to run ATM switches in a ships-in-the-night mode, partitioning > the VCI/VPI space into blocks for allocation by PNNI and LDP(et al). > > The analogy with IP/ATM is pertinent in so far as we all thought ATM > networks would be primarly built for other 'telco' services (migrating > across from wherever...) and that IP would be just another client. > For some ATM installations this was no doubt quite true, and the > 'overlay' model a compelling solution. Yet for those people buying > ATM gear primarily to haul IP traffic around their region(s), it > seemed equally likely that optimizing the ATM control plane for a > single 'client' (IP) was acceptable. > > I'm not sure it is constructive to insist there is an absolute > either/or case to be made for IP/optics. Certainly for work coming > out of the IETF environment it is hardly surprising the focus is > on IP as the client layer. But this isn't the same as saying an > OTN must be built as the IETF wants it. Ships-in-the-night is > still feasible on boxes that switch lamdas, timeslots, ... > > cheers, > gja > ________________________________________________________________________ > Grenville Armitage http://members.home.net/garmitage/ > Bell Labs Research Silicon Valley From owner-mpls@UU.NET Fri Oct 20 14:41:49 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25683 for ; Fri, 20 Oct 2000 14:41:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlti15833; Fri, 20 Oct 2000 18:41:06 GMT Received: by mail-control.mail.uu.net id QQjlti15523 for mpls-outgoing; Fri, 20 Oct 2000 18:40:34 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlti15517 for ; Fri, 20 Oct 2000 18:40:33 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlti25360 for ; Fri, 20 Oct 2000 18:39:01 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlti26410 for ; Fri, 20 Oct 2000 18:39:00 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA27240 for mpls@uu.net; Fri, 20 Oct 2000 14:39:00 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlti15365 for ; Fri, 20 Oct 2000 18:38:44 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlti23608 for ; Fri, 20 Oct 2000 18:38:16 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjlti11323 for ; Fri, 20 Oct 2000 18:38:15 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA00736 for ; Fri, 20 Oct 2000 11:38:13 -0700 (PDT) Message-ID: <39F09113.3C9FD5EF@pluris.com> Date: Fri, 20 Oct 2000 11:38:11 -0700 From: Bora Akyol X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET Subject: Contention Resolution in Generalized MPLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit draft-ashwood-**-00.txt How do we detect a set of bidirectional LSPs causing contention on an LSR? Is there an assumption that two LSRs can only have one set of LSPs that link them? Or is there something akin to a session ID that is used? Bora From owner-mpls@UU.NET Fri Oct 20 14:53:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26958 for ; Fri, 20 Oct 2000 14:53:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltj04601; Fri, 20 Oct 2000 18:53:09 GMT Received: by mail-control.mail.uu.net id QQjltj16959 for mpls-outgoing; Fri, 20 Oct 2000 18:52:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjltj16928 for ; Fri, 20 Oct 2000 18:52:34 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjltj24987 for ; Fri, 20 Oct 2000 18:52:00 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjltj24697 for ; Fri, 20 Oct 2000 18:51:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA29683 for mpls@uu.net; Fri, 20 Oct 2000 14:51:58 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjltj16814 for ; Fri, 20 Oct 2000 18:51:34 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjltj20697 for ; Fri, 20 Oct 2000 18:50:06 GMT Received: from crufty.research.bell-labs.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: crufty.research.bell-labs.com [204.178.16.49]) id QQjltj13629 for ; Fri, 20 Oct 2000 18:50:06 GMT Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Fri Oct 20 14:48:32 EDT 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Fri Oct 20 14:48:31 EDT 2000 Received: from research.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAV40304 (AUTH gja); Fri, 20 Oct 2000 11:48:29 -0700 (PDT) Message-ID: <39F09495.C3553AB8@research.bell-labs.com> Date: Fri, 20 Oct 2000 11:53:09 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Sanjeev Rampal CC: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh References: <71DA16F18D32D2119A1D0000F8FE9A940920C722@mbtlipnt01.btlabs.bt.co.uk> <39F07958.C4DB347@research.bell-labs.com> <39F0908F.B356DF9B@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit aside from the usual caveats of taking analogies too far... Sanjeev Rampal wrote: > > Even if we only care about IP clients, other issues (stemming from > the fact that ATM switches can peer into per-packet (cell) > headers, _ATM_ switches do not look inside packet headers (regardless of what ATM-packet hybrids you might have seen), and packets are not cells. Looking inside cell headers? Well, that's the point isn't it... > do merge operations etc) In the early days of MPLS, ATM switches couldn't all be relied upon to support VC merge either. The analogy to optical switches (despite the loud stretching sounds) is somewhat germane. cheers, gja From owner-mpls@UU.NET Fri Oct 20 15:35:35 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04646 for ; Fri, 20 Oct 2000 15:35:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltm07077; Fri, 20 Oct 2000 19:34:59 GMT Received: by mail-control.mail.uu.net id QQjltm02670 for mpls-outgoing; Fri, 20 Oct 2000 19:34:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjltm02638 for ; Fri, 20 Oct 2000 19:34:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjltm13483 for ; Fri, 20 Oct 2000 19:33:40 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjltm05110 for ; Fri, 20 Oct 2000 19:33:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA05732 for mpls@uu.net; Fri, 20 Oct 2000 15:33:39 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjltm02560 for ; Fri, 20 Oct 2000 19:33:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjltm11186 for ; Fri, 20 Oct 2000 19:32:52 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bounty.cisco.com [161.44.3.204]) id QQjltm29670 for ; Fri, 20 Oct 2000 19:32:52 GMT Received: from cisco.com (rtp7-dhcp-57-119.cisco.com [161.44.57.119]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA05175; Fri, 20 Oct 2000 15:32:38 -0400 (EDT) Message-ID: <39F09E28.532F6C28@cisco.com> Date: Fri, 20 Oct 2000 15:34:00 -0400 From: Sanjeev Rampal X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Grenville Armitage CC: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh References: <71DA16F18D32D2119A1D0000F8FE9A940920C722@mbtlipnt01.btlabs.bt.co.uk> <39F07958.C4DB347@research.bell-labs.com> <39F0908F.B356DF9B@cisco.com> <39F09495.C3553AB8@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Grenville Of course ATM switches do not look at *IP* packet headers from the payload and my note did not say that either ... This was just a way of saying that cells are in fact special "packets" and the VPI/VCI label allows the switch to have some representation of the headers of the packets (IP/ ethernet/ whatever) being transported in that ATM-LSP/ VCC. This enables merging operations etc. In contrast optical switches work at the granularity of optical channels/ lambdas/ STSs which are not "mergeable" Grenville Armitage wrote: > aside from the usual caveats of taking analogies too far... > > Sanjeev Rampal wrote: > > > > Even if we only care about IP clients, other issues (stemming from > > the fact that ATM switches can peer into per-packet (cell) > > headers, > > _ATM_ switches do not look inside packet headers (regardless > of what ATM-packet hybrids you might have seen), and packets are > not cells. Looking inside cell headers? Well, that's the point > isn't it... > > > do merge operations etc) > > In the early days of MPLS, ATM switches couldn't all be relied > upon to support VC merge either. The analogy to optical switches > (despite the loud stretching sounds) is somewhat germane. > > cheers, > gja From owner-mpls@UU.NET Fri Oct 20 17:08:30 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29873 for ; Fri, 20 Oct 2000 17:08:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlts07306; Fri, 20 Oct 2000 21:08:00 GMT Received: by mail-control.mail.uu.net id QQjlts03943 for mpls-outgoing; Fri, 20 Oct 2000 21:07:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlts03938 for ; Fri, 20 Oct 2000 21:07:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlts02297 for ; Fri, 20 Oct 2000 21:06:40 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjlts11210 for ; Fri, 20 Oct 2000 21:06:40 GMT Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP; Fri, 20 Oct 2000 22:05:47 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <4MC6DQH5>; Fri, 20 Oct 2000 22:05:43 +0100 Message-ID: To: azinin@cisco.com, darren.freeland@bt.com Cc: mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Fri, 20 Oct 2000 22:05:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Alex, you observered: > So, maybe it would be more constructive if you document your assumptions, > understanding of the current situation, required functionality and > concerns you have. This would be very valuable, I guess, and would > let people express their opinion. Such a document could serve as > a basis for [hopefully] more productive discussion. > > If e-mail does not work out, I think we can always schedule a BOF-like > meeting (not necessarily at an IETF one). Face-to-face always works > better. > NH=>This activity has been ongoing in BT for some time and we are currently formulating our requirements for the OTN. We have already mentioned many of our concerns/views on the list. If complete in time for the next IETF we may try and bring something along to help shape the framework. We are also already active with other operators/vendors and working on G.ason in the ITU....which is starting with a 'requirements capture' phase for the OTN control-plane. Always willing to talk face-face. Neil From owner-mpls@UU.NET Fri Oct 20 17:09:31 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00221 for ; Fri, 20 Oct 2000 17:09:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlts26205; Fri, 20 Oct 2000 21:08:52 GMT Received: by mail-control.mail.uu.net id QQjlts04129 for mpls-outgoing; Fri, 20 Oct 2000 21:08:21 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlts04124 for ; Fri, 20 Oct 2000 21:08:17 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlts00637 for ; Fri, 20 Oct 2000 21:07:06 GMT Received: from ziggy.stardust.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.stardust.com [205.184.205.34]) id QQjlts06035 for ; Fri, 20 Oct 2000 21:07:05 GMT Received: from pleiades (dhcp204-96.stardust.com [205.184.204.96]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA17543 for ; Fri, 20 Oct 2000 14:01:44 -0700 Message-Id: <3.0.5.32.20001020140143.014a66a0@stardust.com> X-Sender: jasonu@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Oct 2000 14:01:43 -0700 To: mpls@UU.NET From: Jason Utz Subject: MPLS Activities at upcoming iBANDatISPCON event Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk I wanted to give you a heads-up on the sessions at the upcoming iBAND at ISPCON event that are most relevant to this list: "IP Centric Control and Management of Optical Networks " "IP QoS: Whiteboard concept or global reality?" These are just a few of the technical sessions at this year's 5th iBAND conference and showcase, co-located with ISPCON this year at the San Jose Convention Center, November 8-10. Internet Traffic Management, Service Provisioning and Performance Measurement are the themes of the event. For more event information, go to: http://events.stardust.com/iband Before October 25, 2000, you can sign up for the event, get all the sessions free in MP3 format and get a $100 discount by going to https://events.stardust.com/iband/special/register_offer.htm and using the following registration code: MPLS ---------------------- Other Event Highlights ---------------------- Keynotes -------- * Content Delivery: A New World ofTechnology, Business & Value-Added Services Z. Alan Fink, Sr. Vice President & General Manager, Adero & Jim Ricotta,Senior Director, Marketing Cisco Systems * Internet Infrastructure: Why We Can't Just Paint Over the Cracks Judy Estrin, Chief Executive Officer, Packet Design, Inc. * Creating, Provisioning and Managing IP Services Under Massive Commercial Pressures Charles Muirhead, Founder, Orchestream and iGabriel.net BOFs * What's new in network processing and the CPIX Forum's role in it Colin Mick, CPIX Forum Steve Jacobson, RealNetworks * The Technical Needs of Content Peering Mark Day, Cisco Systems & Brad Cain, Mirror Image Internet * Enabling QoS at the Network Edge Manickam "Sri" Sridhar, Sitara Networks * Policy-based Configuration Management Art Mellor, Gold Wire Technology * Riding the Wave of Streaming Video Bodhi Mukherjee, InfoValue Computing * Internet2 Russ Hobby, UC Davis iBAND Showcase The iBAND Showcase is the fourth in a series of networks engineered by members of the QoS Forum and exhibitors at the iBAND event -- It will feature: * Accelerated Application Services * Intelligent Network Infrastructure * Service Management * Network Performance Tools Relevant Sessions S6 - - IP Centric Control and Management of Optical Networks Debanjan Saha, Tellium Optical Systems We are actively involved in the ongoing efforts in IETF, OIF, and ODSI to standardize IP centric control architecture and protocols for optical networks. This session will discuss the following issues from a service provider perspective: IP centric control optical architectures for optical networks and their impact on layer 3 networks, Functional requirements of optical layer control functions, namely, link management, topology discovery, routing, and signaling, and the ways they are different from similar functions in IP networks, Standards activities in these areas (e.g. MPLS, OSPF, UNI, etc.), implementation, and deployment issues. S8 - IP QoS: Whiteboard concept or global reality? Jim Hendrickson, QoS Networks Solutions such as ATM backbones and software offerings have tried to address the whiteboard vision of prioritizing and shaping traffic. The inherent problems with these solutions have been lack of granularity, increased latency, lack of scalability, and the introduction of complexity and inefficient overhead. Within the last two years, technology has been made available and global political shifts have allowed for the delivery of true Quality of Service beyond the edge and to the customer premises. This session will explore the current industry shift and how it will dramatically improve content delivery. It will also discuss what offerings are here now, such as bringing the management of Quality of Service to the desktop via a browser and VoIP delivery at land-line quality levels with no regard for type of termination points. From owner-mpls@UU.NET Fri Oct 20 17:59:03 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14377 for ; Fri, 20 Oct 2000 17:59:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjltv22719; Fri, 20 Oct 2000 21:58:35 GMT Received: by mail-control.mail.uu.net id QQjltv07970 for mpls-outgoing; Fri, 20 Oct 2000 21:58:02 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjltv07964 for ; Fri, 20 Oct 2000 21:57:56 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjltv24069 for ; Fri, 20 Oct 2000 21:57:48 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjltv21569 for ; Fri, 20 Oct 2000 21:57:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA25218 for mpls@uu.net; Fri, 20 Oct 2000 17:57:47 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjltv07947 for ; Fri, 20 Oct 2000 21:57:15 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjltv20119 for ; Fri, 20 Oct 2000 21:56:02 GMT Received: from dirty.research.bell-labs.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: dirty.research.bell-labs.com [204.178.16.6]) id QQjltv19179 for ; Fri, 20 Oct 2000 21:56:01 GMT Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Oct 20 17:55:20 EDT 2000 Received: from mail1.pa.bell-labs.com ([135.250.8.11]) by grubby; Fri Oct 20 17:55:19 EDT 2000 Received: from research.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAV40786 (AUTH gja); Fri, 20 Oct 2000 14:55:17 -0700 (PDT) Message-ID: <39F0C05D.70685486@research.bell-labs.com> Date: Fri, 20 Oct 2000 14:59:57 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh References: <71DA16F18D32D2119A1D0000F8FE9A940920C722@mbtlipnt01.btlabs.bt.co.uk> <39F07958.C4DB347@research.bell-labs.com> <39F0908F.B356DF9B@cisco.com> <39F09495.C3553AB8@research.bell-labs.com> <39F09E28.532F6C28@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sanjeev Rampal wrote: [..] > This enables merging operations > etc. > > In contrast optical switches work at the granularity of > optical channels/ lambdas/ STSs which are not > "mergeable" And my historical note is that "merge" wasn't even a mandatory requirement in MPLS when we first started bringing it into the ATM world. So this is not a point of fundamental difference, and does not invalidate the (now highly overstretched) analogy. Stepping back a little.... What also seems to be missed here is that the analogy between IP/ATM history, and IP/optical today isn't the technical details. It is that some class of operators emerged in the IP/atm world who believed their ATM nets served only one client (primarily) and therefore it made sense (for them) to optimize the ATM control for the IP 'client' (aka MPLS/ATM). Does this support or detract from arguments for the peer model? The absence of large operators stating on these lists that they're rolling out IP-only switched optical nets would seem to favor development of the overlay model for data/optics. cheers, gja From owner-mpls@UU.NET Fri Oct 20 19:33:21 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06972 for ; Fri, 20 Oct 2000 19:33:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjluc15408; Fri, 20 Oct 2000 23:33:10 GMT Received: by mail-control.mail.uu.net id QQjluc07272 for mpls-outgoing; Fri, 20 Oct 2000 23:32:46 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjluc07262 for ; Fri, 20 Oct 2000 23:32:38 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjluc24261 for ; Fri, 20 Oct 2000 23:31:51 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjluc13570 for ; Fri, 20 Oct 2000 23:31:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA03325 for mpls@uu.net; Fri, 20 Oct 2000 19:31:49 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjluc07211 for ; Fri, 20 Oct 2000 23:31:15 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjluc12051; Fri, 20 Oct 2000 23:31:03 GMT Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjluc12493; Fri, 20 Oct 2000 23:31:02 GMT Received: from dhcp-171-69-55-24.cisco.com (dhcp-171-69-55-24.cisco.com [171.69.55.24]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA01790; Fri, 20 Oct 2000 16:30:58 -0700 (PDT) Date: Fri, 20 Oct 2000 16:24:54 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <1683.001020@cisco.com> To: Yong Xue CC: darren.freeland@bt.com, braja@tellium.com, jdrake@calient.net, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: <3.0.32.20001020172636.0130c368@neserve0.uu.net> References: <3.0.32.20001020172636.0130c368@neserve0.uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yong, Friday, October 20, 2000, 2:26 PM, Yong Xue wrote: [...] > I think the carrier > should form > a group and come up with a control plane protocol requirements [...] I believe such a document would be very valuable. Alex. From owner-mpls@UU.NET Fri Oct 20 19:34:37 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07265 for ; Fri, 20 Oct 2000 19:34:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjluc26079; Fri, 20 Oct 2000 23:34:25 GMT Received: by mail-control.mail.uu.net id QQjluc07302 for mpls-outgoing; Fri, 20 Oct 2000 23:34:04 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjluc07295 for ; Fri, 20 Oct 2000 23:33:51 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjluc27083 for ; Fri, 20 Oct 2000 23:33:08 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjluc24343 for ; Fri, 20 Oct 2000 23:33:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA03417 for mpls@uu.net; Fri, 20 Oct 2000 19:33:07 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjluc07261 for ; Fri, 20 Oct 2000 23:32:38 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjluc24744; Fri, 20 Oct 2000 23:32:03 GMT Received: from ce-nfs-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjluc13836; Fri, 20 Oct 2000 23:32:02 GMT Received: from dhcp-171-69-55-24.cisco.com (dhcp-171-69-55-24.cisco.com [171.69.55.24]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA02380; Fri, 20 Oct 2000 16:32:01 -0700 (PDT) Date: Fri, 20 Oct 2000 16:25:58 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <8684.001020@cisco.com> To: "John Strand" CC: "'Yong Xue'" , , , , , , , "'oif_carrier_group'" Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh In-reply-To: <00e201c03ae5$c64bc4b0$3e82cf87@pcstranded.attnjs.research.att.com> References: <00e201c03ae5$c64bc4b0$3e82cf87@pcstranded.attnjs.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John, Friday, October 20, 2000, 3:33 PM, John Strand wrote: [...] > (3) As Yong mentioned, a number of carriers feel that the complexity of the peer model make > this a high-risk initial architecture. I think that Darren and many other people with > transport network experience (including me) would feel a lot more comfortable with > peer model proponents if more attention and respect were being given up-front to defining > requirements and understanding what makes optical networking different. For more on this, > see the I-D draft-chiu-strand-unique-OLCP. (Btw, there's a significantly revised version of > this available to anyone interested that reflects excellent comments from John Eaves and others.) Can I suggest that you just publish the new version? Thanks, Alex. From owner-mpls@UU.NET Fri Oct 20 23:04:52 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13560 for ; Fri, 20 Oct 2000 23:04:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjluq22559; Sat, 21 Oct 2000 03:04:19 GMT Received: by mail-control.mail.uu.net id QQjluq05201 for mpls-outgoing; Sat, 21 Oct 2000 03:03:52 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjluq05157 for ; Sat, 21 Oct 2000 03:03:44 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjluq11710 for ; Sat, 21 Oct 2000 03:03:03 GMT Received: from gateway.ntu.edu.sg by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.1.127]) id QQjluq05252 for ; Sat, 21 Oct 2000 03:03:02 GMT Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id <40TMVKPS>; Sat, 21 Oct 2000 11:02:53 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE039503F7@exchange4.ntu.edu.sg> From: Shen Gangxiang To: Mike Badil , wswen@ece.ucdavis.edu, mpls@UU.NET Subject: RE: Traffic engineering and RSVP Date: Sat, 21 Oct 2000 11:02:56 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk See my comments between lines. -----Original Message----- From: Mike Badil [mailto:hasko10@hotmail.com] Sent: Friday, October 20, 2000 10:48 PM To: wswen@ece.ucdavis.edu; mpls@UU.NET Subject: Re: Traffic engineering and RSVP Thanks eveybody for answer, see my comments below, >In fact, I think the discussion here missed something on the the basic >operation of the IP network. To send a data packet from a source to a >destination, we need to refer to two components--the >information carried inside the packet and a routing tabel (or switching >table). Because the >conventional IP network's routing is based on the destination address, if >we want to route the packet via an explicit path, it is necessary for the >IP header to carry some additional information. IP uses optional header to >carry the explicit route information so that the router inside the network >can process the explicit route request instead of the >destination-based routing. However, the processing overhead for such >optional header is prohibiting high and it is not a very good solution for >traffic engineering. ------------------------------------------------------------- Yes, I absulutly agree with you. So far it is very clear to me. ------------------------------------------------------- >Without MPLS, evern though we can use OSPF or other >link-state routing protocol to distribute the routing information, and use >the RSVP or other protocols to reserved the network resource, it >can not eliminate the requirement of the data packet to carrry the >explicit route information. Otherwise, the data packet will not follow the >explicit path. ------------------------------------------------------------------- Mike wrote: But how does it happened in RSVP, it established the path first then forward packets over pre-established path. isn,t it explicit path? I know, since we don't use swithing it will be slower than in case of swithing(MPLS).But lets forget about scalibility of RSVP, since in RSVP the paths are pre-established, in first router which makes the decision I can choose same the path for RSVP and MPLS, because both can use same algorithm to calculate the path. but after that MPLS path will be faster than the RSVP path because it use swithing. My question is; when you say RSVP will not use the explicit path what you mean, what today's RSVP doing? I think it established the path first then all the packets belongs to same flow follow same path. If this case true, then by using RSVP for pre-established path, we can satisfy TE requirments, such as lightly loaded path, link utilization etc. Lets forget about scalibility and packet processing time at this moment. Conventional RSVP doesn't support explicit path. In fact, it find its path based on the route table provided by those routing protocols hop by hop (e.g.OSPF). So it can't support traffic engineering. However,in MPLS people extended RSVP to let it support explicit path, that is RSVP-TE, so it can support traffic engineering now. Besides RSVP-TE, CR-LDP also have the functionlity to support traffic engineering. Thanks anyway > From owner-mpls@UU.NET Fri Oct 20 23:08:05 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13912 for ; Fri, 20 Oct 2000 23:08:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjluq26820; Sat, 21 Oct 2000 03:07:22 GMT Received: by mail-control.mail.uu.net id QQjluq05529 for mpls-outgoing; Sat, 21 Oct 2000 03:06:46 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjluq05509 for ; Sat, 21 Oct 2000 03:06:31 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjluq16496 for ; Sat, 21 Oct 2000 03:05:42 GMT Received: from gateway.ntu.edu.sg by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.1.127]) id QQjluq09125 for ; Sat, 21 Oct 2000 03:05:36 GMT Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id <40TMVKQ5>; Sat, 21 Oct 2000 11:05:16 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE039503F8@exchange4.ntu.edu.sg> From: Shen Gangxiang To: Sung-eok Jeon , mpls@UU.NET Subject: RE: Is IP TOS field changed by LSR? Date: Sat, 21 Oct 2000 11:05:19 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I think it is impossible as MPLS shim header is independent from IP header except TTL field. I guess you may have something wrong during your implementation. Gangxiang -----Original Message----- From: Sung-eok Jeon [mailto:gte358s@prism.gatech.edu] Sent: Friday, October 20, 2000 4:47 AM To: mpls@UU.NET Subject: Is IP TOS field changed by LSR? Dear Concerns, How are you doing? I and my friend are using the linux-mpls-ldp.pre7-0.200 to setup a MPLS network supporting serveral service classes. While we are trying to do setup our own network, we come upon a weird phenomenon. We think we observed that the TOS field of IP header is changed from LSR to LSR. Is it really true that the TOS field is modified from LSR to LSR? If the above is true? what is the reason? (I guess the front part of IP header might be used as a Label field. Is it right? ) ------------------------------------------------------------------------- The followings are what we are now trying to do : 1) Setup LSP( Source-LSR1-LSR2-Destination) 2) marking the TOS of IP header at LSR1. Because we want to support multiple services, we want to use the TOS field of the IP header. 3) Ping from source to destination and observe the packet content with Smartbit (between LSR1 and LSR2/ between LSR2 and destination). ==> Different TOS values according to different observing position. ------------------------------------------------------------------------- I hope some of you tell me if there is any mechanism modifying the TOS field of IP header in the program. If ture, Is there any other new version which does not change the TOS field? Thanks in advance. Sung-eok Jeon From owner-mpls@UU.NET Fri Oct 20 23:32:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16993 for ; Fri, 20 Oct 2000 23:32:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlus08627; Sat, 21 Oct 2000 03:32:16 GMT Received: by mail-control.mail.uu.net id QQjlus07283 for mpls-outgoing; Sat, 21 Oct 2000 03:31:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlus07275 for ; Sat, 21 Oct 2000 03:31:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjlus25827 for ; Sat, 21 Oct 2000 03:31:22 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjlus28516 for ; Sat, 21 Oct 2000 03:31:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA16328 for mpls@uu.net; Fri, 20 Oct 2000 23:31:21 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlus07153 for ; Sat, 21 Oct 2000 03:31:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlur00748 for ; Sat, 21 Oct 2000 03:29:42 GMT Received: from boyle.eng.level3.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: machine77.Level3.com [209.244.4.106]) id QQjlur05261 for ; Sat, 21 Oct 2000 03:29:37 GMT Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id UAA01001; Fri, 20 Oct 2000 20:52:43 -0600 Date: Fri, 20 Oct 2000 20:52:43 -0600 (MDT) From: Jim Boyle To: Bala Rajagopalan cc: Kireeti Kompella , mpls@UU.NET Subject: Re: Draft Minutes from Pittsburgh In-Reply-To: <39EC9CE8.3EB161D2@tellium.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk sorry if this is a restatement of something substantial in one of the 120 message in this group after this one(!!). I find no reason why the IGPs and interfaces between telecommunications gear should remain closed and proprietary. On safer ground, and I'm sure most of your customers would agree, use of priorities in signalling and routing will be very useful in providing services and achieving different levels of protected services. On technical merits of the two approaches, I believe I've already posted my thoughts. regards, Jim On Tue, 17 Oct 2000, Bala Rajagopalan wrote: > Kireeti: > > Kireeti Kompella wrote: > > > Hi Bala, > > > > I would invite others to participate; so far, the argument has gone > > back and forth between the authors of the drafts, who are > > understandably biased (apart from one comment from Curtis > > I welcome participation from others too. I'd especially like to hear from > those with an optical network perspective. > > > > > > > Perhaps you should read RFC 2702. TE metrics and affinities are a > > big part of MPLS/TE; if they are beyond your requirements, you should > > have a chat with service providers that have implemented MPLS/TE. > > Let me first say that I have had the previlege of reading RFC 2702. > Presently, routing schemes being designed for optical > transport networks are essentially proprietary in the manner > in which paths are computed. This includes whether and how > metrics and other parameters (per 2702) are assigned for links. > I'm interested in knowing if > you have chatted with any service provider who > wants to support all the MPLS/TE capabilities as per 2702 > in optical transport networks. Because, I haven't heard any such > requirement. In any case, you can always form link groups > based on metrics or any other tag. > > > > > > > > > On the other hand, draft-rs- introduces a new mechanism that adds no > > > > value, has the downside that the flooded information is potentially > > > > much greater (without recourse to optimization), and in the end does > > > > not remove the need for multiple parallel bundles between a pair of > > > > LSRs (OXCs). > > > > > > draft-rs addresses a specific set of requirements. Whether that adds > > > "value" is subjective, depending on what the application is. > > > > You're sidestepping the issue. The point is that "link groups" don't > > add value. At best, they appear to remove the need for flood > > optimization; however, since multiple bundles are needed anyway, this > > is a false notion. > > You're indeed getting repetetious here. > > > > > > > > To us, your > > > draft (+ flooding opt, multiple unnumbered link support) > > > doesn't give the value for the amount of work involved in implementing > > > it in the specific environment we're interested in. Your last statement about > > > multiple bundles is not true at all in the environment described in our > > > draft. > > > > Does your "specific environment" include other boxes from other > > vendors that you would interoperate with? Are the vendors of these > > boxes of the same opinion? It would be good to hear from them. > > I think the issue is of relevance to other vendors in our space. Right > now, I can only speak for ourselves. At this point, I don't know > how many people (especially with optical orientation) > have read your drafts and endorse them whole-heartedly. > It'd be good hear from those too. > > Regards, > > -- > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > From owner-mpls@UU.NET Sat Oct 21 05:58:04 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00597 for ; Sat, 21 Oct 2000 05:58:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlvr15195; Sat, 21 Oct 2000 09:57:47 GMT Received: by mail-control.mail.uu.net id QQjlvr07757 for mpls-outgoing; Sat, 21 Oct 2000 09:57:30 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlvr07752 for ; Sat, 21 Oct 2000 09:57:23 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlvr22240 for ; Sat, 21 Oct 2000 09:57:16 GMT Received: from gateway.ntu.edu.sg by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.1.127]) id QQjlvr19356 for ; Sat, 21 Oct 2000 09:57:14 GMT Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id <40TMVN37>; Sat, 21 Oct 2000 17:57:01 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE03950423@exchange4.ntu.edu.sg> From: Shen Gangxiang To: mpls@UU.NET Subject: Efficiency of protocol extension Date: Sat, 21 Oct 2000 17:57:04 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Folks, Now we are seeing lots of published IETF drafts are being extended from those earlier RFCs or drafts. I am sure that such an extension is a simple way to solve the new questions, but I am not sure if such an extension will be efficient enough for these new questions. I guess some guys may also share this opinion. Thanks for all comments! Gangxiang From owner-mpls@UU.NET Sat Oct 21 12:28:41 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22056 for ; Sat, 21 Oct 2000 12:28:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlwr02549; Sat, 21 Oct 2000 16:28:25 GMT Received: by mail-control.mail.uu.net id QQjlwr20659 for mpls-outgoing; Sat, 21 Oct 2000 16:28:07 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlwr20649 for ; Sat, 21 Oct 2000 16:28:03 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlwr08884 for ; Sat, 21 Oct 2000 16:27:08 GMT Received: from csa.iisc.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjlwr00210 for ; Sat, 21 Oct 2000 16:27:05 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA04633 for ; Sat, 21 Oct 2000 21:55:17 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id VAA12103 for ; Sat, 21 Oct 2000 21:56:54 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Sat, 21 Oct 2000 21:56:53 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: RESV session Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Please let me know the answers to the question asked below. Either i missed the anserws sent on this mailing list or perhaps no one replied to the question . Thanx in advance Prasanna ---------- Forwarded message ---------- Date: Tue, 26 Sep 2000 11:16:29 -0700 (PDT) From: jenny li To: mpls@UU.NET Subject: RESV session Hi, Suppose I have a multipoint-to-point LSPs. Host1 LSR Host3 Host2 Host1 and host2 as ingress node send path message with different tunnel and LSP ID to Host3, and suppose Host3 will use SE style to send Resv message back and assign same label to two senders. my questions: 1. in session part of Resv message, what content should be put there, since I have two session between host1/host2 to host3. 2. usually the content of session in Resv and Path is the same or not. for example, only have host1 and host3, and host1 sent path message to host 3, their content of session in both path and resv message is the same? Thanks in advance. Jenny __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-mpls@UU.NET Sat Oct 21 21:00:38 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20501 for ; Sat, 21 Oct 2000 21:00:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlya12943; Sun, 22 Oct 2000 01:00:22 GMT Received: by mail-control.mail.uu.net id QQjlxz21641 for mpls-outgoing; Sun, 22 Oct 2000 00:59:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlxz21636 for ; Sun, 22 Oct 2000 00:59:40 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlxz00664 for ; Sun, 22 Oct 2000 00:59:32 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe21.law10.hotmail.com [64.4.14.125]) id QQjlxz20206 for ; Sun, 22 Oct 2000 00:59:31 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 21 Oct 2000 17:59:31 -0700 X-Originating-IP: [24.189.146.213] From: "Frank Hujber" To: "Debanjan Saha" , Cc: , , References: <71DA16F18D32D2119A1D0000F8FE9A940920C723@mbtlipnt01.btlabs.bt.co.uk> <39F06570.FD3674A5@tellium.com> Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh Date: Sat, 21 Oct 2000 19:59:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 22 Oct 2000 00:59:31.0219 (UTC) FILETIME=[55E64630:01C03BC3] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Daren, Debjan, Do they at least agree that the OTN _will_ be multi-client? Or do they think that each client will own their own OTN? Frank Hujber fhujber@hotmail.com ----- Original Message ----- From: "Debanjan Saha" To: Cc: ; ; Sent: Friday, October 20, 2000 11:32 AM Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes FromPittsburgh > Darren, > > darren.freeland@bt.com wrote: > > My current thinking is that the peer model is impractical > > in a multi-client OTN. > > That's my thinking too. Clearly, there are "faithfuls" out there > who don't agree with this view :-) > > Debanjan > > > -- > Debanjan Saha Phone: 732-923-4264 > Senior Network Architect Fax: 732-923-9804 > Tellium Optical Systems http://www.tellium.com > From owner-mpls@UU.NET Sat Oct 21 22:07:51 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29536 for ; Sat, 21 Oct 2000 22:07:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlye09898; Sun, 22 Oct 2000 02:07:37 GMT Received: by mail-control.mail.uu.net id QQjlye18648 for mpls-outgoing; Sun, 22 Oct 2000 02:07:06 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlye18628 for ; Sun, 22 Oct 2000 02:06:58 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlye21410; Sun, 22 Oct 2000 02:06:30 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe17.law10.hotmail.com [64.4.14.121]) id QQjlye08412; Sun, 22 Oct 2000 02:06:29 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 21 Oct 2000 19:06:28 -0700 X-Originating-IP: [24.189.146.213] From: "Frank Hujber" To: "Alex Zinin" , "Yong Xue" Cc: , , , , , References: <3.0.32.20001020172636.0130c368@neserve0.uu.net> <1683.001020@cisco.com> Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Sat, 21 Oct 2000 21:06:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 22 Oct 2000 02:06:28.0702 (UTC) FILETIME=[B08187E0:01C03BCC] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I agree. Input from the carriers is essential. Frank Hujber fhujber@hotmail.com ----- Original Message ----- From: "Alex Zinin" To: "Yong Xue" Cc: ; ; ; ; ; Sent: Friday, October 20, 2000 7:24 PM Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh > > Yong, > > Friday, October 20, 2000, 2:26 PM, Yong Xue wrote: > > [...] > > > I think the carrier > > should form > > a group and come up with a control plane protocol requirements > > [...] > > I believe such a document would be very valuable. > > Alex. > > > From owner-mpls@UU.NET Sun Oct 22 00:32:20 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18842 for ; Sun, 22 Oct 2000 00:32:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlyn21674; Sun, 22 Oct 2000 04:28:08 GMT Received: by mail-control.mail.uu.net id QQjlyn20179 for mpls-outgoing; Sun, 22 Oct 2000 04:27:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjlyn20174 for ; Sun, 22 Oct 2000 04:27:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlyn12810 for ; Sun, 22 Oct 2000 04:27:07 GMT Received: from cod.ece.ucdavis.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cod.ece.ucdavis.edu [169.237.32.89]) id QQjlyn25141 for ; Sun, 22 Oct 2000 04:27:07 GMT Received: from localhost (wswen@localhost) by cod.ece.ucdavis.edu (8.9.3/8.9.3) with ESMTP id VAA06355; Sat, 21 Oct 2000 21:25:35 -0700 (PDT) Date: Sat, 21 Oct 2000 21:25:35 -0700 (PDT) From: Wushao Wen To: Frank Hujber cc: Shahram Davari , "'Mike Badil'" , mpls@UU.NET Subject: Re: Traffic engineering and RSVP In-Reply-To: <003801c03bbb$d9130780$d592bd18@default> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Frank, In fact, RSVP-TE is appropriate for MPLambdas. With the extension to the original RSVP protocol, RSVP-TE can be used to carry the label binding information. In the MPLambdaS, the label is now . RSVP-TE can carry the mapping information in the optical cross-connect for a connection via its MPLS control component in MPLS over WDM network (MPLambdaS). After the optical crooss-connect's switch fabic is changed according the new binding, the data packet can use circuit-switch to transmit the data backet. In fact, the important thing here is that RSVP is only used to carry the explicit path request along the path. The OXC then can setup its state according to the request. The underline data backet transmission is based on label swapping, not destionation-based routing as used by the IP network, so RSVP-TE can be used for MPLambdaS. Thanks! Wushao > If I understand what you say about RSVP, then I have to conclude that it is > not acceptable for traffic engineering and therefore it is also unacceptable > for MPLambdaS, given any need for the lambda path to be deterministic from > the ingress point. > > Am I missing something? > > Frank Hujber > fhujber@hotmail.com > ----- Original Message ----- > From: "Wushao Wen" > To: "Shahram Davari" > Cc: "'Mike Badil'" ; > Sent: Friday, October 20, 2000 11:43 AM > Subject: RE: Traffic engineering and RSVP > > > > Yes. Shahram is right. In fact, the major task for RSVP is to reserve the > > necessary resource along the path for a connection. Explicit routing is > > not a concern of the RSVP. RSVP does not change the basic > > packet routing mechanism--analyze the packet header and then do > > destination-based routing to select the next hop. > > > > > > Sincerly, > > > > > > Wushao > > > > > > > > As you know RSVP uses hop-by-hop routing in which each hop independently > > > computes the next hop. > > > > > > I think your confusion comes from the fact that in your RSVP example you > are > > > assuming that all nodes (even the interior nodes) are running the > constraint > > > based routing computation, so that there is no need for source routing > > > (explicit routing), rather their hop-by-hop routing results the same > path as > > > the explicit route. This is in theory possible, but it requires massive > > > computation by all the nodes. In comparison, MPLS requires the path > > > computation be done only by one node (the ingress node) and then > distribute > > > the computed path to the downstream nodes. > > > > > > Regards, > > > -Shahram > > > > > > > -----Original Message----- > > > > From: Mike Badil [mailto:hasko10@hotmail.com] > > > > Sent: Friday, October 20, 2000 10:48 AM > > > > To: wswen@ece.ucdavis.edu; mpls@UU.NET > > > > Subject: Re: Traffic engineering and RSVP > > > > > > > > > > > > > > > > Thanks eveybody for answer, > > > > see my comments below, > > > > > > > > > > > > > > > > >In fact, I think the discussion here missed something on the > > > > the basic > > > > >operation of the IP network. To send a data packet from a source to a > > > > >destination, we need to refer to two components--the > > > > >information carried inside the packet and a routing tabel > > > > (or switching > > > > >table). Because the > > > > >conventional IP network's routing is based on the > > > > destination address, if > > > > >we want to route the packet via an explicit path, it is > > > > necessary for the > > > > >IP header to carry some additional information. IP uses > > > > optional header to > > > > >carry the explicit route information so that the router > > > > inside the network > > > > >can process the explicit route request instead of the > > > > >destination-based routing. However, the processing overhead for such > > > > >optional header is prohibiting high and it is not a very > > > > good solution for > > > > >traffic engineering. > > > > ------------------------------------------------------------- > > > > Yes, I absulutly agree with you. So far it is very clear to me. > > > > ------------------------------------------------------- > > > > >Without MPLS, evern though we can use OSPF or other > > > > >link-state routing protocol to distribute the routing > > > > information, and use > > > > >the RSVP or other protocols to reserved the network resource, it > > > > >can not eliminate the requirement of the data packet to carrry the > > > > >explicit route information. Otherwise, the data packet will > > > > not follow the > > > > >explicit path. > > > > ------------------------------------------------------------------- > > > > But how does it happened in RSVP, it established the path > > > > first then forward > > > > packets over pre-established path. isn,t it explicit path? > > > > > > > > I know, since we don't use swithing it will be slower than in case of > > > > swithing(MPLS).But lets forget about scalibility of RSVP, > > > > since in RSVP the > > > > paths are pre-established, in first router which makes the > > > > decision I can > > > > choose same the path for RSVP and MPLS, because both can use > > > > same algorithm > > > > to calculate the path. but after that MPLS path will be > > > > faster than the RSVP > > > > path because it use swithing. > > > > > > > > My question is; when you say RSVP will not use the explicit > > > > path what you > > > > mean, what today's RSVP doing? I think it established the > > > > path first then > > > > all the packets belongs to same flow follow same path. If > > > > this case true, > > > > then by using RSVP for pre-established path, we can satisfy > > > > TE requirments, > > > > such as lightly loaded path, link utilization etc. > > > > Lets forget about scalibility and packet processing time at > > > > this moment. > > > > > > > > > > > > Thanks anyway > > > > > > > > > >MPLS solve this problem by doing label swapping instead of the > > > > >destination-based routing. Therefore, it is possible for a > > > > data packet to > > > > >use a > > > > >very short header to direct the router to send the packet to the > > > > >pre-selected route. > > > > > > > > > > > > > > >Wushao > > > > > > > > > >On Thu, 19 Oct 2000, Bora Akyol wrote: > > > > > > > > > > > I would not jump on this so fast, there is at least one > > > > router out there > > > > >that can > > > > > > do line rate 5-tuple lookups for many, many rules. > > > > > > > > > > > > Just because **you** don't know how to do it, doesn't > > > > mean it can't be > > > > >done. > > > > > > > > > > > > Bora > > > > > > > > > > > > > > > > > > > > > > > > Sudheer Dharanikota wrote: > > > > > > > > > > > > > Yes sir.. you are missing many things. > > > > > > > > > > > > > > TE is mainly used for core. In core nobody in right mind > > > > > > > will do 5 tuple lookup on the the Ip packet :-) > > > > > > > > > > > > > > - sudheer > > > > > > > > > > > > > > Rajeev Manur wrote: > > > > > > > > > > > > > > > > see below... > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > > > > > > > Sent: Thursday, October 19, 2000 7:21 AM > > > > > > > > To: Mike Badil > > > > > > > > Cc: mpls@UU.NET > > > > > > > > Subject: Re: Traffic engineering and RSVP > > > > > > > > > > > > > > > > Mike Badil wrote: > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > > > > > > > > > > > > > My question is: > > > > > > > > > > > > > > > > > > MPLS is combination of layer 2 swithing and layer 3 > > > > routing. > > > > >Traffic eng. > > > > > > > > is > > > > > > > > > part of layer 3. In MPLS route(LSP) is established > > > > in advance > > > > >according to > > > > > > > > > the constraints. in other word, instead of choosing > > > > shortest path, > > > > >it > > > > > > > > choose > > > > > > > > > the path which satisfy its requirments, and to make link > > > > >utulization > > > > > > > > better. > > > > > > > > > In order to have done this with MPLS there are some > > > > works which > > > > >say that > > > > > > > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > > > > > > > > > > > > > That is clear so far, > > > > > > > > > > > > > > > > > > I wondering that whether we can have those traffic > > > > engineering > > > > >conditions > > > > > > > > be > > > > > > > > > satisfied by other tech. > > > > > > > > > > > > > > > > > > For example; RSVP-Intserv set up route in advance > > > > also. If we use > > > > >extended > > > > > > > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we > > > > use in MPLS, > > > > > > > > > we can choose the path which satisfy our > > > > constraints instead of > > > > >choosing > > > > > > > > > Shortest path. Link load balancing can be done as > > > > in MPLS. So most > > > > >of > > > > > > > > > traffic engineering requirements will be > > > > satisfied.(let don't > > > > >consider > > > > > > > > > scalibility problem with RSVP now). Or it can work > > > > any other > > > > >technology > > > > > > > > > which use RSVP. > > > > > > > > > > > > > > > > > > > > > > > > > The problem is in applying filter at every node to > > > > make sure your IP > > > > > > > > packet > > > > > > > > is following the selected path. Hence data path becomes slow. > > > > > > > > > > > > > > > > RAJEEV> I thought almost all the boxes today perform > > > > complete packet > > > > > > > > processing at line-rate with or without the > > > > application of packet > > > > >filters. I > > > > > > > > don't see the relevence of the above statment. Am i missing > > > > >anything.. > > > > > > > > > > > > > > > > - sudheer > > > > > > > > > > > > > > > > > What am I missing here? > > > > > > > > > > > > > > > > > > > > > > >_____________________________________________________________ > > > > ____________ > > > > > > > > > Get Your Private, Free E-mail from MSN Hotmail at > > > > >http://www.hotmail.com. > > > > > > > > > > > > > > > > > > Share information about yourself, create your own > > > > public profile > > > > >at > > > > > > > > > http://profiles.msn.com. > > > > > > > > > > > > > > > > > > > ______________________________________________________________ > > > > ___________ > > > > Get Your Private, Free E-mail from MSN Hotmail at > > > http://www.hotmail.com. > > > > > > Share information about yourself, create your own public profile at > > > http://profiles.msn.com. > > > > > > > > From owner-mpls@UU.NET Sun Oct 22 07:38:17 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20535 for ; Sun, 22 Oct 2000 07:38:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlzq09102; Sun, 22 Oct 2000 11:37:59 GMT Received: by mail-control.mail.uu.net id QQjlzq04696 for mpls-outgoing; Sun, 22 Oct 2000 11:37:45 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjlzq04691 for ; Sun, 22 Oct 2000 11:37:35 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlzq16893 for ; Sun, 22 Oct 2000 11:37:29 GMT Received: from mailhost.iitb.ac.in by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQjlzq05283 for ; Sun, 22 Oct 2000 11:37:23 GMT Received: (qmail 26776 invoked from network); 22 Oct 2000 11:40:18 -0000 Received: from bhairav.ee.iitb.ernet.in (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 22 Oct 2000 11:40:18 -0000 Received: from localhost (gabhijit@localhost) by bhairav.ee.iitb.ernet.in (8.8.8/8.8.8) with SMTP id RAA12808 for ; Sun, 22 Oct 2000 17:04:49 +0530 (IST) Date: Sun, 22 Oct 2000 17:04:49 +0530 (IST) From: Abhijit To: mpls@UU.NET Subject: LDP question.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi all, In the LDP draft, In the procedure for Recognize New FEC (A.1.6) in the Appendix, the explaination of "InitAttributes" is given in the Note following the procedure. 1. An example of an attribute that might be part of InitAttributes is one which specifies desired LSP characteristics, such as class of service (CoS). (Note that while the current version of LDP does not specify a CoS attribute, LDP extensions may.) The means by which FEC InitAttributes, if any, are specified is beyond the scope of LDP. Note that the InitAttributes will not include a known Hop Count or a Path Vector. I have few doubts about that-- The questions are as follows 1. Why there is sudden inclusion of InitAttributes here in the procedure for new FEC when there is no mention of it anywhere in the draft? 2. And why the known Hop Count / Path Vectors cannot be sent while sending the Label mapping message as stated above in the draft? Thanks and Regards -abhijit From owner-mpls@UU.NET Sun Oct 22 09:21:50 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18517 for ; Sun, 22 Oct 2000 09:21:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjlzx08017; Sun, 22 Oct 2000 13:21:37 GMT Received: by mail-control.mail.uu.net id QQjlzx03668 for mpls-outgoing; Sun, 22 Oct 2000 13:21:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjlzx03609 for ; Sun, 22 Oct 2000 13:21:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjlzx22420 for ; Sun, 22 Oct 2000 13:20:20 GMT Received: from cms3.etri.re.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cms3.etri.re.kr [129.254.16.13]) id QQjlzx05948 for ; Sun, 22 Oct 2000 13:20:19 GMT Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2650.21) id ; Sun, 22 Oct 2000 22:20:06 +0900 Received: from pcisdn (pc-isdn10.etri.re.kr [129.254.18.201]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id VG61MT8Z; Sun, 22 Oct 2000 22:20:07 +0900 From: =?euc-kr?B?t/nIo7/r?= To: mpls Message-ID: <000001c03c76$6d770ce0$c912fe81@etri.re.kr> Subject: Loose ER-LSP and Route Pinning Date: Sun, 13 Aug 2000 23:47:49 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C00580.E3549D60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C00580.E3549D60 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgDQogDQpJIGhhdmUgc29tZSBxdWVzdGlvbiB0byBhc2sgcmVnYXJkaW5nIExTUCBzZXR1cCBp biBDUi1MRFAgc3BlY2lmaWF0aW9uLg0KIA0KSSB3YW50IHRvIGtub3cgdGhlIExvb3NlIEVSLUxT UCBhbmQgUm91dGUgUGlubmluZy4NCiANCklmIHlvdSBrbm93IGZvciBpdHMsIHdvdWxkIHlvdSB0 ZWxsIG1lID8gDQogDQpUaGFua3MgaW4gYWRhdm5jZS4NCiANCkJlc3QgUmVnYXJkcy4NCiANCkhv eW9uZyBSeXUuDQo= ------=_NextPart_000_000D_01C00580.E3549D60 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4wMC4yMzE0LjEw MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0Nv bG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSA8L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBoYXZlIHNvbWUgcXVlc3Rpb24gdG8gYXNr IHJlZ2FyZGluZyBMU1Agc2V0dXAgaW4gQ1ItTERQIA0Kc3BlY2lmaWF0aW9uLjwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHdhbnQgdG8ga25vdyB0 aGUgTG9vc2UgRVItTFNQIGFuZCBSb3V0ZSANClBpbm5pbmcuPC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPklmIHlvdSBrbm93Jm5ic3A7Zm9yIGl0cywm bmJzcDt3b3VsZCB5b3UgdGVsbCANCm1lJm5ic3A7PyZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFua3MgaW4gYWRhdm5jZS48L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QmVzdCBSZWdhcmRz LjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Ib3lv bmcgUnl1LjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000D_01C00580.E3549D60-- From owner-mpls@UU.NET Sun Oct 22 20:16:09 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08445 for ; Sun, 22 Oct 2000 20:16:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmbp24921; Mon, 23 Oct 2000 00:15:49 GMT Received: by mail-control.mail.uu.net id QQjmbo16601 for mpls-outgoing; Mon, 23 Oct 2000 00:14:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmbo16594 for ; Mon, 23 Oct 2000 00:14:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmbo29394 for ; Mon, 23 Oct 2000 00:14:49 GMT Received: from web5104.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web5104.mail.yahoo.com [216.115.106.74]) id QQjmbo13158 for ; Mon, 23 Oct 2000 00:14:49 GMT Message-ID: <20001023001448.2659.qmail@web5104.mail.yahoo.com> Received: from [64.208.153.210] by web5104.mail.yahoo.com; Sun, 22 Oct 2000 17:14:48 PDT Date: Sun, 22 Oct 2000 17:14:48 -0700 (PDT) From: Chatur sharp Subject: RFC2597 To: diffserv@ietf.org, mpls@UU.NET Cc: jh@telia.fi, fred@cisco.com, wweiss@lucent.com, jtw@lcs.mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi folks, This mail is regards the policing and providing QoS garruntees part of DIFFSERV. I have a feeling that the current definition of PHBs is incomplete to implement the AFx as well as the EF class. This is because in the PHB definition the destination of a flow is not taken into account. For example let us consider a simple network confg as shown below: Domain| Domain X | Y | | A ----|---B ---- C | \ | \___D In this setup domain X and domain Y are connected via link AB. Both these domains are independent DIFFSERV domain. Let us consider traffic entering domain Y( ingress node B) through domain X ( egress node B). Now the AF class definition says that the domain Y and hence node B must provide garuntee that as long as traffic coming from A is green it MUST forward it reliably. For example, let us say that the SLA between node B and node A garuntees that as long as traffic flowing is less than 200MB per sec it will treat it as green. But if A doesnot specify the destination of its traffic than B would be forced to allocate this much of bandwidth along all its link ( if it is to meet the MUST transfer it reliably requirement). This to me seems a little bizarre. Usually for CAC and traffic engineering you should know the endpoints. To me it seems that DIFFSERV is not useful as a traffic engineering tool as long as it is not combined with something like MPLS or it does not start including end points for identifying flows. To me an SLA between any two domains MUST mention the destination address or no garuntees can be provided and the traffic would be best effort. However, I do believe that in case, there is no CAC and hence policing to be performed then DIFFSERV can be used to prioritize traffic like in regular CoS-IP world. Any comments thanks C. ===== I am willing to learn, if you care to teach. I am willing to teach, if you care to learn. __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ From owner-mpls@UU.NET Mon Oct 23 06:19:34 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13479 for ; Mon, 23 Oct 2000 06:19:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdd23419; Mon, 23 Oct 2000 10:18:52 GMT Received: by mail-control.mail.uu.net id QQjmdd16049 for mpls-outgoing; Mon, 23 Oct 2000 10:18:19 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmdd16037 for ; Mon, 23 Oct 2000 10:18:09 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmdd26010 for ; Mon, 23 Oct 2000 10:18:04 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmdd22002 for ; Mon, 23 Oct 2000 10:18:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA05733 for mpls@uu.net; Mon, 23 Oct 2000 06:18:03 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmdd16010 for ; Mon, 23 Oct 2000 10:17:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmdd17257 for ; Mon, 23 Oct 2000 10:16:20 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjmdd09293 for ; Mon, 23 Oct 2000 10:16:20 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12733; Mon, 23 Oct 2000 06:16:19 -0400 (EDT) Message-Id: <200010231016.GAA12733@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-generalized-signaling-00.txt Date: Mon, 23 Oct 2000 06:16:18 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : Generalized MPLS - Signaling Functional Description Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-signaling-00.txt Pages : 41 Date : 20-Oct-00 This document describes extensions to MPLS signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms are currently included in this draft but are expected to be split out into separate, per protocol documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-00.txt 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-generalized-signaling-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001020115917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001020115917.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Oct 23 06:26:01 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14874 for ; Mon, 23 Oct 2000 06:26:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdd20715; Mon, 23 Oct 2000 10:25:30 GMT Received: by mail-control.mail.uu.net id QQjmdd16515 for mpls-outgoing; Mon, 23 Oct 2000 10:24:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmdd16510 for ; Mon, 23 Oct 2000 10:24:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmdd10092 for ; Mon, 23 Oct 2000 10:23:49 GMT Received: from smtp4.cluster.oleane.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62]) id QQjmdd22328 for ; Mon, 23 Oct 2000 10:23:48 GMT Received: from oleane (dyn-1-1-086.Vin.dialup.oleane.fr [195.25.4.86]) by smtp4.cluster.oleane.net with SMTP id MAA36780 for ; Mon, 23 Oct 2000 12:23:47 +0200 (CEST) Message-ID: <00ea01c03cdb$1c057d00$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World Congres 2001 Date: Mon, 23 Oct 2000 12:22:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01C03CEB.DF438860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00E7_01C03CEB.DF438860 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The MPLS World conference program is now online. Please get more details on: http://www.upperside.fr/congress/congress.htm ------=_NextPart_000_00E7_01C03CEB.DF438860 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The MPLS World conference program is = now=20 online.
Please get more details = on:
http://www.uppersi= de.fr/congress/congress.htm
------=_NextPart_000_00E7_01C03CEB.DF438860-- From owner-mpls@UU.NET Mon Oct 23 06:55:50 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22113 for ; Mon, 23 Oct 2000 06:55:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdf20466; Mon, 23 Oct 2000 10:55:38 GMT Received: by mail-control.mail.uu.net id QQjmdf18019 for mpls-outgoing; Mon, 23 Oct 2000 10:55:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmdf17999 for ; Mon, 23 Oct 2000 10:54:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmdf28150 for ; Mon, 23 Oct 2000 10:54:39 GMT From: darren.freeland@bt.com Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjmdf26998 for ; Mon, 23 Oct 2000 10:54:38 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Mon, 23 Oct 2000 11:18:08 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <4W3BAFTF>; Mon, 23 Oct 2000 11:17:25 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C746@mbtlipnt01.btlabs.bt.co.uk> To: kireeti@juniper.net, braja@tellium.com Cc: mpls@UU.NET Subject: RE: Draft Minutes from Pittsburgh Date: Mon, 23 Oct 2000 11:16:48 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, Back to the bundling debate (my apologies for being late to contribute) ... > > I would invite others to participate; so far, the argument has gone > > back and forth between the authors of the drafts, who are > > understandably biased (apart from one comment from Curtis <..snip..> > > The point is that "link groups" don't > > add value. At best, they appear to remove the need for flood > > optimization; however, since multiple bundles are needed anyway, this > > is a false notion. In my opinion, SRLG's will do value to an OTN simply because they make it easier for an operator to guarantee physically diverse working and protection paths. While it's obvious that your draft covers bundling in a general sense, Bala's draft focuses on the specific case of bundling for the OTN. I believe that it does provide something extra that your draft doesn't support. I'd therefore like to see both of the drafts merged, with a specific 'optical' section in the draft, and the concept of link groups incorporated. Regards, Darren. From owner-mpls@UU.NET Mon Oct 23 06:55:57 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22152 for ; Mon, 23 Oct 2000 06:55:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdf03884; Mon, 23 Oct 2000 10:55:33 GMT Received: by mail-control.mail.uu.net id QQjmdf18014 for mpls-outgoing; Mon, 23 Oct 2000 10:55:03 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmdf18001 for ; Mon, 23 Oct 2000 10:54:51 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmdf08284 for ; Mon, 23 Oct 2000 10:54:44 GMT From: darren.freeland@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjmdf02663 for ; Mon, 23 Oct 2000 10:54:44 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Mon, 23 Oct 2000 11:20:17 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 11:20:15 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C747@mbtlipnt01.btlabs.bt.co.uk> To: jboyle@Level3.net, braja@tellium.com Cc: kireeti@juniper.net, mpls@UU.NET Subject: RE: Draft Minutes from Pittsburgh Date: Mon, 23 Oct 2000 11:18:57 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jim Boyle wrote: > I find no reason why the IGPs and interfaces between telecommunications > gear should remain closed and proprietary. I agree! Regards, Darren. From owner-mpls@UU.NET Mon Oct 23 07:07:03 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24630 for ; Mon, 23 Oct 2000 07:07:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdg06716; Mon, 23 Oct 2000 11:06:25 GMT Received: by mail-control.mail.uu.net id QQjmdg29969 for mpls-outgoing; Mon, 23 Oct 2000 11:06:00 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmdg29952 for ; Mon, 23 Oct 2000 11:05:55 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmdg14484 for ; Mon, 23 Oct 2000 11:05:10 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjmdg16153 for ; Mon, 23 Oct 2000 11:05:07 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 23 Oct 2000 16:37:09 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA10202; Mon, 23 Oct 2000 16:22:17 +0530 Reply-To: From: "Manikantan S" To: Cc: Subject: Doubts, Clarifications requested for draft-ietf-mpls-ldp-ft-00.txt Date: Mon, 23 Oct 2000 16:29:19 +0530 Message-Id: <001601c03ce0$4be4ca80$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Adrian I read through the draft-ietf-mpls-ldp-ft-00.txt. I have a few doubts and can you please clarify? 1) In the section 7 Example Use Page 21, in (12) we have LDP Init(n/a,n/a,95) ---------------------------> This should mean that P1 indicates that it has secured messages with sequence number until 95. Subsequently we have in (14) Label Mapping(L2,95,-) <--------------------------- Is this correct? Since 95 has been given by P1, is it not sufficient that p2 provides only the Label Abort message which is given next in (14)? 2) In Section 4.4 Page 12, Second Paragraph. "Hold Timer" has been mentioned. I am not sure of this "Hold Timer". Is this the Hello Hold Timer (Section 2.5.5 in ldp-11 draft)? 3) Does "The Hold Timer for an FT LDP Session SHOULD be ignored while the FT Reconnection Timer is running" mean that the hello messages need not be expected from the Peer during the Reconnection time? 4) I am not clear with the advantage meant in the statement "This ensures that network resources are not permanently lost by one LSR if its LDP peer is forced to undergo a cold start." in page 8. My confusion is, when a LDP Peer P1 is made to undergo a cold start, the TCP session will be initiated again with "FT Reconnect Flag set to 0". This will cause the other LDP Peer P2 to release all the information. 5) What should be done in case of receipt of a "FT ACK Sequence Error"? This is generated by a Peer P1 to P2 when it receives an out of sequence ACK from P2. 6) When do we generate Notification with Status code " FT Sequence Numbers Exhausted" 7) It has been mentioned (very clearly) in the second paragraph in Section 4.4, that the Reconnection timeout is an implementation choice. Will it be possible to indicate the possible Reconnection timeout value? 8) Let P1 and P2 are two LDP Peers. Let us assume that P1 has transmitted a set of label requests to P2. Can P2 provide a reply to one of the label request messages LRQ1 from P1, without containing FT ACK TLV? and if such a message is received by P1 can P1 assume that the FT sequence number provided in LRQ1 is secured at P2? Thanks in advance with best regards Mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com ----------------------------------------- From owner-mpls@UU.NET Mon Oct 23 10:08:41 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11253 for ; Mon, 23 Oct 2000 10:08:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmds08213; Mon, 23 Oct 2000 14:07:44 GMT Received: by mail-control.mail.uu.net id QQjmds17109 for mpls-outgoing; Mon, 23 Oct 2000 14:07:04 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmds17100 for ; Mon, 23 Oct 2000 14:06:59 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmds05807 for ; Mon, 23 Oct 2000 14:06:12 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmds00782 for ; Mon, 23 Oct 2000 14:06:11 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA08820 for ; Mon, 23 Oct 2000 07:06:10 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA14626 for mpls@uu.net; Mon, 23 Oct 2000 10:06:08 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjltt05825 for ; Fri, 20 Oct 2000 21:29:12 GMT Received: from sysengws055 by imr3.ash.ops.us.uu.net with SMTP (peer crosschecked as: ippool147-224.corp.us.uu.net [153.39.147.224]) id QQjltt09083; Fri, 20 Oct 2000 21:28:42 GMT Message-Id: <3.0.32.20001020172636.0130c368@neserve0.uu.net> X-Sender: yxue@neserve0.uu.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Oct 2000 17:26:37 -0400 To: darren.freeland@bt.com, braja@tellium.com, jdrake@calient.net From: Yong Xue Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Cc: azinin@cisco.com, neil.2.harrison@bt.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Here is my 2 cents .. At 06:14 PM 10/19/00 +0100, darren.freeland@bt.com wrote: >Hi Bala, > >I agree totally with what you said. I think I perhaps gave the impression >to Alex and John that I am against an IP-centric control plane. This is not >the case - I'm not against any type of control plane just yet. > >My first point is that we have to fully understand the requirements of the >optical layer before we decide upon which protocols to use for it. My >second point is as you stated - the peer model is impractical for an >operator who wants to have a multi-client OTN (whether the control plane is >IP-centric or not). I would like to see some more debate on both these >points, because I'm sure there are many keeping quite who have strong views >on both. > As an ISP owned by an telco operator, I am wearing two hats. I would like to make sure the next gen OTN will be able to service not only IP clients, but also other type of clients, such as ATM, PL, Frame Relay, etc. from a telco operator's perspective, On the other hand, as an ISP, I am more concerned with how the OTN can be optimized for IP clients. I think both overlay model and peer model should be supported. OTN should be designed to allow the operator to choose either one of them, or both, depending on the service and business model it uses. However considering the complexity and security issues associated with the peer model, the overlay model should be supported first. This model works and carrier feel comfortable with it the most. As technology evolves, the peer model should find its application and acceptance by the carrier. For example, as an ISP, we would like to have our routers to control not only what lightpaths to be set up end to end by OTN, but how they should be set as well (router determines the explicit routes). Due to the business relation of the ISP with its parent carrier, this is a viable model. This is why the peer model should be supported. In an idea scenario, a policy-based configuration support at the demarcation point between the client network and the carrier OTN should allow the carrier to configure which port is running overlay model and which one is peer model. As for which control plane protocol we should use, I think we should open to all the existing protocols (MPLS/GMPLS, PNNI, SS7, etc.). I think the carrier should form a group and come up with a control plane protocol requirements and see which of them can best serve the requirement. I think we should allow more than one signaling protocols to exist. Actually, the recent T1X1 meeting has formed an ad hoc group to be participated by most of the US carriers to work on a signaling protocol requirement doc for ASON. Since the carriers are the ones that are going to buy the equipment to build their next gen OTN, their opinions should be seriously heard. In my opinion, IP-centric control plane like MPLS-based one sound better simply because we can reuse a proven technology at IP layer and it make it easier to implement the peer model for the IP clients. This may preclude some type of the client types (ATM, PL, etc) from working with the peer model, but it should work for the MPLS-enabled ATM or FR switches. Think about the future, 90% of the traffic is going to be IP and the IP clients should be dominant when we have to make a choice one way or the other. The other types of clients can still be serviced by the overlay model though. /Yong Yong Xue Global Network Architecture UUNET/WorldCom Ashburn, Virginia (703)-886-5358 yxue@uu.net From owner-mpls@UU.NET Mon Oct 23 10:12:36 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12108 for ; Mon, 23 Oct 2000 10:12:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmds15011; Mon, 23 Oct 2000 14:12:15 GMT Received: by mail-control.mail.uu.net id QQjmds17527 for mpls-outgoing; Mon, 23 Oct 2000 14:11:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmds17513 for ; Mon, 23 Oct 2000 14:11:35 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmds03616 for ; Mon, 23 Oct 2000 14:11:17 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjmds07956 for ; Mon, 23 Oct 2000 14:11:17 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22662 for ; Mon, 23 Oct 2000 10:11:13 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03592 for ; Mon, 23 Oct 2000 10:11:15 -0400 (EDT) Message-ID: <39F44532.D9F71FC1@marconi.com> Date: Mon, 23 Oct 2000 10:03:30 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: <9985F17605D2D21192D80008C75DE4BE039503F7@exchange4.ntu.edu.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shen Gangxiang wrote: > > Conventional RSVP doesn't support explicit path. In fact, it find its > path based on the route table provided by those routing protocols hop > by hop (e.g.OSPF). Traditional RSVP is not a routing protocol. It isn't supposed to in any way change the way data packets are routed. It's only supposed to make reservations. > So it can't support traffic engineering. But it doesn't dictate what other routing protocols might be used. If you don't want to use MPLS, you can still use some form of constraint- based routing to make the data follow a traffic-engineered path. A proper RSVP implementation should make reservations along that routed path, just like it would on any other routed path. > However,in MPLS people extended RSVP to let it support explicit path, > that is RSVP-TE, so it can support traffic engineering now. Besides > RSVP-TE, CR-LDP also have the functionlity to support traffic > engineering. RSVP-TE is designed for a completely different purpose. It is meant to carry traffic engineering information (labels and explicit paths), in addition to QoS values. It is designed to carry this information through a network where every node is running RSVP-TE. Straight RSVP is designed to carry QoS values through the internet, where many nodes will not be running RSVP. Needless to say, traffic engineering is impossible if some routers along the data path don't participate. -- David From owner-mpls@UU.NET Mon Oct 23 10:14:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12470 for ; Mon, 23 Oct 2000 10:14:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmds00818; Mon, 23 Oct 2000 14:12:24 GMT Received: by mail-control.mail.uu.net id QQjmds17534 for mpls-outgoing; Mon, 23 Oct 2000 14:11:51 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmds17514 for ; Mon, 23 Oct 2000 14:11:36 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmds03266 for ; Mon, 23 Oct 2000 14:11:09 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjmds07743 for ; Mon, 23 Oct 2000 14:11:08 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22650 for ; Mon, 23 Oct 2000 10:11:05 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03566 for ; Mon, 23 Oct 2000 10:11:07 -0400 (EDT) Message-ID: <39F44705.F22EB675@marconi.com> Date: Mon, 23 Oct 2000 10:11:17 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RESV session References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gaitonde Anandprasanna wrote: > > Please let me know the answers to the question asked below. > > Either i missed the anserws sent on this mailing list or perhaps no > one replied to the question . > > ---------- Forwarded message ---------- > > Suppose I have a multipoint-to-point LSPs. This is not legal in MPLS. Multicast is not specified at this time. Perhaps you are trying to create two unicast LSPs which share a common egress router? > Host1 > LSR Host3 > Host2 > > Host1 and host2 as ingress node send path message with different > tunnel and LSP ID to Host3, and suppose Host3 will use SE style to > send Resv message back and assign same label to two senders. 1: If they use different tunnel IDs, then this is not a multipoint-to- point LSP. You simply have two separate unicast LSPs in two separate sessions. 2: Since you have two sessions, they will not share resources with each other. It doesn't matter what reservation style Host3 chooses to use. > my questions: > 1. in session part of Resv message, what content should be put there, > since I have two session between host1/host2 to host3. You can't do this with one Resv message. You have two sessions. Therefore you must send two Resv messages. > 2. usually the content of session in Resv and Path is the same or not. > for example, only have host1 and host3, and host1 sent path message to > host 3, their content of session in both path and resv message is > the same? Is there a question in here? I can't figure out your English. I think you don't understand how RSVP is supposed to work. If you want two LSPs to share resources, then they must be in the same session. This means they must have the same tunnel egress address, the same tunnel ID, and the same extended tunnel ID. If you require two senders to use different sessions, then there is no way they can possibly share resources. -- David From owner-mpls@UU.NET Mon Oct 23 10:14:49 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12621 for ; Mon, 23 Oct 2000 10:14:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmds26809; Mon, 23 Oct 2000 14:10:06 GMT Received: by mail-control.mail.uu.net id QQjmds17292 for mpls-outgoing; Mon, 23 Oct 2000 14:09:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmds17283 for ; Mon, 23 Oct 2000 14:09:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmds00309 for ; Mon, 23 Oct 2000 14:08:38 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmds23887 for ; Mon, 23 Oct 2000 14:08:37 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA27549 for ; Mon, 23 Oct 2000 07:08:41 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA14642 for mpls@uu.net; Mon, 23 Oct 2000 10:08:35 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjlya03654 for ; Sun, 22 Oct 2000 01:07:05 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjlya15111 for ; Sun, 22 Oct 2000 01:06:02 GMT Received: from mx1.hcvlny.cv.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1.hcvlny.cv.net [167.206.112.76]) id QQjlya28812 for ; Sun, 22 Oct 2000 01:06:01 GMT Received: from s1.optonline.net (s1.optonline.net [167.206.112.6]) by mx1.hcvlny.cv.net (8.10.2/8.10.2) with ESMTP id e9M160005484; Sat, 21 Oct 2000 21:06:00 -0400 (EDT) Received: from default (ool-18bd92d5.dyn.optonline.net [24.189.146.213]) by s1.optonline.net (8.10.2/8.10.2) with SMTP id e9M160n08550; Sat, 21 Oct 2000 21:06:00 -0400 (EDT) Message-ID: <003801c03bbb$d9130780$d592bd18@default> From: "Frank Hujber" To: "Wushao Wen" , "Shahram Davari" Cc: "'Mike Badil'" , References: Subject: Re: Traffic engineering and RSVP Date: Sat, 21 Oct 2000 20:05:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Wushao, Shahram, If I understand what you say about RSVP, then I have to conclude that it is not acceptable for traffic engineering and therefore it is also unacceptable for MPLambdaS, given any need for the lambda path to be deterministic from the ingress point. Am I missing something? Frank Hujber fhujber@hotmail.com ----- Original Message ----- From: "Wushao Wen" To: "Shahram Davari" Cc: "'Mike Badil'" ; Sent: Friday, October 20, 2000 11:43 AM Subject: RE: Traffic engineering and RSVP > Yes. Shahram is right. In fact, the major task for RSVP is to reserve the > necessary resource along the path for a connection. Explicit routing is > not a concern of the RSVP. RSVP does not change the basic > packet routing mechanism--analyze the packet header and then do > destination-based routing to select the next hop. > > > Sincerly, > > > Wushao > > > > > As you know RSVP uses hop-by-hop routing in which each hop independently > > computes the next hop. > > > > I think your confusion comes from the fact that in your RSVP example you are > > assuming that all nodes (even the interior nodes) are running the constraint > > based routing computation, so that there is no need for source routing > > (explicit routing), rather their hop-by-hop routing results the same path as > > the explicit route. This is in theory possible, but it requires massive > > computation by all the nodes. In comparison, MPLS requires the path > > computation be done only by one node (the ingress node) and then distribute > > the computed path to the downstream nodes. > > > > Regards, > > -Shahram > > > > > -----Original Message----- > > > From: Mike Badil [mailto:hasko10@hotmail.com] > > > Sent: Friday, October 20, 2000 10:48 AM > > > To: wswen@ece.ucdavis.edu; mpls@UU.NET > > > Subject: Re: Traffic engineering and RSVP > > > > > > > > > > > > Thanks eveybody for answer, > > > see my comments below, > > > > > > > > > > > > >In fact, I think the discussion here missed something on the > > > the basic > > > >operation of the IP network. To send a data packet from a source to a > > > >destination, we need to refer to two components--the > > > >information carried inside the packet and a routing tabel > > > (or switching > > > >table). Because the > > > >conventional IP network's routing is based on the > > > destination address, if > > > >we want to route the packet via an explicit path, it is > > > necessary for the > > > >IP header to carry some additional information. IP uses > > > optional header to > > > >carry the explicit route information so that the router > > > inside the network > > > >can process the explicit route request instead of the > > > >destination-based routing. However, the processing overhead for such > > > >optional header is prohibiting high and it is not a very > > > good solution for > > > >traffic engineering. > > > ------------------------------------------------------------- > > > Yes, I absulutly agree with you. So far it is very clear to me. > > > ------------------------------------------------------- > > > >Without MPLS, evern though we can use OSPF or other > > > >link-state routing protocol to distribute the routing > > > information, and use > > > >the RSVP or other protocols to reserved the network resource, it > > > >can not eliminate the requirement of the data packet to carrry the > > > >explicit route information. Otherwise, the data packet will > > > not follow the > > > >explicit path. > > > ------------------------------------------------------------------- > > > But how does it happened in RSVP, it established the path > > > first then forward > > > packets over pre-established path. isn,t it explicit path? > > > > > > I know, since we don't use swithing it will be slower than in case of > > > swithing(MPLS).But lets forget about scalibility of RSVP, > > > since in RSVP the > > > paths are pre-established, in first router which makes the > > > decision I can > > > choose same the path for RSVP and MPLS, because both can use > > > same algorithm > > > to calculate the path. but after that MPLS path will be > > > faster than the RSVP > > > path because it use swithing. > > > > > > My question is; when you say RSVP will not use the explicit > > > path what you > > > mean, what today's RSVP doing? I think it established the > > > path first then > > > all the packets belongs to same flow follow same path. If > > > this case true, > > > then by using RSVP for pre-established path, we can satisfy > > > TE requirments, > > > such as lightly loaded path, link utilization etc. > > > Lets forget about scalibility and packet processing time at > > > this moment. > > > > > > > > > Thanks anyway > > > > > > > >MPLS solve this problem by doing label swapping instead of the > > > >destination-based routing. Therefore, it is possible for a > > > data packet to > > > >use a > > > >very short header to direct the router to send the packet to the > > > >pre-selected route. > > > > > > > > > > > >Wushao > > > > > > > >On Thu, 19 Oct 2000, Bora Akyol wrote: > > > > > > > > > I would not jump on this so fast, there is at least one > > > router out there > > > >that can > > > > > do line rate 5-tuple lookups for many, many rules. > > > > > > > > > > Just because **you** don't know how to do it, doesn't > > > mean it can't be > > > >done. > > > > > > > > > > Bora > > > > > > > > > > > > > > > > > > > > Sudheer Dharanikota wrote: > > > > > > > > > > > Yes sir.. you are missing many things. > > > > > > > > > > > > TE is mainly used for core. In core nobody in right mind > > > > > > will do 5 tuple lookup on the the Ip packet :-) > > > > > > > > > > > > - sudheer > > > > > > > > > > > > Rajeev Manur wrote: > > > > > > > > > > > > > > see below... > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Sudheer Dharanikota [mailto:sudheer@nayna.com] > > > > > > > Sent: Thursday, October 19, 2000 7:21 AM > > > > > > > To: Mike Badil > > > > > > > Cc: mpls@UU.NET > > > > > > > Subject: Re: Traffic engineering and RSVP > > > > > > > > > > > > > > Mike Badil wrote: > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > I confused when I read traffic engineering with MPLS. > > > > > > > > > > > > > > > > My question is: > > > > > > > > > > > > > > > > MPLS is combination of layer 2 swithing and layer 3 > > > routing. > > > >Traffic eng. > > > > > > > is > > > > > > > > part of layer 3. In MPLS route(LSP) is established > > > in advance > > > >according to > > > > > > > > the constraints. in other word, instead of choosing > > > shortest path, > > > >it > > > > > > > choose > > > > > > > > the path which satisfy its requirments, and to make link > > > >utulization > > > > > > > better. > > > > > > > > In order to have done this with MPLS there are some > > > works which > > > >say that > > > > > > > > OSPF,IS-IS can be modified by adding constraint to it. > > > > > > > > > > > > > > > > That is clear so far, > > > > > > > > > > > > > > > > I wondering that whether we can have those traffic > > > engineering > > > >conditions > > > > > > > be > > > > > > > > satisfied by other tech. > > > > > > > > > > > > > > > > For example; RSVP-Intserv set up route in advance > > > also. If we use > > > >extended > > > > > > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we > > > use in MPLS, > > > > > > > > we can choose the path which satisfy our > > > constraints instead of > > > >choosing > > > > > > > > Shortest path. Link load balancing can be done as > > > in MPLS. So most > > > >of > > > > > > > > traffic engineering requirements will be > > > satisfied.(let don't > > > >consider > > > > > > > > scalibility problem with RSVP now). Or it can work > > > any other > > > >technology > > > > > > > > which use RSVP. > > > > > > > > > > > > > > > > > > > > > > The problem is in applying filter at every node to > > > make sure your IP > > > > > > > packet > > > > > > > is following the selected path. Hence data path becomes slow. > > > > > > > > > > > > > > RAJEEV> I thought almost all the boxes today perform > > > complete packet > > > > > > > processing at line-rate with or without the > > > application of packet > > > >filters. I > > > > > > > don't see the relevence of the above statment. Am i missing > > > >anything.. > > > > > > > > > > > > > > - sudheer > > > > > > > > > > > > > > > What am I missing here? > > > > > > > > > > > > > > > > > > > >_____________________________________________________________ > > > ____________ > > > > > > > > Get Your Private, Free E-mail from MSN Hotmail at > > > >http://www.hotmail.com. > > > > > > > > > > > > > > > > Share information about yourself, create your own > > > public profile > > > >at > > > > > > > > http://profiles.msn.com. > > > > > > > > > > > > > > > ______________________________________________________________ > > > ___________ > > > Get Your Private, Free E-mail from MSN Hotmail at > > http://www.hotmail.com. > > > > Share information about yourself, create your own public profile at > > http://profiles.msn.com. > > > > From owner-mpls@UU.NET Mon Oct 23 10:18:11 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13452 for ; Mon, 23 Oct 2000 10:18:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdt08057; Mon, 23 Oct 2000 14:16:34 GMT Received: by mail-control.mail.uu.net id QQjmdt17981 for mpls-outgoing; Mon, 23 Oct 2000 14:15:59 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmdt17972 for ; Mon, 23 Oct 2000 14:15:47 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmdt26951; Mon, 23 Oct 2000 14:15:12 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQjmdt19322; Mon, 23 Oct 2000 14:15:12 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA07856; Mon, 23 Oct 2000 10:15:12 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA07847; Mon, 23 Oct 2000 10:15:11 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA20101; Mon, 23 Oct 2000 10:15:11 -0400 (EDT) Message-ID: <39F447EF.3E04007@lucent.com> Date: Mon, 23 Oct 2000 10:15:11 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Yong Xue CC: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <3.0.32.20001020172636.0130c368@neserve0.uu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Yong A question on your comments. > (router determines the explicit routes). This point has been raised by several folks. It really confuses me. If the optical switches are equipped with path calculation ability, what's the benefit to bother router to determine the explicit routes within optical domain (assuming router can be smart enough to handle all optical network specific attributes and constrains) than just have routers to determine the end points of optical trails. Thanks, Yangguang From owner-mpls@UU.NET Mon Oct 23 10:27:34 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15612 for ; Mon, 23 Oct 2000 10:27:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdt29430; Mon, 23 Oct 2000 14:26:36 GMT Received: by mail-control.mail.uu.net id QQjmdt18816 for mpls-outgoing; Mon, 23 Oct 2000 14:26:03 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmdt18790 for ; Mon, 23 Oct 2000 14:25:44 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmdt02567 for ; Mon, 23 Oct 2000 14:24:01 GMT From: darren.freeland@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjmdt25671 for ; Mon, 23 Oct 2000 14:24:01 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Mon, 23 Oct 2000 14:36:50 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <4W3BALP7>; Mon, 23 Oct 2000 14:36:07 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C751@mbtlipnt01.btlabs.bt.co.uk> To: osama@nortelnetworks.com, darren.freeland@bt.com, kireeti@juniper.net Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET, neil.2.harrison@bt.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Mon, 23 Oct 2000 14:35:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03CF6.1C940D20" Sender: owner-mpls@UU.NET Precedence: bulk ------_=_NextPart_001_01C03CF6.1C940D20 Content-type: text/plain; charset="iso-8859-1" Thanks Osama :-) -----Original Message----- From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com] Sent: 20 October 2000 19:21 To: darren.freeland@bt.com; kireeti@juniper.net Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; neil.2.harrison@bt.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh You may also consider the draft on LDP extensions for optical UNI Why I ask the above question is that there is a UNI based on IP > control protocols (draft-gray-mpls-rsvp-oif-uni-ext-00.txt), which > caters to non-IP uses of the OTN, and whose underlying model is the > overlay model. This draft is in response to the *OIF*'s requirements > for an optical UNI. I was not aware of this ID. Thanks. I will have a look at it when I'm back in the office Monday morning. ------_=_NextPart_001_01C03CF6.1C940D20 Content-type: text/html; charset="iso-8859-1" RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh
Thanks Osama :-)
-----Original Message-----
From: Osama Aboul-Magd [mailto:osama@nortelnetworks.com]
Sent: 20 October 2000 19:21
To: darren.freeland@bt.com; kireeti@juniper.net
Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; neil.2.harrison@bt.com
Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh

You may also consider the draft on LDP extensions for optical UNI <draft-mpls-aboulmagd-ldp-opical-uni-00.txt.

Regards;

Osama Aboul-Magd
ASON Standards and Architecture
Nortel Networks
P.O. Box 3511, Station "C"
Ottawa, ON, Canada
K1Y - 4H7
Tel: 613-763-5827
e.mail: osama@nortelnetworks.com


> Why I ask the above question is that there is a UNI based on IP
> control protocols (draft-gray-mpls-rsvp-oif-uni-ext-00.txt), which
> caters to non-IP uses of the OTN, and whose underlying model is the
> overlay model.  This draft is in response to the *OIF*'s requirements
> for an optical UNI.

I was not aware of this ID.  Thanks.  I will have a look at it when I'm back
in the office Monday morning.


------_=_NextPart_001_01C03CF6.1C940D20-- From owner-mpls@UU.NET Mon Oct 23 10:28:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15934 for ; Mon, 23 Oct 2000 10:28:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdt01196; Mon, 23 Oct 2000 14:27:36 GMT Received: by mail-control.mail.uu.net id QQjmdt18916 for mpls-outgoing; Mon, 23 Oct 2000 14:27:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmdt18904 for ; Mon, 23 Oct 2000 14:27:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmdt03431 for ; Mon, 23 Oct 2000 14:26:45 GMT Received: from cowansville.acbm.qc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjmdt05499 for ; Mon, 23 Oct 2000 14:26:40 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca for ; Mon, 23 Oct 2000 10:25:38 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id <4GAKAZLT>; Mon, 23 Oct 2000 10:26:05 -0400 Message-ID: <91E486361D4CD311B3140060089A882556A48D@hermes.hyperchip.com> From: Eyad Saheb To: "'mpls@uu.net'" Subject: stats Date: Mon, 23 Oct 2000 10:26:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03CFD.2C536830" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03CFD.2C536830 Content-Type: text/plain; charset="iso-8859-1" Hello everyone, I can see there are a few people that are unclear about the way RSVP works, perhaps they can do a little reading ? On another note, I have a question about stat gathering for Network Management purposes: Is a MPLS router expected to record the same stats outlined for a regular IP router (ex. rfc1812, MIBs, etc..) ? My feeling is that if it's supposed to be multi-protocol, then it shouldn't be snooping beyond the label stack. TIA, _____ Eyad Saheb IP Software Developer & QoS Technical Lead esaheb@Hyperchip.com www.Hyperchip.com H Y P E R C H I P The Petabit Routing Company Come meet us at: Career & Information Open House, 180 Peel, Suite 333, Oct. 26 & 27 OptiComm 2000, Dallas, Oct 24-25, Richard Norman - Panelist NGN, Washington, Oct 30-Nov 5, Booth 1010 SUPERnet, Santa Clara, Jan 14-17, Richard Norman, Panelist _____ ------_=_NextPart_001_01C03CFD.2C536830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable stats

Hello everyone,

        I can see = there are a few people that are unclear about the way RSVP works, = perhaps they can do a little reading ?

        On another = note, I have a question about stat gathering for Network Management = purposes: Is a MPLS router expected to record the same stats outlined = for a regular IP router (ex. rfc1812, MIBs, etc..) ?  My feeling = is that if it's supposed to be multi-protocol, then it shouldn't be = snooping beyond the label stack.

TIA,

  _____ 

Eyad Saheb
IP Software Developer & QoS Technical = Lead
esaheb@Hyperchip.com <mailto:esaheb@Hyperchip.com>=
www.Hyperchip.com <http://www.hyperchip.comh/>

H Y P E R C H I P
The Petabit Routing Company

Come meet us at:
Career & Information Open House, 180 Peel, Suite = 333, Oct. 26 & 27
OptiComm 2000, Dallas, Oct 24-25, Richard Norman - = Panelist
NGN, Washington, Oct 30-Nov 5, Booth 1010
SUPERnet, Santa Clara, Jan 14-17, Richard Norman, = Panelist

  _____ 


------_=_NextPart_001_01C03CFD.2C536830-- From owner-mpls@UU.NET Mon Oct 23 10:38:09 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18386 for ; Mon, 23 Oct 2000 10:38:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdu21518; Mon, 23 Oct 2000 14:37:41 GMT Received: by mail-control.mail.uu.net id QQjmdu20016 for mpls-outgoing; Mon, 23 Oct 2000 14:37:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmdu19999 for ; Mon, 23 Oct 2000 14:36:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmdu00501 for ; Mon, 23 Oct 2000 14:36:00 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjmdu13599 for ; Mon, 23 Oct 2000 14:36:00 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26493; Mon, 23 Oct 2000 10:35:55 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12778; Mon, 23 Oct 2000 10:35:57 -0400 (EDT) Message-ID: <39F44CD8.527F8AB0@marconi.com> Date: Mon, 23 Oct 2000 10:36:08 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Frank Hujber CC: Wushao Wen , Shahram Davari , "'Mike Badil'" , mpls@UU.NET Subject: Re: Traffic engineering and RSVP References: <003801c03bbb$d9130780$d592bd18@default> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Frank Hujber wrote: > > If I understand what you say about RSVP, then I have to conclude that > it is not acceptable for traffic engineering and therefore it is also > unacceptable for MPLambdaS, given any need for the lambda path to be > deterministic from the ingress point. > > Am I missing something? You're missing the fact that RSVP (aka RFC 2205) and RSVP-TE (draft-ietf-mpls-rsvp-lsp-tunnel-*) are two different protocols. Straight RSVP does not carry any routing information, and therefore can not do traffic engineering by itself. (Although it can work in conjunction with a routing protocol that provides the missing feature.) RSVP-TE, however, does carry explicit routing information. It should be sufficient for MPLambdaS. -- David From owner-mpls@UU.NET Mon Oct 23 10:38:09 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18387 for ; Mon, 23 Oct 2000 10:38:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdu15982; Mon, 23 Oct 2000 14:37:57 GMT Received: by mail-control.mail.uu.net id QQjmdu20033 for mpls-outgoing; Mon, 23 Oct 2000 14:37:23 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmdu20015 for ; Mon, 23 Oct 2000 14:37:03 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmdu13570 for ; Mon, 23 Oct 2000 14:35:41 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmdu11785 for ; Mon, 23 Oct 2000 14:35:41 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA18596 for ; Mon, 23 Oct 2000 07:35:44 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA14807 for mpls@uu.net; Mon, 23 Oct 2000 10:35:39 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmdt18968 for ; Mon, 23 Oct 2000 14:27:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmdt27271 for ; Mon, 23 Oct 2000 14:27:37 GMT Received: from mail-green.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQjmdt01203 for ; Mon, 23 Oct 2000 14:27:37 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id E7BD31E031; Mon, 23 Oct 2000 10:27:36 -0400 (EDT) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id KAA14115; Mon, 23 Oct 2000 10:27:31 -0400 (EDT) Reply-To: From: "John Strand" To: "'Alex Zinin'" Cc: , , "'oif_carrier_group'" Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Mon, 23 Oct 2000 10:27:15 -0400 Message-ID: <000d01c03cfd$5c0fddb0$3e82cf87@pcstranded.attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <8684.001020@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id KAA18387 Alex, We're planning on sending a new I-D to IETF in a couple of weeks. I'll send you a separate Email with the current MS Word version. Anyone else who wants a copy before the IETF version could send me a private Email (dont bother the mailing lists!) John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: Alex Zinin [mailto:azinin@cisco.com] Sent: Friday, October 20, 2000 7:26 PM To: John Strand Cc: 'Yong Xue'; darren.freeland@bt.com; braja@tellium.com; jdrake@calient.net; neil.2.harrison@bt.com; mpls@UU.NET; ip-optical@lists.bell-labs.com; 'oif_carrier_group' Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh John, Friday, October 20, 2000, 3:33 PM, John Strand wrote: [...] > (3) As Yong mentioned, a number of carriers feel that the complexity of the peer model make > this a high-risk initial architecture. I think that Darren and many other people with > transport network experience (including me) would feel a lot more comfortable with > peer model proponents if more attention and respect were being given up-front to defining > requirements and understanding what makes optical networking different. For more on this, > see the I-D draft-chiu-strand-unique-OLCP. (Btw, there's a significantly revised version of > this available to anyone interested that reflects excellent comments from John Eaves and others.) Can I suggest that you just publish the new version? Thanks, Alex. From owner-mpls@UU.NET Mon Oct 23 11:46:14 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00977 for ; Mon, 23 Oct 2000 11:46:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdz00036; Mon, 23 Oct 2000 15:45:00 GMT Received: by mail-control.mail.uu.net id QQjmdy07369 for mpls-outgoing; Mon, 23 Oct 2000 15:44:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmdy07364 for ; Mon, 23 Oct 2000 15:44:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmdy22236; Mon, 23 Oct 2000 15:43:24 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjmdy03910; Mon, 23 Oct 2000 15:43:23 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA29244; Mon, 23 Oct 2000 08:43:23 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id IAA01106; Mon, 23 Oct 2000 08:43:23 -0700 (PDT) Date: Mon, 23 Oct 2000 08:43:23 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010231543.IAA01106@kummer.juniper.net> To: xuyg@lucent.com, yxue@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi, > > (router determines the explicit routes). > > This point has been raised by several folks. It really confuses me. If the > optical switches are equipped with path calculation ability, what's the benefit > to bother router to determine the explicit routes within optical domain > (assuming router can be smart enough to handle all optical network specific > attributes and constrains) than just have routers to determine the end points of > optical trails. Why does this confuse you? Routers may want to determine the exact path that their LSPs take for a number of reasons, including TE and protection. If a router doesn't care where its LSPs are laid out, it can install loose hops at the boundaries of the optical cloud. Kireeti. From owner-mpls@UU.NET Mon Oct 23 12:01:19 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04132 for ; Mon, 23 Oct 2000 12:01:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmdz28909; Mon, 23 Oct 2000 15:59:11 GMT Received: by mail-control.mail.uu.net id QQjmdz08376 for mpls-outgoing; Mon, 23 Oct 2000 15:58:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmdz08365 for ; Mon, 23 Oct 2000 15:58:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmdz03990 for ; Mon, 23 Oct 2000 15:58:03 GMT Received: from ext1.ics.forth.gr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ext1.ics.forth.gr [139.91.151.10]) id QQjmdz27148 for ; Mon, 23 Oct 2000 15:58:01 GMT Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51]) by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id SAA18221 for ; Mon, 23 Oct 2000 18:57:21 +0300 (EET DST) Received: from sappho.ics.forth.gr (sappho-lane.ics.forth.gr [139.91.157.50]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id SAA24471 for ; Mon, 23 Oct 2000 18:57:08 +0300 (EET DST) Received: from localhost (tziou@localhost) by sappho.ics.forth.gr (8.8.8/ICS-FORTH/C1) with ESMTP id SAA27985 for ; Mon, 23 Oct 2000 18:56:06 +0300 (EET DST) Posted-Date: Mon, 23 Oct 2000 18:56:06 +0300 (EET DST) X-Authentication-Warning: sappho.ics.forth.gr: tziou owned process doing -bs Organization: Date: Mon, 23 Oct 2000 18:56:06 +0300 (EET DST) From: Chrysostomos Tziouvaras To: mpls@UU.NET Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Dear partners, if i have understood correctly an OXC is a device that does WAVELENGTH OPTICAL switching. BUT reading the "RSVP Extensions for Signaling Optical Paths" draft i saw that an OXC can have a forwarding table of the form , . IS it possible to OPTICALLY switch a sub-channel? Best regards Tziouvaras Chrysostomos ICS-FORTH Researcher From owner-mpls@UU.NET Mon Oct 23 12:14:15 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05780 for ; Mon, 23 Oct 2000 12:14:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmea17906; Mon, 23 Oct 2000 16:12:57 GMT Received: by mail-control.mail.uu.net id QQjmea20933 for mpls-outgoing; Mon, 23 Oct 2000 16:12:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmea20881 for ; Mon, 23 Oct 2000 16:12:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmea11580; Mon, 23 Oct 2000 16:11:06 GMT Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQjmea11381; Mon, 23 Oct 2000 16:11:06 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA28257; Mon, 23 Oct 2000 12:11:05 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA28233; Mon, 23 Oct 2000 12:11:05 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA16406; Mon, 23 Oct 2000 12:06:13 -0400 (EDT) Message-ID: <39F461F5.F39FD38B@lucent.com> Date: Mon, 23 Oct 2000 12:06:13 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <200010231543.IAA01106@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, You missed my point. I have no objection to whomever do the path selection. It's up to service providers. I am just wondering why some folks think it is BETTER "to have router caculate the optical path" than "to have the optical switches caculate themself"? In technical point of view, path selection can be done by whoever has the access to network level resource information. As path selection is very technology dependent, it should be done within technology domain. Yangguang Kireeti Kompella wrote: > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really confuses me. If the > > optical switches are equipped with path calculation ability, what's the benefit > > to bother router to determine the explicit routes within optical domain > > (assuming router can be smart enough to handle all optical network specific > > attributes and constrains) than just have routers to determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine the exact > path that their LSPs take for a number of reasons, including TE and > protection. If a router doesn't care where its LSPs are laid out, > it can install loose hops at the boundaries of the optical cloud. > > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Mon Oct 23 12:15:17 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05957 for ; Mon, 23 Oct 2000 12:15:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmea15738; Mon, 23 Oct 2000 16:13:49 GMT Received: by mail-control.mail.uu.net id QQjmea20997 for mpls-outgoing; Mon, 23 Oct 2000 16:12:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmea20992 for ; Mon, 23 Oct 2000 16:12:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmea14846 for ; Mon, 23 Oct 2000 16:12:14 GMT Received: from gateway.ntu.edu.sg by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.1.127]) id QQjmea13022 for ; Mon, 23 Oct 2000 16:12:08 GMT Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 00:11:56 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE01FDD112@exchange4.ntu.edu.sg> From: Shen Gangxiang To: "'David Charlap '" , "'mpls@UU.NET '" Subject: RE: Traffic engineering and RSVP Date: Tue, 24 Oct 2000 00:11:59 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, David, Please see my comments below. -----Original Message----- From: David Charlap To: mpls@UU.NET Sent: 23/10/00 10:03 PM Subject: Re: Traffic engineering and RSVP Shen Gangxiang wrote: > > Conventional RSVP doesn't support explicit path. In fact, it find its > path based on the route table provided by those routing protocols hop > by hop (e.g.OSPF). Traditional RSVP is not a routing protocol. It isn't supposed to in any way change the way data packets are routed. It's only supposed to make reservations. =>Agree. In fact, I guess you have misunderstood me. I didn't mean that RSVP is a routing protocol. I just wanted to point out that RSVP needs information from the routing ptotocols (e.g. PATH message) > So it can't support traffic engineering. But it doesn't dictate what other routing protocols might be used. If you don't want to use MPLS, you can still use some form of constraint- based routing to make the data follow a traffic-engineered path. A proper RSVP implementation should make reservations along that routed path, just like it would on any other routed path. =>Agree. However, to support traffic engineering, some extentions are still needed, e.g. ER. > However,in MPLS people extended RSVP to let it support explicit path, > that is RSVP-TE, so it can support traffic engineering now. Besides > RSVP-TE, CR-LDP also have the functionlity to support traffic > engineering. RSVP-TE is designed for a completely different purpose. It is meant to carry traffic engineering information (labels and explicit paths), in addition to QoS values. It is designed to carry this information through a network where every node is running RSVP-TE. Straight RSVP is designed to carry QoS values through the internet, where many nodes will not be running RSVP. Needless to say, traffic engineering is impossible if some routers along the data path don't participate. =>Agree. -- David From owner-mpls@UU.NET Mon Oct 23 12:18:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06761 for ; Mon, 23 Oct 2000 12:18:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmeb21785; Mon, 23 Oct 2000 16:15:31 GMT Received: by mail-control.mail.uu.net id QQjmeb21251 for mpls-outgoing; Mon, 23 Oct 2000 16:15:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmea21101 for ; Mon, 23 Oct 2000 16:14:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmea14424 for ; Mon, 23 Oct 2000 16:12:05 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmea12796 for ; Mon, 23 Oct 2000 16:11:59 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA26312 for ; Mon, 23 Oct 2000 09:11:59 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA15108 for mpls@uu.net; Mon, 23 Oct 2000 12:11:56 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmea11499 for ; Mon, 23 Oct 2000 16:00:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmea12988; Mon, 23 Oct 2000 16:00:39 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjmea21876; Mon, 23 Oct 2000 16:00:39 GMT Received: from mail1.tellium.com (mail1.tellium.com [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9NFqw904432; Mon, 23 Oct 2000 11:52:58 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 11:56:29 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D02204042B9492@mail1.tellium.com> From: Sid Chaudhuri To: "'Kireeti Kompella'" , xuyg@lucent.com, yxue@UU.NET Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 11:56:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I don't see why TE and protection require the routers to specify explicit routes. The routers can simply specify to the optical layer what type of optical layer protection it requires. Based on its traffic flow a router only needs to know between which two routers it needs to establish a new lightpath. How the lightpath is routed in the optical layer seems to me irrelevant to TE. Sid Chaudhuri -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, October 23, 2000 11:43 AM To: xuyg@lucent.com; yxue@UU.NET Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Hi, > > (router determines the explicit routes). > > This point has been raised by several folks. It really confuses me. If the > optical switches are equipped with path calculation ability, what's the benefit > to bother router to determine the explicit routes within optical domain > (assuming router can be smart enough to handle all optical network specific > attributes and constrains) than just have routers to determine the end points of > optical trails. Why does this confuse you? Routers may want to determine the exact path that their LSPs take for a number of reasons, including TE and protection. If a router doesn't care where its LSPs are laid out, it can install loose hops at the boundaries of the optical cloud. Kireeti. From owner-mpls@UU.NET Mon Oct 23 12:20:20 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07087 for ; Mon, 23 Oct 2000 12:20:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmeb17553; Mon, 23 Oct 2000 16:19:04 GMT Received: by mail-control.mail.uu.net id QQjmeb21581 for mpls-outgoing; Mon, 23 Oct 2000 16:18:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmeb21572 for ; Mon, 23 Oct 2000 16:18:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmeb05098; Mon, 23 Oct 2000 16:17:54 GMT Received: from hoemlsrv.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQjmeb23215; Mon, 23 Oct 2000 16:17:54 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA02413; Mon, 23 Oct 2000 12:17:53 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id MAA02400; Mon, 23 Oct 2000 12:17:53 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA10236; Mon, 23 Oct 2000 12:17:53 -0400 Message-ID: <39F46496.A0DE1F82@lucent.com> Date: Mon, 23 Oct 2000 12:17:26 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sid Chaudhuri CC: "'Kireeti Kompella'" , xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <0CD7D73C734BD411AEE100B0D02204042B9492@mail1.tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Sid, And to generalize even further, if a service provider sets up three grades of service (e.g., bronze, gold, platinum), the protection information should already be embedded within those service grades. For example, bronze is no protection at all, gold is dynamic mesh restoration, and platinum is 1+1 protection. I think what is most important to a service provider and their customers are the availability of the connection, i.e., is the connection up 99.99% or 99.999% or some other number. How the service provider chooses to handle how to meet that availability number is up to the service provider and their TE. Am I mis-representing the service provider here? Maybe some service providers can comment on whether the above description sounds right??? Thanks Zhi Sid Chaudhuri wrote: > > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Based on its traffic flow a router only needs to know between > which > two routers it needs to establish a new lightpath. How the lightpath is > routed in the > optical layer seems to me irrelevant to TE. > > Sid Chaudhuri > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com From owner-mpls@UU.NET Mon Oct 23 13:46:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20442 for ; Mon, 23 Oct 2000 13:46:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmeh02549; Mon, 23 Oct 2000 17:46:01 GMT Received: by mail-control.mail.uu.net id QQjmeh09971 for mpls-outgoing; Mon, 23 Oct 2000 17:45:18 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmeh09964 for ; Mon, 23 Oct 2000 17:45:12 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmeg03842 for ; Mon, 23 Oct 2000 17:44:56 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjmeg00511 for ; Mon, 23 Oct 2000 17:44:55 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Mon, 23 Oct 2000 18:30:34 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id <4C8FVWBB>; Mon, 23 Oct 2000 18:30:35 +0100 Message-ID: To: esaheb@hyperchip.com, mpls@UU.NET Subject: RE: stats Date: Mon, 23 Oct 2000 18:30:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk TIA wrote : On another note, I have a question about stat gathering for Network Management purposes: Is a MPLS router expected to record the same stats outlined for a regular IP router (ex. rfc1812, MIBs, etc..) ? My feeling is that if it's supposed to be multi-protocol, then it shouldn't be snooping beyond the label stack. It seems someone else has just realised that an LSP (user-plane) is layer network in its own right irrespective of its client. Your observations (above) are perfectly correct but they do not go far enough. For example, there will be defects that affect an MPLS layer network (at some LSP level) that are relevant only to that LSP and should only be recorded as stats against that layer network. There will, however, be client layers that are effected (and the correct consequent actions need to recurse through all higher client LSPs and ultimately the top-level LSP client payload, eg IP)...but the correct defect handling is not to send an ICMP pkt from where the MPLS layer defect is 1st detected (eg if using BGP4_LSP VPNs then the IP address is not even known to the (operator's) IGP (ie could not even route the ICMP pkt), let alone the fact that it is the LSP owner that needs telling there is a fault and not some external VPN client). The underlying issue here is correct layering and partitioning (as specified in G.805). If one adds O/H at a layer N trail source, that O/H is not relevant to any client layer or any sever layer......it is only meaningful (and hence any defect/perf stats dependent on this O/H) between the source/sink points of the trail at layer N. O/H handling in MPLS can be confused in my view....esp wrt to TTL and exp bits, and esp when PHP is added (PHP is a slightly different issue from other two however, in that O/H termination occurs at a node earlier than where the trail (=LSP) is actually supposed to end). neil From owner-mpls@UU.NET Mon Oct 23 13:59:37 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23299 for ; Mon, 23 Oct 2000 13:59:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmeh24733; Mon, 23 Oct 2000 17:58:53 GMT Received: by mail-control.mail.uu.net id QQjmeh10823 for mpls-outgoing; Mon, 23 Oct 2000 17:58:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmeh10818 for ; Mon, 23 Oct 2000 17:58:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmeh12302; Mon, 23 Oct 2000 17:58:17 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjmeh25327; Mon, 23 Oct 2000 17:58:16 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA11998; Mon, 23 Oct 2000 10:58:12 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA01526; Mon, 23 Oct 2000 10:58:12 -0700 (PDT) Date: Mon, 23 Oct 2000 10:58:12 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010231758.KAA01526@kummer.juniper.net> To: kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Suppose router A wants to get to router B, and wants to take two different ingress and egress points in the optical domain, X->Y for the primary LSP, and W->Z for the backup. A does not require optical protection for the X->Y path, nor for the W->Z path. A *does* require that the X->Y path and the W->Z path do not share common links. How is this to be done? If A did the full path computation, this is simplicity itself. > Based on its traffic flow a router only needs to know between > which > two routers it needs to establish a new lightpath. How the lightpath is > routed in the > optical layer seems to me irrelevant to TE. It's not up to you or me to say "irrelevant to TE"; the judge of relevancy is the user (SP), and it depends very much on how integrated the TE is between the optical domain and the routing domain. I know several SPs that would like *in the long term* to have a tightly integrated TE between the two domains; of course the majority today prefer loose or no coupling, as that fits their current mode of operation. From an analytical point of view, though, if you define TE as the mapping of flows to physical links, then it seems to me that how the lightpath is routed in the optical domain is very relevant. Kireeti. From owner-mpls@UU.NET Mon Oct 23 14:12:40 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25160 for ; Mon, 23 Oct 2000 14:12:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmei15376; Mon, 23 Oct 2000 18:11:17 GMT Received: by mail-control.mail.uu.net id QQjmei23331 for mpls-outgoing; Mon, 23 Oct 2000 18:10:39 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmei23321 for ; Mon, 23 Oct 2000 18:10:32 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmei15136; Mon, 23 Oct 2000 18:09:45 GMT Received: from auemlsrv.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQjmei09674; Mon, 23 Oct 2000 18:09:44 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA03748; Mon, 23 Oct 2000 14:09:44 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id OAA03736; Mon, 23 Oct 2000 14:09:43 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21929; Mon, 23 Oct 2000 14:09:43 -0400 Message-ID: <39F47ECB.4365E866@lucent.com> Date: Mon, 23 Oct 2000 14:09:15 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <200010231758.KAA01526@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kireeti, I agree that the judge of relevancy is the SPs. The SPs will tell us (vendors) what their business models are, and what we need to support first. In your example, you suggest that a router is setting up diverse paths for protection without the service provider knowing about this. Is the router part of the service provider network or part of the customer network? What is the reason for requesting those two diverse paths? Is it to meet some availability requirement? Or is it for something else? Thanks in advance for your clarification. Zhi Kireeti Kompella wrote: > > > I don't see why TE and protection require the routers to specify explicit > > routes. > > The routers can simply specify to the optical layer what type of optical > > layer protection > > it requires. > > Suppose router A wants to get to router B, and wants to take two > different ingress and egress points in the optical domain, X->Y > for the primary LSP, and W->Z for the backup. A does not require > optical protection for the X->Y path, nor for the W->Z path. A > *does* require that the X->Y path and the W->Z path do not share > common links. How is this to be done? > > If A did the full path computation, this is simplicity itself. > > > Based on its traffic flow a router only needs to know between > > which > > two routers it needs to establish a new lightpath. How the lightpath is > > routed in the > > optical layer seems to me irrelevant to TE. > > It's not up to you or me to say "irrelevant to TE"; the judge of > relevancy is the user (SP), and it depends very much on how > integrated the TE is between the optical domain and the routing > domain. I know several SPs that would like *in the long term* to > have a tightly integrated TE between the two domains; of course > the majority today prefer loose or no coupling, as that fits their > current mode of operation. > > From an analytical point of view, though, if you define TE as the > mapping of flows to physical links, then it seems to me that how > the lightpath is routed in the optical domain is very relevant. > > Kireeti. -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com From owner-mpls@UU.NET Mon Oct 23 14:16:16 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25638 for ; Mon, 23 Oct 2000 14:16:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmej21620; Mon, 23 Oct 2000 18:15:20 GMT Received: by mail-control.mail.uu.net id QQjmei24297 for mpls-outgoing; Mon, 23 Oct 2000 18:14:41 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmei24287 for ; Mon, 23 Oct 2000 18:14:31 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmei10899 for ; Mon, 23 Oct 2000 18:13:41 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmei18704 for ; Mon, 23 Oct 2000 18:13:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA04798 for mpls@uu.net; Mon, 23 Oct 2000 14:13:40 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmei23784 for ; Mon, 23 Oct 2000 18:12:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmei23282 for ; Mon, 23 Oct 2000 18:11:23 GMT Received: from miles.dataconnection.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQjmei11837 for ; Mon, 23 Oct 2000 18:11:23 GMT Received: by miles.dataconnection.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 19:11:21 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA570@monk.datcon.co.uk> From: Adrian Farrel To: mpls@UU.NET Cc: lberger@labn.net, petera@nortelnetworks.com Subject: draft-ietf-mpls-generalized-signaling-00.txt Date: Mon, 23 Oct 2000 19:11:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Lou and Peter, Thanks for a great job editing this and for getting it out into the public domain. I have a large block of comments and questions and bunch of minor typos. Please feel free to split the comments into separate threads if you like. Regards, Adrian Questions ========= Link Id and Explicit Routing I'm not sure how much this should be in Kireeti's bundling draft and how much in the Generalized draft. I have the following concern: - Suppose we use LSR addresses (i.e. not link addresses) in our explicit route and also use label sub-objects. Suppose further that there are multiple links of different types between a pair of LSRs. Finally consider that Label_Request is used, not Generalized_Label_Request. How does the LSR processing the ERO interpret the label and decide which link to apply it to? I guess you could say that you should avoid the combination of circumstances listed above and use G_L_R to constrain the link type or use the link address not the LSR address. Does that still work with unnumbered links? Error values etc. Can I suggest adding a section at the end as a place holder for new error values. In the text I have found - Routing Problem/Unsupported Encoding - Routing Problem/Unsupported Link Protection - Routing Problem/Unsupported GPID - Routing Problem/Unacceptable Label Value - Routing Problem/Label Set 3. Generalized Label Request Could you make it clearer right at the top of section 3 that for RSVP the Generalized_Label_Request is not a new object but a new variant of the Label_Request Object, whereas for CR-LDP it is a new TLV. 3.3.1 Waveband Switching "For compatibility reasons, a new RSVP c-type and CR- LDP type is assigned for the Waveband Label." This seems to be the only place in the draft where you haven't explicitly suggested values (subject to IANA). I think you have left gaps for RSVP c-type 3 and CR-LDP type 903. 3.5.1 Label Set It isn't clear how a sequence of subchannels that form a label set are conveyed. It can't be the case that you simply add multiple Subchannels to the Object/TLV since the Type is closely associated with each individual Subchannel. We should either define Label_Set as Explicit_Route with a sequence of subobjects. Or we should allow a series of Label_Sets in the Path/LABEL_REQUEST. In either case, it would be good to put in some motherhood about ordering the elements for clear interpretation. For example, suppose x; Mon, 23 Oct 2000 14:22:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmej29023; Mon, 23 Oct 2000 18:21:00 GMT Received: by mail-control.mail.uu.net id QQjmej25026 for mpls-outgoing; Mon, 23 Oct 2000 18:20:22 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmej25011 for ; Mon, 23 Oct 2000 18:20:18 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmej05132; Mon, 23 Oct 2000 18:18:59 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjmej26018; Mon, 23 Oct 2000 18:18:58 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Mon, 23 Oct 2000 18:59:20 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <41BM98GR>; Mon, 23 Oct 2000 18:57:53 +0100 Message-ID: To: zwlin@lucent.com, sc@tellium.com Cc: kireeti@juniper.net, xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 18:55:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Sounds fine to me Zhi. I keep trying to make the point that availability SLAs and QoS SLAs are quite different animals....the latter only has relevance when a connection (eg an LSP) is in the up-state. So I need to be able to know the former before I can do the latter. This is indeed why I also have a problem with the 'DiffServ' only approach which mutates failures into QoS hits, ie the forwarding behaviour of a traffic type (eg voice that needs EF) bears no relationship to its survivability requirements. I want to be able to offer my VPN customers different avail SLAs and this needs some notion of hard BW partitioning and overall VPN topology survival (vs other peer, different customer, VPNs)....if I merge all their traffic, then how can I do this? Of course this (ie hard BW partitioning) is forced once we start using CO/cct-sw fabrics like SDH and the OTN as 'LSPs' (I am not getting into the common control-plane issue here!....but you know my views on this by now). But the *principle* still applies everywhere else. Bottom-line.....I am only interested in QoS once I know the availability issue is cracked. To crack availability all defects, and there correct (user-plane) handling, must be defined. We are not there yet. Neil > -----Original Message----- > From: Zhi-Wei Lin [SMTP:zwlin@lucent.com] > Sent: Monday, October 23, 2000 5:17 PM > To: Sid Chaudhuri > Cc: 'Kireeti Kompella'; xuyg@lucent.com; yxue@UU.NET; > ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > Hi Sid, > > And to generalize even further, if a service provider sets up three > grades of service (e.g., bronze, gold, platinum), the protection > information should already be embedded within those service grades. For > example, bronze is no protection at all, gold is dynamic mesh > restoration, and platinum is 1+1 protection. > > I think what is most important to a service provider and their customers > are the availability of the connection, i.e., is the connection up > 99.99% or 99.999% or some other number. How the service provider chooses > to handle how to meet that availability number is up to the service > provider and their TE. > > Am I mis-representing the service provider here? Maybe some service > providers can comment on whether the above description sounds right??? > > Thanks > Zhi > > From owner-mpls@UU.NET Mon Oct 23 14:24:00 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26587 for ; Mon, 23 Oct 2000 14:24:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmej25455; Mon, 23 Oct 2000 18:20:56 GMT Received: by mail-control.mail.uu.net id QQjmej25027 for mpls-outgoing; Mon, 23 Oct 2000 18:20:23 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmej25015 for ; Mon, 23 Oct 2000 18:20:19 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmej05105; Mon, 23 Oct 2000 18:18:58 GMT From: darren.freeland@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjmej26010; Mon, 23 Oct 2000 18:18:58 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by gollum (local) with ESMTP; Mon, 23 Oct 2000 17:30:08 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <4W3BASXF>; Mon, 23 Oct 2000 17:28:01 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C758@mbtlipnt01.btlabs.bt.co.uk> To: zwlin@lucent.com, sc@tellium.com Cc: kireeti@juniper.net, xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 17:27:24 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Zhi, Your description sounds fine. Note that we may also wish to offer shared protection and other protection options as well as your three examples though. Regards, Darren. -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: 23 October 2000 17:17 To: Sid Chaudhuri Cc: 'Kireeti Kompella'; xuyg@lucent.com; yxue@UU.NET; ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Hi Sid, And to generalize even further, if a service provider sets up three grades of service (e.g., bronze, gold, platinum), the protection information should already be embedded within those service grades. For example, bronze is no protection at all, gold is dynamic mesh restoration, and platinum is 1+1 protection. I think what is most important to a service provider and their customers are the availability of the connection, i.e., is the connection up 99.99% or 99.999% or some other number. How the service provider chooses to handle how to meet that availability number is up to the service provider and their TE. Am I mis-representing the service provider here? Maybe some service providers can comment on whether the above description sounds right??? Thanks Zhi Sid Chaudhuri wrote: > > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Based on its traffic flow a router only needs to know between > which > two routers it needs to establish a new lightpath. How the lightpath is > routed in the > optical layer seems to me irrelevant to TE. > > Sid Chaudhuri > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com From owner-mpls@UU.NET Mon Oct 23 14:26:41 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26935 for ; Mon, 23 Oct 2000 14:26:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmej08401; Mon, 23 Oct 2000 18:25:16 GMT Received: by mail-control.mail.uu.net id QQjmej25465 for mpls-outgoing; Mon, 23 Oct 2000 18:24:56 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmej25447 for ; Mon, 23 Oct 2000 18:24:48 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmej02291 for ; Mon, 23 Oct 2000 18:23:05 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjmej28630 for ; Mon, 23 Oct 2000 18:23:04 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18426 for ; Mon, 23 Oct 2000 14:23:02 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA17599 for ; Mon, 23 Oct 2000 14:23:02 -0400 (EDT) Message-ID: <39F48212.ECE49186@marconi.com> Date: Mon, 23 Oct 2000 14:23:14 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@UU.NET '" Subject: Re: Traffic engineering and RSVP References: <9985F17605D2D21192D80008C75DE4BE01FDD112@exchange4.ntu.edu.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shen Gangxiang wrote: > > Agree. However, to support traffic engineering, some extentions are > still needed, e.g. ER. But an extension like the ERO object (which changes the nature of RSVP - allowing it to change the path that data packets follow) is not the only way. It is also possible if the routes are determined through some TE routing protocol. Leaving RSVP with its original duties of only making reservations. But this is not relevant here in an MPLS mailing list. -- David From owner-mpls@UU.NET Mon Oct 23 14:31:16 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27936 for ; Mon, 23 Oct 2000 14:31:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmek12321; Mon, 23 Oct 2000 18:30:11 GMT Received: by mail-control.mail.uu.net id QQjmej25917 for mpls-outgoing; Mon, 23 Oct 2000 18:29:37 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmej25908 for ; Mon, 23 Oct 2000 18:29:28 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmej13063 for ; Mon, 23 Oct 2000 18:27:38 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmej12777 for ; Mon, 23 Oct 2000 18:27:37 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA07559 for ; Mon, 23 Oct 2000 11:27:37 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA15449 for mpls@uu.net; Mon, 23 Oct 2000 14:27:35 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmei23028 for ; Mon, 23 Oct 2000 18:07:52 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmei10186; Mon, 23 Oct 2000 18:07:35 GMT Received: from boyle.eng.level3.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: machine77.Level3.com [209.244.4.106]) id QQjmei08634; Mon, 23 Oct 2000 18:07:34 GMT Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id MAA01916; Mon, 23 Oct 2000 12:09:14 -0600 X-Authentication-Warning: boyle.eng.level3.com: jboyle owned process doing -bs Date: Mon, 23 Oct 2000 12:09:14 -0600 (MDT) From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: Sid Chaudhuri cc: "'Kireeti Kompella'" , xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-Reply-To: <0CD7D73C734BD411AEE100B0D02204042B9492@mail1.tellium.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk if the lambda's are unprotected (which is debatable), then the routers can communicate amongst themselves and decide what are the failure scenarios, and request more or less capacity based on that analysis. A complex alternative is to support things like: a) "setup these two circuits in a diverse manner" b) same as (a) but over different UNIs, in fact in different towns (e.g. setup nyc-sfo diverse from wdc-lax) c) "setup this circuit diverse from SRLG A,B,C" (which may be infeasible if the circuit which those SRLGs were derived from preclude a diverse route). As for path selection in general, a knowledge of the underlying topology is probably necessary for most optimal path selection when establishing lightpaths for non-direct traffic. This only makes sense in the 2001 timeframe to support one's ISP over one's optical network. An argument can be made that a good OSS makes a lot of this level of integration unnecessary. Inter-company is a whole other issue. regards, Jim On Mon, 23 Oct 2000, Sid Chaudhuri wrote: > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Based on its traffic flow a router only needs to know between > which > two routers it needs to establish a new lightpath. How the lightpath is > routed in the > optical layer seems to me irrelevant to TE. > > Sid Chaudhuri > > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > From owner-mpls@UU.NET Mon Oct 23 14:35:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29469 for ; Mon, 23 Oct 2000 14:35:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmek23917; Mon, 23 Oct 2000 18:34:31 GMT Received: by mail-control.mail.uu.net id QQjmek26195 for mpls-outgoing; Mon, 23 Oct 2000 18:33:58 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmek26190 for ; Mon, 23 Oct 2000 18:33:50 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmek26510 for ; Mon, 23 Oct 2000 18:33:27 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmek17060 for ; Mon, 23 Oct 2000 18:33:26 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA18237 for ; Mon, 23 Oct 2000 11:33:29 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA15483 for mpls@uu.net; Mon, 23 Oct 2000 14:33:24 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmej25882 for ; Mon, 23 Oct 2000 18:29:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmej05860 for ; Mon, 23 Oct 2000 18:28:45 GMT Received: from mpls-router.hirp.ece.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: unalloc-94net-221.iisc.ernet.in [144.16.94.221] (may be forged)) id QQjmej14394 for ; Mon, 23 Oct 2000 18:28:38 GMT Received: from localhost (ytr@localhost) by mpls-router.hirp.ece.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id AAA02848 for ; Tue, 24 Oct 2000 00:01:30 +0530 X-Authentication-Warning: mpls-router.hirp.ece.iisc.ernet.in: ytr owned process doing -bs Date: Tue, 24 Oct 2000 00:01:29 +0530 (IST) From: "Y.T. Ramanjaneyulu" To: mpls@UU.NET Subject: COPS doubt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk HI, If already discussed these things then please provide pointers to mail archives I am currently working on a Project which involves developing a Label Switched router in a MPLS domain.The core protocols which are used in this work are MPLS as the forwarding mechanism and RSVP-TE as the signalling Protocol.Main intention of ours is to provide Qos services to the end users in MPLS domain. I thought of having a Resource manager inside each LSR to manage the resources locally. We have policies to allow user to consume only certain amount of bandwidth etc. PDP generally situated in some remote machine and collecting statistics from allclients and making descisions . So in our scenario is it necessary to have a PEP and a PDP (COPS Protocol) inside the network ??? Thanx in advance -- Regards YTR NOTE: ----- P L E A S E DON'T R E P L Y TO THIS MAIL ID. ************************* If u want to reply please reply to ytr@csa.iisc.ernet.in ************************ From owner-mpls@UU.NET Mon Oct 23 14:37:21 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00105 for ; Mon, 23 Oct 2000 14:37:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmej29164; Mon, 23 Oct 2000 18:23:23 GMT Received: by mail-control.mail.uu.net id QQjmej25319 for mpls-outgoing; Mon, 23 Oct 2000 18:22:58 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmej25305 for ; Mon, 23 Oct 2000 18:22:49 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmej29790; Mon, 23 Oct 2000 18:22:01 GMT Received: from kcmgwp01.corp.sprint.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ret1.sprint.com [208.18.122.165]) id QQjmej00714; Mon, 23 Oct 2000 18:22:01 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id e9NILwF08996; Mon, 23 Oct 2000 13:21:58 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id e9NILvW27569; Mon, 23 Oct 2000 13:21:57 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id NAA05432; Mon, 23 Oct 2000 13:21:56 -0500 (CDT) From: Mark.Jones@mail.sprint.com X-OpenMail-Hops: 1 Date: Mon, 23 Oct 2000 13:21:55 -0500 Message-Id: Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh MIME-Version: 1.0 TO: ip-optical@lists.bell-labs.com, mpls@UU.NET CC: kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Content-Type: multipart/mixed; boundary="openmail-part-2bb23c62-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-2bb23c62-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 23 Oct 2000 13:21:53 -0500" Content-Transfer-Encoding: 7bit [I haven't had time to follow this entire thread, so please correct me if I'm off track with the discussion.] Zhi and Sid are correct. I have trouble seeing any kind of peering model fitting in a multi-client network like Sprints, so I come with that assumption. For an overlay or client model, the specification of protection types doesn't make sense across the UNI. We argued this point at the OIF in Barcelona. Carriers have their own schemes for providing the protection for services, and every implementation of the different architectures provide different results. What I mean is that a Sprint ring network, deployed over our fiber plant using equipment from vendor X, will give you different availability than a ring in another carrier's network using their fiber plant and vendor Y. That's just one example. The availability and BER are all a customer wants or needs. If I can give you 99.999% availability (or whatever availability you want to pay for) with a BER to satisfy your needs, why do you care whether I use ring, mesh, or some other scheme? Grade of service is sufficient. What is needed is standardization of the service grades, so Gold service is the same thing across every network (independent of the unlying protection architecture). Though I haven't followed the details, I seem to remember seeing work on this in another standards body. Mark Loyd Jones Sprint Technology Planning & Integration 913-534-5247 mark.jones@mail.sprint.com > -----Original Message----- > From: zwlin [mailto:zwlin@lucent.com] > Sent: Monday, October 23, 2000 11:17 AM > To: sc > Cc: zwlin; kireeti; xuyg; yxue; ip-optical; mpls > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > Hi Sid, > > And to generalize even further, if a service provider sets up three > grades of service (e.g., bronze, gold, platinum), the protection > information should already be embedded within those service > grades. For > example, bronze is no protection at all, gold is dynamic mesh > restoration, and platinum is 1+1 protection. > > I think what is most important to a service provider and > their customers > are the availability of the connection, i.e., is the connection up > 99.99% or 99.999% or some other number. How the service > provider chooses > to handle how to meet that availability number is up to the service > provider and their TE. > > Am I mis-representing the service provider here? Maybe some service > providers can comment on whether the above description sounds right??? > > Thanks > Zhi > > > Sid Chaudhuri wrote: > > > > I don't see why TE and protection require the routers to > specify explicit > > routes. > > The routers can simply specify to the optical layer what > type of optical > > layer protection > > it requires. Based on its traffic flow a router only needs > to know between > > which > > two routers it needs to establish a new lightpath. How the > lightpath is > > routed in the > > optical layer seems to me irrelevant to TE. > > > > Sid Chaudhuri > > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com --openmail-part-2bb23c62-00000001-- From owner-mpls@UU.NET Mon Oct 23 14:44:08 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01807 for ; Mon, 23 Oct 2000 14:44:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmek27451; Mon, 23 Oct 2000 18:43:08 GMT Received: by mail-control.mail.uu.net id QQjmek26672 for mpls-outgoing; Mon, 23 Oct 2000 18:42:35 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmek26667 for ; Mon, 23 Oct 2000 18:42:33 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmek16620; Mon, 23 Oct 2000 18:41:57 GMT Received: from mail-green.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQjmek06976; Mon, 23 Oct 2000 18:41:57 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 440111E008; Mon, 23 Oct 2000 14:41:57 -0400 (EDT) Received: from pcalchiu (pclopez [135.207.131.94]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id OAA22881; Mon, 23 Oct 2000 14:41:52 -0400 (EDT) Reply-To: From: "Angela Chiu" To: "'Kireeti Kompella'" Cc: , , , , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 14:42:45 -0400 Message-ID: <003501c03d21$0a0cccc0$5e83cf87@attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200010231758.KAA01526@kummer.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, Some followup discussions in line. Regards, Angela -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kireeti Kompella Sent: Monday, October 23, 2000 1:58 PM To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Suppose router A wants to get to router B, and wants to take two different ingress and egress points in the optical domain, X->Y for the primary LSP, and W->Z for the backup. A does not require optical protection for the X->Y path, nor for the W->Z path. A *does* require that the X->Y path and the W->Z path do not share common links. How is this to be done? If A did the full path computation, this is simplicity itself. [AC] I think you have a good point here. I also heard the same kind if reasoning (i.e., have a layer-3 like protection switching) for supporting the peer model. But after discussing with others, it seems that overlay model should be able to provide the same capability. Normally, the primary LSP X->Y is set up first, and becomes a forwarding adjacency (FA) according to your LSP Hierarchy draft. Then the associated information of the FA X->Y including its exact path and SRLG information should be propagated via IGP extensions, same as with any other link in the network. Thus if router A sends a request to OXC W to set up a backup lightpath from W->Z to be diversely router from the existing FA X->Y, OXC W should already have the right information to perform proper routing. Comparing with the peer model solution where routers need to know all the SRLG information of the optical domain as well as all relevant physical impairments in the optical signal in the case of transparent optical network, it is still not clear to me which one is simpler. I think it is very good to have this kind of technical discussion openly on the list. Hope others can provide more technical and business (after all carriers need to pay for these features) evidences for the need of each model. Some other reasoning I heard includes that peer model can improve the IGP scalability in terms of the number of neighbors a router needs to peer with. But since large ISPs today seem to cope well with the IGP scalability today, I don't see why the problem will get significant worst when optical networks come into play. Regards, Angela BTW, the draft John Strand mentioned on the list earlier should be at http://search.ietf.org/internet-drafts/draft-chiu-strand-unique-olcp-00.txt with all lower cases. A new version will be out in a few weeks before the deadline since we are still working on a few details and editing. From owner-mpls@UU.NET Mon Oct 23 14:49:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02969 for ; Mon, 23 Oct 2000 14:49:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmel16900; Mon, 23 Oct 2000 18:48:03 GMT Received: by mail-control.mail.uu.net id QQjmel27310 for mpls-outgoing; Mon, 23 Oct 2000 18:47:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmel27291 for ; Mon, 23 Oct 2000 18:47:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmel13623 for ; Mon, 23 Oct 2000 18:47:29 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmel15901 for ; Mon, 23 Oct 2000 18:47:28 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27978 for ; Mon, 23 Oct 2000 11:47:27 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA15552 for mpls@uu.net; Mon, 23 Oct 2000 14:47:25 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmek26731 for ; Mon, 23 Oct 2000 18:44:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmek24322; Mon, 23 Oct 2000 18:44:44 GMT Received: from mail-blue.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjmek02533; Mon, 23 Oct 2000 18:44:44 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 14CE64CE4E; Mon, 23 Oct 2000 14:44:40 -0400 (EDT) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id OAA22966; Mon, 23 Oct 2000 14:44:35 -0400 (EDT) Reply-To: From: "John Strand" To: "'Zhi-Wei Lin'" , "'Sid Chaudhuri'" Cc: "'Kireeti Kompella'" , , , , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 14:44:00 -0400 Message-ID: <006401c03d21$43b8e620$3e82cf87@pcstranded.attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <39F46496.A0DE1F82@lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA02969 That you're describing is basically what the OIF Carrier Group included in our requirements document. Some snippets: From the assumptions: (6) Carriers will want to differentiate their services by defining their own "branded" bundles of functionality, service quality, support, and pricing plans. (7) The network is a prime asset for carriers. As such, a carrier will not relinquish control of its resources outside of its administrative boundaries. From the Objectives section: (3) Provide restoration, diverse routing, and other Quality of Service features within the control plane on a per-service-path basis. Per-circuit control of these capabilities is important because of the anticipated diversity of needs of the OL users. (8) Provide the ability for the carrier to control usage of its network resources. The carrier will control what network resources are available to individual services or users. Therefore, in the event of capacity shortages this ability will allow the carrier to ensure that critical and priority services get capacity. From the introduction to the restoration options discussion: We use "service level" to describe priority related characteristics of connections, such as holding priority, set-up priority, or restoration priority. The intent currently is to allow each carrier to define the actual service level in terms of priority, protection, and restoration options. Therefore, mapping of individual service levels to a specific set of priorities will be determined by individual carriers. Service levels are discussed in more detail as connection attributes in oif2000.061. John -----Original Message----- From: ip-optical-admin@lists.bell-labs.com [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Zhi-Wei Lin Sent: Monday, October 23, 2000 12:17 PM To: Sid Chaudhuri Cc: 'Kireeti Kompella'; xuyg@lucent.com; yxue@UU.NET; ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Hi Sid, And to generalize even further, if a service provider sets up three grades of service (e.g., bronze, gold, platinum), the protection information should already be embedded within those service grades. For example, bronze is no protection at all, gold is dynamic mesh restoration, and platinum is 1+1 protection. I think what is most important to a service provider and their customers are the availability of the connection, i.e., is the connection up 99.99% or 99.999% or some other number. How the service provider chooses to handle how to meet that availability number is up to the service provider and their TE. Am I mis-representing the service provider here? Maybe some service providers can comment on whether the above description sounds right??? Thanks Zhi Sid Chaudhuri wrote: > > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Based on its traffic flow a router only needs to know between > which > two routers it needs to establish a new lightpath. How the lightpath is > routed in the > optical layer seems to me irrelevant to TE. > > Sid Chaudhuri > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Mon Oct 23 14:50:25 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03255 for ; Mon, 23 Oct 2000 14:50:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmel19686; Mon, 23 Oct 2000 18:49:34 GMT Received: by mail-control.mail.uu.net id QQjmel27431 for mpls-outgoing; Mon, 23 Oct 2000 18:48:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmel27418 for ; Mon, 23 Oct 2000 18:48:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmel16293 for ; Mon, 23 Oct 2000 18:48:20 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmel17456 for ; Mon, 23 Oct 2000 18:48:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27812 for ; Mon, 23 Oct 2000 11:48:18 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA15548 for mpls@uu.net; Mon, 23 Oct 2000 14:47:13 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmek26443 for ; Mon, 23 Oct 2000 18:37:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmek00929; Mon, 23 Oct 2000 18:36:58 GMT Received: from kcmso1.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso1.att.com [192.128.133.69]) id QQjmek28601; Mon, 23 Oct 2000 18:36:58 GMT Received: from gab200r1.ems.att.com ([135.37.94.32]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id OAA20674; Mon, 23 Oct 2000 14:36:34 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id OAA20666; Mon, 23 Oct 2000 14:35:31 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 14:36:33 -0400 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F403240534@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Mark.Jones@mail.sprint.com'" , ip-optical@lists.bell-labs.com, mpls@UU.NET Cc: kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 14:36:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Following the ongoing discussions, I would like to add a couple of points. The optical network is essentially used to set-up facilities=circuits. This is done by having cross-connects set physical connections between appropriate ports. The actual flow of traffic or packets is transparent to the optical network. From a functional perspective this looks more like setting up a very, very fat modem pipe between two pieces of equipment using optical network facilities. So from this perspective I don't see why the peer model should be preferred over the client model. Furthermore, there are several standards documents co-authored by multiple carriers indicating the need to support a client model. The T1X1 version of requirements (ftp://ftp.t1.org/pub/t1x1/x1.0/0x100490.doc) which has been proposed as a USA contribution to the ITU-T for G.ason discusses needs such as support of third party signaling, support of multiple client naming schemes and connection scheduling. . The OIF Carrier Document is public as a T1X1 document going to the ITU-T (ftp://ftp.t1.org/pub/t1x1/x1.0/0x100510.doc) and it also discusses in some detail both requirements and the motivations behind them. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Mark.Jones@mail.sprint.com [mailto:Mark.Jones@mail.sprint.com] Sent: Monday, October 23, 2000 2:22 PM To: ip-optical@lists.bell-labs.com; mpls@UU.NET Cc: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh [I haven't had time to follow this entire thread, so please correct me if I'm off track with the discussion.] Zhi and Sid are correct. I have trouble seeing any kind of peering model fitting in a multi-client network like Sprints, so I come with that assumption. For an overlay or client model, the specification of protection types doesn't make sense across the UNI. We argued this point at the OIF in Barcelona. Carriers have their own schemes for providing the protection for services, and every implementation of the different architectures provide different results. What I mean is that a Sprint ring network, deployed over our fiber plant using equipment from vendor X, will give you different availability than a ring in another carrier's network using their fiber plant and vendor Y. That's just one example. The availability and BER are all a customer wants or needs. If I can give you 99.999% availability (or whatever availability you want to pay for) with a BER to satisfy your needs, why do you care whether I use ring, mesh, or some other scheme? Grade of service is sufficient. What is needed is standardization of the service grades, so Gold service is the same thing across every network (independent of the unlying protection architecture). Though I haven't followed the details, I seem to remember seeing work on this in another standards body. Mark Loyd Jones Sprint Technology Planning & Integration 913-534-5247 mark.jones@mail.sprint.com > -----Original Message----- > From: zwlin [mailto:zwlin@lucent.com] > Sent: Monday, October 23, 2000 11:17 AM > To: sc > Cc: zwlin; kireeti; xuyg; yxue; ip-optical; mpls > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > Hi Sid, > > And to generalize even further, if a service provider sets up three > grades of service (e.g., bronze, gold, platinum), the protection > information should already be embedded within those service > grades. For > example, bronze is no protection at all, gold is dynamic mesh > restoration, and platinum is 1+1 protection. > > I think what is most important to a service provider and > their customers > are the availability of the connection, i.e., is the connection up > 99.99% or 99.999% or some other number. How the service > provider chooses > to handle how to meet that availability number is up to the service > provider and their TE. > > Am I mis-representing the service provider here? Maybe some service > providers can comment on whether the above description sounds right??? > > Thanks > Zhi > > > Sid Chaudhuri wrote: > > > > I don't see why TE and protection require the routers to > specify explicit > > routes. > > The routers can simply specify to the optical layer what > type of optical > > layer protection > > it requires. Based on its traffic flow a router only needs > to know between > > which > > two routers it needs to establish a new lightpath. How the > lightpath is > > routed in the > > optical layer seems to me irrelevant to TE. > > > > Sid Chaudhuri > > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com From owner-mpls@UU.NET Mon Oct 23 14:51:24 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03486 for ; Mon, 23 Oct 2000 14:51:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmel10390; Mon, 23 Oct 2000 18:50:18 GMT Received: by mail-control.mail.uu.net id QQjmel27461 for mpls-outgoing; Mon, 23 Oct 2000 18:49:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmel27452 for ; Mon, 23 Oct 2000 18:49:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmel06860 for ; Mon, 23 Oct 2000 18:48:56 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjmel18579 for ; Mon, 23 Oct 2000 18:48:56 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA02736 for ; Mon, 23 Oct 2000 14:48:56 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA02728; Mon, 23 Oct 2000 14:48:56 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA20749; Mon, 23 Oct 2000 14:48:55 -0400 (EDT) Message-ID: <39F48816.C50D6EC9@lucent.com> Date: Mon, 23 Oct 2000 14:48:54 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella ttsburgh , hepstein@lucent.com CC: mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, Several ways to do: 1) A can request the first LSP to optical network (x-y), then request another one which different the first one (w-z, also with LSP ID of x-y to avoid). 2) A can send one request for two disjointed paths (x-y) and (w-z) together. The key point is whatever routers can do to optical network, optical switches can do by themselves (as easy as router can do). Why bother? Yangguang >Suppose router A wants to get to router B, and wants to take two >different ingress and egress points in the optical domain, X->Y >for the primary LSP, and W->Z for the backup. A does not require >optical protection for the X->Y path, nor for the W->Z path. A >*does* require that the X->Y path and the W->Z path do not share >common links. How is this to be done? >If A did the full path computation, this is simplicity itself. From owner-mpls@UU.NET Mon Oct 23 14:59:45 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05395 for ; Mon, 23 Oct 2000 14:59:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmel04233; Mon, 23 Oct 2000 18:58:17 GMT Received: by mail-control.mail.uu.net id QQjmel28705 for mpls-outgoing; Mon, 23 Oct 2000 18:57:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmel28698 for ; Mon, 23 Oct 2000 18:57:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmel00776; Mon, 23 Oct 2000 18:56:47 GMT Received: from alpha.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjmel01573; Mon, 23 Oct 2000 18:56:47 GMT Received: from mail1.tellium.com (mail1.tellium.com [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9NImv913717; Mon, 23 Oct 2000 14:48:58 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 14:52:28 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D02204042B9496@mail1.tellium.com> From: Sid Chaudhuri To: "'Jim Boyle'" Cc: "'Kireeti Kompella'" , xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 14:52:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The routers can't figure out the failure scenarios unless they know the SRGs within the optical layer. For example, consider three routers A, B, C each pair connected by an OC-48 via optical switches, two of which (AB and BC) may share part of the way the same conduit and hence may fail in a single event. Routers wouldn't know that unless we assume that each router connected to the optical layer receives the SRG information from the optical layer. It's possible to do that if we assume two things: (1) All routers and optical switches in a network share the same information - in other words peer model, (2) SRG can be defined in so many different ways - sharing same WDM, same fiber cable, same WDM, same conduit, same office. It's difficult for me to assume that standards can be erected to define this and passed to the routers. These are the types of things I would presume ISPs would inquire before connecting their routers to the optical layer service provider and then request via signaling the type of services (Gold, Silver, Bronze, etc.) they need. The ISPs would know based on the optical layer restoration, SRG implementation etc. what these service levels mean in terms of availability, protection switching time, etc. Setting up diverse routes within an optical layer which implements the concept of SRGs is really not so complex. Request by routers to provide diverse routes in the optical layer is already incorporated in the OIF UNI spec. Regards. Sid -----Original Message----- From: Jim Boyle [mailto:jboyle@Level3.com] Sent: Monday, October 23, 2000 2:09 PM To: Sid Chaudhuri Cc: 'Kireeti Kompella'; xuyg@lucent.com; yxue@UU.NET; ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh if the lambda's are unprotected (which is debatable), then the routers can communicate amongst themselves and decide what are the failure scenarios, and request more or less capacity based on that analysis. A complex alternative is to support things like: a) "setup these two circuits in a diverse manner" b) same as (a) but over different UNIs, in fact in different towns (e.g. setup nyc-sfo diverse from wdc-lax) c) "setup this circuit diverse from SRLG A,B,C" (which may be infeasible if the circuit which those SRLGs were derived from preclude a diverse route). As for path selection in general, a knowledge of the underlying topology is probably necessary for most optimal path selection when establishing lightpaths for non-direct traffic. This only makes sense in the 2001 timeframe to support one's ISP over one's optical network. An argument can be made that a good OSS makes a lot of this level of integration unnecessary. Inter-company is a whole other issue. regards, Jim On Mon, 23 Oct 2000, Sid Chaudhuri wrote: > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Based on its traffic flow a router only needs to know between > which > two routers it needs to establish a new lightpath. How the lightpath is > routed in the > optical layer seems to me irrelevant to TE. > > Sid Chaudhuri > > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > From owner-mpls@UU.NET Mon Oct 23 15:02:38 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06081 for ; Mon, 23 Oct 2000 15:02:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmem25133; Mon, 23 Oct 2000 19:00:44 GMT Received: by mail-control.mail.uu.net id QQjmem29151 for mpls-outgoing; Mon, 23 Oct 2000 19:00:03 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmel28758 for ; Mon, 23 Oct 2000 18:59:50 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmel27807 for ; Mon, 23 Oct 2000 18:59:29 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmel20374 for ; Mon, 23 Oct 2000 18:59:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA13419 for ; Mon, 23 Oct 2000 11:59:33 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA15707 for mpls@uu.net; Mon, 23 Oct 2000 14:59:26 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmel27475 for ; Mon, 23 Oct 2000 18:50:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmel20422; Mon, 23 Oct 2000 18:49:38 GMT Received: from almso1.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso1.att.com [192.128.167.69]) id QQjmel19864; Mon, 23 Oct 2000 18:49:38 GMT Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id OAA07142; Mon, 23 Oct 2000 14:49:37 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id OAA05234; Mon, 23 Oct 2000 14:48:26 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 14:49:27 -0400 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F403240535@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'darren.freeland@bt.com'" , zwlin@lucent.com, sc@tellium.com Cc: kireeti@juniper.net, xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 14:49:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk My 2c: when selling service, availability numbers are often used. On the other hand, there are multiple networking methods that can be used to deliver given availability numbers. The overall solution to providing network reliability is much more complex than simply deciding: it shall be rings, or it shall be mesh, or... The overall network will use a mix of protection and restoration techniques according to reliability of different network components, such as (but not limited to individual network elements expectations of failure rates) After careful consideration of all factors, a carrier will choose certain sets of protection and restoration mechanisms to be implemented in its network. So, the specifics of the mechanisms should not be negotiated over the UNI. However, the actual class of service (including availability numbers are negotiable). Then routing of a given circuit will follow routes as appropriate to meet the class of service. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: darren.freeland@bt.com [mailto:darren.freeland@bt.com] Sent: Monday, October 23, 2000 12:27 PM To: zwlin@lucent.com; sc@tellium.com Cc: kireeti@juniper.net; xuyg@lucent.com; yxue@UU.NET; ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Hi Zhi, Your description sounds fine. Note that we may also wish to offer shared protection and other protection options as well as your three examples though. Regards, Darren. -----Original Message----- From: Zhi-Wei Lin [mailto:zwlin@lucent.com] Sent: 23 October 2000 17:17 To: Sid Chaudhuri Cc: 'Kireeti Kompella'; xuyg@lucent.com; yxue@UU.NET; ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Hi Sid, And to generalize even further, if a service provider sets up three grades of service (e.g., bronze, gold, platinum), the protection information should already be embedded within those service grades. For example, bronze is no protection at all, gold is dynamic mesh restoration, and platinum is 1+1 protection. I think what is most important to a service provider and their customers are the availability of the connection, i.e., is the connection up 99.99% or 99.999% or some other number. How the service provider chooses to handle how to meet that availability number is up to the service provider and their TE. Am I mis-representing the service provider here? Maybe some service providers can comment on whether the above description sounds right??? Thanks Zhi Sid Chaudhuri wrote: > > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Based on its traffic flow a router only needs to know between > which > two routers it needs to establish a new lightpath. How the lightpath is > routed in the > optical layer seems to me irrelevant to TE. > > Sid Chaudhuri > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Mon Oct 23 15:21:13 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10190 for ; Mon, 23 Oct 2000 15:21:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmen26148; Mon, 23 Oct 2000 19:19:49 GMT Received: by mail-control.mail.uu.net id QQjmen12158 for mpls-outgoing; Mon, 23 Oct 2000 19:19:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmen12152 for ; Mon, 23 Oct 2000 19:19:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmen09403; Mon, 23 Oct 2000 19:19:15 GMT Received: from mail.disney.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.disney.com [204.128.192.15]) id QQjmen05022; Mon, 23 Oct 2000 19:19:15 GMT Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e9NJJER27233; Mon, 23 Oct 2000 12:19:14 -0700 (PDT) Received: from 1crp232.corp.disney.com by pain.corp.disney.com with ESMTP; Mon, 23 Oct 2000 12:19:48 -0700 Received: by 1crp232.corp.disney.com with Internet Mail Service (5.5.2651.58) id ; Mon, 23 Oct 2000 12:19:11 -0700 Message-Id: From: "Holmes, David A." To: Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET Cc: kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 12:18:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I have not been following this entire thread either, but as an Enterprise customer, I take issue with the following remarks: "... The availability and BER are all a customer wants or needs. If I can give you 99.999% availability (or whatever availability you want to pay for) with a BER to satisfy your needs, why do you care whether I use ring, mesh, or some other scheme? Grade of service is sufficient." In addition to availability, what is critical to this customer is reasonable circuit provisioning lead times. It is not uncommon to wait 6 months for a DS3 or higher speed circuit to be provisioned. The Sprints, MCIs, AT&Ts, etc. appear to believe that this is business as usual, and is acceptable to the customer. From the customer's standpoint, time is money. My understanding of the IP/MPLambdaS mesh model proposals, is that optical transport network circuit provisioning can be done in seconds. Fast provisioning is a necessary requirement in my view. David Holmes -----Original Message----- From: Mark.Jones@mail.sprint.com [mailto:Mark.Jones@mail.sprint.com] Sent: Monday, October 23, 2000 11:22 AM To: ip-optical@lists.bell-labs.com; mpls@UU.NET Cc: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh [I haven't had time to follow this entire thread, so please correct me if I'm off track with the discussion.] Zhi and Sid are correct. I have trouble seeing any kind of peering model fitting in a multi-client network like Sprints, so I come with that assumption. For an overlay or client model, the specification of protection types doesn't make sense across the UNI. We argued this point at the OIF in Barcelona. Carriers have their own schemes for providing the protection for services, and every implementation of the different architectures provide different results. What I mean is that a Sprint ring network, deployed over our fiber plant using equipment from vendor X, will give you different availability than a ring in another carrier's network using their fiber plant and vendor Y. That's just one example. The availability and BER are all a customer wants or needs. If I can give you 99.999% availability (or whatever availability you want to pay for) with a BER to satisfy your needs, why do you care whether I use ring, mesh, or some other scheme? Grade of service is sufficient. What is needed is standardization of the service grades, so Gold service is the same thing across every network (independent of the unlying protection architecture). Though I haven't followed the details, I seem to remember seeing work on this in another standards body. Mark Loyd Jones Sprint Technology Planning & Integration 913-534-5247 mark.jones@mail.sprint.com > -----Original Message----- > From: zwlin [mailto:zwlin@lucent.com] > Sent: Monday, October 23, 2000 11:17 AM > To: sc > Cc: zwlin; kireeti; xuyg; yxue; ip-optical; mpls > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > Hi Sid, > > And to generalize even further, if a service provider sets up three > grades of service (e.g., bronze, gold, platinum), the protection > information should already be embedded within those service > grades. For > example, bronze is no protection at all, gold is dynamic mesh > restoration, and platinum is 1+1 protection. > > I think what is most important to a service provider and > their customers > are the availability of the connection, i.e., is the connection up > 99.99% or 99.999% or some other number. How the service > provider chooses > to handle how to meet that availability number is up to the service > provider and their TE. > > Am I mis-representing the service provider here? Maybe some service > providers can comment on whether the above description sounds right??? > > Thanks > Zhi > > > Sid Chaudhuri wrote: > > > > I don't see why TE and protection require the routers to > specify explicit > > routes. > > The routers can simply specify to the optical layer what > type of optical > > layer protection > > it requires. Based on its traffic flow a router only needs > to know between > > which > > two routers it needs to establish a new lightpath. How the > lightpath is > > routed in the > > optical layer seems to me irrelevant to TE. > > > > Sid Chaudhuri > > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com From owner-mpls@UU.NET Mon Oct 23 15:27:39 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11611 for ; Mon, 23 Oct 2000 15:27:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmen14908; Mon, 23 Oct 2000 19:26:31 GMT Received: by mail-control.mail.uu.net id QQjmen12541 for mpls-outgoing; Mon, 23 Oct 2000 19:26:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmen12497 for ; Mon, 23 Oct 2000 19:25:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmen28336 for ; Mon, 23 Oct 2000 19:25:30 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjmen26476 for ; Mon, 23 Oct 2000 19:25:30 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA21166; Mon, 23 Oct 2000 12:25:28 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id MAA02262; Mon, 23 Oct 2000 12:25:28 -0700 (PDT) Date: Mon, 23 Oct 2000 12:25:28 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010231925.MAA02262@kummer.juniper.net> To: hepstein@lucent.com, kireeti@juniper.net, xuyg@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Yangguang, > Several ways to do: > 1) A can request the first LSP to optical network (x-y), then request another > one which different the first one (w-z, also with LSP ID of x-y to avoid). First of all, that means that signalling must include a mechanism for "avoid lsp-id x-y". Even if that is possible, how does w compute a path that avoids lsp x-y? There is no info in the IGP about LSP ids. Finally, it is much preferable to do the path computation in one step rather than two steps. Angela's approach works better: if the x->y LSP is announced as an FA with path info, and there was a mechanism to say "compute an LSP that avoids this path", then w has the info to compute the w-z LSP. However, this requires some extensions to the signalling protocol, and moreover, this is still a two-step approach. > 2) A can send one request for two disjointed paths (x-y) and (w-z) together. This is a better approach, except that there is no mechanism for this in signalling protocols. Also, two independent OXCs, x and w have to coordinate -- this idea doesn't scale very well. Or there is a third party for path computation, in which case, forget routers and switches computing paths; just do the TE offline. > The key point is whatever routers can do to optical network, optical switches > can do by themselves (as easy as router can do). Why bother? This is not a router vs. optical switch issue. The issue is that the *originator* of the LSP has all the info. The originator of the LSPs can do a full path computation, can do both paths simultaneously, has no coordination issues, no extensions to signalling or link state protocols. Kireeti. From owner-mpls@UU.NET Mon Oct 23 15:29:50 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12126 for ; Mon, 23 Oct 2000 15:29:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmen29010; Mon, 23 Oct 2000 19:27:15 GMT Received: by mail-control.mail.uu.net id QQjmen12644 for mpls-outgoing; Mon, 23 Oct 2000 19:26:43 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmen12635 for ; Mon, 23 Oct 2000 19:26:37 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmen00208; Mon, 23 Oct 2000 19:26:11 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjmen06436; Mon, 23 Oct 2000 19:26:11 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Mon, 23 Oct 2000 19:43:02 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <41BM90LX>; Mon, 23 Oct 2000 19:41:36 +0100 Message-ID: To: kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 19:40:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > Suppose router A wants to get to router B, and wants to take two > different ingress and egress points in the optical domain, X->Y > for the primary LSP, and W->Z for the backup. A does not require > optical protection for the X->Y path, nor for the W->Z path. A > *does* require that the X->Y path and the W->Z path do not share > common links. How is this to be done? > > If A did the full path computation, this is simplicity itself. > NH=> Kireeti, I don't this can be a general answer. The request (from whatever the client) is for two phyically disjoint paths between two points A and B. How the server delivers this request is not a function of the client. To fully answer the question also requires the duct network routing to be fully known....all availability is inherited from this layer since it is the bottom layer in the stack. But what if the client does not own the server layers, let alone the duct? (this is a layering problem). And what happens when two operators connect via an NNI? (this is a partitioning problem). Note - to fully satisfy the example you gave on a truly global case across all customers requires that the world only has 1 SP (assuming SPs would not want to share all their duct/server layer routing with everyone else, irrespective of the scalability issues this implies). I don't think this scenrario is likely however. The only consistent/generic model I see working here is that a client makes a request of the server and the server says whether this can be honoured. > > Based on its traffic flow a router only needs to know between > > which > > two routers it needs to establish a new lightpath. How the lightpath is > > routed in the > > optical layer seems to me irrelevant to TE. > > It's not up to you or me to say "irrelevant to TE"; the judge of > relevancy is the user (SP), and it depends very much on how > integrated the TE is between the optical domain and the routing > domain. I know several SPs that would like *in the long term* to > have a tightly integrated TE between the two domains; of course > the majority today prefer loose or no coupling, as that fits their > current mode of operation. > > From an analytical point of view, though, if you define TE as the > mapping of flows to physical links, then it seems to me that how > the lightpath is routed in the optical domain is very relevant. NH=> I don't describe TE like this....but I have to say this is predicated on today's (and the foreseeable) networks where I have to consider multiple client layers. TE to me has 3 time constants. Large (+ large BW quanta) -> physical duct/L1 build Medium (+ medium BW quanta) -> client layer topology built from server layer trails (ie "client layer link connections = server layer trails")......and this is the one I want to focus on wrt the OTN, ie move from slow management-plane trail provisioning to faster control-plane based trail provisioning (this would be a really good 1st step for now!). Small (+ small BW quanta) -> within layer bypass of some general constraint, like an IGP The latter 2 only buy time until you can do real TE via the first....assuming we are discussing a mismatch of observred traffic trends vs predicted (ie from forecasts) and not getting over some transient hump. From owner-mpls@UU.NET Mon Oct 23 15:29:52 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12165 for ; Mon, 23 Oct 2000 15:29:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmen17711; Mon, 23 Oct 2000 19:28:18 GMT Received: by mail-control.mail.uu.net id QQjmen12700 for mpls-outgoing; Mon, 23 Oct 2000 19:27:42 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmen12679 for ; Mon, 23 Oct 2000 19:27:32 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmen09007; Mon, 23 Oct 2000 19:25:23 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjmen13260; Mon, 23 Oct 2000 19:25:22 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA19826; Mon, 23 Oct 2000 15:25:22 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id PAA25327; Mon, 23 Oct 2000 15:09:43 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA26570; Mon, 23 Oct 2000 15:09:42 -0400 Message-ID: <39F48CDB.A0A5EB19@lucent.com> Date: Mon, 23 Oct 2000 15:09:15 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sid Chaudhuri CC: "'Jim Boyle'" , "'Kireeti Kompella'" , xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <0CD7D73C734BD411AEE100B0D02204042B9496@mail1.tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Sid, I agree with most of your points. I think they are very valid, and have been confirmed by several service providers. So this is good. One thing I'm not so sure about is your comment regarding setting up SRG being not so complex. I think you are right that specifying the use of such information is not complex. We only need to include that parameter! And I'm sure we can come up with a dis-joint algorithm for route determination that can take SRG into account. But, as John (Strand) mentioned, the complexity is trying to get the necessary information to come up with the SRG value in the first place. As John said, "Even for a single carrier, keeping track of the data required to construct an internal SRLG database is a formidable task" (John I hope I'm not mis-representing your quote! If I am forgive me!) Now if you consider sharing this with a client (the OIF uses the term user instead of client) network, and that the connection may traverse multiple carrier networks, getting the SRLG shared among all the participants is probably even more of a formidable task...even considering that including the parameter in a signaling protocol is a not-so formidable task... Zhi Sid Chaudhuri wrote: > > The routers can't figure out the failure scenarios unless they know the SRGs > within the optical layer. For example, consider three routers A, B, C each > pair connected by an OC-48 via optical switches, two of which (AB and BC) > may share part of the way the same conduit and hence may fail in a single > event. Routers wouldn't know that unless we assume that each router > connected to the optical layer receives the SRG information from the optical > layer. It's possible to do that if we assume two things: (1) All routers > and optical switches in a network share the same information - in other > words peer model, (2) SRG can be defined in so many different ways - sharing > same WDM, same fiber cable, same WDM, same conduit, same office. It's > difficult for me to assume that standards can be erected to define this and > passed to the routers. These are the types of things I would presume ISPs > would inquire before connecting their routers to the optical layer service > provider and then request via signaling the type of services (Gold, Silver, > Bronze, etc.) they need. The ISPs would know based on the optical layer > restoration, SRG implementation etc. what these service levels mean in terms > of availability, protection switching time, etc. > > Setting up diverse routes within an optical layer which implements the > concept of SRGs is really not so complex. Request by routers to provide > diverse routes in the optical layer is already incorporated in the OIF UNI > spec. > > Regards. > > Sid > > -----Original Message----- > From: Jim Boyle [mailto:jboyle@Level3.com] > Sent: Monday, October 23, 2000 2:09 PM > To: Sid Chaudhuri > Cc: 'Kireeti Kompella'; xuyg@lucent.com; yxue@UU.NET; > ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: RE: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > if the lambda's are unprotected (which is debatable), then > the routers can > communicate amongst themselves and decide what are the > failure scenarios, > and request more or less capacity based on that analysis. > > A complex alternative is to support things like: > > a) "setup these two circuits in a diverse manner" > b) same as (a) but over different UNIs, in fact in different > towns > (e.g. setup nyc-sfo diverse from wdc-lax) > c) "setup this circuit diverse from SRLG A,B,C" (which may > be infeasible > if the circuit which those SRLGs were derived from preclude > a diverse > route). > > As for path selection in general, a knowledge of the > underlying topology > is probably necessary for most optimal path selection when > establishing > lightpaths for non-direct traffic. > > This only makes sense in the 2001 timeframe to support one's > ISP over > one's optical network. An argument can be made that a good > OSS makes a > lot of this level of integration unnecessary. Inter-company > is a whole > other issue. > > regards, > > Jim > > On Mon, 23 Oct 2000, Sid Chaudhuri wrote: > > > I don't see why TE and protection require the routers to > specify explicit > > routes. > > The routers can simply specify to the optical layer what > type of optical > > layer protection > > it requires. Based on its traffic flow a router only > needs to know between > > which > > two routers it needs to establish a new lightpath. How > the lightpath is > > routed in the > > optical layer seems to me irrelevant to TE. > > > > Sid Chaudhuri > > > > > > -----Original Message----- > > From: Kireeti Kompella > [mailto:kireeti@juniper.net] > > Sent: Monday, October 23, 2000 11:43 AM > > To: xuyg@lucent.com; yxue@UU.NET > > Cc: ip-optical@lists.bell-labs.com; > mpls@UU.NET > > Subject: Re: [IP-Optical] RE: Optical > link bundling. > > Was Re: DraftMinutes From Pittsburgh > > > > Hi, > > > > > > (router determines the explicit routes). > > > > > > > This point has been raised by several > folks. It really > > confuses me. If the > > > optical switches are equipped with path > calculation > > ability, what's the benefit > > > to bother router to determine the explicit > routes within > > optical domain > > > (assuming router can be smart enough to > handle all optical > > network specific > > > attributes and constrains) than just have > routers to > > determine the end points of > > > optical trails. > > > > Why does this confuse you? Routers may want > to determine > > the exact > > path that their LSPs take for a number of > reasons, including > > TE and > > protection. If a router doesn't care where > its LSPs are > > laid out, > > it can install loose hops at the boundaries > of the optical > > cloud. > > > > Kireeti. > > -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com From owner-mpls@UU.NET Mon Oct 23 15:40:14 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14279 for ; Mon, 23 Oct 2000 15:40:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmeo03556; Mon, 23 Oct 2000 19:39:36 GMT Received: by mail-control.mail.uu.net id QQjmeo13513 for mpls-outgoing; Mon, 23 Oct 2000 19:39:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmeo13508 for ; Mon, 23 Oct 2000 19:39:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmeo20462 for ; Mon, 23 Oct 2000 19:38:07 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmeo01433 for ; Mon, 23 Oct 2000 19:38:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA25367 for mpls@uu.net; Mon, 23 Oct 2000 15:38:05 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmeo13326 for ; Mon, 23 Oct 2000 19:37:33 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmeo20684; Mon, 23 Oct 2000 19:34:51 GMT Received: from mail-blue.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjmeo21046; Mon, 23 Oct 2000 19:34:50 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 853E74CE20; Mon, 23 Oct 2000 15:34:50 -0400 (EDT) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA24953; Mon, 23 Oct 2000 15:34:45 -0400 (EDT) Reply-To: From: "John Strand" To: "'Kireeti Kompella'" , , , Cc: , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 15:34:35 -0400 Message-ID: <007b01c03d28$47950ab0$3e82cf87@pcstranded.attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200010231758.KAA01526@kummer.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA14279 Kireeti, What's needed is a way for you to ask for a lightpath that's physically diverse from one or more other lightpaths, whether or not the other lightpaths have the same terminals as the new lightpath. This is done routinely at DS3 and (I think) OC-n levels today by PL services like AT&T's EDRO (Enhanced Diversity Routing Option). There are 2 general options: (1) If all the circuits are new, they can be routed simultaneously. This is an NP-complete problem and probably would have to be done in the management plane. This is essentially the EDRO approach. (2) To do dynamically (real time) a pragmatic approach would be to request the circuits sequentially, one at a time, with each request including a requirement that it be diverse from the previously routed ones. This ought to be easy to implement algorithmically but won't always work (give diverse paths). The problem cases would come if (in your example) X and W are close together (same metro), and Y and Z are also, and the 2 metros are far apart. Then the 1st lightpath routed might inadvertently mess up routing options for the 2nd. The heuristics to simultaneously route a number of circuits simultaneously subject to diversity constraints essentially require zillions of calls to a Dijkstra algorithm and so don't seem to lend themselves to incorporation in the control plane. (Am I being too pessimistic?) This however is not just an Optical Layer problem - the IP layer would have the same computation to do. I'd be interested in hearing more about the drivers for your example. I would expect that if you want physical diversity you are setting up lightpaths that are going to be around for a while. If this is the case would it be OK to take a little longer (but < 1 minute) to do the provisioning? If so simultaneous routing ought to be possible. I'd be interested in hearing from control plane developers their reactions to incorporating an algorithm requiring (say) 10**2 calls to a Dijkstra algorithm on a large (10**3 node) network. There's a book by Ramesh Bhandari that addresses some of the algorithm issues. I don't believe that the heuristics used for services like EDRO are in the public domain though. I have a long-standing interest in these algorithms (I did the ones used in EDRO) and would be most interested in hearing from people working in this area. John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: ip-optical-admin@lists.bell-labs.com [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Kireeti Kompella Sent: Monday, October 23, 2000 1:58 PM To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Suppose router A wants to get to router B, and wants to take two different ingress and egress points in the optical domain, X->Y for the primary LSP, and W->Z for the backup. A does not require optical protection for the X->Y path, nor for the W->Z path. A *does* require that the X->Y path and the W->Z path do not share common links. How is this to be done? If A did the full path computation, this is simplicity itself. > Based on its traffic flow a router only needs to know between > which > two routers it needs to establish a new lightpath. How the lightpath is > routed in the > optical layer seems to me irrelevant to TE. It's not up to you or me to say "irrelevant to TE"; the judge of relevancy is the user (SP), and it depends very much on how integrated the TE is between the optical domain and the routing domain. I know several SPs that would like *in the long term* to have a tightly integrated TE between the two domains; of course the majority today prefer loose or no coupling, as that fits their current mode of operation. >From an analytical point of view, though, if you define TE as the mapping of flows to physical links, then it seems to me that how the lightpath is routed in the optical domain is very relevant. Kireeti. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Mon Oct 23 15:42:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14587 for ; Mon, 23 Oct 2000 15:42:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmeo03243; Mon, 23 Oct 2000 19:41:56 GMT Received: by mail-control.mail.uu.net id QQjmeo13611 for mpls-outgoing; Mon, 23 Oct 2000 19:41:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmeo13594 for ; Mon, 23 Oct 2000 19:41:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmeo14477; Mon, 23 Oct 2000 19:40:36 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjmeo00827; Mon, 23 Oct 2000 19:40:35 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA22495; Mon, 23 Oct 2000 12:40:35 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id MAA02335; Mon, 23 Oct 2000 12:40:35 -0700 (PDT) Date: Mon, 23 Oct 2000 12:40:35 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010231940.MAA02335@kummer.juniper.net> To: kireeti@juniper.net, neil.2.harrison@bt.com, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk > > Suppose router A wants to get to router B, and wants to take two > > different ingress and egress points in the optical domain, X->Y > > for the primary LSP, and W->Z for the backup. A does not require > > optical protection for the X->Y path, nor for the W->Z path. A > > *does* require that the X->Y path and the W->Z path do not share > > common links. How is this to be done? > > > > If A did the full path computation, this is simplicity itself. > > > NH=> Kireeti, I don't this can be a general answer. The request > (from whatever the client) is for two phyically disjoint paths between two > points A and B. Neil, A *is* the client. And A wants two disjoint paths to B via *different ingress points in the OTN*. This is a very reasonable request. Also, A doing a full path computation is *not* a general answer. It is an illustration of an advantage of the peer model, and of routers doing a full path computation across the OTN. To achieve what A wants in an overlay/client/UNI model would require a fair amount of work in extending routing/signalling/UNI protocols. Kireeti. From owner-mpls@UU.NET Mon Oct 23 15:52:46 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15749 for ; Mon, 23 Oct 2000 15:52:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmep03441; Mon, 23 Oct 2000 19:52:02 GMT Received: by mail-control.mail.uu.net id QQjmep14377 for mpls-outgoing; Mon, 23 Oct 2000 19:51:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmep14352 for ; Mon, 23 Oct 2000 19:51:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmep15339 for ; Mon, 23 Oct 2000 19:51:17 GMT Received: from hoemlsrv.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQjmep02242 for ; Mon, 23 Oct 2000 19:51:17 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA05015 for ; Mon, 23 Oct 2000 15:51:16 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA05009; Mon, 23 Oct 2000 15:51:16 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA03610; Mon, 23 Oct 2000 15:51:15 -0400 (EDT) Message-ID: <39F496B3.74F75E0E@lucent.com> Date: Mon, 23 Oct 2000 15:51:15 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <200010231925.MAA02262@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, > First of all, that means that signalling must include a mechanism > for "avoid lsp-id x-y". Even if that is possible, how does w > compute a path that avoids lsp x-y? There is no info in the IGP > about LSP ids. Finally, it is much preferable to do the path > computation in one step rather than two steps. > > Angela's approach works better: if the x->y LSP is announced as an > FA with path info, and there was a mechanism to say "compute an LSP > that avoids this path", then w has the info to compute the w-z LSP. > However, this requires some extensions to the signalling protocol, > and moreover, this is still a two-step approach. > After optical network create a LSP x-y, LSP source node x (in optical domain) will maintain the LSP path information. New path w-z source node w can query x for path LSP x-y ER hop list info and run explicit routing to avoid LSP x-y. IGP maintain topology information. It doesn't need to know which LSP use which topology. LSP information is maintain separately from topology information. LSP w-z is created with the "constrain" saying avoid LSP x-y. Please refer to "Path selection section" of the document I sent to you for details. > > 2) A can send one request for two disjointed paths (x-y) and (w-z) together. > > This is a better approach, except that there is no mechanism for > this in signalling protocols. Also, two independent OXCs, x and > w have to coordinate -- this idea doesn't scale very well. Or > there is a third party for path computation, in which case, forget > routers and switches computing paths; just do the TE offline. Because it's one request, the OXC who receives the request for (example x) can perform explicit routing for both paths, then using MPLS signaling to set up these two paths (it has to notify W with ER hop lists). No scalability problem, no need for co-ordination at all. > > > The key point is whatever routers can do to optical network, optical switches > > can do by themselves (as easy as router can do). Why bother? > > This is not a router vs. optical switch issue. The issue is > that the *originator* of the LSP has all the info. The originator > of the LSPs can do a full path computation, can do both paths > simultaneously, has no coordination issues, no extensions to > signalling or link state protocols. > Using the second solution I mention above, it's as simple as have router do it. Yet, it applies to all business models. The solution you mentioned only works for certain service provider. > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Mon Oct 23 16:09:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17698 for ; Mon, 23 Oct 2000 16:09:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmeq26913; Mon, 23 Oct 2000 20:08:59 GMT Received: by mail-control.mail.uu.net id QQjmeq27469 for mpls-outgoing; Mon, 23 Oct 2000 20:08:25 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmeq27464 for ; Mon, 23 Oct 2000 20:08:22 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmeq18391; Mon, 23 Oct 2000 20:08:01 GMT Received: from hoemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQjmeq25489; Mon, 23 Oct 2000 20:08:00 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA29929; Mon, 23 Oct 2000 16:08:00 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id QAA29908; Mon, 23 Oct 2000 16:07:59 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA00782; Mon, 23 Oct 2000 16:07:59 -0400 Message-ID: <39F49A84.1FB71267@lucent.com> Date: Mon, 23 Oct 2000 16:07:32 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: neil.2.harrison@bt.com, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <200010231940.MAA02335@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Maybe I can set up a scenario where we can see how these routings work. Let's take an example where we have a service provider XYZ serving the NY metro area. Let's also assume that the offered service is the switched optical service. Let's also assume that XYZ has several customers such as Citibank, JPMorgan, Turner Cable, Verizon. 1. Citibank wants to set up a connection between its NYC office and its Atlanta office. In order to reach Atlanta, service provider XYZ may need to connect with a secondary (intermediate) service provider ABC for connectivity. 2. And let's say Citibank wants to be able to specify the explicit route. That means the Citibank router doing the path computation needs to know how the nodes are connected, the resources available at the node, and probably other information such as the SRGs of these links. Not only that, but it also needs to know the inner topology (and other) details of the ABC network to do explicit routing. 3. This means that if other XYZ and ABC customers want explicit routing, they would also be provided to them (let's say they are all IP over optical via the POS or the new GFP mapping). ==> Given this example, how realistic is it (from both a customer expectation and carrier expectation) to share the type of information needed to allow the client router to perform explicit routing? ==> What about the seemingly need to share information across carriers into customers? I think this is not a question of whether the vendors can build this type of box and the mechanisms to support this (clearly vendors can build whatever customer want -- the issue is what is the customer getting for the price), but the question really is: ==> How comfortable are carriers in giving this information out, and how comfortable are customers (especially financial institutions that may have qualms about their resource use being visible by other customers) in sharing their network use with other customers. Again, I don't think this is a question for vendors, but more for carriers. Vendors of course can have our own opinions and we can offer what our customer tell us, but let's allow the carriers to formulate their opinion first and follow what they have to say instead of simply hand-waving and say "this is what our customers want". Zhi Kireeti Kompella wrote: > > > > Suppose router A wants to get to router B, and wants to take two > > > different ingress and egress points in the optical domain, X->Y > > > for the primary LSP, and W->Z for the backup. A does not require > > > optical protection for the X->Y path, nor for the W->Z path. A > > > *does* require that the X->Y path and the W->Z path do not share > > > common links. How is this to be done? > > > > > > If A did the full path computation, this is simplicity itself. > > > > > NH=> Kireeti, I don't this can be a general answer. The request > > (from whatever the client) is for two phyically disjoint paths between two > > points A and B. > > Neil, A *is* the client. And A wants two disjoint paths to B via > *different ingress points in the OTN*. This is a very reasonable > request. > > Also, A doing a full path computation is *not* a general answer. > It is an illustration of an advantage of the peer model, and of > routers doing a full path computation across the OTN. To achieve > what A wants in an overlay/client/UNI model would require a fair > amount of work in extending routing/signalling/UNI protocols. > > Kireeti. -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com From owner-mpls@UU.NET Mon Oct 23 16:26:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19601 for ; Mon, 23 Oct 2000 16:26:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmer19436; Mon, 23 Oct 2000 20:25:30 GMT Received: by mail-control.mail.uu.net id QQjmer00473 for mpls-outgoing; Mon, 23 Oct 2000 20:25:05 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmer00453 for ; Mon, 23 Oct 2000 20:25:00 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmer16384 for ; Mon, 23 Oct 2000 20:24:59 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjmer14822 for ; Mon, 23 Oct 2000 20:24:58 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA25966; Mon, 23 Oct 2000 13:24:58 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id NAA02482; Mon, 23 Oct 2000 13:24:57 -0700 (PDT) Date: Mon, 23 Oct 2000 13:24:57 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010232024.NAA02482@kummer.juniper.net> To: jls@research.att.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi John, > What's needed is a way for you to ask for a lightpath that's physically > diverse from one or more other lightpaths, whether or not the other > lightpaths have the same terminals as the new lightpath. Yes, that is correct. > This is done > routinely at DS3 and (I think) OC-n levels today by PL services like > AT&T's EDRO (Enhanced Diversity Routing Option). Are you (or others) proposing the mechanisms to do this in the UNI/GMPLS framework? > The heuristics to simultaneously route a number of circuits simultaneously > subject to diversity constraints essentially require zillions of calls > to a Dijkstra algorithm and so don't seem to lend themselves to incorporation > in the control plane. In the IP world, I see the use for simultaneous set up of a small number of disjoint paths, basically, a primary and one or more backups for an LSP. So, this may not be an issue. What is the requirement driving having lots of simultaneous diverse paths in the telephony world? > I'd be interested in hearing more about the drivers for your example. I would > expect that if you want physical diversity you are setting up lightpaths that > are going to be around for a while. Yes, but as I said above, I visualize lots of LSPs, each requiring two or three diverse paths, not hundreds of diverse paths. So, this should not be an issue. > There's a book by Ramesh Bhandari that addresses some of the algorithm issues. > I don't believe that the heuristics used for services like EDRO are in the > public domain though. More's the pity :-) Kireeti. PS. BTW, your mail replies are MIME encoded, even when they are simple ASCII. From owner-mpls@UU.NET Mon Oct 23 16:26:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19627 for ; Mon, 23 Oct 2000 16:26:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmer06359; Mon, 23 Oct 2000 20:25:26 GMT Received: by mail-control.mail.uu.net id QQjmer00440 for mpls-outgoing; Mon, 23 Oct 2000 20:24:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmer00419 for ; Mon, 23 Oct 2000 20:24:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmer12845 for ; Mon, 23 Oct 2000 20:24:31 GMT Received: from asc_exch.asc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: outlook.asc.com [63.82.128.45]) id QQjmer14167 for ; Mon, 23 Oct 2000 20:24:30 GMT Received: by ASC_EXCH with Internet Mail Service (5.5.2650.21) id <47Q0JGFS>; Mon, 23 Oct 2000 16:17:52 -0400 Message-ID: <47B932CAF145D411B91700B0D04931BD29A9DB@ASC_EXCH> From: Noel Wasson To: "'mpls@UU.NET'" Subject: Remove Me Date: Mon, 23 Oct 2000 16:17:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D2E.526A6BF0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03D2E.526A6BF0 Content-Type: text/plain; charset="iso-8859-1" List Removal ------_=_NextPart_001_01C03D2E.526A6BF0 Content-Type: text/html; charset="iso-8859-1" Remove Me

List Removal

------_=_NextPart_001_01C03D2E.526A6BF0-- From owner-mpls@UU.NET Mon Oct 23 17:11:23 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24905 for ; Mon, 23 Oct 2000 17:11:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmeu26615; Mon, 23 Oct 2000 21:10:15 GMT Received: by mail-control.mail.uu.net id QQjmeu16095 for mpls-outgoing; Mon, 23 Oct 2000 21:09:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmeu15991 for ; Mon, 23 Oct 2000 21:09:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmeu08035 for ; Mon, 23 Oct 2000 21:08:15 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmeu19189 for ; Mon, 23 Oct 2000 21:08:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA11575 for mpls@uu.net; Mon, 23 Oct 2000 17:08:13 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmeu15921 for ; Mon, 23 Oct 2000 21:07:42 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmeu05068; Mon, 23 Oct 2000 21:06:38 GMT Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjmeu16572; Mon, 23 Oct 2000 21:06:38 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 061DE4CE14; Mon, 23 Oct 2000 17:06:35 -0400 (EDT) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id RAA28030; Mon, 23 Oct 2000 17:06:30 -0400 (EDT) Reply-To: From: "John Strand" To: "'Zhi-Wei Lin'" , "'Kireeti Kompella'" Cc: , , , , , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 17:06:19 -0400 Message-ID: <008d01c03d35$185ef050$3e82cf87@pcstranded.attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <39F49A84.1FB71267@lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id RAA24905 Zhi, Before complicating the problem by inserting the XYZ and ABC service provider, consider the problem where one of the customers you mentioned has direct connectivity to a backbone optical network. In this case I think the Carrier Requirements document discusses a couple of specific options: For a major customer, perhaps an OVPN (see my previous Email for a high-level business model of this) with information sharing about the resources the customer has contracted for and customer control of them. When you introduce XYZ and ABC, things get much more difficult: (1) As I mentioned in an earlier Email there is no mechanism now being contemplated that would allow the definition of SRLG's across carriers, so Citibank or whoever would not be able to get the information needed to do diverse routing - the carriers just don't have it to give. (2) There is not yet any work underway on interdomain protocols that I'm aware of in the OIF, ITU, or IETF. (I just got some stuff from Canarie in Canada, but I haven't looked at it yet.) (3) For Citibank (say) to get the information needed about XYZ, ABC, and the backbone optical network(s) presumably all of these optical network providers would end up sharing not only topology information but information on spare capacity with each other as well as with citibank. I don't know much about Internet peering, but there doesn't seem to be a whole lot of topology information shared between ISP's now. It's hard for me to see why optical network providers are going to be any more trusting than ISP's are. (4) There also will presumably be peering relationships between optical networks that will constrain Citbank's routing options. For example, what if XYZ and ABC don't have an arrangement for splitting revenues? John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: ip-optical-admin@lists.bell-labs.com [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Zhi-Wei Lin Sent: Monday, October 23, 2000 4:08 PM To: Kireeti Kompella Cc: neil.2.harrison@bt.com; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Hi, Maybe I can set up a scenario where we can see how these routings work. Let's take an example where we have a service provider XYZ serving the NY metro area. Let's also assume that the offered service is the switched optical service. Let's also assume that XYZ has several customers such as Citibank, JPMorgan, Turner Cable, Verizon. 1. Citibank wants to set up a connection between its NYC office and its Atlanta office. In order to reach Atlanta, service provider XYZ may need to connect with a secondary (intermediate) service provider ABC for connectivity. 2. And let's say Citibank wants to be able to specify the explicit route. That means the Citibank router doing the path computation needs to know how the nodes are connected, the resources available at the node, and probably other information such as the SRGs of these links. Not only that, but it also needs to know the inner topology (and other) details of the ABC network to do explicit routing. 3. This means that if other XYZ and ABC customers want explicit routing, they would also be provided to them (let's say they are all IP over optical via the POS or the new GFP mapping). ==> Given this example, how realistic is it (from both a customer expectation and carrier expectation) to share the type of information needed to allow the client router to perform explicit routing? ==> What about the seemingly need to share information across carriers into customers? I think this is not a question of whether the vendors can build this type of box and the mechanisms to support this (clearly vendors can build whatever customer want -- the issue is what is the customer getting for the price), but the question really is: ==> How comfortable are carriers in giving this information out, and how comfortable are customers (especially financial institutions that may have qualms about their resource use being visible by other customers) in sharing their network use with other customers. Again, I don't think this is a question for vendors, but more for carriers. Vendors of course can have our own opinions and we can offer what our customer tell us, but let's allow the carriers to formulate their opinion first and follow what they have to say instead of simply hand-waving and say "this is what our customers want". Zhi Kireeti Kompella wrote: > > > > Suppose router A wants to get to router B, and wants to take two > > > different ingress and egress points in the optical domain, X->Y > > > for the primary LSP, and W->Z for the backup. A does not require > > > optical protection for the X->Y path, nor for the W->Z path. A > > > *does* require that the X->Y path and the W->Z path do not share > > > common links. How is this to be done? > > > > > > If A did the full path computation, this is simplicity itself. > > > > > NH=> Kireeti, I don't this can be a general answer. The request > > (from whatever the client) is for two phyically disjoint paths between two > > points A and B. > > Neil, A *is* the client. And A wants two disjoint paths to B via > *different ingress points in the OTN*. This is a very reasonable > request. > > Also, A doing a full path computation is *not* a general answer. > It is an illustration of an advantage of the peer model, and of > routers doing a full path computation across the OTN. To achieve > what A wants in an overlay/client/UNI model would require a fair > amount of work in extending routing/signalling/UNI protocols. > > Kireeti. -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Mon Oct 23 17:11:26 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24928 for ; Mon, 23 Oct 2000 17:11:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmeu07391; Mon, 23 Oct 2000 21:10:21 GMT Received: by mail-control.mail.uu.net id QQjmeu16122 for mpls-outgoing; Mon, 23 Oct 2000 21:09:51 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmeu16105 for ; Mon, 23 Oct 2000 21:09:46 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmeu24265; Mon, 23 Oct 2000 21:07:02 GMT Received: from caemsbridge.opticworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.108.172.129]) id QQjmeu22062; Mon, 23 Oct 2000 21:07:01 GMT Received: by caemsbridge.opticworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 14:07:04 -0700 Message-ID: <5325CE3D64E3D31184B1009027DDD26F0272B106@caems1.opticworks.com> From: Anil Rao To: "'neil.2.harrison@bt.com'" , kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 14:06:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D35.31AD61C2" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03D35.31AD61C2 Content-Type: text/plain; charset="iso-8859-1" Neil/Kireeti, > Note - to fully satisfy the example > you gave on a > truly global case across all customers requires that the > world only has 1 SP > (assuming SPs would not want to share all their duct/server > layer routing > with everyone else, irrespective of the scalability issues > this implies). I > don't think this scenrario is likely however. > > The only consistent/generic model I see working here is that a > client makes a request of the server and the server says > whether this can be > honoured. I think there is value to both the models. There are various carriers and service providers who want to run both the client and server with a well distributed information model(in which the client understands the shortcomings of the server) and also in a client/server model where the client requests the server for services. The gmpls model should support both. In one model, as Neil pointed out information will not be available for an explicit route object while in the other case information will be available for explicit route object. -anil. ------_=_NextPart_001_01C03D35.31AD61C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes = From Pittsburgh

Neil/Kireeti,

> Note - to fully satisfy the example
> you gave on a
> truly global case across all customers requires = that the
> world only has 1 SP
> (assuming SPs would not want to share all their = duct/server
> layer routing
> with everyone else, irrespective of the = scalability issues
> this implies).  I
> don't think this scenrario is likely = however.
>
>       The only = consistent/generic model I see working here is that a
> client makes a request of the server and the = server says
> whether this can be
> honoured.

I think there is value to both the models.  = There are various carriers and service providers who want to run both = the client and server with a well distributed information model(in = which the client understands the shortcomings of the server) and also = in a client/server model where the client requests the server for = services. 

The gmpls model should support both.  In one = model, as Neil pointed out information will not be available for an = explicit route object while in the other case information will be = available for explicit route object.

-anil.

------_=_NextPart_001_01C03D35.31AD61C2-- From owner-mpls@UU.NET Mon Oct 23 17:42:12 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28486 for ; Mon, 23 Oct 2000 17:42:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmew14218; Mon, 23 Oct 2000 21:41:06 GMT Received: by mail-control.mail.uu.net id QQjmew18279 for mpls-outgoing; Mon, 23 Oct 2000 21:40:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmew18272 for ; Mon, 23 Oct 2000 21:40:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmew14531 for ; Mon, 23 Oct 2000 21:40:09 GMT Received: from zrtps06s.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQjmew12610 for ; Mon, 23 Oct 2000 21:40:08 GMT Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 23 Oct 2000 17:30:46 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRFPCW>; Mon, 23 Oct 2000 17:30:44 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4029F98D3@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Adrian Farrel'" , "'mpls@UU.NET'" Cc: "'lberger@labn.net'" Subject: RE: draft-ietf-mpls-generalized-signaling-00.txt Date: Mon, 23 Oct 2000 17:30:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D38.7D738700" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03D38.7D738700 Content-Type: text/plain; charset="iso-8859-1" I had little to do with it. The credit goes to Lou. I just read it a few times. Thanks Lou, Peter -----Original Message----- From: Adrian Farrel [SMTP:AF@dataconnection.com] Sent: Monday, October 23, 2000 2:11 PM To: mpls@UU.NET Cc: lberger@labn.net; Ashwood-Smith, Peter [CAR:CS0I:EXCH] Subject: draft-ietf-mpls-generalized-signaling-00.txt Lou and Peter, Thanks for a great job editing this and for getting it out into the public domain. I have a large block of comments and questions and bunch of minor typos. Please feel free to split the comments into separate threads if you like. Regards, Adrian Questions ========= Link Id and Explicit Routing I'm not sure how much this should be in Kireeti's bundling draft and how much in the Generalized draft. I have the following concern: - Suppose we use LSR addresses (i.e. not link addresses) in our explicit route and also use label sub-objects. Suppose further that there are multiple links of different types between a pair of LSRs. Finally consider that Label_Request is used, not Generalized_Label_Request. How does the LSR processing the ERO interpret the label and decide which link to apply it to? I guess you could say that you should avoid the combination of circumstances listed above and use G_L_R to constrain the link type or use the link address not the LSR address. Does that still work with unnumbered links? Error values etc. Can I suggest adding a section at the end as a place holder for new error values. In the text I have found - Routing Problem/Unsupported Encoding - Routing Problem/Unsupported Link Protection - Routing Problem/Unsupported GPID - Routing Problem/Unacceptable Label Value - Routing Problem/Label Set 3. Generalized Label Request Could you make it clearer right at the top of section 3 that for RSVP the Generalized_Label_Request is not a new object but a new variant of the Label_Request Object, whereas for CR-LDP it is a new TLV. 3.3.1 Waveband Switching "For compatibility reasons, a new RSVP c-type and CR- LDP type is assigned for the Waveband Label." This seems to be the only place in the draft where you haven't explicitly suggested values (subject to IANA). I think you have left gaps for RSVP c-type 3 and CR-LDP type 903. 3.5.1 Label Set It isn't clear how a sequence of subchannels that form a label set are conveyed. It can't be the case that you simply add multiple Subchannels to the Object/TLV since the Type is closely associated with each individual Subchannel. We should either define Label_Set as Explicit_Route with a sequence of subobjects. Or we should allow a series of Label_Sets in the Path/LABEL_REQUEST. In either case, it would be good to put in some motherhood about ordering the elements for clear interpretation. For example, suppose x RE: draft-ietf-mpls-generalized-signaling-00.txt

I had little to do with it. The credit = goes to Lou. I just read it a few times.

Thanks Lou,

Peter

    -----Original = Message-----
    From:   Adrian Farrel = [SMTP:AF@dataconnection.com]
    Sent:   Monday, October 23, 2000 2:11 PM
    To:     mpls@UU.NET
    Cc:     lberger@labn.net; Ashwood-Smith, Peter = [CAR:CS0I:EXCH]
    Subject:       = draft-ietf-mpls-generalized-signaling-00.txt

    Lou and Peter,

    Thanks for a great job editing this = and for getting it out into the public
    domain.

    I have a large block of comments and = questions and bunch of minor typos.
    Please feel free to split the = comments into separate threads if you like.

    Regards,
    Adrian

    Questions
    =3D=3D=3D=3D=3D=3D=3D=3D=3D

    Link Id and Explicit Routing
    I'm not sure how much this should be = in Kireeti's bundling draft
    and how much in the Generalized = draft.  I have the following
    concern:

    - Suppose we use LSR addresses (i.e. = not link addresses) in our
      explicit route and also use = label sub-objects.  Suppose further
      that there are multiple links = of different types between a pair
      of LSRs.  Finally = consider that Label_Request is used, not
      = Generalized_Label_Request.
      How does the LSR processing = the ERO interpret the label and
      decide which link to apply it = to?
      I guess you could say that you = should avoid the combination of
      circumstances listed above and = use G_L_R to constrain the link
      type or use the link address = not the LSR address.  Does that
      still work with unnumbered = links?
     

    Error values etc.
    Can I suggest adding a section at the = end as a place holder for new error
    values.
    In the text I have found
    - Routing Problem/Unsupported = Encoding
    - Routing Problem/Unsupported Link = Protection
    - Routing Problem/Unsupported = GPID
    - Routing Problem/Unacceptable Label = Value
    - Routing Problem/Label Set


    3. Generalized Label Request
    Could you make it clearer right at = the top of section 3 that
    for RSVP the = Generalized_Label_Request is not a new object but a
    new variant of the Label_Request = Object, whereas for CR-LDP it is
    a new TLV.


    3.3.1 Waveband Switching
    "For compatibility reasons, a = new RSVP c-type and CR-
     LDP type is assigned for the = Waveband Label."
    This seems to be the only place in = the draft where you
    haven't explicitly suggested values = (subject to IANA).
    I think you have left gaps for RSVP = c-type 3 and CR-LDP
    type 903.


    3.5.1 Label Set
    It isn't clear how a sequence of = subchannels that form a
    label set are conveyed.  It = can't be the case that you
    simply add multiple Subchannels to = the Object/TLV since
    the Type is closely associated with = each individual
    Subchannel.
    We should either define Label_Set as = Explicit_Route with
    a sequence of subobjects.  Or we = should allow a series
    of Label_Sets in the = Path/LABEL_REQUEST.
    In either case, it would be good to = put in some motherhood
    about ordering the elements for clear = interpretation. For
    example, suppose x<y<z.  = Can I define the label set
    {x, x+1, ... , y-1, y+1, ..., z} = using three subchannels
    (viz. start x, exclude y, end z) or = must I use four?


    3.5.2 Label_Set Procedures
    I suppose it is implicit, but there = is no mention of inserting
    Label_Set for the first time.


    4. Bidirectional LSPs
    I think it would help to point out = that the support for
    bidirectional LSPs added here is = restricted to certain levels
    of symmetry
    - the TSpec is the same in both = directions
    - the LSRs on the path are the same = in both directions
    - the links between LSRs are not = necessarily the same in both
      directions.


    Suggested_Label
    Sorry if I missed this.
    Must Suggested_Label be chosen from = within the Label_Set?


    4.2 Bidirectional LSP = Procedures
    The choice you have made is = consistent (that you may not
    propagate a Path containing = Upstream_Label until the local
    switch has been programmed, so that = the terminator may start
    sending data as soon as it has = processed the Path) but may
    unnecessarily increase the latency of = LSP set up (compare
    with the arguments for Suggested_Label= ).
    If ResvConf were to be requested and = used, the individual
    switch programming tasks could be = processed in parallel with
    the propagation of the Path = message.  The terminator is not
    allowed to start sending data until = it receives the ResvConf.
    This is a direct trade-off, but could = quite easily reduce
    setup time for individual = LSPs.


    4.3 Bidirectional LSP Contention = Resolution
    Note that action on receipt of a = PathErr is in contradiction
    with RFC2205.  This is, however, = the correct function in the
    situation described.


    4.3 Bidirectional LSP Contention = Resolution
    The suggested behavior for reducing = contention depends on
    adjacent LSRs knowing each other's = node IDs.  Does this
    rely on Hello messages, carnal = knowledge or what?


    5. Notification
    Flag this at the top as being RSVP = only.


    5.1.2 Notify Request Procedures
    We should add a statement about = multiple instances of this object.
    The current discussion allows just a = single instance.


    5.2.2 Notify Procedures
    This version of the text does not = prohibit the Notify Node from
    being other than the requester (i.e. = initiator or terminator).
    We should either impose this for the = time being, or note that
    the Notify Node might not support = Notify messages (and so will
    not send an Ack).


    5.2.2 Notify Procedures
    It's not clear to me that the default = time of 1ms for combining
    Notifies is relevant.


    5.3 Removing State with PathErr
    Note that the reference to RFC 2205 = here is obsoleted by the
    actions required for bidriectional = LSPs (see 4.3) and by
    processing that may be utilized for = local repair and fast
    re-route.
    In effect, RFC 2205's rules for = forwarding PathErr without
    taking action have are already = bent.


    5.3 Removing State with PathErr

    Can we add some text describing the = Path state on downstream
    nodes when Path_State_Removed is = used.  If I receive PathErr
    w/o P_S_R, am I allowed to remove = Path state and send PathErr
    w/ P_S_R?

      
    6.2 Procedures
    The text listing the errors could do = with some cleaning.
    The L-bit isn't the only issue = here.  The nature of the previous
    sub-object can be strict but = imprecise (i.e. a non-unitary
    abstract node .. prefix !=3D 32) or = could be an Autonomous System
    number. In CR-LDP, the subobject = could be an LSPId.


    Reporting explicit labels.
    draft-ietf-mpls-rsvp-lsp-tunnel-07 = has scope in the RRO for
    reporting labels, but this doesn't = quite match the ERO extensions
    here.  In particular we = need
    - scope for two label objects per = hop
    - definition of the U bit
    I believe that this should be in a = new section 6.3


    Specifying links in EROs
    I know we discussed this a bit = before, but I want to check that
    we're in synch.
    We're allowing the IP address = subobject in an explicit route to
    identify an egress link rather than a = next hop.  It becomes a
    local matter how such subobjects are = handled.
    We are not allowing specification of = a link _and_ a next hop. This
    rules out parallel links in a = multidrop network.
    We do not have the ability to specify = an unnumbered link.  This is
    seen as illogical since the indexes = of unnumbered links have only
    local (and possibly extending to the = other end of the link) meaning.


    BNFs
    Label_Set is optional





    Trivial typos (haven't I got better = things to do?)
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    page 4  for "ends on a = LSC" read "ends on an LSC"

    page 5  for "traditional and = and non-PSC" read "traditional and non-PSC"

    page 6  for "come from = non-PSC" read "comes from non-PSC"

    page 7  for "as specific a = LSP Encoding Type" read "as specific an LSP
    Encoding Type"

    3.2.1.1 for "SDH and SONET define = each" read "SDH and SONET each define"

    3.2.1.1 for "directly the = distinction" read "the direct distinction"

    3.2.1.1 for "take part into the = inverse" read "take part in the inverse"

    3.2.1.1 for "higher order signal = need to be" read "higher order signal needs
    to be"

    3.2.1.1 for "in the increasing = order" read "in increasing order"

    3.5     for = "there are a sequence" read "there is a = sequence"

    4.3     for = "since the label sets are exchanged" read "if the label = sets are
    exchanged"

    5.1.2   Notify Target Object = should be Notify Request Object (twice)

    5.2     for = "who's" read "whose"

    5.2     = "Notify Ack" is obsolete, read "Ack"

    5.3     for = "receiving such a error" read "receiving such an = error"

    6.      for = "This occurs case when" read "This occurs in the case = when"

    9.      = strike "Non-adjacent bundle messages, and"

    10.     = rsvp-lsp-tunnel is up to version 7 now.
    --
    Adrian Farrel  mailto:af@dataconnection.com
    Network Convergence Group
    Data Connection Ltd., Chester, = UK
    http://www.dataconnection.com/
    Tel: +44 (0) 1244 313440  Fax: = +44 (0) 1244 312422

------_=_NextPart_001_01C03D38.7D738700-- From owner-mpls@UU.NET Mon Oct 23 18:34:15 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04421 for ; Mon, 23 Oct 2000 18:34:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfa05528; Mon, 23 Oct 2000 22:33:44 GMT Received: by mail-control.mail.uu.net id QQjmfa03436 for mpls-outgoing; Mon, 23 Oct 2000 22:33:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmfa03418 for ; Mon, 23 Oct 2000 22:33:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmfa25709; Mon, 23 Oct 2000 22:32:56 GMT Received: from kcmgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ret1.sprint.com [208.18.122.165]) id QQjmfa12659; Mon, 23 Oct 2000 22:32:55 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id e9NMWnF29589; Mon, 23 Oct 2000 17:32:49 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id e9NMWlW13279; Mon, 23 Oct 2000 17:32:48 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id RAA08049; Mon, 23 Oct 2000 17:32:47 -0500 (CDT) From: Mark.Jones@mail.sprint.com X-OpenMail-Hops: 1 Date: Mon, 23 Oct 2000 17:32:46 -0500 Message-Id: Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh MIME-Version: 1.0 TO: David.A.Holmes@disney.com, ip-optical@lists.bell-labs.com, mpls@UU.NET CC: kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Content-Type: multipart/mixed; boundary="openmail-part-2bbc2b36-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-2bbc2b36-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 23 Oct 2000 17:32:46 -0500" Content-Transfer-Encoding: 7bit David, Great point! The need to automate features like provisioning is one of the key reasons we are all looking at optical networking. However, the fast provisioning we all desire does not require the peer model. (Many problems with the peer model for large multi-service carriers like Sprint have already been raised in this discussion, so I won't repeat them.) I expect end-to-end provisioning in seconds or at least in minutes to be possible with the overlay model too. The question we should be asking is, who will be able to actually take advantage of that capability regardless of the model you adopt? My guess is that it will primarily be an internal network feature that few network customers will ever use directly. Here's why. Even if you find a carrier to support the peer model, you will be required to pay for connections that you MIGHT use in the event that you want to add bandwidth to your connection. No carrier or customer wants to build out capacity without some level of commitment that the equipment will be needed. How much do you want to pay for the privilege of having bandwidth on demand? For sub-wavelength bandwidth, packet level aggregation minimizes the costs of bandwidth on demand for carriers and customers. I believe that exists in limited ways in service offerings already. However, wavelength level bandwidth on demand may never be profitable due to the price of wavelength level port cards and systems. So, the carrier may deploy optical networking with seconds required for provisioning, but the bandwidth will still have to be built out to the customer after an order before it's available. I don't want to burst anyone's dream of bandwidth on demand, but please consider the practical aspects required to make it a reasonable service offering. Even if customers don't have direct access to bandwidth on demand, I expect many of the automated features of optical networking to drastically improve the speed of service delivery to customers. Mark Loyd Jones Sprint Technology Planning & Integration 913-534-5247 mark.jones@mail.sprint.com > -----Original Message----- > From: David.A.Holmes [mailto:David.A.Holmes@disney.com] > Sent: Monday, October 23, 2000 2:19 PM > To: Jones, Mark L.; ip-optical; mpls > Cc: kireeti; sc; xuyg; yxue; zwlin > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > I have not been following this entire thread either, but as > an Enterprise > customer, I take issue with the following remarks: > > "... The availability and BER are all a customer wants or > needs. If I can > give you 99.999% availability (or whatever availability you > want to pay > for) with a BER to satisfy your needs, why do you care whether I use > ring, mesh, or some other scheme? Grade of service is sufficient." > > In addition to availability, what is critical to this > customer is reasonable > circuit provisioning lead times. It is not uncommon to wait 6 > months for a > DS3 or higher speed circuit to be provisioned. The Sprints, > MCIs, AT&Ts, > etc. appear to believe that this is business as usual, and is > acceptable to > the customer. From the customer's standpoint, time is money. My > understanding of the IP/MPLambdaS mesh model proposals, is > that optical > transport network circuit provisioning can be done in seconds. Fast > provisioning is a necessary requirement in my view. > > David Holmes > > -----Original Message----- > From: Mark.Jones@mail.sprint.com [mailto:Mark.Jones@mail.sprint.com] > Sent: Monday, October 23, 2000 11:22 AM > To: ip-optical@lists.bell-labs.com; mpls@UU.NET > Cc: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; > zwlin@lucent.com > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > [I haven't had time to follow this entire thread, so please > correct me > if I'm off track with the discussion.] > > Zhi and Sid are correct. I have trouble seeing any kind of peering > model fitting in a multi-client network like Sprints, so I come with > that assumption. For an overlay or client model, the > specification of > protection types doesn't make sense across the UNI. We argued this > point at the OIF in Barcelona. > > Carriers have their own schemes for providing the protection for > services, and every implementation of the different architectures > provide different results. What I mean is that a Sprint ring > network, > deployed over our fiber plant using equipment from vendor X, > will give > you different availability than a ring in another carrier's network > using their fiber plant and vendor Y. That's just one example. > > The availability and BER are all a customer wants or needs. If I can > give you 99.999% availability (or whatever availability you > want to pay > for) with a BER to satisfy your needs, why do you care whether I use > ring, mesh, or some other scheme? Grade of service is sufficient. > What is needed is standardization of the service grades, so Gold > service is the same thing across every network (independent of the > unlying protection architecture). Though I haven't followed the > details, I seem to remember seeing work on this in another standards > body. > > Mark Loyd Jones > Sprint > Technology Planning & Integration > 913-534-5247 > mark.jones@mail.sprint.com > > > > -----Original Message----- > > From: zwlin [mailto:zwlin@lucent.com] > > Sent: Monday, October 23, 2000 11:17 AM > > To: sc > > Cc: zwlin; kireeti; xuyg; yxue; ip-optical; mpls > > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > > DraftMinutes From Pittsburgh > > > > > > Hi Sid, > > > > And to generalize even further, if a service provider sets up three > > grades of service (e.g., bronze, gold, platinum), the protection > > information should already be embedded within those service > > grades. For > > example, bronze is no protection at all, gold is dynamic mesh > > restoration, and platinum is 1+1 protection. > > > > I think what is most important to a service provider and > > their customers > > are the availability of the connection, i.e., is the connection up > > 99.99% or 99.999% or some other number. How the service > > provider chooses > > to handle how to meet that availability number is up to the service > > provider and their TE. > > > > Am I mis-representing the service provider here? Maybe some service > > providers can comment on whether the above description > sounds right??? > > > > Thanks > > Zhi > > > > > > Sid Chaudhuri wrote: > > > > > > I don't see why TE and protection require the routers to > > specify explicit > > > routes. > > > The routers can simply specify to the optical layer what > > type of optical > > > layer protection > > > it requires. Based on its traffic flow a router only needs > > to know between > > > which > > > two routers it needs to establish a new lightpath. How the > > lightpath is > > > routed in the > > > optical layer seems to me irrelevant to TE. > > > > > > Sid Chaudhuri > > > > > > -----Original Message----- > > > From: Kireeti Kompella > [mailto:kireeti@juniper.net] > > Sent: Monday, October 23, 2000 11:43 AM > > To: xuyg@lucent.com; yxue@UU.NET > > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > > Subject: Re: [IP-Optical] RE: Optical link > bundling. > > Was Re: DraftMinutes From Pittsburgh > > > > Hi, > > > > > > (router determines the explicit routes). > > > > > > This point has been raised by several folks. It > really > > confuses me. If the > > > optical switches are equipped with path > calculation > > ability, what's the benefit > > > to bother router to determine the explicit routes > within > > optical domain > > > (assuming router can be smart enough to > handle all > optical > > network specific > > > attributes and constrains) than just have > routers to > > determine the end points of > > > optical trails. > > > > Why does this confuse you? Routers may want to > determine > > the exact > > path that their LSPs take for a number of reasons, > including > > TE and > > protection. If a router doesn't care where > its LSPs > are > > laid out, > > it can install loose hops at the boundaries of the > optical > > cloud. > > > > Kireeti. > > > > _______________________________________________ > > IP-Optical mailing list > > IP-Optical@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/ip-optical > > -- > Zhi-Wei Lin > Lucent Technologies Tel: +1 732 949 5141 > 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 > Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com > --openmail-part-2bbc2b36-00000001-- From owner-mpls@UU.NET Mon Oct 23 18:44:05 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05529 for ; Mon, 23 Oct 2000 18:44:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfa13641; Mon, 23 Oct 2000 22:43:16 GMT Received: by mail-control.mail.uu.net id QQjmfa04447 for mpls-outgoing; Mon, 23 Oct 2000 22:42:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmfa04439 for ; Mon, 23 Oct 2000 22:42:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmfa25341; Mon, 23 Oct 2000 22:42:47 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjmfa17486; Mon, 23 Oct 2000 22:42:46 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Mon, 23 Oct 2000 23:42:35 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id ; Mon, 23 Oct 2000 23:42:20 +0100 Message-ID: To: David.A.Holmes@disney.com, Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET Cc: kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 23:42:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Daveid Holmes observed: > I have not been following this entire thread either, but as an Enterprise > customer, I take issue with the following remarks: > > "... The availability and BER are all a customer wants or needs. If I can > > give you 99.999% availability (or whatever availability you want to pay > for) with a BER to satisfy your needs, why do you care whether I use > ring, mesh, or some other scheme? Grade of service is sufficient." > > In addition to availability, what is critical to this customer is > reasonable > circuit provisioning lead times. It is not uncommon to wait 6 months for a > DS3 or higher speed circuit to be provisioned. The Sprints, MCIs, AT&Ts, > etc. appear to believe that this is business as usual, and is acceptable > to > the customer. From the customer's standpoint, time is money. My > understanding of the IP/MPLambdaS mesh model proposals, is that optical > transport network circuit provisioning can be done in seconds. Fast > provisioning is a necessary requirement in my view. > NH=> I think Mark and all operators understand the point you are making here David.....so I apologise on all behalf of us all. We really want to be able to give you rapidly provisioned leased-line/managed BW services. But your observation is somewhat tangential to the main lines being discussed, which are the closely related questions: (i) are traditional IP control-plane facets (so that is, for example, v4 addressing, RSVP signalling and a IGP) the correct choice for an OTN?....though to be honest no-one it seems dare raise this most basic of questions too loudly; (ii) irrespective (in principle if not practice) of the choice of control-plane facets, can these be unified/shared over all network layers? I don't think we have 'consensus' to either of these as yet (though some have aleady made up their minds on part (i), and assume (ii) follows). However, if all you need are faster provisioned managed BW services from the OTN, then you are (in effect) perhaps unconsciously stating a clear requirement for the overlay model. I have no problems with this, as we know there will be plenty of customers who will still want to build their own networks (various sizes/requirements) based on managed BW services. My problem, as an operator, is to make sure that your requirements are not ignored in this debate and that the OTN can deliver these services. From owner-mpls@UU.NET Mon Oct 23 18:44:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05649 for ; Mon, 23 Oct 2000 18:44:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfa26872; Mon, 23 Oct 2000 22:44:05 GMT Received: by mail-control.mail.uu.net id QQjmfa04500 for mpls-outgoing; Mon, 23 Oct 2000 22:43:33 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmfa04484 for ; Mon, 23 Oct 2000 22:43:22 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmfa18045; Mon, 23 Oct 2000 22:42:51 GMT Received: from kcmgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ret1.sprint.com [208.18.122.165]) id QQjmfa25323; Mon, 23 Oct 2000 22:42:51 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id e9NMgnF01243; Mon, 23 Oct 2000 17:42:49 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id e9NMgmW15154; Mon, 23 Oct 2000 17:42:48 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id RAA11937; Mon, 23 Oct 2000 17:42:48 -0500 (CDT) From: Mark.Jones@mail.sprint.com X-OpenMail-Hops: 1 Date: Mon, 23 Oct 2000 17:42:47 -0500 Message-Id: Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh MIME-Version: 1.0 TO: azinin@cisco.com, yxue@UU.NET CC: braja@tellium.com, darren.freeland@bt.com, ip-optical@lists.bell-labs.com, jdrake@calient.net, mpls@UU.NET, neil.2.harrison@bt.com Content-Type: multipart/mixed; boundary="openmail-part-2bbc58a7-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-2bbc58a7-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 23 Oct 2000 17:42:47 -0500" Content-Transfer-Encoding: 7bit I believe you will find that carriers are already working on requirements in T1X1 and the ITU-T. The OIF Carrier group document served as a catalyst to get the requirements on paper. That has triggered carrier work on requirements in T1X1 and elsewhere for inclusion in IETF and ITU-T documents. We don't need another group to work this issue. The best results will come from carrier/vendor interaction to develop acceptable requirements. Mark Loyd Jones Sprint Technology Planning & Integration 913-534-5247 mark.jones@mail.sprint.com > -----Original Message----- > From: azinin [mailto:azinin@cisco.com] > Sent: Friday, October 20, 2000 6:25 PM > To: yxue > Cc: azinin; darren.freeland; braja; jdrake; neil.2.harrison; mpls; > ip-optical > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft > Minutes From Pittsburgh > > > > Yong, > > Friday, October 20, 2000, 2:26 PM, Yong Xue wrote: > > [...] > > > I think the carrier > > should form > > a group and come up with a control plane protocol requirements > > [...] > > I believe such a document would be very valuable. > > Alex. > > > --openmail-part-2bbc58a7-00000001-- From owner-mpls@UU.NET Mon Oct 23 18:51:56 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06482 for ; Mon, 23 Oct 2000 18:51:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfb28350; Mon, 23 Oct 2000 22:51:15 GMT Received: by mail-control.mail.uu.net id QQjmfb05576 for mpls-outgoing; Mon, 23 Oct 2000 22:50:56 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmfb05556 for ; Mon, 23 Oct 2000 22:50:41 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmfb04667 for ; Mon, 23 Oct 2000 22:50:03 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmfb04788 for ; Mon, 23 Oct 2000 22:50:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA25054 for mpls@uu.net; Mon, 23 Oct 2000 18:50:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmfb05460 for ; Mon, 23 Oct 2000 22:49:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmfb07299 for ; Mon, 23 Oct 2000 22:49:04 GMT Received: from mail-blue.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjmfb25459 for ; Mon, 23 Oct 2000 22:49:04 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 9EB084CE56; Mon, 23 Oct 2000 18:48:59 -0400 (EDT) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id SAA00222; Mon, 23 Oct 2000 18:48:54 -0400 (EDT) Reply-To: From: "John Strand" To: "'Kireeti Kompella'" Cc: , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Mon, 23 Oct 2000 18:48:39 -0400 Message-ID: <009901c03d43$63635010$3e82cf87@pcstranded.attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200010232024.NAA02482@kummer.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id SAA06482 Hi Kireeti, Comments in-line. Sorry about the MIME encoding ... when I get a chance I'll check into my options. John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Monday, October 23, 2000 4:25 PM To: jls@research.att.com Cc: ip-optical@lists.bell-labs.com; mpls@uu.net Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Hi John, > What's needed is a way for you to ask for a lightpath that's physically > diverse from one or more other lightpaths, whether or not the other > lightpaths have the same terminals as the new lightpath. Yes, that is correct. > This is done > routinely at DS3 and (I think) OC-n levels today by PL services like > AT&T's EDRO (Enhanced Diversity Routing Option). Are you (or others) proposing the mechanisms to do this in the UNI/GMPLS framework? [JLS Comment] The Carrier Group requirements specify an interface that should support the necessary information flow - in particular, specify that lambda n+1 should be diverse from a specified list of existing lambdas. (At present it doesnt explicitly say these existing lambdas can have different end points. I'm going to try to get this fixed.) My OIF 2000.109 has additional specific requirements. > The heuristics to simultaneously route a number of circuits simultaneously > subject to diversity constraints essentially require zillions of calls > to a Dijkstra algorithm and so don't seem to lend themselves to incorporation > in the control plane. In the IP world, I see the use for simultaneous set up of a small number of disjoint paths, basically, a primary and one or more backups for an LSP. So, this may not be an issue. What is the requirement driving having lots of simultaneous diverse paths in the telephony world? [JLS Comment] Large single-customer PL networks. Frequently they have done their own reliability analysis and come in with a matrix showing which circuits need to be diverse. There are some examples in the OIF 2000.109 that give a little more information. For another entirely different example consider a SONET ring: All edges of the ring must be diverse. > I'd be interested in hearing more about the drivers for your example. I would > expect that if you want physical diversity you are setting up lightpaths that > are going to be around for a while. Yes, but as I said above, I visualize lots of LSPs, each requiring two or three diverse paths, not hundreds of diverse paths. So, this should not be an issue. [JLS Comment] I agree - sounds like you're at the easy end of this sort of problem. > There's a book by Ramesh Bhandari that addresses some of the algorithm issues. > I don't believe that the heuristics used for services like EDRO are in the > public domain though. More's the pity :-) Kireeti. PS. BTW, your mail replies are MIME encoded, even when they are simple ASCII. From owner-mpls@UU.NET Mon Oct 23 19:32:52 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10997 for ; Mon, 23 Oct 2000 19:32:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfe27155; Mon, 23 Oct 2000 23:31:52 GMT Received: by mail-control.mail.uu.net id QQjmfe22007 for mpls-outgoing; Mon, 23 Oct 2000 23:31:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmfe21973 for ; Mon, 23 Oct 2000 23:31:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmfe22414; Mon, 23 Oct 2000 23:30:42 GMT Received: from hoemlsrv.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQjmfe18252; Mon, 23 Oct 2000 23:30:42 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA07626; Mon, 23 Oct 2000 19:30:41 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id TAA07593; Mon, 23 Oct 2000 19:30:37 -0400 (EDT) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id TAA14913; Mon, 23 Oct 2000 19:30:26 -0400 Message-ID: <39F4CA87.ADCF46FC@hotair.hobl.lucent.com> Date: Mon, 23 Oct 2000 19:32:23 -0400 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: neil.2.harrison@bt.com, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <200010231940.MAA02335@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kireeti, I think the problem you are trying to pose pertains to the calculation of the pair of disjoint paths from A to B through an intemediate OTN network. The solution consists of three parts: 1) Calculate diverse paths from A to ingress points X and W, i.e., path A to X and path A to W, which are physically-disjoint from each other, except at the common source point A 2) Calculate two disjoint paths paths through the OTN network connecting the ingress points X and W to the egress points Y and Z (two possibilities arise in general: the diverse paths within the OTN are i) X to Y and W to Z ii) X to Z and W to Y) 3) Calculate paths Y to B and Z to B, which are diverse from each other, except at the end point B. For A to do all the calculation would require a massive amount of data at B, including all the necessary details of the (physical) OTN ( not to mention the fact that in a catastrophic disaster like a fiber cable cut, thousands of LSP's with different pairs of endpoints would be affected simultaneoulsy, and need to be also restored simultaneously by the routers for fast restoration). In the Overlay/Client model, the requests are received at the ingress points X and W from the router A, and diverse paths are computed within the OTN, using network information at each of the OXC controllers (basically part 2 above of the solution for the peer model). Regards, Ramesh PS Algorithms for finding disjoint paths of the type - parts 1), 2) and 3) of thesolution above- exist, and can be found in my book "Survivable Networks - Algorithms for Diverse Routing", Kluwer Academic Publishers (1999). Kireeti Kompella wrote: > > > Suppose router A wants to get to router B, and wants to take two > > > different ingress and egress points in the optical domain, X->Y > > > for the primary LSP, and W->Z for the backup. A does not require > > > optical protection for the X->Y path, nor for the W->Z path. A > > > *does* require that the X->Y path and the W->Z path do not share > > > common links. How is this to be done? > > > > > > If A did the full path computation, this is simplicity itself. > > > > > NH=> Kireeti, I don't this can be a general answer. The request > > (from whatever the client) is for two phyically disjoint paths between two > > points A and B. > > Neil, A *is* the client. And A wants two disjoint paths to B via > *different ingress points in the OTN*. This is a very reasonable > request. > > Also, A doing a full path computation is *not* a general answer. > It is an illustration of an advantage of the peer model, and of > routers doing a full path computation across the OTN. To achieve > what A wants in an overlay/client/UNI model would require a fair > amount of work in extending routing/signalling/UNI protocols. > > Kireeti. From owner-mpls@UU.NET Mon Oct 23 20:48:12 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19481 for ; Mon, 23 Oct 2000 20:48:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfj24002; Tue, 24 Oct 2000 00:47:50 GMT Received: by mail-control.mail.uu.net id QQjmfj09405 for mpls-outgoing; Tue, 24 Oct 2000 00:47:15 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmfj09385 for ; Tue, 24 Oct 2000 00:47:01 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmfj00219 for ; Tue, 24 Oct 2000 00:46:10 GMT Received: from smtp01.mrf.mail.rcn.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp01.mrf.mail.rcn.net [207.172.4.60]) id QQjmfj21830 for ; Tue, 24 Oct 2000 00:46:09 GMT Received: from 208-58-202-97.s351.tnt12.lnhva.md.dialup.rcn.com ([208.58.202.97] helo=erols.com) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13nsEC-0003hD-00 ; Mon, 23 Oct 2000 20:46:09 -0400 Message-ID: <39F4DBBB.695C94D3@erols.com> Date: Mon, 23 Oct 2000 20:45:47 -0400 From: "S. Chkaravorty" X-Mailer: Mozilla 4.51 [en]C-RR032399 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: jls@research.att.com, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <200010232024.NAA02482@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, Kireeti Kompella wrote: > > Are you (or others) proposing the mechanisms to do this in the > UNI/GMPLS framework? > Why is that so important? > > > The heuristics to simultaneously route a number of circuits simultaneously > > subject to diversity constraints essentially require zillions of calls > > to a Dijkstra algorithm and so don't seem to lend themselves to incorporation > > in the control plane. > > In the IP world, I see the use for simultaneous set up of a small > number of disjoint paths, basically, a primary and one or more > backups for an LSP. So, this may not be an issue. What is the > requirement driving having lots of simultaneous diverse paths in > the telephony world? > Very simple. It is an age old practice in all transmission networks to provide route diversity for failure back-up and peak traffic conditions. From owner-mpls@UU.NET Mon Oct 23 21:03:53 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21246 for ; Mon, 23 Oct 2000 21:03:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfk08661; Tue, 24 Oct 2000 01:02:58 GMT Received: by mail-control.mail.uu.net id QQjmfk16061 for mpls-outgoing; Tue, 24 Oct 2000 01:02:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmfk15875 for ; Tue, 24 Oct 2000 01:02:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmfk21256; Tue, 24 Oct 2000 01:01:46 GMT Received: from hoemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQjmfk11528; Tue, 24 Oct 2000 01:01:46 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA08187; Mon, 23 Oct 2000 21:01:46 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id VAA08178; Mon, 23 Oct 2000 21:01:45 -0400 (EDT) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id VAA18545; Mon, 23 Oct 2000 21:01:45 -0400 Message-ID: <39F4DFED.3141D81F@hotair.hobl.lucent.com> Date: Mon, 23 Oct 2000 21:03:42 -0400 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jls@research.att.com CC: "'Kireeti Kompella'" , sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <007b01c03d28$47950ab0$3e82cf87@pcstranded.attnjs.research.att.com> Content-Type: multipart/alternative; boundary="------------23E9F2AFB2403BA2480B6AEB" Sender: owner-mpls@UU.NET Precedence: bulk --------------23E9F2AFB2403BA2480B6AEB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Folks, There has been a flurry of email exchanges on issues and algorithms pertaining to paths routed diversely within a network (e.g., the OTN) in accordance with client's request. Several interesting scenarios were briefly discussed: path routed diversely from existing paths, simultaneous calculation of diverse paths, efficiency of the algorithms, diverse paths requested by a client ingressing and egressing through the OTN network through different points( and how to achieve that), etc. In the process, my book on diversity algorithms was pointed out by John Strand. In light of the interest in diversity , I thought I mention a few important details about my book "Survivable Networks - Algorithms or Diverse Routing", Kluwer Academic Publishers (1999): 1) The book points out the pitfalls of finding the shortest path first and then routing the second path diversely from the first path; this approach produces nonoptimal solutions, and is sometimes unable to determine a diverse pair of paths, even when such a pair actually exists. 2) It provides detailed algorithms for simultaneously calculating the diverse pair of paths in an optimal (least total cost) manner. The algorithms are simple and efficient, basically requiring two runs of a (modified) Dijkstra algorithm. They are easily extended to finding K(>2) disjoint paths in he network (this is useful for protection against multiple failures and network and also efficient network design) When diversity simply does not exist due to insufficient network connectivity, maximally disjoint paths are found (this is important, since a customr may accept less than 100% diversity). 3) It provides extensions to the real-life physical networks, involving span-sharing links (or SRLG's, as they are now called) 4) It provides extensions to the types of cases brought out by Kireeti Kompella (different ingress and egress points for diverse routes) Although the construction of algorithms in the book is driven by optimality, for complicated situations where fast, optimal solutions are not possible, suitable (fast) heuristics can be derived (see, e.g., Section 6.2 of the book) using the developed algorithms. Clearly, heuristic approaches which involve running the Dijkstra algorithm over and over again are to be avoided, as they become inefficient. Regards, Ramesh --------------23E9F2AFB2403BA2480B6AEB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Folks,

There has been a flurry of email exchanges on issues and algorithms pertaining to paths routed diversely within a network (e.g., the OTN) in accordance with client's request. Several interesting scenarios were briefly discussed: path routed diversely from existing paths, simultaneous calculation of diverse paths, efficiency of the algorithms, diverse paths requested by a client ingressing and egressing through the OTN network through different points( and how to achieve that), etc. In the process, my book on diversity algorithms was pointed out by John Strand. In light of the interest in diversity , I thought I mention a few important details about my book "Survivable Networks - Algorithms or Diverse Routing", Kluwer Academic Publishers (1999):

1) The book points out the pitfalls of finding the shortest path first and then routing the second path diversely from the first path; this approach produces nonoptimal solutions, and is sometimes unable to determine a diverse pair of paths, even when such a pair actually exists.

2) It provides detailed algorithms for simultaneously calculating the diverse pair of paths in an optimal (least total cost) manner. The algorithms are simple and efficient, basically requiring two runs of a (modified) Dijkstra algorithm. They are easily extended to finding K(>2) disjoint paths in he network (this is useful for protection against multiple failures and network and also efficient network design) When diversity simply does not exist due to insufficient network connectivity, maximally disjoint paths are found (this is important, since a customr may accept less than 100% diversity).

3) It provides extensions to the real-life physical networks, involving span-sharing links (or SRLG's, as they are now called)

4) It provides extensions to the types of cases brought out by Kireeti Kompella (different ingress and egress points for diverse routes)

Although the construction of algorithms in the book is driven by optimality, for complicated situations where fast, optimal solutions are not possible, suitable (fast) heuristics can be derived (see, e.g., Section 6.2 of the book) using the developed algorithms. Clearly, heuristic approaches which involve running the Dijkstra algorithm over and over again are to be avoided, as they become inefficient.

Regards,

Ramesh
 
  --------------23E9F2AFB2403BA2480B6AEB-- From owner-mpls@UU.NET Mon Oct 23 21:06:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21560 for ; Mon, 23 Oct 2000 21:06:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfk17303; Tue, 24 Oct 2000 01:06:29 GMT Received: by mail-control.mail.uu.net id QQjmfk21317 for mpls-outgoing; Tue, 24 Oct 2000 01:05:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmfk21010 for ; Tue, 24 Oct 2000 01:05:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmfk01517 for ; Tue, 24 Oct 2000 01:05:13 GMT Received: from icarian.ZAFFIRE.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjmfk11587 for ; Tue, 24 Oct 2000 01:05:12 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <48XX18BT>; Mon, 23 Oct 2000 18:06:05 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6625D8B86@ICARIAN> From: Eric Gray To: "'S. Chkaravorty'" , Kireeti Kompella Cc: jls@research.att.com, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: Draft Minutes From Pittsburgh Date: Mon, 23 Oct 2000 18:06:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk S. Chkaravorty, Route diversity is not provided per-call, for every call, even in the most retentive of transmission networks. :-) -- Eric Gray > -----Original Message----- > From: S. Chkaravorty [mailto:sc12@erols.com] > Sent: Monday, October 23, 2000 5:46 PM > To: Kireeti Kompella > Cc: jls@research.att.com; ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > Kireeti, > > > Kireeti Kompella wrote: > > > > > Are you (or others) proposing the mechanisms to do this in the > > UNI/GMPLS framework? > > > > Why is that so important? > > > > > > The heuristics to simultaneously route a number of > circuits simultaneously > > > subject to diversity constraints essentially require > zillions of calls > > > to a Dijkstra algorithm and so don't seem to lend > themselves to incorporation > > > in the control plane. > > > > In the IP world, I see the use for simultaneous set up of a small > > number of disjoint paths, basically, a primary and one or more > > backups for an LSP. So, this may not be an issue. What is the > > requirement driving having lots of simultaneous diverse paths in > > the telephony world? > > > > Very simple. It is an age old practice in all transmission > networks to provide > route diversity for failure back-up and peak traffic conditions. > > From owner-mpls@UU.NET Mon Oct 23 21:11:48 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22146 for ; Mon, 23 Oct 2000 21:11:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfk00459; Tue, 24 Oct 2000 01:11:17 GMT Received: by mail-control.mail.uu.net id QQjmfk23169 for mpls-outgoing; Tue, 24 Oct 2000 01:10:38 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmfk23123 for ; Tue, 24 Oct 2000 01:10:22 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmfk25100 for ; Tue, 24 Oct 2000 01:09:54 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f138.law11.hotmail.com [64.4.17.138]) id QQjmfk17391 for ; Tue, 24 Oct 2000 01:09:53 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Oct 2000 18:09:53 -0700 Received: from 64.217.73.116 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 24 Oct 2000 01:09:53 GMT X-Originating-IP: [64.217.73.116] From: "Charles Smith" To: mpls@UU.NET Subject: LSP failure detection Date: Tue, 24 Oct 2000 01:09:53 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Oct 2000 01:09:53.0087 (UTC) FILETIME=[1D634CF0:01C03D57] Sender: owner-mpls@UU.NET Precedence: bulk MPLS list: Can someone please explain the mechanisms involved to detect a node or link failure within a particular LSP? How can MPLS as a technology guarantee < 1 second LSP failure restoration (contrast to SONET)? I need to understand exactly how a failure is detected, how the backup path is activated or how fast re-route directs the LSP around the link or node failure. I am just a marketing guy who has read the drafts and still needs the engineers to explain the concepts :-) Cheers. Chas _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Mon Oct 23 21:45:29 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28148 for ; Mon, 23 Oct 2000 21:45:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfn05611; Tue, 24 Oct 2000 01:45:12 GMT Received: by mail-control.mail.uu.net id QQjmfm26955 for mpls-outgoing; Tue, 24 Oct 2000 01:44:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmfm26942 for ; Tue, 24 Oct 2000 01:44:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmfm00158 for ; Tue, 24 Oct 2000 01:44:02 GMT Received: from smtp03.mrf.mail.rcn.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp03.mrf.mail.rcn.net [207.172.4.62]) id QQjmfm11135 for ; Tue, 24 Oct 2000 01:44:02 GMT Received: from 216-164-129-205.s459.tnt1.lnhva.md.dialup.rcn.com ([216.164.129.205] helo=erols.com) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13nt8D-0006jF-00 ; Mon, 23 Oct 2000 21:44:01 -0400 Message-ID: <39F4E94C.5D352EA5@erols.com> Date: Mon, 23 Oct 2000 21:43:40 -0400 From: "S. Chkaravorty" X-Mailer: Mozilla 4.51 [en]C-RR032399 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Eric Gray CC: Kireeti Kompella , jls@research.att.com, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: Draft MinutesFrom Pittsburgh References: <4611AD058694D4118FD5009027B0A6625D8B86@ICARIAN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit True, I didn't mean it that way :-)) Eric Gray wrote: > S. Chkaravorty, > > Route diversity is not provided per-call, > for every call, even in the most retentive of > transmission networks. :-) > > -- > Eric Gray > > > -----Original Message----- > > From: S. Chkaravorty [mailto:sc12@erols.com] > > Sent: Monday, October 23, 2000 5:46 PM > > To: Kireeti Kompella > > Cc: jls@research.att.com; ip-optical@lists.bell-labs.com; mpls@UU.NET > > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > > DraftMinutes From Pittsburgh > > > > > > Kireeti, > > > > > > Kireeti Kompella wrote: > > > > > > > > Are you (or others) proposing the mechanisms to do this in the > > > UNI/GMPLS framework? > > > > > > > Why is that so important? > > > > > > > > > The heuristics to simultaneously route a number of > > circuits simultaneously > > > > subject to diversity constraints essentially require > > zillions of calls > > > > to a Dijkstra algorithm and so don't seem to lend > > themselves to incorporation > > > > in the control plane. > > > > > > In the IP world, I see the use for simultaneous set up of a small > > > number of disjoint paths, basically, a primary and one or more > > > backups for an LSP. So, this may not be an issue. What is the > > > requirement driving having lots of simultaneous diverse paths in > > > the telephony world? > > > > > > > Very simple. It is an age old practice in all transmission > > networks to provide > > route diversity for failure back-up and peak traffic conditions. > > > > From owner-mpls@UU.NET Tue Oct 24 00:44:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00858 for ; Tue, 24 Oct 2000 00:44:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmfy11417; Tue, 24 Oct 2000 04:38:41 GMT Received: by mail-control.mail.uu.net id QQjmfy20386 for mpls-outgoing; Tue, 24 Oct 2000 04:38:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmfy20375 for ; Tue, 24 Oct 2000 04:37:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmfy21460 for ; Tue, 24 Oct 2000 04:37:47 GMT Received: from srnex01.sd.osicom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: srnex01.sd.osicom.com [131.143.32.21]) id QQjmfy04603 for ; Tue, 24 Oct 2000 04:37:46 GMT Received: by srnex01.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 21:28:56 -0700 Message-ID: <022A2DBC40A6D411967000D0B78892A625862F@srnex01.sd.osicom.com> From: "Guo, Dan" To: "'Adrian Farrel'" , mpls@UU.NET Cc: lberger@labn.net, petera@nortelnetworks.com Subject: RE: draft-ietf-mpls-generalized-signaling-00.txt Date: Mon, 23 Oct 2000 21:28:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D72.EBB1FB90" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03D72.EBB1FB90 Content-Type: text/plain; charset="iso-8859-1" Adrian, I also feel it was not clear how label-set is conveyed. From your example (like x-1...), you seem to imply that wavelength is represented by an index (like 1...n). Such thing has to be stipulated in a global sense (ie. every node agrees). The draft is not clear about this. In the draft, it says "subchannel to local channel identifiers (eg. wavelength) mappings are a local matter." Some clarification is needed, especially with types "inclusive" and "exclusive." It would be super if illustrated with simple examples. Dan -----Original Message----- From: Adrian Farrel [mailto:AF@dataconnection.com] Sent: Monday, October 23, 2000 11:11 AM To: mpls@UU.NET Cc: lberger@labn.net; petera@nortelnetworks.com Subject: draft-ietf-mpls-generalized-signaling-00.txt 3.5.1 Label Set It isn't clear how a sequence of subchannels that form a label set are conveyed. It can't be the case that you simply add multiple Subchannels to the Object/TLV since the Type is closely associated with each individual Subchannel. We should either define Label_Set as Explicit_Route with a sequence of subobjects. Or we should allow a series of Label_Sets in the Path/LABEL_REQUEST. In either case, it would be good to put in some motherhood about ordering the elements for clear interpretation. For example, suppose x RE: draft-ietf-mpls-generalized-signaling-00.txt

Adrian,

I also feel it was not clear how label-set is = conveyed.

From your example (like x-1...), you seem to imply = that wavelength is represented by an index (like 1...n).
Such thing has to be stipulated in a global sense = (ie. every node agrees). The draft is not clear about this.

In the draft, it says "subchannel to local = channel identifiers (eg. wavelength) mappings are a local matter." = Some clarification is needed, especially with types = "inclusive" and "exclusive."

It would be super if illustrated with simple = examples.

Dan

-----Original Message-----
From: Adrian Farrel [mailto:AF@dataconnection.com]<= /FONT>
Sent: Monday, October 23, 2000 11:11 AM
To: mpls@UU.NET
Cc: lberger@labn.net; = petera@nortelnetworks.com
Subject: = draft-ietf-mpls-generalized-signaling-00.txt
3.5.1 Label Set
It isn't clear how a sequence of subchannels that = form a
label set are conveyed.  It can't be the case = that you
simply add multiple Subchannels to the Object/TLV = since
the Type is closely associated with each individual =
Subchannel.
We should either define Label_Set as Explicit_Route = with
a sequence of subobjects.  Or we should allow a = series
of Label_Sets in the Path/LABEL_REQUEST.
In either case, it would be good to put in some = motherhood
about ordering the elements for clear = interpretation. For
example, suppose x<y<z.  Can I define the = label set
{x, x+1, ... , y-1, y+1, ..., z} using three = subchannels
(viz. start x, exclude y, end z) or must I use = four?


3.5.2 Label_Set Procedures
I suppose it is implicit, but there is no mention of = inserting
Label_Set for the first time.

------_=_NextPart_001_01C03D72.EBB1FB90-- From owner-mpls@UU.NET Tue Oct 24 05:19:03 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20716 for ; Tue, 24 Oct 2000 05:19:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmgr02869; Tue, 24 Oct 2000 09:18:37 GMT Received: by mail-control.mail.uu.net id QQjmgr18912 for mpls-outgoing; Tue, 24 Oct 2000 09:18:19 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmgr18904 for ; Tue, 24 Oct 2000 09:18:17 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmgr28699 for ; Tue, 24 Oct 2000 09:17:03 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f206.law4.hotmail.com [216.33.149.206]) id QQjmgr23865 for ; Tue, 24 Oct 2000 09:17:03 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 24 Oct 2000 02:17:02 -0700 Received: from 138.96.192.3 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 24 Oct 2000 09:17:02 GMT X-Originating-IP: [138.96.192.3] From: "Rares SERBAN" To: ytr@csa.iisc.ernet.in, mpls@UU.NET Subject: Re: COPS doubt Date: Tue, 24 Oct 2000 09:17:02 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Oct 2000 09:17:02.0679 (UTC) FILETIME=[2B951670:01C03D9B] Sender: owner-mpls@UU.NET Precedence: bulk Hi YTR, Yes it is necessary to have PEP (PEP agents) and PDP in the network. To avoid the congestion inside the network, using Traffic Engineering, we need informations to make decisions. For example: we can use COPS to calculate the I/O traffic through an interface and make decisions and enforce them at ingress nodes of the network. R. --------------------------------------- Ph.D. student Rares Serban, MsCS http://www.inria.fr/rodeo/Rares.Serban/ --------------------------------------- >From: "Y.T. Ramanjaneyulu" > >To: mpls@UU.NET >Subject: COPS doubt >Date: Tue, 24 Oct 2000 00:01:29 +0530 (IST) > >HI, > > >If already discussed these things then please provide pointers to mail >archives > >I am currently working on a Project which involves developing a Label >Switched router in a MPLS domain.The core protocols which are used in this >work are MPLS as the forwarding mechanism and RSVP-TE as the signalling >Protocol.Main intention of ours is to provide Qos services to the end users >in MPLS >domain. > >I thought of having a Resource manager inside each LSR to manage the >resources locally. We have policies to allow user to consume only certain >amount of >bandwidth etc. > >PDP generally situated in some remote machine and collecting statistics >from allclients and making descisions . > > So in our scenario is it necessary to have a PEP and a PDP (COPS >Protocol) inside the network ??? > > > Thanx in advance > > >-- >Regards >YTR > >NOTE: >----- > P L E A S E DON'T R E P L Y TO THIS MAIL ID. > >************************* >If u want to reply > > please reply to >ytr@csa.iisc.ernet.in > >************************ > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Tue Oct 24 05:59:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29421 for ; Tue, 24 Oct 2000 05:59:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmgt23421; Tue, 24 Oct 2000 09:59:28 GMT Received: by mail-control.mail.uu.net id QQjmgt23564 for mpls-outgoing; Tue, 24 Oct 2000 09:58:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmgt23556 for ; Tue, 24 Oct 2000 09:58:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmgt03141 for ; Tue, 24 Oct 2000 09:58:46 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmgt15507 for ; Tue, 24 Oct 2000 09:58:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA03545 for mpls@uu.net; Tue, 24 Oct 2000 05:58:43 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmgt23511 for ; Tue, 24 Oct 2000 09:58:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmgt08813 for ; Tue, 24 Oct 2000 09:57:38 GMT Received: from mail-gw1.hursley.ibm.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-gw1.hursley.ibm.com [194.196.110.15]) id QQjmgt14107 for ; Tue, 24 Oct 2000 09:57:37 GMT Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA18830; Tue, 24 Oct 2000 10:56:06 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA54194; Mon, 23 Oct 2000 17:26:58 +0100 Message-ID: <39F466B1.46161AE6@hursley.ibm.com> Date: Mon, 23 Oct 2000 11:26:25 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Chatur sharp CC: diffserv@ietf.org, mpls@UU.NET, jh@telia.fi, fred@cisco.com, wweiss@lucent.com, jtw@lcs.mit.edu Subject: Re: [Diffserv] RFC2597 References: <20001023001448.2659.qmail@web5104.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, You say "Now the AF class definition says that the domain Y and hence node B must provide garuntee that as long as traffic coming from A is green it MUST forward it reliably." I'm sorry, but RFC 2597 says nothing of the kind. It says things like > An AF implementation MUST detect and respond to long-term congestion > within each class by dropping packets, while handling short-term > congestion (packet bursts) by queueing packets. which shows clearly that reliable forwarding is *not* part of the AF definition. The traffic engineering for services based on AF is statistical, and obviously requires statistical estimates of traffic per egress, but there are no guarantees. Brian Carpenter diffserv co-chair > Chatur sharp wrote: > > Hi folks, > > This mail is regards the policing and providing > QoS garruntees part of DIFFSERV. I have a feeling > that the current definition of PHBs is incomplete to > implement the AFx as well as the EF class. This is > because in the PHB definition the destination of > a flow is not taken into account. > > For example let us consider a simple network confg > as shown below: > > Domain| Domain > X | Y > | > | > A ----|---B ---- C > | \ > | \___D > > > In this setup domain X and domain Y are connected > via link AB. Both these domains are independent > DIFFSERV domain. Let us consider traffic entering > domain Y( ingress node B) through domain X ( egress > node B). > > Now the AF class definition says that the domain Y > and hence node B must provide garuntee that as long > as traffic coming from A is green it MUST forward > it reliably. For example, let us say that the SLA > between node B and node A garuntees that as long > as traffic flowing is less than 200MB per sec it > will treat it as green. But if A doesnot specify > the destination of its traffic than B would be > forced to allocate this much of bandwidth along all > its link ( if it is to meet the MUST transfer it > reliably requirement). This to me seems a little > bizarre. Usually for CAC and traffic engineering > you should know the endpoints. > > To me it seems that DIFFSERV is not useful as a > traffic engineering tool as long as it is not > combined with something like MPLS or it does not > start including end points for identifying flows. > > To me an SLA between any two domains MUST mention > the destination address or no garuntees can be > provided and the traffic would be best effort. > > However, I do believe that in case, there is no CAC > and hence policing to be performed then DIFFSERV can > be used to prioritize traffic like in regular > CoS-IP world. > > Any comments > thanks > C. > > ===== > I am willing to learn, if you care to teach. > I am willing to teach, if you care to learn. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Messenger - Talk while you surf! It's FREE. > http://im.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From owner-mpls@UU.NET Tue Oct 24 06:14:33 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02896 for ; Tue, 24 Oct 2000 06:14:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmgu29183; Tue, 24 Oct 2000 10:13:50 GMT Received: by mail-control.mail.uu.net id QQjmgu06624 for mpls-outgoing; Tue, 24 Oct 2000 10:13:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmgu06607 for ; Tue, 24 Oct 2000 10:13:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmgu10816 for ; Tue, 24 Oct 2000 10:11:04 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmgu00852 for ; Tue, 24 Oct 2000 10:11:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA04326 for mpls@uu.net; Tue, 24 Oct 2000 06:11:03 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmgu06253 for ; Tue, 24 Oct 2000 10:10:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmgu18849 for ; Tue, 24 Oct 2000 10:10:38 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjmgu25131 for ; Tue, 24 Oct 2000 10:10:38 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01978; Tue, 24 Oct 2000 06:10:37 -0400 (EDT) Message-Id: <200010241010.GAA01978@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsp-query-00.txt Date: Tue, 24 Oct 2000 06:10:36 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --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 : MPLS LDP Query Message Description Author(s) : P. Ashwood-Smith, A. Paraschiv Filename : draft-ietf-mpls-lsp-query-00.txt Pages : 18 Date : 23-Oct-00 This document describes the encoding and procedures for three new LDP messages, the Query Message and Query-Reply Message and Partial Query-Reply Message (the last one is almost identical to the Query- Reply message; therefore all references to the Query-Reply messages imply the Partial Query-Reply messages as well, unless otherwise specified). An LER sends a Query message when it needs to find out information about an LSP. The Query message is sent for an established LSP. The Query message can be used for LDP LSPs as well as for CR-LSPs. The queried data is encoded into the Query-Reply messages. The Query Message carries only the list of hops. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-00.txt 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-lsp-query-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-query-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001023112409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-query-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-query-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001023112409.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Oct 24 07:20:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20312 for ; Tue, 24 Oct 2000 07:20:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmgz04299; Tue, 24 Oct 2000 11:20:05 GMT Received: by mail-control.mail.uu.net id QQjmgz24998 for mpls-outgoing; Tue, 24 Oct 2000 11:19:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmgz24993 for ; Tue, 24 Oct 2000 11:19:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmgz08787; Tue, 24 Oct 2000 11:19:26 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjmgz24871; Tue, 24 Oct 2000 11:19:26 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Tue, 24 Oct 2000 11:51:47 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id <4C8FW63W>; Tue, 24 Oct 2000 11:51:41 +0100 Message-ID: To: bhandari1@lucent.com, kireeti@juniper.net Cc: sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Tue, 24 Oct 2000 11:51:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Ramesh thanks.....I was going to write back to Kireeti and say the key points of my mail were ignored/unanswered by the snipped extract....however, you have addressed them here. Others have also pointed out the impossibility of 'knowing to the duct' in all networks....esp for NNI case, ie includes both layering and partitioning. neil > -----Original Message----- > From: Ramesh Bhandari [SMTP:bhandari1@lucent.com] > Sent: Tuesday, October 24, 2000 12:32 AM > To: Kireeti Kompella > Cc: neil.2.harrison@bt.com; sc@tellium.com; xuyg@lucent.com; > yxue@UU.NET; ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > Hi Kireeti, > > I think the problem you are trying to pose pertains to the calculation of > the > pair of disjoint paths from A to B through an intemediate OTN network. The > solution consists of three parts: > > 1) Calculate diverse paths from A to ingress points X and W, i.e., path A > to X > and path A to W, which are physically-disjoint from each other, except at > the > common source point A > 2) Calculate two disjoint paths paths through the OTN network connecting > the > ingress points X and W to the egress points Y and Z (two possibilities > arise in > general: the diverse paths within the OTN are i) X to Y and W to Z ii) X > to Z > and W to Y) > 3) Calculate paths Y to B and Z to B, which are diverse from each other, > except > at the end point B. > > For A to do all the calculation would require a massive amount of data at > B, > including all the necessary details of the (physical) OTN ( not to mention > the > fact that in a catastrophic disaster like a fiber cable cut, thousands of > LSP's > with different pairs of endpoints would be affected simultaneoulsy, and > need to > be also restored simultaneously by the routers for fast restoration). > > In the Overlay/Client model, the requests are received at the ingress > points X > and W from the router A, and diverse paths are computed within the OTN, > using > network information at each of the OXC controllers (basically part 2 above > of > the solution for the peer model). > > Regards, > > Ramesh > > PS Algorithms for finding disjoint paths of the type - parts 1), 2) and 3) > of > thesolution above- exist, and can be found in my book "Survivable Networks > - > Algorithms for Diverse Routing", Kluwer Academic Publishers (1999). > > Kireeti Kompella wrote: > > > > > Suppose router A wants to get to router B, and wants to take two > > > > different ingress and egress points in the optical domain, X->Y > > > > for the primary LSP, and W->Z for the backup. A does not require > > > > optical protection for the X->Y path, nor for the W->Z path. A > > > > *does* require that the X->Y path and the W->Z path do not share > > > > common links. How is this to be done? > > > > > > > > If A did the full path computation, this is simplicity itself. > > > > > > > NH=> Kireeti, I don't this can be a general answer. The request > > > (from whatever the client) is for two phyically disjoint paths between > two > > > points A and B. > > > > Neil, A *is* the client. And A wants two disjoint paths to B via > > *different ingress points in the OTN*. This is a very reasonable > > request. > > > > Also, A doing a full path computation is *not* a general answer. > > It is an illustration of an advantage of the peer model, and of > > routers doing a full path computation across the OTN. To achieve > > what A wants in an overlay/client/UNI model would require a fair > > amount of work in extending routing/signalling/UNI protocols. > > > > Kireeti. From owner-mpls@UU.NET Tue Oct 24 07:24:39 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21239 for ; Tue, 24 Oct 2000 07:24:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmgz09752; Tue, 24 Oct 2000 11:24:16 GMT Received: by mail-control.mail.uu.net id QQjmgz25282 for mpls-outgoing; Tue, 24 Oct 2000 11:23:55 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmgz25268 for ; Tue, 24 Oct 2000 11:23:46 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmgz20604 for ; Tue, 24 Oct 2000 11:23:43 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjmgz00047 for ; Tue, 24 Oct 2000 11:23:43 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Tue, 24 Oct 2000 11:51:43 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id <4MC6HD62>; Tue, 24 Oct 2000 11:51:38 +0100 Message-ID: To: chasmith9@hotmail.com, mpls@UU.NET Subject: RE: LSP failure detection Date: Tue, 24 Oct 2000 11:51:32 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Chas, you asked: > Can someone please explain the mechanisms involved to detect a node or > link > failure within a particular LSP? NH=> There are 3 main areas that need defect detection: - nodal internal failures (which may or may not be traffic affecting) - user-plane failures (which are invariably traffic affecting) - control-plane failures (which may or may not be traffic affecting) 1st is usually a proprietary issue for the manufacturer and is usually not subject to standardisation (2nd and 3rd are however, since we need to interwork). 2nd has not really been addressed yet for the MPLS layers (each nested LSP is a layer network in its own right) Defects deteceted in server layers below the lowest LSP (eg SDH) would result in AIS being passed, as the Forward Defect Indicator (FDI), to the MPLS layers. However, as yet the MPLS layers do not have a method of recursing the FDI through their own stack and on the ultimate client. Some potential failure modes here are: simple LSP breaks, swapped LSPs, mismerged LSPs (various scenarios) and self-mismerged LSPs. Hopefully some of these should(?) be rare, but if they occur have implications ranging from simple avail/QoS SLA violation through security (ie leaking VPN traffic into Internet say), censorship and misbilling. I am looking at definitions for these at present and the entry/exit criteria and consequent actions. 3rd has been addressed in some detail within the signalling (eg LDP, RSVP) and discovery/routing (ie IGP) protocols. To date IETF has majored only on control-plane failures since a 1:1 routing congruence has been assumed with the user-plane. This congruence should not always be assumed however at the routing level (esp for flexible solutions , and almost forced when considering technologies like the OTN), and in any case different internal nodal processing is used so the user and control planes can have different failure mechanisms where one plane is not aware of failures in the other. Further, when considering restoration, user-plane detected defects need a close association with the control-plane to instigate prot-sw actions. > How can MPLS as a technology guarantee < 1 > second LSP failure restoration (contrast to SONET)? I need to understand > exactly how a failure is detected, how the backup path is activated or how > > fast re-route directs the LSP around the link or node failure. NH=> Why do you want restoration so fast? The basic rule is that the further you are aware from the duct the slower the restoration required......if not, then the whole thing becomes not only unmanageable, but not cost-effective and may be counter-productive. For protocols interfacing with applications one first needs to ask about the tolerance of the applications. I know of few applications that really need sub-1s restoration (nice, but certainly not essential). This is certainly true if humans involved. If data devices involved, then one should seriously question the robustness of the application protocol....much cheaper to fix this than to try and engineer faster and faster restoration as one moves down the stack to the duct. Further, the speed at which one can prot-sw is also a function of the resolution of the defect detection mechanism employed. These can be very fast at the lower layer transport networks, eg line level (such as loss of electrical or optical signal), but can be quite slow at the higher layers nearer to applications, eg if a keepalive with a 1 second period was used then the best detection period one could realistically use would be about 3 seconds (to have any sort of confidence in avoiding false triggering). Note: When I studied the error distributions in networks (albeit some time ago) I was amazed to learn how many 1-3s events there were and from which the network self-recovered. Not sure if still true today, but (as I said) restoration at the top level should be determined by *real* application needs......then one has to get faster as we move towards the duct. So don't start too fast at the top if you want nested prot-sw schemes to work in a sensible/cost-effective manner. From owner-mpls@UU.NET Tue Oct 24 10:29:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03070 for ; Tue, 24 Oct 2000 10:29:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhl08891; Tue, 24 Oct 2000 14:28:21 GMT Received: by mail-control.mail.uu.net id QQjmhl16776 for mpls-outgoing; Tue, 24 Oct 2000 14:28:01 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmhl16765 for ; Tue, 24 Oct 2000 14:27:56 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmhl26587 for ; Tue, 24 Oct 2000 14:27:47 GMT Received: from rly-ip01.mx.aol.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip01.mx.aol.com [205.188.156.49]) id QQjmhl29666 for ; Tue, 24 Oct 2000 14:27:47 GMT Received: from cm-ta4.proxy.aol.com (cm-ta4.proxy.aol.com [152.163.205.44]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id KAA01731; Tue, 24 Oct 2000 10:27:45 -0400 (EDT) Received: from cs.columbia.edu (AC906CEC.ipt.aol.com [172.144.108.236]) by cm-ta4.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e9OEPHZ17126; Tue, 24 Oct 2000 10:25:17 -0400 (EDT) Message-ID: <39F59AB5.DCD4D8A@cs.columbia.edu> Date: Tue, 24 Oct 2000 10:20:37 -0400 From: Ping Pan Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ytr@csa.iisc.ernet.in CC: mpls@UU.NET Subject: Re: COPS doubt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPPan@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The way I view the use of COPS in MPLS networking environment is the same as RIPE being used for BGP route filters in the backbone today. ISP's can define a bunch of TE policies to map user traffic to some MPLS LSP's at the network edge. That information is sent to the edge routers (LSR's or PEP's) via COPS, where a COPS PDP is a UNIX box sitting at NOC somewhere running COPS daemon. When something is wrong, the LSR's can notify the PDP via COPS too. But, IMH, here is something more: 1. COPS PEP should not be put on every routers, only border/edge ones at best. 2. COPS distributes policies only, and is not a signaling mechanism to select bandwidth, labels, routing path... 3. People can setup the policy entries from the routers directly without using COPS. 4. If people actually deploy SNMP with security and set/trap functionality, that would work too. Here is a badly out-dated web page on an out-dated ID: http://www.cs.columbia.edu/~pingpan/projects/policy_cu.html - Ping "Y.T. Ramanjaneyulu" wrote: > > HI, > > I am currently working on a Project which involves developing a Label > Switched router in a MPLS domain.The core protocols which are used in this > work are MPLS as the forwarding mechanism and RSVP-TE as the signalling > Protocol.Main intention of ours is to provide Qos services to the end users in MPLS > domain. > > I thought of having a Resource manager inside each LSR to manage the > resources locally. We have policies to allow user to consume only certain amount of > bandwidth etc. > > PDP generally situated in some remote machine and collecting statistics > from allclients and making descisions . > > So in our scenario is it necessary to have a PEP and a PDP (COPS > Protocol) inside the network ??? > > > Thanx in advance > > -- > Regards > YTR > From owner-mpls@UU.NET Tue Oct 24 10:49:13 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05874 for ; Tue, 24 Oct 2000 10:49:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhn05372; Tue, 24 Oct 2000 14:47:40 GMT Received: by mail-control.mail.uu.net id QQjmhn19360 for mpls-outgoing; Tue, 24 Oct 2000 14:47:20 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmhn19348 for ; Tue, 24 Oct 2000 14:47:11 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmhn10008 for ; Tue, 24 Oct 2000 14:46:56 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjmhn24608 for ; Tue, 24 Oct 2000 14:46:51 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id UAA01637 for ; Tue, 24 Oct 2000 20:14:57 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id UAA22546 for ; Tue, 24 Oct 2000 20:16:47 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Tue, 24 Oct 2000 20:16:47 +0530 (IST) From: Gaitonde Anandprasanna Reply-To: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Query about COPS USAGE in MPLS DOMAIN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I am currently working on a Project which involves setting up the software running in a LSR with support for Traffic Engineering. The core protocols involved are MPLS and signalling thru RSVP-TE But to achieve traffic engineering we also need to incorporate the policy info in the routers. Let say that policy info is stored at a central PDP Now when we are talking about TE environment we have to keep tha current usage of each LSPs, The maximaum bandiwdth an LSP can support etc . Now i want to know whether this info has to be stored at the PDP or at the local LSR itself. That is any info about resources used by any LSR stored at the PDP ???? I am confused THankx in advance Yours sincerely PRAS _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Tue, 24 Oct 2000 11:17:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhp03812; Tue, 24 Oct 2000 15:15:23 GMT Received: by mail-control.mail.uu.net id QQjmhp03574 for mpls-outgoing; Tue, 24 Oct 2000 15:15:00 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmho03539 for ; Tue, 24 Oct 2000 15:14:48 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmho19622 for ; Tue, 24 Oct 2000 15:13:42 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjmho11268 for ; Tue, 24 Oct 2000 15:13:42 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA12259 for ; Tue, 24 Oct 2000 11:12:03 -0400 (EDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA19102 for mpls@uu.net; Tue, 24 Oct 2000 11:08:45 -0400 (EDT) Received: from neserve0.corp.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.92.148]) id QQjmhg20414 for ; Tue, 24 Oct 2000 13:04:24 GMT Received: from localhost by neserve0.corp.us.uu.net with ESMTP (peer crosschecked as: yxue@localhost) id QQjmhg28685; Tue, 24 Oct 2000 09:04:24 -0400 (EDT) Date: Tue, 24 Oct 2000 09:04:24 -0400 (EDT) From: Yong Xue X-Sender: yxue@neserve0.corp.us.uu.net To: Yangguang Xu cc: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-Reply-To: <39F447EF.3E04007@lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Yangguang, It's for traffic engineering purpose. As an ISP, ip service is provided and routers know where and when the new cross-OTN connections are needed assuming they have all the intelligentce. /Yong On Mon, 23 Oct 2000, Yangguang Xu wrote: > Hi, Yong > > A question on your comments. > > > (router determines the explicit routes). > > This point has been raised by several folks. It really confuses me. If the > optical switches are equipped with path calculation ability, what's the benefit > to bother router to determine the explicit routes within optical domain > (assuming router can be smart enough to handle all optical network specific > attributes and constrains) than just have routers to determine the end points of > optical trails. > > Thanks, > > Yangguang > From owner-mpls@UU.NET Tue Oct 24 11:19:14 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10499 for ; Tue, 24 Oct 2000 11:19:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhp07573; Tue, 24 Oct 2000 15:17:18 GMT Received: by mail-control.mail.uu.net id QQjmhp04061 for mpls-outgoing; Tue, 24 Oct 2000 15:16:48 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmhp04028 for ; Tue, 24 Oct 2000 15:16:40 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmhp26323 for ; Tue, 24 Oct 2000 15:16:39 GMT Received: from syd-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: syd-msg-core-1.cisco.com [144.254.150.253]) id QQjmhp15135 for ; Tue, 24 Oct 2000 15:16:36 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by syd-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id BAA08970 for ; Wed, 25 Oct 2000 01:16:33 +1000 (EST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA19117 for mpls@uu.net; Tue, 24 Oct 2000 11:09:56 -0400 (EDT) Received: from neserve0.corp.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.92.148]) id QQjmhh26816 for ; Tue, 24 Oct 2000 13:15:31 GMT Received: from localhost by neserve0.corp.us.uu.net with ESMTP (peer crosschecked as: yxue@localhost) id QQjmhh00641; Tue, 24 Oct 2000 09:15:30 -0400 (EDT) Date: Tue, 24 Oct 2000 09:15:30 -0400 (EDT) From: Yong Xue X-Sender: yxue@neserve0.corp.us.uu.net To: Sid Chaudhuri cc: "'Kireeti Kompella'" , xuyg@lucent.com, ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-Reply-To: <0CD7D73C734BD411AEE100B0D02204042B9492@mail1.tellium.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Sid, You are correct. The requirement for connection is generated from router and it can be serviced by network in the overlay model or by the router if it's peer model. /Yong On Mon, 23 Oct 2000, Sid Chaudhuri wrote: > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Based on its traffic flow a router only needs to know between > which > two routers it needs to establish a new lightpath. How the lightpath is > routed in the > optical layer seems to me irrelevant to TE. > > Sid Chaudhuri > > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > From owner-mpls@UU.NET Tue Oct 24 11:22:54 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10921 for ; Tue, 24 Oct 2000 11:22:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhp09971; Tue, 24 Oct 2000 15:19:39 GMT Received: by mail-control.mail.uu.net id QQjmhp04250 for mpls-outgoing; Tue, 24 Oct 2000 15:19:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmhp04236 for ; Tue, 24 Oct 2000 15:19:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmhp28688 for ; Tue, 24 Oct 2000 15:18:05 GMT Received: from ams-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQjmhp07640 for ; Tue, 24 Oct 2000 15:18:05 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by ams-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA07855 for ; Tue, 24 Oct 2000 17:15:00 +0200 (MET DST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA19130 for mpls@uu.net; Tue, 24 Oct 2000 11:11:27 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmhl16163 for ; Tue, 24 Oct 2000 14:22:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmhl23297; Tue, 24 Oct 2000 14:21:57 GMT Received: from ckmso1.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ckmso1.att.com [12.20.58.69]) id QQjmhl00177; Tue, 24 Oct 2000 14:21:57 GMT Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA29367; Tue, 24 Oct 2000 10:21:33 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA17892; Tue, 24 Oct 2000 10:20:30 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 24 Oct 2000 10:21:32 -0400 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F403240539@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Holmes, David A.'" , Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET Cc: kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Tue, 24 Oct 2000 10:21:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk David, From our perspective, having the tools to support sub-minute automated provisioning of circuits is one of the main drivers of this work. This is one of the reasons that drives us to push for support of multiple clients by the control plane optical network. Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Holmes, David A. [mailto:David.A.Holmes@disney.com] Sent: Monday, October 23, 2000 3:19 PM To: Mark.Jones@mail.sprint.com; ip-optical@lists.bell-labs.com; mpls@UU.NET Cc: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh I have not been following this entire thread either, but as an Enterprise customer, I take issue with the following remarks: "... The availability and BER are all a customer wants or needs. If I can give you 99.999% availability (or whatever availability you want to pay for) with a BER to satisfy your needs, why do you care whether I use ring, mesh, or some other scheme? Grade of service is sufficient." In addition to availability, what is critical to this customer is reasonable circuit provisioning lead times. It is not uncommon to wait 6 months for a DS3 or higher speed circuit to be provisioned. The Sprints, MCIs, AT&Ts, etc. appear to believe that this is business as usual, and is acceptable to the customer. From the customer's standpoint, time is money. My understanding of the IP/MPLambdaS mesh model proposals, is that optical transport network circuit provisioning can be done in seconds. Fast provisioning is a necessary requirement in my view. David Holmes -----Original Message----- From: Mark.Jones@mail.sprint.com [mailto:Mark.Jones@mail.sprint.com] Sent: Monday, October 23, 2000 11:22 AM To: ip-optical@lists.bell-labs.com; mpls@UU.NET Cc: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh [I haven't had time to follow this entire thread, so please correct me if I'm off track with the discussion.] Zhi and Sid are correct. I have trouble seeing any kind of peering model fitting in a multi-client network like Sprints, so I come with that assumption. For an overlay or client model, the specification of protection types doesn't make sense across the UNI. We argued this point at the OIF in Barcelona. Carriers have their own schemes for providing the protection for services, and every implementation of the different architectures provide different results. What I mean is that a Sprint ring network, deployed over our fiber plant using equipment from vendor X, will give you different availability than a ring in another carrier's network using their fiber plant and vendor Y. That's just one example. The availability and BER are all a customer wants or needs. If I can give you 99.999% availability (or whatever availability you want to pay for) with a BER to satisfy your needs, why do you care whether I use ring, mesh, or some other scheme? Grade of service is sufficient. What is needed is standardization of the service grades, so Gold service is the same thing across every network (independent of the unlying protection architecture). Though I haven't followed the details, I seem to remember seeing work on this in another standards body. Mark Loyd Jones Sprint Technology Planning & Integration 913-534-5247 mark.jones@mail.sprint.com > -----Original Message----- > From: zwlin [mailto:zwlin@lucent.com] > Sent: Monday, October 23, 2000 11:17 AM > To: sc > Cc: zwlin; kireeti; xuyg; yxue; ip-optical; mpls > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > Hi Sid, > > And to generalize even further, if a service provider sets up three > grades of service (e.g., bronze, gold, platinum), the protection > information should already be embedded within those service > grades. For > example, bronze is no protection at all, gold is dynamic mesh > restoration, and platinum is 1+1 protection. > > I think what is most important to a service provider and > their customers > are the availability of the connection, i.e., is the connection up > 99.99% or 99.999% or some other number. How the service > provider chooses > to handle how to meet that availability number is up to the service > provider and their TE. > > Am I mis-representing the service provider here? Maybe some service > providers can comment on whether the above description sounds right??? > > Thanks > Zhi > > > Sid Chaudhuri wrote: > > > > I don't see why TE and protection require the routers to > specify explicit > > routes. > > The routers can simply specify to the optical layer what > type of optical > > layer protection > > it requires. Based on its traffic flow a router only needs > to know between > > which > > two routers it needs to establish a new lightpath. How the > lightpath is > > routed in the > > optical layer seems to me irrelevant to TE. > > > > Sid Chaudhuri > > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Monday, October 23, 2000 11:43 AM > To: xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. > Was Re: DraftMinutes From Pittsburgh > > Hi, > > > > (router determines the explicit routes). > > > > This point has been raised by several folks. It really > confuses me. If the > > optical switches are equipped with path calculation > ability, what's the benefit > > to bother router to determine the explicit routes within > optical domain > > (assuming router can be smart enough to handle all optical > network specific > > attributes and constrains) than just have routers to > determine the end points of > > optical trails. > > Why does this confuse you? Routers may want to determine > the exact > path that their LSPs take for a number of reasons, including > TE and > protection. If a router doesn't care where its LSPs are > laid out, > it can install loose hops at the boundaries of the optical > cloud. > > Kireeti. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Tue Oct 24 11:29:57 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12025 for ; Tue, 24 Oct 2000 11:29:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhp21838; Tue, 24 Oct 2000 15:28:02 GMT Received: by mail-control.mail.uu.net id QQjmhp05371 for mpls-outgoing; Tue, 24 Oct 2000 15:27:23 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmhp05363 for ; Tue, 24 Oct 2000 15:27:19 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmhp14443 for ; Tue, 24 Oct 2000 15:24:29 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmhp25693 for ; Tue, 24 Oct 2000 15:24:28 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA02511 for mpls@uu.net; Tue, 24 Oct 2000 11:24:27 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmhp03962 for ; Tue, 24 Oct 2000 15:16:25 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmhp25425 for ; Tue, 24 Oct 2000 15:16:14 GMT Received: from stl-smtpout-01.boeing.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: stl-smtpout-01.boeing.com [12.13.247.21]) id QQjmhp14623 for ; Tue, 24 Oct 2000 15:16:14 GMT Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA28337 for ; Tue, 24 Oct 2000 10:16:13 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id KAA24777 for ; Tue, 24 Oct 2000 10:16:11 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Tue, 24 Oct 2000 10:16:07 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 11:16:06 -0400 Message-Id: <4102273CEB77D211869200805FE6F593018C5AF7@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Lazer, Monica A, NNAD'" , ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Tue, 24 Oct 2000 11:15:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I guess I'm missing this speed argument that's been made twice today. Why would one expect that optics by itself can change the speed with which bandwidth is provisioned? Surely if tools can be deployed to rapidly provision bandwidth using lambda as the knob, similar tools can provision bandwidth about as quickly using other knobs? Like ATM PVCs, SONET pipes, LSPs? Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Lazer, Monica A, NNAD [mailto:mlazer@att.com] > > David, > From our perspective, having the tools to support sub-minute automated > provisioning of circuits is one of the main drivers of this > work. This is > one of the reasons that drives us to push for support of > multiple clients by > the control plane optical network. > > Monica A. Lazer > Advanced Transport Technology and Architecture Planning > > 908 234 8462 > mlazer@att.com From owner-mpls@UU.NET Tue Oct 24 11:56:31 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17824 for ; Tue, 24 Oct 2000 11:56:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhr00651; Tue, 24 Oct 2000 15:55:03 GMT Received: by mail-control.mail.uu.net id QQjmhr08359 for mpls-outgoing; Tue, 24 Oct 2000 15:54:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmhr08354 for ; Tue, 24 Oct 2000 15:54:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmhr18647 for ; Tue, 24 Oct 2000 15:53:52 GMT Received: from cowansville.acbm.qc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjmhr28799 for ; Tue, 24 Oct 2000 15:53:50 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca; Tue, 24 Oct 2000 11:53:43 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id <4GAKAZ0J>; Tue, 24 Oct 2000 11:53:22 -0400 Message-ID: <91E486361D4CD311B3140060089A882556A4A4@hermes.hyperchip.com> From: Eyad Saheb To: "'Charles Smith'" Cc: "'mpls@UU.NET'" Subject: RE: LSP failure detection Date: Tue, 24 Oct 2000 11:53:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DD2.8703E5E0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03DD2.8703E5E0 Content-Type: text/plain; charset="iso-8859-1" There're a few ways to do it. Detection: # Hardware notifies you of a failure # Software detects a failure through keep-alives, time-outs, etc... Protection: # A pre-computed path is ready for switch-over # A new path is computed at fail-time Hardware notification is obviously the better choice for detection purposes, since software keep-alives have longer time-outs to reduce bandwidth consumption. With repect to protection, a pre-computed path is the fastest, however it might not have the most up-to-date information. Eyad -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Charles Smith Sent: Monday, October 23, 2000 9:10 PM To: mpls@UU.NET Subject: LSP failure detection MPLS list: Can someone please explain the mechanisms involved to detect a node or link failure within a particular LSP? How can MPLS as a technology guarantee < 1 second LSP failure restoration (contrast to SONET)? I need to understand exactly how a failure is detected, how the backup path is activated or how fast re-route directs the LSP around the link or node failure. I am just a marketing guy who has read the drafts and still needs the engineers to explain the concepts :-) Cheers. Chas _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. ------_=_NextPart_001_01C03DD2.8703E5E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: LSP failure detection

There're a few ways to do it.

Detection:

        # Hardware = notifies you of a failure
        # = Software detects a failure through keep-alives, time-outs, = etc...

Protection:

        # A = pre-computed path is ready for switch-over
        # A new = path is computed at fail-time

Hardware notification is obviously the better choice = for detection purposes, since software keep-alives have longer = time-outs to reduce bandwidth consumption.  With repect to = protection, a pre-computed path is the fastest, however it might not = have the most up-to-date information.

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Charles
Smith
Sent: Monday, October 23, 2000 9:10 PM
To: mpls@UU.NET
Subject: LSP failure detection


MPLS list:

Can someone please explain the mechanisms involved to = detect a node or link
failure within a particular LSP? How can MPLS as a = technology guarantee < 1
second LSP failure restoration (contrast to SONET)? = I need to understand
exactly how a failure is detected, how the backup = path is activated or how
fast re-route directs the LSP around the link or = node failure.

I am just a marketing guy who has read the drafts and = still needs the
engineers to explain the concepts :-)

Cheers.

Chas
_______________________________________________________________= __________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own = public profile at
http://profiles.msn.com.

------_=_NextPart_001_01C03DD2.8703E5E0-- From owner-mpls@UU.NET Tue Oct 24 11:58:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18271 for ; Tue, 24 Oct 2000 11:58:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhr02932; Tue, 24 Oct 2000 15:57:06 GMT Received: by mail-control.mail.uu.net id QQjmhr08563 for mpls-outgoing; Tue, 24 Oct 2000 15:56:46 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmhr08556 for ; Tue, 24 Oct 2000 15:56:43 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmhr25695 for ; Tue, 24 Oct 2000 15:55:20 GMT Received: from web5103.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web5103.mail.yahoo.com [216.115.106.73]) id QQjmhr00390 for ; Tue, 24 Oct 2000 15:55:19 GMT Message-ID: <20001024155519.19014.qmail@web5103.mail.yahoo.com> Received: from [169.144.16.187] by web5103.mail.yahoo.com; Tue, 24 Oct 2000 08:55:19 PDT Date: Tue, 24 Oct 2000 08:55:19 -0700 (PDT) From: Chatur sharp Subject: Re: [Diffserv] RFC2597 To: Brian E Carpenter Cc: diffserv@ietf.org, mpls@UU.NET, jh@telia.fi, fred@cisco.com, wweiss@lucent.com, jtw@lcs.mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Thanks for your comments. But... How about EF? Following is a flick from the EF definition RFC2598. " The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. " Now I do agree SHOULD is not same as MUST. But given the scenario I have drawn how do you meet this recommended requirement, over the time scales mentioned in the RFC? To me DIFFSERV would be fine if we take away the policing part. There is no need for a meter. Only scheduler is enough. The kind of link level rate limiting you are talking about in DIFFSERV will fall apart once you have network with different link speeds. To me DIFFSERV seems like an attempt to divide one network into as many networks as the number of DIFFSERV classes, with resources being allocated to each of them? This a sub-optimal use of network resources and does not provide any garuntees which a lot of applications need. Anyhow phrases like : " The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. " Do not make any sense, till the time you specify what is the meaning of transit. Does it mean that traffic coming on interface i and going out of interface j will have this commitment? If so it is fine, else it is losing too much by coarse graining everything. IMHO, DIFFSERV should provide an option to let PHBs be associated to destination addresses or egress points through a network if needed. It will still allow diffserv to work in the manner it is working today and will also enable SPs to provide garuntees which are required by some of the real-time applications Finally, I think the DIFFSERV-MPLS approach is the right approach as it really takes into account need of all kinds of traffic rather than just the traditional IP services. Thanks C. --- Brian E Carpenter wrote: > Hi, > > You say > > "Now the AF class definition says that the domain > Y > and hence node B must provide garuntee that as > long > as traffic coming from A is green it MUST forward > it reliably." > > I'm sorry, but RFC 2597 says nothing of the kind. It > says things like > > > An AF implementation MUST detect and respond to > long-term congestion > > within each class by dropping packets, while > handling short-term > > congestion (packet bursts) by queueing packets. > > which shows clearly that reliable forwarding is > *not* part of the > AF definition. The traffic engineering for services > based on AF is > statistical, and obviously requires statistical > estimates of traffic > per egress, but there are no guarantees. > > Brian Carpenter > diffserv co-chair > > > Chatur sharp wrote: > > > > Hi folks, > > > > This mail is regards the policing and providing > > QoS garruntees part of DIFFSERV. I have a feeling > > that the current definition of PHBs is incomplete > to > > implement the AFx as well as the EF class. This is > > because in the PHB definition the destination of > > a flow is not taken into account. > > > > For example let us consider a simple network confg > > as shown below: > > > > Domain| Domain > > X | Y > > | > > | > > A ----|---B ---- C > > | \ > > | \___D > > > > > > In this setup domain X and domain Y are connected > > via link AB. Both these domains are independent > > DIFFSERV domain. Let us consider traffic entering > > domain Y( ingress node B) through domain X ( > egress > > node B). > > > > Now the AF class definition says that the domain Y > > and hence node B must provide garuntee that as > long > > as traffic coming from A is green it MUST forward > > it reliably. For example, let us say that the SLA > > between node B and node A garuntees that as long > > as traffic flowing is less than 200MB per sec it > > will treat it as green. But if A doesnot specify > > the destination of its traffic than B would be > > forced to allocate this much of bandwidth along > all > > its link ( if it is to meet the MUST transfer it > > reliably requirement). This to me seems a little > > bizarre. Usually for CAC and traffic engineering > > you should know the endpoints. > > > > To me it seems that DIFFSERV is not useful as a > > traffic engineering tool as long as it is not > > combined with something like MPLS or it does not > > start including end points for identifying flows. > > > > To me an SLA between any two domains MUST mention > > the destination address or no garuntees can be > > provided and the traffic would be best effort. > > > > However, I do believe that in case, there is no > CAC > > and hence policing to be performed then DIFFSERV > can > > be used to prioritize traffic like in regular > > CoS-IP world. > > > > Any comments > > thanks > > C. > > > > ===== > > I am willing to learn, if you care to teach. > > I am willing to teach, if you care to learn. > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Messenger - Talk while you surf! It's > FREE. > > http://im.yahoo.com/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > ===== I am willing to learn, if you care to teach. I am willing to teach, if you care to learn. __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ From owner-mpls@UU.NET Tue Oct 24 12:23:30 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23770 for ; Tue, 24 Oct 2000 12:23:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmht09086; Tue, 24 Oct 2000 16:22:39 GMT Received: by mail-control.mail.uu.net id QQjmht22591 for mpls-outgoing; Tue, 24 Oct 2000 16:22:00 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmht22563 for ; Tue, 24 Oct 2000 16:21:46 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmht26817 for ; Tue, 24 Oct 2000 16:21:17 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmht06696 for ; Tue, 24 Oct 2000 16:21:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA12449 for mpls@uu.net; Tue, 24 Oct 2000 12:21:15 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmht22464 for ; Tue, 24 Oct 2000 16:20:55 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmht17039 for ; Tue, 24 Oct 2000 16:20:49 GMT Received: from miles.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.datcon.co.uk [192.91.191.8]) id QQjmht06077 for ; Tue, 24 Oct 2000 16:20:48 GMT Received: by miles.dataconnection.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 17:20:42 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA58F@monk.datcon.co.uk> From: Adrian Farrel To: manis@future.futsoft.com Cc: mpls@UU.NET Subject: RE: Doubts, Clarifications requested for draft-ietf-mpls-ldp-ft-0 0.txt Date: Tue, 24 Oct 2000 17:20:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Mani, >I read through the draft-ietf-mpls-ldp-ft-00.txt. Thanks for your interest in the draft. >I have a few doubts and can you please clarify? > >1) In the section 7 Example Use Page 21, in (12) we have > > LDP Init(n/a,n/a,95) > ---------------------------> > >This should mean that P1 indicates that it has secured >messages with sequence number until 95. > >Subsequently we have in (14) > Label Mapping(L2,95,-) > <--------------------------- > >Is this correct? Since 95 has been given by P1, is it not >sufficient that p2 provides only the Label Abort message >which is given next in (14)? Correct. To comply with the text accompanying the example, the LDP Init should ack only up to 94. I will update the diagram. >2) In Section 4.4 Page 12, Second Paragraph. "Hold Timer" >has been mentioned. I am not sure of this "Hold Timer". >Is this the Hello Hold Timer (Section 2.5.5 in ldp-11 draft)? It is. There names are used interchangeably in LDP-11. I will add a reference for clarity. >3) Does > "The Hold Timer for an FT LDP Session SHOULD be ignored >while the FT > Reconnection Timer is running" mean that the hello >messages need not be expected from the Peer during the >Reconnection time? Correct. They need not be expected, but they could be received. You could view the Reconnection Timer as replacing the Hold Timer for the period immediately after failure. >4) I am not clear with the advantage meant in the statement > "This ensures that network resources are not permanently > lost by one LSR if its LDP peer is forced to undergo a cold start." >in page 8. > >My confusion is, when a LDP Peer P1 is made to undergo a >cold start, the TCP session will be initiated again >with "FT Reconnect Flag set to 0". This will cause the other >LDP Peer P2 to release all the information. Precisely. All we are saying is that if this rule did not exist there would be a risk that the peer that stayed up would retain resources that are no longer valid. The statement is necessary since we are replacing the rule about releasing resources when the TCP session fails. >5) What should be done in case of receipt of a "FT ACK Sequence >Error"? This is generated by a Peer P1 to P2 when it receives >an out of sequence ACK from P2. Well, the most probable solution is to fix the code :-) Section 6.1 shows that the E-bit must be set for this status code, indicating that this is a fatal error as defined by LDP-11. LDP-11 says... 1. Error notifications, used to signal fatal errors. If an LSR receives an error notification from a peer for an LDP session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all label mappings learned via the session. >6) When do we generate Notification with Status code > " FT Sequence Numbers Exhausted" Good point, missing text. The answer is simple. When an implementation determines that it is unable to allocate a sequence number to a message because it has none available. This might be because they are all unacked by the peer, or because it fears that to allocate another one would cause wrapping confusion, or because it is implemented with a fixed size array of un-acked seq nos. >7) It has been mentioned (very clearly) in the second >paragraph in Section 4.4, that the Reconnection timeout is >an implementation choice. Will it be possible to indicate >the possible Reconnection timeout value? Yes, we will add a suggested value. >8) Let P1 and P2 are two LDP Peers. Let us assume > that P1 has transmitted a set of label requests > to P2. Can P2 provide a reply to one of the label > request messages LRQ1 from P1, without containing FT > ACK TLV? and if such a message is received by P1 > can P1 assume that the FT sequence number provided in > LRQ1 is secured at P2? Good question. Implicit acknowledgement. Personally I don't like it, and it can't be too much effort to add an Ack TLV to the response (e.g. Label Mapping). We will discuss this and get back to you. Regards, Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Tue Oct 24 12:54:16 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28446 for ; Tue, 24 Oct 2000 12:54:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhv19524; Tue, 24 Oct 2000 16:52:35 GMT Received: by mail-control.mail.uu.net id QQjmhv25805 for mpls-outgoing; Tue, 24 Oct 2000 16:52:02 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmhv25768 for ; Tue, 24 Oct 2000 16:51:55 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmhv04599 for ; Tue, 24 Oct 2000 16:50:43 GMT Received: from srnex01.sd.osicom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: srnex01.sd.osicom.com [131.143.32.21]) id QQjmhv16963 for ; Tue, 24 Oct 2000 16:50:42 GMT Received: by srnex01.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 09:41:51 -0700 Message-ID: <022A2DBC40A6D411967000D0B78892A61A95EB@srnex01.sd.osicom.com> From: "Zhang, Leah" To: "'Adrian Farrel'" , mpls@UU.NET Cc: lberger@labn.net, petera@nortelnetworks.com Subject: RE: draft-ietf-mpls-generalized-signaling-00.txt Date: Tue, 24 Oct 2000 09:41:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DD9.4EFA2DB0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03DD9.4EFA2DB0 Content-Type: text/plain; charset="iso-8859-1" Adrian posted a excellent set of questions. On the thread of suggested label and label set, it is not clear how they work together. In the draft, it says The Suggested Label is used to provide a downstream node with the upstream node's label preference; The Label Set is used to limit the label choices of a downstream node to a set of acceptable labels. It sounds like that the Suggested Label has to be chosen from the label set, otherwise it will be rejected. I think that it would be useful for the authors to clarify this in the draft. Regards, Leah Zhang -----Original Message----- From: Adrian Farrel [mailto:AF@dataconnection.com] Sent: Monday, October 23, 2000 11:11 AM To: mpls@UU.NET Cc: lberger@labn.net; petera@nortelnetworks.com Subject: draft-ietf-mpls-generalized-signaling-00.txt Lou and Peter, Thanks for a great job editing this and for getting it out into the public domain. I have a large block of comments and questions and bunch of minor typos. Please feel free to split the comments into separate threads if you like. Regards, Adrian Questions ========= Link Id and Explicit Routing I'm not sure how much this should be in Kireeti's bundling draft and how much in the Generalized draft. I have the following concern: - Suppose we use LSR addresses (i.e. not link addresses) in our explicit route and also use label sub-objects. Suppose further that there are multiple links of different types between a pair of LSRs. Finally consider that Label_Request is used, not Generalized_Label_Request. How does the LSR processing the ERO interpret the label and decide which link to apply it to? I guess you could say that you should avoid the combination of circumstances listed above and use G_L_R to constrain the link type or use the link address not the LSR address. Does that still work with unnumbered links? Error values etc. Can I suggest adding a section at the end as a place holder for new error values. In the text I have found - Routing Problem/Unsupported Encoding - Routing Problem/Unsupported Link Protection - Routing Problem/Unsupported GPID - Routing Problem/Unacceptable Label Value - Routing Problem/Label Set 3. Generalized Label Request Could you make it clearer right at the top of section 3 that for RSVP the Generalized_Label_Request is not a new object but a new variant of the Label_Request Object, whereas for CR-LDP it is a new TLV. 3.3.1 Waveband Switching "For compatibility reasons, a new RSVP c-type and CR- LDP type is assigned for the Waveband Label." This seems to be the only place in the draft where you haven't explicitly suggested values (subject to IANA). I think you have left gaps for RSVP c-type 3 and CR-LDP type 903. 3.5.1 Label Set It isn't clear how a sequence of subchannels that form a label set are conveyed. It can't be the case that you simply add multiple Subchannels to the Object/TLV since the Type is closely associated with each individual Subchannel. We should either define Label_Set as Explicit_Route with a sequence of subobjects. Or we should allow a series of Label_Sets in the Path/LABEL_REQUEST. In either case, it would be good to put in some motherhood about ordering the elements for clear interpretation. For example, suppose x RE: draft-ietf-mpls-generalized-signaling-00.txt

Adrian posted a excellent set of questions. On the = thread of suggested label and label set, it is not clear how they work = together. In the draft, it says

The Suggested Label is used to provide a downstream = node with the upstream node's label preference;

The Label Set is used to limit the label choices of a = downstream node to a set of acceptable labels.

It sounds like that the Suggested Label has to be = chosen from the label set, otherwise it will be rejected.

I think that it would be useful for the authors to = clarify this in the draft.

Regards,
Leah Zhang

-----Original Message-----
From: Adrian Farrel [mailto:AF@dataconnection.com]<= /FONT>
Sent: Monday, October 23, 2000 11:11 AM
To: mpls@UU.NET
Cc: lberger@labn.net; = petera@nortelnetworks.com
Subject: = draft-ietf-mpls-generalized-signaling-00.txt


Lou and Peter,

Thanks for a great job editing this and for getting = it out into the public
domain.

I have a large block of comments and questions and = bunch of minor typos.
Please feel free to split the comments into separate = threads if you like.

Regards,
Adrian

Questions
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Link Id and Explicit Routing
I'm not sure how much this should be in Kireeti's = bundling draft
and how much in the Generalized draft.  I have = the following
concern:

- Suppose we use LSR addresses (i.e. not link = addresses) in our
  explicit route and also use label = sub-objects.  Suppose further
  that there are multiple links of different = types between a pair
  of LSRs.  Finally consider that = Label_Request is used, not
  Generalized_Label_Request.
  How does the LSR processing the ERO interpret = the label and
  decide which link to apply it to?
  I guess you could say that you should avoid = the combination of
  circumstances listed above and use G_L_R to = constrain the link
  type or use the link address not the LSR = address.  Does that
  still work with unnumbered links?
 

Error values etc.
Can I suggest adding a section at the end as a place = holder for new error
values.
In the text I have found
- Routing Problem/Unsupported Encoding
- Routing Problem/Unsupported Link Protection
- Routing Problem/Unsupported GPID
- Routing Problem/Unacceptable Label Value
- Routing Problem/Label Set


3. Generalized Label Request
Could you make it clearer right at the top of = section 3 that
for RSVP the Generalized_Label_Request is not a new = object but a
new variant of the Label_Request Object, whereas for = CR-LDP it is
a new TLV.


3.3.1 Waveband Switching
"For compatibility reasons, a new RSVP c-type = and CR-
 LDP type is assigned for the Waveband = Label."
This seems to be the only place in the draft where = you
haven't explicitly suggested values (subject to = IANA).
I think you have left gaps for RSVP c-type 3 and = CR-LDP
type 903.


3.5.1 Label Set
It isn't clear how a sequence of subchannels that = form a
label set are conveyed.  It can't be the case = that you
simply add multiple Subchannels to the Object/TLV = since
the Type is closely associated with each individual =
Subchannel.
We should either define Label_Set as Explicit_Route = with
a sequence of subobjects.  Or we should allow a = series
of Label_Sets in the Path/LABEL_REQUEST.
In either case, it would be good to put in some = motherhood
about ordering the elements for clear = interpretation. For
example, suppose x<y<z.  Can I define the = label set
{x, x+1, ... , y-1, y+1, ..., z} using three = subchannels
(viz. start x, exclude y, end z) or must I use = four?


3.5.2 Label_Set Procedures
I suppose it is implicit, but there is no mention of = inserting
Label_Set for the first time.


4. Bidirectional LSPs
I think it would help to point out that the support = for
bidirectional LSPs added here is restricted to = certain levels
of symmetry
- the TSpec is the same in both directions
- the LSRs on the path are the same in both = directions
- the links between LSRs are not necessarily the = same in both
  directions.


Suggested_Label
Sorry if I missed this.
Must Suggested_Label be chosen from within the = Label_Set?


4.2 Bidirectional LSP Procedures
The choice you have made is consistent (that you may = not
propagate a Path containing Upstream_Label until the = local
switch has been programmed, so that the terminator = may start
sending data as soon as it has processed the Path) = but may
unnecessarily increase the latency of LSP set up = (compare
with the arguments for Suggested_Label).
If ResvConf were to be requested and used, the = individual
switch programming tasks could be processed in = parallel with
the propagation of the Path message.  The = terminator is not
allowed to start sending data until it receives the = ResvConf.
This is a direct trade-off, but could quite easily = reduce
setup time for individual LSPs.


4.3 Bidirectional LSP Contention Resolution
Note that action on receipt of a PathErr is in = contradiction
with RFC2205.  This is, however, the correct = function in the
situation described.


4.3 Bidirectional LSP Contention Resolution
The suggested behavior for reducing contention = depends on
adjacent LSRs knowing each other's node IDs.  = Does this
rely on Hello messages, carnal knowledge or = what?


5. Notification
Flag this at the top as being RSVP only.


5.1.2 Notify Request Procedures
We should add a statement about multiple instances = of this object.
The current discussion allows just a single = instance.


5.2.2 Notify Procedures
This version of the text does not prohibit the = Notify Node from
being other than the requester (i.e. initiator or = terminator).
We should either impose this for the time being, or = note that
the Notify Node might not support Notify messages = (and so will
not send an Ack).


5.2.2 Notify Procedures
It's not clear to me that the default time of 1ms = for combining
Notifies is relevant.


5.3 Removing State with PathErr
Note that the reference to RFC 2205 here is = obsoleted by the
actions required for bidriectional LSPs (see 4.3) = and by
processing that may be utilized for local repair and = fast
re-route.
In effect, RFC 2205's rules for forwarding PathErr = without
taking action have are already bent.


5.3 Removing State with PathErr

Can we add some text describing the Path state on = downstream
nodes when Path_State_Removed is used.  If I = receive PathErr
w/o P_S_R, am I allowed to remove Path state and = send PathErr
w/ P_S_R?

  
6.2 Procedures
The text listing the errors could do with some = cleaning.
The L-bit isn't the only issue here.  The = nature of the previous
sub-object can be strict but imprecise (i.e. a = non-unitary
abstract node .. prefix !=3D 32) or could be an = Autonomous System
number. In CR-LDP, the subobject could be an = LSPId.


Reporting explicit labels.
draft-ietf-mpls-rsvp-lsp-tunnel-07 has scope in the = RRO for
reporting labels, but this doesn't quite match the = ERO extensions
here.  In particular we need
- scope for two label objects per hop
- definition of the U bit
I believe that this should be in a new section = 6.3


Specifying links in EROs
I know we discussed this a bit before, but I want to = check that
we're in synch.
We're allowing the IP address subobject in an = explicit route to
identify an egress link rather than a next = hop.  It becomes a
local matter how such subobjects are handled.
We are not allowing specification of a link _and_ a = next hop. This
rules out parallel links in a multidrop = network.
We do not have the ability to specify an unnumbered = link.  This is
seen as illogical since the indexes of unnumbered = links have only
local (and possibly extending to the other end of = the link) meaning.


BNFs
Label_Set is optional





Trivial typos (haven't I got better things to = do?)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

page 4  for "ends on a LSC" read = "ends on an LSC"

page 5  for "traditional and and = non-PSC" read "traditional and non-PSC"

page 6  for "come from non-PSC" read = "comes from non-PSC"

page 7  for "as specific a LSP Encoding = Type" read "as specific an LSP
Encoding Type"

3.2.1.1 for "SDH and SONET define each" = read "SDH and SONET each define"

3.2.1.1 for "directly the distinction" read = "the direct distinction"

3.2.1.1 for "take part into the inverse" = read "take part in the inverse"

3.2.1.1 for "higher order signal need to = be" read "higher order signal needs
to be"

3.2.1.1 for "in the increasing order" read = "in increasing order"

3.5     for "there are a = sequence" read "there is a sequence"

4.3     for "since the label = sets are exchanged" read "if the label sets are
exchanged"

5.1.2   Notify Target Object should be = Notify Request Object (twice)

5.2     for "who's" = read "whose"

5.2     "Notify Ack" is = obsolete, read "Ack"

5.3     for "receiving such = a error" read "receiving such an error"

6.      for "This = occurs case when" read "This occurs in the case = when"

9.      strike = "Non-adjacent bundle messages, and"

10.     rsvp-lsp-tunnel is up to = version 7 now.
--
Adrian Farrel  mailto:af@dataconnection.com
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.dataconnection.com/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 = 312422

------_=_NextPart_001_01C03DD9.4EFA2DB0-- From owner-mpls@UU.NET Tue Oct 24 13:48:33 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05540 for ; Tue, 24 Oct 2000 13:48:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmhz08936; Tue, 24 Oct 2000 17:47:18 GMT Received: by mail-control.mail.uu.net id QQjmhz13078 for mpls-outgoing; Tue, 24 Oct 2000 17:46:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmhz13019 for ; Tue, 24 Oct 2000 17:46:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmhz11700; Tue, 24 Oct 2000 17:46:00 GMT Received: from smtp2.cluster.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQjmhz07573; Tue, 24 Oct 2000 17:46:00 GMT Received: from fr01ws20 ([212.234.220.124]) by smtp2.cluster.oleane.net with SMTP id TAA34213; Tue, 24 Oct 2000 19:49:05 +0200 (CEST) Reply-To: From: "valerie le faucheur" To: "'Kireeti Kompella'" Cc: , , , , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Tue, 24 Oct 2000 19:48:16 +0200 Message-ID: <000801c03de2$97466490$e971ff0a@algetytelecom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, Some followup discussions in line. Regards, Angela -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kireeti Kompella Sent: Monday, October 23, 2000 1:58 PM To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh > I don't see why TE and protection require the routers to specify explicit > routes. > The routers can simply specify to the optical layer what type of optical > layer protection > it requires. Suppose router A wants to get to router B, and wants to take two different ingress and egress points in the optical domain, X->Y for the primary LSP, and W->Z for the backup. A does not require optical protection for the X->Y path, nor for the W->Z path. A *does* require that the X->Y path and the W->Z path do not share common links. How is this to be done? If A did the full path computation, this is simplicity itself. [AC] I think you have a good point here. I also heard the same kind if reasoning (i.e., have a layer-3 like protection switching) for supporting the peer model. But after discussing with others, it seems that overlay model should be able to provide the same capability. Normally, the primary LSP X->Y is set up first, and becomes a forwarding adjacency (FA) according to your LSP Hierarchy draft. Then the associated information of the FA X->Y including its exact path and SRLG information should be propagated via IGP extensions, same as with any other link in the network. Thus if router A sends a request to OXC W to set up a backup lightpath from W->Z to be diversely router from the existing FA X->Y, OXC W should already have the right information to perform proper routing. Comparing with the peer model solution where routers need to know all the SRLG information of the optical domain as well as all relevant physical impairments in the optical signal in the case of transparent optical network, it is still not clear to me which one is simpler. I think it is very good to have this kind of technical discussion openly on the list. Hope others can provide more technical and business (after all carriers need to pay for these features) evidences for the need of each model. Some other reasoning I heard includes that peer model can improve the IGP scalability in terms of the number of neighbors a router needs to peer with. But since large ISPs today seem to cope well with the IGP scalability today, I don't see why the problem will get significant worst when optical networks come into play. Regards, Angela BTW, the draft John Strand mentioned on the list earlier should be at http://search.ietf.org/internet-drafts/draft-chiu-strand-unique-olcp-00.txt with all lower cases. A new version will be out in a few weeks before the deadline since we are still working on a few details and editing. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Tue Oct 24 14:02:04 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07301 for ; Tue, 24 Oct 2000 14:02:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmia01239; Tue, 24 Oct 2000 18:00:14 GMT Received: by mail-control.mail.uu.net id QQjmhz14331 for mpls-outgoing; Tue, 24 Oct 2000 17:59:49 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmhz14315 for ; Tue, 24 Oct 2000 17:59:39 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmhz16522 for ; Tue, 24 Oct 2000 17:59:29 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmhz25624 for ; Tue, 24 Oct 2000 17:59:28 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA27906 for mpls@uu.net; Tue, 24 Oct 2000 13:59:28 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmhz14231 for ; Tue, 24 Oct 2000 17:58:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmhz17262; Tue, 24 Oct 2000 17:57:54 GMT Received: from omega.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmhz23486; Tue, 24 Oct 2000 17:57:54 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA21702; Tue, 24 Oct 2000 10:57:41 -0700 (PDT) Message-Id: <200010241757.KAA21702@omega.cisco.com> To: neil.2.harrison@bt.com cc: David.A.Holmes@disney.com, Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-reply-to: Your message of "Mon, 23 Oct 2000 23:42:16 BST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21699.972410261.1@cisco.com> Date: Tue, 24 Oct 2000 10:57:41 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Neil, [clipped...] > (i) are traditional IP control-plane facets (so that is, for > example, v4 addressing, RSVP signalling and a IGP) the correct choice for an > OTN?....though to be honest no-one it seems dare raise this most basic of > questions too loudly; If you have "the correct choice" for an OTN, which is other than GMPLS, please share it with the rest of us (by the way, don't forget to include detailed description of why your "correct choice" is any better than GMPLS). > (ii) irrespective (in principle if not practice) of the choice of > control-plane facets, can these be unified/shared over all network layers? > I don't think we have 'consensus' to either of these as yet (though > some have aleady made up their minds on part (i), and assume (ii) follows). There is no need to reach consensus on (ii) in the MPLS WG, as with GMPLS the choice between the peer and the overlay model is up to each service provider. Yakov. From owner-mpls@UU.NET Tue Oct 24 14:08:26 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08104 for ; Tue, 24 Oct 2000 14:08:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmia12352; Tue, 24 Oct 2000 18:07:23 GMT Received: by mail-control.mail.uu.net id QQjmia26318 for mpls-outgoing; Tue, 24 Oct 2000 18:06:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmia26310 for ; Tue, 24 Oct 2000 18:06:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmia11999; Tue, 24 Oct 2000 18:05:52 GMT Received: from srnex01.sd.osicom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: srnex01.sd.osicom.com [131.143.32.21]) id QQjmia09836; Tue, 24 Oct 2000 18:05:51 GMT Received: by srnex01.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 10:56:59 -0700 Message-ID: <022A2DBC40A6D411967000D0B78892A61AB2B7@srnex01.sd.osicom.com> From: "Fu, James" To: "'Yakov Rekhter'" , neil.2.harrison@bt.com Cc: David.A.Holmes@disney.com, Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Tue, 24 Oct 2000 10:56:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DE3.CE398300" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03DE3.CE398300 Content-Type: text/plain; charset="iso-8859-1" Yakov: Agreed. The discussion of the peer model vs. overlay model has lingered too long in this mailing list. We had a long discussion like this back in July. We reached the same conclusion as Yakov suggested at that time. It is believed that there are no many merits to re-start this topic and continue for another unnecessary lengthy time. James Fu Sorrento Networks. -----Original Message----- From: Yakov Rekhter [mailto:yakov@cisco.com] Sent: Tuesday, October 24, 2000 10:58 AM To: neil.2.harrison@bt.com Cc: David.A.Holmes@disney.com; Mark.Jones@mail.sprint.com; ip-optical@lists.bell-labs.com; mpls@UU.NET; kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Neil, [clipped...] > (i) are traditional IP control-plane facets (so that is, for > example, v4 addressing, RSVP signalling and a IGP) the correct choice for an > OTN?....though to be honest no-one it seems dare raise this most basic of > questions too loudly; If you have "the correct choice" for an OTN, which is other than GMPLS, please share it with the rest of us (by the way, don't forget to include detailed description of why your "correct choice" is any better than GMPLS). > (ii) irrespective (in principle if not practice) of the choice of > control-plane facets, can these be unified/shared over all network layers? > I don't think we have 'consensus' to either of these as yet (though > some have aleady made up their minds on part (i), and assume (ii) follows). There is no need to reach consensus on (ii) in the MPLS WG, as with GMPLS the choice between the peer and the overlay model is up to each service provider. Yakov. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical ------_=_NextPart_001_01C03DE3.CE398300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes = From Pittsburgh

Yakov:

    Agreed. 

    The discussion of the peer model = vs. overlay model has lingered too long in this mailing list.  We = had a long discussion like this back in July.   We reached = the same conclusion as Yakov suggested at that time.

    It is believed that there are no = many merits to re-start this topic and continue for another unnecessary = lengthy time.


James Fu

Sorrento Networks.

 
       

-----Original Message-----
From: Yakov Rekhter [mailto:yakov@cisco.com]
Sent: Tuesday, October 24, 2000 10:58 AM
To: neil.2.harrison@bt.com
Cc: David.A.Holmes@disney.com; = Mark.Jones@mail.sprint.com;
ip-optical@lists.bell-labs.com; mpls@UU.NET; = kireeti@juniper.net;
sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; = zwlin@lucent.com
Subject: Re: [IP-Optical] RE: Optical link bundling. = Was Re:
DraftMinutes From Pittsburgh


Neil,

[clipped...]

>       = (i)     are traditional IP control-plane facets (so = that is, for
> example, v4 addressing, RSVP signalling and a = IGP) the correct choice for an
> OTN?....though to be honest no-one it seems = dare raise this most basic of
> questions too loudly;

If you have "the correct choice" for an = OTN, which is other than
GMPLS, please share it with the rest of us (by the = way, don't
forget to include detailed description of why your = "correct choice"
is any better than GMPLS).

>       = (ii)    irrespective (in principle if not practice) of = the choice of
> control-plane facets, can these be = unified/shared over all network layers?
>       I don't think we = have 'consensus' to either of these as yet (though
> some have aleady made up their minds on part = (i), and assume (ii) follows).

There is no need to reach consensus on (ii) in the = MPLS WG, as with
GMPLS the choice between the peer and the overlay = model is
up to each service provider.

Yakov.

_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical=

------_=_NextPart_001_01C03DE3.CE398300-- From owner-mpls@UU.NET Tue Oct 24 14:09:16 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08237 for ; Tue, 24 Oct 2000 14:09:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmia09306; Tue, 24 Oct 2000 18:08:23 GMT Received: by mail-control.mail.uu.net id QQjmia26442 for mpls-outgoing; Tue, 24 Oct 2000 18:07:50 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmia26396 for ; Tue, 24 Oct 2000 18:07:33 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmia04594 for ; Tue, 24 Oct 2000 18:07:00 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQjmia11582 for ; Tue, 24 Oct 2000 18:06:55 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA25140 for ; Tue, 24 Oct 2000 14:05:01 -0400 (EDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA19754 for mpls@uu.net; Tue, 24 Oct 2000 13:59:46 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmhz13009 for ; Tue, 24 Oct 2000 17:46:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmhz09664 for ; Tue, 24 Oct 2000 17:45:21 GMT Received: from mailman.packetdesign.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dns.PACKETDESIGN.NET [216.15.46.10]) id QQjmhz06707 for ; Tue, 24 Oct 2000 17:45:20 GMT Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id e9OHijQ08915; Tue, 24 Oct 2000 10:44:45 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <39F5CBC6.F052B920@packetdesign.com> Date: Tue, 24 Oct 2000 10:49:58 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 CC: diffserv@ietf.org, mpls@UU.NET Subject: Re: [Diffserv] RFC2597 References: <20001024155519.19014.qmail@web5103.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQjmia09306 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA08237 Chatur sharp wrote: > ... > > Anyhow phrases like : > " The EF traffic SHOULD receive this rate > independent of the intensity of any other traffic > attempting to transit the node. " > > Do not make any sense, till the time you specify what > is the meaning of transit. The meaning of transit (from www.dictionary.com): tran·sit (trnst, -zt) n. Abbr. t. 1.The act of passing over, across, or through; passage. 2.Conveyance of people or goods from one place to another, especially on a local public transportation system. 3.A transition or change, as to a spiritual existence at death. 4.Astronomy. a.The passage of a celestial body across the observer's meridian. b.The passage of a smaller celestial body or its shadow across the disk of a larger celestial body. 5.A surveying instrument similar to a theodolite that measures horizontal and vertical angles. Definition 1 is what we had in mind. I would have thought the others didn't fit. > Does it mean that traffic > coming on interface i and going out of interface j > will have this commitment? It is difficult to tell if you mean by the above: "coming in on a specific interface i and going out of a specific interface j" or "coming in on some arbitrary interface i and going out on some arbitrary interface j". > > IMHO, DIFFSERV should provide an option to let > PHBs be associated to destination addresses or egress > points through a network if needed. It will still > allow > diffserv to work in the manner it is working today and > > will also enable SPs to provide garuntees which are > required by some of the real-time applications > Again, it is difficult to tell if you mean "associating" in the sense of applying a classifier on that destination address and when there is a match, treating it with that PHB (which is, of course, possible) of if you mean you want to specifically take all the packets marked for a particular per-node forwarding behavior and ensure that they egress the network at a particular point. This is clearly something in the domain of the control plane, not the forwarding path and would require that the IGP make a decision based on the DSCP it seems. This is the wrong working group for that. > Finally, I think the DIFFSERV-MPLS approach is > the right approach as it really takes into account > need of all kinds of traffic rather than just the > traditional IP services. Then it sounds like your needs are being met. MPLS is a control plane approach using diffserv mechanisms in the FP. If you like that approach, it isn't clear what you want this WG to do. Kathie From owner-mpls@UU.NET Tue Oct 24 14:19:42 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09542 for ; Tue, 24 Oct 2000 14:19:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmib28568; Tue, 24 Oct 2000 18:18:21 GMT Received: by mail-control.mail.uu.net id QQjmib27589 for mpls-outgoing; Tue, 24 Oct 2000 18:17:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmib27581 for ; Tue, 24 Oct 2000 18:17:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmib16553 for ; Tue, 24 Oct 2000 18:17:04 GMT Received: from cowansville.acbm.qc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjmib22132 for ; Tue, 24 Oct 2000 18:16:59 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca; Tue, 24 Oct 2000 14:16:01 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id <4GAKA5DF>; Tue, 24 Oct 2000 14:16:33 -0400 Message-ID: <91E486361D4CD311B3140060089A882556A4A6@hermes.hyperchip.com> From: Eyad Saheb To: "'Kathleen Nichols'" Cc: "'mpls@UU.NET'" Subject: RE: [Diffserv] RFC2597 Date: Tue, 24 Oct 2000 14:16:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DE6.8932BCB0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03DE6.8932BCB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I concur with Kathleen. Eyad -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kathleen Nichols Sent: Tuesday, October 24, 2000 1:50 PM Cc: diffserv@ietf.org; mpls@UU.NET Subject: Re: [Diffserv] RFC2597 Chatur sharp wrote: >=20 ... >=20 > Anyhow phrases like : > " The EF traffic SHOULD receive this rate > independent of the intensity of any other traffic > attempting to transit the node. " >=20 > Do not make any sense, till the time you specify what > is the meaning of transit.=20 The meaning of transit (from www.dictionary.com): tran=B7sit (trnst, -zt)=20 n. Abbr. t.=20 1.The act of passing over, across, or through; passage.=20 2.Conveyance of people or goods from one place to another, especially on a local public transportation system.=20 3.A transition or change, as to a spiritual existence at death. = 4.Astronomy.=20 a.The passage of a celestial body across the observer's meridian.=20 b.The passage of a smaller celestial body or its shadow across the disk of a larger celestial body.=20 5.A surveying instrument similar to a theodolite that measures horizontal and vertical angles.=20 Definition 1 is what we had in mind. I would have thought the others didn't fit. > Does it mean that traffic > coming on interface i and going out of interface j > will have this commitment?=20 It is difficult to tell if you mean by the above: "coming in on a specific interface i and going out of a specific interface j" or "coming in on some arbitrary interface i and going out on some arbitrary interface j". >=20 > IMHO, DIFFSERV should provide an option to let > PHBs be associated to destination addresses or egress > points through a network if needed. It will still > allow > diffserv to work in the manner it is working today and >=20 > will also enable SPs to provide garuntees which are > required by some of the real-time applications >=20 Again, it is difficult to tell if you mean "associating" in the sense of applying a classifier on that destination address and when there is a match, treating it with that PHB (which is, of course, possible) of if you mean you want to specifically take all the packets marked for a particular per-node forwarding behavior and ensure that they egress the network at a particular point. This is clearly something in the domain of the control plane, not the forwarding path and would require that the IGP make a decision based on the DSCP it seems. This is the wrong working group for that. > Finally, I think the DIFFSERV-MPLS approach is > the right approach as it really takes into account > need of all kinds of traffic rather than just the > traditional IP services. Then it sounds like your needs are being met. MPLS is a control plane approach using diffserv mechanisms in the FP. If you like that approach, it isn't clear what you want this WG to do. Kathie ------_=_NextPart_001_01C03DE6.8932BCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] RFC2597

I concur with Kathleen.

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Kathleen
Nichols
Sent: Tuesday, October 24, 2000 1:50 PM
Cc: diffserv@ietf.org; mpls@UU.NET
Subject: Re: [Diffserv] RFC2597



Chatur sharp wrote:
>
...
>
> Anyhow phrases like :
> "  The EF traffic SHOULD receive this = rate
>    independent of the intensity = of any other traffic
>    attempting to transit the = node.  "
>
> Do not make any sense, till the time you = specify what
> is the meaning of transit.

The meaning of transit (from = www.dictionary.com):

tran=B7sit (trnst, -zt)
 n. Abbr. t.

        1.The act = of passing over, across, or through; passage.
        = 2.Conveyance of people or goods from one place to another,
especially on a local public transportation system. =
        3.A = transition or change, as to a spiritual existence at death.
        = 4.Astronomy.
          &nb= sp;  a.The passage of a celestial body across the = observer's
meridian.
          &nb= sp;  b.The passage of a smaller celestial body or its = shadow
across the disk of a larger celestial body.
        5.A = surveying instrument similar to a theodolite that measures
horizontal and vertical angles.

Definition 1 is what we had in mind. I would have = thought the others
didn't fit.

> Does it mean that traffic
> coming on interface i and going out of = interface j
> will have this commitment?

It is difficult to tell if you mean by the above: = "coming
in on a specific interface i and going out of a = specific
interface j" or "coming in on some = arbitrary interface i
and going out on some arbitrary interface = j".

>
> IMHO, DIFFSERV should provide an option to = let
> PHBs be associated to destination addresses or = egress
> points through a network if needed. It will = still
> allow
> diffserv to work in the manner it is working = today and
>
> will also enable SPs to provide garuntees which = are
> required by some of the real-time = applications
>

Again, it is difficult to tell if you mean = "associating"
in the sense of applying a classifier on that = destination
address and when there is a match, treating it with = that
PHB (which is, of course, possible) of if you mean = you
want to specifically take all the packets marked for = a particular
per-node forwarding behavior and ensure that they = egress the
network at a particular point. This is clearly = something in
the domain of the control plane, not the forwarding = path and
would require that the IGP make a decision based on = the DSCP
it seems. This is the wrong working group for = that.

> Finally, I think the DIFFSERV-MPLS approach = is
> the right approach as it really takes into = account
> need of all kinds of traffic rather than just = the
> traditional IP services.

Then it sounds like your needs are being met. MPLS is = a control
plane approach using diffserv mechanisms in the FP. = If you like
that approach, it isn't clear what you want this WG = to do.


        Kathie

------_=_NextPart_001_01C03DE6.8932BCB0-- From owner-mpls@UU.NET Tue Oct 24 14:19:54 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09568 for ; Tue, 24 Oct 2000 14:19:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmib23893; Tue, 24 Oct 2000 18:18:13 GMT Received: by mail-control.mail.uu.net id QQjmib27575 for mpls-outgoing; Tue, 24 Oct 2000 18:17:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmib27570 for ; Tue, 24 Oct 2000 18:17:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmib05876; Tue, 24 Oct 2000 18:15:02 GMT Received: from alemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQjmib23760; Tue, 24 Oct 2000 18:15:01 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA10335; Tue, 24 Oct 2000 14:15:00 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id OAA10317; Tue, 24 Oct 2000 14:15:00 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21235; Tue, 24 Oct 2000 14:14:59 -0400 Message-ID: <39F5D18A.FF1E4476@lucent.com> Date: Tue, 24 Oct 2000 14:14:34 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fu, James" CC: "'Yakov Rekhter'" , neil.2.harrison@bt.com, David.A.Holmes@disney.com, Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <022A2DBC40A6D411967000D0B78892A61AB2B7@srnex01.sd.osicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi James, Yakov, I don't think the current discussion has lingered that long...I mean, we've been asking to have service provider comments for a lot of this. Now we have them, and are we simply to ignore them simply because they don't agree? I don't think that should be the way the standards process works... Zhi > "Fu, James" wrote: > > Yakov: > > Agreed. > > The discussion of the peer model vs. overlay model has lingered > too long in this mailing list. We had a long discussion like this > back in July. We reached the same conclusion as Yakov suggested at > that time. > > It is believed that there are no many merits to re-start this > topic and continue for another unnecessary lengthy time. > > James Fu > > Sorrento Networks. > > > > > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@cisco.com] > Sent: Tuesday, October 24, 2000 10:58 AM > To: neil.2.harrison@bt.com > Cc: David.A.Holmes@disney.com; Mark.Jones@mail.sprint.com; > ip-optical@lists.bell-labs.com; mpls@UU.NET; kireeti@juniper.net; > sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > Neil, > > [clipped...] > > > (i) are traditional IP control-plane facets (so that is, > for > > example, v4 addressing, RSVP signalling and a IGP) the correct > choice for an > > OTN?....though to be honest no-one it seems dare raise this most > basic of > > questions too loudly; > > If you have "the correct choice" for an OTN, which is other than > GMPLS, please share it with the rest of us (by the way, don't > forget to include detailed description of why your "correct choice" > is any better than GMPLS). > > > (ii) irrespective (in principle if not practice) of the > choice of > > control-plane facets, can these be unified/shared over all network > layers? > > I don't think we have 'consensus' to either of these as yet > (though > > some have aleady made up their minds on part (i), and assume (ii) > follows). > > There is no need to reach consensus on (ii) in the MPLS WG, as with > GMPLS the choice between the peer and the overlay model is > up to each service provider. > > Yakov. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com From owner-mpls@UU.NET Tue Oct 24 14:52:05 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13605 for ; Tue, 24 Oct 2000 14:52:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmid08072; Tue, 24 Oct 2000 18:50:44 GMT Received: by mail-control.mail.uu.net id QQjmid29769 for mpls-outgoing; Tue, 24 Oct 2000 18:50:10 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmid29759 for ; Tue, 24 Oct 2000 18:50:03 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmid12425 for ; Tue, 24 Oct 2000 18:49:00 GMT Received: from prue.eim.surrey.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQjmid05688 for ; Tue, 24 Oct 2000 18:48:59 GMT Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13o97z-0000SR-00; Tue, 24 Oct 2000 19:48:51 +0100 Date: Tue, 24 Oct 2000 19:48:25 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Kathleen Nichols cc: diffserv@ietf.org, mpls@UU.NET Subject: Re: [Diffserv] RFC2597 In-Reply-To: <39F5CBC6.F052B920@packetdesign.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id OAA13605 On Tue, 24 Oct 2000, Kathleen Nichols wrote: > Chatur sharp wrote: > > Anyhow phrases like : > > " The EF traffic SHOULD receive this rate > > independent of the intensity of any other traffic > > attempting to transit the node. " > > > > Do not make any sense, till the time you specify what > > is the meaning of transit. > > The meaning of transit (from www.dictionary.com): > > tran·sit (trnst, -zt) > n. Abbr. t. > > 1.The act of passing over, across, or through; passage. [..] n. That's short for noun. It's unfortunate that you couldn't find a definition supporting your use of 'transit' as a verb. Why we have to verb rare nouns instead of saying something perfectly clear to English-is-second-language-speakers as 'attempting to travel through' is beyond me. The challenge is perfectly reasonable; 'passing over' often means 'avoiding', making the use ambiguous as well as ungrammatical. If you must resort to quoting a dictionary definition, you need a rewrite. L. PGP From owner-mpls@UU.NET Tue Oct 24 15:01:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14793 for ; Tue, 24 Oct 2000 15:01:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmie26860; Tue, 24 Oct 2000 19:01:09 GMT Received: by mail-control.mail.uu.net id QQjmie03414 for mpls-outgoing; Tue, 24 Oct 2000 19:00:45 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmie03205 for ; Tue, 24 Oct 2000 19:00:32 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmid27996 for ; Tue, 24 Oct 2000 18:59:00 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmid23906 for ; Tue, 24 Oct 2000 18:58:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA10228 for mpls@uu.net; Tue, 24 Oct 2000 14:58:58 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmid29711 for ; Tue, 24 Oct 2000 18:48:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmid16259 for ; Tue, 24 Oct 2000 18:47:44 GMT Received: from xover.hjinc.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjmid04011 for ; Tue, 24 Oct 2000 18:47:43 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id <45RJVHJN>; Tue, 24 Oct 2000 14:46:25 -0400 Message-ID: <87009604743AD411B1F600508BA0F959040C68@xover.hjinc.com> From: "Sanford, Bill" To: "'mpls@UU.NET'" Subject: DIFF-SERV error values Date: Tue, 24 Oct 2000 14:46:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In draft-ietf-mpls-diff-ext-07.txt, the error vales for DIFF-SERV are: Error Unexpected DIFFSERV object (or TLV) Unsupported PHB Invalid EXP<-->PHB mapping Unsupported PSC Per-LSP context allocation failure I thought the following messages would be appropriate for LDP and RSVP: Missing Map Entry (E-LSP TLV) Unsupported LSP Type (LDP) Invalid MAPnb value (LDP & RSVP) Invalid MAPnb<-->Map value (LDP & RSVP) Invalid object length (LDP & RSVP) Bill From owner-mpls@UU.NET Tue Oct 24 15:15:04 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16423 for ; Tue, 24 Oct 2000 15:15:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmie09568; Tue, 24 Oct 2000 19:14:29 GMT Received: by mail-control.mail.uu.net id QQjmie13041 for mpls-outgoing; Tue, 24 Oct 2000 19:14:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmie13033 for ; Tue, 24 Oct 2000 19:13:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmie06484 for ; Tue, 24 Oct 2000 19:13:24 GMT Received: from cowansville.acbm.qc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cowansville.acbm.qc.ca [207.96.170.2]) id QQjmie13373 for ; Tue, 24 Oct 2000 19:13:22 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by cowansville.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-55493U700L2S100V35) with ESMTP id ca; Tue, 24 Oct 2000 15:12:18 -0400 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2650.21) id <4GAKA51R>; Tue, 24 Oct 2000 15:12:27 -0400 Message-ID: <91E486361D4CD311B3140060089A882556A4A7@hermes.hyperchip.com> From: Eyad Saheb To: "'Dhiraj Bhuyan'" Cc: "'mpls@uu.net'" Subject: RE: Some doubts Date: Tue, 24 Oct 2000 15:12:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DEE.5912D0D0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03DEE.5912D0D0 Content-Type: text/plain; charset="iso-8859-1" I believe the question really is, what's the use of having a label *stack*. Why not use just one label ? There're a few reasons, but the ones that are foremost on my mind are: 1) Multiple labels are useful when each one can not only direct a packet's path, but also provide insight into it's contents, bindings, etc... For example, the first label can indicate the path to follow, as well as the CoS. The next label can indicate that the Layer3 is IP. etc... 2) Another 'obvious' use is tunneling. The benefits of tunneling are also numerous, but above all it is a great way to transit a domain that isn't under your control. For example, an LSP heirarchy can be created as a packet transits an ISP, the ISP's carrier, the carrier's carrier, and back again. On each domain crossing, a new label is pushed on to the packet, routed internally, and removed at the egress. For more reasons, there are plenty of books on MPLS applications. Eyad -----Original Message----- From: Dhiraj Bhuyan [mailto:dhirajb@rediffmail.com] Sent: Tuesday, October 24, 2000 1:06 PM To: mpls-ops@mplsrc.com Subject: Some doubts Greetings, I have a doubt. Will be grateful if somebody can clarify it - What's the use of having a LSP tunnel? Regards, Dhiraj Bhuyan Bachelor of Technology, Computer Science & Engg Dept Indian Institute of Technology, Delhi India _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com Participate in crazy auctions at http://auctions.rediff.com/auctions/ ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------_=_NextPart_001_01C03DEE.5912D0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Some doubts

I believe the question really is, what's the use of = having a label *stack*.  Why not use just one label ?  = There're a few reasons, but the ones that are foremost on my mind = are:

1) Multiple labels are useful when each one can not = only direct a packet's path, but also provide insight into it's = contents, bindings, etc... For example, the first label can indicate = the path to follow, as well as the CoS.  The next label can = indicate that the Layer3 is IP. etc...

2) Another 'obvious' use is tunneling.  The = benefits of tunneling are also numerous, but above all it is a great = way to transit a domain that isn't under your control.  For = example, an LSP heirarchy can be created as a packet transits an ISP, = the ISP's carrier, the carrier's carrier, and back again.  On each = domain crossing, a new label is pushed on to the packet, routed = internally, and removed at the egress.

For more reasons, there are plenty of books on MPLS = applications.

Eyad

-----Original Message-----
From: Dhiraj Bhuyan [mailto:dhirajb@rediffmail.com= ]
Sent: Tuesday, October 24, 2000 1:06 PM
To: mpls-ops@mplsrc.com
Subject: Some doubts


Greetings,
I have a doubt. Will be grateful if somebody can = clarify it -

What's the use of having a LSP tunnel?

Regards,

Dhiraj Bhuyan  
Bachelor of Technology,
Computer Science & Engg Dept
Indian Institute of Technology, Delhi
India

_____________________________________________________
Chat with your friends as soon as they come online. = Get Rediff Bol at
http://bol.rediff.com

Participate in crazy auctions at http://auctions.rediff.com/auctions/



-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

------_=_NextPart_001_01C03DEE.5912D0D0-- From owner-mpls@UU.NET Tue Oct 24 15:52:41 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23043 for ; Tue, 24 Oct 2000 15:52:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmih07610; Tue, 24 Oct 2000 19:51:48 GMT Received: by mail-control.mail.uu.net id QQjmih16222 for mpls-outgoing; Tue, 24 Oct 2000 19:51:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmih16208 for ; Tue, 24 Oct 2000 19:50:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmih02076 for ; Tue, 24 Oct 2000 19:50:49 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmih10534 for ; Tue, 24 Oct 2000 19:50:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA20094 for mpls@uu.net; Tue, 24 Oct 2000 15:50:47 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmih16170 for ; Tue, 24 Oct 2000 19:50:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmih21311; Tue, 24 Oct 2000 19:48:08 GMT Received: from almso1.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso1.att.com [192.128.167.69]) id QQjmih29770; Tue, 24 Oct 2000 19:48:08 GMT Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id PAA06273; Tue, 24 Oct 2000 15:48:06 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA23479; Tue, 24 Oct 2000 15:47:04 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 24 Oct 2000 15:48:05 -0400 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F403240546@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Yakov Rekhter'" , neil.2.harrison@bt.com Cc: David.A.Holmes@disney.com, Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Tue, 24 Oct 2000 15:47:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk See below Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Yakov Rekhter [mailto:yakov@cisco.com] Sent: Tuesday, October 24, 2000 1:58 PM To: neil.2.harrison@bt.com Cc: David.A.Holmes@disney.com; Mark.Jones@mail.sprint.com; ip-optical@lists.bell-labs.com; mpls@UU.NET; kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Neil, [clipped...] > (i) are traditional IP control-plane facets (so that is, for > example, v4 addressing, RSVP signalling and a IGP) the correct choice for an > OTN?....though to be honest no-one it seems dare raise this most basic of > questions too loudly; [MAL] Neil is right. I have not seen any overwhelming evidence as to why a protocol used for routing individual packets is the best possible alternative to be used to set-up circuits. If you have "the correct choice" for an OTN, which is other than GMPLS, please share it with the rest of us (by the way, don't forget to include detailed description of why your "correct choice" is any better than GMPLS). > (ii) irrespective (in principle if not practice) of the choice of > control-plane facets, can these be unified/shared over all network layers? > I don't think we have 'consensus' to either of these as yet (though > some have aleady made up their minds on part (i), and assume (ii) follows). There is no need to reach consensus on (ii) in the MPLS WG, as with GMPLS the choice between the peer and the overlay model is up to each service provider. ...{MAL] As long as the OTN will be able to support IP, ATM, and other types of clients (including the relevant naming schemes - IP used by IP clients, E.164 used by ATM switches, etc), third party signaling, scheduling, and if the routing decisions are within the OTN, not made by a client router. Several service providers have specifically asked that the client model be supported for OTN, in multiple standards bodies/forums. Yakov. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Tue Oct 24 16:45:42 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07730 for ; Tue, 24 Oct 2000 16:45:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmik19941; Tue, 24 Oct 2000 20:44:37 GMT Received: by mail-control.mail.uu.net id QQjmik01806 for mpls-outgoing; Tue, 24 Oct 2000 20:44:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmik01798 for ; Tue, 24 Oct 2000 20:44:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmik07341 for ; Tue, 24 Oct 2000 20:43:54 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmik22482 for ; Tue, 24 Oct 2000 20:43:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA28898 for mpls@uu.net; Tue, 24 Oct 2000 16:43:52 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmik01711 for ; Tue, 24 Oct 2000 20:43:22 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmik27536 for ; Tue, 24 Oct 2000 20:42:55 GMT Received: from smtprch1.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjmik21198 for ; Tue, 24 Oct 2000 20:42:54 GMT Received: from zsc4c000.corpwest.baynetworks.com by smtprch1.nortel.com; Tue, 24 Oct 2000 14:28:08 -0500 Received: by zsc4c000.corpwest.baynetworks.com with Internet Mail Service (5.5.2652.35) id ; Tue, 24 Oct 2000 12:27:55 -0700 Message-ID: <8B888AAAAB0FD31189590008C791844303BB20F8@zbl6c002.corpeast.baynetworks.com> From: "Joy Ghanekar" To: mpls@UU.NET Subject: unsubscribe Date: Tue, 24 Oct 2000 12:27:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DF0.7D726BF0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03DF0.7D726BF0 Content-Type: text/plain; charset="iso-8859-1" Joy Ghanekar, Carrier Ethernet Switching, Nortel Networks, Billerica, MA Ph: +1-978-288-7827 Fax: +1-978-288-0620 jghaneka@nortelnetworks.com ------_=_NextPart_001_01C03DF0.7D726BF0 Content-Type: text/html; charset="iso-8859-1" unsubscribe

Joy Ghanekar, Carrier Ethernet Switching,  Nortel Networks, Billerica, MA
Ph: +1-978-288-7827  Fax: +1-978-288-0620  jghaneka@nortelnetworks.com

------_=_NextPart_001_01C03DF0.7D726BF0-- From owner-mpls@UU.NET Tue Oct 24 16:47:58 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08216 for ; Tue, 24 Oct 2000 16:47:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmil22215; Tue, 24 Oct 2000 20:47:07 GMT Received: by mail-control.mail.uu.net id QQjmil02153 for mpls-outgoing; Tue, 24 Oct 2000 20:46:30 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmil02145 for ; Tue, 24 Oct 2000 20:46:27 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmil04250 for ; Tue, 24 Oct 2000 20:45:54 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmil20044 for ; Tue, 24 Oct 2000 20:45:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA29114 for mpls@uu.net; Tue, 24 Oct 2000 16:45:37 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmil02007 for ; Tue, 24 Oct 2000 20:45:05 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmik00554 for ; Tue, 24 Oct 2000 20:44:16 GMT Received: from coltrane.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjmik19357 for ; Tue, 24 Oct 2000 20:44:15 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id <4W19NK30>; Tue, 24 Oct 2000 21:43:59 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA59A@monk.datcon.co.uk> From: Adrian Farrel To: Lou Berger Cc: mpls@UU.NET, petera@nortelnetworks.com Subject: RE: draft-ietf-mpls-generalized-signaling-00.txt Date: Tue, 24 Oct 2000 21:43:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Lou, Thanks for the response. Agreements deleted. Sorry that I missed so many obvious points. Regards, Adrian >>Error values etc. >>Can I suggest adding a section at the end as a place holder >>for new error values. > >This is *really* stylistic, do you really care? I don't care, but the (new) values are going to have to be defined somewhere. Perhaps we push this out to the protocol-specific docs that will be written later? >>4.2 Bidirectional LSP Procedures >>The choice you have made is consistent (that you may not >>propagate a Path containing Upstream_Label until the local >>switch has been programmed, so that the terminator may start >>sending data as soon as it has processed the Path) but may >>unnecessarily increase the latency of LSP set up (compare >>with the arguments for Suggested_Label). >>If ResvConf were to be requested and used, the individual >>switch programming tasks could be processed in parallel with >>the propagation of the Path message. The terminator is not >>allowed to start sending data until it receives the ResvConf. >>This is a direct trade-off, but could quite easily reduce >>setup time for individual LSPs. > >This is a reasonable representation of the choice that was made. No chance of re-opening this debate? >>4.3 Bidirectional LSP Contention Resolution >>The suggested behavior for reducing contention depends on >>adjacent LSRs knowing each other's node IDs. Does this >>rely on Hello messages, carnal knowledge or what? > >from the draft: > For the purposes of RSVP contention > resolution, the node ID is the IP address used in the RSVP_HOP > object. Agreed. However, the draft also says... To reduce the probability of contention, one may impose a policy that the node with the lower ID never suggests a label in the downstream direction and always accepts a Suggested Label from an upstream node with a higher ID. To know whether to suggest a label, you need to know whether you have the higher or lower ID. To find that out, you have to receive a Path message containing RSVP_HOP from the other node. Hence my question. >>5.1.2 Notify Request Procedures >>We should add a statement about multiple instances of this object. >>The current discussion allows just a single instance. > >This is by design. Others have made the same point, but it >wasn't clear that this functionality is really required. >Why do you believe this is needed? I'm aproaching from the other end. I'd like an explicit statement limiting us to one instance (more explicit than the BNF) precisely because of the discussions about multiple targets. >>5.2.2 Notify Procedures >>This version of the text does not prohibit the Notify Node from >>being other than the requester (i.e. initiator or terminator). > >Again, this is by design. Do I take it, then, that we're also leaving it open for nodes to change the value of the Notify Address as the Path/Resv is propagated? This would be good, but it might be helpful to describe the process. (Text available on demand :-) >>5.2 "Notify Ack" is obsolete, read "Ack" > >I couldn't find this. Can you provide more context. > >>5.3 for "receiving such a error" read "receiving such an error" > >I couldn't find this. Can you provide more context. Sorry. both transcription errors from my review of the beta draft. -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Tue Oct 24 16:51:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09085 for ; Tue, 24 Oct 2000 16:51:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmil29127; Tue, 24 Oct 2000 20:51:09 GMT Received: by mail-control.mail.uu.net id QQjmil02518 for mpls-outgoing; Tue, 24 Oct 2000 20:50:32 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmil02505 for ; Tue, 24 Oct 2000 20:50:24 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmil24801 for ; Tue, 24 Oct 2000 20:49:41 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjmil00254 for ; Tue, 24 Oct 2000 20:49:41 GMT Received: from tellium.com ([192.168.24.75]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9OKerI01127; Tue, 24 Oct 2000 16:40:54 -0400 (EDT) Message-ID: <39F5F569.5B15D209@tellium.com> Date: Tue, 24 Oct 2000 16:47:37 -0400 From: Dimitrios Pendarakis X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ytr@csa.iisc.ernet.in CC: mpls@UU.NET Subject: Re: COPS doubt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit YTR, COPS is intended to provide two main benefits: - The ability to outsource policy decisions to an external PDP. - To allow a PEP to communicate with third party, COPS compliant, PDPs. To decide whether you need COPS, you should evaluate the relevance of these benefits to your network, taking into account the complexity of implementing COPS. In general, an external PDP is necessary if processing requirements of policy decisions are too high for your LSR, if your LSR lacks the intelligence or the flexibility to provide the functionality, or if the information needed to make the decisions is not available locally at the PEP. If you have already decided you need an external PDP, COPS is certainly a valid option, if not the most appropriate. However, if you are planning to develop the PDP on your own, you could also consider other options, such as SNMP (as pointed out by Ping's earlier mail), LDAP, etc. In any case, policy decisions need only be taken at the ingress and egress nodes of an administrative domain. Regards, Dimitrios Pendarakis Tellium, Inc. "Y.T. Ramanjaneyulu" wrote: > HI, > > If already discussed these things then please provide pointers to mail > archives > > I am currently working on a Project which involves developing a Label > Switched router in a MPLS domain.The core protocols which are used in this > work are MPLS as the forwarding mechanism and RSVP-TE as the signalling > Protocol.Main intention of ours is to provide Qos services to the end users in MPLS > domain. > > I thought of having a Resource manager inside each LSR to manage the > resources locally. We have policies to allow user to consume only certain amount of > bandwidth etc. > > PDP generally situated in some remote machine and collecting statistics > from allclients and making descisions . > > So in our scenario is it necessary to have a PEP and a PDP (COPS > Protocol) inside the network ??? > > > Thanx in advance > > -- > Regards > YTR > > NOTE: > ----- > P L E A S E DON'T R E P L Y TO THIS MAIL ID. > > ************************* > If u want to reply > > please reply to > ytr@csa.iisc.ernet.in > > ************************ > From owner-mpls@UU.NET Tue Oct 24 17:38:42 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15627 for ; Tue, 24 Oct 2000 17:38:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmio29023; Tue, 24 Oct 2000 21:37:23 GMT Received: by mail-control.mail.uu.net id QQjmio18114 for mpls-outgoing; Tue, 24 Oct 2000 21:36:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmio18107 for ; Tue, 24 Oct 2000 21:36:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmio23028 for ; Tue, 24 Oct 2000 21:35:47 GMT Received: from cs.columbia.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cs.columbia.edu [128.59.16.20]) id QQjmio28682 for ; Tue, 24 Oct 2000 21:35:43 GMT Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA14092; Tue, 24 Oct 2000 17:35:41 -0400 (EDT) Received: from localhost (pingpan@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA22602; Tue, 24 Oct 2000 17:35:37 -0400 (EDT) Date: Tue, 24 Oct 2000 17:35:29 -0400 (EDT) From: Ping Pan To: Dimitrios Pendarakis cc: ytr@csa.iisc.ernet.in, mpls@UU.NET Subject: Re: COPS doubt In-Reply-To: <39F5F569.5B15D209@tellium.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 24 Oct 2000, Dimitrios Pendarakis wrote: > To decide whether you need COPS, you should evaluate the relevance of these > benefits to your network, taking into account the complexity of implementing COPS. > In general, an external PDP is necessary if processing requirements of policy > decisions are too high for your LSR, I thought LSR's don't need to maintain policy database, that's why we need to keep it else where and use COPS to pick it up. > if your LSR lacks the intelligence or the > flexibility to provide the functionality, Wonder which LSR's are you referring to. :-) If LSR's can handle routing protocols and RSVP, they'd better have a lot of intellengence and flexibility. :-) Take care! - Ping From owner-mpls@UU.NET Tue Oct 24 17:44:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16221 for ; Tue, 24 Oct 2000 17:44:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmio10500; Tue, 24 Oct 2000 21:43:07 GMT Received: by mail-control.mail.uu.net id QQjmio18802 for mpls-outgoing; Tue, 24 Oct 2000 21:42:41 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmio18797 for ; Tue, 24 Oct 2000 21:42:36 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmio14140 for ; Tue, 24 Oct 2000 21:42:24 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmio09537 for ; Tue, 24 Oct 2000 21:42:24 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA04069 for ; Tue, 24 Oct 2000 14:42:23 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA20275 for mpls@uu.net; Tue, 24 Oct 2000 17:42:22 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmig14876 for ; Tue, 24 Oct 2000 19:35:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmig10386 for ; Tue, 24 Oct 2000 19:34:04 GMT Received: from mail.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.movaz.com [64.47.156.131]) id QQjmig12597 for ; Tue, 24 Oct 2000 19:34:03 GMT Received: from nfloat.movaz.com (griffin.host4u.net [209.150.128.163]) by mail.movaz.com (8.9.3/8.8.7) with ESMTP id PAA18398; Tue, 24 Oct 2000 15:35:17 -0400 Message-Id: <4.3.2.7.2.20001024074202.00abef00@mo-mail> X-Sender: lou@mo-mail X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Oct 2000 15:00:17 -0400 To: Adrian Farrel From: Lou Berger Subject: Re: draft-ietf-mpls-generalized-signaling-00.txt Cc: mpls@UU.NET, lberger@labn.net, petera@nortelnetworks.com In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2CA570@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Adrian, Thank you very much for the detailed comments. At 02:11 PM 10/23/00, Adrian Farrel wrote: >Lou and Peter, > >Thanks for a great job editing this and for getting it out into the public >domain. I'd love to take all the credit but, as is shown by the Author's list, there are lots of folks working on the document. >I have a large block of comments and questions and bunch of minor typos. >Please feel free to split the comments into separate threads if you like. > >Regards, >Adrian > >Questions >========= > >Link Id and Explicit Routing >I'm not sure how much this should be in Kireeti's bundling draft >and how much in the Generalized draft. I have the following >concern: > >- Suppose we use LSR addresses (i.e. not link addresses) in our > explicit route and also use label sub-objects. This should result in an error. The text says: The Label subobject follows a subobject containing the IP address, or the interface identifier [MPLS-UNNUM], associated with the link on which it is to be used. I'll make the text more explicit on this point. > Suppose further > that there are multiple links of different types between a pair > of LSRs. Finally consider that Label_Request is used, not > Generalized_Label_Request. > > How does the LSR processing the ERO interpret the label and > decide which link to apply it to? > I guess you could say that you should avoid the combination of > circumstances listed above and use G_L_R to constrain the link > type or use the link address not the LSR address. Does that > still work with unnumbered links? This situation SHOULD result in an error. The next rev will be more explicit. >Error values etc. >Can I suggest adding a section at the end as a place holder for new error >values. >In the text I have found >- Routing Problem/Unsupported Encoding >- Routing Problem/Unsupported Link Protection >- Routing Problem/Unsupported GPID >- Routing Problem/Unacceptable Label Value >- Routing Problem/Label Set This is *really* stylistic, do you really care? >3. Generalized Label Request >Could you make it clearer right at the top of section 3 that >for RSVP the Generalized_Label_Request is not a new object but a >new variant of the Label_Request Object, whereas for CR-LDP it is >a new TLV. This too seems like a style comment. >3.3.1 Waveband Switching >"For compatibility reasons, a new RSVP c-type and CR- > LDP type is assigned for the Waveband Label." >This seems to be the only place in the draft where you >haven't explicitly suggested values (subject to IANA). > >I think you have left gaps for RSVP c-type 3 and CR-LDP >type 903. Thanks. >3.5.1 Label Set >It isn't clear how a sequence of subchannels that form a >label set are conveyed. I agree, the text needs to be cleaned up. Thanks for pointing this out. >It can't be the case that you >simply add multiple Subchannels to the Object/TLV since >the Type is closely associated with each individual >Subchannel. > >We should either define Label_Set as Explicit_Route with >a sequence of subobjects. Or we should allow a series >of Label_Sets in the Path/LABEL_REQUEST. >In either case, it would be good to put in some motherhood >about ordering the elements for clear interpretation. For >example, suppose x{x, x+1, ... , y-1, y+1, ..., z} using three subchannels >(viz. start x, exclude y, end z) or must I use four? There's already words on ordering. This doesn't diminish your earlier point. >3.5.2 Label_Set Procedures >I suppose it is implicit, but there is no mention of inserting >Label_Set for the first time. > > >4. Bidirectional LSPs >I think it would help to point out that the support for >bidirectional LSPs added here is restricted to certain levels >of symmetry >- the TSpec is the same in both directions >- the LSRs on the path are the same in both directions >- the links between LSRs are not necessarily the same in both > directions. > All but LSRs were already mentioned. I added LSRs to the list. >Suggested_Label >Sorry if I missed this. >Must Suggested_Label be chosen from within the Label_Set? It's not a requirement, but use of such a suggestion will guarantee that the suggestion will not be used. >4.2 Bidirectional LSP Procedures >The choice you have made is consistent (that you may not >propagate a Path containing Upstream_Label until the local >switch has been programmed, so that the terminator may start >sending data as soon as it has processed the Path) but may >unnecessarily increase the latency of LSP set up (compare >with the arguments for Suggested_Label). >If ResvConf were to be requested and used, the individual >switch programming tasks could be processed in parallel with >the propagation of the Path message. The terminator is not >allowed to start sending data until it receives the ResvConf. >This is a direct trade-off, but could quite easily reduce >setup time for individual LSPs. This is a reasonable representation of the choice that was made. >4.3 Bidirectional LSP Contention Resolution >Note that action on receipt of a PathErr is in contradiction >with RFC2205. This is, however, the correct function in the >situation described. > if by "contradiction" you mean "different", I agree. >4.3 Bidirectional LSP Contention Resolution >The suggested behavior for reducing contention depends on >adjacent LSRs knowing each other's node IDs. Does this >rely on Hello messages, carnal knowledge or what? from the draft: For the purposes of RSVP contention resolution, the node ID is the IP address used in the RSVP_HOP object. >5. Notification >Flag this at the top as being RSVP only. The draft will soon be split (as mentioned at the last WG meeting) into a CR-LDP and RSVP draft, it'll be 100% clear at that point. >5.1.2 Notify Request Procedures >We should add a statement about multiple instances of this object. >The current discussion allows just a single instance. This is by design. Others have made the same point, but it wasn't clear that this functionality is really required. Why do you believe this is needed? >5.2.2 Notify Procedures >This version of the text does not prohibit the Notify Node from >being other than the requester (i.e. initiator or terminator). Again, this is by design. >We should either impose this for the time being, or note that >the Notify Node might not support Notify messages (and so will >not send an Ack). If you really think it's not obvious, we can state that the node inserting the NOTIFY_REQUEST must use an IPv4 Notify Node Address of a node known to support the notify message. >5.2.2 Notify Procedures >It's not clear to me that the default time of 1ms for combining >Notifies is relevant. > Not having default time values has held up other drafts. I put in a default to avoid this problem in the future. >5.3 Removing State with PathErr >Note that the reference to RFC 2205 here is obsoleted by the >actions required for bidriectional LSPs (see 4.3) and by >processing that may be utilized for local repair and fast >re-route. >In effect, RFC 2205's rules for forwarding PathErr without >taking action have are already bent. so noted. >5.3 Removing State with PathErr > >Can we add some text describing the Path state on downstream >nodes when Path_State_Removed is used. If I receive PathErr >w/o P_S_R, am I allowed to remove Path state and send PathErr >w/ P_S_R? from the draft: If the Path state is removed the Path_State_Removed flag SHOULD be set in the outgoing PathErr message. A node which does not remove the associated Path state MUST NOT set the Path_State_Removed flag. A node that receives an error with the Path_State_Removed flag set to zero MUST NOT set this flag unless it also generates a corresponding PathTear message. > >6.2 Procedures >The text listing the errors could do with some cleaning. okay, will review. >The L-bit isn't the only issue here. The nature of the previous >sub-object can be strict but imprecise (i.e. a non-unitary >abstract node .. prefix != 32) or could be an Autonomous System >number. In CR-LDP, the subobject could be an LSPId. As previously mentioned, all these cases are invalid and should result in an error. The next rev of the draft will be more explicit. >Reporting explicit labels. >draft-ietf-mpls-rsvp-lsp-tunnel-07 has scope in the RRO for >reporting labels, but this doesn't quite match the ERO extensions >here. In particular we need >- scope for two label objects per hop A good point! >- definition of the U bit >I believe that this should be in a new section 6.3 > > >Specifying links in EROs >I know we discussed this a bit before, but I want to check that >we're in synch. >We're allowing the IP address subobject in an explicit route to >identify an egress link rather than a next hop. It becomes a >local matter how such subobjects are handled. >We are not allowing specification of a link _and_ a next hop. This >rules out parallel links in a multidrop network. >We do not have the ability to specify an unnumbered link. I don't understand why you say this. >This is >seen as illogical since the indexes of unnumbered links have only >local (and possibly extending to the other end of the link) meaning. > > >BNFs >Label_Set is optional > Thanks. >Trivial typos (haven't I got better things to do?) >============= > Thank you! >5.2 "Notify Ack" is obsolete, read "Ack" I couldn't find this. Can you provide more context. >5.3 for "receiving such a error" read "receiving such an error" I couldn't find this. Can you provide more context. Thank you again for the detailed comments, Lou From owner-mpls@UU.NET Tue Oct 24 18:07:43 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18943 for ; Tue, 24 Oct 2000 18:07:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmiq11244; Tue, 24 Oct 2000 22:06:43 GMT Received: by mail-control.mail.uu.net id QQjmiq02252 for mpls-outgoing; Tue, 24 Oct 2000 22:06:21 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmiq02244 for ; Tue, 24 Oct 2000 22:06:13 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmiq06237 for ; Tue, 24 Oct 2000 22:04:47 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmiq08225 for ; Tue, 24 Oct 2000 22:04:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA09876 for mpls@uu.net; Tue, 24 Oct 2000 18:04:25 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmiq01656 for ; Tue, 24 Oct 2000 22:04:06 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmiq02251 for ; Tue, 24 Oct 2000 22:03:03 GMT Received: from mail-gw1.hursley.ibm.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-gw1.hursley.ibm.com [194.196.110.15]) id QQjmiq03692 for ; Tue, 24 Oct 2000 22:02:42 GMT Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA22946; Tue, 24 Oct 2000 22:57:31 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA28518; Tue, 24 Oct 2000 22:57:29 +0100 Message-ID: <39F602D6.7CFDDA25@hursley.ibm.com> Date: Tue, 24 Oct 2000 16:44:54 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Chatur sharp CC: diffserv@ietf.org, mpls@UU.NET, jh@telia.fi, fred@cisco.com, wweiss@lucent.com, jtw@lcs.mit.edu Subject: Re: [Diffserv] RFC2597 References: <20001024155519.19014.qmail@web5103.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Adding to what Kathie said... Chatur sharp wrote: > > Hi > > Thanks for your comments. But... So you accept my comments on AF? > > How about EF? Following is a flick from the EF > definition > RFC2598. > > " > The EF PHB is defined as a forwarding treatment > for a particular diffserv aggregate where the > departure rate of the aggregate's packets from any > diffserv node must equal or exceed a configurable > rate. The EF traffic SHOULD receive this rate > independent of the intensity of any other traffic > attempting to transit the node. It SHOULD average > at least the configured rate when measured over any > time interval equal to or longer than the time it > takes to send an output link MTU sized packet at > the configured rate. > " > > Now I do agree SHOULD is not same as MUST. But given > the scenario I have drawn how do you meet this > recommended requirement, over the time scales > mentioned in the RFC? Well, the EF PHB is being studied by a design team at present because there are indeed one or two problems in the definition. So maybe we can discuss this when the design team reports back. > To me DIFFSERV would be fine > if we take away the policing part. There is no need > for a meter. Only scheduler is enough. Sorry, any kind of QOS mechanism without metering and policing makes no sense whatever to me. A scheduler is not enough. > The kind of > link level rate limiting you are talking about in > DIFFSERV will fall apart once you have network with > different link speeds. Of course not; you configure the rates so that they fit into the lowest speed links. > To me DIFFSERV seems like > an attempt to divide one network into as many networks > as the number of DIFFSERV classes, with resources > being > allocated to each of them? Exactly > This a sub-optimal use of > network resources and does not provide any garuntees > which a lot of applications need. Hello? There is no free lunch. If you fully commit resources in a packet switched network with self-similar traffic distributions, you certainly can't give any guarantees. That's today's Internet. Mathematically, it's only by under-committing resources that you can give guarantees to some traffic streams without starving others. > > Anyhow phrases like : > " The EF traffic SHOULD receive this rate > independent of the intensity of any other traffic > attempting to transit the node. " > > Do not make any sense, till the time you specify what > is the meaning of transit. Does it mean that traffic > coming on interface i and going out of interface j > will have this commitment? If so it is fine, else > it is losing too much by coarse graining everything. Like any PHB, EF refers to the behavior at a specific egress. What this says is that the EF rate should be delivered at a specific egress, independent of other traffic. > > IMHO, DIFFSERV should provide an option to let > PHBs be associated to destination addresses or egress > points through a network if needed. No, PHBs are stateless so that they can be processed at line speed only by looking at the 6-bit DSCP. > It will still > allow > diffserv to work in the manner it is working today and No it wouldn't, because it wouldn't scale. > > will also enable SPs to provide garuntees which are > required by some of the real-time applications That is what EF is for already. > > Finally, I think the DIFFSERV-MPLS approach is > the right approach as it really takes into account > need of all kinds of traffic rather than just the > traditional IP services. Well, diffserv was invented to support non-traditional IP services. Diffserv over MPLS is just one mapping of diffserv onto a specific lower layer. Brian From owner-mpls@UU.NET Tue Oct 24 19:00:06 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25198 for ; Tue, 24 Oct 2000 19:00:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmit14376; Tue, 24 Oct 2000 22:59:30 GMT Received: by mail-control.mail.uu.net id QQjmit07586 for mpls-outgoing; Tue, 24 Oct 2000 22:59:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmit07577 for ; Tue, 24 Oct 2000 22:58:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmit16119 for ; Tue, 24 Oct 2000 22:58:21 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmit12781 for ; Tue, 24 Oct 2000 22:58:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA15066 for mpls@uu.net; Tue, 24 Oct 2000 18:58:20 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmit07482 for ; Tue, 24 Oct 2000 22:57:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmit05123; Tue, 24 Oct 2000 22:57:35 GMT Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmit13832; Tue, 24 Oct 2000 22:57:34 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA01408; Tue, 24 Oct 2000 15:57:22 -0700 (PDT) Message-Id: <200010242257.PAA01408@omega.cisco.com> To: "Lazer, Monica A, NNAD" cc: "'Yakov Rekhter'" , neil.2.harrison@bt.com, David.A.Holmes@disney.com, Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-reply-to: Your message of "Tue, 24 Oct 2000 15:47:58 EDT." <31236E6272C7D2119F1C0000C0A8E4F403240546@nj0200po04.bm.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1406.972428241.1@cisco.com> Date: Tue, 24 Oct 2000 15:57:21 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Monica, > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@cisco.com] > Sent: Tuesday, October 24, 2000 1:58 PM > To: neil.2.harrison@bt.com > Cc: David.A.Holmes@disney.com; Mark.Jones@mail.sprint.com; > ip-optical@lists.bell-labs.com; mpls@UU.NET; kireeti@juniper.net; > sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > Neil, > > [clipped...] > > > (i) are traditional IP control-plane facets (so that is, for > > example, v4 addressing, RSVP signalling and a IGP) the correct choice for > an > > OTN?....though to be honest no-one it seems dare raise this most basic of > > questions too loudly; > > > [MAL] Neil is right. I have not seen any overwhelming evidence as to why a > protocol used for routing individual packets is the best possible > alternative to be used to set-up circuits. > yakov > If you have "the correct choice" for an OTN, which is other than yakov > GMPLS, please share it with the rest of us (by the way, don't yakov > forget to include detailed description of why your "correct choice" yakov > is any better than GMPLS). If you think that Neil is right, then please share with the rest of us what do you think is "the best possible alternative" (please include an explanation on why it is any better than GMPLS). Yakov. P.S. On being constructive, let me suggest that rather than continue telling us that GMPLS is not "the best possible alternative to be used to set-up circuits", folks who subscribe to this point of view should start working on "the best possible alternative". From owner-mpls@UU.NET Tue Oct 24 19:08:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26080 for ; Tue, 24 Oct 2000 19:08:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmiu28765; Tue, 24 Oct 2000 23:07:40 GMT Received: by mail-control.mail.uu.net id QQjmiu20195 for mpls-outgoing; Tue, 24 Oct 2000 23:07:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmiu20188 for ; Tue, 24 Oct 2000 23:07:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmiu11305 for ; Tue, 24 Oct 2000 23:06:33 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmiu27216 for ; Tue, 24 Oct 2000 23:06:32 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA16246 for mpls@uu.net; Tue, 24 Oct 2000 19:06:31 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmiu19622 for ; Tue, 24 Oct 2000 23:05:51 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmiu06794; Tue, 24 Oct 2000 23:05:44 GMT Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmiu24091; Tue, 24 Oct 2000 23:05:43 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA02585; Tue, 24 Oct 2000 16:05:39 -0700 (PDT) Message-Id: <200010242305.QAA02585@omega.cisco.com> To: "valerie le faucheur" cc: Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-reply-to: Your message of "Tue, 24 Oct 2000 19:47:33 +0200." <000701c03de2$7d138b70$e971ff0a@algetytelecom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2582.972428738.1@cisco.com> Date: Tue, 24 Oct 2000 16:05:39 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Monica, > Following the ongoing discussions, I would like to add a couple of points. > The optical network is essentially used to set-up facilities=circuits. This > is done by having cross-connects set physical connections between > appropriate ports. The actual flow of traffic or packets is transparent to > the optical network. > >From a functional perspective this looks more like setting up a very, very > fat modem pipe between two pieces of equipment using optical network > facilities. So from this perspective I don't see why the peer model should > be preferred over the client model. Nobody is forcing you to use the peer model - it is completely your choice to use, or not to use it. > Furthermore, there are several standards documents co-authored by multiple > carriers indicating the need to support a client model. Nobody is forcing you not to use the overlay (aka client) model. It is completely your choice to use, or not to use it. Yakov. From owner-mpls@UU.NET Tue Oct 24 19:14:27 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26829 for ; Tue, 24 Oct 2000 19:14:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmiu04686; Tue, 24 Oct 2000 23:13:57 GMT Received: by mail-control.mail.uu.net id QQjmiu21125 for mpls-outgoing; Tue, 24 Oct 2000 23:13:37 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmiu21113 for ; Tue, 24 Oct 2000 23:13:35 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmiu23834 for ; Tue, 24 Oct 2000 23:13:03 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmiu05848 for ; Tue, 24 Oct 2000 23:13:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA17112 for mpls@uu.net; Tue, 24 Oct 2000 19:13:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmiu20881 for ; Tue, 24 Oct 2000 23:12:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmiu20389; Tue, 24 Oct 2000 23:12:16 GMT Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmiu02516; Tue, 24 Oct 2000 23:12:15 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA03342; Tue, 24 Oct 2000 16:11:47 -0700 (PDT) Message-Id: <200010242311.QAA03342@omega.cisco.com> To: Zhi-Wei Lin cc: "Fu, James" , "'Yakov Rekhter'" , neil.2.harrison@bt.com, David.A.Holmes@disney.com, Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-reply-to: Your message of "Tue, 24 Oct 2000 14:14:34 EDT." <39F5D18A.FF1E4476@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3339.972429106.1@cisco.com> Date: Tue, 24 Oct 2000 16:11:47 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Zhi, > Hi James, Yakov, > > I don't think the current discussion has lingered that long...I mean, > we've been asking to have service provider comments for a lot of this. > Now we have them, and are we simply to ignore them simply because they > don't agree? > > I don't think that should be the way the standards process works... > To repeat what I said before: There is no need to reach consensus on (ii) in the MPLS WG, as with GMPLS the choice between the peer and the overlay model is up to each service provider. In other words, it is *not* up to the MPLS WG to dictate to service providers whether to use the peer or the overlay model. That is the way the standards process works. Yakov. From owner-mpls@UU.NET Tue Oct 24 19:32:04 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28810 for ; Tue, 24 Oct 2000 19:32:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmiw25139; Tue, 24 Oct 2000 23:31:32 GMT Received: by mail-control.mail.uu.net id QQjmiw23567 for mpls-outgoing; Tue, 24 Oct 2000 23:30:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmiw23548 for ; Tue, 24 Oct 2000 23:30:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmiw22881 for ; Tue, 24 Oct 2000 23:30:00 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjmiw25281 for ; Tue, 24 Oct 2000 23:30:00 GMT Received: from tellium.com ([192.168.24.67]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9ONMCg07879; Tue, 24 Oct 2000 19:22:12 -0400 (EDT) Message-ID: <39F61B32.D773BB99@tellium.com> Date: Tue, 24 Oct 2000 19:28:50 -0400 From: Dimitrios Pendarakis X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ping Pan CC: ytr@csa.iisc.ernet.in, mpls@UU.NET Subject: Re: COPS doubt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ping, Ping Pan wrote: > On Tue, 24 Oct 2000, Dimitrios Pendarakis wrote: > > > To decide whether you need COPS, you should evaluate the relevance of these > > benefits to your network, taking into account the complexity of implementing COPS. > > In general, an external PDP is necessary if processing requirements of policy > > decisions are too high for your LSR, > > I thought LSR's don't need to maintain policy database, that's why we need > to keep it else where and use COPS to pick it up. > I thought you gave an answer to this yourself :-) Here is a quote from your previous message: "3. People can setup the policy entries from the routers directly without using COPS." BTW, is there a flaw in the above reasoning? I am not sure what your exact definition of a policy database is, but the fact that LSR's "don't need to maintain policy database" doesn't necessarily imply that we "need to keep it elsewhere and use COPS". You could apply the reverse argument as well: if the LSR can maintain a policy database, why can't it make policy decisions locally and avoid the need for COPS? It's all a matter of relative complexity... > > > if your LSR lacks the intelligence or the > > flexibility to provide the functionality, > > Wonder which LSR's are you referring to. :-) If LSR's can handle routing > protocols and RSVP, they'd better have a lot of intellengence and > flexibility. :-) > Not sure what answer you are looking for, but I wasn't referring to any particular LSR. However, people have talked about policies that one would expect several LSRs to have difficulty processing locally, especially if the policy decisions have to be made very frequently. RFC 2753 discusses some examples. And LSR's which have to do more work on the data plane might be more pressed to conserve cycles by outsourcing policy decisions :-) > > Take care! > > - Ping Regards, Dimitris From owner-mpls@UU.NET Tue Oct 24 21:07:55 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09678 for ; Tue, 24 Oct 2000 21:07:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmjc26447; Wed, 25 Oct 2000 01:07:33 GMT Received: by mail-control.mail.uu.net id QQjmjc23506 for mpls-outgoing; Wed, 25 Oct 2000 01:07:04 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmjc23493 for ; Wed, 25 Oct 2000 01:07:02 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmjc12604 for ; Wed, 25 Oct 2000 01:06:08 GMT Received: from NOD.RESTON.MCI.NET by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQjmjc26695 for ; Wed, 25 Oct 2000 01:06:08 GMT Received: from rbonica ([166.60.18.132]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JVQ9NBTEG69N4B3V@shoe.reston.mci.net> for mpls@UU.NET; Tue, 24 Oct 2000 21:06:04 EST Date: Tue, 24 Oct 2000 20:59:55 -0400 From: Ron Bonica Subject: Two orthogonal issue In-reply-to: <200010242311.QAA03342@omega.cisco.com> To: mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Folks, Have we been discussing two distinct questions, as if they were the same? These are: 1) Overlay model vs. Peer model 2) UNI vs MPLS signaling between client IP network and optical transport network The first issue addresses the degree to which a client IP network can access the optical transport network's signaling. The second issue addresses the syntax of the interface between the client IP network and optical transport network. These two issues are orthogonal to one another. One could (in theory) design a UNI that gives the client IP network total access to the optical transport networks world of signaling. Likewise, one could impose an access policy upon MPLS signaling such that the client IP network has very limited access to the optical transport network's world of signaling. Whether we choose a UNI or MPLS signaling, flexible access policy is required. That way, an optical carrier could decide exactly how much privilege to grant each client, on a case by case basis. Please re-orient me if I am missing the point, entirely. Ron P.S. I hope that I have not just opened Pandora's box. From owner-mpls@UU.NET Tue Oct 24 21:25:11 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11637 for ; Tue, 24 Oct 2000 21:25:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmjd18374; Wed, 25 Oct 2000 01:24:40 GMT Received: by mail-control.mail.uu.net id QQjmjd25284 for mpls-outgoing; Wed, 25 Oct 2000 01:24:05 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmjd25272 for ; Wed, 25 Oct 2000 01:23:55 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmjd20796 for ; Wed, 25 Oct 2000 01:22:36 GMT Received: from rly-ip01.mx.aol.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip01.mx.aol.com [205.188.156.49]) id QQjmjd15818 for ; Wed, 25 Oct 2000 01:22:36 GMT Received: from tot-wn.proxy.aol.com (tot-wn.proxy.aol.com [205.188.197.131]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id VAA28492; Tue, 24 Oct 2000 21:22:29 -0400 (EDT) Received: from cs.columbia.edu (AC8AA6BE.ipt.aol.com [172.138.166.190]) by tot-wn.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e9P1MOi32302; Tue, 24 Oct 2000 21:22:25 -0400 (EDT) Message-ID: <39F63428.8E40894E@cs.columbia.edu> Date: Tue, 24 Oct 2000 21:15:20 -0400 From: Ping Pan Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dimitrios Pendarakis CC: mpls@UU.NET Subject: Re: COPS doubt References: <39F61B32.D773BB99@tellium.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPPan@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dimitrios Pendarakis wrote: > > You could apply the reverse argument as well: if the LSR can maintain a policy > database, why can't it make policy decisions locally and avoid the need for COPS? > It's all a matter of relative complexity... > That's true. You're right. > However, people have talked about policies that one would expect several > LSRs to have difficulty processing locally, especially if the policy decisions have to be > made very frequently. RFC 2753 discusses some examples. > Processing packets base on policy (aka, enforcing policy) can consume a lot of CPU cycles. But this is somewhat different from processing policy decisions. Actually, I cannot imagine that there will be very frequent policy exchanges on purpose that can swamp LSR's, otherwise, we should call it man-made policy flopping and need to write a new draft on policy dampening. ;-) > And LSR's which have to do more work on the data plane might be more > pressed to conserve cycles by outsourcing policy decisions :-) > Take care, man. Just busting your chops. ;-) - Ping From owner-mpls@UU.NET Tue Oct 24 21:32:41 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12514 for ; Tue, 24 Oct 2000 21:32:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmje29632; Wed, 25 Oct 2000 01:32:25 GMT Received: by mail-control.mail.uu.net id QQjmje26073 for mpls-outgoing; Wed, 25 Oct 2000 01:32:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmje26061 for ; Wed, 25 Oct 2000 01:31:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmje14966; Wed, 25 Oct 2000 01:30:09 GMT Received: from Yellow.japan-telecom.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: Yellow.japan-telecom.co.jp [210.146.35.35]) id QQjmje22286; Wed, 25 Oct 2000 01:30:07 GMT Received: from japan-telecom.co.jp (localhost [127.0.0.1]) by Yellow.japan-telecom.co.jp (3.7W-Yellow) with ESMTP id KAA13228; Wed, 25 Oct 2000 10:26:07 +0900 (JST) Received: (from root@localhost) by japan-telecom.co.jp (3.7W-SP340201) id KAA15786; Wed, 25 Oct 2000 10:29:18 +0900 (JST) Date: Wed, 25 Oct 2000 10:29:18 +0900 (JST) Message-Id: <200010250129.KAA15786@japan-telecom.co.jp> Received: from unknown [172.18.82.49] by SP340201.japan-telecom.co.jp with SMTP id LAA15726 ; Wed, 25 Oct 2000 10:29:17 +0900 X-Sender: yone@172.18.44.2 X-Mailer: Windows Eudora Pro Version 2.1.2Jr2 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" To: Yakov Rekhter From: Susumu Yoneda Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Cc: "valerie le faucheur" , Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Sender: owner-mpls@UU.NET Precedence: bulk Yakov-san, Could you teach us whether the following aspects have some impacts on this i ssue or not? In the future, a customer may obtain - "always-on" broadband access, and - V6 global address. Thank you, > > Nobody is forcing you to use the peer model - it is completely your > choice to use, or not to use it. > > > Furthermore, there are several standards documents co-authored by multiple > > carriers indicating the need to support a client model. > > Nobody is forcing you not to use the overlay (aka client) model. > It is completely your choice to use, or not to use it. > > Yakov. > > > ------------------------------------------ Susumu Yoneda tel:+81 3 5540 8493 Japan Telecom fax:+81 3 5540 8485 Information and Communication Labs. e-mail: yone@japan-telecom.co.jp ------------------------------------------ From owner-mpls@UU.NET Tue Oct 24 22:45:07 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22449 for ; Tue, 24 Oct 2000 22:45:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmji24714; Wed, 25 Oct 2000 02:44:27 GMT Received: by mail-control.mail.uu.net id QQjmji13832 for mpls-outgoing; Wed, 25 Oct 2000 02:43:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmji13823 for ; Wed, 25 Oct 2000 02:43:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmji05084 for ; Wed, 25 Oct 2000 02:43:49 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjmji27536 for ; Wed, 25 Oct 2000 02:43:48 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA15974; Tue, 24 Oct 2000 19:43:46 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id TAA07887; Tue, 24 Oct 2000 19:43:46 -0700 (PDT) Date: Tue, 24 Oct 2000 19:43:46 -0700 (PDT) From: Kireeti Kompella Message-Id: <200010250243.TAA07887@kummer.juniper.net> To: mpls@UU.NET, rbonica@mci.net Subject: Re: Two orthogonal issue Sender: owner-mpls@UU.NET Precedence: bulk Hi Ron, > Have we been discussing two distinct questions, as if they were the same? > These are: > 1) Overlay model vs. Peer model > 2) UNI vs MPLS signaling between client IP network and optical transport > network > The first issue addresses the degree to which a client IP network can access > the optical transport network's signaling. The second issue addresses the > syntax of the interface between the client IP network and optical transport > network. Good distinction. > These two issues are orthogonal to one another. In principle, yes. In practice, though, the connotation of "UNI" is pretty much "overlay" -- the distinction between U and N means that there is a restriction in information exchange. And in any case, the current UNI spec has a very restricted flow of information across the U/N border -- it's primarily a signalling protocol, and the information exchange is "end point discovery" and "LSP status". However, in GMPLS, both models are supported equally. For the peer model, one puts all boxes in one IGP area. One easy way to accomplish the overlay model is by the notion of IGP areas; another is by means of IGP instances. The finishing touch is to define a good means of doing inter-area TE which includes GMPLS TE (watch this space). > Whether we choose a UNI or MPLS signaling, flexible access policy is > required. That way, an optical carrier could decide exactly how much > privilege to grant each client, on a case by case basis. Absolutely. A lot of folks don't seem to get this point: for example, one could have OXCs and *some* routers in the backbone area; other routers in non-backbone areas, and yet other clients (routers, ADMs, ...) accessing the same OXCs via the UNI. And one could run NMS systems as well for provisioning legacy boxes. > Please re-orient me if I am missing the point, entirely. You aren't. Note however that two other points have been raised: a) is IP the "right" protocol for the control plane; and b) is GMPLS the "right" protocol for the control plane. However, I haven't seen convincing arguments that IP and GMPLS aren't suitable; nor have I seen alternate proposals. > P.S. I hope that I have not just opened Pandora's box. No, it was already wide open :-) One thing that has come out of this debate is that carriers are thinking more deeply about requirements, which is a welcome step forward. At the same time, several deep-rooted biases are being exposed, and I'll be the first to admit my bias towards using MPLS/GMPLS for the control plane. Another step forward, but this one is more painful. Kireeti. From owner-mpls@UU.NET Tue Oct 24 23:28:07 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27186 for ; Tue, 24 Oct 2000 23:28:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmjl18096; Wed, 25 Oct 2000 03:27:36 GMT Received: by mail-control.mail.uu.net id QQjmjl29233 for mpls-outgoing; Wed, 25 Oct 2000 03:27:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmjl29215 for ; Wed, 25 Oct 2000 03:27:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmjl12048 for ; Wed, 25 Oct 2000 03:26:58 GMT Received: from smtprch1.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjmjl21279 for ; Wed, 25 Oct 2000 03:26:58 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 24 Oct 2000 22:26:32 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 24 Oct 2000 22:26:30 -0500 Message-ID: From: "Wenbo Sheng" To: "'mpls-ops@mplsrc.com'" Cc: "'mpls@uu.net'" Subject: VPN solution Date: Tue, 24 Oct 2000 22:26:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03E33.5D8586E0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03E33.5D8586E0 Content-Type: text/plain; charset="iso-8859-1" HI, Assuming my customer need to create a VPN, I just want to know which solution is better - using MPLS-VPN or virtual routers? Which solution is/will be more popular in creating a VPN? Thanks in advance, W.S. ------_=_NextPart_001_01C03E33.5D8586E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VPN solution

HI,

Assuming my customer need to = create a VPN, I just want to know which solution is better - using = MPLS-VPN or virtual routers? Which solution is/will be more popular in = creating a VPN?

Thanks in advance,

W.S.

------_=_NextPart_001_01C03E33.5D8586E0-- From owner-mpls@UU.NET Wed Oct 25 00:34:52 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07915 for ; Wed, 25 Oct 2000 00:34:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmjq14903; Wed, 25 Oct 2000 04:34:27 GMT Received: by mail-control.mail.uu.net id QQjmjq16411 for mpls-outgoing; Wed, 25 Oct 2000 04:33:54 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmjq16397 for ; Wed, 25 Oct 2000 04:33:36 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmjq02924 for ; Wed, 25 Oct 2000 04:33:20 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjmjq13365 for ; Wed, 25 Oct 2000 04:33:17 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id KAA23107; Wed, 25 Oct 2000 10:01:15 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id KAA21354; Wed, 25 Oct 2000 10:02:55 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Wed, 25 Oct 2000 10:02:55 +0530 (IST) From: Ramanjaneyulu Y T To: Ping Pan cc: Dimitrios Pendarakis , mpls@UU.NET Subject: Re: COPS doubt In-Reply-To: <39F63428.8E40894E@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Thsnks for your comments. After reading your comments , we came to the following conclusions. * We need some entity to take policy decisions , so this is situated in LSR, according to RFC 2753 , PDP is situated in LSRs * For future expansion , we are planning to use COPS between PDP and RSVP-TE. What do u say?. Thanks once again Regards Ramanjaneyulu Y.T. -------------------------------------------------------------------------------- On Tue, 24 Oct 2000, Ping Pan wrote: > Dimitrios Pendarakis wrote: > > > > You could apply the reverse argument as well: if the LSR can maintain a policy > > database, why can't it make policy decisions locally and avoid the need for COPS? > > It's all a matter of relative complexity... > > > > That's true. You're right. > > > However, people have talked about policies that one would expect several > > LSRs to have difficulty processing locally, especially if the policy decisions have to be > > made very frequently. RFC 2753 discusses some examples. > > > > Processing packets base on policy (aka, enforcing policy) can consume a > lot of CPU cycles. But this is somewhat different from processing policy > decisions. Actually, I cannot imagine that there will be very frequent > policy exchanges on purpose that can swamp LSR's, otherwise, we should > call it man-made policy flopping and need to write a new draft on policy > dampening. ;-) > > > And LSR's which have to do more work on the data plane might be more > > pressed to conserve cycles by outsourcing policy decisions :-) > > > > Take care, man. Just busting your chops. ;-) > > - Ping > From owner-mpls@UU.NET Wed Oct 25 02:49:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27176 for ; Wed, 25 Oct 2000 02:49:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmjz29247; Wed, 25 Oct 2000 06:49:13 GMT Received: by mail-control.mail.uu.net id QQjmjz20640 for mpls-outgoing; Wed, 25 Oct 2000 06:48:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmjz20632 for ; Wed, 25 Oct 2000 06:48:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmjz28948 for ; Wed, 25 Oct 2000 06:48:36 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjmjz28800 for ; Wed, 25 Oct 2000 06:48:33 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id LAA24925 for ; Wed, 25 Oct 2000 11:58:25 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id MAA24496 for ; Wed, 25 Oct 2000 12:00:16 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Wed, 25 Oct 2000 12:00:16 +0530 (IST) From: Gaitonde Anandprasanna Reply-To: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Question about LSP ID and Tunnel ID Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have one question about RSVP-TE:- The extensions to RVP-TE has the following additional objects: LSP_TUNNEL_IPv4 SenderTemplate Object which contains the LSP ID LSP_TUNNEL_IPv4 Session Object which contains the Tunnel ID. When ever RSVP-TE gets a new request (a Microflow) it has to pass this microflow into either an exisitng LSP or create a new LSP for it (Am i right??) So based on that descision the field like LSP ID and the Tunel ID will be field in the Path messaage and will be sent along the path. If what i have said above is correct then it perhaps these fields should be filled only after contacting the PDP server (that is by querying the policies). Is this correct? Or is that the fields i mentioned above should be filled before contacting the PDP server and should be done by RSVP_TE itself. Thanx in advance waiting for reply Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Wed, 25 Oct 2000 04:22:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmkf19354; Wed, 25 Oct 2000 08:22:00 GMT Received: by mail-control.mail.uu.net id QQjmkf19717 for mpls-outgoing; Wed, 25 Oct 2000 08:21:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmkf19712 for ; Wed, 25 Oct 2000 08:21:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmkf09328 for ; Wed, 25 Oct 2000 08:20:41 GMT Received: from yamato.ccrle.nec.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: yamato.ccrle.nec.de [195.37.70.1]) id QQjmkf21259 for ; Wed, 25 Oct 2000 08:20:41 GMT Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e9P8KWT55007; Wed, 25 Oct 2000 10:20:32 +0200 (CEST) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA13161; Wed, 25 Oct 2000 10:20:38 +0200 Message-ID: <39F69929.E43CA843@ccrle.nec.de> Date: Wed, 25 Oct 2000 10:26:17 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: Ping Pan CC: "mpls@UU.NET" Subject: Re: COPS doubt References: <39F59AB5.DCD4D8A@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ping Pan wrote: > > The way I view the use of COPS in MPLS networking environment is the > same as RIPE being used for BGP route filters in the backbone today. > ISP's can define a bunch of TE policies to map user traffic to some MPLS > LSP's at the network edge. That information is sent to the edge routers > (LSR's or PEP's) via COPS, where a COPS PDP is a UNIX box sitting at NOC > somewhere running COPS daemon. When something is wrong, the LSR's can > notify the PDP via COPS too. > > But, IMH, here is something more: > 1. COPS PEP should not be put on every routers, only border/edge ones at > best. Wrong in cases where you want to perform traffic engeneering using MPLS tunnels. > 2. COPS distributes policies only, and is not a signaling mechanism to > select bandwidth, labels, routing path... It is not a signalling mechanism, but it may initiate the signaling protocol. > 3. People can setup the policy entries from the routers directly without > using COPS. > 4. If people actually deploy SNMP with security and set/trap > functionality, that would work too. > > Here is a badly out-dated web page on an out-dated ID: > http://www.cs.columbia.edu/~pingpan/projects/policy_cu.html > > - Ping > > "Y.T. Ramanjaneyulu" wrote: > > > > HI, > > > > I am currently working on a Project which involves developing a Label > > Switched router in a MPLS domain.The core protocols which are used in this > > work are MPLS as the forwarding mechanism and RSVP-TE as the signalling > > Protocol.Main intention of ours is to provide Qos services to the end users in MPLS > > domain. > > > > I thought of having a Resource manager inside each LSR to manage the > > resources locally. We have policies to allow user to consume only certain amount of > > bandwidth etc. > > > > PDP generally situated in some remote machine and collecting statistics > > from allclients and making descisions . > > > > So in our scenario is it necessary to have a PEP and a PDP (COPS > > Protocol) inside the network ??? > > > > > > Thanx in advance > > > > -- > > Regards > > YTR > > -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From owner-mpls@UU.NET Wed Oct 25 05:00:09 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29519 for ; Wed, 25 Oct 2000 05:00:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmkh05634; Wed, 25 Oct 2000 08:59:48 GMT Received: by mail-control.mail.uu.net id QQjmkh21569 for mpls-outgoing; Wed, 25 Oct 2000 08:59:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmkh21562 for ; Wed, 25 Oct 2000 08:59:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmkh11640 for ; Wed, 25 Oct 2000 08:59:00 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f230.law4.hotmail.com [216.33.149.230]) id QQjmkh04498 for ; Wed, 25 Oct 2000 08:58:59 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Oct 2000 01:58:59 -0700 Received: from 138.96.192.3 by lw4fd.law4.hotmail.msn.com with HTTP; Wed, 25 Oct 2000 08:58:58 GMT X-Originating-IP: [138.96.192.3] From: "Rares SERBAN" To: pingpan@cs.columbia.edu, dpendarakis@tellium.com Cc: mpls@UU.NET Subject: Re: COPS doubt Date: Wed, 25 Oct 2000 08:58:58 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Oct 2000 08:58:59.0054 (UTC) FILETIME=[D01AC8E0:01C03E61] Sender: owner-mpls@UU.NET Precedence: bulk Hi, First, you can use COPS-Policy Framework to make provisioning and outsourcing (MPLS, RSVP cases). If the LSR (in MPLS) makes policy decisions, it MUST report (RPT message) to PDP (Policy Server) its decisions. The policy decision is taking just at the edge of the network. Don't worry if takes time. Is not time expensive like routing process. :) Thanks, R. --------------------------------------- Ph.D. student Rares Serban, MsCS http://www.inria.fr/rodeo/Rares.Serban/ --------------------------------------- >From: Ping Pan >To: Dimitrios Pendarakis >CC: mpls@UU.NET >Subject: Re: COPS doubt >Date: Tue, 24 Oct 2000 21:15:20 -0400 > >Dimitrios Pendarakis wrote: > > > > You could apply the reverse argument as well: if the LSR can maintain a >policy > > database, why can't it make policy decisions locally and avoid the need >for COPS? > > It's all a matter of relative complexity... > > > >That's true. You're right. > > > However, people have talked about policies that one would expect several > > LSRs to have difficulty processing locally, especially if the policy >decisions have to be > > made very frequently. RFC 2753 discusses some examples. > > > >Processing packets base on policy (aka, enforcing policy) can consume a >lot of CPU cycles. But this is somewhat different from processing policy >decisions. Actually, I cannot imagine that there will be very frequent >policy exchanges on purpose that can swamp LSR's, otherwise, we should >call it man-made policy flopping and need to write a new draft on policy >dampening. ;-) > > > And LSR's which have to do more work on the data plane might be more > > pressed to conserve cycles by outsourcing policy decisions :-) > > > >Take care, man. Just busting your chops. ;-) > >- Ping _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Wed Oct 25 06:28:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27173 for ; Wed, 25 Oct 2000 06:28:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmkn26728; Wed, 25 Oct 2000 10:27:55 GMT Received: by mail-control.mail.uu.net id QQjmkn20133 for mpls-outgoing; Wed, 25 Oct 2000 10:27:29 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmkn20126 for ; Wed, 25 Oct 2000 10:27:24 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmkn05978 for ; Wed, 25 Oct 2000 10:27:02 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjmkn25367 for ; Wed, 25 Oct 2000 10:26:51 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 25 Oct 2000 15:59:02 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id PAA06122; Wed, 25 Oct 2000 15:43:43 +0530 Reply-To: From: "Manikantan S" To: "Antonela Paraschiv (E-mail)" Cc: Subject: Doubts in "draft-ietf-mpls-lsp-query-00.txt" Date: Wed, 25 Oct 2000 15:50:49 +0530 Message-Id: <002e01c03e6d$3fb8b1c0$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Paraschiv I read the draft "draft-ietf-mpls-lsp-query-00.txt". I have a few doubts and can you please clarify them? Thanks. 1) Label TLV is used in the Query message and the Query Label TLV as Optional parameters in the Query Reply message. Both the TLVs contain a set of Generalized Label TLVs. I am not clear as why do we require Query Label TLV and Label TLV i.e., two TLVs when the contents are the same? 2) ER TLV has been specified as Optional parameters in Query Message and in Query-reply message. I understand that this TLV's usage is to keep track of the hops. Path Vector TLV (in LDP), RRO in (RSVP-TE)helps in providing this information too. What is the significance of using ER TLV? 3) In Section 5.2 Page 9, we have -------------------------------------------------------------------- Upon receiving a Query Message, an LSR decodes the label to identify which LSP is queried. If it cannot find the LSP which is using the label, it sends back a Notification message. -------------------------------------------------------------------- What is the status value that should be indicated in this case? 4) In Section 6.2 Page 12, we have ------------------------------------------------------------------- A Query-Reply message is initiated by an egress node which receives a Query message, if the egress is able to identify the queried LSP. If not, the egress replies with a Notification message. -------------------------------------------------------------------- What is the status value that should be indicated in this case? Should this be the same one as for question 3? I noticed Following minor typos/missing info 1) Section 6.3 Page 13 we have +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Query-Reply (0x0411) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ should be +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Partial-Query-Reply (0x0411)| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2) Section 7.2 Page 16 for "The format for the Query Label TLV " read "The format for the Merge Flags TLV" 3) Section 7.3 Page 16 for "The format for the Query Label TLV " read "The format for the Label TLV" Thanks in advance with best regards mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com ----------------------------------------- From owner-mpls@UU.NET Wed Oct 25 07:19:50 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15529 for ; Wed, 25 Oct 2000 07:19:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmkr25396; Wed, 25 Oct 2000 11:18:40 GMT Received: by mail-control.mail.uu.net id QQjmkr04419 for mpls-outgoing; Wed, 25 Oct 2000 11:18:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmkr04414 for ; Wed, 25 Oct 2000 11:17:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmkr12225 for ; Wed, 25 Oct 2000 11:16:36 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmkr22730 for ; Wed, 25 Oct 2000 11:16:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA01515 for mpls@uu.net; Wed, 25 Oct 2000 07:16:35 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmkr04332 for ; Wed, 25 Oct 2000 11:16:21 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmkr03495; Wed, 25 Oct 2000 11:15:41 GMT Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmkr25066; Wed, 25 Oct 2000 11:15:41 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id EAA20263; Wed, 25 Oct 2000 04:15:34 -0700 (PDT) Message-Id: <200010251115.EAA20263@omega.cisco.com> To: Susumu Yoneda cc: "valerie le faucheur" , Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-reply-to: Your message of "Wed, 25 Oct 2000 10:29:18 +0900." <200010250129.KAA15786@japan-telecom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20261.972472534.1@cisco.com> Date: Wed, 25 Oct 2000 04:15:34 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Susumu, > Yakov-san, > > Could you teach us whether the following aspects have some impacts on this i > issue or not? > In the future, a customer may obtain > - "always-on" broadband access, and > - V6 global address. To the best of my knowledge the above aspects have no impact on the this issue. Yakov. > > Thank you, > > > > > Nobody is forcing you to use the peer model - it is completely your > > choice to use, or not to use it. > > > > > Furthermore, there are several standards documents co-authored by multipl e > > > carriers indicating the need to support a client model. > > > > Nobody is forcing you not to use the overlay (aka client) model. > > It is completely your choice to use, or not to use it. > > > > Yakov. > > > > > > > ------------------------------------------ > Susumu Yoneda tel:+81 3 5540 8493 > Japan Telecom fax:+81 3 5540 8485 > Information and Communication Labs. > e-mail: yone@japan-telecom.co.jp > ------------------------------------------ > From owner-mpls@UU.NET Wed Oct 25 07:38:15 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22646 for ; Wed, 25 Oct 2000 07:38:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmks22998; Wed, 25 Oct 2000 11:37:52 GMT Received: by mail-control.mail.uu.net id QQjmks05446 for mpls-outgoing; Wed, 25 Oct 2000 11:37:31 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmks05440 for ; Wed, 25 Oct 2000 11:37:28 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmks20082 for ; Wed, 25 Oct 2000 11:36:16 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmks17003 for ; Wed, 25 Oct 2000 11:36:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA02911 for mpls@uu.net; Wed, 25 Oct 2000 07:36:15 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmks05294 for ; Wed, 25 Oct 2000 11:35:58 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmks18279; Wed, 25 Oct 2000 11:35:30 GMT Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmks19660; Wed, 25 Oct 2000 11:35:29 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id EAA21131; Wed, 25 Oct 2000 04:35:27 -0700 (PDT) Message-Id: <200010251135.EAA21131@omega.cisco.com> To: alchiu@research.att.com cc: ip-optical@lists.bell-labs.com, mpls@UU.NET, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-reply-to: Your message of "Tue, 24 Oct 2000 19:48:16 +0200." <000801c03de2$97466490$e971ff0a@algetytelecom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21129.972473727.1@cisco.com> Date: Wed, 25 Oct 2000 04:35:27 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Angela, > Some followup discussions in line. more in line... > Regards, > Angela > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kireeti > Kompella > Sent: Monday, October 23, 2000 1:58 PM > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > > I don't see why TE and protection require the routers to specify explicit > > routes. > > The routers can simply specify to the optical layer what type of optical > > layer protection > > it requires. > > Suppose router A wants to get to router B, and wants to take two > different ingress and egress points in the optical domain, X->Y > for the primary LSP, and W->Z for the backup. A does not require > optical protection for the X->Y path, nor for the W->Z path. A > *does* require that the X->Y path and the W->Z path do not share > common links. How is this to be done? > > If A did the full path computation, this is simplicity itself. > > [AC] I think you have a good point here. I also heard the same kind if > reasoning (i.e., have a layer-3 like protection switching) for supporting > the peer model. But after discussing with others, it seems that overlay > model should be able to provide the same capability. Not really... for more on this see below... > Normally, the primary > LSP X->Y is set up first, and becomes a forwarding adjacency (FA) according > to your LSP Hierarchy draft. Then the associated information of the FA X->Y > including its exact path and SRLG information should be propagated via IGP > extensions, same as with any other link in the network. Thus if router A > sends a request to OXC W to set up a backup lightpath from W->Z to be > diversely router from the existing FA X->Y, OXC W should already have the > right information to perform proper routing. It is a known fact that for computing disjoint paths the approach you outlined above may result in a situation where no backup path will be found, despite the fact that that it is possible (using some other approach) to find two disjoint paths. > Comparing with the peer model solution where routers need to know all the > SRLG information of the optical domain as well as all relevant physical > impairments in the optical signal in the case of transparent optical > network, it is still not clear to me which one is simpler. > > I think it is very good to have this kind of technical discussion openly on > the list. Hope others can provide more technical and business (after all > carriers need to pay for these features) evidences for the need of each > model. Some other reasoning I heard includes that peer model can improve the > IGP scalability in terms of the number of neighbors a router needs to peer > with. But since large ISPs today seem to cope well with the IGP scalability > today, I don't see why the problem will get significant worst when optical > networks come into play. In the end it is not the discussion on this list, but the competition in the marketplace that will determine the viability of different models. Yakov. From owner-mpls@UU.NET Wed Oct 25 09:01:59 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17123 for ; Wed, 25 Oct 2000 09:01:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmky08892; Wed, 25 Oct 2000 13:01:26 GMT Received: by mail-control.mail.uu.net id QQjmky25323 for mpls-outgoing; Wed, 25 Oct 2000 13:00:52 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmky24960 for ; Wed, 25 Oct 2000 13:00:41 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmky04021 for ; Wed, 25 Oct 2000 13:00:32 GMT Received: from rly-ip02.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip02.mx.aol.com [152.163.225.160]) id QQjmky08720 for ; Wed, 25 Oct 2000 13:00:32 GMT Received: from tot-te.proxy.aol.com (tot-te.proxy.aol.com [152.163.195.131]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id JAA21315; Wed, 25 Oct 2000 09:00:25 -0400 (EDT) Received: from cs.columbia.edu (AC9A1FD8.ipt.aol.com [172.154.31.216]) by tot-te.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e9PD0NQ01896; Wed, 25 Oct 2000 09:00:23 -0400 (EDT) Message-ID: <39F6D7BF.70EE46DB@cs.columbia.edu> Date: Wed, 25 Oct 2000 08:53:19 -0400 From: Ping Pan Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ramanjaneyulu Y T CC: Dimitrios Pendarakis , mpls@UU.NET Subject: Re: COPS doubt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPPan@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ramanjaneyulu Y T wrote: > > Thsnks for your comments. After reading your comments , we came to > the following conclusions. > > * We need some entity to take policy decisions , so this is situated > in LSR, according to RFC 2753 , PDP is situated in LSRs > That is, you should be able to input policy driectly at the LSR's. > * For future expansion , we are planning to use COPS between PDP and > RSVP-TE. > That's a good idea, especially when you have many policy entris to manage. > What do u say?. > > Thanks once again > Regards > Ramanjaneyulu Y.T. - Ping From owner-mpls@UU.NET Wed Oct 25 09:04:37 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17705 for ; Wed, 25 Oct 2000 09:04:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmky07801; Wed, 25 Oct 2000 13:03:45 GMT Received: by mail-control.mail.uu.net id QQjmky01481 for mpls-outgoing; Wed, 25 Oct 2000 13:03:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmky00800 for ; Wed, 25 Oct 2000 13:03:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmky00796; Wed, 25 Oct 2000 13:02:37 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQjmky06266; Wed, 25 Oct 2000 13:02:37 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA26036; Wed, 25 Oct 2000 09:02:36 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id JAA26000; Wed, 25 Oct 2000 09:02:35 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA16042; Wed, 25 Oct 2000 09:02:35 -0400 Message-ID: <39F6D9D0.56FBDE8B@lucent.com> Date: Wed, 25 Oct 2000 09:02:08 -0400 From: Zhi-Wei Lin Organization: Lucent Technologies X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: "Fu, James" , neil.2.harrison@bt.com, David.A.Holmes@disney.com, Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <200010242311.QAA03342@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yakov, I agree. The MPLS WG do not dictate to service providers. It will be the service providers' decision which method will be accepted in their network. I just thought that since the service providers have provided their input as to what is more important in the near future, we should at least try to get something that should be aligned with their desire... Maybe some folks don't think this is such an important issue then... Zhi Yakov Rekhter wrote: > > Zhi, > > > Hi James, Yakov, > > > > I don't think the current discussion has lingered that long...I mean, > > we've been asking to have service provider comments for a lot of this. > > Now we have them, and are we simply to ignore them simply because they > > don't agree? > > > > I don't think that should be the way the standards process works... > > > > To repeat what I said before: > > There is no need to reach consensus on (ii) in the MPLS WG, as with > GMPLS the choice between the peer and the overlay model is > up to each service provider. > > In other words, it is *not* up to the MPLS WG to dictate to service providers > whether to use the peer or the overlay model. That is the way the > standards process works. > > Yakov. -- Zhi-Wei Lin Lucent Technologies Tel: +1 732 949 5141 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com From owner-mpls@UU.NET Wed Oct 25 09:05:32 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17932 for ; Wed, 25 Oct 2000 09:05:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmky13544; Wed, 25 Oct 2000 13:04:52 GMT Received: by mail-control.mail.uu.net id QQjmky03317 for mpls-outgoing; Wed, 25 Oct 2000 13:04:14 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmky03188 for ; Wed, 25 Oct 2000 13:04:06 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmky11241 for ; Wed, 25 Oct 2000 13:03:40 GMT Received: from xaloc.upc.es by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: xaloc.upc.es [147.83.105.131]) id QQjmky11920 for ; Wed, 25 Oct 2000 13:03:39 GMT Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id PAA02923; Wed, 25 Oct 2000 15:01:49 +0200 (METDST) Message-ID: <39F6E846.C369AEA@estos.upc.es> Date: Wed, 25 Oct 2000 15:03:50 +0100 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Wenbo Sheng CC: MPLS WG Subject: Re: VPN solution References: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Wenbo,

The method to build VPNs most discussed (and that makes me think
that is the most popular) in this mailing list is
the BGP/MPLS model explained in  draft-rosen-rfc2547bis-02.txt . Personally I
think this method has a lot of advantages such as scalability, security, manageability
and use of private addressing. Some of this advantages (specially scalability) have been 
discussed in this mailing list.

Best Regards,

Diego

Wenbo Sheng wrote:

HI,

Assuming my customer need to create a VPN, I just want to know which solution is better - using MPLS-VPN or virtual routers? Which solution is/will be more popular in creating a VPN?

Thanks in advance,

W.S.


--
http://www.geocities.com/diego_otero/
  From owner-mpls@UU.NET Wed Oct 25 09:25:04 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24472 for ; Wed, 25 Oct 2000 09:25:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmkz05241; Wed, 25 Oct 2000 13:24:32 GMT Received: by mail-control.mail.uu.net id QQjmkz05367 for mpls-outgoing; Wed, 25 Oct 2000 13:24:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmkz05355 for ; Wed, 25 Oct 2000 13:24:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmkz04046 for ; Wed, 25 Oct 2000 13:23:46 GMT Received: from rly-ip02.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rly-ip02.mx.aol.com [152.163.225.160]) id QQjmkz09417 for ; Wed, 25 Oct 2000 13:23:46 GMT Received: from tot-te.proxy.aol.com (tot-te.proxy.aol.com [152.163.195.131]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id JAA08995; Wed, 25 Oct 2000 09:23:40 -0400 (EDT) Received: from cs.columbia.edu (AC9A1FD8.ipt.aol.com [172.154.31.216]) by tot-te.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e9PDNcQ23858; Wed, 25 Oct 2000 09:23:38 -0400 (EDT) Message-ID: <39F6DD33.951E99BB@cs.columbia.edu> Date: Wed, 25 Oct 2000 09:16:35 -0400 From: Ping Pan Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: brunner@ccrle.nec.de CC: "mpls@UU.NET" Subject: Re: COPS doubt References: <39F59AB5.DCD4D8A@cs.columbia.edu> <39F69929.E43CA843@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: PingPPan@aol.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Marcus Brunner wrote: > > > 1. COPS PEP should not be put on every routers, only border/edge ones at > > best. > > Wrong in cases where you want to perform traffic engeneering using MPLS > tunnels. > Are you suggesting of using COPS instead of RSVP-TE? Don't. :-) If you argue to use both RSVP-TE and COPS in the same network for MPLS, installing COPS in every router is a bad idea for several reasons: 1. Since the control is at PDP's, the PDP's need to know everything about the network at all time. The information includes routing topology (both static and dynamic) and resource availability at every link. Otherwise, you cannot setup explict-routing path for TE. 2. The LSR's (PEP's) need to tell PDP's about path setup every step of the way, including the processing of new messages (PATH and RESV), as well as reservation termination or error (RESVTEAR, PATHTEAR, RESVERR and PATHERR). In a large backbone, you may have as many as 300-400 routers, and thousands of reservation states. What do you think the cost of message processing and state synchronizing at both PDP's and PEP's would be? So, if you want to have any policy control over LSP's, do it at edge. Policy download may be COPS, but network resource monitoring and updating should be using OSPF-TE and ISIS-TE, while tunnel setup and maintenance should be done with RSVP-TE/CR-LDP. - Ping From owner-mpls@UU.NET Wed Oct 25 09:41:31 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00047 for ; Wed, 25 Oct 2000 09:41:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmla01800; Wed, 25 Oct 2000 13:40:30 GMT Received: by mail-control.mail.uu.net id QQjmla06213 for mpls-outgoing; Wed, 25 Oct 2000 13:39:54 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmla06203 for ; Wed, 25 Oct 2000 13:39:47 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmla27557 for ; Wed, 25 Oct 2000 13:39:40 GMT Received: from qhars002.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: qhars002.NortelNetworks.com [192.100.101.19]) id QQjmla29250 for ; Wed, 25 Oct 2000 13:39:40 GMT Received: from znsgd00t.europe.nortel.com (actually znsgd00t) by qhars002.nortel.com; Wed, 25 Oct 2000 14:39:15 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 25 Oct 2000 14:39:13 +0100 Message-ID: From: "Javier Gonzalez" To: Juan Diego Otero , "Wenbo Sheng" Cc: MPLS WG Subject: RE: VPN solution Date: Wed, 25 Oct 2000 14:39:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03E88.F2ED3480" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03E88.F2ED3480 Content-Type: text/plain; charset="iso-8859-1" The fact that the BGP/MPLS model explained in the informational draft described below is the most discussed does not necessarily make it the best possible solution. Can you please provide more insight into the actual scalability, security, manageability and use of private addressing details that you make reference to ? Have you read/implemented: http://www.ietf.cnri.reston.va.us/rfc/rfc2764.txt?number=2764 or http://www.ietf.org/internet-drafts/draft-ouldbrahim-vpn-vr-01.txt or http://www.ietf.org/internet-drafts/draft-ouldbrahim-bgp-vpn-00.txt Javier -----Original Message----- From: Juan Diego Otero [mailto:diego@estos.upc.es] Sent: 25 October 2000 16:04 To: Sheng, Wenbo Cc: MPLS WG Subject: Re: VPN solution Hi Wenbo, The method to build VPNs most discussed (and that makes me think that is the most popular) in this mailing list is the BGP/MPLS model explained in draft-rosen-rfc2547bis-02.txt . Personally I think this method has a lot of advantages such as scalability, security, manageability and use of private addressing. Some of this advantages (specially scalability) have been discussed in this mailing list. Best Regards, Diego Wenbo Sheng wrote: HI, Assuming my customer need to create a VPN, I just want to know which solution is better - using MPLS-VPN or virtual routers? Which solution is/will be more popular in creating a VPN? Thanks in advance, W.S. -- http://www.geocities.com/diego_otero/ ------_=_NextPart_001_01C03E88.F2ED3480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The=20 fact that the BGP/MPLS model explained in the informational draft = described=20 below is the most discussed does not necessarily make it the best = possible=20 solution.  Can you please provide more insight into the actual = scalability,=20 security, manageability and use of private addressing details that you = make=20 reference to ?  Have you = read/implemented:
 
http://www.ietf.cnri.reston.va.us/rfc/rfc2764.txt?number=3D2764
or
http://www.ietf.org/internet-drafts/draft-ouldbrahim-vpn-vr-01.txt
or
http://www.ietf.org/internet-drafts/draft-ouldbrahim-bgp-vpn-00.txt=  
 
Javier
 
-----Original Message-----
From: Juan Diego Otero=20 [mailto:diego@estos.upc.es]
Sent: 25 October 2000=20 16:04
To: Sheng, Wenbo
Cc: MPLS = WG
Subject: Re:=20 VPN solution

Hi Wenbo,=20

The method to build VPNs most discussed (and that makes me think =
that=20 is the most popular) in this mailing list is
the BGP/MPLS model = explained=20 in  draft-rosen-rfc2547bis-02.txt=20 . Personally I
think this method has a lot of advantages such as=20 scalability, security, manageability
and use of private = addressing. Some=20 of this advantages (specially scalability) have been  =
discussed in=20 this mailing list.=20

Best Regards,=20

Diego=20

Wenbo Sheng wrote:=20

HI,=20

Assuming my = customer need to=20 create a VPN, I just want to know which solution is better - using = MPLS-VPN=20 or virtual routers? Which solution is/will be more popular in = creating a=20 VPN?=20

Thanks in = advance,=20

W.S.


--
http://www.geocities.com/= diego_otero/=20
 

------_=_NextPart_001_01C03E88.F2ED3480-- From owner-mpls@UU.NET Wed Oct 25 09:42:24 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00335 for ; Wed, 25 Oct 2000 09:42:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmla03982; Wed, 25 Oct 2000 13:41:49 GMT Received: by mail-control.mail.uu.net id QQjmla06410 for mpls-outgoing; Wed, 25 Oct 2000 13:41:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmla06383 for ; Wed, 25 Oct 2000 13:41:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmla02420 for ; Wed, 25 Oct 2000 13:40:24 GMT Received: from snickers.cs.umd.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: snickers.cs.umd.edu [128.8.126.109]) id QQjmla00265 for ; Wed, 25 Oct 2000 13:40:24 GMT Received: from localhost (localhost [127.0.0.1]) by snickers.cs.umd.edu (8.9.3/8.9.1) with ESMTP id JAA04209; Wed, 25 Oct 2000 09:40:13 -0400 (EDT) Date: Wed, 25 Oct 2000 09:40:13 -0400 (EDT) From: Rob Jaeger To: Juan Diego Otero cc: Wenbo Sheng , MPLS WG Subject: Re: VPN solution In-Reply-To: <39F6E846.C369AEA@estos.upc.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Juan/Wenbo, An alternative to draft-rosen-rfc2547bis is l2vpn as described in draft-kompella-mpls-l2vpn-01.txt . One advantage of this method is the separation of administrative responsibilities. In MPLS L2VPNs, the service provider does not participate in the customer's L3 routing. This may provide better stability than L3 VPNs. Rob On Wed, 25 Oct 2000, Juan Diego Otero wrote: > Hi Wenbo, > > The method to build VPNs most discussed (and that makes me think > that is the most popular) in this mailing list is > the BGP/MPLS model explained in draft-rosen-rfc2547bis-02.txt . Personally I > think this method has a lot of advantages such as scalability, security, manageability > and use of private addressing. Some of this advantages (specially scalability) have been > discussed in this mailing list. > > Best Regards, > > Diego > > Wenbo Sheng wrote: > HI, > > Assuming my customer need to create a VPN, I just want to know which solution is better - using > MPLS-VPN or virtual routers? Which solution is/will be more popular in creating a VPN? > > Thanks in advance, > > W.S. > > > -- > http://www.geocities.com/diego_otero/ > > From owner-mpls@UU.NET Wed Oct 25 10:03:50 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07050 for ; Wed, 25 Oct 2000 10:03:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlc02562; Wed, 25 Oct 2000 14:03:04 GMT Received: by mail-control.mail.uu.net id QQjmlc15030 for mpls-outgoing; Wed, 25 Oct 2000 14:02:29 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlc14853 for ; Wed, 25 Oct 2000 14:02:12 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlc18504; Wed, 25 Oct 2000 14:01:49 GMT Received: from mail-green.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQjmlc28553; Wed, 25 Oct 2000 14:01:49 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id DF0DE1E013; Wed, 25 Oct 2000 10:01:44 -0400 (EDT) Received: from pcalchiu (pclopez [135.207.131.94]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id KAA25771; Wed, 25 Oct 2000 10:01:39 -0400 (EDT) Reply-To: From: "Angela Chiu" To: "'Yakov Rekhter'" Cc: , , , , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 10:02:57 -0400 Message-ID: <000601c03e8c$497f7fd0$5e83cf87@attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200010251135.EAA21131@omega.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov, Yes, you are right. Routing the primary and backup paths jointly is always more optimal than fixing the path for primary first then routing the backup accordingly. The same argument can be applied to comparing centralized routing with distributed routing. Even distributed routing is less optimal, it is the trend today. I think the real issue is at what cost the additional optimality is gained, and how much the additional optimality is in a typical network setting. In this case the cost is all the topological information including SRLG information as well as physical impairment constraints in the optical network that routers need to obtain in order to make proper routing decision. I have an idea, this will be a valid master/PhD thesis for some graduate students who would like to work on real world problems. Regards, Angela -----Original Message----- From: ip-optical-admin@lists.bell-labs.com [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Yakov Rekhter Sent: Wednesday, October 25, 2000 7:35 AM To: alchiu@research.att.com Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Angela, > Some followup discussions in line. more in line... > Regards, > Angela > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kireeti > Kompella > Sent: Monday, October 23, 2000 1:58 PM > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > > I don't see why TE and protection require the routers to specify explicit > > routes. > > The routers can simply specify to the optical layer what type of optical > > layer protection > > it requires. > > Suppose router A wants to get to router B, and wants to take two > different ingress and egress points in the optical domain, X->Y > for the primary LSP, and W->Z for the backup. A does not require > optical protection for the X->Y path, nor for the W->Z path. A > *does* require that the X->Y path and the W->Z path do not share > common links. How is this to be done? > > If A did the full path computation, this is simplicity itself. > > [AC] I think you have a good point here. I also heard the same kind if > reasoning (i.e., have a layer-3 like protection switching) for supporting > the peer model. But after discussing with others, it seems that overlay > model should be able to provide the same capability. Not really... for more on this see below... > Normally, the primary > LSP X->Y is set up first, and becomes a forwarding adjacency (FA) according > to your LSP Hierarchy draft. Then the associated information of the FA X->Y > including its exact path and SRLG information should be propagated via IGP > extensions, same as with any other link in the network. Thus if router A > sends a request to OXC W to set up a backup lightpath from W->Z to be > diversely router from the existing FA X->Y, OXC W should already have the > right information to perform proper routing. It is a known fact that for computing disjoint paths the approach you outlined above may result in a situation where no backup path will be found, despite the fact that that it is possible (using some other approach) to find two disjoint paths. > Comparing with the peer model solution where routers need to know all the > SRLG information of the optical domain as well as all relevant physical > impairments in the optical signal in the case of transparent optical > network, it is still not clear to me which one is simpler. > > I think it is very good to have this kind of technical discussion openly on > the list. Hope others can provide more technical and business (after all > carriers need to pay for these features) evidences for the need of each > model. Some other reasoning I heard includes that peer model can improve the > IGP scalability in terms of the number of neighbors a router needs to peer > with. But since large ISPs today seem to cope well with the IGP scalability > today, I don't see why the problem will get significant worst when optical > networks come into play. In the end it is not the discussion on this list, but the competition in the marketplace that will determine the viability of different models. Yakov. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Wed Oct 25 10:05:16 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07464 for ; Wed, 25 Oct 2000 10:05:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlc00756; Wed, 25 Oct 2000 14:03:24 GMT Received: by mail-control.mail.uu.net id QQjmlc17181 for mpls-outgoing; Wed, 25 Oct 2000 14:02:49 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmlc15924 for ; Wed, 25 Oct 2000 14:02:38 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlc27472 for ; Wed, 25 Oct 2000 14:02:13 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmlc29082 for ; Wed, 25 Oct 2000 14:02:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA19510 for mpls@uu.net; Wed, 25 Oct 2000 10:02:12 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlc14705 for ; Wed, 25 Oct 2000 14:01:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlc06517 for ; Wed, 25 Oct 2000 14:01:14 GMT Received: from alpo.casc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpo.casc.com [152.148.10.6]) id QQjmlc29921 for ; Wed, 25 Oct 2000 14:01:13 GMT Received: from lucent.com ([152.148.88.87]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id KAA29554; Wed, 25 Oct 2000 10:00:32 -0400 (EDT) Message-ID: <39F6CC9C.61E489E8@lucent.com> Date: Wed, 25 Oct 2000 08:05:48 -0400 From: Karthik Muthukrishnan Organization: Lucent Technologies: InterNetworking Systems X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Javier Gonzalez CC: Juan Diego Otero , Wenbo Sheng , MPLS WG Subject: Re: VPN solution References: Content-Type: multipart/mixed; boundary="------------7613FE9240E54618A85D2397" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------7613FE9240E54618A85D2397 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit .. add http://www.ietf.org/rfc/rfc2917.txt?number=2917 to the list of other approaches... The fact that the BGP/MPLS model explained in the informational draft described below is the most discussed does not necessarily make it the best possible solution. Can you please provide more insight into the actual scalability, security, manageability and use of private addressing details that you make reference to ? Have you read/implemented: http://www.ietf.cnri.reston.va.us/rfc/rfc2764.txt?number=2764 or http://www.ietf.org/internet-drafts/draft-ouldbrahim-vpn-vr-01.txt or http://www.ietf.org/internet-drafts/draft-ouldbrahim-bgp-vpn-00.txt Javier -----Original Message----- From: Juan Diego Otero [mailto:diego@estos.upc.es] Sent: 25 October 2000 16:04 To: Sheng, Wenbo Cc: MPLS WG Subject: Re: VPN solution Hi Wenbo, The method to build VPNs most discussed (and that makes me think that is the most popular) in this mailing list is the BGP/MPLS model explained in draft-rosen-rfc2547bis-02.txt . Personally I think this method has a lot of advantages such as scalability, security, manageability and use of private addressing. Some of this advantages (specially scalability) have been discussed in this mailing list. Best Regards, Diego Wenbo Sheng wrote: HI, Assuming my customer need to create a VPN, I just want to know which solution is better - using MPLS-VPN or virtual routers? Which solution is/will be more popular in creating a VPN? Thanks in advance, W.S. -- http://www.geocities.com/diego_otero/ --------------7613FE9240E54618A85D2397 Content-Type: text/x-vcard; charset=us-ascii; name="mkarthik.vcf" Content-Description: Card for Karthik Muthukrishnan Content-Disposition: attachment; filename="mkarthik.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Muthukrishnan;Karthik tel;pager:1587321@skytel.com tel;fax:(978)-692-1509 tel;work:(978)-952-1368 x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:mkarthik@lucent.com end:vcard --------------7613FE9240E54618A85D2397-- From owner-mpls@UU.NET Wed Oct 25 10:12:43 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09121 for ; Wed, 25 Oct 2000 10:12:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlc12554; Wed, 25 Oct 2000 14:12:14 GMT Received: by mail-control.mail.uu.net id QQjmlc20655 for mpls-outgoing; Wed, 25 Oct 2000 14:11:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlc20463 for ; Wed, 25 Oct 2000 14:11:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlc07205 for ; Wed, 25 Oct 2000 14:11:10 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmlc13479 for ; Wed, 25 Oct 2000 14:11:10 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA04185 for ; Wed, 25 Oct 2000 07:11:10 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA20870 for mpls@uu.net; Wed, 25 Oct 2000 10:11:08 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmkv19493 for ; Wed, 25 Oct 2000 12:17:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmkv12264 for ; Wed, 25 Oct 2000 12:15:12 GMT Received: from mail.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.movaz.com [64.47.156.131]) id QQjmkv10168 for ; Wed, 25 Oct 2000 12:15:12 GMT Received: from toy.movaz.com (griffin.host4u.net [209.150.128.163]) by mail.movaz.com (8.9.3/8.8.7) with ESMTP id IAA22997; Wed, 25 Oct 2000 08:16:20 -0400 Message-Id: <4.3.2.7.2.20001025074636.00c55ef0@mo-mail> X-Sender: lou@mo-mail X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Oct 2000 08:15:27 -0400 To: Adrian Farrel From: Lou Berger Subject: RE: draft-ietf-mpls-generalized-signaling-00.txt Cc: Lou Berger , mpls@UU.NET, petera@nortelnetworks.com In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2CA59A@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Adrian, See below. At 04:43 PM 10/24/00, Adrian Farrel wrote: >[...] > > > >This is *really* stylistic, do you really care? > >I don't care, but the (new) values are going to have to be >defined somewhere. Perhaps we push this out to the >protocol-specific docs that will be written later? Done. > >>4.2 Bidirectional LSP Procedures > >>The choice you have made is consistent (that you may not > >>propagate a Path containing Upstream_Label until the local > >>switch has been programmed, so that the terminator may start > >>sending data as soon as it has processed the Path) but may > >>unnecessarily increase the latency of LSP set up (compare > >>with the arguments for Suggested_Label). > >>If ResvConf were to be requested and used, the individual > >>switch programming tasks could be processed in parallel with > >>the propagation of the Path message. The terminator is not > >>allowed to start sending data until it receives the ResvConf. > >>This is a direct trade-off, but could quite easily reduce > >>setup time for individual LSPs. > > > >This is a reasonable representation of the choice that was made. > >No chance of re-opening this debate? I actually don't think there's much to debate here. Here's my view: Your suggested approach would require the use of ResvConf. There are a some issues with this. (1) ResvConf is currently optional, and (2) more importantly ResvConf is not refreshed. The latter means that the reliable message delivery of refresh-reduct is also required to support bidirectional LSPs, such support isn't currently required. (BTW I may be mistaken, but I don't think there's a ResvConf equivalent in CR-LDP, so it too would need to be defined.) If all of this isn't enough, the other factor to consider is that LSP setup would require three passes of control messages versus the two passes currently supported by both signaling protocols. Given all of this, I think it's clear that use of /reliance on ResvConf isn't the way to go. > >>4.3 Bidirectional LSP Contention Resolution > >>The suggested behavior for reducing contention depends on > >>adjacent LSRs knowing each other's node IDs. Does this > >>rely on Hello messages, carnal knowledge or what? > > > >from the draft: > > For the purposes of RSVP contention > > resolution, the node ID is the IP address used in the RSVP_HOP > > object. > >Agreed. >However, the draft also says... > > To reduce the probability of contention, one may impose a > policy that the node with the lower ID never suggests a > label in the downstream direction and always accepts a > Suggested Label from an upstream node with a higher ID. > >To know whether to suggest a label, you need to know whether >you have the higher or lower ID. To find that out, you >have to receive a Path message containing RSVP_HOP from the >other node. > >Hence my question. If I understand you correctly, you're point is that the neighbor address might not be known when sending the 1st path messages and if both sides send initial path messages at approximately the same time, they might not know the neighbor's address. Did I get it right? If so, there are lots of other places in the system where such information should be available. Assuming it's not, both nodes suggesting a random label when the neighbor's address should be good enough for this initial condition. I'll add a comment in the draft to that effect. > >>5.1.2 Notify Request Procedures > >>We should add a statement about multiple instances of this object. > >>The current discussion allows just a single instance. > > > >This is by design. Others have made the same point, but it > >wasn't clear that this functionality is really required. > >Why do you believe this is needed? > >I'm aproaching from the other end. >I'd like an explicit statement limiting us to one instance (more >explicit than the BNF) precisely because of the discussions about >multiple targets. Okay I think the BNF is explicit but I've added the following text anyway: If a message contains multiple NOTIFY_REQUEST objects, only the first object is meaningful. Subsequent NOTIFY_REQUEST objects MAY be ignored and SHOULD NOT be propagated. > >>5.2.2 Notify Procedures > >>This version of the text does not prohibit the Notify Node from > >>being other than the requester (i.e. initiator or terminator). > > > >Again, this is by design. > >Do I take it, then, that we're also leaving it open for nodes >to change the value of the Notify Address as the Path/Resv >is propagated? yes. >This would be good, but it might be helpful to describe the >process. (Text available on demand :-) The text says: The outgoing Notify Node Address MAY be updated based on local policy. I think this is enough since this is a local implementation issue. Thanks again for the comments, Lou From owner-mpls@UU.NET Wed Oct 25 10:14:57 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09592 for ; Wed, 25 Oct 2000 10:14:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlc12744; Wed, 25 Oct 2000 14:14:15 GMT Received: by mail-control.mail.uu.net id QQjmlc20729 for mpls-outgoing; Wed, 25 Oct 2000 14:13:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmlc20720 for ; Wed, 25 Oct 2000 14:13:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlc26939 for ; Wed, 25 Oct 2000 14:11:40 GMT Received: from hoemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQjmlc14157 for ; Wed, 25 Oct 2000 14:11:40 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA07454 for ; Wed, 25 Oct 2000 10:11:39 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id KAA07450; Wed, 25 Oct 2000 10:11:39 -0400 (EDT) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA22019; Wed, 25 Oct 2000 10:11:39 -0400 Message-ID: <39F6EA1B.C82B38C3@hotair.hobl.lucent.com> Date: Wed, 25 Oct 2000 10:11:39 -0400 From: "S.Sankaranarayanan" Reply-To: ssnarayanan@lucent.com Organization: JJ0C21010 X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Manfredi, Albert E" CC: "'Lazer, Monica A, NNAD'" , ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <4102273CEB77D211869200805FE6F593018C5AF7@xch-phl-01.he.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Albert, "Manfredi, Albert E" wrote: > > I guess I'm missing this speed argument that's been made twice today. Why > would one expect that optics by itself can change the speed with which > bandwidth is provisioned? > > Surely if tools can be deployed to rapidly provision bandwidth using lambda > as the knob, similar tools can provision bandwidth about as quickly using > other knobs? Like ATM PVCs, SONET pipes, LSPs? The speed argument is with respect to the use of an automated control plane to set up switched circuits, not with respect to which transport technology we choose to use. As a matter of fact, one of the things that has emerged in various standards organizations working on automatically switched optical networks is that the control plane by itself should be "layer agnostic", i.e., the same control plane should be capable of handling switched services irrespective of what the underlying transport is. > > Bert > albert.e.manfredi@boeing.com > > > -----Original Message----- > > From: Lazer, Monica A, NNAD [mailto:mlazer@att.com] > > > > David, > > From our perspective, having the tools to support sub-minute automated > > provisioning of circuits is one of the main drivers of this > > work. This is > > one of the reasons that drives us to push for support of > > multiple clients by > > the control plane optical network. > > > > Monica A. Lazer > > Advanced Transport Technology and Architecture Planning > > > > 908 234 8462 > > mlazer@att.com -- Regards, Shiva ------------------ Sivakumar Sankaranarayanan Member of Technical Staff HO 3C-508A Lucent Technologies, 101 Crawfords Corner Road, Holmdel, NJ 07733. Phone: +1 732 949 5762 Fax: +1 732 949 3210 (Attn: S. Sankaranarayanan) Email: ssnarayanan@lucent.com From owner-mpls@UU.NET Wed Oct 25 10:20:26 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10765 for ; Wed, 25 Oct 2000 10:20:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmld22650; Wed, 25 Oct 2000 14:19:31 GMT Received: by mail-control.mail.uu.net id QQjmld21304 for mpls-outgoing; Wed, 25 Oct 2000 14:19:03 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmld21295 for ; Wed, 25 Oct 2000 14:18:58 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmld24351 for ; Wed, 25 Oct 2000 14:17:44 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmld17776 for ; Wed, 25 Oct 2000 14:17:43 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA25851 for ; Wed, 25 Oct 2000 07:17:42 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA20908 for mpls@uu.net; Wed, 25 Oct 2000 10:17:42 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmkz05104 for ; Wed, 25 Oct 2000 13:19:43 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmkz07629 for ; Wed, 25 Oct 2000 13:16:24 GMT Received: from exchenc1.ennovatenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.66]) id QQjmkz28675 for ; Wed, 25 Oct 2000 13:16:24 GMT Received: by exchenc1.ennovatenetworks.com with Internet Mail Service (5.5.2448.0) id ; Wed, 25 Oct 2000 09:18:12 -0400 Message-ID: From: "Newcomb, Robert" To: "'Juan Diego Otero'" Cc: "'mpls@uu.net'" Subject: RE: VPN solution Date: Wed, 25 Oct 2000 09:18:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03E86.0650E300" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03E86.0650E300 Content-Type: text/plain; charset="iso-8859-1" Hello Diego, I am not sure what you have been reading and who you have been talking to, but one of the biggest challenges encountered in deploying RFC 2547 VPNs is scalability and manageability. These have been discussed throughout and I believe that there is a general consensus in the market that it is difficult to do both with this Informational Draft approach. With that said, it is also the one MPLS VPN solution in deployment today. There are also a number of deployments using the Virtual Router VPN approach and it has its advantages as well. Robert -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juan Diego Otero Sent: Wednesday, October 25, 2000 10:04 AM To: Wenbo Sheng Cc: MPLS WG Subject: Re: VPN solution Hi Wenbo, The method to build VPNs most discussed (and that makes me think that is the most popular) in this mailing list is the BGP/MPLS model explained in draft-rosen-rfc2547bis-02.txt . Personally I think this method has a lot of advantages such as scalability, security, manageability and use of private addressing. Some of this advantages (specially scalability) have been discussed in this mailing list. Best Regards, Diego Wenbo Sheng wrote: HI, Assuming my customer need to create a VPN, I just want to know which solution is better - using MPLS-VPN or virtual routers? Which solution is/will be more popular in creating a VPN? Thanks in advance, W.S. -- http://www.geocities.com/diego_otero/ ------_=_NextPart_001_01C03E86.0650E300 Content-Type: text/html; charset="iso-8859-1"
Hello Diego,
 
I am not sure what you have been reading and who you have been talking to, but one of the biggest challenges encountered in deploying RFC 2547 VPNs is scalability and manageability.  These have been discussed throughout and I believe that there is a general consensus in the market that it is difficult to do both with this Informational Draft approach.  With that said, it is also the one MPLS VPN solution in deployment today.  There are also a number of deployments using the Virtual Router VPN approach and it has its advantages as well. 
 
Robert
 
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juan Diego Otero
Sent: Wednesday, October 25, 2000 10:04 AM
To: Wenbo Sheng
Cc: MPLS WG
Subject: Re: VPN solution

Hi Wenbo,

The method to build VPNs most discussed (and that makes me think
that is the most popular) in this mailing list is
the BGP/MPLS model explained in  draft-rosen-rfc2547bis-02.txt . Personally I
think this method has a lot of advantages such as scalability, security, manageability
and use of private addressing. Some of this advantages (specially scalability) have been 
discussed in this mailing list.

Best Regards,

Diego

Wenbo Sheng wrote:

HI,

Assuming my customer need to create a VPN, I just want to know which solution is better - using MPLS-VPN or virtual routers? Which solution is/will be more popular in creating a VPN?

Thanks in advance,

W.S.


--
http://www.geocities.com/diego_otero/
 

------_=_NextPart_001_01C03E86.0650E300-- From owner-mpls@UU.NET Wed Oct 25 10:30:12 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13026 for ; Wed, 25 Oct 2000 10:30:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmld07032; Wed, 25 Oct 2000 14:29:23 GMT Received: by mail-control.mail.uu.net id QQjmld21908 for mpls-outgoing; Wed, 25 Oct 2000 14:28:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmld21903 for ; Wed, 25 Oct 2000 14:28:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmld09358 for ; Wed, 25 Oct 2000 14:26:00 GMT Received: from old-callisto.ftel.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: big-relay-1.ftel.co.uk [192.65.220.123]) id QQjmld03440 for ; Wed, 25 Oct 2000 14:25:59 GMT Received: (from root@localhost) by old-callisto.ftel.co.uk (8.11.1/8.11.1/Revision:1.55/cyrus/yp) id e9PEPwV04698; Wed, 25 Oct 2000 15:25:58 +0100 (BST) Received: from ftel.co.uk (kiwi.ftel.co.uk [172.16.13.170]) by old-callisto.ftel.co.uk (8.11.1/8.11.1/Revision:1.55/scanin/yp) with ESMTP id e9PEPvD04690; Wed, 25 Oct 2000 15:25:57 +0100 (BST) Message-ID: <39F6ED7F.7A094A36@ftel.co.uk> Date: Wed, 25 Oct 2000 15:26:07 +0100 From: Robert M Matheson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Newcomb, Robert" CC: "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Robert, What exactly is/are the scalability issue/s with RFC 2547 VPNs? Robert "Newcomb, Robert" wrote: > Hello Diego,I am not sure what you have been reading and who you have > been talking to, but one of the biggest challenges encountered in > deploying RFC 2547 VPNs is scalability and manageability. These have > been discussed throughout and I believe that there is a general > consensus in the market that it is difficult to do both with this > Informational Draft approach. With that said, it is also the one MPLS > VPN solution in deployment today. There are also a number of > deployments using the Virtual Router VPN approach and it has its > advantages as well. Robert > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juan > Diego Otero > Sent: Wednesday, October 25, 2000 10:04 AM > To: Wenbo Sheng > Cc: MPLS WG > Subject: Re: VPN solution > > Hi Wenbo, > > The method to build VPNs most discussed (and that makes me think > that is the most popular) in this mailing list is > the BGP/MPLS model explained in draft-rosen-rfc2547bis-02.txt > Personally I > think this method has a lot of advantages such as scalability, > security, manageability > and use of private addressing. Some of this advantages (specially > scalability) have been > discussed in this mailing list. > > Best Regards, > > Diego > > Wenbo Sheng wrote: > >> HI, >> >> Assuming my customer need to create a VPN, I just want to know which >> solution is better - using MPLS-VPN or virtual routers? Which >> solution is/will be more popular in creating a VPN? >> >> Thanks in advance, >> >> W.S. > > > -- > http://www.geocities.com/diego_otero/ > From owner-mpls@UU.NET Wed Oct 25 10:36:28 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14465 for ; Wed, 25 Oct 2000 10:36:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmle17960; Wed, 25 Oct 2000 14:35:42 GMT Received: by mail-control.mail.uu.net id QQjmle22375 for mpls-outgoing; Wed, 25 Oct 2000 14:35:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmle22369 for ; Wed, 25 Oct 2000 14:35:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmle19244 for ; Wed, 25 Oct 2000 14:34:27 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjmle16519 for ; Wed, 25 Oct 2000 14:34:26 GMT Received: from tellium.com ([192.168.24.115]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9PEQlg28739; Wed, 25 Oct 2000 10:26:47 -0400 (EDT) Message-ID: <39F6EF33.C3388FA9@tellium.com> Date: Wed, 25 Oct 2000 10:33:23 -0400 From: Dimitrios Pendarakis X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ping Pan CC: mpls@UU.NET Subject: Re: COPS doubt References: <39F61B32.D773BB99@tellium.com> <39F63428.8E40894E@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ping, I wasn't referring to policy enforcement on individual packets; that you have to do on the LSR anyway. But some of the policies that have been suggested in the context of RSVP, like checking customer databases, credit cards, verifying digital certificates, may require a lot of processing. I have to admit though that I don't know if and how soon these will become a reality, and I agree that for MPLS traffic engineering purposes LSR's should have the appropriate processing power. The remaining issue is where does the information needed to make a decision reside ... Take care, Dimitris Ping Pan wrote: > Dimitrios Pendarakis wrote: > > > > You could apply the reverse argument as well: if the LSR can maintain a policy > > database, why can't it make policy decisions locally and avoid the need for COPS? > > It's all a matter of relative complexity... > > > > That's true. You're right. > > > However, people have talked about policies that one would expect several > > LSRs to have difficulty processing locally, especially if the policy decisions have to be > > made very frequently. RFC 2753 discusses some examples. > > > > Processing packets base on policy (aka, enforcing policy) can consume a > lot of CPU cycles. But this is somewhat different from processing policy > decisions. Actually, I cannot imagine that there will be very frequent > policy exchanges on purpose that can swamp LSR's, otherwise, we should > call it man-made policy flopping and need to write a new draft on policy > dampening. ;-) > > > And LSR's which have to do more work on the data plane might be more > > pressed to conserve cycles by outsourcing policy decisions :-) > > > > Take care, man. Just busting your chops. ;-) > > - Ping From owner-mpls@UU.NET Wed Oct 25 10:43:17 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16032 for ; Wed, 25 Oct 2000 10:43:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmle00215; Wed, 25 Oct 2000 14:42:21 GMT Received: by mail-control.mail.uu.net id QQjmle22788 for mpls-outgoing; Wed, 25 Oct 2000 14:41:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmle22781 for ; Wed, 25 Oct 2000 14:41:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmle11484 for ; Wed, 25 Oct 2000 14:41:22 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmle00864 for ; Wed, 25 Oct 2000 14:41:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA27460 for mpls@uu.net; Wed, 25 Oct 2000 10:41:21 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmle22650 for ; Wed, 25 Oct 2000 14:40:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmle06907 for ; Wed, 25 Oct 2000 14:39:52 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmle28564 for ; Wed, 25 Oct 2000 14:39:52 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA29438; Wed, 25 Oct 2000 07:38:22 -0700 (PDT) Message-Id: <200010251438.HAA29438@omega.cisco.com> To: "Newcomb, Robert" cc: "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution In-reply-to: Your message of "Wed, 25 Oct 2000 09:18:11 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29436.972484701.1@cisco.com> Date: Wed, 25 Oct 2000 07:38:22 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Robert, > Hello Diego, > > I am not sure what you have been reading and who you have been talking to, > but one of the biggest challenges encountered in deploying RFC 2547 VPNs is > scalability and manageability. Do you have any *facts* to support the above statement ? Or is it just rumors ? > These have been discussed throughout and I > believe that there is a general consensus in the market that it is difficult > to do both with this Informational Draft approach. While you certainly entitled to express *your* belief in what general consensus is, all I'd like to say that there is no general consensus that your belief (even remotely) reflects reality. > With that said, it is > also the one MPLS VPN solution in deployment today. There are also a number > of deployments using the Virtual Router VPN approach and it has its > advantages as well. As well as its drawbacks... Yakov. P.S. While some folks like to complain about scalability and problems with BGP (and therefore with BGP/MPLS VPN), please note that without working BGP, it would be highly unlikely that you'll be able to receive this e-mail. From owner-mpls@UU.NET Wed Oct 25 10:47:45 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17043 for ; Wed, 25 Oct 2000 10:47:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlf06429; Wed, 25 Oct 2000 14:46:55 GMT Received: by mail-control.mail.uu.net id QQjmlf23234 for mpls-outgoing; Wed, 25 Oct 2000 14:46:30 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmlf23185 for ; Wed, 25 Oct 2000 14:46:22 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlf10442 for ; Wed, 25 Oct 2000 14:45:42 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmlf06816 for ; Wed, 25 Oct 2000 14:45:41 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA00501; Wed, 25 Oct 2000 07:45:37 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA20980; Wed, 25 Oct 2000 10:45:35 -0400 (EDT) Message-Id: <200010251445.KAA20980@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Robert M Matheson cc: "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution In-reply-to: Your message of Wed, 25 Oct 2000 15:26:07 +0100. <39F6ED7F.7A094A36@ftel.co.uk> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 25 Oct 2000 10:45:35 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk When someone asks a question which is of the form "which vendor has the best product offering for some particular purpose", you can't really expect a technical discussion to follow, but you can expect a lot of FUD. This thread is of that sort. All you can learn from it is that everyone has their own favorite scheme, and you can pretty much guess which scheme someone will like by noting which company he works for. You know the thread has reached the point of absurdity when people refer to a scheme which has been widely adopted and assert that there is a "market consensus" against it. From owner-mpls@UU.NET Wed Oct 25 11:06:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21119 for ; Wed, 25 Oct 2000 11:06:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlg04296; Wed, 25 Oct 2000 15:05:24 GMT Received: by mail-control.mail.uu.net id QQjmlg05682 for mpls-outgoing; Wed, 25 Oct 2000 15:04:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlg05674 for ; Wed, 25 Oct 2000 15:04:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlg20728; Wed, 25 Oct 2000 15:03:55 GMT Received: from mail-green.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQjmlg29960; Wed, 25 Oct 2000 15:03:55 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id A82FD1E05E; Wed, 25 Oct 2000 11:03:54 -0400 (EDT) Received: from pcalchiu (pclopez [135.207.131.94]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id LAA28017; Wed, 25 Oct 2000 11:03:49 -0400 (EDT) Reply-To: From: "Angela Chiu" To: "'Yakov Rekhter'" Cc: , , , , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 11:05:09 -0400 Message-ID: <000d01c03e94$f9375990$5e83cf87@attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <000601c03e8c$497f7fd0$5e83cf87@attnjs.research.att.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I meant "thesis topic" in my last email. Yakov, I agree with your other point that the market will eventually determine the viability of the two or more models. From a carrier's point of view, since the overlay model is most likely the one to be used first, we want to make sure that key capabilities are supported by the overlay model. In particular, routing a new lightpath that is diverse from one or more existing lightpaths is not only needed by the capability that Kireeti described earlier, i.e., layer-3 like protection switching, but also needed in cases where an upper layer network wants to have its own survivability. For example, an IP network wants to have IP layer only restoration (e.g., if link C-D needs to support additional traffic when link A-B fails, they need to be diversely routed), or a private line network needs to have diversity among a set of links as John pointed our earlier (for more details on diverse routing, see the draft we presented in last IETF, http://search.ietf.org/internet-drafts/draft-chiu-strand-unique-olcp-00.txt, a new version will be issued in a few weeks). As Kireeti pointed out before, certain extensions to the existing GMPLS protocols needed to provide this type of diversity capability is currently not defined yet, i.e., messages that a client uses to request a new lightpath that is diverse from one or more existing lightpaths. Since this requirement has been defined in OIF carriers' requirement document as well as our draft, I think we can all work together to make it happen. Regards, Angela -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Angela Chiu Sent: Wednesday, October 25, 2000 10:03 AM To: 'Yakov Rekhter' Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Yakov, Yes, you are right. Routing the primary and backup paths jointly is always more optimal than fixing the path for primary first then routing the backup accordingly. The same argument can be applied to comparing centralized routing with distributed routing. Even distributed routing is less optimal, it is the trend today. I think the real issue is at what cost the additional optimality is gained, and how much the additional optimality is in a typical network setting. In this case the cost is all the topological information including SRLG information as well as physical impairment constraints in the optical network that routers need to obtain in order to make proper routing decision. I have an idea, this will be a valid master/PhD thesis for some graduate students who would like to work on real world problems. Regards, Angela -----Original Message----- From: ip-optical-admin@lists.bell-labs.com [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Yakov Rekhter Sent: Wednesday, October 25, 2000 7:35 AM To: alchiu@research.att.com Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Angela, > Some followup discussions in line. more in line... > Regards, > Angela > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kireeti > Kompella > Sent: Monday, October 23, 2000 1:58 PM > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > > I don't see why TE and protection require the routers to specify explicit > > routes. > > The routers can simply specify to the optical layer what type of optical > > layer protection > > it requires. > > Suppose router A wants to get to router B, and wants to take two > different ingress and egress points in the optical domain, X->Y > for the primary LSP, and W->Z for the backup. A does not require > optical protection for the X->Y path, nor for the W->Z path. A > *does* require that the X->Y path and the W->Z path do not share > common links. How is this to be done? > > If A did the full path computation, this is simplicity itself. > > [AC] I think you have a good point here. I also heard the same kind if > reasoning (i.e., have a layer-3 like protection switching) for supporting > the peer model. But after discussing with others, it seems that overlay > model should be able to provide the same capability. Not really... for more on this see below... > Normally, the primary > LSP X->Y is set up first, and becomes a forwarding adjacency (FA) according > to your LSP Hierarchy draft. Then the associated information of the FA X->Y > including its exact path and SRLG information should be propagated via IGP > extensions, same as with any other link in the network. Thus if router A > sends a request to OXC W to set up a backup lightpath from W->Z to be > diversely router from the existing FA X->Y, OXC W should already have the > right information to perform proper routing. It is a known fact that for computing disjoint paths the approach you outlined above may result in a situation where no backup path will be found, despite the fact that that it is possible (using some other approach) to find two disjoint paths. > Comparing with the peer model solution where routers need to know all the > SRLG information of the optical domain as well as all relevant physical > impairments in the optical signal in the case of transparent optical > network, it is still not clear to me which one is simpler. > > I think it is very good to have this kind of technical discussion openly on > the list. Hope others can provide more technical and business (after all > carriers need to pay for these features) evidences for the need of each > model. Some other reasoning I heard includes that peer model can improve the > IGP scalability in terms of the number of neighbors a router needs to peer > with. But since large ISPs today seem to cope well with the IGP scalability > today, I don't see why the problem will get significant worst when optical > networks come into play. In the end it is not the discussion on this list, but the competition in the marketplace that will determine the viability of different models. Yakov. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Wed Oct 25 11:11:03 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22093 for ; Wed, 25 Oct 2000 11:11:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlg11583; Wed, 25 Oct 2000 15:10:26 GMT Received: by mail-control.mail.uu.net id QQjmlg06195 for mpls-outgoing; Wed, 25 Oct 2000 15:09:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlg06182 for ; Wed, 25 Oct 2000 15:09:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlg05389 for ; Wed, 25 Oct 2000 15:08:42 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmlg06711 for ; Wed, 25 Oct 2000 15:08:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA02106 for mpls@uu.net; Wed, 25 Oct 2000 11:08:41 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlg06002 for ; Wed, 25 Oct 2000 15:07:52 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlg21539 for ; Wed, 25 Oct 2000 15:07:42 GMT Received: from stl-smtpout-01.boeing.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: stl-smtpout-01.boeing.com [12.13.247.21]) id QQjmlg06725 for ; Wed, 25 Oct 2000 15:07:02 GMT Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA12331 for ; Wed, 25 Oct 2000 10:07:01 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id KAA03968 for ; Wed, 25 Oct 2000 10:07:00 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Wed, 25 Oct 2000 10:06:47 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 11:06:46 -0400 Message-Id: <4102273CEB77D211869200805FE6F593018C5AFD@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'ssnarayanan@lucent.com'" Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling Date: Wed, 25 Oct 2000 11:06:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk S.Sankaranarayanan wrote: > The speed argument is with respect to the use of an automated control > plane to set up switched circuits, not with respect to which transport > technology we choose to use. As a matter of fact, one of the things > that has emerged in various standards organizations working on > automatically switched optical networks is that the control plane by > itself should be "layer agnostic", i.e., the same control > plane should > be capable of handling switched services irrespective of what the > underlying transport is. Indeed, Shiva, that was my point. The solutions used elsewhere (SONET, ATM, MPLS) can apply here, and any better solution found here can be applied elsewhere. No need to mix up the issues. I originally wondered why the ION WG charter had not been exanded to address this topic. Bert albert.e.manfredi@boeing.com From owner-mpls@UU.NET Wed Oct 25 11:11:15 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22152 for ; Wed, 25 Oct 2000 11:11:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlg09244; Wed, 25 Oct 2000 15:10:25 GMT Received: by mail-control.mail.uu.net id QQjmlg06190 for mpls-outgoing; Wed, 25 Oct 2000 15:09:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlg06180 for ; Wed, 25 Oct 2000 15:09:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlg05941 for ; Wed, 25 Oct 2000 15:08:52 GMT Received: from ns1.arch.bellsouth.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.arch.bellsouth.net [205.152.173.2]) id QQjmlg09257 for ; Wed, 25 Oct 2000 15:08:52 GMT Received: (from ck@localhost) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) id LAA02732; Wed, 25 Oct 2000 11:08:51 -0400 (EDT) Date: Wed, 25 Oct 2000 11:08:51 -0400 From: Christian Kuhtz To: "Newcomb, Robert" Cc: mpls@UU.NET Subject: Re: VPN solution Message-ID: <20001025110851.D2109@ns1.arch.bellsouth.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Newcomb, Robert on Wed, Oct 25, 2000 at 09:18:11AM -0400 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, Oct 25, 2000 at 09:18:11AM -0400, Newcomb, Robert wrote: > I am not sure what you have been reading and who you have been talking to, > but one of the biggest challenges encountered in deploying RFC 2547 VPNs is > scalability and manageability. These have been discussed throughout and I > believe that there is a general consensus in the market that it is difficult > to do both with this Informational Draft approach. With that said, it is > also the one MPLS VPN solution in deployment today. There are also a number > of deployments using the Virtual Router VPN approach and it has its > advantages as well. Aside from misrepresentation, what do you have to contribute to this conversation? -- Christian Kuhtz Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." From owner-mpls@UU.NET Wed Oct 25 11:15:03 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23005 for ; Wed, 25 Oct 2000 11:15:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlg13084; Wed, 25 Oct 2000 15:13:32 GMT Received: by mail-control.mail.uu.net id QQjmlg06596 for mpls-outgoing; Wed, 25 Oct 2000 15:12:58 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmlg06550 for ; Wed, 25 Oct 2000 15:12:45 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlg11016 for ; Wed, 25 Oct 2000 15:12:00 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmlg11749 for ; Wed, 25 Oct 2000 15:11:59 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA06653; Wed, 25 Oct 2000 08:11:57 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA21044; Wed, 25 Oct 2000 11:11:57 -0400 (EDT) Message-Id: <200010251511.LAA21044@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Yakov Rekhter cc: "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution In-reply-to: Your message of Wed, 25 Oct 2000 07:38:22 -0700. <200010251438.HAA29438@omega.cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 25 Oct 2000 11:11:57 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Yakov> P.S. While some folks like to complain about scalability and Yakov> problems with BGP ***SARCASM ALERT*** Well, if BGP were really scalable, then the Internet would no longer be just a small scale academic and government toy; it would have world-wide scope and be heavily used by commerce and industry. I always find it interesting that people will say that the network layer mechanisms which hold the Internet together are unscalable, and then will advocate the use of data link layer mechanisms instead. I guess that once we have the scalable and easy to manage "world wide lan", or the scalable and easy to manage "word wide mesh of point-to-point links", we won't need stuff like BGP any more. ***END OF SARCASM ALERT*** (and sorry for wasting everyone's time) From owner-mpls@UU.NET Wed Oct 25 11:19:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23880 for ; Wed, 25 Oct 2000 11:19:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlh21962; Wed, 25 Oct 2000 15:17:55 GMT Received: by mail-control.mail.uu.net id QQjmlh07131 for mpls-outgoing; Wed, 25 Oct 2000 15:17:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlh07094 for ; Wed, 25 Oct 2000 15:17:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlh27131 for ; Wed, 25 Oct 2000 15:15:47 GMT Received: from ns1.arch.bellsouth.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.arch.bellsouth.net [205.152.173.2]) id QQjmlh16179 for ; Wed, 25 Oct 2000 15:15:46 GMT Received: (from ck@localhost) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) id LAA02840; Wed, 25 Oct 2000 11:15:44 -0400 (EDT) Date: Wed, 25 Oct 2000 11:15:44 -0400 From: Christian Kuhtz To: Rob Jaeger Cc: MPLS WG Subject: Re: VPN solution Message-ID: <20001025111543.E2109@ns1.arch.bellsouth.net> References: <39F6E846.C369AEA@estos.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Rob Jaeger on Wed, Oct 25, 2000 at 09:40:13AM -0400 Sender: owner-mpls@UU.NET Precedence: bulk On Wed, Oct 25, 2000 at 09:40:13AM -0400, Rob Jaeger wrote: > An alternative to draft-rosen-rfc2547bis is l2vpn as described in > draft-kompella-mpls-l2vpn-01.txt . One advantage of this method is the > separation of administrative responsibilities. I think you can argue that last point with great ease either way to say the least. YMMV. > In MPLS L2VPNs, the > service provider does not participate in the customer's L3 routing. This > may provide better stability than L3 VPNs. Based on what? Why is interaction with the SP equalled with instability? Care to explain? Several of the L2 VPN vendors use what essentially amounts to OSPF or some other kind of *IGP* underneath. And, of course, that part never does have any problems or faces any challenges. -- Christian Kuhtz Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." From owner-mpls@UU.NET Wed Oct 25 11:25:07 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25455 for ; Wed, 25 Oct 2000 11:25:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlh27662; Wed, 25 Oct 2000 15:23:38 GMT Received: by mail-control.mail.uu.net id QQjmlh07559 for mpls-outgoing; Wed, 25 Oct 2000 15:23:05 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmlh07551 for ; Wed, 25 Oct 2000 15:22:59 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlh05913 for ; Wed, 25 Oct 2000 15:22:52 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmlh26517 for ; Wed, 25 Oct 2000 15:22:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA05425 for mpls@uu.net; Wed, 25 Oct 2000 11:22:51 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmlh07488 for ; Wed, 25 Oct 2000 15:22:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlh24805 for ; Wed, 25 Oct 2000 15:21:22 GMT Received: from stl-smtpout-01.boeing.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: stl-smtpout-01.boeing.com [12.13.247.21]) id QQjmlh23839 for ; Wed, 25 Oct 2000 15:21:21 GMT Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA18689 for ; Wed, 25 Oct 2000 10:21:21 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id KAA14364 for ; Wed, 25 Oct 2000 10:21:20 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Wed, 25 Oct 2000 10:21:07 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 11:21:07 -0400 Message-Id: <4102273CEB77D211869200805FE6F593018C5AFE@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'alchiu@research.att.com'" Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 11:20:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Angela Chiu wrote: > In > particular, routing a new lightpath that is diverse from one or more > existing lightpaths is not only needed by the capability that Kireeti > described earlier, i.e., layer-3 like protection switching, > but also needed > in cases where an upper layer network wants to have its own > survivability. > For example, an IP network wants to have IP layer only > restoration (e.g., if > link C-D needs to support additional traffic when link A-B > fails, they need > to be diversely routed), or a private line network needs to > have diversity > among a set of links as John pointed our earlier (for more details on > diverse routing, see the draft we presented in last IETF, > http://search.ietf.org/internet-drafts/draft-chiu-strand-uniqu > e-olcp-00.txt, > a new version will be issued in a few weeks). Can't the existing IP options fields be used to achieve this at Layer 3? If light paths are merely links between routers, can't you achieve path diversity this way, if you want to do this at the Network Layer? Bert albert.e.manfredi@boeing.com From owner-mpls@UU.NET Wed Oct 25 11:36:44 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27103 for ; Wed, 25 Oct 2000 11:36:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmli13423; Wed, 25 Oct 2000 15:34:57 GMT Received: by mail-control.mail.uu.net id QQjmli08380 for mpls-outgoing; Wed, 25 Oct 2000 15:34:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmli08375 for ; Wed, 25 Oct 2000 15:34:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmli19606 for ; Wed, 25 Oct 2000 15:33:02 GMT Received: from mail-green.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQjmli09941 for ; Wed, 25 Oct 2000 15:33:02 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id E9A9E1E013; Wed, 25 Oct 2000 11:33:01 -0400 (EDT) Received: from pcalchiu (pclopez [135.207.131.94]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id LAA28964; Wed, 25 Oct 2000 11:32:56 -0400 (EDT) Reply-To: From: "Angela Chiu" To: "'Manfredi, Albert E'" Cc: , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 11:34:17 -0400 Message-ID: <000e01c03e99$0ac5fdc0$5e83cf87@attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <4102273CEB77D211869200805FE6F593018C5AFE@xch-phl-01.he.boeing.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bert, Two disjoint links in IP layer may not be diversely routed in the physically layer, for example they could share the same fiber conduit as certain point of the routes. See our draft http://search.ietf.org/internet-drafts/draft-chiu-strand-unique-olcp-00.txt for more details on this. Regards, Angela -----Original Message----- From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] Sent: Wednesday, October 25, 2000 11:21 AM To: 'alchiu@research.att.com' Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Angela Chiu wrote: > In > particular, routing a new lightpath that is diverse from one or more > existing lightpaths is not only needed by the capability that Kireeti > described earlier, i.e., layer-3 like protection switching, > but also needed > in cases where an upper layer network wants to have its own > survivability. > For example, an IP network wants to have IP layer only > restoration (e.g., if > link C-D needs to support additional traffic when link A-B > fails, they need > to be diversely routed), or a private line network needs to > have diversity > among a set of links as John pointed our earlier (for more details on > diverse routing, see the draft we presented in last IETF, > http://search.ietf.org/internet-drafts/draft-chiu-strand-uniqu > e-olcp-00.txt, > a new version will be issued in a few weeks). Can't the existing IP options fields be used to achieve this at Layer 3? If light paths are merely links between routers, can't you achieve path diversity this way, if you want to do this at the Network Layer? Bert albert.e.manfredi@boeing.com From owner-mpls@UU.NET Wed Oct 25 11:46:17 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28282 for ; Wed, 25 Oct 2000 11:46:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlj29689; Wed, 25 Oct 2000 15:45:32 GMT Received: by mail-control.mail.uu.net id QQjmli08969 for mpls-outgoing; Wed, 25 Oct 2000 15:44:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmli08964 for ; Wed, 25 Oct 2000 15:44:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmli04712 for ; Wed, 25 Oct 2000 15:44:20 GMT Received: from smtprch1.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjmli26677 for ; Wed, 25 Oct 2000 15:44:20 GMT Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by smtprch1.nortel.com; Wed, 25 Oct 2000 10:23:19 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VT2NQ7D6; Wed, 25 Oct 2000 11:23:15 -0400 Received: from nortelnetworks.com (starmie.engeast.baynetworks.com [192.32.148.132]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VDZZ16T8; Wed, 25 Oct 2000 11:23:14 -0400 Message-ID: <39F6FAE2.799C99AF@nortelnetworks.com> Date: Wed, 25 Oct 2000 11:23:15 -0400 From: "Antonela Paraschiv" X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manis CC: mpls@UU.NET Subject: Re: Doubts in "draft-ietf-mpls-lsp-query-00.txt" References: <002e01c03e6d$3fb8b1c0$1006000a@future.futsoft.com> Content-Type: multipart/alternative; boundary="------------D5CCCDA3242B164B72E54EA0" Sender: owner-mpls@UU.NET Precedence: bulk --------------D5CCCDA3242B164B72E54EA0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thank you for comments. Please find my answers below. Best regards, Antonela Paraschiv Manikantan S wrote: > Hello Paraschiv > > I read the draft "draft-ietf-mpls-lsp-query-00.txt". > > I have a few doubts and can you please clarify them? > > Thanks. > > 1) Label TLV is used in the Query message and the Query Label > TLV as Optional parameters in the Query Reply message. > Both the TLVs contain a set of Generalized Label TLVs. > I am not clear as why do we require Query Label TLV and > Label TLV i.e., two TLVs when the contents are the same? You are right. The only reason I created 2 different TLVs was to make it clearer . I could certainly remove one of them. > > > 2) ER TLV has been specified as Optional parameters in > Query Message and in Query-reply message. I understand > that this TLV's usage is to keep track of the hops. > Path Vector TLV (in LDP), RRO in (RSVP-TE)helps in > providing this information too. What is the significance > of using ER TLV? The ER TLV provides the proper format to encode a list of interface addresses. Its only purpose is to carry the list of hops. It is not used for loop detection as the Path Vector TLV. > > > 3) In Section 5.2 Page 9, we have > -------------------------------------------------------------------- > Upon receiving a Query Message, an LSR decodes the label to identify > which LSP is queried. If it cannot find the LSP which is using the > label, it sends back a Notification message. > -------------------------------------------------------------------- > What is the status value that should be indicated in this case? > > 4) In Section 6.2 Page 12, we have > ------------------------------------------------------------------- > A Query-Reply message is initiated by an egress node which receives a > Query message, if the egress is able to identify the queried LSP. If > not, the egress replies with a Notification message. > -------------------------------------------------------------------- > What is the status value that should be indicated in this case? 3 and 4 : I will add a new Status code: "No Lsp to query" with status data = next available. > > Should this be the same one as for question 3? > > I noticed Following minor typos/missing info > > 1) Section 6.3 Page 13 > we have > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Query-Reply (0x0411) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > should be > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Partial-Query-Reply (0x0411)| Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 2) Section 7.2 Page 16 > for "The format for the Query Label TLV " read "The format for the Merge > Flags TLV" > > 3) Section 7.3 Page 16 > for "The format for the Query Label TLV " read "The format for the Label > TLV" > > Thanks in advance > with best regards > mani > ----------------------------------------- > S.Manikantan > Future Software Limited > 480-481, Anna Salai, > Nandanam, Chennai, India. > Zip (PIN CODE) : 600 035 > Phone : 91-44-4330550 > Fax : 91-44-4344157 > email : manis@future.futsoft.com > ----------------------------------------- -- Antonela Paraschiv Carrier Packet Division, Nortel Networks Esn : 978-288-6136 E-mail: antonela@nortelnetworks.com --------------D5CCCDA3242B164B72E54EA0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Thank you for comments. Please find my answers below.
Best regards,
Antonela Paraschiv

Manikantan S wrote:

Hello Paraschiv

I read the draft "draft-ietf-mpls-lsp-query-00.txt".

I have a few doubts and can you please clarify them?

Thanks.

1) Label TLV is used in the Query message and the Query Label
   TLV as Optional parameters in the Query Reply message.
   Both the TLVs contain a set of Generalized Label TLVs.
   I am not clear as why do we require Query Label TLV and
   Label TLV i.e., two TLVs when the contents are the same?

You  are right. The only reason I created 2 different TLVs was to make it clearer . I could certainly remove one of them.
 

2) ER TLV has been specified as Optional parameters in
   Query Message and in Query-reply message. I understand
   that this TLV's usage is to keep track of the hops.
   Path Vector TLV (in LDP), RRO in (RSVP-TE)helps in
   providing this information too. What is the significance
   of using ER TLV?

The ER TLV provides the proper format to encode a list of interface addresses. Its only purpose is to carry the list of hops. It is not used for loop detection as the Path Vector TLV.
 

3) In Section 5.2 Page 9, we have
   --------------------------------------------------------------------
   Upon receiving a Query Message, an LSR decodes the label to identify
   which LSP is queried. If it cannot find the LSP which is using the
   label, it sends back a Notification message.
   --------------------------------------------------------------------
   What is the status value that should be indicated in this case?

4) In Section 6.2 Page 12, we have
   -------------------------------------------------------------------
   A Query-Reply message is initiated by an egress node which receives a
   Query message, if the egress is able to identify the queried LSP.  If
   not, the egress replies with a Notification message.
   --------------------------------------------------------------------
   What is the status value that should be indicated in this case?

3 and 4 : I will add a new Status code: "No Lsp to query" with status data = next available.
 
   Should this be the same one as for question 3?

I noticed Following minor typos/missing info

1) Section 6.3 Page 13
   we have
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|    Query-Reply (0x0411)     |      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  should be
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0| Partial-Query-Reply (0x0411)|      Message Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2) Section 7.2 Page 16
   for "The format for the Query Label TLV " read "The format for the Merge
Flags TLV"

3) Section 7.3 Page 16
   for "The format for the Query Label TLV " read "The format for the Label
TLV"

Thanks in advance
with best regards
mani
-----------------------------------------
S.Manikantan
Future Software Limited
480-481, Anna Salai,
Nandanam, Chennai, India.
Zip (PIN CODE) : 600 035
Phone          : 91-44-4330550
Fax            : 91-44-4344157
email          : manis@future.futsoft.com
-----------------------------------------

-- 
Antonela Paraschiv 
Carrier Packet Division, Nortel Networks
Esn   : 978-288-6136
E-mail: antonela@nortelnetworks.com
  --------------D5CCCDA3242B164B72E54EA0-- From owner-mpls@UU.NET Wed Oct 25 11:48:47 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28581 for ; Wed, 25 Oct 2000 11:48:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlj01760; Wed, 25 Oct 2000 15:48:03 GMT Received: by mail-control.mail.uu.net id QQjmlj09393 for mpls-outgoing; Wed, 25 Oct 2000 15:47:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmlj09376 for ; Wed, 25 Oct 2000 15:47:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlj11725 for ; Wed, 25 Oct 2000 15:46:50 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmlj01692 for ; Wed, 25 Oct 2000 15:46:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA09811 for mpls@uu.net; Wed, 25 Oct 2000 11:46:48 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmli08971 for ; Wed, 25 Oct 2000 15:44:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmli25574 for ; Wed, 25 Oct 2000 15:44:50 GMT Received: from stl-smtpout-01.boeing.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: stl-smtpout-01.boeing.com [12.13.247.21]) id QQjmli27318 for ; Wed, 25 Oct 2000 15:44:50 GMT Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA03823 for ; Wed, 25 Oct 2000 10:44:49 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id KAA06009 for ; Wed, 25 Oct 2000 10:44:47 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Wed, 25 Oct 2000 10:44:39 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 11:44:39 -0400 Message-Id: <4102273CEB77D211869200805FE6F593018C5B00@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'alchiu@research.att.com'" Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 11:44:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Angela Chiu wrote: > Bert, > > Two disjoint links in IP layer may not be diversely routed in > the physically > layer, for example they could share the same fiber conduit as > certain point > of the routes. See our draft > http://search.ietf.org/internet-drafts/draft-chiu-strand-uniqu > e-olcp-00.txt > for more details on this. Of course. But if a client wants to achieve path diversity at Layer 3, for whatever reasons of reliability, then the service provider could provide that client with the appropriate paths to use, based on that service provider's physical network. Nothing new to invent? And if the service provider sets up the separate paths over separate OSPF areas, for example, one might ensure that the paths stay physically separate. Bert albert.e.manfredi@boeing.com From owner-mpls@UU.NET Wed Oct 25 11:55:52 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29440 for ; Wed, 25 Oct 2000 11:55:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlj12596; Wed, 25 Oct 2000 15:54:47 GMT Received: by mail-control.mail.uu.net id QQjmlj09855 for mpls-outgoing; Wed, 25 Oct 2000 15:54:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlj09811 for ; Wed, 25 Oct 2000 15:54:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlj21723 for ; Wed, 25 Oct 2000 15:53:15 GMT Received: from mail-blue.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQjmlj09144 for ; Wed, 25 Oct 2000 15:53:14 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id EC1274CE29; Wed, 25 Oct 2000 11:53:13 -0400 (EDT) Received: from pcalchiu (pclopez [135.207.131.94]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id LAA29643; Wed, 25 Oct 2000 11:53:08 -0400 (EDT) Reply-To: From: "Angela Chiu" To: "'Manfredi, Albert E'" Cc: , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 11:54:30 -0400 Message-ID: <001201c03e9b$dd768940$5e83cf87@attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <4102273CEB77D211869200805FE6F593018C5B00@xch-phl-01.he.boeing.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bert, The part that is new is that we want to automate the whole request and routing process by using signaling protocols in the control plane. As Kireeti pointed our earlier, current GMPLS protocols do not provide such capability is the overlay model is used. Regards, Angela -----Original Message----- From: Manfredi, Albert E [mailto:Albert.Manfredi@PHL.Boeing.com] Sent: Wednesday, October 25, 2000 11:44 AM To: 'alchiu@research.att.com' Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Angela Chiu wrote: > Bert, > > Two disjoint links in IP layer may not be diversely routed in > the physically > layer, for example they could share the same fiber conduit as > certain point > of the routes. See our draft > http://search.ietf.org/internet-drafts/draft-chiu-strand-uniqu > e-olcp-00.txt > for more details on this. Of course. But if a client wants to achieve path diversity at Layer 3, for whatever reasons of reliability, then the service provider could provide that client with the appropriate paths to use, based on that service provider's physical network. Nothing new to invent? And if the service provider sets up the separate paths over separate OSPF areas, for example, one might ensure that the paths stay physically separate. Bert albert.e.manfredi@boeing.com From owner-mpls@UU.NET Wed Oct 25 12:01:40 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00631 for ; Wed, 25 Oct 2000 12:01:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlk19626; Wed, 25 Oct 2000 16:00:51 GMT Received: by mail-control.mail.uu.net id QQjmlk12911 for mpls-outgoing; Wed, 25 Oct 2000 16:00:29 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlk12185 for ; Wed, 25 Oct 2000 16:00:22 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlk22459 for ; Wed, 25 Oct 2000 16:00:10 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmlk16869 for ; Wed, 25 Oct 2000 16:00:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA12821 for mpls@uu.net; Wed, 25 Oct 2000 12:00:08 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlj10242 for ; Wed, 25 Oct 2000 15:59:53 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlj21385 for ; Wed, 25 Oct 2000 15:59:46 GMT Received: from coltrane.dataconnection.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.datcon.co.uk [192.91.191.4]) id QQjmlj16281 for ; Wed, 25 Oct 2000 15:59:45 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id <4W19NMC1>; Wed, 25 Oct 2000 16:59:43 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2CA5AE@monk.datcon.co.uk> From: Adrian Farrel To: Lou Berger Cc: mpls@UU.NET, petera@nortelnetworks.com Subject: RE: draft-ietf-mpls-generalized-signaling-00.txt Date: Wed, 25 Oct 2000 16:59:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Lou, Thanks. Agreement reached on all points. Best regards, Adrian -- Adrian Farrel mailto:af@dataconnection.com Network Convergence Group Data Connection Ltd., Chester, UK http://www.dataconnection.com/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Wed Oct 25 12:09:53 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02454 for ; Wed, 25 Oct 2000 12:09:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlk01296; Wed, 25 Oct 2000 16:08:26 GMT Received: by mail-control.mail.uu.net id QQjmlk22237 for mpls-outgoing; Wed, 25 Oct 2000 16:07:50 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmlk22218 for ; Wed, 25 Oct 2000 16:07:45 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlk17871 for ; Wed, 25 Oct 2000 16:07:03 GMT Received: from ennovatenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjmlk29305 for ; Wed, 25 Oct 2000 16:07:03 GMT Received: from ennovatenetworks.com (h0040d0042eaa.ne.mediaone.net [24.147.156.69]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id MAA29204; Wed, 25 Oct 2000 12:06:43 -0400 (EDT) (envelope-from pdoolan@ennovatenetworks.com) Message-ID: <39F700ED.E9E8B872@ennovatenetworks.com> Date: Wed, 25 Oct 2000 11:49:01 -0400 From: Paul Doolan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution References: <200010251438.HAA29438@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: >P.S. While some folks like to complain about scalability and >problems with BGP (and therefore with BGP/MPLS VPN), please >note that without working BGP, it would be highly unlikely that >you'll be able to receive this e-mail. Which is true. But irrelevant. BGP helps the IP internetwork deliver email ergo it's good for VPNs ? Mail works as well as it does because of the reliability built into the application and transfer protocols. That reliability is provided because of the unreliable nature of the underlying network layer which can be attributed to a number of causes including failures in IDR. As an aside I'm not aware of anyone who is suggesting building VPNs to deliver email. Are you ? pd From owner-mpls@UU.NET Wed Oct 25 12:25:38 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04549 for ; Wed, 25 Oct 2000 12:25:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmll19411; Wed, 25 Oct 2000 16:24:30 GMT Received: by mail-control.mail.uu.net id QQjmll23583 for mpls-outgoing; Wed, 25 Oct 2000 16:24:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmll23575 for ; Wed, 25 Oct 2000 16:23:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmll01710 for ; Wed, 25 Oct 2000 16:23:52 GMT Received: from ennovatenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjmll18446 for ; Wed, 25 Oct 2000 16:23:51 GMT Received: from ennovatenetworks.com (h0040d0042eaa.ne.mediaone.net [24.147.156.69]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id MAA00436; Wed, 25 Oct 2000 12:23:45 -0400 (EDT) (envelope-from pdoolan@ennovatenetworks.com) Message-ID: <39F704E7.F394E14F@ennovatenetworks.com> Date: Wed, 25 Oct 2000 12:05:59 -0400 From: Paul Doolan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Robert M Matheson , "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution References: <200010251445.KAA20980@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, Yesterday, in response to Bryan, it was 'hogwash' today its 'FUD'. This is not your usual dispassionate approach. Has something touched a raw nerve ? There's an unintentional, I'm sure, hilarity in your last paragraph. While Robert's probably going a little over the top with his "market concensus" (he was probably using George's definition) how about "widely adopted" ? Don't you think that's overstating the case just a wee bit ? pd Eric Rosen wrote: > When someone asks a question which is of the form "which vendor has the > best product offering for some particular purpose", you can't really expect > a technical discussion to follow, but you can expect a lot of FUD. > > This thread is of that sort. All you can learn from it is that everyone has > their own favorite scheme, and you can pretty much guess which scheme > someone will like by noting which company he works for. > > You know the thread has reached the point of absurdity when people refer to > a scheme which has been widely adopted and assert that there is a "market > consensus" against it. From owner-mpls@UU.NET Wed Oct 25 12:29:50 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05087 for ; Wed, 25 Oct 2000 12:29:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmll25368; Wed, 25 Oct 2000 16:28:43 GMT Received: by mail-control.mail.uu.net id QQjmll23853 for mpls-outgoing; Wed, 25 Oct 2000 16:28:20 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmll23832 for ; Wed, 25 Oct 2000 16:28:13 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmll04526 for ; Wed, 25 Oct 2000 16:27:26 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmll23553 for ; Wed, 25 Oct 2000 16:27:26 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA02648; Wed, 25 Oct 2000 09:27:25 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA21261; Wed, 25 Oct 2000 12:27:22 -0400 (EDT) Message-Id: <200010251627.MAA21261@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Paul Doolan cc: Robert M Matheson , "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution In-reply-to: Your message of Wed, 25 Oct 2000 12:05:59 -0400. <39F704E7.F394E14F@ennovatenetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 25 Oct 2000 12:27:21 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Paul> how about "widely adopted" ? Don't you think that's overstating the Paul> case just a wee bit ? No. Paul> Yesterday, in response to Bryan, it was 'hogwash' today its Paul> 'FUD'. This is not your usual dispassionate approach. Has something Paul> touched a raw nerve ? No, sometimes it's just necessary to call 'em like I see 'em. From owner-mpls@UU.NET Wed Oct 25 12:39:51 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07022 for ; Wed, 25 Oct 2000 12:39:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlm09302; Wed, 25 Oct 2000 16:39:04 GMT Received: by mail-control.mail.uu.net id QQjmlm24468 for mpls-outgoing; Wed, 25 Oct 2000 16:38:41 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlm24461 for ; Wed, 25 Oct 2000 16:38:32 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlm19619 for ; Wed, 25 Oct 2000 16:38:17 GMT Received: from postal.redback.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: postal.redback.com [155.53.12.9]) id QQjmlm11267 for ; Wed, 25 Oct 2000 16:38:16 GMT Received: from redback.com (pptp-15-136.redback.com [155.53.15.136]) by postal.redback.com (Postfix) with ESMTP id A42CB17BC14; Wed, 25 Oct 2000 09:38:14 -0700 (PDT) Message-ID: <39F7374F.7ED31F7C@redback.com> Date: Wed, 25 Oct 2000 12:41:03 -0700 From: Rob Coltun X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Doolan , erosen@cisco.com, Robert M Matheson , "Newcomb, Robert" , "'Juan Diego Otero'" Cc: "'mpls@uu.net'" Subject: Re: VPN solution References: <200010251445.KAA20980@erosen-sun.cisco.com> <39F704E7.F394E14F@ennovatenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit We're starting to move into inappropriate territories. Can we move this thread to the more appropriate dukeitoutsomewhereelse mailing list. thanks, ---rob > > > Yesterday, in response to Bryan, it was 'hogwash' today its 'FUD'. This is > not your usual dispassionate approach. Has something touched a raw nerve ? > > There's an unintentional, I'm sure, hilarity in your last paragraph. While > Robert's > probably going a little over the top with his "market concensus" (he was > probably > using George's definition) how about "widely adopted" ? Don't you think that's > overstating the case just a wee bit ? > > pd > > Eric Rosen wrote: > > > When someone asks a question which is of the form "which vendor has the > > best product offering for some particular purpose", you can't really expect > > a technical discussion to follow, but you can expect a lot of FUD. > > > > This thread is of that sort. All you can learn from it is that everyone has > > their own favorite scheme, and you can pretty much guess which scheme > > someone will like by noting which company he works for. > > > > You know the thread has reached the point of absurdity when people refer to > > a scheme which has been widely adopted and assert that there is a "market > > consensus" against it. From owner-mpls@UU.NET Wed Oct 25 12:50:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08581 for ; Wed, 25 Oct 2000 12:50:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmln24390; Wed, 25 Oct 2000 16:48:59 GMT Received: by mail-control.mail.uu.net id QQjmln25133 for mpls-outgoing; Wed, 25 Oct 2000 16:48:41 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmln25128 for ; Wed, 25 Oct 2000 16:48:38 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmln20690 for ; Wed, 25 Oct 2000 16:47:14 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmln21884 for ; Wed, 25 Oct 2000 16:47:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA21184 for mpls@uu.net; Wed, 25 Oct 2000 12:47:12 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmln25085 for ; Wed, 25 Oct 2000 16:46:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmln07248; Wed, 25 Oct 2000 16:45:39 GMT Received: from almso1.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: almso1.att.com [192.128.167.69]) id QQjmln20912; Wed, 25 Oct 2000 16:45:38 GMT Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id MAA14543; Wed, 25 Oct 2000 12:45:37 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id MAA14153; Wed, 25 Oct 2000 12:44:35 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Wed, 25 Oct 2000 12:45:36 -0400 Message-ID: <31236E6272C7D2119F1C0000C0A8E4F40324054B@nj0200po04.bm.att.com> From: "Lazer, Monica A, NNAD" To: "'Yakov Rekhter'" Cc: neil.2.harrison@bt.com, David.A.Holmes@disney.com, Mark.Jones@mail.sprint.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, kireeti@juniper.net, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 12:45:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yakov, As of today I am not convinced that any given alternative is "the best". However, I do know that from a network operator's perspective the choice for the best alternative is based on analysis of the capabilities of the potential options. The basic item here is that there are certain capabilities that have to be supported by the OTN. I (with other representatives at T1X1) am working on putting together a list of needed capabilities, based on several existing requirements documents already presented in different forums with additional input, if needed from willing participants. That should form criteria for figuring out which is the best standard solution for OTN. We are looking at vendor representatives to help assess the degree to which different architectures and signaling schemes can support or can be extended to support these capabilities, and we are looking at interested network operators to help sift through these requirements and build the criteria needed for this assessment. I believe that this approach is sound. In the mean time I can refer you to several documents which are relevant to our concerns. ftp://ftp.t1.org/pub/t1x1/x1.0/0x100490.doc and ITU-T ftp://ftp.t1.org/pub/t1x1/x1.0/0x100510.doc P.S. We are also in the process of reformatting ftp://ftp.t1.org/pub/t1x1/x1.0/0x100510.doc and posting it as a draft for the IETF community. (we would have done it earlier, but putting all the figures in the stick format .....). Monica A. Lazer Advanced Transport Technology and Architecture Planning 908 234 8462 mlazer@att.com -----Original Message----- From: Yakov Rekhter [mailto:yakov@cisco.com] Sent: Tuesday, October 24, 2000 6:57 PM To: Lazer, Monica A, NNAD Cc: 'Yakov Rekhter'; neil.2.harrison@bt.com; David.A.Holmes@disney.com; Mark.Jones@mail.sprint.com; ip-optical@lists.bell-labs.com; mpls@UU.NET; kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Monica, > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@cisco.com] > Sent: Tuesday, October 24, 2000 1:58 PM > To: neil.2.harrison@bt.com > Cc: David.A.Holmes@disney.com; Mark.Jones@mail.sprint.com; > ip-optical@lists.bell-labs.com; mpls@UU.NET; kireeti@juniper.net; > sc@tellium.com; xuyg@lucent.com; yxue@UU.NET; zwlin@lucent.com > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > Neil, > > [clipped...] > > > (i) are traditional IP control-plane facets (so that is, for > > example, v4 addressing, RSVP signalling and a IGP) the correct choice for > an > > OTN?....though to be honest no-one it seems dare raise this most basic of > > questions too loudly; > > > [MAL] Neil is right. I have not seen any overwhelming evidence as to why a > protocol used for routing individual packets is the best possible > alternative to be used to set-up circuits. > yakov > If you have "the correct choice" for an OTN, which is other than yakov > GMPLS, please share it with the rest of us (by the way, don't yakov > forget to include detailed description of why your "correct choice" yakov > is any better than GMPLS). If you think that Neil is right, then please share with the rest of us what do you think is "the best possible alternative" (please include an explanation on why it is any better than GMPLS). Yakov. P.S. On being constructive, let me suggest that rather than continue telling us that GMPLS is not "the best possible alternative to be used to set-up circuits", folks who subscribe to this point of view should start working on "the best possible alternative". From owner-mpls@UU.NET Wed Oct 25 12:51:48 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08760 for ; Wed, 25 Oct 2000 12:51:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmln25257; Wed, 25 Oct 2000 16:51:05 GMT Received: by mail-control.mail.uu.net id QQjmln25184 for mpls-outgoing; Wed, 25 Oct 2000 16:50:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmln25178 for ; Wed, 25 Oct 2000 16:50:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmln15018 for ; Wed, 25 Oct 2000 16:49:49 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmln25850 for ; Wed, 25 Oct 2000 16:49:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA21632 for mpls@uu.net; Wed, 25 Oct 2000 12:49:47 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmln25137 for ; Wed, 25 Oct 2000 16:48:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmln16152 for ; Wed, 25 Oct 2000 16:48:40 GMT Received: from alpo.casc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpo.casc.com [152.148.10.6]) id QQjmln21929 for ; Wed, 25 Oct 2000 16:48:39 GMT Received: from lucent.com ([152.148.88.87]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id MAA03390; Wed, 25 Oct 2000 12:47:34 -0400 (EDT) Message-ID: <39F6F3C1.F62D6A12@lucent.com> Date: Wed, 25 Oct 2000 10:52:49 -0400 From: Karthik Muthukrishnan Organization: Lucent Technologies: InterNetworking Systems X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Yakov Rekhter , "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution References: <200010251511.LAA21044@erosen-sun.cisco.com> Content-Type: multipart/mixed; boundary="------------B033CE14D591AC54FDBF8DDD" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------B033CE14D591AC54FDBF8DDD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric: The question is not whether BGP is scalable. The question is whether informational rfc 2547 use of BGP to build MPLS VPNs is scalable.. -karthik Eric Rosen wrote: > > Yakov> P.S. While some folks like to complain about scalability and > Yakov> problems with BGP > > ***SARCASM ALERT*** > > Well, if BGP were really scalable, then the Internet would no longer be just > a small scale academic and government toy; it would have world-wide scope > and be heavily used by commerce and industry. > > I always find it interesting that people will say that the network layer > mechanisms which hold the Internet together are unscalable, and then will > advocate the use of data link layer mechanisms instead. I guess that once > we have the scalable and easy to manage "world wide lan", or the scalable > and easy to manage "word wide mesh of point-to-point links", we won't need > stuff like BGP any more. > > ***END OF SARCASM ALERT*** > > (and sorry for wasting everyone's time) --------------B033CE14D591AC54FDBF8DDD Content-Type: text/x-vcard; charset=us-ascii; name="mkarthik.vcf" Content-Description: Card for Karthik Muthukrishnan Content-Disposition: attachment; filename="mkarthik.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Muthukrishnan;Karthik tel;pager:1587321@skytel.com tel;fax:(978)-692-1509 tel;work:(978)-952-1368 x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:mkarthik@lucent.com end:vcard --------------B033CE14D591AC54FDBF8DDD-- From owner-mpls@UU.NET Wed Oct 25 13:03:21 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10309 for ; Wed, 25 Oct 2000 13:03:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlo12754; Wed, 25 Oct 2000 17:02:23 GMT Received: by mail-control.mail.uu.net id QQjmlo00329 for mpls-outgoing; Wed, 25 Oct 2000 17:02:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmlo00156 for ; Wed, 25 Oct 2000 17:01:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlo24698 for ; Wed, 25 Oct 2000 17:01:14 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmlo11999 for ; Wed, 25 Oct 2000 17:01:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA23991 for mpls@uu.net; Wed, 25 Oct 2000 13:01:13 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlo28784 for ; Wed, 25 Oct 2000 17:00:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlo17210 for ; Wed, 25 Oct 2000 17:00:18 GMT Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmlo07674 for ; Wed, 25 Oct 2000 17:00:17 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA11446; Wed, 25 Oct 2000 09:59:06 -0700 (PDT) Message-Id: <200010251659.JAA11446@omega.cisco.com> To: Karthik Muthukrishnan cc: erosen@cisco.com, "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution In-reply-to: Your message of "Wed, 25 Oct 2000 10:52:49 EDT." <39F6F3C1.F62D6A12@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11444.972493146.1@cisco.com> Date: Wed, 25 Oct 2000 09:59:06 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Karthik, > Eric: > > The question is not whether BGP is scalable. The question is whether > informational rfc 2547 use of BGP to build MPLS VPNs is scalable.. For those interested in answering this question, please read the scalability analysis described in section 15 of draft-rosen-rfc2547bis-02.txt. Yakov. > > -karthik > > Eric Rosen wrote: > > > > Yakov> P.S. While some folks like to complain about scalability and > > Yakov> problems with BGP > > > > ***SARCASM ALERT*** > > > > Well, if BGP were really scalable, then the Internet would no longer be jus t > > a small scale academic and government toy; it would have world-wide scop e > > and be heavily used by commerce and industry. > > > > I always find it interesting that people will say that the network laye r > > mechanisms which hold the Internet together are unscalable, and then wil l > > advocate the use of data link layer mechanisms instead. I guess that onc e > > we have the scalable and easy to manage "world wide lan", or the scalabl e > > and easy to manage "word wide mesh of point-to-point links", we won't nee d > > stuff like BGP any more. > > > > ***END OF SARCASM ALERT*** > > > > (and sorry for wasting everyone's time) > --------------B033CE14D591AC54FDBF8DDD > Content-Type: text/x-vcard; charset=us-ascii; > name="mkarthik.vcf" > Content-Transfer-Encoding: 7bit > Content-Description: Card for Karthik Muthukrishnan > Content-Disposition: attachment; > filename="mkarthik.vcf" > > begin:vcard > n:Muthukrishnan;Karthik > tel;pager:1587321@skytel.com > tel;fax:(978)-692-1509 > tel;work:(978)-952-1368 > x-mozilla-html:TRUE > adr:;;;;;; > version:2.1 > email;internet:mkarthik@lucent.com > end:vcard > > --------------B033CE14D591AC54FDBF8DDD-- > From owner-mpls@UU.NET Wed Oct 25 13:06:22 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10695 for ; Wed, 25 Oct 2000 13:06:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlo17121; Wed, 25 Oct 2000 17:05:34 GMT Received: by mail-control.mail.uu.net id QQjmlo07379 for mpls-outgoing; Wed, 25 Oct 2000 17:05:05 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlo07356 for ; Wed, 25 Oct 2000 17:04:51 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlo18784 for ; Wed, 25 Oct 2000 17:03:51 GMT Received: from c008.sfo.cp.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: c008-h017.c008.sfo.cp.net [209.228.14.206]) id QQjmlo12241 for ; Wed, 25 Oct 2000 17:03:50 GMT Received: (cpmta 15067 invoked from network); 25 Oct 2000 10:03:49 -0700 Received: from 04-wks-1004.pcnet.whq.netconstruct.com (HELO 04wks1004) (208.179.184.97) by smtp.netconstruct.com (209.228.14.206) with SMTP; 25 Oct 2000 10:03:49 -0700 X-Sent: 25 Oct 2000 17:03:49 GMT Reply-To: From: "Alexander G. Paoli" Cc: "'mpls@uu.net'" Subject: RE: VPN solution Date: Wed, 25 Oct 2000 10:02:33 -0700 Message-ID: <009c01c03ea5$5ea2fe00$61b8b3d0@pcnet.whq.netconstruct.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01C03E6A.B2442600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009D_01C03E6A.B2442600 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQjmlo17121 Content-Transfer-Encoding: quoted-printable All, I would like to add, that as simple as the question is it has merit. Some= of us look to each other and to you for real life examples. I believe that Wenbo Sheng asked a question that no one has really answered, except to say.. =93Here, go look at this draft.=94. Then of course like = usual, somebody=92s feelings were hurt and POOF this thread is useless and non productive. I, like Wenbo, are curious what you all think about the various VPN solutions and are interested in you responses. I am currently in the move= to implement a 30 =96 40 node worldwide presence using MPLS VPN. I have MIS,= IT and engineers waiting to hear what I decide (as well as some very excited Vendors needless to say, it=92s a 100 Million dollar job). I have read th= e drafts and come to some conclusions, however, not ready to directly ask a= ny of you. Then this thread popped up, I was happy to see it and was interes= ted in what you all had to say. To my amazement I felt like I was watching a Linux thread when a MS product is brought up.. (run!!) SO please, could we attempt to answer this question? I would ask that everyone write his or her DIRECT experience with the subject; even if it touches a nerve, just write what you have found or experienced in researc= h, writing the drafts, implementation and day to day management. Readers lik= e myself and others will then decide based on the data, which if any MPLS V= PN solution is the one to research and/or implement for our customers and conclude which solution might be the =93=85most popular=94. If you feel the nerve to attack someone else=92s response (Including myse= lf), do it off-line. Please! Thanks for you time and wonderful work. BTW: The original question (for those of you that lost it) is attached below. Alexander G. Paoli VP Technology Chief Network Architect NetConstruct, Inc. (818) 985.2239 -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Wenbo Shen= g Sent: Tuesday, October 24, 2000 8:26 PM To: 'mpls-ops@mplsrc.com' Cc: 'mpls@uu.net' Subject: VPN solution HI, Assuming my customer need to create a VPN, I just want to know which solution is better - using MPLS-VPN or virtual routers? Which solution is/will be more popular in creating a VPN? Thanks in advance, W.S. ------=_NextPart_000_009D_01C03E6A.B2442600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VPN solution

Al= l,

 

I = would like to add, that as simple as the question is it has merit. Some of us = look to each other and to you for real life examples. I believe that Wenbo Sheng = asked a question that no one has really answered, except to say.. “Here, = go look at this draft.<yada yada>”. Then of course like usual, = somebody’s feelings were hurt and POOF this thread is useless and non = productive.

 

I,= like Wenbo, are curious what you all think about the various VPN solutions = and are interested in you responses. I am currently in the move to implement a = 30 – 40 node worldwide presence using MPLS VPN. I have MIS, IT and engineers waiting = to hear what I decide (as well as some very excited Vendors needless to say, = it’s a 100 Million dollar job). I have read the drafts and come to some = conclusions, however, not ready to directly ask any of you. Then this thread popped = up, I was happy to see it and was interested in what you all had to say. To my amazement I felt like I was watching a Linux thread when a MS product is brought up.. (run!!)

 

SO= please, could we attempt to answer this question? I would ask that everyone = write his or her DIRECT experience with the subject; even if it touches a nerve, = just write what you have found or experienced in research, writing the = drafts, implementation and day to day management. Readers like myself and others will then = decide based on the data, which if any MPLS VPN solution is the one to research = and/or implement for our customers and conclude which solution might be the = “…most popular”.

 

If= you feel the nerve to attack someone else’s response (Including = myself), do it off-line. Please!

 

 

Th= anks for you time and wonderful work.

 

BT= W: The original question (for those of you that lost it) is attached below. =

 

Alexander G. = Paoli

 

VP Technology

Chief Network = Architect

NetConstruct, = Inc.

(818) 985.2239

<= span class=3DEmailStyle16> 

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf = Of Wenbo Sheng
Sent: Tuesday, October = 24, 2000 8:26 PM
To: = 'mpls-ops@mplsrc.com'
Cc: 'mpls@uu.net'
Subject: VPN = solution

 

HI, <= /p>

Assuming my customer need to create a VPN, I just want to know which solution is = better - using MPLS-VPN or virtual routers? Which solution is/will be more = popular in creating a VPN?

Thanks in advance, = <= /p>

W.S. <= /p>

------=_NextPart_000_009D_01C03E6A.B2442600-- From owner-mpls@UU.NET Wed Oct 25 13:26:33 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13358 for ; Wed, 25 Oct 2000 13:26:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlp11582; Wed, 25 Oct 2000 17:25:48 GMT Received: by mail-control.mail.uu.net id QQjmlp09031 for mpls-outgoing; Wed, 25 Oct 2000 17:25:26 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmlp09025 for ; Wed, 25 Oct 2000 17:25:25 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlp18677 for ; Wed, 25 Oct 2000 17:24:53 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmlp13319 for ; Wed, 25 Oct 2000 17:24:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA28579 for mpls@uu.net; Wed, 25 Oct 2000 13:24:51 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmlp08982 for ; Wed, 25 Oct 2000 17:24:25 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlp16985 for ; Wed, 25 Oct 2000 17:24:09 GMT Received: from mail-green.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQjmlp09362 for ; Wed, 25 Oct 2000 17:24:09 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 1D12F1E01B; Wed, 25 Oct 2000 13:24:09 -0400 (EDT) Received: from pcstranded (pcstranded [135.207.130.62]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id NAA01517; Wed, 25 Oct 2000 13:23:45 -0400 (EDT) Reply-To: From: "John Strand" To: "'Manfredi, Albert E'" , Cc: , Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 13:23:31 -0400 Message-ID: <011e01c03ea8$4eac33b0$3e82cf87@pcstranded.attnjs.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <4102273CEB77D211869200805FE6F593018C5B00@xch-phl-01.he.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id NAA13358 Bert, As I explained at length in an earlier Email it is a big mistake to assume that separate administrative domains implies physical diversity. (I talked about separate carriers, but it applies pretty generally.) John John Strand AT&T Lightwave Networks Research Dept. 100 Schulz Drive, Room 4-212 Red Bank, N.J. 07701-7033 (732)345-3255 jls@research.att.com -----Original Message----- From: ip-optical-admin@lists.bell-labs.com [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Manfredi, Albert E Sent: Wednesday, October 25, 2000 11:44 AM To: 'alchiu@research.att.com' Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Angela Chiu wrote: > Bert, > > Two disjoint links in IP layer may not be diversely routed in > the physically > layer, for example they could share the same fiber conduit as > certain point > of the routes. See our draft > http://search.ietf.org/internet-drafts/draft-chiu-strand-uniqu > e-olcp-00.txt > for more details on this. Of course. But if a client wants to achieve path diversity at Layer 3, for whatever reasons of reliability, then the service provider could provide that client with the appropriate paths to use, based on that service provider's physical network. Nothing new to invent? And if the service provider sets up the separate paths over separate OSPF areas, for example, one might ensure that the paths stay physically separate. Bert albert.e.manfredi@boeing.com _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Wed Oct 25 13:31:18 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13963 for ; Wed, 25 Oct 2000 13:31:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlq21071; Wed, 25 Oct 2000 17:30:20 GMT Received: by mail-control.mail.uu.net id QQjmlp09388 for mpls-outgoing; Wed, 25 Oct 2000 17:29:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlp09380 for ; Wed, 25 Oct 2000 17:29:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlp16984 for ; Wed, 25 Oct 2000 17:29:31 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmlp16844 for ; Wed, 25 Oct 2000 17:29:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA03340; Wed, 25 Oct 2000 10:29:29 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA21399; Wed, 25 Oct 2000 13:29:28 -0400 (EDT) Message-Id: <200010251729.NAA21399@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Paul Doolan cc: Yakov Rekhter , "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution In-reply-to: Your message of Wed, 25 Oct 2000 11:49:01 -0400. <39F700ED.E9E8B872@ennovatenetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 25 Oct 2000 13:29:27 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Paul> Mail works as well as it does because of the reliability built into Paul> the application Having had several years' experience managing a large world-wide mailing list, I will never again speak of the "reliability" of the mail application. If you could only see the hundreds of error messages that are generated every time someone sends a message to the MPLS list! The Internet routing is one of the most reliable components of the whole operation, far more reliable than the operations that occur at the mail servers. Paul> and transfer protocols. It may be comforting to think of TCP as maintaining an open connection for weeks while the operators work heroically to restore the connectivity that has been lost due to the plethora of major routing failures. But I don't think this happens much. A lack of connectivity will result in an application-layer retry at some later time. In any event, the vast majority of the connectivity problems (from my experience managing the MPLS list) are due to problems at the mail servers. DNS problems are probably a distant second. Paul> That reliability is provided because of the unreliable nature of the Paul> underlying network layer which can be attributed to a number of causes Paul> including failures in IDR. TCP provides reliability not because the underlying network is unreliable (in any common sense of the word), but because the underlying network does not provide a service which guarantees against loss. "Doesn't guarantee against loss" is perhaps the technical meaning of "unreliable", but rhetorically sliding from the technical meaning ("IP provides an unreliable service") to the common meaning ("the Internet is unreliable") is a fallacy. The various TCP optimizations which presume in-order packet delivery to be the normal case are in fact testimony to the reliability in practice of the underlying network layer service. Paul> As an aside I'm not aware of anyone who is suggesting building VPNs to Paul> deliver email. I think that close to 100% of those who have VPNs use them for email. Anyway, I'm sure you realize that when Yakov said "email" he was just using it as an example of a commonly used Internet application. The set of commonly used Internet applications does bear a passing resemblance to the set of commonly used intranet applications. People build VPNs to support the entire set of network applications that they need to run, email being one of them, of course. Paul> BGP helps the IP internetwork deliver email ergo it's good for VPNs ? I don't think Yakov said that, what he was saying is that if BGP is scalable enough to handle Internet email, why should we think that it is not scalable enough to handle VPNs. Recognizing that "deliver email" is really placeholder for "support a large and varied set of networking applications", let's rephrase: if BGP is scalable enough to handle a large and varied set of Internet applications, why should we think it is not scalable enough to handle VPNs." Of course, the fact that BGP is scalable enough to handle VPNs does not by itself imply that VPNs should be built according to RFC2547, because the scalability of BGP is only one of the issues. Paul> What does FUD stand for by the way Fear, uncertainty, and doubt. (I.e., marketing.) From owner-mpls@UU.NET Wed Oct 25 13:58:00 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17269 for ; Wed, 25 Oct 2000 13:57:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlr26991; Wed, 25 Oct 2000 17:57:22 GMT Received: by mail-control.mail.uu.net id QQjmlr11087 for mpls-outgoing; Wed, 25 Oct 2000 17:57:05 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlr11079 for ; Wed, 25 Oct 2000 17:56:56 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlr21840; Wed, 25 Oct 2000 17:56:46 GMT Received: from smtprch2.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15]) id QQjmlr27117; Wed, 25 Oct 2000 17:56:46 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Wed, 25 Oct 2000 12:52:18 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 25 Oct 2000 12:56:19 -0500 Message-ID: <6DDA62170439D31185750000F80826AC04286E83@zmerd004.ca.nortel.com> From: "David Allan" To: alchiu , "'Yakov Rekhter'" Cc: ip-optical , mpls , sc , xuyg , yxue Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 12:56:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03EAC.DA2CCCC0" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03EAC.DA2CCCC0 Content-Type: text/plain; charset="iso-8859-1" Angela: Jointly routing the paths intuitively does not strike me as optimal. Not unless we are periodically performing path maintenance on the entire set of network resources. I would have to assume that the overall configuration of the network occurred incrementally, and with a desire to minimize service interruption of the already established paths. With that in mind, I would assume the routing of the primary path should always be chosen as the optimal route. The backup path is then required to be diverse (node, fiber, conduit, trench) with the optimal primary path and would frequently be less optimal as the physical routing would frequently be in the form of a longer path. I do not understand how whether this is done sequentially or simultaneously affects these basics, except in the possible deadlock scenario where the optimal routing of the primary path precludes a viable backup. In the meantime, I would assume sequential establishment of primary then backup would stand an overall greater chance of success, especially if the path computing node does not have a comprehensive and authoritative view of the network state. It strikes me that routing the backup should have the ability to intelligently crank back with knowledge of what to avoid to maintain diversity with the primary path. regards Dave > -----Original Message----- > From: Angela Chiu [SMTP:alchiu@research.att.com] > Sent: Wednesday, October 25, 2000 10:03 AM > To: 'Yakov Rekhter' > Cc: ip-optical; mpls; sc; xuyg; yxue > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > Yakov, > > Yes, you are right. Routing the primary and backup paths jointly is always > more optimal than fixing the path for primary first then routing the > backup > accordingly. The same argument can be applied to comparing centralized > routing with distributed routing. Even distributed routing is less > optimal, > it is the trend today. I think the real issue is at what cost the > additional > optimality is gained, and how much the additional optimality is in a > typical > network setting. In this case the cost is all the topological information > including SRLG information as well as physical impairment constraints in > the > optical network that routers need to obtain in order to make proper > routing > decision. > > I have an idea, this will be a valid master/PhD thesis for some graduate > students who would like to work on real world problems. > > Regards, > > Angela > > -----Original Message----- > From: ip-optical-admin@lists.bell-labs.com > [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Yakov Rekhter > Sent: Wednesday, October 25, 2000 7:35 AM > To: alchiu@research.att.com > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com; > xuyg@lucent.com; yxue@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > Angela, > > > Some followup discussions in line. > > more in line... > > > Regards, > > Angela > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kireeti > > Kompella > > Sent: Monday, October 23, 2000 1:58 PM > > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET > > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > > DraftMinutes From Pittsburgh > > > > > > > I don't see why TE and protection require the routers to specify > explicit > > > routes. > > > The routers can simply specify to the optical layer what type of > optical > > > layer protection > > > it requires. > > > > Suppose router A wants to get to router B, and wants to take two > > different ingress and egress points in the optical domain, X->Y > > for the primary LSP, and W->Z for the backup. A does not require > > optical protection for the X->Y path, nor for the W->Z path. A > > *does* require that the X->Y path and the W->Z path do not share > > common links. How is this to be done? > > > > If A did the full path computation, this is simplicity itself. > > > > [AC] I think you have a good point here. I also heard the same kind if > > reasoning (i.e., have a layer-3 like protection switching) for > supporting > > the peer model. But after discussing with others, it seems that overlay > > model should be able to provide the same capability. > > Not really... for more on this see below... > > > Normally, the primary > > LSP X->Y is set up first, and becomes a forwarding adjacency (FA) > according > > to your LSP Hierarchy draft. Then the associated information of the FA > X->Y > > including its exact path and SRLG information should be propagated via > IGP > > extensions, same as with any other link in the network. Thus if router A > > sends a request to OXC W to set up a backup lightpath from W->Z to be > > diversely router from the existing FA X->Y, OXC W should already have > the > > right information to perform proper routing. > > It is a known fact that for computing disjoint paths the approach > you outlined above may result in a situation where no backup > path will be found, despite the fact that that it is possible > (using some other approach) to find two disjoint paths. > > > Comparing with the peer model solution where routers need to know all > the > > SRLG information of the optical domain as well as all relevant physical > > impairments in the optical signal in the case of transparent optical > > network, it is still not clear to me which one is simpler. > > > > I think it is very good to have this kind of technical discussion openly > on > > the list. Hope others can provide more technical and business (after all > > carriers need to pay for these features) evidences for the need of each > > model. Some other reasoning I heard includes that peer model can improve > the > > IGP scalability in terms of the number of neighbors a router needs to > peer > > with. But since large ISPs today seem to cope well with the IGP > scalability > > today, I don't see why the problem will get significant worst when > optical > > networks come into play. > > In the end it is not the discussion on this list, but the competition > in the marketplace that will determine the viability of different > models. > > Yakov. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical > ------_=_NextPart_001_01C03EAC.DA2CCCC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes = From Pittsburgh

Angela:

Jointly routing the = paths intuitively does not strike me as optimal. Not unless we are = periodically performing path maintenance on the entire set of network = resources. I would have to assume that the overall configuration of the = network occurred incrementally, and with a desire to minimize service = interruption of the already established paths.

With that in mind, I = would assume the routing of the primary path should always be chosen as = the optimal route. The backup path is then required to be diverse = (node, fiber, conduit, trench) with the optimal primary path and would = frequently be less optimal as the physical routing would frequently be = in the form of a longer path.

I do not understand = how whether this is done sequentially or simultaneously affects these = basics, except in the possible deadlock scenario where the optimal = routing of the primary path precludes a viable backup. In the meantime, = I would assume sequential establishment of primary then backup would = stand an overall greater chance of success, especially if the path = computing node does not have a comprehensive and authoritative view of = the network state. It strikes me that routing the backup should have = the ability to intelligently crank back with knowledge of what to avoid = to maintain diversity with the primary path.

regards
Dave

    -----Original Message-----
    From:   Angela Chiu = [SMTP:alchiu@research.att.com]
    Sent:   Wednesday, October 25, 2000 10:03 AM
    To:     'Yakov Rekhter'
    Cc:     ip-optical; mpls; sc; xuyg; yxue
    Subject:       = RE: [IP-Optical] RE: Optical link = bundling. Was Re: DraftMinutes From  Pittsburgh

    Yakov,

    Yes, you are right. Routing the = primary and backup paths jointly is always
    more optimal than fixing the path for = primary first then routing the backup
    accordingly. The same argument can be = applied to comparing centralized
    routing with distributed routing. = Even distributed routing is less optimal,
    it is the trend today. I think the = real issue is at what cost the additional
    optimality is gained, and how much = the additional optimality is in a typical
    network setting. In this case the = cost is all the topological information
    including SRLG information as well as = physical impairment constraints in the
    optical network that routers need to = obtain in order to make proper routing
    decision.

    I have an idea, this will be a valid = master/PhD thesis for some graduate
    students who would like to work on = real world problems.

    Regards,

    Angela

    -----Original Message-----
    From: = ip-optical-admin@lists.bell-labs.com
    [mailto:ip-optical-a= dmin@lists.bell-labs.com]On Behalf Of Yakov Rekhter
    Sent: Wednesday, October 25, 2000 = 7:35 AM
    To: alchiu@research.att.com
    Cc: ip-optical@lists.bell-labs.com; = mpls@UU.NET; sc@tellium.com;
    xuyg@lucent.com; yxue@UU.NET
    Subject: Re: [IP-Optical] RE: Optical = link bundling. Was Re:
    DraftMinutes From Pittsburgh


    Angela,

    > Some followup discussions in = line.

    more in line...

    > Regards,
    > Angela
    >
    > -----Original = Message-----
    > From: owner-mpls@UU.NET = [mailto:owner-mpls@UU.NET]On= Behalf Of Kireeti
    > Kompella
    > Sent: Monday, October 23, 2000 = 1:58 PM
    > To: kireeti@juniper.net; = sc@tellium.com; xuyg@lucent.com; yxue@UU.NET
    > Cc: = ip-optical@lists.bell-labs.com; mpls@UU.NET
    > Subject: RE: [IP-Optical] RE: = Optical link bundling. Was Re:
    > DraftMinutes From = Pittsburgh
    >
    >
    > > I don't see why TE and = protection require the routers to specify
    explicit
    > > routes.
    > > The routers can simply = specify to the optical layer what type of optical
    > > layer protection
    > > it requires.
    >
    > Suppose router A wants to get to = router B, and wants to take two
    > different ingress and egress = points in the optical domain, X->Y
    > for the primary LSP, and W->Z = for the backup.  A does not require
    > optical protection for the = X->Y path, nor for the W->Z path.  A
    > *does* require that the X->Y = path and the W->Z path do not share
    > common links.  How is this = to be done?
    >
    > If A did the full path = computation, this is simplicity itself.
    >
    > [AC] I think you have a good = point here. I also heard the same kind if
    > reasoning (i.e., have a layer-3 = like protection switching) for supporting
    > the peer model. But after = discussing with others, it seems that overlay
    > model should be able to provide = the same capability.

    Not really... for more on this see = below...

    > Normally, the primary
    > LSP X->Y is set up first, and = becomes a forwarding adjacency (FA)
    according
    > to your LSP Hierarchy draft. = Then the associated information of the FA
    X->Y
    > including its exact path and = SRLG information should be propagated via IGP
    > extensions, same as with any = other link in the network. Thus if router A
    > sends a request to OXC W to set = up a backup lightpath from W->Z to be
    > diversely router from the = existing FA X->Y, OXC W should already have the
    > right information to perform = proper routing.

    It is a known fact that for computing = disjoint paths the approach
    you outlined above may result in a = situation where no backup
    path will be found, despite the fact = that that it is possible
    (using some other approach) to find = two disjoint paths.

    > Comparing with the peer model = solution where routers need to know all the
    > SRLG information of the optical = domain as well as all relevant physical
    > impairments in the optical = signal in the case of transparent optical
    > network, it is still not clear = to me which one is simpler.
    >
    > I think it is very good to have = this kind of technical discussion openly
    on
    > the list. Hope others can = provide more technical and business (after all
    > carriers need to pay for these = features) evidences for the need of each
    > model. Some other reasoning I = heard includes that peer model can improve
    the
    > IGP scalability in terms of the = number of neighbors a router needs to peer
    > with. But since large ISPs today = seem to cope well with the IGP
    scalability
    > today, I don't see why the = problem will get significant worst when optical
    > networks come into play.

    In the end it is not the discussion on = this list, but the competition
    in the marketplace that will = determine the viability of different
    models.

    Yakov.

    _______________________________________________
    IP-Optical mailing list
    IP-Optical@lists.bell-labs.com
    http://lists.bell-labs.com/mailman/listinfo/ip-optical=

------_=_NextPart_001_01C03EAC.DA2CCCC0-- From owner-mpls@UU.NET Wed Oct 25 14:00:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17528 for ; Wed, 25 Oct 2000 14:00:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlr29877; Wed, 25 Oct 2000 17:59:17 GMT Received: by mail-control.mail.uu.net id QQjmlr11135 for mpls-outgoing; Wed, 25 Oct 2000 17:59:00 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlr11126 for ; Wed, 25 Oct 2000 17:58:50 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlr24955 for ; Wed, 25 Oct 2000 17:58:06 GMT Received: from hermes.research.kpn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjmlr28887 for ; Wed, 25 Oct 2000 17:58:05 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JVRLKDMDOO000S89@research.kpn.com> for mpls@UU.NET; Wed, 25 Oct 2000 19:58:04 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 19:58:04 +0100 Content-return: allowed Date: Wed, 25 Oct 2000 19:58:01 +0100 From: "Metz, E.T." Subject: RE: VPN solution To: "'alex.paoli@netconstruct.com'" Cc: "'mpls@uu.net'" Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A5A9@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA17528 Probably, the answer to the question is that there is no straightforward answer. There are different solutions for building VPNs, all have their merits and downsides. Now it depends on the situation (i.e. the service you want to offer) which solution is best. Which features are important and which are not? Such a question is hard to answer for a general case, but much easier if you got the requirements sorted out. When can be matched with the characteristics/features of the solutions (which is where the drafts come in). cheers, Eduard ps this may be a good place to look at: http://nbvpn.francetelecom.com/ > ---------- > From: Alexander G. Paoli[SMTP:alex.paoli@netconstruct.com] > Sent: woensdag 25 oktober 2000 18:02 > Cc: 'mpls@uu.net' > Subject: RE: VPN solution > > All, >   > I would like to add, that as simple as the question is it has merit. Some > of us look to each other and to you for real life examples. I believe that > Wenbo Sheng asked a question that no one has really answered, except to > say.. "Here, go look at this draft.". Then of course like > usual, somebody's feelings were hurt and POOF this thread is useless and > non productive. >   > I, like Wenbo, are curious what you all think about the various VPN > solutions and are interested in you responses. I am currently in the move > to implement a 30 - 40 node worldwide presence using MPLS VPN. I have MIS, > IT and engineers waiting to hear what I decide (as well as some very > excited Vendors needless to say, it's a 100 Million dollar job). I have > read the drafts and come to some conclusions, however, not ready to > directly ask any of you. Then this thread popped up, I was happy to see it > and was interested in what you all had to say. To my amazement I felt like > I was watching a Linux thread when a MS product is brought up.. (run!!) >   > SO please, could we attempt to answer this question? I would ask that > everyone write his or her DIRECT experience with the subject; even if it > touches a nerve, just write what you have found or experienced in > research, writing the drafts, implementation and day to day management. > Readers like myself and others will then decide based on the data, which > if any MPLS VPN solution is the one to research and/or implement for our > customers and conclude which solution might be the "…most popular". >   > If you feel the nerve to attack someone else's response (Including > myself), do it off-line. Please! >   >   > Thanks for you time and wonderful work. >   > BTW: The original question (for those of you that lost it) is attached > below. >   > Alexander G. Paoli >   > VP Technology > Chief Network Architect > NetConstruct, Inc. > (818) 985.2239 >   > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Wenbo Sheng > Sent: Tuesday, October 24, 2000 8:26 PM > To: 'mpls-ops@mplsrc.com' > Cc: 'mpls@uu.net' > Subject: VPN solution >   > HI, > Assuming my customer need to create a VPN, I just want to know which > solution is better - using MPLS-VPN or virtual routers? Which solution > is/will be more popular in creating a VPN? > Thanks in advance, > W.S. > From owner-mpls@UU.NET Wed Oct 25 14:15:31 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19342 for ; Wed, 25 Oct 2000 14:15:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmls22190; Wed, 25 Oct 2000 18:14:11 GMT Received: by mail-control.mail.uu.net id QQjmls23711 for mpls-outgoing; Wed, 25 Oct 2000 18:13:39 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmls23670 for ; Wed, 25 Oct 2000 18:13:28 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmls28465 for ; Wed, 25 Oct 2000 18:12:32 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmls15512 for ; Wed, 25 Oct 2000 18:12:31 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA15286 for ; Wed, 25 Oct 2000 11:12:31 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA21499 for mpls@uu.net; Wed, 25 Oct 2000 14:12:29 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmlr10667 for ; Wed, 25 Oct 2000 17:50:23 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlr14416 for ; Wed, 25 Oct 2000 17:48:36 GMT Received: from pumpkin.bcit.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pumpkin.bcit.ca [142.232.189.70]) id QQjmlr16176 for ; Wed, 25 Oct 2000 17:48:36 GMT Subject: Query vis a vis every node is running RSVP-TE To: Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.2a November 23, 1999 Message-ID: From: "William Rutherford" Date: Wed, 25 Oct 2000 10:45:20 -0700 X-MIMETrack: Serialize by Router on Notesmail/BCIT(Release 5.0.3 |March 21, 2000) at 10/25/2000 10:45:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram Assuming that an explicit route object implies RSVP should/will reserve bandwidth along the specified route instead of other provisions >>> and some assurance that this is indeed occuring rather than the default behavior >>> what are the (possibly mission critical) feedback alternatives (possibly across AS boundaries etc.) on this. Thanks Bill R. From owner-mpls@UU.NET Wed Oct 25 14:16:47 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19498 for ; Wed, 25 Oct 2000 14:16:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmls21232; Wed, 25 Oct 2000 18:14:13 GMT Received: by mail-control.mail.uu.net id QQjmls23712 for mpls-outgoing; Wed, 25 Oct 2000 18:13:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmls23658 for ; Wed, 25 Oct 2000 18:13:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmls01245 for ; Wed, 25 Oct 2000 18:12:58 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmls19184 for ; Wed, 25 Oct 2000 18:12:58 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA17608 for ; Wed, 25 Oct 2000 11:12:56 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA21504 for mpls@uu.net; Wed, 25 Oct 2000 14:12:56 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlr10906 for ; Wed, 25 Oct 2000 17:55:09 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlr15046 for ; Wed, 25 Oct 2000 17:53:45 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjmlr19429 for ; Wed, 25 Oct 2000 17:53:42 GMT Received: from jupiter.csa.iisc.ernet.in (IDENT:root@jupiter.csa.iisc.ernet.in [144.16.67.42]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id XAA18107; Wed, 25 Oct 2000 23:21:31 +0530 Received: from localhost (asarun@localhost) by jupiter.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id XAA10240; Wed, 25 Oct 2000 23:23:22 +0530 X-Authentication-Warning: jupiter.csa.iisc.ernet.in: asarun owned process doing -bs Date: Wed, 25 Oct 2000 23:23:22 +0530 (IST) From: A S Arun To: mpls@UU.NET, rsvp@isi.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I am looking for a language by which policy can be entered There was one "policy Framework definition language" IETF Draft, Nov 1998, but is dormant now Are there any standard languages, Given a language I would write a compiler which would build the policy database, which would be searched as and when required. regards, ******************************************************************************* A.S.ARUN (Arun A Somasundara) 3rd Sem M.E. Room No. D-3 Computer Science & Engineering IISc Hostels Dept. of Computer Science & Automation Indian Institute of Science Bangalore - 560012 INDIA ******************************************************************************* From owner-mpls@UU.NET Wed Oct 25 14:20:19 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19944 for ; Wed, 25 Oct 2000 14:20:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlt00336; Wed, 25 Oct 2000 18:19:38 GMT Received: by mail-control.mail.uu.net id QQjmlt24293 for mpls-outgoing; Wed, 25 Oct 2000 18:19:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlt24283 for ; Wed, 25 Oct 2000 18:19:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlt16886 for ; Wed, 25 Oct 2000 18:18:17 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmlt27060 for ; Wed, 25 Oct 2000 18:18:16 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA22477 for ; Wed, 25 Oct 2000 11:18:14 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA21526 for mpls@uu.net; Wed, 25 Oct 2000 14:18:14 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlk22673 for ; Wed, 25 Oct 2000 16:11:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlk18671 for ; Wed, 25 Oct 2000 16:11:39 GMT Received: from roam.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [206.163.43.51]) id QQjmlk04704 for ; Wed, 25 Oct 2000 16:11:37 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13oT90-0004PG-00; Wed, 25 Oct 2000 09:11:14 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: Yakov Rekhter , "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution References: <200010251438.HAA29438@omega.cisco.com> <200010251511.LAA21044@erosen-sun.cisco.com> Message-Id: Date: Wed, 25 Oct 2000 09:11:14 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I always find it interesting that people will say that the network layer > mechanisms which hold the Internet together are unscalable and operators find it amusing that vendors thing their products are not dying from overload already and requiring massive effort to keep semi- functioning. From owner-mpls@UU.NET Wed Oct 25 14:21:51 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20129 for ; Wed, 25 Oct 2000 14:21:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlt26626; Wed, 25 Oct 2000 18:20:20 GMT Received: by mail-control.mail.uu.net id QQjmlt24306 for mpls-outgoing; Wed, 25 Oct 2000 18:19:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmlt24295 for ; Wed, 25 Oct 2000 18:19:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlt17976 for ; Wed, 25 Oct 2000 18:18:47 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmlt24336 for ; Wed, 25 Oct 2000 18:18:47 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA21408 for ; Wed, 25 Oct 2000 11:18:47 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA21534 for mpls@uu.net; Wed, 25 Oct 2000 14:18:45 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlp08925 for ; Wed, 25 Oct 2000 17:23:30 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlp03821 for ; Wed, 25 Oct 2000 17:23:09 GMT Received: from xaloc.upc.es by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: xaloc.upc.es [147.83.105.131]) id QQjmlp07997 for ; Wed, 25 Oct 2000 17:23:04 GMT Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id TAA04096; Wed, 25 Oct 2000 19:21:20 +0200 (METDST) Message-ID: <39F7251B.9A99BC4@estos.upc.es> Date: Wed, 25 Oct 2000 19:23:23 +0100 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Doolan CC: erosen@cisco.com, Yakov Rekhter , "Newcomb, Robert" , "'mpls@uu.net'" Subject: Re: VPN solution References: <200010251511.LAA21044@erosen-sun.cisco.com> <39F70778.63A477B@ennovatenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi again, Paul Doolan wrote: > Eric, > > >I always find it interesting that people will say that the network layer > >mechanisms which hold the Internet together are unscalable, and then will > >advocate the use of data link layer mechanisms instead. > > I'd find it interesting also. But it doesn't appear to me that Robert was > suggesting > that. So I'm puzzled why you would float such a notion in response to his mail ? > What > does FUD stand for by the way ? FUD = Fear Uncertainty Doubt I think Eric Rosen is right when he says: "When someone asks a question which is of the form "which vendor has the best product offering for some particular purpose", you can't really expect a technical discussion to follow, but you can expect a lot of FUD. This thread is of that sort. All you can learn from it is that everyone has their own favorite scheme, and you can pretty much guess which scheme someone will like by noting which company he works for. " Look, we are doing what Eric said: Everybody says that the model is scalable or not but nobody says why. I think we should do what Yakhov says and read the scalability analysis described in section 15 of draft-rosen-rfc2547bis-02.txt. When I answered the VPN solution first mail I expected this kind of reaction from the people in the mailing list. Best regards, Diego -- http://www.geocities.com/diego_otero/ From owner-mpls@UU.NET Wed Oct 25 14:32:53 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21446 for ; Wed, 25 Oct 2000 14:32:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlt13681; Wed, 25 Oct 2000 18:29:19 GMT Received: by mail-control.mail.uu.net id QQjmlt25211 for mpls-outgoing; Wed, 25 Oct 2000 18:28:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlt25204 for ; Wed, 25 Oct 2000 18:28:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlt16547 for ; Wed, 25 Oct 2000 18:27:56 GMT Received: from ennovatenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjmlt11251 for ; Wed, 25 Oct 2000 18:27:56 GMT Received: from ennovatenetworks.com (h0040d0042eaa.ne.mediaone.net [24.147.156.69]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id OAA08855; Wed, 25 Oct 2000 14:27:53 -0400 (EDT) (envelope-from pdoolan@ennovatenetworks.com) Message-ID: <39F721E7.F05F72FB@ennovatenetworks.com> Date: Wed, 25 Oct 2000 14:09:44 -0400 From: Paul Doolan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, don't know how it's going at your end but the private mail to me is 5 to 2 in favor of keeping this up. Which only goes to prove there are some folks with too much time on their hands;-) But we've probably tried the patience of a bigger number of folks. So I'm done after this. Eric>but rhetorically sliding from the technical meaning ("IP provides an unreliable Eric>service") to the common meaning ("the Internet is unreliable") is a Eric>fallacy. True but one which I didn't commit. >Paul> As an aside I'm not aware of anyone who is suggesting building VPNs to >Paul> deliver email. Eric>I think that close to 100% of those who have VPNs use them for email. And I agree with you. But its not got much to do with what I said has it ? Eric>Recognizing that "deliver email" is really placeholder for "support a large Eric>and varied set of networking applications", let's rephrase: if BGP is Eric>scalable enough to handle a large and varied set of Internet applications, Eric>why should we think it is not scalable enough to handle VPNs." Have you moved into marketing :-) BGP doesn't 'handle ...... applications'. It distributes reachability information in the IDR system. We may agree or disagree on how well it scales in that application. That has little bearing on whether that property applies in this different application. Eric>Of course, the fact that BGP is scalable enough to handle VPNs does not by Eric>itself imply that VPNs should be built according to RFC2547, because the Eric>scalability of BGP is only one of the issues. Ignoring the contentious first part I have to say I'm glad we can agree on one point. The scalability of BGP is only one of the issues with the protocol which call its use in this application into question. And there are other issues with building VPNs as well. pd From owner-mpls@UU.NET Wed Oct 25 14:33:26 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21530 for ; Wed, 25 Oct 2000 14:33:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlt11603; Wed, 25 Oct 2000 18:28:07 GMT Received: by mail-control.mail.uu.net id QQjmlt25066 for mpls-outgoing; Wed, 25 Oct 2000 18:27:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmlt25058 for ; Wed, 25 Oct 2000 18:27:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlt08465 for ; Wed, 25 Oct 2000 18:25:41 GMT Received: from roam.psg.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: roam.psg.com [147.28.4.2]) id QQjmlt07907 for ; Wed, 25 Oct 2000 18:25:40 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13oVEz-0004Wu-00; Wed, 25 Oct 2000 11:25:33 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: "'mpls@uu.net'" Subject: Re: VPN solution References: <39F704E7.F394E14F@ennovatenetworks.com> <200010251627.MAA21261@erosen-sun.cisco.com> Message-Id: Date: Wed, 25 Oct 2000 11:25:33 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > No, sometimes it's just necessary to call 'em like I see 'em. all depends on what glasses one wears, i guess. i am sure it's widely deployed within cisco. or is it. i just operate a network. i wouldn't touch 2547[bis] with a bargepole. it will not scale, will eat massive hardware, which i imagine is why uyou like it, and will make a fool of anyone who deploys it in large quantities. as mo says, i wish all my competitors would use it. randy From owner-mpls@UU.NET Wed Oct 25 14:37:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19946 for ; Wed, 25 Oct 2000 14:20:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlt29322; Wed, 25 Oct 2000 18:19:47 GMT Received: by mail-control.mail.uu.net id QQjmlt24300 for mpls-outgoing; Wed, 25 Oct 2000 18:19:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmlt24288 for ; Wed, 25 Oct 2000 18:19:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlt17116 for ; Wed, 25 Oct 2000 18:18:30 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmlt27354 for ; Wed, 25 Oct 2000 18:18:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA22725 for ; Wed, 25 Oct 2000 11:18:28 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA21530 for mpls@uu.net; Wed, 25 Oct 2000 14:18:28 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmlm24372 for ; Wed, 25 Oct 2000 16:36:13 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlm11907 for ; Wed, 25 Oct 2000 16:34:58 GMT Received: from ennovatenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjmlm05818 for ; Wed, 25 Oct 2000 16:34:58 GMT Received: from ennovatenetworks.com (h0040d0042eaa.ne.mediaone.net [24.147.156.69]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id MAA01127; Wed, 25 Oct 2000 12:34:45 -0400 (EDT) (envelope-from pdoolan@ennovatenetworks.com) Message-ID: <39F70778.63A477B@ennovatenetworks.com> Date: Wed, 25 Oct 2000 12:16:57 -0400 From: Paul Doolan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Yakov Rekhter , "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution References: <200010251511.LAA21044@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, >I always find it interesting that people will say that the network layer >mechanisms which hold the Internet together are unscalable, and then will >advocate the use of data link layer mechanisms instead. I'd find it interesting also. But it doesn't appear to me that Robert was suggesting that. So I'm puzzled why you would float such a notion in response to his mail ? What does FUD stand for by the way ? Oh, I apologise. You seem to be commenting on the, also irrelevant, observation wrt email & BGP made by Yakov. >(and sorry for wasting everyone's time) You said it ;-) pd From owner-mpls@UU.NET Wed Oct 25 14:45:53 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23588 for ; Wed, 25 Oct 2000 14:45:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlu06723; Wed, 25 Oct 2000 18:44:45 GMT Received: by mail-control.mail.uu.net id QQjmlu26087 for mpls-outgoing; Wed, 25 Oct 2000 18:44:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmlu26077 for ; Wed, 25 Oct 2000 18:44:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlu03598 for ; Wed, 25 Oct 2000 18:43:14 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmlu04273 for ; Wed, 25 Oct 2000 18:43:14 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA13888; Wed, 25 Oct 2000 11:42:41 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA21622; Wed, 25 Oct 2000 14:42:39 -0400 (EDT) Message-Id: <200010251842.OAA21622@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Paul Doolan cc: yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? In-reply-to: Your message of Wed, 25 Oct 2000 14:09:44 -0400. <39F721E7.F05F72FB@ennovatenetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 25 Oct 2000 14:42:39 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk I don't really want to keep it up either, but as long as misleading statements are being made I feel I have to reply. Paul> BGP ... distributes reachability information in the IDR system. We Paul> may agree or disagree on how well it scales in that application. That Paul> has little bearing on whether that property applies in this different Paul> application. Whether something scales in an extremely large environment has little bearing on whether it scales in a smaller environment? I can't imagine why anyone would make such a claim. Paul> The scalability of BGP is only one of the issues with the protocol Paul> which call its use in this application into question. Now that's an example of FUD!! From owner-mpls@UU.NET Wed Oct 25 14:54:31 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25421 for ; Wed, 25 Oct 2000 14:54:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmlv15208; Wed, 25 Oct 2000 18:53:44 GMT Received: by mail-control.mail.uu.net id QQjmlv27027 for mpls-outgoing; Wed, 25 Oct 2000 18:53:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmlv27022 for ; Wed, 25 Oct 2000 18:53:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlv28419 for ; Wed, 25 Oct 2000 18:52:38 GMT Received: from srnex01.sd.osicom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: srnex01.sd.osicom.com [131.143.32.21]) id QQjmlv19274 for ; Wed, 25 Oct 2000 18:52:37 GMT Received: by srnex01.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 11:43:44 -0700 Message-ID: <022A2DBC40A6D411967000D0B78892A61AB2BF@srnex01.sd.osicom.com> From: "Fu, James" To: "'erosen@cisco.com'" , Paul Doolan Cc: yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: RE: VPN solution - White flag ? Date: Wed, 25 Oct 2000 11:43:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03EB3.801064C0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03EB3.801064C0 Content-Type: text/plain; charset="iso-8859-1" I didn't realize that these are the latest innovative IETF language trend. James Fu -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Wednesday, October 25, 2000 11:43 AM To: Paul Doolan Cc: yakov@cisco.com; rnewcomb@ennovatenetowrks.com; mpls@UU.NET; diego@estos.upc.es Subject: Re: VPN solution - White flag ? I don't really want to keep it up either, but as long as misleading statements are being made I feel I have to reply. Paul> BGP ... distributes reachability information in the IDR system. We Paul> may agree or disagree on how well it scales in that application. That Paul> has little bearing on whether that property applies in this different Paul> application. Whether something scales in an extremely large environment has little bearing on whether it scales in a smaller environment? I can't imagine why anyone would make such a claim. Paul> The scalability of BGP is only one of the issues with the protocol Paul> which call its use in this application into question. Now that's an example of FUD!! ------_=_NextPart_001_01C03EB3.801064C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: VPN solution - White flag ?

I didn't realize that these are the latest innovative = IETF language trend.


James Fu 

-----Original Message-----
From: Eric Rosen [mailto:erosen@cisco.com]
Sent: Wednesday, October 25, 2000 11:43 AM
To: Paul Doolan
Cc: yakov@cisco.com; rnewcomb@ennovatenetowrks.com; = mpls@UU.NET;
diego@estos.upc.es
Subject: Re: VPN solution - White flag ?



I  don't really  want  to  keep = it  up  either, but  as  long as  = misleading
statements are being made I feel I have to reply. =

Paul> BGP ...   distributes reachability = information  in the IDR  system. We
Paul> may agree or disagree on how well it scales = in that application.  That
Paul> has little bearing on whether  that = property applies in this different
Paul> application.

Whether  something  scales in  = an  extremely  large  environment has  = little
bearing on whether it scales in  a smaller = environment?  I can't imagine why
anyone would make such a claim.

Paul> The scalability  of BGP is  only = one of  the issues with  the protocol
Paul> which call its use in this application into = question.

Now that's an example of FUD!!



------_=_NextPart_001_01C03EB3.801064C0-- From owner-mpls@UU.NET Wed Oct 25 22:31:35 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24315 for ; Wed, 25 Oct 2000 22:31:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna26278; Thu, 26 Oct 2000 02:31:10 GMT Received: by mail-control.mail.uu.net id QQjmna13257 for mpls-outgoing; Thu, 26 Oct 2000 02:30:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmna13114 for ; Thu, 26 Oct 2000 02:30:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlz23846 for ; Wed, 25 Oct 2000 19:52:04 GMT Received: from ennovatenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjmlz10583 for ; Wed, 25 Oct 2000 19:52:04 GMT Received: from ennovatenetworks.com (h0040d0042eaa.ne.mediaone.net [24.147.156.69]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id PAA14632; Wed, 25 Oct 2000 15:52:00 -0400 (EDT) (envelope-from pdoolan@ennovatenetworks.com) Message-ID: <39F73588.FD554FAD@ennovatenetworks.com> Date: Wed, 25 Oct 2000 15:33:28 -0400 From: Paul Doolan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? References: <200010251842.OAA21622@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >Paul> BGP ... distributes reachability information in the IDR system. We >Paul> may agree or disagree on how well it scales in that application. That >Paul> has little bearing on whether that property applies in this different >Paul> application. > Eric>Whether something scales in an extremely large environment has little Eric>bearing on whether it scales in a smaller environment? I can't imagine why Eric>anyone would make such a claim. Neither can I. And _again_ if you read a little more carefully you'll see that it is not what I wrote. But since you mention it I'm a little puzzled by you choosing to define (the NBVPN) as a 'smaller' environment. Lets assume the the (internet) core routers are currently handling ~60,000 routes. And there are (?) thousands of AS's. That's big. No doubt about it. A lot of routing information. In contrast your own colleagues refer to the "virtually unlimited scalability" of your VPN approach while your marketing has talked about "hundreds of thousands of VPNs". Allowing and order of magnitude for marketing hyperbole (and for the fact I can only find a reference to tens of thousands to hand :-) ) that leaves say 6 routes per VPN. Even with the paucity of routes that I postulate per VPN this hardly seems to qualify as a 'smaller' environment. And we haven't begun to think about the poor folks who are being told that they can use BGP to support VPNs while it is also performing the role for which it was designed. And they are being told this......or at least not being clearly told the opposite. pd Eric Rosen wrote: > I don't really want to keep it up either, but as long as misleading > statements are being made I feel I have to reply. > > Paul> BGP ... distributes reachability information in the IDR system. We > Paul> may agree or disagree on how well it scales in that application. That > Paul> has little bearing on whether that property applies in this different > Paul> application. > > Whether something scales in an extremely large environment has little > bearing on whether it scales in a smaller environment? I can't imagine why > anyone would make such a claim. > > Paul> The scalability of BGP is only one of the issues with the protocol > Paul> which call its use in this application into question. > > Now that's an example of FUD!! From owner-mpls@UU.NET Wed Oct 25 22:32:52 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24641 for ; Wed, 25 Oct 2000 22:32:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna00204; Thu, 26 Oct 2000 02:32:21 GMT Received: by mail-control.mail.uu.net id QQjmna13631 for mpls-outgoing; Thu, 26 Oct 2000 02:31:52 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmna13603 for ; Thu, 26 Oct 2000 02:31:44 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlz01688 for ; Wed, 25 Oct 2000 19:45:49 GMT Received: from snickers.cs.umd.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: snickers.cs.umd.edu [128.8.126.109]) id QQjmlz06430 for ; Wed, 25 Oct 2000 19:45:48 GMT Received: from localhost (localhost [127.0.0.1]) by snickers.cs.umd.edu (8.9.3/8.9.1) with ESMTP id PAA05490; Wed, 25 Oct 2000 15:45:36 -0400 (EDT) Date: Wed, 25 Oct 2000 15:45:36 -0400 (EDT) From: Rob Jaeger To: Christian Kuhtz cc: MPLS WG Subject: Re: VPN solution In-Reply-To: <20001025111543.E2109@ns1.arch.bellsouth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Christian, > > An alternative to draft-rosen-rfc2547bis is l2vpn as described in draft-kompella-mpls-l2vpn-01.txt . > > In MPLS L2VPNs, the service provider does not participate in the customer's L3 routing. This may provide better stability than L3 VPNs. > > Based on what? Why is interaction with the SP equalled with instability? Care > to explain? Based on the draft, in L2 vpn, a misbehaving CE only affects the corportate network to which it is attached whereas this CE in an L3VPN *could* cause route flaps on the PE and perhaps the SP's network. I expect service providers will use both L2 and L3 VPNs depending on the customer. You can *alternatively* use L2 or L3 for a particular customer but use BOTH within your network. Scaleability has been argued passionately from both sides so I'll wait to see what happens in SP's networks. I was only trying to offer an alternative VPN strategy in response to the query. rob From owner-mpls@UU.NET Wed Oct 25 22:33:13 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24686 for ; Wed, 25 Oct 2000 22:33:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna28526; Thu, 26 Oct 2000 02:32:35 GMT Received: by mail-control.mail.uu.net id QQjmna13660 for mpls-outgoing; Thu, 26 Oct 2000 02:31:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmna13378 for ; Thu, 26 Oct 2000 02:30:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmlx23181 for ; Wed, 25 Oct 2000 19:18:53 GMT Received: from bgslc02.TBG.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQjmlx22147 for ; Wed, 25 Oct 2000 19:18:52 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 13:02:02 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE7BAEBF9@BGSLC02> From: Irwin Lazar To: "'mpls@uu.net'" Subject: Networld Interoperabilty lab Date: Wed, 25 Oct 2000 13:02:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C03EB6.0E8F6F28" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C03EB6.0E8F6F28 Content-Type: text/plain; charset="iso-8859-1" Pardon the intrusion, but does anyone have contact information for the person who ran the MPLS interoperability lab at Networld+Interop, both in Las Vegas and Atlanta? I believe he was from a mid-western university. Thanks, Irwin ------_=_NextPart_000_01C03EB6.0E8F6F28 Content-Type: application/octet-stream; name="Irwin Lazar.vcf" Content-Disposition: attachment; filename="Irwin Lazar.vcf" BEGIN:VCARD VERSION:2.1 N:Lazar;Irwin FN:Irwin Lazar ORG:The Burton Group;Consulting TITLE:Consultant NOTE:Burton Group Staff TEL;WORK;VOICE:(703) 742-9659 TEL;CELL;VOICE:(703) 623-0713 ADR;WORK:;Sterling;45615 Willow Pond Plaza;Sterling;VA;20164;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Sterling=0D=0A45615 Willow Pond Plaza=0D=0ASterling, VA 20164=0D=0AUSA EMAIL;PREF;INTERNET:ILazar@tbg.com REV:20000918T173422Z END:VCARD ------_=_NextPart_000_01C03EB6.0E8F6F28-- From owner-mpls@UU.NET Wed Oct 25 22:33:52 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24761 for ; Wed, 25 Oct 2000 22:33:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna00080; Thu, 26 Oct 2000 02:33:30 GMT Received: by mail-control.mail.uu.net id QQjmna13658 for mpls-outgoing; Thu, 26 Oct 2000 02:31:56 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmna13604 for ; Thu, 26 Oct 2000 02:31:44 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmmh22709 for ; Wed, 25 Oct 2000 21:51:37 GMT Received: from ennovatenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjmmh29612 for ; Wed, 25 Oct 2000 21:51:37 GMT Received: from ennovatenetworks.com (h0040d0042eaa.ne.mediaone.net [24.147.156.69]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id RAA21791; Wed, 25 Oct 2000 17:51:34 -0400 (EDT) (envelope-from pdoolan@ennovatenetworks.com) Message-ID: <39F7517D.4C5762A9@ennovatenetworks.com> Date: Wed, 25 Oct 2000 17:32:45 -0400 From: Paul Doolan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? References: <200010252049.QAA21878@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Not everyone in cisco is a rogue! And its very hard to write anything down with you carping away in the background all day. When you resort to including this sort of stuff we're clearly at point where your emotions have gotten the better of you. Its a pity because the first part of your mail was relevant and valueable. So at least I've gotten something more out of you taoday than 'mailserver' war stories. pd > > > "Eric, you didn't read my message carefully, you didn't > answer my question, what you are saying makes no sense, > what you are saying is irrelevant, you don't know > anything about routing, you don't understand BGP, > everyone at cisco is a rogue, and I have a bunch of > detailed technical criticisms of your ideas but I don't > have time to write them down now." From owner-mpls@UU.NET Wed Oct 25 22:34:13 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24814 for ; Wed, 25 Oct 2000 22:34:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna24411; Thu, 26 Oct 2000 02:33:34 GMT Received: by mail-control.mail.uu.net id QQjmna13675 for mpls-outgoing; Thu, 26 Oct 2000 02:32:03 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmna13393 for ; Thu, 26 Oct 2000 02:30:55 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmmv11991 for ; Thu, 26 Oct 2000 01:29:07 GMT Received: from smtp03.mrf.mail.rcn.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp03.mrf.mail.rcn.net [207.172.4.62]) id QQjmmv09061 for ; Thu, 26 Oct 2000 01:29:07 GMT Received: from 207-172-49-214.s214.tnt7.lnhva.md.dialup.rcn.com ([207.172.49.214] helo=erols.com) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13obqo-0002bW-00 ; Wed, 25 Oct 2000 21:29:03 -0400 Message-ID: <39F788D3.1681F4AC@erols.com> Date: Wed, 25 Oct 2000 21:28:51 -0400 From: "S. Chkaravorty" X-Mailer: Mozilla 4.51 [en]C-RR032399 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Robert M Matheson , "Newcomb, Robert" , "'Juan Diego Otero'" , "'mpls@uu.net'" Subject: Re: VPN solution References: <200010251445.KAA20980@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, You echo our feelings altogether. This thread has been a zoo of ideas for a while - going nowhere. We feel this is because MPLS is perhaps one more impossible 'technology' people are trying to design for everything and it isn't working. (Remember IPv6 - had flow control and authentication and just about everything tho' the problem really was the limited addressing space - probably could have been solved by using the IP option fields and providing extensions to IPv4?) Sorry, if I offended anyone. SC **************** Eric Rosen wrote: > When someone asks a question which is of the form "which vendor has the > best product offering for some particular purpose", you can't really expect > a technical discussion to follow, but you can expect a lot of FUD. > > This thread is of that sort. All you can learn from it is that everyone has > their own favorite scheme, and you can pretty much guess which scheme > someone will like by noting which company he works for. > > You know the thread has reached the point of absurdity when people refer to > a scheme which has been widely adopted and assert that there is a "market > consensus" against it. From owner-mpls@UU.NET Wed Oct 25 22:34:55 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24906 for ; Wed, 25 Oct 2000 22:34:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna03506; Thu, 26 Oct 2000 02:34:34 GMT Received: by mail-control.mail.uu.net id QQjmna13778 for mpls-outgoing; Thu, 26 Oct 2000 02:33:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmna13750 for ; Thu, 26 Oct 2000 02:32:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmmb10484 for ; Wed, 25 Oct 2000 20:18:58 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjmmb18655 for ; Wed, 25 Oct 2000 20:18:55 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id BAA19770 for ; Thu, 26 Oct 2000 01:47:01 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id BAA27706 for ; Thu, 26 Oct 2000 01:48:52 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Thu, 26 Oct 2000 01:48:52 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: COPS doubt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk If we are using the COPS protocol in the MPLS domain , then i think the interaction betwwen PDP and all the routers of the network should be present as suppose at the PDP sys ad decided the FEC mappings to the LSPs then they should be incorporated in the backbone routers also alongwth the edge routers. Am i correct?? Thanx _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Wed, 25 Oct 2000 22:35:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna26124; Thu, 26 Oct 2000 02:34:40 GMT Received: by mail-control.mail.uu.net id QQjmna13716 for mpls-outgoing; Thu, 26 Oct 2000 02:32:20 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmna13679 for ; Thu, 26 Oct 2000 02:32:05 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmmd13147 for ; Wed, 25 Oct 2000 20:50:19 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmmd06057 for ; Wed, 25 Oct 2000 20:50:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA29168; Wed, 25 Oct 2000 13:49:44 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA21878; Wed, 25 Oct 2000 16:49:44 -0400 (EDT) Message-Id: <200010252049.QAA21878@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Paul Doolan cc: yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? In-reply-to: Your message of Wed, 25 Oct 2000 15:33:28 -0400. <39F73588.FD554FAD@ennovatenetworks.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 25 Oct 2000 16:49:44 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Paul> I'm a little puzzled by you choosing to define (the NBVPN) as a Paul> 'smaller' environment The reason I regard the NBVPN routing environment as smaller in scale than the Internet routing environment is the following. In the Internet routing environment, anyone in the world needs to be able to reach anyone else in the world. This creates an enormous "inter- connectivity matrix", and one which is constantly growing. If, through the liberal application of route aggregation, this inter-connectivity matrix can be reduced to 100,000 routes, then quite a few routers are going to have to be able to hold 100,000 routes. Since the inter-connectivity matrix is constantly growing in size, this poses an evident box scaling problem; the number of routes which a single router must hold is constantly growing. In the NBVPN routing environment, it is not true that anyone in the world needs to be able to reach anyone else in the world. Each VPN has its own inter-connectivity matrix, much smaller than the Internet connectivity matrix. Now if you add up all the VPN routes, summed over all VPNs, you may indeed get a much larger number than the number of Internet routes. But there is no one box which needs to hold them all. Since an instance of BGP runs in a particular box, and only has to deal with the routes that need to be in that box, you don't run up against the same box scaling problems you run up against in the Internet routing environment. You can design your system to have a given box handle as many routes or as few routes as you want. Now someone will say, "Wait a minute, as your customer base increases, this may require you to deploy more boxes; unscalable, unscalable". I have to admit, the scheme does not allow you to provide an unbounded amount of service in a single box. Both the growth is not exponential, geometric, factorial, or any of that really bad stuff. The growth is linear, which is about the best you can do. There are other differences between the NBVPN environment and the Internet routing environment that make the former less stressful. In the most common cases, you are not relying on routing information from independent (and perhaps uncooperative) third parties in order to provide service to your own customers. This in itself reduces the stress on the system considerably. What we really have is the application of highly scalable techniques from the world of inter-domain routing applied to a much more orderly and controllable environment. I think it does provide virtually unlimited scalability because there is nothing that will stop you from adding more, and the "more" you have to add grows at worst linearly with the additional service you need to provide. Some people shudder at the thought of having to add all the VPN routes to an already stressed out Internet routing system, but that's really not how the scheme works. You can maintain as much or as little separation as you want between the VPN routing and the Internet routing. Paul> And we haven't begun to think about the poor folks who are being told Paul> that they can use BGP to support VPNs while it is also performing the Paul> role for which it was designed. And they are being told this......or Paul> at least not being clearly told the opposite. I'm not sure I can comment on who you say is being told what by whom. As far as I know, we have always placed an emphasis on scaling the system by limiting the number of routes that need to be known in any one place, including partitioning the system of route reflectors. It's perfectly accurate to say that BGP is supporting both VPNs and Internet routing, what's not accurate is to say that it has to support all those routes in any one box. To save you the trouble of replying, let me compose a reply for you: "Eric, you didn't read my message carefully, you didn't answer my question, what you are saying makes no sense, what you are saying is irrelevant, you don't know anything about routing, you don't understand BGP, everyone at cisco is a rogue, and I have a bunch of detailed technical criticisms of your ideas but I don't have time to write them down now." From owner-mpls@UU.NET Wed Oct 25 22:36:13 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25071 for ; Wed, 25 Oct 2000 22:36:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna04922; Thu, 26 Oct 2000 02:35:24 GMT Received: by mail-control.mail.uu.net id QQjmna13786 for mpls-outgoing; Thu, 26 Oct 2000 02:33:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmna13715 for ; Thu, 26 Oct 2000 02:32:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmlw25182; Wed, 25 Oct 2000 19:11:41 GMT Received: from mail-green.research.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-30-103.research.att.com [135.207.30.103]) id QQjmlw16591; Wed, 25 Oct 2000 19:11:41 GMT Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 1D2391E03C; Wed, 25 Oct 2000 15:11:37 -0400 (EDT) Received: from pcalchiu (pclopez [135.207.131.94]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA03866; Wed, 25 Oct 2000 15:11:31 -0400 (EDT) Reply-To: From: "Angela Chiu" To: "'David Allan'" Cc: "'ip-optical'" , "'mpls'" , "'sc'" , "'xuyg'" , "'yxue'" , "'Yakov Rekhter'" Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Wed, 25 Oct 2000 15:12:55 -0400 Message-ID: <002401c03eb7$950c6a50$5e83cf87@attnjs.research.att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C03E96.0DFACA50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <6DDA62170439D31185750000F80826AC04286E83@zmerd004.ca.nortel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C03E96.0DFACA50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes >From PittsburghDave, I agree with you that jointly routing the primary and backup paths may seem to be more optimal locally in a distributed routing environment, it may not be more optimal globally. I think the real issue is not which one is more optimal for Kireeti's example, as I described in my previous email, routing a new lightpath that is diverse from some existing lightpaths is a general requirement. It needs to be supported no matter which model providers choose, e.g., overlay, peer, or others. Regards, Angela -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, October 25, 2000 1:56 PM To: alchiu; 'Yakov Rekhter' Cc: ip-optical; mpls; sc; xuyg; yxue Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Angela: Jointly routing the paths intuitively does not strike me as optimal. Not unless we are periodically performing path maintenance on the entire set of network resources. I would have to assume that the overall configuration of the network occurred incrementally, and with a desire to minimize service interruption of the already established paths. With that in mind, I would assume the routing of the primary path should always be chosen as the optimal route. The backup path is then required to be diverse (node, fiber, conduit, trench) with the optimal primary path and would frequently be less optimal as the physical routing would frequently be in the form of a longer path. I do not understand how whether this is done sequentially or simultaneously affects these basics, except in the possible deadlock scenario where the optimal routing of the primary path precludes a viable backup. In the meantime, I would assume sequential establishment of primary then backup would stand an overall greater chance of success, especially if the path computing node does not have a comprehensive and authoritative view of the network state. It strikes me that routing the backup should have the ability to intelligently crank back with knowledge of what to avoid to maintain diversity with the primary path. regards Dave -----Original Message----- From: Angela Chiu [SMTP:alchiu@research.att.com] Sent: Wednesday, October 25, 2000 10:03 AM To: 'Yakov Rekhter' Cc: ip-optical; mpls; sc; xuyg; yxue Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Yakov, Yes, you are right. Routing the primary and backup paths jointly is always more optimal than fixing the path for primary first then routing the backup accordingly. The same argument can be applied to comparing centralized routing with distributed routing. Even distributed routing is less optimal, it is the trend today. I think the real issue is at what cost the additional optimality is gained, and how much the additional optimality is in a typical network setting. In this case the cost is all the topological information including SRLG information as well as physical impairment constraints in the optical network that routers need to obtain in order to make proper routing decision. I have an idea, this will be a valid master/PhD thesis for some graduate students who would like to work on real world problems. Regards, Angela -----Original Message----- From: ip-optical-admin@lists.bell-labs.com [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Yakov Rekhter Sent: Wednesday, October 25, 2000 7:35 AM To: alchiu@research.att.com Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Angela, > Some followup discussions in line. more in line... > Regards, > Angela > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Kireeti > Kompella > Sent: Monday, October 23, 2000 1:58 PM > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; yxue@UU.NET > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > > I don't see why TE and protection require the routers to specify explicit > > routes. > > The routers can simply specify to the optical layer what type of optical > > layer protection > > it requires. > > Suppose router A wants to get to router B, and wants to take two > different ingress and egress points in the optical domain, X->Y > for the primary LSP, and W->Z for the backup. A does not require > optical protection for the X->Y path, nor for the W->Z path. A > *does* require that the X->Y path and the W->Z path do not share > common links. How is this to be done? > > If A did the full path computation, this is simplicity itself. > > [AC] I think you have a good point here. I also heard the same kind if > reasoning (i.e., have a layer-3 like protection switching) for supporting > the peer model. But after discussing with others, it seems that overlay > model should be able to provide the same capability. Not really... for more on this see below... > Normally, the primary > LSP X->Y is set up first, and becomes a forwarding adjacency (FA) according > to your LSP Hierarchy draft. Then the associated information of the FA X->Y > including its exact path and SRLG information should be propagated via IGP > extensions, same as with any other link in the network. Thus if router A > sends a request to OXC W to set up a backup lightpath from W->Z to be > diversely router from the existing FA X->Y, OXC W should already have the > right information to perform proper routing. It is a known fact that for computing disjoint paths the approach you outlined above may result in a situation where no backup path will be found, despite the fact that that it is possible (using some other approach) to find two disjoint paths. > Comparing with the peer model solution where routers need to know all the > SRLG information of the optical domain as well as all relevant physical > impairments in the optical signal in the case of transparent optical > network, it is still not clear to me which one is simpler. > > I think it is very good to have this kind of technical discussion openly on > the list. Hope others can provide more technical and business (after all > carriers need to pay for these features) evidences for the need of each > model. Some other reasoning I heard includes that peer model can improve the > IGP scalability in terms of the number of neighbors a router needs to peer > with. But since large ISPs today seem to cope well with the IGP scalability > today, I don't see why the problem will get significant worst when optical > networks come into play. In the end it is not the discussion on this list, but the competition in the marketplace that will determine the viability of different models. Yakov. _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical ------=_NextPart_000_0025_01C03E96.0DFACA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes = >From Pittsburgh
Dave,
 
I=20 agree with you that jointly routing the primary and backup paths may = seem to be=20 more optimal locally in a distributed routing environment, it may not be = more=20 optimal globally.
 
I=20 think the real issue is not which one is more optimal for Kireeti's = example, as I described in my previous email, routing a new lightpath = that is=20 diverse from some existing lightpaths is a general requirement. It needs = to be=20 supported no matter which model providers choose, e.g., overlay, peer, = or=20 others.
 
Regards,
Angela
-----Original Message-----
From: David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, October = 25, 2000=20 1:56 PM
To: alchiu; 'Yakov Rekhter'
Cc: = ip-optical; mpls;=20 sc; xuyg; yxue
Subject: RE: [IP-Optical] RE: Optical link = bundling.=20 Was Re: DraftMinutes From Pittsburgh

Angela:

Jointly routing the = paths intuitively=20 does not strike me as optimal. Not unless we are periodically = performing path=20 maintenance on the entire set of network resources. I would have to = assume=20 that the overall configuration of the network occurred incrementally, = and with=20 a desire to minimize service interruption of the already established = paths.=20

With that in mind, I = would assume the=20 routing of the primary path should always be chosen as the optimal = route. The=20 backup path is then required to be diverse (node, fiber, conduit, = trench) with=20 the optimal primary path and would frequently be less optimal as the = physical=20 routing would frequently be in the form of a longer path.

I do not understand how = whether this=20 is done sequentially or simultaneously affects these basics, except in = the=20 possible deadlock scenario where the optimal routing of the primary = path=20 precludes a viable backup. In the meantime, I would assume sequential=20 establishment of primary then backup would stand an overall greater = chance of=20 success, especially if the path computing node does not have a = comprehensive=20 and authoritative view of the network state. It strikes me that = routing the=20 backup should have the ability to intelligently crank back with = knowledge of=20 what to avoid to maintain diversity with the primary path.

regards =
Dave

    -----Original Message----- =
    From:   Angela Chiu [SMTP:alchiu@research.att.com] =
    Sent:   Wednesday, October 25, 2000 10:03 AM
    To:     'Yakov=20 Rekhter'
    Cc:     ip-optical; mpls; sc; xuyg; yxue
    Subject:        = RE: [IP-Optical] RE: Optical link bundling. = Was Re:=20 DraftMinutes From  Pittsburgh

    Yakov,

    Yes, you are right. Routing the = primary and=20 backup paths jointly is always
    more=20 optimal than fixing the path for primary first then routing the=20 backup
    accordingly. The same = argument can=20 be applied to comparing centralized
    routing with distributed routing. Even distributed routing = is less=20 optimal,
    it is the trend = today. I think=20 the real issue is at what cost the additional
    optimality is gained, and how much the additional = optimality is in a=20 typical
    network setting. In = this case the=20 cost is all the topological information
    including SRLG information as well as physical impairment = constraints=20 in the
    optical network that = routers need=20 to obtain in order to make proper routing
    decision.

    I have an idea, this will be a valid = master/PhD=20 thesis for some graduate
    students who=20 would like to work on real world problems.

    Regards,

    Angela

    -----Original Message----- =
    From: = ip-optical-admin@lists.bell-labs.com=20
    [mailto:ip-optical-ad= min@lists.bell-labs.com]On Behalf Of Yakov Rekhter
    Sent: Wednesday, October 25, 2000 7:35 AM
    To: alchiu@research.att.com
    Cc:=20 ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com;=20
    xuyg@lucent.com; yxue@UU.NET =
    Subject: Re: [IP-Optical] RE: Optical link = bundling. Was=20 Re:
    DraftMinutes From = Pittsburgh=20


    Angela,

    > Some followup discussions in = line.=20

    more in line...

    > Regards,
    > Angela
    >
    > -----Original Message----- =
    > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On<= /U> Behalf Of Kireeti
    >=20 Kompella
    > Sent: Monday, = October 23,=20 2000 1:58 PM
    > To:=20 kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; = yxue@UU.NET=20
    > Cc: = ip-optical@lists.bell-labs.com;=20 mpls@UU.NET
    > Subject: RE: = [IP-Optical] RE: Optical link bundling. Was Re:
    > DraftMinutes From Pittsburgh
    >
    > =
    > > I don't see why TE and protection = require the=20 routers to specify
    explicit=20
    > > routes.
    > > The routers can simply specify to the optical = layer what=20 type of optical
    > > = layer=20 protection
    > > it = requires.=20
    >
    >=20 Suppose router A wants to get to router B, and wants to take = two=20
    > different ingress and egress = points in the=20 optical domain, X->Y
    > = for the=20 primary LSP, and W->Z for the backup.  A does not = require=20
    > optical protection for the = X->Y path,=20 nor for the W->Z path.  A
    >=20 *does* require that the X->Y path and the W->Z path do not=20 share
    > common = links.  How is=20 this to be done?
    > =
    > If A did the full path computation, this = is=20 simplicity itself.
    >
    > [AC] I think you have a good point here. = I also heard=20 the same kind if
    > = reasoning (i.e.,=20 have a layer-3 like protection switching) for supporting =
    > the peer model. But after discussing with = others, it=20 seems that overlay
    > model = should be=20 able to provide the same capability.

    Not really... for more on this see=20 below...

    > Normally, the primary =
    > LSP X->Y is set up first, and becomes = a forwarding=20 adjacency (FA)
    according
    > to your LSP Hierarchy draft. Then the = associated=20 information of the FA
    X->Y=20
    > including its exact path and = SRLG=20 information should be propagated via IGP
    > extensions, same as with any other link in the = network. Thus if=20 router A
    > sends a request = to OXC W to=20 set up a backup lightpath from W->Z to be
    > diversely router from the existing FA X->Y, OXC W = should=20 already have the
    > right = information=20 to perform proper routing.

    It is a known fact that for computing = disjoint=20 paths the approach
    you = outlined above may=20 result in a situation where no backup
    path will be found, despite the fact that that it is = possible=20
    (using some other approach) to find = two disjoint=20 paths.

    > Comparing with the peer model = solution where=20 routers need to know all the
    > SRLG=20 information of the optical domain as well as all relevant = physical=20
    > impairments in the optical = signal in the=20 case of transparent optical
    > network,=20 it is still not clear to me which one is simpler.
    >
    > I think it is=20 very good to have this kind of technical discussion openly =
    on
    > = the list. Hope=20 others can provide more technical and business (after all =
    > carriers need to pay for these features) = evidences=20 for the need of each
    > = model. Some=20 other reasoning I heard includes that peer model can improve=20
    the
    > IGP=20 scalability in terms of the number of neighbors a router needs to=20 peer
    > with. But since = large ISPs=20 today seem to cope well with the IGP
    scalability
    > = today, I don't=20 see why the problem will get significant worst when optical =
    > networks come into play.

    In the end it is not the discussion = on this list,=20 but the competition
    in the = marketplace=20 that will determine the viability of different
    models.

    Yakov.

    _______________________________________________ =
    IP-Optical mailing list
    IP-Optical@lists.bell-labs.com
    http://lists.bell-labs.com/mailman/listinfo/ip-optical=20

------=_NextPart_000_0025_01C03E96.0DFACA50-- From owner-mpls@UU.NET Wed Oct 25 22:36:24 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25096 for ; Wed, 25 Oct 2000 22:36:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna04038; Thu, 26 Oct 2000 02:36:07 GMT Received: by mail-control.mail.uu.net id QQjmna13887 for mpls-outgoing; Thu, 26 Oct 2000 02:34:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmna13843 for ; Thu, 26 Oct 2000 02:33:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmna27794 for ; Thu, 26 Oct 2000 02:33:17 GMT Received: from NOD.RESTON.MCI.NET by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nod.reston.mci.net [166.60.6.38]) id QQjmna29665 for ; Thu, 26 Oct 2000 02:33:17 GMT Received: from rbonica ([166.60.18.132]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JVRQZS7A3G9LVIIV@shoe.reston.mci.net> for mpls@UU.NET; Wed, 25 Oct 2000 22:33:16 EST Date: Wed, 25 Oct 2000 22:27:04 -0400 From: Ron Bonica Subject: RE: Two orthogonal issue In-reply-to: <200010250243.TAA07887@kummer.juniper.net> To: Kireeti Kompella , mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT > > Absolutely. A lot of folks don't seem to get this point: for > example, one could have OXCs and *some* routers in the backbone > area; other routers in non-backbone areas, and yet other clients > (routers, ADMs, ...) accessing the same OXCs via the UNI. And > one could run NMS systems as well for provisioning legacy boxes. > If the client IP network were to used MPLS signaling to obtain services from the optical transport network, and if the optical transport network were clever about enforcing a configurable admission control policy, would there be any need for a UNI? Couldn't the admission control policy restrict client networks to services that they might otherwise have obtained through the UNI? From owner-mpls@UU.NET Wed Oct 25 22:37:08 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25191 for ; Wed, 25 Oct 2000 22:37:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna28889; Thu, 26 Oct 2000 02:36:31 GMT Received: by mail-control.mail.uu.net id QQjmna14040 for mpls-outgoing; Thu, 26 Oct 2000 02:35:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmna14010 for ; Thu, 26 Oct 2000 02:35:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmmh25228 for ; Wed, 25 Oct 2000 21:46:20 GMT Received: from baynet.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20]) id QQjmmh21336 for ; Wed, 25 Oct 2000 21:46:19 GMT Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id OAA14962 for ; Wed, 25 Oct 2000 14:44:44 -0700 (PDT) Received: from shasta-exch.shastanets.com (mailserver.shastanets.com [47.82.16.150]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id OAA04019 for ; Wed, 25 Oct 2000 14:44:43 -0700 (PDT) Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 14:44:07 -0700 Message-ID: <940E42DB5D7FD4119C420004ACE6E0A09D78EC@mailserver.shastanets.com> From: Suresh Boddapati To: "'mpls@uu.net'" Subject: VPN IPV4 Address Format Date: Wed, 25 Oct 2000 14:44:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk 2547.bis section 4.1 defines the VPN-IPV4 Address Family and the address is defined to be "a 12 byte quantity, beginning with an 8-byte Route Distinguisher and ending with a 4-byte IPv4 Address". Where is the prefix length (mask length) carried? Thanks. Regards, Suresh From owner-mpls@UU.NET Wed Oct 25 22:37:26 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25231 for ; Wed, 25 Oct 2000 22:37:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna07386; Thu, 26 Oct 2000 02:37:04 GMT Received: by mail-control.mail.uu.net id QQjmna14043 for mpls-outgoing; Thu, 26 Oct 2000 02:35:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmna13990 for ; Thu, 26 Oct 2000 02:34:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmmf24896 for ; Wed, 25 Oct 2000 21:17:09 GMT Received: from icarian.ZAFFIRE.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjmmf08757 for ; Wed, 25 Oct 2000 21:17:08 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <48XXFNVF>; Wed, 25 Oct 2000 14:18:04 -0700 Message-ID: <4611AD058694D4118FD5009027B0A66273A7BB@ICARIAN> From: Paul Joseph To: "'Randy Bush'" , Eric Rosen Cc: "'mpls@uu.net'" Subject: RE: VPN solution Date: Wed, 25 Oct 2000 14:17:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, October 25, 2000 11:26 AM > To: Eric Rosen > Cc: 'mpls@uu.net' > Subject: Re: VPN solution > i just operate a network. i wouldn't touch 2547[bis] with a > bargepole. it > will not scale, will eat massive hardware, which i imagine > is why uyou like > it, and will make a fool of anyone who deploys it in large > quantities. > And that is your evaluation of some major customers who have deployment experience with it and are solving problems associated with earlier VPNs ? > as mo says, i wish all my competitors would use it. > How widely deployed is your VPN strategy ? What problems is it solving ? Paul > randy > From owner-mpls@UU.NET Wed Oct 25 22:38:29 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25383 for ; Wed, 25 Oct 2000 22:38:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna01006; Thu, 26 Oct 2000 02:37:54 GMT Received: by mail-control.mail.uu.net id QQjmna14050 for mpls-outgoing; Thu, 26 Oct 2000 02:35:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmna13896 for ; Thu, 26 Oct 2000 02:34:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmna00495 for ; Thu, 26 Oct 2000 02:31:56 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmna21940 for ; Thu, 26 Oct 2000 02:31:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA00916 for mpls@uu.net; Wed, 25 Oct 2000 22:31:54 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmna13337 for ; Thu, 26 Oct 2000 02:30:32 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmmg23684 for ; Wed, 25 Oct 2000 21:33:19 GMT Received: from aurms0.aur.alcatel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hostr41.alcatel.com [143.209.4.1]) id QQjmmg00206 for ; Wed, 25 Oct 2000 21:33:18 GMT Received: from aurmsa.aur.alcatel.com (aurmsa [143.209.7.230]) by aurms0.aur.alcatel.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA22556; Wed, 25 Oct 2000 17:33:17 -0400 (EDT) Received: from aurmsa.aur.alcatel.com (localhost [127.0.0.1]) by aurmsa.aur.alcatel.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9PLXIU24868; Wed, 25 Oct 2000 17:33:18 -0400 (EDT) Received: from usa.alcatel.com ([143.209.22.94]) by aurmsa.aur.alcatel.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e9PLXIl24864; Wed, 25 Oct 2000 17:33:18 -0400 (EDT) Message-ID: <39F752D6.9CBEEEEA@usa.alcatel.com> Date: Wed, 25 Oct 2000 17:38:30 -0400 From: Manal Afify Organization: Alcatel USA, Inc. X-Sender: "Manal Afify" <@relay.aur.alcatel.com> X-Mailer: Mozilla 4.73 [en]C-CCK-MCD office (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit As a general question: How does an LSR know when to swap, pop, or push a label...does it have to be provisioned? Thanx MA From owner-mpls@UU.NET Wed Oct 25 22:38:33 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25394 for ; Wed, 25 Oct 2000 22:38:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna08845; Thu, 26 Oct 2000 02:37:56 GMT Received: by mail-control.mail.uu.net id QQjmna14053 for mpls-outgoing; Thu, 26 Oct 2000 02:35:40 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmna13937 for ; Thu, 26 Oct 2000 02:34:35 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlx07198 for ; Wed, 25 Oct 2000 19:29:20 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmlx12278 for ; Wed, 25 Oct 2000 19:29:20 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA21613; Wed, 25 Oct 2000 12:29:18 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA21731; Wed, 25 Oct 2000 15:29:18 -0400 (EDT) Message-Id: <200010251929.PAA21731@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Randy Bush cc: "'mpls@uu.net'" Subject: Re: VPN solution In-reply-to: Your message of Wed, 25 Oct 2000 11:25:33 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 25 Oct 2000 15:29:17 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Randy> i am sure it's widely deployed within cisco Cisco is not a service provider. "Widely adopted", in this context, means deployed or being deployed by a significant number of service providers. No, I won't furnish the number, you can either believe me or not. Randy> i just operate a network. I don't mean to make light of your experience in this area, but I can tell you that many others who operate networks do not share your conclusions. That doesn't mean you are wrong or right, it just means that operating a network doesn't make one omniscient. Randy> it ... will eat massive hardware, which i imagine is why you like it I think the best way for a vendor to make money is by providing good business solutions. Deliberately advocating a bad business solution as a way of selling hardware would be counter-productive, imho, and is not something I would do. From owner-mpls@UU.NET Wed Oct 25 22:41:36 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25811 for ; Wed, 25 Oct 2000 22:41:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmna05698; Thu, 26 Oct 2000 02:41:15 GMT Received: by mail-control.mail.uu.net id QQjmna14440 for mpls-outgoing; Thu, 26 Oct 2000 02:40:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmna14415 for ; Thu, 26 Oct 2000 02:40:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmna12771 for ; Thu, 26 Oct 2000 02:39:10 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmna10782 for ; Thu, 26 Oct 2000 02:39:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA03304 for mpls@uu.net; Wed, 25 Oct 2000 22:39:08 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmna14039 for ; Thu, 26 Oct 2000 02:35:27 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmme09930 for ; Wed, 25 Oct 2000 21:07:31 GMT Received: from no-worries.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: no-worries.cisco.com [144.254.148.250]) id QQjmme25556 for ; Wed, 25 Oct 2000 21:07:28 GMT Received: from DAPATTERLAPTOP (dapatter-isdn1.cisco.com [171.70.160.89]) by no-worries.cisco.com (8.8.8+Sun/8.8.8) with SMTP id IAA08338 for ; Thu, 26 Oct 2000 08:07:24 +1100 (EST) From: "Darren Patterson" To: Subject: re: draft-kompella-mpls-l2vpn-00.txt Date: Thu, 26 Oct 2000 05:02:57 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit how do we plan to support aal1 / aal2 synchronous cell streams in this draft? regards From owner-mpls@UU.NET Wed Oct 25 22:59:36 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27789 for ; Wed, 25 Oct 2000 22:59:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmnb03153; Thu, 26 Oct 2000 02:59:19 GMT Received: by mail-control.mail.uu.net id QQjmnb15533 for mpls-outgoing; Thu, 26 Oct 2000 02:58:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmnb15527 for ; Thu, 26 Oct 2000 02:58:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmnb03413 for ; Thu, 26 Oct 2000 02:56:24 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmnb29374 for ; Thu, 26 Oct 2000 02:56:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA07051 for mpls@uu.net; Wed, 25 Oct 2000 22:56:22 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmnb15413 for ; Thu, 26 Oct 2000 02:56:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmnb19595 for ; Thu, 26 Oct 2000 02:51:03 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmnb22921 for ; Thu, 26 Oct 2000 02:51:02 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA16849; Wed, 25 Oct 2000 19:51:01 -0700 (PDT) Message-Id: <200010260251.TAA16849@omega.cisco.com> To: Kireeti Kompella cc: mpls@UU.NET, rbonica@mci.net Subject: Re: Two orthogonal issue In-reply-to: Your message of "Tue, 24 Oct 2000 19:43:46 PDT." <200010250243.TAA07887@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16847.972528661.1@cisco.com> Date: Wed, 25 Oct 2000 19:51:01 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, [clipped...] > One thing that has come out of this debate is that carriers are > thinking more deeply about requirements, which is a welcome step > forward. At the same time, several deep-rooted biases are being > exposed, and I'll be the first to admit my bias towards using > MPLS/GMPLS for the control plane. There are fairly pragmatic reasons for using MPLS/GMPLS for the control plane - for more on this folks may read draft-awduche-mpls-te-optical-02.txt. Yakov. From owner-mpls@UU.NET Wed Oct 25 23:05:29 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28480 for ; Wed, 25 Oct 2000 23:05:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmnc05939; Thu, 26 Oct 2000 03:05:11 GMT Received: by mail-control.mail.uu.net id QQjmnc27255 for mpls-outgoing; Thu, 26 Oct 2000 03:04:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmnc27247 for ; Thu, 26 Oct 2000 03:04:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmnc15248 for ; Thu, 26 Oct 2000 03:03:02 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmnc08048 for ; Thu, 26 Oct 2000 03:03:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA09049 for mpls@uu.net; Wed, 25 Oct 2000 23:03:01 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmnc23463 for ; Thu, 26 Oct 2000 03:02:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmnc17525 for ; Thu, 26 Oct 2000 03:01:23 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmnc05984 for ; Thu, 26 Oct 2000 03:01:22 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA17316; Wed, 25 Oct 2000 20:00:51 -0700 (PDT) Message-Id: <200010260300.UAA17316@omega.cisco.com> To: Suresh Boddapati cc: "'mpls@uu.net'" Subject: Re: VPN IPV4 Address Format In-reply-to: Your message of "Wed, 25 Oct 2000 14:44:06 PDT." <940E42DB5D7FD4119C420004ACE6E0A09D78EC@mailserver.shastanets.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17314.972529251.1@cisco.com> Date: Wed, 25 Oct 2000 20:00:51 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Suresh, > 2547.bis section 4.1 defines the VPN-IPV4 Address Family and the address is > defined to be "a 12 byte quantity, beginning with an 8-byte Route > Distinguisher and ending with a 4-byte IPv4 Address". Where is the prefix > length (mask length) carried? As part of the BGP Multi-Protocol Extension attribute. Yakov. From owner-mpls@UU.NET Wed Oct 25 23:07:30 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28701 for ; Wed, 25 Oct 2000 23:07:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmnc08374; Thu, 26 Oct 2000 03:06:51 GMT Received: by mail-control.mail.uu.net id QQjmnc27439 for mpls-outgoing; Thu, 26 Oct 2000 03:06:33 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmnc27434 for ; Thu, 26 Oct 2000 03:06:31 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmnc12179 for ; Thu, 26 Oct 2000 03:06:30 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmnc07799 for ; Thu, 26 Oct 2000 03:06:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA09467 for mpls@uu.net; Wed, 25 Oct 2000 23:06:28 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmna13711 for ; Thu, 26 Oct 2000 02:32:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmlw25389 for ; Wed, 25 Oct 2000 19:11:45 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmlw16223 for ; Wed, 25 Oct 2000 19:11:44 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA27868; Wed, 25 Oct 2000 12:11:09 -0700 (PDT) Message-Id: <200010251911.MAA27868@omega.cisco.com> To: Randy Bush cc: "'mpls@uu.net'" Subject: Re: VPN solution In-reply-to: Your message of "Wed, 25 Oct 2000 11:25:33 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27866.972501069.1@cisco.com> Date: Wed, 25 Oct 2000 12:11:09 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk > > No, sometimes it's just necessary to call 'em like I see 'em. > > all depends on what glasses one wears, i guess. Yes, indeed. Including the glasses you wear... Yakov. From owner-mpls@UU.NET Wed Oct 25 23:55:48 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04500 for ; Wed, 25 Oct 2000 23:55:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmnf07698; Thu, 26 Oct 2000 03:55:06 GMT Received: by mail-control.mail.uu.net id QQjmnf00472 for mpls-outgoing; Thu, 26 Oct 2000 03:54:34 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmnf00467 for ; Thu, 26 Oct 2000 03:54:26 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmnf02633 for ; Thu, 26 Oct 2000 03:54:04 GMT Received: from mail1.doit.wisc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.doit.wisc.edu [144.92.9.40]) id QQjmnf10946 for ; Thu, 26 Oct 2000 03:54:03 GMT Received: from [128.104.54.180] by mail1.doit.wisc.edu id WAA208862 (8.9.1/50); Wed, 25 Oct 2000 22:53:50 -0500 Message-Id: <5.0.0.25.2.20001025224916.023ba690@facstaff.wisc.edu> X-Sender: wejensen@facstaff.wisc.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 25 Oct 2000 22:53:47 -0500 To: Irwin Lazar From: Bill Jensen Subject: Re: Networld Interoperabilty lab Cc: "'mpls@uu.net'" In-Reply-To: <0C875DC28791D21192CD00104B95BFE7BAEBF9@BGSLC02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Irwin, I think you are referring to me. Please feel free to contact me directly. Sorry for the reply to the list - I'm just trying to curb the potential of multiple responses that may come from other folks. -wej At 01:02 PM 10/25/00 -0600, Irwin Lazar wrote: >Pardon the intrusion, but does anyone have contact information for the >person who ran the MPLS interoperability lab at Networld+Interop, both in >Las Vegas and Atlanta? I believe he was from a mid-western university. > >Thanks, >Irwin > > Bill Jensen, UW-Madison DoIT Network Engineering 1210 W. Dayton St., Madison, WI 53706 voice: 608-263-9325 efax: 413-208-1297 email: wej@doit.wisc.edu cell: 608-576-8345 pager: 608-275-9513 alpha: wej@page.doit.wisc.edu From owner-mpls@UU.NET Thu Oct 26 00:02:49 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05264 for ; Thu, 26 Oct 2000 00:02:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmng25500; Thu, 26 Oct 2000 04:02:15 GMT Received: by mail-control.mail.uu.net id QQjmng07335 for mpls-outgoing; Thu, 26 Oct 2000 04:01:56 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmng07328 for ; Thu, 26 Oct 2000 04:01:46 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmng20134 for ; Thu, 26 Oct 2000 04:01:42 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjmng16076 for ; Thu, 26 Oct 2000 04:01:39 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id JAA06249; Thu, 26 Oct 2000 09:29:45 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id JAA32026; Thu, 26 Oct 2000 09:31:36 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Thu, 26 Oct 2000 09:31:36 +0530 (IST) From: Ramanjaneyulu Y T To: Manal Afify cc: mpls@UU.NET Subject: Re: Question In-Reply-To: <39F752D6.9CBEEEEA@usa.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk hi, Each LSR maintains table , when LSR recieves MPLS packet it conatins incoming label, which indexed into table. The table conatils next outgoing label and operations performed on incoimg label .So while binding labels only one has to take care of operation. On Wed, 25 Oct 2000, Manal Afify wrote: > As a general question: > > How does an LSR know when to swap, pop, or push a label...does it have > to be provisioned? > > Thanx > > MA > From owner-mpls@UU.NET Thu Oct 26 01:09:02 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18777 for ; Thu, 26 Oct 2000 01:09:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmnk08474; Thu, 26 Oct 2000 05:08:32 GMT Received: by mail-control.mail.uu.net id QQjmnk27351 for mpls-outgoing; Thu, 26 Oct 2000 05:08:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmnk27338 for ; Thu, 26 Oct 2000 05:07:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmnk26933 for ; Thu, 26 Oct 2000 05:07:46 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmnk07439 for ; Thu, 26 Oct 2000 05:07:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA20904 for mpls@uu.net; Thu, 26 Oct 2000 01:07:45 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmnk27275 for ; Thu, 26 Oct 2000 05:07:27 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmnk27127 for ; Thu, 26 Oct 2000 05:04:20 GMT Received: from mail1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.cisco.com [171.68.225.60]) id QQjmnk11741 for ; Thu, 26 Oct 2000 05:04:20 GMT Received: from jsauviacpc2 (jsauviac-isdn3.cisco.com [10.21.1.44]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id WAA00284 for ; Wed, 25 Oct 2000 22:04:18 -0700 (PDT) From: "Jason Sauviac" To: Subject: UNSUBSCRIBE Date: Wed, 25 Oct 2000 23:00:46 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200010260251.TAA16849@omega.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit UNSUBSCRIBE From owner-mpls@UU.NET Thu Oct 26 01:26:41 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27415 for ; Thu, 26 Oct 2000 01:26:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmnl00430; Thu, 26 Oct 2000 05:26:08 GMT Received: by mail-control.mail.uu.net id QQjmnl28592 for mpls-outgoing; Thu, 26 Oct 2000 05:25:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmnl28587 for ; Thu, 26 Oct 2000 05:25:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmnl13147 for ; Thu, 26 Oct 2000 05:25:26 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmnl29433 for ; Thu, 26 Oct 2000 05:25:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA22059 for mpls@uu.net; Thu, 26 Oct 2000 01:25:25 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmnl28572 for ; Thu, 26 Oct 2000 05:25:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmnl04021 for ; Thu, 26 Oct 2000 05:24:33 GMT Received: from ns01.newbridge.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns01.newbridge.com [192.75.23.67]) id QQjmnl07526 for ; Thu, 26 Oct 2000 05:24:33 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id BAA19469 for ; Thu, 26 Oct 2000 01:16:32 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA0DyZgO; Thu Oct 26 01:16:26 2000 Received: from hkmail01.ap.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@uu.net; Thu, 26 Oct 2000 01:22:55 -0400 Received: from alcatel.com ([138.120.193.45]) by hkmail01.ap.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA63C6 for ; Thu, 26 Oct 2000 13:22:52 +0800 Message-Id: <39F7BB13.EF77E357@alcatel.com> Date: Thu, 26 Oct 2000 13:03:15 +0800 From: "ABDUL RAZAQUE" Reply-To: abdul.razaque@alcatel.com X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: unsubscribe Content-Type: multipart/mixed; boundary="------------E2767A34BCC81F749BC0AB91" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------E2767A34BCC81F749BC0AB91 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe --------------E2767A34BCC81F749BC0AB91 Content-Type: text/x-vcard; charset=us-ascii; name="abdul.razaque.vcf" Content-Description: Card for Abdul Razaque Memon Content-Disposition: attachment; filename="abdul.razaque.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:RAZAQUE;MEMON ABDUL tel;fax:+852-28072570 tel;work:+852-21048335 x-mozilla-html:FALSE url:http://www.cid.alcatel.com org:Learning services APR;Alcatel Carrier Internetworking Division adr:;;;HONG KONG;;; version:2.1 email;internet:abdul.razaque@alcatel.com title:Manager Customer Learning x-mozilla-cpt:;-24784 fn:ABDUL RAZAQUE end:vcard --------------E2767A34BCC81F749BC0AB91-- From owner-mpls@UU.NET Thu Oct 26 03:11:06 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13326 for ; Thu, 26 Oct 2000 03:11:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmns12747; Thu, 26 Oct 2000 07:10:26 GMT Received: by mail-control.mail.uu.net id QQjmns27110 for mpls-outgoing; Thu, 26 Oct 2000 07:10:02 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmns27082 for ; Thu, 26 Oct 2000 07:09:54 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmns06417 for ; Thu, 26 Oct 2000 07:05:11 GMT Received: from albatross-ext.wise.edt.ericsson.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116]) id QQjmns01364 for ; Thu, 26 Oct 2000 07:05:10 GMT Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e9Q759t13728 for ; Thu, 26 Oct 2000 09:05:09 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Thu Oct 26 09:05:09 2000 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <4Z87SKL6>; Thu, 26 Oct 2000 09:05:07 +0200 Message-ID: <1367DA832A24D311A95C0008C791C770060C6098@eitrmnt100.tei.ericsson.se> From: "Eleonora Manconi (TEI)" To: "'mpls@UU.NET'" Subject: draft-ietf-mpls-diff-ext-07.txt Date: Thu, 26 Oct 2000 09:05:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I have some question about draft-ietf-mpls-diff-ext-07.txt: -in E-LSP method, PSC is inferred from EXP field. The question is: PSC means only priority or I can infer also other information like loss, delay, etc. from EXP field? Are these information meaningful for MPLS? -In which kind of scenarios it is (does it is?) meaningful the coexistence of L-LSP and E-LSP? Thank you in advance. Eleonora. From owner-mpls@UU.NET Thu Oct 26 05:17:17 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22302 for ; Thu, 26 Oct 2000 05:17:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmob17707; Thu, 26 Oct 2000 09:16:24 GMT Received: by mail-control.mail.uu.net id QQjmob27624 for mpls-outgoing; Thu, 26 Oct 2000 09:15:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmob27619 for ; Thu, 26 Oct 2000 09:15:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmoa16935 for ; Thu, 26 Oct 2000 09:14:03 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjmoa18425 for ; Thu, 26 Oct 2000 09:14:00 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA24535; Thu, 26 Oct 2000 14:42:01 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id OAA29289; Thu, 26 Oct 2000 14:43:53 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Thu, 26 Oct 2000 14:43:53 +0530 (IST) From: Gaitonde Anandprasanna Reply-To: Gaitonde Anandprasanna To: rsvp@isi.edu, mpls@UU.NET Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have the follwoing doubt about RSVP & RSVP-TE . On the edge router of an MPLS domain , the signalling mechanism should be able to identify and proceess both RSVP messages aswell as RSVP-TE messages . How to handle this. Does RSVP-TE handle RSVP messages ? Or should there be a rsvp desmon running on the edge router as well as rsvp-te deamon running. Also i wanted to know one thing. RSVP protocol is identified by protocol no 46 . How will be RSVP-TE protocol identified by IP layer. Please let me know. Thanx in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Thu, 26 Oct 2000 05:24:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmob00299; Thu, 26 Oct 2000 09:23:22 GMT Received: by mail-control.mail.uu.net id QQjmob28092 for mpls-outgoing; Thu, 26 Oct 2000 09:23:02 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmob28087 for ; Thu, 26 Oct 2000 09:22:57 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmob25094 for ; Thu, 26 Oct 2000 09:20:11 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjmob26177 for ; Thu, 26 Oct 2000 09:20:08 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id OAA25414 for ; Thu, 26 Oct 2000 14:48:13 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id OAA29316 for ; Thu, 26 Oct 2000 14:50:05 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Thu, 26 Oct 2000 14:50:05 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: COPS query Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have the following question: Is the communication between PDP and the core LSRS required or only with edge routers in an MPLs domain. If required with core routers also then what kind of interaction is required?? Please explain Thankx in advance Prasanna _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Thu, 26 Oct 2000 06:31:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmog13388; Thu, 26 Oct 2000 10:31:15 GMT Received: by mail-control.mail.uu.net id QQjmog13562 for mpls-outgoing; Thu, 26 Oct 2000 10:30:57 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmog13527 for ; Thu, 26 Oct 2000 10:30:48 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmof22028 for ; Thu, 26 Oct 2000 10:28:07 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmof15298 for ; Thu, 26 Oct 2000 10:28:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA06193 for mpls@uu.net; Thu, 26 Oct 2000 06:28:05 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmof13425 for ; Thu, 26 Oct 2000 10:27:52 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmof19058 for ; Thu, 26 Oct 2000 10:22:04 GMT Received: from no-worries.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: no-worries.cisco.com [144.254.148.250]) id QQjmof12765 for ; Thu, 26 Oct 2000 10:22:03 GMT Received: from DAPATTERLAPTOP (dapatter-isdn.cisco.com [144.254.141.53]) by no-worries.cisco.com (8.8.8+Sun/8.8.8) with SMTP id VAA15298; Thu, 26 Oct 2000 21:18:53 +1100 (EST) From: "Darren Patterson" To: "Rob Jaeger" , "Juan Diego Otero" Cc: "Wenbo Sheng" , "MPLS WG" Subject: RE: VPN solution Date: Thu, 26 Oct 2000 18:14:28 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I would have argued that l2 and l3 vpns would co-exist on any providers network and be sold and used where appropriate. i dont think these are mutually exclusive, but rather complimentary...the real arguement is on the model used for l3 vpn's. regards > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Rob > Jaeger > Sent: Wednesday, 25 October 2000 9:40 PM > To: Juan Diego Otero > Cc: Wenbo Sheng; MPLS WG > Subject: Re: VPN solution > > > > Juan/Wenbo, > > An alternative to draft-rosen-rfc2547bis is l2vpn as described in > draft-kompella-mpls-l2vpn-01.txt . One advantage of this method is the > separation of administrative responsibilities. In MPLS L2VPNs, the > service provider does not participate in the customer's L3 routing. This > may provide better stability than L3 VPNs. > > Rob > > > On Wed, 25 Oct 2000, Juan Diego Otero wrote: > > > Hi Wenbo, > > > > The method to build VPNs most discussed (and that makes me think > > that is the most popular) in this mailing list is > > the BGP/MPLS model explained in draft-rosen-rfc2547bis-02.txt > . Personally I > > think this method has a lot of advantages such as scalability, > security, manageability > > and use of private addressing. Some of this advantages > (specially scalability) have been > > discussed in this mailing list. > > > > Best Regards, > > > > Diego > > > > Wenbo Sheng wrote: > > HI, > > > > Assuming my customer need to create a VPN, I just want to > know which solution is better - using > > MPLS-VPN or virtual routers? Which solution is/will be > more popular in creating a VPN? > > > > Thanks in advance, > > > > W.S. > > > > > > -- > > http://www.geocities.com/diego_otero/ > > > > From owner-mpls@UU.NET Thu Oct 26 08:18:17 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14169 for ; Thu, 26 Oct 2000 08:18:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmon06131; Thu, 26 Oct 2000 12:17:52 GMT Received: by mail-control.mail.uu.net id QQjmon12699 for mpls-outgoing; Thu, 26 Oct 2000 12:17:18 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmon12689 for ; Thu, 26 Oct 2000 12:17:11 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmon13032 for ; Thu, 26 Oct 2000 12:16:42 GMT Received: from redbaron.nexabit.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQjmon04583 for ; Thu, 26 Oct 2000 12:16:42 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id IAA19588; Thu, 26 Oct 2000 08:30:42 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 08:15:40 -0400 Message-ID: From: Barry Hass To: Darren Patterson , Rob Jaeger , Juan Diego Otero Cc: Wenbo Sheng , MPLS WG Subject: RE: VPN solution Date: Thu, 26 Oct 2000 08:15:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Darren, Could you elaborate on what you think are the relative strengths and weaknesses of L2 and L3 VPNs, and what yout think are the most appropriate uses of each? Thanks. > -----Original Message----- > From: Darren Patterson [mailto:dapatter@cisco.com] > Sent: Thursday, October 26, 2000 6:14 AM > To: Rob Jaeger; Juan Diego Otero > Cc: Wenbo Sheng; MPLS WG > Subject: RE: VPN solution > > > I would have argued that l2 and l3 vpns would co-exist on any > providers > network and be sold and used where appropriate. i dont think these are > mutually exclusive, but rather complimentary...the real > arguement is on the > model used for l3 vpn's. > > regards > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Rob > > Jaeger > > Sent: Wednesday, 25 October 2000 9:40 PM > > To: Juan Diego Otero > > Cc: Wenbo Sheng; MPLS WG > > Subject: Re: VPN solution > > > > > > > > Juan/Wenbo, > > > > An alternative to draft-rosen-rfc2547bis is l2vpn as described in > > draft-kompella-mpls-l2vpn-01.txt . One advantage of this > method is the > > separation of administrative responsibilities. In MPLS L2VPNs, the > > service provider does not participate in the customer's L3 > routing. This > > may provide better stability than L3 VPNs. > > > > Rob > > > > > > On Wed, 25 Oct 2000, Juan Diego Otero wrote: > > > > > Hi Wenbo, > > > > > > The method to build VPNs most discussed (and that makes me think > > > that is the most popular) in this mailing list is > > > the BGP/MPLS model explained in draft-rosen-rfc2547bis-02.txt > > . Personally I > > > think this method has a lot of advantages such as scalability, > > security, manageability > > > and use of private addressing. Some of this advantages > > (specially scalability) have been > > > discussed in this mailing list. > > > > > > Best Regards, > > > > > > Diego > > > > > > Wenbo Sheng wrote: > > > HI, > > > > > > Assuming my customer need to create a VPN, I just want to > > know which solution is better - using > > > MPLS-VPN or virtual routers? Which solution is/will be > > more popular in creating a VPN? > > > > > > Thanks in advance, > > > > > > W.S. > > > > > > > > > -- > > > http://www.geocities.com/diego_otero/ > > > > > > > From owner-mpls@UU.NET Thu Oct 26 08:20:35 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15149 for ; Thu, 26 Oct 2000 08:20:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmon06185; Thu, 26 Oct 2000 12:20:12 GMT Received: by mail-control.mail.uu.net id QQjmon12798 for mpls-outgoing; Thu, 26 Oct 2000 12:19:39 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmon12790 for ; Thu, 26 Oct 2000 12:19:33 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmon26814 for ; Thu, 26 Oct 2000 12:19:24 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmon08415 for ; Thu, 26 Oct 2000 12:19:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA12280 for mpls@uu.net; Thu, 26 Oct 2000 08:19:23 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmon12764 for ; Thu, 26 Oct 2000 12:18:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmon16070 for ; Thu, 26 Oct 2000 12:18:13 GMT Received: from ogma.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjmon03449 for ; Thu, 26 Oct 2000 12:18:13 GMT Received: from amsterdam.cisco.com (amsterdam.cisco.com [144.254.74.36]) by ogma.cisco.com (Postfix) with ESMTP id B2202153 for ; Thu, 26 Oct 2000 14:18:12 +0200 (MET DST) Received: from mmorrow-81kcdt.cisco.com (par-ilm-dhcp1-vl133-16.cisco.com [144.254.54.211]) by amsterdam.cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA23121 for ; Thu, 26 Oct 2000 14:18:11 +0200 (MET DST) Message-Id: <4.1.20001026131250.00944100@amsterdam.cisco.com> Message-Id: <4.1.20001026131250.00944100@amsterdam.cisco.com> X-Sender: mmorrow@amsterdam.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 26 Oct 2000 13:13:07 +0100 To: mpls@UU.NET From: Monique Morrow Subject: subscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk mpls-request@uu.net **************************** Monique Jeanne Morrow Solution Design Consultant Cisco Systems GCoE, EMEA CCIE # 1711 Tel: +41 1 878 9412 Mobile: +41 79 334 57 23 ****************************** From owner-mpls@UU.NET Thu Oct 26 08:39:45 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22589 for ; Thu, 26 Oct 2000 08:39:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmoo00316; Thu, 26 Oct 2000 12:39:05 GMT Received: by mail-control.mail.uu.net id QQjmoo13819 for mpls-outgoing; Thu, 26 Oct 2000 12:38:42 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmoo13814 for ; Thu, 26 Oct 2000 12:38:35 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmoo09329 for ; Thu, 26 Oct 2000 12:37:44 GMT Received: from redbaron.nexabit.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQjmoo28486 for ; Thu, 26 Oct 2000 12:37:43 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id IAA19670; Thu, 26 Oct 2000 08:52:34 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 08:37:31 -0400 Message-ID: From: Barry Hass To: erosen@cisco.com, Paul Doolan Cc: yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: RE: VPN solution - White flag ? Date: Thu, 26 Oct 2000 08:37:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eric, Doesn't a PE router have to handle the full Internet routing table, plus VRFs for whatever VPNs it is supporting? I think that what some folks are suggesting is that BGP (not "the box", but BGP specifically) is already bumping up against scaling limits at 100,000 or so routes, and that burdening it with the additional responsibility of managing VPNs is not such a great idea. ("Some folks" please correct me if I'm wrong). Can you comment on that? By the way, I don't have enough information to have an opinion on this. I'm just trying to steer the discussion back to what I thought was an interesting technical question before the insults started to fly. > In the NBVPN routing environment, it is not true that > anyone in the world > needs to be able to reach anyone else in the world. Each > VPN has its own > inter-connectivity matrix, much smaller than the > Internet connectivity > matrix. Now if you add up all the VPN routes, summed over > all VPNs, you may > indeed get a much larger number than the number of > Internet routes. But > there is no one box which needs to hold them all. Since an > instance of BGP > runs in a particular box, and only has to deal with the > routes that need to > be in that box, you don't run up against the same box > scaling problems you > run up against in the Internet routing environment. You > can design your > system to have a given box handle as many routes or as few > routes as you > want. From owner-mpls@UU.NET Thu Oct 26 08:47:51 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25216 for ; Thu, 26 Oct 2000 08:47:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmop10802; Thu, 26 Oct 2000 12:46:58 GMT Received: by mail-control.mail.uu.net id QQjmop14413 for mpls-outgoing; Thu, 26 Oct 2000 12:46:41 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmop14405 for ; Thu, 26 Oct 2000 12:46:31 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmop29047 for ; Thu, 26 Oct 2000 12:46:11 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmop12594 for ; Thu, 26 Oct 2000 12:46:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA15407 for mpls@uu.net; Thu, 26 Oct 2000 08:46:10 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmop14274 for ; Thu, 26 Oct 2000 12:45:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmop10029 for ; Thu, 26 Oct 2000 12:45:42 GMT Received: from ogma.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjmop00839 for ; Thu, 26 Oct 2000 12:45:41 GMT Received: from london.cisco.com (london.cisco.com [144.254.32.10]) by ogma.cisco.com (Postfix) with ESMTP id 0C3A7F2; Thu, 26 Oct 2000 14:45:40 +0200 (MET DST) Received: from jguichar-8kcdt.cisco.com (lon-sto4-lan-vlan127-dhcp40.cisco.com [144.254.105.107]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id OAA15960; Thu, 26 Oct 2000 14:45:40 +0200 (MET DST) Message-Id: <200010261245.OAA15960@london.cisco.com> X-Sender: jguichar@uk.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 26 Oct 2000 13:42:49 +0100 To: Barry Hass , erosen@cisco.com, Paul Doolan From: Jim Guichard Subject: RE: VPN solution - White flag ? Cc: yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Barry, the answer is no. There are various ways to design Internet connectivity within this environment, one of which is to carry full Internet routes on the PE router. Other options include default routing from VPN sites to a central site that has Internet connectivity, another is to offload the Internet routes from the PE and run direct eBGP sessions from the VPN site to the Internet exit point. Which option is actually taken will depend on the specific design requirements. Jim At 08:37 26/10/2000 -0400, Barry Hass wrote: >Eric, > >Doesn't a PE router have to handle the full Internet routing >table, plus VRFs for whatever VPNs it is supporting? I think >that what some folks are suggesting is that BGP (not "the box", >but BGP specifically) is already bumping up against scaling >limits at 100,000 or so routes, and that burdening it with the >additional responsibility of managing VPNs is not such a great >idea. ("Some folks" please correct me if I'm wrong). Can you >comment on that? > >By the way, I don't have enough information to have an opinion >on this. I'm just trying to steer the discussion back to what >I thought was an interesting technical question before the >insults started to fly. > >> In the NBVPN routing environment, it is not true that >> anyone in the world >> needs to be able to reach anyone else in the world. Each >> VPN has its own >> inter-connectivity matrix, much smaller than the >> Internet connectivity >> matrix. Now if you add up all the VPN routes, summed over >> all VPNs, you may >> indeed get a much larger number than the number of >> Internet routes. But >> there is no one box which needs to hold them all. Since an >> instance of BGP >> runs in a particular box, and only has to deal with the >> routes that need to >> be in that box, you don't run up against the same box >> scaling problems you >> run up against in the Internet routing environment. You >> can design your >> system to have a given box handle as many routes or as few >> routes as you >> want. > Jim Guichard CCIE #2069 Network Design Consultant EMEA Global Solutions Engineering +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Thu Oct 26 09:12:19 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03181 for ; Thu, 26 Oct 2000 09:12:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmoq13455; Thu, 26 Oct 2000 13:11:50 GMT Received: by mail-control.mail.uu.net id QQjmoq27525 for mpls-outgoing; Thu, 26 Oct 2000 13:11:21 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmoq27515 for ; Thu, 26 Oct 2000 13:11:17 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmoq17844 for ; Thu, 26 Oct 2000 13:10:25 GMT Received: from ennovatenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjmoq13880 for ; Thu, 26 Oct 2000 13:10:24 GMT Received: from ennovatenetworks.com (h0040d0042eaa.ne.mediaone.net [24.147.156.69]) by ennovatenetworks.com (8.8.7/8.8.7) with ESMTP id JAA24808; Thu, 26 Oct 2000 09:10:16 -0400 (EDT) (envelope-from pdoolan@ennovatenetworks.com) Message-ID: <39F827F9.CC2165A3@ennovatenetworks.com> Date: Thu, 26 Oct 2000 08:47:54 -0400 From: Paul Doolan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Guichard CC: Barry Hass , erosen@cisco.com, yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? References: <200010261245.OAA15960@london.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jim, >Other options include default routing from VPN sites to a >central site that has Internet connectivity, another is to offload the >Internet routes from the PE and run direct eBGP sessions from the VPN site >to the Internet exit point. When you say 'VPN site' here are you suggesting that the CE router is running eBGP with/to the 'Internet exit point' ? pd From owner-mpls@UU.NET Thu Oct 26 09:22:30 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05647 for ; Thu, 26 Oct 2000 09:22:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmor17571; Thu, 26 Oct 2000 13:21:35 GMT Received: by mail-control.mail.uu.net id QQjmor28256 for mpls-outgoing; Thu, 26 Oct 2000 13:21:14 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmor28251 for ; Thu, 26 Oct 2000 13:21:11 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmor17012 for ; Thu, 26 Oct 2000 13:20:00 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmor24553 for ; Thu, 26 Oct 2000 13:19:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA19354 for mpls@uu.net; Thu, 26 Oct 2000 09:19:58 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmor28187 for ; Thu, 26 Oct 2000 13:19:24 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmor14816; Thu, 26 Oct 2000 13:19:01 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmor23264; Thu, 26 Oct 2000 13:19:00 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA14985; Thu, 26 Oct 2000 06:18:52 -0700 (PDT) Message-Id: <200010261318.GAA14985@omega.cisco.com> To: Mark.Jones@mail.sprint.com cc: David.A.Holmes@disney.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, sc@tellium.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-reply-to: Your message of "Mon, 23 Oct 2000 17:32:46 CDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14982.972566332.1@cisco.com> Date: Thu, 26 Oct 2000 06:18:52 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Mark, > Great point! The need to automate features like provisioning is one of > the key reasons we are all looking at optical networking. However, the > fast provisioning we all desire does not require the peer model. (Many > problems with the peer model for large multi-service carriers like > Sprint have already been raised in this discussion, so I won't repeat > them.) I expect end-to-end provisioning in seconds or at least in > minutes to be possible with the overlay model too. > > The question we should be asking is, who will be able to actually take > advantage of that capability regardless of the model you adopt? My > guess is that it will primarily be an internal network feature that few > network customers will ever use directly. > > Here's why. Even if you find a carrier to support the peer model, you > will be required to pay for connections that you MIGHT use in the event > that you want to add bandwidth to your connection. No carrier or > customer wants to build out capacity without some level of commitment > that the equipment will be needed. How much do you want to pay for the > privilege of having bandwidth on demand? For sub-wavelength bandwidth, > packet level aggregation minimizes the costs of bandwidth on demand for > carriers and customers. I believe that exists in limited ways in > service offerings already. However, wavelength level bandwidth on > demand may never be profitable due to the price of wavelength level > port cards and systems. So, the carrier may deploy optical networking > with seconds required for provisioning, but the bandwidth will still > have to be built out to the customer after an order before it's > available. I don't want to burst anyone's dream of bandwidth on > demand, but please consider the practical aspects required to make it a > reasonable service offering. So, if you think that bandwidth on demand as a service offering isn't practical, what are the scenario(s) where UNI would be useful ? Yakov. From owner-mpls@UU.NET Thu Oct 26 09:28:21 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06909 for ; Thu, 26 Oct 2000 09:28:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmor04881; Thu, 26 Oct 2000 13:26:16 GMT Received: by mail-control.mail.uu.net id QQjmor28522 for mpls-outgoing; Thu, 26 Oct 2000 13:25:55 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmor28517 for ; Thu, 26 Oct 2000 13:25:49 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmor29841 for ; Thu, 26 Oct 2000 13:25:40 GMT Received: from auemlsrv.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQjmor23116 for ; Thu, 26 Oct 2000 13:25:39 GMT Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA13059 for ; Thu, 26 Oct 2000 09:25:39 -0400 (EDT) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA13044; Thu, 26 Oct 2000 09:25:38 -0400 (EDT) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA27306; Thu, 26 Oct 2000 09:25:36 -0400 (EDT) Message-ID: <39F830CE.1DE19A00@lucent.com> Date: Thu, 26 Oct 2000 09:25:34 -0400 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Ron Bonica CC: mpls@UU.NET Subject: Re: Two orthogonal issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ron, > > If the client IP network were to used MPLS signaling to obtain services from > the optical transport network, and if the optical transport network were > clever about enforcing a configurable admission control policy, would there > be any need for a UNI? Couldn't the admission control policy restrict client > networks to services that they might otherwise have obtained through the > UNI? You are right. Especially in the case you mentioned. I understand many folks don't even want to hear "UNI" probably because of their previous bad experiences of ATM UNI. (Mee too, at beginning). Yet, optical UNI is different from ATM UNI in many key aspects (and sure similar in many concepts). Think optical UNI as only a "functional" interface. It can be thin and thick with service providers' control according to different network application scenarios. For one extreme, optical network and routers are owned by different service providers. You sure need a thick UNI with strong security and policy control. For another extreme, optical network and routers are owned by the same service provider and provisioned within a single area. Now UNI is very thin. Actually only GMPLS signaling is needed. However, the "UNI" is still there because the optical LSP is triggered by the request from routers' traffic engineering function. UNI is not a monster. It's up to how we define and design it. Regards, Yangguang From owner-mpls@UU.NET Thu Oct 26 09:43:02 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10173 for ; Thu, 26 Oct 2000 09:43:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmos25248; Thu, 26 Oct 2000 13:41:44 GMT Received: by mail-control.mail.uu.net id QQjmos29404 for mpls-outgoing; Thu, 26 Oct 2000 13:41:15 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmos29394 for ; Thu, 26 Oct 2000 13:41:13 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmos27578; Thu, 26 Oct 2000 13:40:44 GMT Received: from nexen.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maelstrom.nexen.com [204.249.97.5]) id QQjmos23892; Thu, 26 Oct 2000 13:40:44 GMT Received: from phish.nexen.com (phish-98 [204.249.98.14]) by nexen.com (8.11.0/8.11.0) with ESMTP id e9QDeil19267; Thu, 26 Oct 2000 08:40:45 -0500 (EST) Received: from nexen.com (bhome [204.249.97.124]) by phish.nexen.com (8.8.5/8.8.5) with ESMTP id JAA23211; Thu, 26 Oct 2000 09:40:31 -0400 (EDT) Message-ID: <39F83459.45ACA54D@nexen.com> Date: Thu, 26 Oct 2000 09:40:41 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Allan CC: alchiu , "'Yakov Rekhter'" , ip-optical , mpls , sc , xuyg , yxue Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <6DDA62170439D31185750000F80826AC04286E83@zmerd004.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dave The concept of jointly routing primary and protection paths has been well accepted by Bell heads looking at optimizing their networks for a long time. Part of the reason for this is the assumption that protection path(s) must also be conformant to the same SLA as the primary path, and joint routing is the most likely to achieve this. This does not of course address your concerns about race conditions at connection establishment. But joint routing is guaranteed to produce a solution not worse than independent routing, and results in a lower commitment of network resources. ciao mark David Allan wrote: > > > Angela: > > Jointly routing the paths intuitively does not strike me as optimal. > Not unless we are periodically performing path maintenance on the > entire set of network resources. I would have to assume that the > overall configuration of the network occurred incrementally, and with > a desire to minimize service interruption of the already established > paths. > > With that in mind, I would assume the routing of the primary path > should always be chosen as the optimal route. The backup path is then > required to be diverse (node, fiber, conduit, trench) with the optimal > primary path and would frequently be less optimal as the physical > routing would frequently be in the form of a longer path. > > I do not understand how whether this is done sequentially or > simultaneously affects these basics, except in the possible deadlock > scenario where the optimal routing of the primary path precludes a > viable backup. In the meantime, I would assume sequential > establishment of primary then backup would stand an overall greater > chance of success, especially if the path computing node does not have > a comprehensive and authoritative view of the network state. It > strikes me that routing the backup should have the ability to > intelligently crank back with knowledge of what to avoid to maintain > diversity with the primary path. > > regards > Dave > > -----Original Message----- > From: Angela Chiu [SMTP:alchiu@research.att.com] > Sent: Wednesday, October 25, 2000 10:03 AM > To: 'Yakov Rekhter' > Cc: ip-optical; mpls; sc; xuyg; yxue > Subject: RE: [IP-Optical] RE: Optical link bundling. Was > Re: DraftMinutes From Pittsburgh > > Yakov, > > Yes, you are right. Routing the primary and backup paths jointly > is always > more optimal than fixing the path for primary first then routing > the backup > accordingly. The same argument can be applied to comparing > centralized > routing with distributed routing. Even distributed routing is > less optimal, > it is the trend today. I think the real issue is at what cost the > additional > optimality is gained, and how much the additional optimality is > in a typical > network setting. In this case the cost is all the topological > information > including SRLG information as well as physical impairment > constraints in the > optical network that routers need to obtain in order to make > proper routing > decision. > > I have an idea, this will be a valid master/PhD thesis for some > graduate > students who would like to work on real world problems. > > Regards, > > Angela > > -----Original Message----- > From: ip-optical-admin@lists.bell-labs.com > [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Yakov > Rekhter > Sent: Wednesday, October 25, 2000 7:35 AM > To: alchiu@research.att.com > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com; > xuyg@lucent.com; yxue@UU.NET > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > Angela, > > > Some followup discussions in line. > > more in line... > > > Regards, > > Angela > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Kireeti > > Kompella > > Sent: Monday, October 23, 2000 1:58 PM > > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; > yxue@UU.NET > > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > > DraftMinutes From Pittsburgh > > > > > > > I don't see why TE and protection require the routers to > specify > explicit > > > routes. > > > The routers can simply specify to the optical layer what type > of optical > > > layer protection > > > it requires. > > > > Suppose router A wants to get to router B, and wants to take > two > > different ingress and egress points in the optical domain, X->Y > > > for the primary LSP, and W->Z for the backup. A does not > require > > optical protection for the X->Y path, nor for the W->Z path. A > > > *does* require that the X->Y path and the W->Z path do not > share > > common links. How is this to be done? > > > > If A did the full path computation, this is simplicity itself. > > > > [AC] I think you have a good point here. I also heard the same > kind if > > reasoning (i.e., have a layer-3 like protection switching) for > supporting > > the peer model. But after discussing with others, it seems that > overlay > > model should be able to provide the same capability. > > Not really... for more on this see below... > > > Normally, the primary > > LSP X->Y is set up first, and becomes a forwarding adjacency > (FA) > according > > to your LSP Hierarchy draft. Then the associated information of > the FA > X->Y > > including its exact path and SRLG information should be > propagated via IGP > > extensions, same as with any other link in the network. Thus if > router A > > sends a request to OXC W to set up a backup lightpath from W->Z > to be > > diversely router from the existing FA X->Y, OXC W should > already have the > > right information to perform proper routing. > > It is a known fact that for computing disjoint paths the approach > > you outlined above may result in a situation where no backup > path will be found, despite the fact that that it is possible > (using some other approach) to find two disjoint paths. > > > Comparing with the peer model solution where routers need to > know all the > > SRLG information of the optical domain as well as all relevant > physical > > impairments in the optical signal in the case of transparent > optical > > network, it is still not clear to me which one is simpler. > > > > I think it is very good to have this kind of technical > discussion openly > on > > the list. Hope others can provide more technical and business > (after all > > carriers need to pay for these features) evidences for the need > of each > > model. Some other reasoning I heard includes that peer model > can improve > the > > IGP scalability in terms of the number of neighbors a router > needs to peer > > with. But since large ISPs today seem to cope well with the IGP > > scalability > > today, I don't see why the problem will get significant worst > when optical > > networks come into play. > > In the end it is not the discussion on this list, but the > competition > in the marketplace that will determine the viability of different > > models. > > Yakov. > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical > From owner-mpls@UU.NET Thu Oct 26 09:50:50 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11887 for ; Thu, 26 Oct 2000 09:50:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmot24926; Thu, 26 Oct 2000 13:49:54 GMT Received: by mail-control.mail.uu.net id QQjmot00116 for mpls-outgoing; Thu, 26 Oct 2000 13:49:15 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmot00109 for ; Thu, 26 Oct 2000 13:49:06 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmot12852 for ; Thu, 26 Oct 2000 13:47:21 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmot00212 for ; Thu, 26 Oct 2000 13:47:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA23249 for mpls@uu.net; Thu, 26 Oct 2000 09:47:19 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmot00039 for ; Thu, 26 Oct 2000 13:46:49 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmot16546 for ; Thu, 26 Oct 2000 13:45:48 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmot28035 for ; Thu, 26 Oct 2000 13:45:47 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA16375; Thu, 26 Oct 2000 06:45:45 -0700 (PDT) Message-Id: <200010261345.GAA16375@omega.cisco.com> To: Yangguang Xu cc: Ron Bonica , mpls@UU.NET Subject: Re: Two orthogonal issue In-reply-to: Your message of "Thu, 26 Oct 2000 09:25:34 EDT." <39F830CE.1DE19A00@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16373.972567945.1@cisco.com> Date: Thu, 26 Oct 2000 06:45:45 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Yangguang, > > If the client IP network were to used MPLS signaling to obtain services from > > the optical transport network, and if the optical transport network were > > clever about enforcing a configurable admission control policy, would there > > be any need for a UNI? Couldn't the admission control policy restrict client > > networks to services that they might otherwise have obtained through the > > UNI? > > You are right. Especially in the case you mentioned. > > I understand many folks don't even want to hear "UNI" probably because of the ir > previous bad experiences of ATM UNI. (Mee too, at beginning). Yet, optical UNI > is different from ATM UNI in many key aspects (and sure similar in many > concepts). > > Think optical UNI as only a "functional" interface. It can be thin and thick > with service providers' control according to different network application > scenarios. > > For one extreme, optical network and routers are owned by different service > providers. You sure need a thick UNI with strong security and policy control. That is clearly the case where the overlay model is needed (and the peer model isn't suitable). > For another extreme, optical network and routers are owned by the same service > provider and provisioned within a single area. Now UNI is very thin. Actually > only GMPLS signaling is needed. However, the "UNI" is still there because the > optical LSP is triggered by the request from routers' traffic engineering > function. For the latter case (OXCs and routers are provisioned within a single area), routers themselves may as well compute routes for LSPs. So, why bother with UNI in this scenario ? As Kireeti was trying to explain to you before, Yangguang> The key point is whatever routers can do to optical network, Yangguang> optical switches can do by themselves (as easy as router can do). Yangguang> Why bother? Kireeti> This is not a router vs. optical switch issue. The issue is Kireeti> that the *originator* of the LSP has all the info. The originator Kireeti> of the LSPs can do a full path computation, can do both paths Kireeti> simultaneously, has no coordination issues, no extensions to Kireeti> signalling or link state protocols. Yakov. P.S. And just to add to this, you may look at the attached e-mail that was posted to this list last February... -- using template mhl.format -- Date: Wed, 02 Feb 2000 01:18:21 PST To: Theimer Thomas cc: curtis@avici.com, mpls@UU.NET From: Tony Li Subject: Re: MPLS and Optical network!! > I would expect that initially the optical domain will have a control > plane that is independent from the layer 3 control plane of routers. Of > course, > there is traffic engineering in the optical domain, and there is traffic > engineering > in the layer 3 domain, but why do they have to be integrated ??? In addition to Curtis' points, we should also note that traffic engineering computations for deriving the optimal allocation of circuits in static network is already considered to be a computationally 'hard' problem in operations research. If we partition the problem in the way that you describe, we make the computation 'harder' in the sense that we've precluded the traffic engineering demands on the routed plane from interacting nicely with the wavelength allocation in the optical plane. One can envision (possibly pathological) cases where optimality is actually improved by keeping certain traffic on the routed plane, thereby allowing other traffic to make use of the optical plane. The more cynical might suggest that I'm proposing that we simply dump the hard parts of the problem in the laps of the OR folks and do the bare minimum amount of engineering necessary to have a simplistic, functional system. ;-) Tony From owner-mpls@UU.NET Thu Oct 26 10:16:42 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17684 for ; Thu, 26 Oct 2000 10:16:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmov10534; Thu, 26 Oct 2000 14:15:44 GMT Received: by mail-control.mail.uu.net id QQjmov13251 for mpls-outgoing; Thu, 26 Oct 2000 14:15:16 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmov13176 for ; Thu, 26 Oct 2000 14:15:05 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmou14194 for ; Thu, 26 Oct 2000 14:13:48 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmou29266 for ; Thu, 26 Oct 2000 14:13:48 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA26964 for mpls@uu.net; Thu, 26 Oct 2000 10:13:47 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmou12966 for ; Thu, 26 Oct 2000 14:13:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmou07138; Thu, 26 Oct 2000 14:12:16 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmou05854; Thu, 26 Oct 2000 14:12:15 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA17374; Thu, 26 Oct 2000 07:01:53 -0700 (PDT) Message-Id: <200010261401.HAA17374@omega.cisco.com> To: Mark Stewart cc: David Allan , alchiu , ip-optical , mpls , sc , xuyg , yxue Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh In-reply-to: Your message of "Thu, 26 Oct 2000 09:40:41 EDT." <39F83459.45ACA54D@nexen.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17372.972568913.1@cisco.com> Date: Thu, 26 Oct 2000 07:01:53 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Mark, > The concept of jointly routing primary and protection paths has been > well accepted by Bell heads looking at optimizing their networks for a > long time. Part of the reason for this is the assumption that protection > path(s) must also be conformant to the same SLA as the primary path, and > joint routing is the most likely to achieve this. > > This does not of course address your concerns about race conditions at > connection establishment. But joint routing is guaranteed to produce a > solution not worse than independent routing, and results in a lower > commitment of network resources. Moreover, in certain cases independent routing would not be able to produce a solution at all, while joint routing would be able to produce a solution. Yakov. > > ciao > > mark > > > > > > > David Allan wrote: > > > > > > > Angela: > > > > Jointly routing the paths intuitively does not strike me as optimal. > > Not unless we are periodically performing path maintenance on the > > entire set of network resources. I would have to assume that the > > overall configuration of the network occurred incrementally, and with > > a desire to minimize service interruption of the already established > > paths. > > > > With that in mind, I would assume the routing of the primary path > > should always be chosen as the optimal route. The backup path is then > > required to be diverse (node, fiber, conduit, trench) with the optimal > > primary path and would frequently be less optimal as the physical > > routing would frequently be in the form of a longer path. > > > > I do not understand how whether this is done sequentially or > > simultaneously affects these basics, except in the possible deadlock > > scenario where the optimal routing of the primary path precludes a > > viable backup. In the meantime, I would assume sequential > > establishment of primary then backup would stand an overall greater > > chance of success, especially if the path computing node does not have > > a comprehensive and authoritative view of the network state. It > > strikes me that routing the backup should have the ability to > > intelligently crank back with knowledge of what to avoid to maintain > > diversity with the primary path. > > > > regards > > Dave > > > > -----Original Message----- > > From: Angela Chiu [SMTP:alchiu@research.att.com] > > Sent: Wednesday, October 25, 2000 10:03 AM > > To: 'Yakov Rekhter' > > Cc: ip-optical; mpls; sc; xuyg; yxue > > Subject: RE: [IP-Optical] RE: Optical link bundling. Was > > Re: DraftMinutes From Pittsburgh > > > > Yakov, > > > > Yes, you are right. Routing the primary and backup paths jointly > > is always > > more optimal than fixing the path for primary first then routing > > the backup > > accordingly. The same argument can be applied to comparing > > centralized > > routing with distributed routing. Even distributed routing is > > less optimal, > > it is the trend today. I think the real issue is at what cost the > > additional > > optimality is gained, and how much the additional optimality is > > in a typical > > network setting. In this case the cost is all the topological > > information > > including SRLG information as well as physical impairment > > constraints in the > > optical network that routers need to obtain in order to make > > proper routing > > decision. > > > > I have an idea, this will be a valid master/PhD thesis for some > > graduate > > students who would like to work on real world problems. > > > > Regards, > > > > Angela > > > > -----Original Message----- > > From: ip-optical-admin@lists.bell-labs.com > > [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Yakov > > Rekhter > > Sent: Wednesday, October 25, 2000 7:35 AM > > To: alchiu@research.att.com > > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com; > > xuyg@lucent.com; yxue@UU.NET > > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > > DraftMinutes From Pittsburgh > > > > Angela, > > > > > Some followup discussions in line. > > > > more in line... > > > > > Regards, > > > Angela > > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > Kireeti > > > Kompella > > > Sent: Monday, October 23, 2000 1:58 PM > > > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; > > yxue@UU.NET > > > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > > > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > > > DraftMinutes From Pittsburgh > > > > > > > > > > I don't see why TE and protection require the routers to > > specify > > explicit > > > > routes. > > > > The routers can simply specify to the optical layer what type > > of optical > > > > layer protection > > > > it requires. > > > > > > Suppose router A wants to get to router B, and wants to take > > two > > > different ingress and egress points in the optical domain, X->Y > > > > > for the primary LSP, and W->Z for the backup. A does not > > require > > > optical protection for the X->Y path, nor for the W->Z path. A > > > > > *does* require that the X->Y path and the W->Z path do not > > share > > > common links. How is this to be done? > > > > > > If A did the full path computation, this is simplicity itself. > > > > > > [AC] I think you have a good point here. I also heard the same > > kind if > > > reasoning (i.e., have a layer-3 like protection switching) for > > supporting > > > the peer model. But after discussing with others, it seems that > > overlay > > > model should be able to provide the same capability. > > > > Not really... for more on this see below... > > > > > Normally, the primary > > > LSP X->Y is set up first, and becomes a forwarding adjacency > > (FA) > > according > > > to your LSP Hierarchy draft. Then the associated information of > > the FA > > X->Y > > > including its exact path and SRLG information should be > > propagated via IGP > > > extensions, same as with any other link in the network. Thus if > > router A > > > sends a request to OXC W to set up a backup lightpath from W->Z > > to be > > > diversely router from the existing FA X->Y, OXC W should > > already have the > > > right information to perform proper routing. > > > > It is a known fact that for computing disjoint paths the approach > > > > you outlined above may result in a situation where no backup > > path will be found, despite the fact that that it is possible > > (using some other approach) to find two disjoint paths. > > > > > Comparing with the peer model solution where routers need to > > know all the > > > SRLG information of the optical domain as well as all relevant > > physical > > > impairments in the optical signal in the case of transparent > > optical > > > network, it is still not clear to me which one is simpler. > > > > > > I think it is very good to have this kind of technical > > discussion openly > > on > > > the list. Hope others can provide more technical and business > > (after all > > > carriers need to pay for these features) evidences for the need > > of each > > > model. Some other reasoning I heard includes that peer model > > can improve > > the > > > IGP scalability in terms of the number of neighbors a router > > needs to peer > > > with. But since large ISPs today seem to cope well with the IGP > > > > scalability > > > today, I don't see why the problem will get significant worst > > when optical > > > networks come into play. > > > > In the end it is not the discussion on this list, but the > > competition > > in the marketplace that will determine the viability of different > > > > models. > > > > Yakov. > > > > _______________________________________________ > > IP-Optical mailing list > > IP-Optical@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/ip-optical > > > From owner-mpls@UU.NET Thu Oct 26 10:30:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20616 for ; Thu, 26 Oct 2000 10:30:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmov01130; Thu, 26 Oct 2000 14:29:02 GMT Received: by mail-control.mail.uu.net id QQjmov14080 for mpls-outgoing; Thu, 26 Oct 2000 14:28:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmov14071 for ; Thu, 26 Oct 2000 14:28:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmov09006 for ; Thu, 26 Oct 2000 14:27:33 GMT From: darren.freeland@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjmov29039 for ; Thu, 26 Oct 2000 14:27:32 GMT Received: from cbtlipnt02.btlabs.bt.co.uk by gollum (local) with ESMTP; Thu, 26 Oct 2000 15:19:54 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id <4W3BDA66>; Thu, 26 Oct 2000 15:17:43 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C781@mbtlipnt01.btlabs.bt.co.uk> To: yakov@cisco.com Cc: mpls@UU.NET, alan.mcguire@bt.com, andy.bd.reid@bt.com Subject: RE: Two orthogonal issue Date: Thu, 26 Oct 2000 15:17:11 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yakov, > There are fairly pragmatic reasons for using MPLS/GMPLS for > the control plane - for more on this folks may read > draft-awduche-mpls-te-optical-02.txt. I have read the draft. Twice. As far as I can see, the only real justification given for using MPLS/GMPLS for optical control is the reuse of existing protocols. Cool, I think we all agree that we don't want to reinvent the wheel. Why not PNNI then? Why do you say that IP protocols should be used for the control plane facets? Again, note that I'm not advocating any particular approach just yet - I am saying that the requirements of the OTN (or any other network in the case of GMPLS) should be fully considered in the first place. The choice (and extensions) of control plane protocols should then be made to fit requirements. Putting aside this questionable "okay, here is the answers - now what was the question" type approach, I have another big problem with draft-awduche-mpls-te-optical-02.txt. Lets pretend that we HAVE actually fully considered operators requirements, and the major consensus among operators is that the reuse of IP protocols is perfect for OTN. If I'm to start out on this approach with draft-awduche-mpls-te-optical-02.txt then I'm going to be building my OTN for IP only. The draft shows a clear bias towards the peer option. I'm not happy with that. What's the justification given for using this model over the overlay option? **To avoid problems encountered with IP over ATM** ... sorry, wrong answer. OTN is not ATM. We (inc other operators) have made our feelings clear on the peer model. As far as I (as an operator with multiple clients) am concerned, it's a no-go option for my OTN. So if I'm to pretend that we have fully considered operators OTN requirements and came to a consensus on the reuse of IP control protocols, then I have to insist that vendors who want my money develop the overlay model first. Regards, Darren. -----Original Message----- From: Yakov Rekhter [mailto:yakov@cisco.com] Sent: 26 October 2000 03:51 To: Kireeti Kompella Cc: mpls@UU.NET; rbonica@mci.net Subject: Re: Two orthogonal issue Kireeti, [clipped...] > One thing that has come out of this debate is that carriers are > thinking more deeply about requirements, which is a welcome step > forward. At the same time, several deep-rooted biases are being > exposed, and I'll be the first to admit my bias towards using > MPLS/GMPLS for the control plane. There are fairly pragmatic reasons for using MPLS/GMPLS for the control plane - for more on this folks may read draft-awduche-mpls-te-optical-02.txt. Yakov. -------------------------------------------- > Disclaimer > > "The information and statements in this > email are supplied and made in good faith > and without prejudice. They do not > represent BT's only or final view or > position and are subject to any change > that BT may wish to make (including a > complete reversal). BT will not be liable > for any action you take or not take based > upon the contents of this email". -------------------------------------------- From owner-mpls@UU.NET Thu Oct 26 10:35:24 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21760 for ; Thu, 26 Oct 2000 10:35:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmow26893; Thu, 26 Oct 2000 14:34:14 GMT Received: by mail-control.mail.uu.net id QQjmow14427 for mpls-outgoing; Thu, 26 Oct 2000 14:33:51 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmow14420 for ; Thu, 26 Oct 2000 14:33:48 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmow28007 for ; Thu, 26 Oct 2000 14:32:54 GMT Received: from devmail.dev.tivoli.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136]) id QQjmow03901 for ; Thu, 26 Oct 2000 14:32:53 GMT Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19]) by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id JAA04672 for ; Thu, 26 Oct 2000 09:32:52 -0500 (CDT) Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70]) by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id KAA00970 for ; Thu, 26 Oct 2000 10:35:44 -0400 (EDT) From: "Paul Tasillo" To: "mpls@UU. net" Subject: FW: VPN solution - White flag ? Date: Thu, 26 Oct 2000 10:34:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Will the overhead of running Virtual Routers impact the scalablity of the draft-ouldbrahim-vpn-vr-01 approach? That is, there must be a limit to the number of VRs a PE can handle and thus a limit to the number of VPNs the PE can handle. Is this true? -Paul (not Paul Doolan) Paul Tasillo Tivoli Systems -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Guichard Sent: Thursday, October 26, 2000 8:43 AM To: Barry Hass; erosen@cisco.com; Paul Doolan Cc: yakov@cisco.com; rnewcomb@ennovatenetowrks.com.tivoli.com; mpls@UU.NET; diego@estos.upc.es Subject: RE: VPN solution - White flag ? Barry, the answer is no. There are various ways to design Internet connectivity within this environment, one of which is to carry full Internet routes on the PE router. Other options include default routing from VPN sites to a central site that has Internet connectivity, another is to offload the Internet routes from the PE and run direct eBGP sessions from the VPN site to the Internet exit point. Which option is actually taken will depend on the specific design requirements. Jim At 08:37 26/10/2000 -0400, Barry Hass wrote: >Eric, > >Doesn't a PE router have to handle the full Internet routing >table, plus VRFs for whatever VPNs it is supporting? I think >that what some folks are suggesting is that BGP (not "the box", >but BGP specifically) is already bumping up against scaling >limits at 100,000 or so routes, and that burdening it with the >additional responsibility of managing VPNs is not such a great >idea. ("Some folks" please correct me if I'm wrong). Can you >comment on that? > >By the way, I don't have enough information to have an opinion >on this. I'm just trying to steer the discussion back to what >I thought was an interesting technical question before the >insults started to fly. > >> In the NBVPN routing environment, it is not true that >> anyone in the world >> needs to be able to reach anyone else in the world. Each >> VPN has its own >> inter-connectivity matrix, much smaller than the >> Internet connectivity >> matrix. Now if you add up all the VPN routes, summed over >> all VPNs, you may >> indeed get a much larger number than the number of >> Internet routes. But >> there is no one box which needs to hold them all. Since an >> instance of BGP >> runs in a particular box, and only has to deal with the >> routes that need to >> be in that box, you don't run up against the same box >> scaling problems you >> run up against in the Internet routing environment. You >> can design your >> system to have a given box handle as many routes or as few >> routes as you >> want. > Jim Guichard CCIE #2069 Network Design Consultant EMEA Global Solutions Engineering +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Thu Oct 26 10:39:44 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22738 for ; Thu, 26 Oct 2000 10:39:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmow15180; Thu, 26 Oct 2000 14:39:03 GMT Received: by mail-control.mail.uu.net id QQjmow14936 for mpls-outgoing; Thu, 26 Oct 2000 14:38:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmow14928 for ; Thu, 26 Oct 2000 14:38:37 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmow11014 for ; Thu, 26 Oct 2000 14:38:31 GMT Received: from devmail.dev.tivoli.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136]) id QQjmow03046 for ; Thu, 26 Oct 2000 14:38:31 GMT Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19]) by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id JAA05361 for ; Thu, 26 Oct 2000 09:38:30 -0500 (CDT) Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70]) by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id KAA01004 for ; Thu, 26 Oct 2000 10:41:21 -0400 (EDT) From: "Paul Tasillo" To: "mpls@UU. net" Subject: FW: Two orthogonal issue Date: Thu, 26 Oct 2000 10:39:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit See comments in line... -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of darren.freeland@bt.com Sent: Thursday, October 26, 2000 10:17 AM To: yakov@cisco.com Cc: mpls@UU.NET; alan.mcguire@bt.com; andy.bd.reid@bt.com Subject: RE: Two orthogonal issue Yakov, > There are fairly pragmatic reasons for using MPLS/GMPLS for > the control plane - for more on this folks may read > draft-awduche-mpls-te-optical-02.txt. I have read the draft. Twice. As far as I can see, the only real justification given for using MPLS/GMPLS for optical control is the reuse of existing protocols. Cool, I think we all agree that we don't want to reinvent the wheel. Why not PNNI then? Why do you say that IP protocols should be used for the control plane facets? Again, note that I'm not advocating any particular approach just yet - I am saying that the requirements of the OTN (or any other network in the case of GMPLS) should be fully considered in the first place. The choice (and extensions) of control plane protocols should then be made to fit requirements. PT>> isn't this the same reason people want to use MPLS on ATM networks? To solve the ATM scalability problem. From what I understand, IP routing is scalable and ATM (PNNI) isn't because of the signalling(SVC)/PVC table size. Perhaps I am missing something here? -Paul Putting aside this questionable "okay, here is the answers - now what was the question" type approach, I have another big problem with draft-awduche-mpls-te-optical-02.txt. Lets pretend that we HAVE actually fully considered operators requirements, and the major consensus among operators is that the reuse of IP protocols is perfect for OTN. If I'm to start out on this approach with draft-awduche-mpls-te-optical-02.txt then I'm going to be building my OTN for IP only. The draft shows a clear bias towards the peer option. I'm not happy with that. What's the justification given for using this model over the overlay option? **To avoid problems encountered with IP over ATM** ... sorry, wrong answer. OTN is not ATM. We (inc other operators) have made our feelings clear on the peer model. As far as I (as an operator with multiple clients) am concerned, it's a no-go option for my OTN. So if I'm to pretend that we have fully considered operators OTN requirements and came to a consensus on the reuse of IP control protocols, then I have to insist that vendors who want my money develop the overlay model first. Regards, Darren. -----Original Message----- From: Yakov Rekhter [mailto:yakov@cisco.com] Sent: 26 October 2000 03:51 To: Kireeti Kompella Cc: mpls@UU.NET; rbonica@mci.net Subject: Re: Two orthogonal issue Kireeti, [clipped...] > One thing that has come out of this debate is that carriers are > thinking more deeply about requirements, which is a welcome step > forward. At the same time, several deep-rooted biases are being > exposed, and I'll be the first to admit my bias towards using > MPLS/GMPLS for the control plane. There are fairly pragmatic reasons for using MPLS/GMPLS for the control plane - for more on this folks may read draft-awduche-mpls-te-optical-02.txt. Yakov. -------------------------------------------- > Disclaimer > > "The information and statements in this > email are supplied and made in good faith > and without prejudice. They do not > represent BT's only or final view or > position and are subject to any change > that BT may wish to make (including a > complete reversal). BT will not be liable > for any action you take or not take based > upon the contents of this email". -------------------------------------------- From owner-mpls@UU.NET Thu Oct 26 10:45:41 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24039 for ; Thu, 26 Oct 2000 10:45:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmow11044; Thu, 26 Oct 2000 14:44:34 GMT Received: by mail-control.mail.uu.net id QQjmow15237 for mpls-outgoing; Thu, 26 Oct 2000 14:44:03 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmow15232 for ; Thu, 26 Oct 2000 14:44:01 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmow01213 for ; Thu, 26 Oct 2000 14:43:59 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjmow18914 for ; Thu, 26 Oct 2000 14:43:58 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09922; Thu, 26 Oct 2000 10:43:55 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13299; Thu, 26 Oct 2000 10:43:57 -0400 (EDT) Message-ID: <39F84343.5D281862@marconi.com> Date: Thu, 26 Oct 2000 10:44:19 -0400 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Manal Afify CC: mpls@UU.NET Subject: Re: Question References: <39F752D6.9CBEEEEA@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Manal Afify wrote: > > As a general question: > > How does an LSR know when to swap, pop, or push a label...does it have > to be provisioned? It's not provisioned. It is signalled. The routers dynamically configure themselves to do this in reponse to the signalling packets (LDP or RSVP) that are used to establish the LSP in the first place. -- David From owner-mpls@UU.NET Thu Oct 26 11:01:25 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27540 for ; Thu, 26 Oct 2000 11:01:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmoy12433; Thu, 26 Oct 2000 15:00:56 GMT Received: by mail-control.mail.uu.net id QQjmoy18011 for mpls-outgoing; Thu, 26 Oct 2000 15:00:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmoy17950 for ; Thu, 26 Oct 2000 15:00:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmoy19137 for ; Thu, 26 Oct 2000 15:00:13 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmoy11300 for ; Thu, 26 Oct 2000 15:00:12 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA04404 for mpls@uu.net; Thu, 26 Oct 2000 11:00:11 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmox16212 for ; Thu, 26 Oct 2000 14:59:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmox01177 for ; Thu, 26 Oct 2000 14:59:21 GMT Received: from ogma.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjmox01391 for ; Thu, 26 Oct 2000 14:59:20 GMT Received: from london.cisco.com (london.cisco.com [144.254.32.10]) by ogma.cisco.com (Postfix) with ESMTP id EC85E199; Thu, 26 Oct 2000 16:59:19 +0200 (MET DST) Received: from jguichar-8kcdt.cisco.com (jguichar-isdn-home.cisco.com [10.49.131.222]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA09502; Thu, 26 Oct 2000 16:59:11 +0200 (MET DST) Message-Id: <200010261459.QAA09502@london.cisco.com> X-Sender: jguichar@uk.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 26 Oct 2000 15:56:21 +0100 To: Paul Doolan From: Jim Guichard Subject: Re: VPN solution - White flag ? Cc: Barry Hass , erosen@cisco.com, yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es In-Reply-To: <39F827F9.CC2165A3@ennovatenetworks.com> References: <200010261245.OAA15960@london.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk yes, exactly this. By doing this, the CE is able to learn full Internet routing information without the need to populate the PE with this information. The Internet exit point address needs to be available via the PE router and a default route within the PE VRF has to be available so that any destination that is not covered by a VPN route can be routed based on the default toward the exit point. From a CE perspective, all it needs to do is be able to reach the exit point and advertise its BGP peering address (next-hop) toward the PE router. Jim At 08:47 26/10/2000 -0400, Paul Doolan wrote: >Jim, > >>Other options include default routing from VPN sites to a >>central site that has Internet connectivity, another is to offload the >>Internet routes from the PE and run direct eBGP sessions from the VPN site >>to the Internet exit point. > > When you say 'VPN site' here are you suggesting that the CE router is > running eBGP with/to the 'Internet exit point' ? > > pd > Jim Guichard CCIE #2069 Network Design Consultant EMEA Global Solutions Engineering +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Thu Oct 26 11:08:04 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28978 for ; Thu, 26 Oct 2000 11:08:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmoy12130; Thu, 26 Oct 2000 15:06:57 GMT Received: by mail-control.mail.uu.net id QQjmoy28145 for mpls-outgoing; Thu, 26 Oct 2000 15:06:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmoy28121 for ; Thu, 26 Oct 2000 15:06:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmoy21091 for ; Thu, 26 Oct 2000 15:05:45 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmoy19563 for ; Thu, 26 Oct 2000 15:05:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA05660 for mpls@uu.net; Thu, 26 Oct 2000 11:05:44 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmoy28028 for ; Thu, 26 Oct 2000 15:05:21 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmoy16392 for ; Thu, 26 Oct 2000 15:03:08 GMT Received: from omega.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmoy15886 for ; Thu, 26 Oct 2000 15:03:08 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA20715; Thu, 26 Oct 2000 08:03:04 -0700 (PDT) Message-Id: <200010261503.IAA20715@omega.cisco.com> To: darren.freeland@bt.com cc: yakov@cisco.com, mpls@UU.NET, alan.mcguire@bt.com, andy.bd.reid@bt.com Subject: Re: Two orthogonal issue In-reply-to: Your message of "Thu, 26 Oct 2000 15:17:11 BST." <71DA16F18D32D2119A1D0000F8FE9A940920C781@mbtlipnt01.btlabs.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20713.972572584.1@cisco.com> Date: Thu, 26 Oct 2000 08:03:04 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Darren, > > There are fairly pragmatic reasons for using MPLS/GMPLS for > > the control plane - for more on this folks may read > > draft-awduche-mpls-te-optical-02.txt. > > I have read the draft. Twice. As far as I can see, the only real > justification given for using MPLS/GMPLS for optical control is the reuse of > existing protocols. Cool, I think we all agree that we don't want to > reinvent the wheel. Why not PNNI then? Why do you say that IP protocols > should be used for the control plane facets? Again, note that I'm not > advocating any particular approach just yet - I am saying that the > requirements of the OTN (or any other network in the case of GMPLS) should > be fully considered in the first place. The choice (and extensions) of > control plane protocols should then be made to fit requirements. > > Putting aside this questionable "okay, here is the answers - now what was > the question" type approach, I have another big problem with > draft-awduche-mpls-te-optical-02.txt. Lets pretend that we HAVE actually > fully considered operators requirements, and the major consensus among > operators is that the reuse of IP protocols is perfect for OTN. No, it is not "perfect" - it is just pragmatic. > If I'm to > start out on this approach with draft-awduche-mpls-te-optical-02.txt then > I'm going to be building my OTN for IP only. Could you point to any specific text in draft-awduche-mpls-te-optical-02.txt to support this ? > The draft shows a clear bias towards the peer option. Perhaps you should re-read the following (Section 8 of the draft): Essentially, there are two extremal architectural options for deployment of the proposed control plane in an operational context consisting of LSRs and OXCs. - Overlay Option: One option is to use different instances of the control plane in the OTN (OXC) and IP (LSR) domains. In this situation, each instance of the control plane will operate independent of the other. Interworking (including control coordination) between the two domains can be established through static configuration or through some other procedures that are outside the scope of this document. This partitioned and explicitely decoupled deployment option allows maximal control isolation between the OTN and IP domains. This scheme is conceptually similar to the model in use today, whereby the OTN simply provides point-to-point channels between IP network elements with very minimal control interaction between the two domains. - Peer Option: Another option is to use a single instance of the control plane that subsumes and spans LSRs and OXCs. Other architectural options are also possible which allow various degrees of control isolation and control integration between the OXCs and LSRs. To improve scalability the control plane may use routing hierarchy (e.g., routing areas). Hierarchy may be applied in either of the situations mentioned above. Furthermore, in the overlay option with different control plane instances for OXCs and LSRs, hierarchy could be enabled for each control plane instance independent of the other. In the deployment option with a single instance of the control plane, each routing area may maintain a link state database that contains: (1) physical LSPs (fiber links), (2) optical LSPs (optical channel trails), and (3) logical LSPs (conventional label switched paths). As a general rule, all of these path-oriented connection entities could simply be considered as LSPs with different characteristics. The origination LSR (the head-end) of each LSP entity may locally decide whether to advertise the LSP (with appropriate attributes), so that other LSRs could use it as a link for subsequent path computations. There are significant tradeoffs to the above deployment options, including aspects related to scalability and fault isolation. Additional documents to follow may elaborate on some of these aspects. One of the advantages of the control plane design approach described in this memo is that it potentially allows network administrators the leeway to make these deployment architectural decisions based on their specific objectives, network contexts, and service models. > I'm not happy with that. What's the justification > given for using this model over the overlay option? **To avoid problems > encountered with IP over ATM** ... sorry, wrong answer. OTN is not ATM. Yet from the IP routing point of view the overlay model has exactly the same problems, irrespective of whether the overlay is realized over ATM, or OTN, or X.25, etc... In other words, overlay is an overlay, irrespective of the underlying technology. > We (inc other operators) have made our feelings clear on the peer model. Yes, indeed, as indicated in the following e-mail from UUNet: Yong Xue> I think both overlay model and peer model should be supported. > As far as I (as an operator with multiple clients) am concerned, it's a no-go > option for my OTN. So if I'm to pretend that we have fully considered > operators OTN requirements and came to a consensus on the reuse of IP > control protocols, then I have to insist that vendors who want my money > develop the overlay model first. That would be fine. Yakov. > Regards, > Darren. > > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@cisco.com] > Sent: 26 October 2000 03:51 > To: Kireeti Kompella > Cc: mpls@UU.NET; rbonica@mci.net > Subject: Re: Two orthogonal issue > > > Kireeti, > > [clipped...] > > > One thing that has come out of this debate is that carriers are > > thinking more deeply about requirements, which is a welcome step > > forward. At the same time, several deep-rooted biases are being > > exposed, and I'll be the first to admit my bias towards using > > MPLS/GMPLS for the control plane. > > There are fairly pragmatic reasons for using MPLS/GMPLS for > the control plane - for more on this folks may read > draft-awduche-mpls-te-optical-02.txt. > > Yakov. > > -------------------------------------------- > > Disclaimer > > > > "The information and statements in this > > email are supplied and made in good faith > > and without prejudice. They do not > > represent BT's only or final view or > > position and are subject to any change > > that BT may wish to make (including a > > complete reversal). BT will not be liable > > for any action you take or not take based > > upon the contents of this email". > -------------------------------------------- From owner-mpls@UU.NET Thu Oct 26 11:10:19 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29513 for ; Thu, 26 Oct 2000 11:10:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmoy27516; Thu, 26 Oct 2000 15:09:24 GMT Received: by mail-control.mail.uu.net id QQjmoy28435 for mpls-outgoing; Thu, 26 Oct 2000 15:08:48 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmoy28400 for ; Thu, 26 Oct 2000 15:08:33 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmoy28867; Thu, 26 Oct 2000 15:08:28 GMT Received: from nexen.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maelstrom.nexen.com [204.249.97.5]) id QQjmoy26084; Thu, 26 Oct 2000 15:08:27 GMT Received: from phish.nexen.com (phish-98 [204.249.98.14]) by nexen.com (8.11.0/8.11.0) with ESMTP id e9QF8Sl21907; Thu, 26 Oct 2000 10:08:28 -0500 (EST) Received: from nexen.com (bhome [204.249.97.124]) by phish.nexen.com (8.8.5/8.8.5) with ESMTP id LAA24519; Thu, 26 Oct 2000 11:08:14 -0400 (EDT) Message-ID: <39F848E8.6AB0BC5@nexen.com> Date: Thu, 26 Oct 2000 11:08:25 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: David Allan , alchiu , ip-optical , mpls , sc , xuyg , yxue Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <200010261401.HAA17374@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > Mark, > > > The concept of jointly routing primary and protection paths has been > > well accepted by Bell heads looking at optimizing their networks for a > > long time. Part of the reason for this is the assumption that protection > > path(s) must also be conformant to the same SLA as the primary path, and > > joint routing is the most likely to achieve this. > > > > This does not of course address your concerns about race conditions at > > connection establishment. But joint routing is guaranteed to produce a > > solution not worse than independent routing, and results in a lower > > commitment of network resources. > > Moreover, in certain cases independent routing would not be able to > produce a solution at all, while joint routing would be able to produce > a solution. > > Yakov. > very true. As a general question though is anyone aware what work has been done on how best to recover should one of the above race conditions prevent the establishment of one of the paths? ciao Mark From owner-mpls@UU.NET Thu Oct 26 11:10:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29625 for ; Thu, 26 Oct 2000 11:10:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmoy25528; Thu, 26 Oct 2000 15:09:52 GMT Received: by mail-control.mail.uu.net id QQjmoy28443 for mpls-outgoing; Thu, 26 Oct 2000 15:09:06 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmoy28434 for ; Thu, 26 Oct 2000 15:08:47 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmoy21716 for ; Thu, 26 Oct 2000 15:08:42 GMT Received: from devmail.dev.tivoli.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136]) id QQjmoy14926 for ; Thu, 26 Oct 2000 15:08:41 GMT Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19]) by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id KAA08780 for ; Thu, 26 Oct 2000 10:08:40 -0500 (CDT) Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70]) by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id LAA01456 for ; Thu, 26 Oct 2000 11:11:31 -0400 (EDT) From: "Paul Tasillo" To: "mpls@UU. net" Subject: FW: Question Date: Thu, 26 Oct 2000 11:09:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Paul Tasillo wrote: > > It can be signaled, but you can provision with CLI and SNMP (when the MIBs > are supported). Isn't that what the drafts describe? > -Paul > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David > Charlap > Sent: Thursday, October 26, 2000 10:44 AM > To: Manal Afify > Cc: mpls@UU.NET > Subject: Re: Question > > Manal Afify wrote: > > > > As a general question: > > > > How does an LSR know when to swap, pop, or push a label...does it have > > to be provisioned? > > It's not provisioned. It is signalled. The routers dynamically > configure themselves to do this in reponse to the signalling packets > (LDP or RSVP) that are used to establish the LSP in the first place. > > -- David From owner-mpls@UU.NET Thu Oct 26 11:19:01 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01474 for ; Thu, 26 Oct 2000 11:19:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmox29983; Thu, 26 Oct 2000 14:58:32 GMT Received: by mail-control.mail.uu.net id QQjmox16177 for mpls-outgoing; Thu, 26 Oct 2000 14:58:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmox16172 for ; Thu, 26 Oct 2000 14:57:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmox09721; Thu, 26 Oct 2000 14:57:12 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjmox07080; Thu, 26 Oct 2000 14:57:12 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA07482; Thu, 26 Oct 2000 10:57:12 -0400 (EDT) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id KAA07461; Thu, 26 Oct 2000 10:57:11 -0400 (EDT) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA23508; Thu, 26 Oct 2000 10:57:10 -0400 Message-ID: <39F846BD.B394BB2C@hotair.hobl.lucent.com> Date: Thu, 26 Oct 2000 10:59:10 -0400 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: Mark Stewart , David Allan , alchiu , ip-optical , mpls , sc , xuyg , yxue Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <200010261401.HAA17374@omega.cisco.com> Content-Type: multipart/alternative; boundary="------------9B64BB5648386D31D9ACDB82" Sender: owner-mpls@UU.NET Precedence: bulk --------------9B64BB5648386D31D9ACDB82 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, Joint routing is expected to produce a solution which takes up less total resources compared to independent routing and, as was mentioned by me in a previous email from me and also noted below by Yakov, the latter may not produce a solution in certain cases even when the solution exists. This point is addressed in detail in the book "Survivable networks - Algorithms for Diverse Routing" (Chapter 3). Regards, Ramesh Yakov Rekhter wrote: > Mark, > > > The concept of jointly routing primary and protection paths has been > > well accepted by Bell heads looking at optimizing their networks for a > > long time. Part of the reason for this is the assumption that protection > > path(s) must also be conformant to the same SLA as the primary path, and > > joint routing is the most likely to achieve this. > > > > This does not of course address your concerns about race conditions at > > connection establishment. But joint routing is guaranteed to produce a > > solution not worse than independent routing, and results in a lower > > commitment of network resources. > > Moreover, in certain cases independent routing would not be able to > produce a solution at all, while joint routing would be able to produce > a solution. > > Yakov. > > > > > ciao > > > > mark > > > > > > > > > > > > > > David Allan wrote: > > > > > > > > > > > Angela: > > > > > > Jointly routing the paths intuitively does not strike me as optimal. > > > Not unless we are periodically performing path maintenance on the > > > entire set of network resources. I would have to assume that the > > > overall configuration of the network occurred incrementally, and with > > > a desire to minimize service interruption of the already established > > > paths. > > > > > > With that in mind, I would assume the routing of the primary path > > > should always be chosen as the optimal route. The backup path is then > > > required to be diverse (node, fiber, conduit, trench) with the optimal > > > primary path and would frequently be less optimal as the physical > > > routing would frequently be in the form of a longer path. > > > > > > I do not understand how whether this is done sequentially or > > > simultaneously affects these basics, except in the possible deadlock > > > scenario where the optimal routing of the primary path precludes a > > > viable backup. In the meantime, I would assume sequential > > > establishment of primary then backup would stand an overall greater > > > chance of success, especially if the path computing node does not have > > > a comprehensive and authoritative view of the network state. It > > > strikes me that routing the backup should have the ability to > > > intelligently crank back with knowledge of what to avoid to maintain > > > diversity with the primary path. > > > > > > regards > > > Dave > > > > > > -----Original Message----- > > > From: Angela Chiu [SMTP:alchiu@research.att.com] > > > Sent: Wednesday, October 25, 2000 10:03 AM > > > To: 'Yakov Rekhter' > > > Cc: ip-optical; mpls; sc; xuyg; yxue > > > Subject: RE: [IP-Optical] RE: Optical link bundling. Was > > > Re: DraftMinutes From Pittsburgh > > > > > > Yakov, > > > > > > Yes, you are right. Routing the primary and backup paths jointly > > > is always > > > more optimal than fixing the path for primary first then routing > > > the backup > > > accordingly. The same argument can be applied to comparing > > > centralized > > > routing with distributed routing. Even distributed routing is > > > less optimal, > > > it is the trend today. I think the real issue is at what cost the > > > additional > > > optimality is gained, and how much the additional optimality is > > > in a typical > > > network setting. In this case the cost is all the topological > > > information > > > including SRLG information as well as physical impairment > > > constraints in the > > > optical network that routers need to obtain in order to make > > > proper routing > > > decision. > > > > > > I have an idea, this will be a valid master/PhD thesis for some > > > graduate > > > students who would like to work on real world problems. > > > > > > Regards, > > > > > > Angela > > > > > > -----Original Message----- > > > From: ip-optical-admin@lists.bell-labs.com > > > [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Yakov > > > Rekhter > > > Sent: Wednesday, October 25, 2000 7:35 AM > > > To: alchiu@research.att.com > > > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com; > > > xuyg@lucent.com; yxue@UU.NET > > > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > > > DraftMinutes From Pittsburgh > > > > > > Angela, > > > > > > > Some followup discussions in line. > > > > > > more in line... > > > > > > > Regards, > > > > Angela > > > > > > > > -----Original Message----- > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > > Kireeti > > > > Kompella > > > > Sent: Monday, October 23, 2000 1:58 PM > > > > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com; > > > yxue@UU.NET > > > > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET > > > > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: > > > > DraftMinutes From Pittsburgh > > > > > > > > > > > > > I don't see why TE and protection require the routers to > > > specify > > > explicit > > > > > routes. > > > > > The routers can simply specify to the optical layer what type > > > of optical > > > > > layer protection > > > > > it requires. > > > > > > > > Suppose router A wants to get to router B, and wants to take > > > two > > > > different ingress and egress points in the optical domain, X->Y > > > > > > > for the primary LSP, and W->Z for the backup. A does not > > > require > > > > optical protection for the X->Y path, nor for the W->Z path. A > > > > > > > *does* require that the X->Y path and the W->Z path do not > > > share > > > > common links. How is this to be done? > > > > > > > > If A did the full path computation, this is simplicity itself. > > > > > > > > [AC] I think you have a good point here. I also heard the same > > > kind if > > > > reasoning (i.e., have a layer-3 like protection switching) for > > > supporting > > > > the peer model. But after discussing with others, it seems that > > > overlay > > > > model should be able to provide the same capability. > > > > > > Not really... for more on this see below... > > > > > > > Normally, the primary > > > > LSP X->Y is set up first, and becomes a forwarding adjacency > > > (FA) > > > according > > > > to your LSP Hierarchy draft. Then the associated information of > > > the FA > > > X->Y > > > > including its exact path and SRLG information should be > > > propagated via IGP > > > > extensions, same as with any other link in the network. Thus if > > > router A > > > > sends a request to OXC W to set up a backup lightpath from W->Z > > > to be > > > > diversely router from the existing FA X->Y, OXC W should > > > already have the > > > > right information to perform proper routing. > > > > > > It is a known fact that for computing disjoint paths the approach > > > > > > you outlined above may result in a situation where no backup > > > path will be found, despite the fact that that it is possible > > > (using some other approach) to find two disjoint paths. > > > > > > > Comparing with the peer model solution where routers need to > > > know all the > > > > SRLG information of the optical domain as well as all relevant > > > physical > > > > impairments in the optical signal in the case of transparent > > > optical > > > > network, it is still not clear to me which one is simpler. > > > > > > > > I think it is very good to have this kind of technical > > > discussion openly > > > on > > > > the list. Hope others can provide more technical and business > > > (after all > > > > carriers need to pay for these features) evidences for the need > > > of each > > > > model. Some other reasoning I heard includes that peer model > > > can improve > > > the > > > > IGP scalability in terms of the number of neighbors a router > > > needs to peer > > > > with. But since large ISPs today seem to cope well with the IGP > > > > > > scalability > > > > today, I don't see why the problem will get significant worst > > > when optical > > > > networks come into play. > > > > > > In the end it is not the discussion on this list, but the > > > competition > > > in the marketplace that will determine the viability of different > > > > > > models. > > > > > > Yakov. > > > > > > _______________________________________________ > > > IP-Optical mailing list > > > IP-Optical@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical > > > > > --------------9B64BB5648386D31D9ACDB82 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Folks,

Joint routing is expected to produce a solution which takes up less total resources compared to independent routing and, as was mentioned by me in a previous email from me and also noted below by Yakov, the latter may not produce a solution in certain cases even when the solution exists. This point is  addressed in detail in the book "Survivable networks - Algorithms for Diverse Routing" (Chapter 3).

Regards,

Ramesh

Yakov Rekhter wrote:

Mark,

> The concept of jointly routing primary and protection paths has been
> well accepted by Bell heads looking at optimizing their networks for a
> long time. Part of the reason for this is the assumption that protection
> path(s) must also be conformant to the same SLA as the primary path, and
> joint routing is the most likely to achieve this.
>
> This does not of course address your concerns about race conditions at
> connection establishment. But joint routing is guaranteed to produce a
> solution not worse than independent routing, and results in a lower
> commitment of network resources.

Moreover, in certain cases independent routing would not be able to
produce a solution at all, while joint routing would be able to produce
a solution.

Yakov.

>
> ciao
>
> mark
>
>
>
>
>
>
> David Allan wrote:
>
> >
> >
> > Angela:
> >
> > Jointly routing the paths intuitively does not strike me as optimal.
> > Not unless we are periodically performing path maintenance on the
> > entire set of network resources. I would have to assume that the
> > overall configuration of the network occurred incrementally, and with
> > a desire to minimize service interruption of the already established
> > paths.
> >
> > With that in mind, I would assume the routing of the primary path
> > should always be chosen as the optimal route. The backup path is then
> > required to be diverse (node, fiber, conduit, trench) with the optimal
> > primary path and would frequently be less optimal as the physical
> > routing would frequently be in the form of a longer path.
> >
> > I do not understand how whether this is done sequentially or
> > simultaneously affects these basics, except in the possible deadlock
> > scenario where the optimal routing of the primary path precludes a
> > viable backup. In the meantime, I would assume sequential
> > establishment of primary then backup would stand an overall greater
> > chance of success, especially if the path computing node does not have
> > a comprehensive and authoritative view of the network state. It
> > strikes me that routing the backup should have the ability to
> > intelligently crank back with knowledge of what to avoid to maintain
> > diversity with the primary path.
> >
> > regards
> > Dave
> >
> >      -----Original Message-----
> >      From:   Angela Chiu [SMTP:alchiu@research.att.com]
> >      Sent:   Wednesday, October 25, 2000 10:03 AM
> >      To:     'Yakov Rekhter'
> >      Cc:     ip-optical; mpls; sc; xuyg; yxue
> >      Subject:        RE: [IP-Optical] RE: Optical link bundling. Was
> >      Re: DraftMinutes From  Pittsburgh
> >
> >      Yakov,
> >
> >      Yes, you are right. Routing the primary and backup paths jointly
> >      is always
> >      more optimal than fixing the path for primary first then routing
> >      the backup
> >      accordingly. The same argument can be applied to comparing
> >      centralized
> >      routing with distributed routing. Even distributed routing is
> >      less optimal,
> >      it is the trend today. I think the real issue is at what cost the
> >      additional
> >      optimality is gained, and how much the additional optimality is
> >      in a typical
> >      network setting. In this case the cost is all the topological
> >      information
> >      including SRLG information as well as physical impairment
> >      constraints in the
> >      optical network that routers need to obtain in order to make
> >      proper routing
> >      decision.
> >
> >      I have an idea, this will be a valid master/PhD thesis for some
> >      graduate
> >      students who would like to work on real world problems.
> >
> >      Regards,
> >
> >      Angela
> >
> >      -----Original Message-----
> >      From: ip-optical-admin@lists.bell-labs.com
> >      [mailto:ip-optical-admin@lists.bell-labs.com]On Behalf Of Yakov
> >      Rekhter
> >      Sent: Wednesday, October 25, 2000 7:35 AM
> >      To: alchiu@research.att.com
> >      Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET; sc@tellium.com;
> >      xuyg@lucent.com; yxue@UU.NET
> >      Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re:
> >      DraftMinutes From Pittsburgh
> >
> >      Angela,
> >
> >      > Some followup discussions in line.
> >
> >      more in line...
> >
> >      > Regards,
> >      > Angela
> >      >
> >      > -----Original Message-----
> >      > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> >      Kireeti
> >      > Kompella
> >      > Sent: Monday, October 23, 2000 1:58 PM
> >      > To: kireeti@juniper.net; sc@tellium.com; xuyg@lucent.com;
> >      yxue@UU.NET
> >      > Cc: ip-optical@lists.bell-labs.com; mpls@UU.NET
> >      > Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re:
> >      > DraftMinutes From Pittsburgh
> >      >
> >      >
> >      > > I don't see why TE and protection require the routers to
> >      specify
> >      explicit
> >      > > routes.
> >      > > The routers can simply specify to the optical layer what type
> >      of optical
> >      > > layer protection
> >      > > it requires.
> >      >
> >      > Suppose router A wants to get to router B, and wants to take
> >      two
> >      > different ingress and egress points in the optical domain, X->Y
> >
> >      > for the primary LSP, and W->Z for the backup.  A does not
> >      require
> >      > optical protection for the X->Y path, nor for the W->Z path.  A
> >
> >      > *does* require that the X->Y path and the W->Z path do not
> >      share
> >      > common links.  How is this to be done?
> >      >
> >      > If A did the full path computation, this is simplicity itself.
> >      >
> >      > [AC] I think you have a good point here. I also heard the same
> >      kind if
> >      > reasoning (i.e., have a layer-3 like protection switching) for
> >      supporting
> >      > the peer model. But after discussing with others, it seems that
> >      overlay
> >      > model should be able to provide the same capability.
> >
> >      Not really... for more on this see below...
> >
> >      > Normally, the primary
> >      > LSP X->Y is set up first, and becomes a forwarding adjacency
> >      (FA)
> >      according
> >      > to your LSP Hierarchy draft. Then the associated information of
> >      the FA
> >      X->Y
> >      > including its exact path and SRLG information should be
> >      propagated via IGP
> >      > extensions, same as with any other link in the network. Thus if
> >      router A
> >      > sends a request to OXC W to set up a backup lightpath from W->Z
> >      to be
> >      > diversely router from the existing FA X->Y, OXC W should
> >      already have the
> >      > right information to perform proper routing.
> >
> >      It is a known fact that for computing disjoint paths the approach
> >
> >      you outlined above may result in a situation where no backup
> >      path will be found, despite the fact that that it is possible
> >      (using some other approach) to find two disjoint paths.
> >
> >      > Comparing with the peer model solution where routers need to
> >      know all the
> >      > SRLG information of the optical domain as well as all relevant
> >      physical
> >      > impairments in the optical signal in the case of transparent
> >      optical
> >      > network, it is still not clear to me which one is simpler.
> >      >
> >      > I think it is very good to have this kind of technical
> >      discussion openly
> >      on
> >      > the list. Hope others can provide more technical and business
> >      (after all
> >      > carriers need to pay for these features) evidences for the need
> >      of each
> >      > model. Some other reasoning I heard includes that peer model
> >      can improve
> >      the
> >      > IGP scalability in terms of the number of neighbors a router
> >      needs to peer
> >      > with. But since large ISPs today seem to cope well with the IGP
> >
> >      scalability
> >      > today, I don't see why the problem will get significant worst
> >      when optical
> >      > networks come into play.
> >
> >      In the end it is not the discussion on this list, but the
> >      competition
> >      in the marketplace that will determine the viability of different
> >
> >      models.
> >
> >      Yakov.
> >
> >      _______________________________________________
> >      IP-Optical mailing list
> >      IP-Optical@lists.bell-labs.com
> >      http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
>

--------------9B64BB5648386D31D9ACDB82-- From owner-mpls@UU.NET Thu Oct 26 11:21:02 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01931 for ; Thu, 26 Oct 2000 11:21:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmoz00716; Thu, 26 Oct 2000 15:20:02 GMT Received: by mail-control.mail.uu.net id QQjmoz29423 for mpls-outgoing; Thu, 26 Oct 2000 15:19:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmoz29418 for ; Thu, 26 Oct 2000 15:19:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmoz16939 for ; Thu, 26 Oct 2000 15:19:02 GMT From: darren.freeland@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjmoz08199 for ; Thu, 26 Oct 2000 15:19:02 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 26 Oct 2000 16:18:16 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Thu, 26 Oct 2000 16:18:13 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C785@mbtlipnt01.btlabs.bt.co.uk> To: yakov@cisco.com, darren.freeland@bt.com Cc: mpls@UU.NET, alan.mcguire@bt.com, andy.bd.reid@bt.com Subject: RE: Two orthogonal issue Date: Thu, 26 Oct 2000 16:16:54 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yakov, >>> Putting aside this questionable "okay, here is the answers - now what was >>> the question" type approach, I have another big problem with >>> draft-awduche-mpls-te-optical-02.txt. Lets pretend that we HAVE actually >>> fully considered operators requirements, and the major consensus among >>> operators is that the reuse of IP protocols is perfect for OTN. > > No, it is not "perfect" - it is just pragmatic. So you consider coming up with the answers prior to fully asking the questions to be prgamatic? >>> If I'm to >>> start out on this approach with draft-awduche-mpls-te-optical-02.txt then >>> I'm going to be building my OTN for IP only. > > Could you point to any specific text in draft-awduche-mpls-te-optical-02.txt > to support this ? It's implicit from the part of text that has clear bias towards the peer model (see below). For reasons that I'm not going into again because they've been beated out on this list over the last week or so (see a number of previous mails from myself & Neil Harrison with regards to client/server relationships). >>> The draft shows a clear bias towards the peer option. > > Perhaps you should re-read the following (Section 8 of the draft): And perhaps you should re-read the following (section 6 of the draft): Given that that both OXCs and LSRs require control planes, one option would be to have two separate, independent, and incompatible control planes - one for OXCs, and another for LSRs. To understand the drawbacks of this approach, especially in IP-centric optical internetworking systems, one need to look no further than the experience with IP over ATM, where IP has its own control plane (BGP, IS-IS, OSPF), and ATM its own control plane (PNNI) [12]. For some of the drawbacks see [1,2]. Given that the control planes for both OXCs and LSRs have relatively similar requirements, an alternative approach is to develop a coherent control plane technology that can be used for LSRs and for OXCs. Such a uniform control plane will eliminate the administrative complexity of managing hybrid optical internetworking systems with separate, dissimilar control and operational semantics. Specializations may be introduced in the control plane, as necessary, to account for inherent peculiarities of the underlying technologies and networking contexts. All of the above observations suggest, therefore, that the MPLS Traffic Engineering control plane (with some minor extensions) would be very suitable as the control plane for OXCs. An OXC that uses the MPLS traffic engineering control plane would effectively become an IP addressable device. Thus, this proposition also solves the problem of addressing for OXCs. >>> As far as I (as an operator with multiple clients) am concerned, it's a no-go >>> option for my OTN. So if I'm to pretend that we have fully considered >>> operators OTN requirements and came to a consensus on the reuse of IP >>> control protocols, then I have to insist that vendors who want my money >>> develop the overlay model first. > > That would be fine. Thank you. Darren. > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@cisco.com] > Sent: 26 October 2000 03:51 > To: Kireeti Kompella > Cc: mpls@UU.NET; rbonica@mci.net > Subject: Re: Two orthogonal issue > > > Kireeti, > > [clipped...] > > > One thing that has come out of this debate is that carriers are > > thinking more deeply about requirements, which is a welcome step > > forward. At the same time, several deep-rooted biases are being > > exposed, and I'll be the first to admit my bias towards using > > MPLS/GMPLS for the control plane. > > There are fairly pragmatic reasons for using MPLS/GMPLS for > the control plane - for more on this folks may read > draft-awduche-mpls-te-optical-02.txt. > > Yakov. > > -------------------------------------------- > > Disclaimer > > > > "The information and statements in this > > email are supplied and made in good faith > > and without prejudice. They do not > > represent BT's only or final view or > > position and are subject to any change > > that BT may wish to make (including a > > complete reversal). BT will not be liable > > for any action you take or not take based > > upon the contents of this email". > -------------------------------------------- From owner-mpls@UU.NET Thu Oct 26 11:23:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02584 for ; Thu, 26 Oct 2000 11:23:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmoz04778; Thu, 26 Oct 2000 15:22:44 GMT Received: by mail-control.mail.uu.net id QQjmoz29575 for mpls-outgoing; Thu, 26 Oct 2000 15:22:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmoz29563 for ; Thu, 26 Oct 2000 15:22:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmoz24791 for ; Thu, 26 Oct 2000 15:21:36 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmoz03110 for ; Thu, 26 Oct 2000 15:21:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA08973 for mpls@uu.net; Thu, 26 Oct 2000 11:21:34 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmoz29493 for ; Thu, 26 Oct 2000 15:20:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmoz07011 for ; Thu, 26 Oct 2000 15:20:45 GMT Received: from no-worries.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: no-worries.cisco.com [144.254.148.250]) id QQjmoz10487 for ; Thu, 26 Oct 2000 15:20:43 GMT Received: from DAPATTERLAPTOP (syd-vpdn-client-100.cisco.com [144.254.145.101]) by no-worries.cisco.com (8.8.8+Sun/8.8.8) with SMTP id CAA14952; Fri, 27 Oct 2000 02:19:32 +1100 (EST) From: "Darren Patterson" To: "Barry Hass" , "Rob Jaeger" , "Juan Diego Otero" Cc: "Wenbo Sheng" , "MPLS WG" Subject: RE: VPN solution Date: Thu, 26 Oct 2000 23:15:06 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit L2 - simple transport from service providers perspective, does not require knowledge of customer ip addressing or routing topology, also means less provisioning overhead in the core as the lsp's are dynamically created unlike n^2 issues. from the customer's perspective not much over their traditional existing fr / atm / ll type services ( i might be overlooking something here). L3 - from the service providers side the ability to offer enhanced ip services which provides qos capabilites to the customer and can provide things like differential billing and sla's based upon these types of services. so for the provider incremental revenues, whilst lowering the costs of operation as it also uses dynamic creation of the lsp's in the core just like L2. more importantly from the customers perspective they are getting a tailored service which can provide integrated services and guarantees whilst lowering their cost. basically a network service built for their network traffic type - ip (assuming this is their network traffic type and they are not running other types of protocols). these are just a few of the top of my head quickly. regards > -----Original Message----- > From: Barry Hass [mailto:BHass@nexabit.com] > Sent: Thursday, 26 October 2000 8:16 PM > To: Darren Patterson; Rob Jaeger; Juan Diego Otero > Cc: Wenbo Sheng; MPLS WG > Subject: RE: VPN solution > > > Darren, > > Could you elaborate on what you think are the relative > strengths and weaknesses of L2 and L3 VPNs, and what > yout think are the most appropriate uses of each? > > Thanks. > > > > -----Original Message----- > > From: Darren Patterson [mailto:dapatter@cisco.com] > > Sent: Thursday, October 26, 2000 6:14 AM > > To: Rob Jaeger; Juan Diego Otero > > Cc: Wenbo Sheng; MPLS WG > > Subject: RE: VPN solution > > > > > > I would have argued that l2 and l3 vpns would co-exist on any > > providers > > network and be sold and used where appropriate. i dont think these are > > mutually exclusive, but rather complimentary...the real > > arguement is on the > > model used for l3 vpn's. > > > > regards > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Rob > > > Jaeger > > > Sent: Wednesday, 25 October 2000 9:40 PM > > > To: Juan Diego Otero > > > Cc: Wenbo Sheng; MPLS WG > > > Subject: Re: VPN solution > > > > > > > > > > > > Juan/Wenbo, > > > > > > An alternative to draft-rosen-rfc2547bis is l2vpn as described in > > > draft-kompella-mpls-l2vpn-01.txt . One advantage of this > > method is the > > > separation of administrative responsibilities. In MPLS L2VPNs, the > > > service provider does not participate in the customer's L3 > > routing. This > > > may provide better stability than L3 VPNs. > > > > > > Rob > > > > > > > > > On Wed, 25 Oct 2000, Juan Diego Otero wrote: > > > > > > > Hi Wenbo, > > > > > > > > The method to build VPNs most discussed (and that makes me think > > > > that is the most popular) in this mailing list is > > > > the BGP/MPLS model explained in draft-rosen-rfc2547bis-02.txt > > > . Personally I > > > > think this method has a lot of advantages such as scalability, > > > security, manageability > > > > and use of private addressing. Some of this advantages > > > (specially scalability) have been > > > > discussed in this mailing list. > > > > > > > > Best Regards, > > > > > > > > Diego > > > > > > > > Wenbo Sheng wrote: > > > > HI, > > > > > > > > Assuming my customer need to create a VPN, I just want to > > > know which solution is better - using > > > > MPLS-VPN or virtual routers? Which solution is/will be > > > more popular in creating a VPN? > > > > > > > > Thanks in advance, > > > > > > > > W.S. > > > > > > > > > > > > -- > > > > http://www.geocities.com/diego_otero/ > > > > > > > > > > From owner-mpls@UU.NET Thu Oct 26 11:27:35 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03389 for ; Thu, 26 Oct 2000 11:27:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmoz19862; Thu, 26 Oct 2000 15:26:42 GMT Received: by mail-control.mail.uu.net id QQjmoz29911 for mpls-outgoing; Thu, 26 Oct 2000 15:26:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmoz29826 for ; Thu, 26 Oct 2000 15:25:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmoz21402 for ; Thu, 26 Oct 2000 15:25:16 GMT Received: from devmail.dev.tivoli.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136]) id QQjmoz09705 for ; Thu, 26 Oct 2000 15:25:15 GMT Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19]) by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id KAA10260; Thu, 26 Oct 2000 10:25:11 -0500 (CDT) Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70]) by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id LAA01586; Thu, 26 Oct 2000 11:28:02 -0400 (EDT) From: "Paul Tasillo" To: "Christian Kuhtz" Cc: "mpls@UU. net" Subject: RE: FW: Question Date: Thu, 26 Oct 2000 11:26:26 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20001026111527.A25877@ns1.arch.bellsouth.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Christian- Its not that I'm advocating it. I'm just describing what I've read in the drafts. Look at http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-06.txt If you have security issues, use SNMPv3 with security and authentication. -Paul -----Original Message----- From: Christian Kuhtz [mailto:ck@arch.bellsouth.net] Sent: Thursday, October 26, 2000 11:15 AM To: Paul Tasillo Subject: Re: FW: Question On Thu, Oct 26, 2000 at 11:09:55AM -0400, Paul Tasillo wrote: > Paul Tasillo wrote: > > > > It can be signaled, but you can provision with CLI and SNMP (when the MIBs > > are supported). Isn't that what the drafts describe? > > -Paul Errr... you're advocating SNMP writes in an SP network? Some people have security policies expressly prohibiting that. CLI, or whatever other methods the various vendors provide. -- Christian Kuhtz Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." From owner-mpls@UU.NET Thu Oct 26 11:33:15 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04674 for ; Thu, 26 Oct 2000 11:33:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpa19567; Thu, 26 Oct 2000 15:32:29 GMT Received: by mail-control.mail.uu.net id QQjmpa00351 for mpls-outgoing; Thu, 26 Oct 2000 15:32:03 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmpa00339 for ; Thu, 26 Oct 2000 15:31:52 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmpa14467 for ; Thu, 26 Oct 2000 15:31:10 GMT Received: from smtprch1.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjmpa26038 for ; Thu, 26 Oct 2000 15:31:09 GMT Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Thu, 26 Oct 2000 10:16:56 -0500 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VTYP4CVW; Thu, 26 Oct 2000 11:16:51 -0400 Received: from americasm01.nt.com (wcars1du.ca.nortel.com [47.14.80.164]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VNHG1KJA; Thu, 26 Oct 2000 11:16:50 -0400 Message-ID: <39F84AE1.DC7EF783@americasm01.nt.com> Date: Thu, 26 Oct 2000 11:16:50 -0400 From: "Hamid Ould-Brahim" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Tasillo CC: "mpls@UU. net" , nbvpn@bbo.com Subject: Re: FW: VPN solution - White flag ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Paul, Your scalability question is really related to PE's resources (e.g., CPU, memory) On this respect building vpns with virtual routers is no different than any other application VPN/PE scalability depends also on factors like the software/hardware architecture of the PE and whether the "virtualization" aspect of VR is built in within the PE infrastructure day one. However no matter how powerful is the PE, there is always a limit on what you can do on it. Regards Hamid Paul Tasillo wrote: > Will the overhead of running Virtual Routers impact the scalablity of the > draft-ouldbrahim-vpn-vr-01 approach? That is, there must be a limit to the > number of VRs a PE can handle and thus a limit to the number of VPNs the PE > can handle. Is this true? > > -Paul (not Paul Doolan) > Paul Tasillo > Tivoli Systems > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim > Guichard > Sent: Thursday, October 26, 2000 8:43 AM > To: Barry Hass; erosen@cisco.com; Paul Doolan > Cc: yakov@cisco.com; rnewcomb@ennovatenetowrks.com.tivoli.com; > mpls@UU.NET; diego@estos.upc.es > Subject: RE: VPN solution - White flag ? > > Barry, > > the answer is no. There are various ways to design Internet connectivity > within this environment, one of which is to carry full Internet routes on > the PE router. Other options include default routing from VPN sites to a > central site that has Internet connectivity, another is to offload the > Internet routes from the PE and run direct eBGP sessions from the VPN site > to the Internet exit point. Which option is actually taken will depend on > the specific design requirements. Jim > > At 08:37 26/10/2000 -0400, Barry Hass wrote: > >Eric, > > > >Doesn't a PE router have to handle the full Internet routing > >table, plus VRFs for whatever VPNs it is supporting? I think > >that what some folks are suggesting is that BGP (not "the box", > >but BGP specifically) is already bumping up against scaling > >limits at 100,000 or so routes, and that burdening it with the > >additional responsibility of managing VPNs is not such a great > >idea. ("Some folks" please correct me if I'm wrong). Can you > >comment on that? > > > >By the way, I don't have enough information to have an opinion > >on this. I'm just trying to steer the discussion back to what > >I thought was an interesting technical question before the > >insults started to fly. > > > >> In the NBVPN routing environment, it is not true that > >> anyone in the world > >> needs to be able to reach anyone else in the world. Each > >> VPN has its own > >> inter-connectivity matrix, much smaller than the > >> Internet connectivity > >> matrix. Now if you add up all the VPN routes, summed over > >> all VPNs, you may > >> indeed get a much larger number than the number of > >> Internet routes. But > >> there is no one box which needs to hold them all. Since an > >> instance of BGP > >> runs in a particular box, and only has to deal with the > >> routes that need to > >> be in that box, you don't run up against the same box > >> scaling problems you > >> run up against in the Internet routing environment. You > >> can design your > >> system to have a given box handle as many routes or as few > >> routes as you > >> want. > > > > Jim Guichard CCIE #2069 > Network Design Consultant EMEA > Global Solutions Engineering > > +44 208 756 8806 > Mobile: +44 7802 809763 From owner-mpls@UU.NET Thu Oct 26 11:46:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07700 for ; Thu, 26 Oct 2000 11:46:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpb15059; Thu, 26 Oct 2000 15:45:00 GMT Received: by mail-control.mail.uu.net id QQjmpa01060 for mpls-outgoing; Thu, 26 Oct 2000 15:44:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmpa01051 for ; Thu, 26 Oct 2000 15:44:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmpa19046 for ; Thu, 26 Oct 2000 15:43:50 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmpa13413 for ; Thu, 26 Oct 2000 15:43:49 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04867; Thu, 26 Oct 2000 08:43:08 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA24604; Thu, 26 Oct 2000 11:43:09 -0400 (EDT) Message-Id: <200010261543.LAA24604@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Barry Hass cc: Paul Doolan , yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? In-reply-to: Your message of Thu, 26 Oct 2000 08:37:21 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 Oct 2000 11:43:08 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Barry> Doesn't a PE router have to handle the full Internet routing table, Barry> plus VRFs for whatever VPNs it is supporting? No. A PE router doesn't necessarily have to have any of the Internet routing table at all, because Internet access doesn't have to be offered as part of the VPN service, and even if it is, it doesn't have to be offered via an interface to the same PE. Many providers and their customers are actually more comfortable with a clean separation of Internet access from VPN service. For the case in which Internet access and VPN service are offered via the same PE, it still is generally not necessary to bring the full set of Internet routes to the edge, as Jim as indicated. I can certainly see that this is a mismatch with the default-free Tier 1 ISP that hopes to offer "VPN service" as a sideline in order to sell some of its excess bandwidth. That just isn't the target market for the scheme. If an ISP wants a sideline in order to sell excess bandwidth, selling a layer 2 service might well be the best way to go. One size doesn't fit all. You will notice that our documents tend to speak of "SPs" rather than "ISPs". Barry> I think that what some folks are suggesting is that BGP (not "the Barry> box", but BGP specifically) is already bumping up against scaling Barry> limits at 100,000 or so routes, and that burdening it with the Barry> additional responsibility of managing VPNs is not such a great idea BGP runs in a box. The amount of state it needs to manipulate, the amount of messaging it needs to do, the amount of computation it needs to do, is largely a function of the number of routes which the box needs to maintain. I am always at pains to emphasize that the Internet routes and the VPN routes are not just thrown together in a big mishmash, but I don't seem to have succeeded in making this clear. Paul> When you say 'VPN site' here are you suggesting that the CE router Paul> is running eBGP with/to the 'Internet exit point' ? The point is that in those cases where the CE router wants to run EBGP to import Internet routes into the enterprise network, the EBGP peer does not have to be the PE router. But there is no requirement on the part of the VPN scheme that the CE router import the Internet routes. From owner-mpls@UU.NET Thu Oct 26 12:00:12 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10799 for ; Thu, 26 Oct 2000 12:00:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpb05363; Thu, 26 Oct 2000 15:59:34 GMT Received: by mail-control.mail.uu.net id QQjmpb02218 for mpls-outgoing; Thu, 26 Oct 2000 15:59:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmpb02210 for ; Thu, 26 Oct 2000 15:58:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmpb03221 for ; Thu, 26 Oct 2000 15:58:08 GMT Received: from rimmer.orchestream.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.orchestream.com [195.153.64.98]) id QQjmpb05110 for ; Thu, 26 Oct 2000 15:58:08 GMT Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id QAA32135; Thu, 26 Oct 2000 16:55:14 +0100 Received: by s1000.orchestream.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 16:55:38 +0100 Message-ID: From: "Morgan, Richard" To: "'Hamid Ould-Brahim'" , Paul Tasillo Cc: "mpls@UU. net" , nbvpn@bbo.com Subject: RE: FW: VPN solution - White flag ? Date: Thu, 26 Oct 2000 16:55:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Does the Virtual Router soluntion take advantage of the 'hierrachy of routing knowledge' ie use two labels, one to get the PE and another to identify the VR - or does it create individual LSP's between each other VR's and not use the label stack ? Richard Morgan > -----Original Message----- > From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] > Sent: Thursday, October 26, 2000 4:17 PM > To: Paul Tasillo > Cc: mpls@UU. net; nbvpn@bbo.com > Subject: Re: FW: VPN solution - White flag ? > > > Paul, > > Your scalability question is really related to PE's resources > (e.g., CPU, > memory) > On this respect building vpns with virtual routers is > no different than any other application > > VPN/PE scalability depends also on factors like the software/hardware > architecture of the PE and whether the "virtualization" > aspect of VR is > built in within the PE infrastructure day one. > > However no matter how powerful is the PE, there is always a limit > on what you can do on it. > > Regards > Hamid > > > Paul Tasillo wrote: > > > Will the overhead of running Virtual Routers impact the > scalablity of the > > draft-ouldbrahim-vpn-vr-01 approach? That is, there must be > a limit to the > > number of VRs a PE can handle and thus a limit to the > number of VPNs the PE > > can handle. Is this true? > > > > -Paul (not Paul Doolan) > > Paul Tasillo > > Tivoli Systems > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim > > Guichard > > Sent: Thursday, October 26, 2000 8:43 AM > > To: Barry Hass; erosen@cisco.com; Paul Doolan > > Cc: yakov@cisco.com; rnewcomb@ennovatenetowrks.com.tivoli.com; > > mpls@UU.NET; diego@estos.upc.es > > Subject: RE: VPN solution - White flag ? > > > > Barry, > > > > the answer is no. There are various ways to design Internet > connectivity > > within this environment, one of which is to carry full > Internet routes on > > the PE router. Other options include default routing from > VPN sites to a > > central site that has Internet connectivity, another is to > offload the > > Internet routes from the PE and run direct eBGP sessions > from the VPN site > > to the Internet exit point. Which option is actually taken > will depend on > > the specific design requirements. Jim > > > > At 08:37 26/10/2000 -0400, Barry Hass wrote: > > >Eric, > > > > > >Doesn't a PE router have to handle the full Internet routing > > >table, plus VRFs for whatever VPNs it is supporting? I think > > >that what some folks are suggesting is that BGP (not "the box", > > >but BGP specifically) is already bumping up against scaling > > >limits at 100,000 or so routes, and that burdening it with the > > >additional responsibility of managing VPNs is not such a great > > >idea. ("Some folks" please correct me if I'm wrong). Can you > > >comment on that? > > > > > >By the way, I don't have enough information to have an opinion > > >on this. I'm just trying to steer the discussion back to what > > >I thought was an interesting technical question before the > > >insults started to fly. > > > > > >> In the NBVPN routing environment, it is not true that > > >> anyone in the world > > >> needs to be able to reach anyone else in the world. Each > > >> VPN has its own > > >> inter-connectivity matrix, much smaller than the > > >> Internet connectivity > > >> matrix. Now if you add up all the VPN routes, summed over > > >> all VPNs, you may > > >> indeed get a much larger number than the number of > > >> Internet routes. But > > >> there is no one box which needs to hold them all. Since an > > >> instance of BGP > > >> runs in a particular box, and only has to deal with the > > >> routes that need to > > >> be in that box, you don't run up against the same box > > >> scaling problems you > > >> run up against in the Internet routing environment. You > > >> can design your > > >> system to have a given box handle as many routes or as few > > >> routes as you > > >> want. > > > > > > > Jim Guichard CCIE #2069 > > Network Design Consultant EMEA > > Global Solutions Engineering > > > > +44 208 756 8806 > > Mobile: +44 7802 809763 > From owner-mpls@UU.NET Thu Oct 26 12:16:46 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15289 for ; Thu, 26 Oct 2000 12:16:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpd27810; Thu, 26 Oct 2000 16:15:47 GMT Received: by mail-control.mail.uu.net id QQjmpd14936 for mpls-outgoing; Thu, 26 Oct 2000 16:15:04 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmpc14830 for ; Thu, 26 Oct 2000 16:14:56 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmpc02771 for ; Thu, 26 Oct 2000 16:14:13 GMT Received: from roam.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: roam.psg.com [147.28.4.2]) id QQjmpc27476 for ; Thu, 26 Oct 2000 16:14:12 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13opdu-0004w7-00; Thu, 26 Oct 2000 09:12:38 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jim Guichard Cc: Barry Hass , erosen@cisco.com, Paul Doolan , yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: RE: VPN solution - White flag ? References: <200010261245.OAA15960@london.cisco.com> Message-Id: Date: Thu, 26 Oct 2000 09:12:38 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit and which one will work for a large isp with lots of vpn customers and lots of connections to other peer isps? > the answer is no. There are various ways to design Internet connectivity > within this environment, one of which is to carry full Internet routes on > the PE router. Other options include default routing from VPN sites to a > central site that has Internet connectivity, another is to offload the > Internet routes from the PE and run direct eBGP sessions from the VPN site > to the Internet exit point. Which option is actually taken will depend on > the specific design requirements. Jim > > At 08:37 26/10/2000 -0400, Barry Hass wrote: > >Eric, > > > >Doesn't a PE router have to handle the full Internet routing > >table, plus VRFs for whatever VPNs it is supporting? I think > >that what some folks are suggesting is that BGP (not "the box", > >but BGP specifically) is already bumping up against scaling > >limits at 100,000 or so routes, and that burdening it with the > >additional responsibility of managing VPNs is not such a great > >idea. ("Some folks" please correct me if I'm wrong). Can you > >comment on that? > > > >By the way, I don't have enough information to have an opinion > >on this. I'm just trying to steer the discussion back to what > >I thought was an interesting technical question before the > >insults started to fly. > > > >> In the NBVPN routing environment, it is not true that > >> anyone in the world > >> needs to be able to reach anyone else in the world. Each > >> VPN has its own > >> inter-connectivity matrix, much smaller than the > >> Internet connectivity > >> matrix. Now if you add up all the VPN routes, summed over > >> all VPNs, you may > >> indeed get a much larger number than the number of > >> Internet routes. But > >> there is no one box which needs to hold them all. Since an > >> instance of BGP > >> runs in a particular box, and only has to deal with the > >> routes that need to > >> be in that box, you don't run up against the same box > >> scaling problems you > >> run up against in the Internet routing environment. You > >> can design your > >> system to have a given box handle as many routes or as few > >> routes as you > >> want. > > > > > Jim Guichard CCIE #2069 > Network Design Consultant EMEA > Global Solutions Engineering > > +44 208 756 8806 > Mobile: +44 7802 809763 > From owner-mpls@UU.NET Thu Oct 26 12:17:57 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15576 for ; Thu, 26 Oct 2000 12:17:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpd20555; Thu, 26 Oct 2000 16:16:44 GMT Received: by mail-control.mail.uu.net id QQjmpd15099 for mpls-outgoing; Thu, 26 Oct 2000 16:16:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmpd15060 for ; Thu, 26 Oct 2000 16:15:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmpc05326 for ; Thu, 26 Oct 2000 16:14:20 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmpc17363 for ; Thu, 26 Oct 2000 16:14:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA08497 for ; Thu, 26 Oct 2000 09:14:18 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA24689 for mpls@uu.net; Thu, 26 Oct 2000 12:14:16 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmnv29865 for ; Thu, 26 Oct 2000 07:52:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmnv17291 for ; Thu, 26 Oct 2000 07:49:55 GMT Received: from tiny-teddy.aarnet.edu.au by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tiny-teddy.aarnet.edu.au [203.21.37.30]) id QQjmnv05614 for ; Thu, 26 Oct 2000 07:49:52 GMT Received: from aarnet.edu.au (bush.aarnet.adelaide.edu.au [129.127.80.130]) by tiny-teddy.aarnet.edu.au (8.9.3/8.9.3) with ESMTP id RAA16878 for ; Thu, 26 Oct 2000 17:19:49 +0930 Message-ID: <39F7E27C.8812740D@aarnet.edu.au> Date: Thu, 26 Oct 2000 17:21:24 +0930 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "'mpls@UU.NET'" Subject: Re: LSP failure detection References: <91E486361D4CD311B3140060089A882556A4A4@hermes.hyperchip.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Detection: > > # Hardware notifies you of a failure > # Software detects a failure through keep-alives, time-outs, etc... As far as I can tell, currently defined IP keepalives don't really cut it. For example most vendors have a minimum keepalive interval of 1 second and require 3 lost keepalives before marking the link as down. Similarly for OSPF HELLOs. Is there a special MPLS keepalive defined that allows subsecond detection of a forwarding failure? Or is such a beast yet to be engineered? -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised From owner-mpls@UU.NET Thu Oct 26 12:26:04 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17322 for ; Thu, 26 Oct 2000 12:26:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpd01662; Thu, 26 Oct 2000 16:25:14 GMT Received: by mail-control.mail.uu.net id QQjmpd15673 for mpls-outgoing; Thu, 26 Oct 2000 16:24:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmpd15668 for ; Thu, 26 Oct 2000 16:24:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmpd03895 for ; Thu, 26 Oct 2000 16:24:01 GMT Received: from roam.psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: roam.psg.com [147.28.4.2]) id QQjmpd29948 for ; Thu, 26 Oct 2000 16:24:00 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13opoo-0004wt-00; Thu, 26 Oct 2000 09:23:54 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jim Guichard Cc: Paul Doolan , Barry Hass , erosen@cisco.com, yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? References: <200010261245.OAA15960@london.cisco.com> <200010261459.QAA09502@london.cisco.com> Message-Id: Date: Thu, 26 Oct 2000 09:23:54 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit the problem is that an isp has *many* 'exits' to the internet, like dozens. > yes, exactly this. By doing this, the CE is able to learn full Internet > routing information without the need to populate the PE with this > information. The Internet exit point address needs to be available via the > PE router and a default route within the PE VRF has to be available so that > any destination that is not covered by a VPN route can be routed based on > the default toward the exit point. From a CE perspective, all it needs to > do is be able to reach the exit point and advertise its BGP peering address > (next-hop) toward the PE router. Jim > > At 08:47 26/10/2000 -0400, Paul Doolan wrote: > >Jim, > > > >>Other options include default routing from VPN sites to a > >>central site that has Internet connectivity, another is to offload the > >>Internet routes from the PE and run direct eBGP sessions from the VPN site > >>to the Internet exit point. > > > > When you say 'VPN site' here are you suggesting that the CE router is > > running eBGP with/to the 'Internet exit point' ? > > > > pd > > > > > Jim Guichard CCIE #2069 > Network Design Consultant EMEA > Global Solutions Engineering > > +44 208 756 8806 > Mobile: +44 7802 809763 > From owner-mpls@UU.NET Thu Oct 26 12:36:33 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19615 for ; Thu, 26 Oct 2000 12:36:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpe25552; Thu, 26 Oct 2000 16:35:34 GMT Received: by mail-control.mail.uu.net id QQjmpe16293 for mpls-outgoing; Thu, 26 Oct 2000 16:35:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmpe16284 for ; Thu, 26 Oct 2000 16:34:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmpe23166 for ; Thu, 26 Oct 2000 16:33:54 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmpe21831 for ; Thu, 26 Oct 2000 16:33:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA21911 for mpls@uu.net; Thu, 26 Oct 2000 12:33:52 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmpe16256 for ; Thu, 26 Oct 2000 16:33:27 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmpe07759 for ; Thu, 26 Oct 2000 16:33:06 GMT Received: from ogma.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjmpe22276 for ; Thu, 26 Oct 2000 16:33:05 GMT Received: from london.cisco.com (london.cisco.com [144.254.32.10]) by ogma.cisco.com (Postfix) with ESMTP id 3FB1EEF; Thu, 26 Oct 2000 18:33:05 +0200 (MET DST) Received: from jguichar-8kcdt.cisco.com (jguichar-isdn-home.cisco.com [10.49.131.222]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id SAA05865; Thu, 26 Oct 2000 18:33:03 +0200 (MET DST) Message-Id: <200010261633.SAA05865@london.cisco.com> X-Sender: jguichar@uk.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 26 Oct 2000 17:30:09 +0100 To: Randy Bush From: Jim Guichard Subject: RE: VPN solution - White flag ? Cc: Barry Hass , erosen@cisco.com, Paul Doolan , yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es In-Reply-To: References: <200010261245.OAA15960@london.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk depends. If I separate VPN and Internet access then I can propogate my global Internet routing information between all Internet routers but VPN information only between PE routers that need it. I could also direct my traffic to an Internet router that has selected the best path based on all peering points. Maybe I have customers that actually want access via a specific ISP ? I can do this also by directed BGP session from the VPN site to the exit point. I also may have requirements for NAT and Firewall services where I need to direct my VPN customers to central services that provide this functionality and also provide optimal BGP exit point routing based on the best path selection. Maybe I don't want to exchange Internet routes at all with the VPN provider in which case I will run iBGP sessions directly between my sites and just exchange next-hops with the provider .. Jim At 09:12 26/10/2000 -0700, Randy Bush wrote: >and which one will work for a large isp with lots of vpn customers and lots >of connections to other peer isps? > >> the answer is no. There are various ways to design Internet connectivity >> within this environment, one of which is to carry full Internet routes on >> the PE router. Other options include default routing from VPN sites to a >> central site that has Internet connectivity, another is to offload the >> Internet routes from the PE and run direct eBGP sessions from the VPN site >> to the Internet exit point. Which option is actually taken will depend on >> the specific design requirements. Jim >> >> At 08:37 26/10/2000 -0400, Barry Hass wrote: >> >Eric, >> > >> >Doesn't a PE router have to handle the full Internet routing >> >table, plus VRFs for whatever VPNs it is supporting? I think >> >that what some folks are suggesting is that BGP (not "the box", >> >but BGP specifically) is already bumping up against scaling >> >limits at 100,000 or so routes, and that burdening it with the >> >additional responsibility of managing VPNs is not such a great >> >idea. ("Some folks" please correct me if I'm wrong). Can you >> >comment on that? >> > >> >By the way, I don't have enough information to have an opinion >> >on this. I'm just trying to steer the discussion back to what >> >I thought was an interesting technical question before the >> >insults started to fly. >> > >> >> In the NBVPN routing environment, it is not true that >> >> anyone in the world >> >> needs to be able to reach anyone else in the world. Each >> >> VPN has its own >> >> inter-connectivity matrix, much smaller than the >> >> Internet connectivity >> >> matrix. Now if you add up all the VPN routes, summed over >> >> all VPNs, you may >> >> indeed get a much larger number than the number of >> >> Internet routes. But >> >> there is no one box which needs to hold them all. Since an >> >> instance of BGP >> >> runs in a particular box, and only has to deal with the >> >> routes that need to >> >> be in that box, you don't run up against the same box >> >> scaling problems you >> >> run up against in the Internet routing environment. You >> >> can design your >> >> system to have a given box handle as many routes or as few >> >> routes as you >> >> want. >> > >> >> >> Jim Guichard CCIE #2069 >> Network Design Consultant EMEA >> Global Solutions Engineering >> >> +44 208 756 8806 >> Mobile: +44 7802 809763 >> > Jim Guichard CCIE #2069 Network Design Consultant EMEA Global Solutions Engineering +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Thu Oct 26 12:50:30 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22307 for ; Thu, 26 Oct 2000 12:50:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpf14577; Thu, 26 Oct 2000 16:49:25 GMT Received: by mail-control.mail.uu.net id QQjmpf17192 for mpls-outgoing; Thu, 26 Oct 2000 16:49:05 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmpf17187 for ; Thu, 26 Oct 2000 16:48:55 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmpf13790 for ; Thu, 26 Oct 2000 16:48:38 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmpf13398 for ; Thu, 26 Oct 2000 16:48:38 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA01773; Thu, 26 Oct 2000 09:48:01 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA24762; Thu, 26 Oct 2000 12:48:01 -0400 (EDT) Message-Id: <200010261648.MAA24762@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Randy Bush cc: Jim Guichard , Barry Hass , Paul Doolan , yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? In-reply-to: Your message of Thu, 26 Oct 2000 09:12:38 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 Oct 2000 12:48:01 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Randy> which one will work for a large isp with lots of vpn customers and Randy> lots of connections to other peer isps? This particular scenario is not the only scenario in existence. But for this scenario, it is probably best to keep the VPN routes and the Internet routes strictly separated, so that no one edge router has them both. There are two obvious ways to do this: - If VPN access and Internet access are to be offered over the same interface, then keep only the VPN routes in the PE router to which that interface leads. Packets which need to go to the Internet then get default-routed to an adjacent router which has the Internet routes. - Use different interfaces for VPN access and Internet access, and have them lead to different edge routers. Of course, if one makes it a requirement that the adoption of a VPN service have no impact on the network design, then the RFC2547 solution will be ruled out in this scenario. From owner-mpls@UU.NET Thu Oct 26 13:12:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24864 for ; Thu, 26 Oct 2000 13:12:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpg14962; Thu, 26 Oct 2000 17:11:21 GMT Received: by mail-control.mail.uu.net id QQjmpg29862 for mpls-outgoing; Thu, 26 Oct 2000 17:10:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmpg29851 for ; Thu, 26 Oct 2000 17:10:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmpg13423 for ; Thu, 26 Oct 2000 17:09:38 GMT Received: from roam.psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: roam.psg.com [147.28.4.2]) id QQjmpg00815 for ; Thu, 26 Oct 2000 17:09:37 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13oqWl-00051U-00; Thu, 26 Oct 2000 10:09:19 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ben Black Cc: Jim Guichard , Paul Doolan , Barry Hass , erosen@cisco.com, yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? References: <200010261245.OAA15960@london.cisco.com> <200010261459.QAA09502@london.cisco.com> <20001026095220.A4189@layer8.net> Message-Id: Date: Thu, 26 Oct 2000 10:09:19 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Then perhaps this is not the solution for you. However, the fact > that it is not applicable to your particular application does not > make it worthless (this is to be differentiated from drafts > documenting architectures that are applicable to no applications). > > Is it inappropriate, in general, for SPs who need to maintain full > Internet tables in their PEs? Quite likely. > > Is it inappropriate, in general, for SPs who have nothing but VPN > customers, each of whom has very few prefixes? Probably not. > > I don't believe anyone has challenged either MOs or your ability to > engineer ISP networks, but perhaps viewing everything through your > ISP goggles is not the most effective way to judge the utility of > all drafts. so we agree it is not for isps. cool. so, if an enterprise wanting to deploy it is not an isp, then they'll need their own layer 1 or2 connectivity between all endpoints. so then what is the advantage to them of this clever (a pejorative) approach to old-style layer 2 vpns? randy From owner-mpls@UU.NET Thu Oct 26 13:14:35 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25144 for ; Thu, 26 Oct 2000 13:14:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpg07543; Thu, 26 Oct 2000 17:13:41 GMT Received: by mail-control.mail.uu.net id QQjmpg00195 for mpls-outgoing; Thu, 26 Oct 2000 17:13:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmpg00190 for ; Thu, 26 Oct 2000 17:12:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmpg21852 for ; Thu, 26 Oct 2000 17:12:21 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmpg04501 for ; Thu, 26 Oct 2000 17:12:20 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA04334 for ; Thu, 26 Oct 2000 10:12:20 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA24904 for mpls@uu.net; Thu, 26 Oct 2000 13:12:19 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmpg29002 for ; Thu, 26 Oct 2000 17:03:51 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmpg23914 for ; Thu, 26 Oct 2000 17:02:35 GMT Received: from tristero.cryptocourier.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQjmpg00057 for ; Thu, 26 Oct 2000 17:02:35 GMT Received: (qmail 404 invoked from network); 26 Oct 2000 17:05:40 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 26 Oct 2000 17:05:40 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Thu, 26 Oct 2000 09:52:20 -0700 Date: Thu, 26 Oct 2000 09:52:20 -0700 From: Ben Black To: Randy Bush Cc: Jim Guichard , Paul Doolan , Barry Hass , erosen@cisco.com, yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? Message-ID: <20001026095220.A4189@layer8.net> References: <200010261245.OAA15960@london.cisco.com> <200010261459.QAA09502@london.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from randy@psg.com on Thu, Oct 26, 2000 at 09:23:54AM -0700 Sender: owner-mpls@UU.NET Precedence: bulk Then perhaps this is not the solution for you. However, the fact that it is not applicable to your particular application does not make it worthless (this is to be differentiated from drafts documenting architectures that are applicable to no applications). Is it inappropriate, in general, for SPs who need to maintain full Internet tables in their PEs? Quite likely. Is it inappropriate, in general, for SPs who have nothing but VPN customers, each of whom has very few prefixes? Probably not. I don't believe anyone has challenged either MOs or your ability to engineer ISP networks, but perhaps viewing everything through your ISP goggles is not the most effective way to judge the utility of all drafts. Ben On Thu, Oct 26, 2000 at 09:23:54AM -0700, Randy Bush wrote: > the problem is that an isp has *many* 'exits' to the internet, like dozens. > > > yes, exactly this. By doing this, the CE is able to learn full Internet > > routing information without the need to populate the PE with this > > information. The Internet exit point address needs to be available via the > > PE router and a default route within the PE VRF has to be available so that > > any destination that is not covered by a VPN route can be routed based on > > the default toward the exit point. From a CE perspective, all it needs to > > do is be able to reach the exit point and advertise its BGP peering address > > (next-hop) toward the PE router. Jim > > > > At 08:47 26/10/2000 -0400, Paul Doolan wrote: > > >Jim, > > > > > >>Other options include default routing from VPN sites to a > > >>central site that has Internet connectivity, another is to offload the > > >>Internet routes from the PE and run direct eBGP sessions from the VPN site > > >>to the Internet exit point. > > > > > > When you say 'VPN site' here are you suggesting that the CE router is > > > running eBGP with/to the 'Internet exit point' ? > > > > > > pd > > > > > > > > > Jim Guichard CCIE #2069 > > Network Design Consultant EMEA > > Global Solutions Engineering > > > > +44 208 756 8806 > > Mobile: +44 7802 809763 > > > From owner-mpls@UU.NET Thu Oct 26 13:19:18 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25699 for ; Thu, 26 Oct 2000 13:19:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmph25976; Thu, 26 Oct 2000 17:18:38 GMT Received: by mail-control.mail.uu.net id QQjmph00772 for mpls-outgoing; Thu, 26 Oct 2000 17:18:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmph00767 for ; Thu, 26 Oct 2000 17:18:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmph20546 for ; Thu, 26 Oct 2000 17:17:37 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjmph28278 for ; Thu, 26 Oct 2000 17:17:34 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id WAA28556 for ; Thu, 26 Oct 2000 22:45:38 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id WAA30411 for ; Thu, 26 Oct 2000 22:47:31 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Thu, 26 Oct 2000 22:47:31 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Doubt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Can RSVP-TE handle RSVP messages??? _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Thu, 26 Oct 2000 13:27:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmph10277; Thu, 26 Oct 2000 17:27:01 GMT Received: by mail-control.mail.uu.net id QQjmph01287 for mpls-outgoing; Thu, 26 Oct 2000 17:26:28 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmph01225 for ; Thu, 26 Oct 2000 17:26:13 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmph12971 for ; Thu, 26 Oct 2000 17:25:48 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmph00611 for ; Thu, 26 Oct 2000 17:25:47 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA17853 for ; Thu, 26 Oct 2000 10:25:47 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA24959 for mpls@uu.net; Thu, 26 Oct 2000 13:25:46 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmph00948 for ; Thu, 26 Oct 2000 17:21:54 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmph02007 for ; Thu, 26 Oct 2000 17:21:14 GMT Received: from tristero.cryptocourier.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQjmph01166 for ; Thu, 26 Oct 2000 17:21:12 GMT Received: (qmail 514 invoked from network); 26 Oct 2000 17:24:18 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 26 Oct 2000 17:24:18 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Thu, 26 Oct 2000 10:10:59 -0700 Date: Thu, 26 Oct 2000 10:10:59 -0700 From: Ben Black To: Randy Bush Cc: Jim Guichard , Paul Doolan , Barry Hass , erosen@cisco.com, yakov@cisco.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? Message-ID: <20001026101058.B4189@layer8.net> References: <200010261245.OAA15960@london.cisco.com> <200010261459.QAA09502@london.cisco.com> <20001026095220.A4189@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from randy@psg.com on Thu, Oct 26, 2000 at 10:09:19AM -0700 Sender: owner-mpls@UU.NET Precedence: bulk I am not sure I understand your question. Are we not debating the merits of draft-rosen-rfc2547bis-02.txt, a layer 3 approach? Ben On Thu, Oct 26, 2000 at 10:09:19AM -0700, Randy Bush wrote: > > Then perhaps this is not the solution for you. However, the fact > > that it is not applicable to your particular application does not > > make it worthless (this is to be differentiated from drafts > > documenting architectures that are applicable to no applications). > > > > Is it inappropriate, in general, for SPs who need to maintain full > > Internet tables in their PEs? Quite likely. > > > > Is it inappropriate, in general, for SPs who have nothing but VPN > > customers, each of whom has very few prefixes? Probably not. > > > > I don't believe anyone has challenged either MOs or your ability to > > engineer ISP networks, but perhaps viewing everything through your > > ISP goggles is not the most effective way to judge the utility of > > all drafts. > > so we agree it is not for isps. cool. > > so, if an enterprise wanting to deploy it is not an isp, then they'll > need their own layer 1 or2 connectivity between all endpoints. so then > what is the advantage to them of this clever (a pejorative) approach to > old-style layer 2 vpns? > > randy > From owner-mpls@UU.NET Thu Oct 26 13:28:25 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26808 for ; Thu, 26 Oct 2000 13:28:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmph03559; Thu, 26 Oct 2000 17:27:45 GMT Received: by mail-control.mail.uu.net id QQjmph01309 for mpls-outgoing; Thu, 26 Oct 2000 17:27:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmph01304 for ; Thu, 26 Oct 2000 17:26:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmph17631 for ; Thu, 26 Oct 2000 17:26:16 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmph12276 for ; Thu, 26 Oct 2000 17:26:16 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA06915; Thu, 26 Oct 2000 10:25:38 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA24952; Thu, 26 Oct 2000 13:25:38 -0400 (EDT) Message-Id: <200010261725.NAA24952@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Randy Bush cc: Ben Black , Jim Guichard , Paul Doolan , Barry Hass , yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es Subject: Re: VPN solution - White flag ? In-reply-to: Your message of Thu, 26 Oct 2000 10:09:19 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 Oct 2000 13:25:38 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Randy> if an enterprise wanting to deploy it is not an isp, then they'll Randy> need their own layer 1 or2 connectivity between all endpoints. Just to be clear, you are saying that, to the best of your knowledge, all networks fall into one of the following two categories: 1. needs to carry all Internet routes to every edge 2. needs complete mesh of layer 2 connections between all endpoints. I had no idea that all networks fell into one of these two categories! I don't know how I missed that ;-) From owner-mpls@UU.NET Thu Oct 26 14:06:13 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01354 for ; Thu, 26 Oct 2000 14:06:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpk07026; Thu, 26 Oct 2000 18:05:41 GMT Received: by mail-control.mail.uu.net id QQjmpk14712 for mpls-outgoing; Thu, 26 Oct 2000 18:05:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmpk14704 for ; Thu, 26 Oct 2000 18:05:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmpk04214 for ; Thu, 26 Oct 2000 18:04:14 GMT Received: from mx3out.umbc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx3out.umbc.edu [130.85.253.53]) id QQjmpk04913 for ; Thu, 26 Oct 2000 18:04:10 GMT Received: from gl.umbc.edu (vijay@irix1.gl.umbc.edu [130.85.60.8]) by mx3out.umbc.edu (8.9.3/8.9.3) with ESMTP id OAA14728 for ; Thu, 26 Oct 2000 14:04:05 -0400 (EDT) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id OAA435978 for ; Thu, 26 Oct 2000 14:04:04 -0400 (EDT) X-Authentication-Warning: irix1.gl.umbc.edu: vijay owned process doing -bs Date: Thu, 26 Oct 2000 14:04:04 -0400 From: Vijay Gill X-Sender: vijay@irix1.gl.umbc.edu To: mpls@UU.NET Subject: Re: VPN solution - White flag ? In-Reply-To: <200010261725.NAA24952@erosen-sun.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk [ folks, it doesn't hurt to trim headers ] On Thu, 26 Oct 2000, Eric Rosen wrote: > Randy> if an enterprise wanting to deploy it is not an isp, then they'll > Randy> need their own layer 1 or2 connectivity between all endpoints. > > Just to be clear, you are saying that, to the best of your knowledge, all > networks fall into one of the following two categories: > > 1. needs to carry all Internet routes to every edge Having worked at one or two promising local ISPs, I assure you that the plan of deploying two routers where one will do (and where one is just to aggregate VPN customers) is something that will not fly very well. This of course leads to a realistic scenario where you have the minimum number of routers necessary to satisfy the business need at the edge and since a couple of customers insist on having full routes, well.... I suspect this is where Randy is coming from. Given that routers _barely_ work as it is, we'd much rather wish this additional problem onto someone else than have it sit in the ISP core, where routers crashing lead to SLA violations and asosciated pain. > 2. needs complete mesh of layer 2 connections between all endpoints. > > I had no idea that all networks fell into one of these two categories! I > don't know how I missed that ;-) Just most _realistic_ ISP networks fall into case 1. /vijay From owner-mpls@UU.NET Thu Oct 26 14:28:28 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03902 for ; Thu, 26 Oct 2000 14:28:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpl26233; Thu, 26 Oct 2000 18:27:27 GMT Received: by mail-control.mail.uu.net id QQjmpl16632 for mpls-outgoing; Thu, 26 Oct 2000 18:26:55 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmpl16624 for ; Thu, 26 Oct 2000 18:26:49 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmpl16922 for ; Thu, 26 Oct 2000 18:26:31 GMT Received: from icarian.ZAFFIRE.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netscreen10.zaffire.com [64.232.69.132]) id QQjmpl05360 for ; Thu, 26 Oct 2000 18:26:30 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <48XXFXNM>; Thu, 26 Oct 2000 11:27:28 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> From: Eric Gray To: "'erosen@cisco.com'" Cc: yakov@cisco.com, rnewcomb@ennovatenetowrks.com, mpls@UU.NET, diego@estos.upc.es, Paul Doolan Subject: RE: VPN solution - White flag ? Date: Thu, 26 Oct 2000 11:27:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric, On a technical note (:-)) - I believe it is possible to support a logarithmic growth in the number of "boxes" relative to services. I suspect this would make service providers happier than a linear growth. It would also allow larger service providers to realize economies of scale - an idea which has been fairly low profile in industry in general these days... > --- --- > > Now someone will say, "Wait a minute, as your customer base > increases, this may require you to deploy more boxes; unscalable, > unscalable". I have to admit, the scheme does not allow you to > provide an unbounded amount of service in a single box. Both > the growth is not exponential, geometric, factorial, or any of > that really bad stuff. The growth is linear, which is about the > best you can do. > > --- --- From owner-mpls@UU.NET Thu Oct 26 15:07:52 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08526 for ; Thu, 26 Oct 2000 15:07:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpo28068; Thu, 26 Oct 2000 19:06:51 GMT Received: by mail-control.mail.uu.net id QQjmpo00936 for mpls-outgoing; Thu, 26 Oct 2000 19:06:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmpo00916 for ; Thu, 26 Oct 2000 19:06:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmpo21568 for ; Thu, 26 Oct 2000 19:05:36 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmpo18281 for ; Thu, 26 Oct 2000 19:05:35 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07190 for ; Thu, 26 Oct 2000 12:05:35 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA25205 for mpls@uu.net; Thu, 26 Oct 2000 15:05:33 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmpl15542 for ; Thu, 26 Oct 2000 18:15:01 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmpk20307 for ; Thu, 26 Oct 2000 18:14:46 GMT Received: from tristero.cryptocourier.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQjmpk09472 for ; Thu, 26 Oct 2000 18:14:45 GMT Received: (qmail 763 invoked from network); 26 Oct 2000 18:17:51 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 26 Oct 2000 18:17:51 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Thu, 26 Oct 2000 11:04:32 -0700 Date: Thu, 26 Oct 2000 11:04:32 -0700 From: Ben Black To: Vijay Gill Cc: mpls@UU.NET Subject: Re: VPN solution - White flag ? Message-ID: <20001026110432.D4189@layer8.net> References: <200010261725.NAA24952@erosen-sun.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from vijay@umbc.edu on Thu, Oct 26, 2000 at 02:04:04PM -0400 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Oct 26, 2000 at 02:04:04PM -0400, Vijay Gill wrote: > > Just most _realistic_ ISP networks fall into case 1. > Not all SPs are ISPs. The audience for IETF documents is not restricted to ISPs. ISPs wishing to provide MPLS VPN services may find the L2 approach of the Kompella draft more attractive. Dedicated MPLS VPN SPs may find the L3 approach of the Rosen draft more attractive. The difference in environments for each dictates engineering preferences, but does not invalidate preferences in other environments. In summary: Can't we all just get along? Ben From owner-mpls@UU.NET Thu Oct 26 15:09:27 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08727 for ; Thu, 26 Oct 2000 15:09:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpo02135; Thu, 26 Oct 2000 19:07:57 GMT Received: by mail-control.mail.uu.net id QQjmpo01521 for mpls-outgoing; Thu, 26 Oct 2000 19:07:17 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmpo01473 for ; Thu, 26 Oct 2000 19:07:05 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmpo07855 for ; Thu, 26 Oct 2000 19:05:52 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmpo29065 for ; Thu, 26 Oct 2000 19:05:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA22074 for ; Thu, 26 Oct 2000 12:05:49 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA25209 for mpls@uu.net; Thu, 26 Oct 2000 15:05:49 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmpl16750 for ; Thu, 26 Oct 2000 18:28:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmpl24252 for ; Thu, 26 Oct 2000 18:27:15 GMT Received: from southpass.baynetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns2.BayNetworks.COM [134.177.3.16]) id QQjmpl06331 for ; Thu, 26 Oct 2000 18:27:14 GMT Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id LAA01284 for ; Thu, 26 Oct 2000 11:18:43 -0700 (PDT) Received: from shasta-exch.shastanets.com (mailserver.shastanets.com [47.82.16.150]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id LAA12262 for ; Thu, 26 Oct 2000 11:25:37 -0700 (PDT) Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 11:25:01 -0700 Message-ID: <940E42DB5D7FD4119C420004ACE6E0A08101D1@mailserver.shastanets.com> From: Janardan Ramesh To: "'mpls@uu.net'" Subject: Question on vpn-ipv4 address format Date: Thu, 26 Oct 2000 11:25:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk RFC-2547.bis says that format for vpn-ipv4 address is 8 byte RD + 4 byte prefix. Suresh sent out a question regarding the prefix length. In the reply received from Yakov, it said that the prefix length is endoded as per multiprotocol extensions to BGP (rfc2858). My undertanding of the MPLS_REACH_NLRI (based on 2858 and carrying labels in BGP draft is as follows) NLRI Len (1 byte), Label (3bytes), NLRI variable. The draft says that the length includes the length of the label and the NLRI length. For the VPN-ipv4 case, the MP_REACH_NLRI will look like NLRI Len (1byte) = 14, Label (bytes), NLRI Len=prefixlen, 8 byte NLRI + 4 byte prefix. I feel that this model has deviated from the representation of IP prefix in traditional ipv4 BGP. Should the format for vpn-ipv4 address be as follows? 8 byte RD + 1 byte prefix len + 4 bytes prefix (with trailing zeros) What is the current format used both when conveying the information and storing the routes in the routing table? Regards Ramesh From owner-mpls@UU.NET Thu Oct 26 15:14:18 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09309 for ; Thu, 26 Oct 2000 15:14:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpo29724; Thu, 26 Oct 2000 19:13:39 GMT Received: by mail-control.mail.uu.net id QQjmpo02477 for mpls-outgoing; Thu, 26 Oct 2000 19:13:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmpo02443 for ; Thu, 26 Oct 2000 19:12:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmpo03076 for ; Thu, 26 Oct 2000 19:11:49 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjmpo27255 for ; Thu, 26 Oct 2000 19:11:49 GMT Received: from cryndent01.mww.bt.com by marvin (local) with ESMTP; Thu, 26 Oct 2000 20:11:31 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id ; Thu, 26 Oct 2000 20:11:26 +0100 Message-ID: To: yakov@cisco.com, darren.freeland@bt.com Cc: mpls@UU.NET, alan.mcguire@bt.com, andy.bd.reid@bt.com Subject: RE: Two orthogonal issue Date: Thu, 26 Oct 2000 20:11:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > I'm not happy with that. What's the justification > > given for using this model over the overlay option? **To avoid problems > > encountered with IP over ATM** ... sorry, wrong answer. OTN is not > ATM. >NH=> The are very good reasons to unite the control-plane apsects of a CO and CNLS transfer mode at an application interfacing level. And although MPLS is only being used in a 'S-PVC' like mode at present to augment a dominantly CNLS transfer mode, this may not always be the case in the future, eg if lots of interactive video takes off to use all that BW that the OTN provides. However, although this is conjecture, MPLS does offer the possibility to flexibly respond if needed (and this is where an IP/ATM harmonisation could never work....essentially due to use of different addressing). MPLS user-plane has still some major availability/QoS issues unanswered in my opinion...see my last mail to Paul Tassillo on this thread. Until/unless these are answered, then there will always be a need for L2 VPNs. Indeed, there will always be a need for L1/L2 VPNs for those customers who demand them (and in the L1 case, this is wholesale large managed BW, which has to come from L1 (eg SDH VC4) to be cost-effective)......and we know there are customers who will always want these types of service. This, of course, ignores granfathering other client types. So, for operators in this position and who want to serve a wide market segment, overlay is an essential requirement. However, I would not want to stop people doing the peer-model if that suits their business....indeed its suits me if they do. The OTN is agnostic, since it is user-plane PDU-type transparent. It is also CO/cct-sw. And if I was being very cynical, I could say that the only way for router vendors to play in this space is to import their control-planes. I have yet to see any evaulation of various addressing, signalling and routing instances (as independent issues, which they are) which are based on hard OTN requirements agreed across a large population of operators. We are working on this and I know other are too, but the work is not complete. So whilst some might favour certain solutions for their peer model, others may want different solutions for their overlay model. > Yet from the IP routing point of view the overlay model has exactly > the same problems, irrespective of whether the overlay is realized > over ATM, or OTN, or X.25, etc... In other words, overlay is an > overlay, irrespective of the underlying technology. > > > We (inc other operators) have made our feelings clear on the peer model. > > > Yes, indeed, as indicated in the following e-mail from UUNet: > > Yong Xue> I think both overlay model and peer model should be supported. > NH=> I had a chat to our regulatory department today about peer/overlay models. In the UK at least, there are *no* operators who want to share detailed duct/L1 topology information with other operators......all UK operators seem to agree with this (for I think quite obvious reasons). However, if people really want to pursue the peer model then I think they had better face this inter-operator NNI issue from the outset.....because if they don't then their model is not going to get them very far, ie they will have to be content with only being able to run certain services based on it within a their own single domain....and outside that they will be forced to go overlay (actually its also partitioning too). Now consider a global VPN customer in such a case.....just what sort of model is needed to serve that customer if you don't have infrastruture to the duct around the globe? That's why I said those who favour the peer model are fine by me....however, I'd go and check this with your finance people first. Neil From owner-mpls@UU.NET Thu Oct 26 15:14:23 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09335 for ; Thu, 26 Oct 2000 15:14:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmpo07782; Thu, 26 Oct 2000 19:13:37 GMT Received: by mail-control.mail.uu.net id QQjmpo02468 for mpls-outgoing; Thu, 26 Oct 2000 19:13:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmpo02435 for ; Thu, 26 Oct 2000 19:12:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmpo10501 for ; Thu, 26 Oct 2000 19:11:55 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjmpo08109 for ; Thu, 26 Oct 2000 19:11:53 GMT Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP; Thu, 26 Oct 2000 20:11:28 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2651.88) id ; Thu, 26 Oct 2000 20:11:29 +0100 Message-ID: To: glen.turner@aarnet.edu.au, mpls@UU.NET Subject: RE: LSP failure detection Date: Thu, 26 Oct 2000 20:11:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Glen, I, and few others, are working on an ID for MPLS user-plane OAM functions. Progress has been slowed for several reasons.....not least of which is an ITU SG13/Q6 mtg next month which will be looking at MPLS user-plane OAM requirements. I have prepared some papers for this which are the same (though cut-up to suit ITU needs) since I want to try and keep ITU/IETF as aligned as possible....or at least from our perspective wrt requirements. If anyone wants a copy please let me know........note they have to get formal BT approval (as indeed do all papers submitted to any stds fora), and this will take about 1 week if all goes OK. Neil > -----Original Message----- > From: Glen Turner [SMTP:glen.turner@aarnet.edu.au] > Sent: Thursday, October 26, 2000 8:51 AM > To: 'mpls@UU.NET' > Subject: Re: LSP failure detection > > > > Detection: > > > > # Hardware notifies you of a failure > > # Software detects a failure through keep-alives, time-outs, > etc... > > As far as I can tell, currently defined IP keepalives don't really > cut it. For example most vendors have a minimum keepalive > interval of 1 second and require 3 lost keepalives before > marking the link as down. Similarly for OSPF HELLOs. > > Is there a special MPLS keepalive defined that allows subsecond > detection of a forwarding failure? Or is such a beast yet to > be engineered? > > -- > Glen Turner Network Engineer > (08) 8303 3936 Australian Academic and Research Network > glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ > -- > The revolution will not be televised, it will be digitised From owner-mpls@UU.NET Thu Oct 26 22:31:39 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09061 for ; Thu, 26 Oct 2000 22:31:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmqs10170; Fri, 27 Oct 2000 02:31:14 GMT Received: by mail-control.mail.uu.net id QQjmqs26995 for mpls-outgoing; Fri, 27 Oct 2000 02:30:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmqs26962 for ; Fri, 27 Oct 2000 02:30:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmqc06794 for ; Thu, 26 Oct 2000 22:37:59 GMT Received: from roam.psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: roam.psg.com [147.28.4.2]) id QQjmqc02688 for ; Thu, 26 Oct 2000 22:37:53 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13oveN-00057P-00; Thu, 26 Oct 2000 15:37:31 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Gray Cc: mpls@UU.NET Subject: RE: VPN solution - White flag ? References: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> Message-Id: Date: Thu, 26 Oct 2000 15:37:31 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > On a technical note (:-)) - I believe it is > possible to support a logarithmic growth in the > number of "boxes" relative to services. I suspect > this would make service providers happier than a > linear growth. but not as happy as zero growth, which solutions such as ipsec provide. remember, for a provider, management cost is a function of number of customers, which we want to increase, and routers,which we prefer not to increase. and, as it seems to be agreed that the 2547 cleverness is not really for isps, it's lucky we have a useful alternative. randy From owner-mpls@UU.NET Thu Oct 26 22:31:54 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09229 for ; Thu, 26 Oct 2000 22:31:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmqs25942; Fri, 27 Oct 2000 02:31:33 GMT Received: by mail-control.mail.uu.net id QQjmqs27209 for mpls-outgoing; Fri, 27 Oct 2000 02:30:47 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmqs27129 for ; Fri, 27 Oct 2000 02:30:39 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmqe23825 for ; Thu, 26 Oct 2000 23:05:39 GMT Received: from outside.whiterocknetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 64-48-28-18.customer.algx.net [64.48.28.18]) id QQjmqe20050 for ; Thu, 26 Oct 2000 23:05:39 GMT Received: from [192.168.1.220] by outside.whiterocknetworks.com for mpls@UU.net id SAA10154; Thu Oct 26 18:05:35 2000 Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 18:02:26 -0500 Message-ID: <758F0C2C951CD411B15300D0B744446503BF8E@192-168-1-220.customer.algx.net> Subject: TE information in GMPLS Date: Thu, 26 Oct 2000 18:02:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" To: "'mpls@UU.net'" From: "Connell, Jeff" Sender: owner-mpls@UU.NET Precedence: bulk Lou et all, In reading the new GMPLS draft, section 3.1.4 Bandwidth encoding, you state the PDR and CDR fields be used to specify the maximum reservable bandwidth. This needs to be extended to indicate the number of each type available. For instance, if I have two links to the same dest., one with 2 STS-12c's available and the other with 1 STS-12c available, I would prefer the first due to load balancing (all else equal.) Or, what if I wanted to provision 12 STS-1s, I would only know I have at least one available. An advantage of your proposed method is: only when "Signal Type" is no longer available does the TE TLV need to be re-flooded. If the metrics change with every provisioned cross-connect, there could be a heavier TE TLV load on the network. Thresholds can be used to solve that problem. I think there needs to be more information than is currently flooded. On an editorial note, I notice in this draft (and the earlier version) STS-1s are mentioned, and then OC-3, OC-12, etc.. Do you mean STS-3c, and STS-12c? I know the intent is to keep the difference between SONET and WDM (not wavelength, but bandwidth) abstract, but it does make the SONET guys cringe a bit :) As you know, there does not exist a OC-12 within an OC-48, but there can be up to four STS-12c's. It would be more correct to say : STS-12c/OC-12/STM-4 for signal type (SONET/WDM/SDH). Jeff Connell White Rock Networks (972)588-3762 www.whiterocknetworks.com From owner-mpls@UU.NET Thu Oct 26 22:33:04 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09820 for ; Thu, 26 Oct 2000 22:33:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmqs12458; Fri, 27 Oct 2000 02:32:39 GMT Received: by mail-control.mail.uu.net id QQjmqs27247 for mpls-outgoing; Fri, 27 Oct 2000 02:30:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmqs27188 for ; Fri, 27 Oct 2000 02:30:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmpx25459; Thu, 26 Oct 2000 21:15:47 GMT Received: from kcmgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker1.sprint.com [208.18.122.165]) id QQjmpx22061; Thu, 26 Oct 2000 21:15:46 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id e9QLFeF00322; Thu, 26 Oct 2000 16:15:40 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id e9QLFcc11865; Thu, 26 Oct 2000 16:15:39 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id QAA23259; Thu, 26 Oct 2000 16:15:38 -0500 (CDT) From: Mark.Jones@mail.sprint.com X-OpenMail-Hops: 1 Date: Thu, 26 Oct 2000 16:15:37 -0500 Message-Id: Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh MIME-Version: 1.0 TO: yakov@cisco.com CC: David.A.Holmes@disney.com, ip-optical@lists.bell-labs.com, mpls@UU.NET, sc@tellium.com, vpoudyal@telcordia.com, xuyg@lucent.com, yxue@UU.NET, zwlin@lucent.com Content-Type: multipart/mixed; boundary="openmail-part-2c11e1f6-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-2c11e1f6-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Thu, 26 Oct 2000 16:15:37 -0500" Content-Transfer-Encoding: 7bit Yakov, "...what are the scenario(s) where UNI would be useful?" is an excellent question. Before I could capture my thoughts on this, I received a better description than I could write from a different discussion list. That correspondence and one set of comments is below. In short, the best application for the UNI is a carrier's carrier type application or an OVPN, where the customer has leased a select set of resources with flexibility to change the connectivity of those resources at will. Mark Loyd Jones Sprint Technology Planning & Integration 913-534-5247 mark.jones@mail.sprint.com > -----Original Message----- > From: vpoudyal [mailto:vpoudyal@telcordia.com] > Sent: Thursday, October 26, 2000 2:24 PM > To: [long laundry list of addresses removed] > Subject: Re: peer vs overlay (not this again!!) > > > > > Zhi: > I agree with your assertions. > Two more comments (tagged [vijaya]) below: > Vijaya > > > > Zhi-Wei Lin on 10/26/2000 02:36:23 PM > > To: [long laundry list of addresses removed] > Subject: peer vs overlay (not this again!!) > > > > OK, > > I know you're all sick of this by now, but...I still want to get a > better feel from you all. > > For the interface between the user and the service provider: > 1. user has router, service provider has ONE > 2. user has router, service provider has router > 3. user has ONE, servicer provider has ONE > > For the interface within the service provider network: > 4. The requestor is a router, the "servicer" is an ONE > 5. The requestor is a router, the "servicer" is a router > 6. The requestor is an ONE, the servicer is an ONE > > > Which cases will peer model make sense (I assume all of 4-6), > and which > cases will overlay model make sense (I assume all of 1-3, > plus possibly > 4-6). > > This means that when people say peer they actually mean the NNI (for > 4-6) > [Vijaya] I think that this is true for fully compatible NEs. However, if the requestor NE is not complaint with the NNI specs., it could still be complaint with the UNI specs. > When people say overlay they actually mean the UNI. > > ==> I've heard UUNET state that both overlay and peer will be > used, and > I've heard Level3 state this same. Do both companies mean to use peer > model within their own network (which couls be between router > and ONE or > ONE and ONE)?? Or use peer between the user and service provider? > > If the latter, then in order for the customer (e.g., router) to make > intelligent route determination decisions, they need not only the > topology information, but also how much resources are > available in each > link and in each node in order to determine how the route should > traverse. Is this acceptable to everyone? If you only provide topology > by itself, there is no way for the customer to know whether or not one > path will have the resources... > [Vijaya] The peer model could apply to the OVPN type of service alluded to in the OIF carriers requirement document. In this case, the user would ONLY have visibility and control over the portion of the network resource that it has "leased". > > Looking forward to your responses! > > Zhi > > > > -- > Zhi-Wei Lin > Lucent Technologies Tel: +1 732 949 5141 > 101 Crawfords Corner Rd, Rm 3C-512 Fax: +1 732 949 3210 > Holmdel, New Jersey 07733-3030 USA Email: zwlin@lucent.com > > > > -----Original Message----- > From: yakov [mailto:yakov@cisco.com] > Sent: Thursday, October 26, 2000 8:19 AM > To: Jones, Mark L. > Cc: David.A.Holmes; ip-optical; mpls; sc; xuyg; yxue; zwlin; yakov > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > > Mark, > > > Great point! The need to automate features like > provisioning is one of > > the key reasons we are all looking at optical networking. > However, the > > fast provisioning we all desire does not require the peer > model. (Many > > problems with the peer model for large multi-service carriers like > > Sprint have already been raised in this discussion, so I > won't repeat > > them.) I expect end-to-end provisioning in seconds or at least in > > minutes to be possible with the overlay model too. > > > > The question we should be asking is, who will be able to > actually take > > advantage of that capability regardless of the model you adopt? My > > guess is that it will primarily be an internal network > feature that few > > network customers will ever use directly. > > > > Here's why. Even if you find a carrier to support the peer > model, you > > will be required to pay for connections that you MIGHT use > in the event > > that you want to add bandwidth to your connection. No carrier or > > customer wants to build out capacity without some level of > commitment > > that the equipment will be needed. How much do you want to > pay for the > > privilege of having bandwidth on demand? For > sub-wavelength bandwidth, > > packet level aggregation minimizes the costs of bandwidth > on demand for > > carriers and customers. I believe that exists in limited ways in > > service offerings already. However, wavelength level bandwidth on > > demand may never be profitable due to the price of wavelength level > > port cards and systems. So, the carrier may deploy optical > networking > > with seconds required for provisioning, but the bandwidth > will still > > have to be built out to the customer after an order before it's > > available. I don't want to burst anyone's dream of bandwidth on > > demand, but please consider the practical aspects required > to make it a > > reasonable service offering. > > So, if you think that bandwidth on demand as a service offering > isn't practical, what are the scenario(s) where UNI would be useful ? > > Yakov. > --openmail-part-2c11e1f6-00000001-- From owner-mpls@UU.NET Thu Oct 26 22:34:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10239 for ; Thu, 26 Oct 2000 22:34:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmqs29103; Fri, 27 Oct 2000 02:33:49 GMT Received: by mail-control.mail.uu.net id QQjmqs27624 for mpls-outgoing; Fri, 27 Oct 2000 02:33:11 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmqs27600 for ; Fri, 27 Oct 2000 02:33:02 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmqs28119 for ; Fri, 27 Oct 2000 02:30:59 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmqs09740 for ; Fri, 27 Oct 2000 02:30:58 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA26720 for mpls@uu.net; Thu, 26 Oct 2000 22:30:57 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmqs27002 for ; Fri, 27 Oct 2000 02:30:27 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmpy02886 for ; Thu, 26 Oct 2000 21:39:22 GMT Received: from stl-smtpout-01.boeing.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: stl-smtpout-01.boeing.com [12.13.247.21]) id QQjmpy16417 for ; Thu, 26 Oct 2000 21:39:21 GMT Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA05830 for ; Thu, 26 Oct 2000 16:39:21 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2) with ESMTP id QAA29059 for ; Thu, 26 Oct 2000 16:39:20 -0500 (CDT) Received: from xch-phlbh-01.he.boeing.com by stl-hub-01.boeing.com with ESMTP; Thu, 26 Oct 2000 16:39:08 -0500 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 17:39:07 -0400 Message-Id: <4102273CEB77D211869200805FE6F593018C5B08@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Mark.Jones@mail.sprint.com'" Cc: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Thu, 26 Oct 2000 17:38:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Mark.Jones wrote: > Yakov, > > "...what are the scenario(s) where UNI would be useful?" is an > excellent question. Before I could capture my thoughts on this, I > received a better description than I could write from a different > discussion list. That correspondence and one set of comments > is below. > In short, the best application for the UNI is a carrier's > carrier type > application or an OVPN, where the customer has leased a select set of > resources with flexibility to change the connectivity of those > resources at will. Agree with this. And here is an example. A few weeks ago, my daughter is about to go off to school (vet school). I have to set up her PC to use the school's network. Sitting at home, in this case about 150 miles away from school, it's no problem. Why? Because I can layer IP over something else, and make it appear to IP as if I were there. In this case, it was a modem dial-in over PSTN. It could have been an ATM UNI setup too. Or some such (tunnel over MPLS?). To tie this back to the redundant provisioning discussion. Let's say I wanted redundant data paths from my broadband provider. I had suggested that using IP "options" and carefully chosen OSPF areas, you could achieve this without anything else. I was told, and I agree, that this doesn't guarantee that the data paths will be separate. Because trunks for the two IP data paths might share the same cable, or cableway. Of course. The point is, I'm not sure I understand how you can avoid this situation OTHER THAN by having the service provider know the physical topology of his network. How can _any_ UNI/NNI scheme ensure that physical paths of different routes are far apart, except by someone knowing the physical structure? I don't see how using just IP "options" is any less effective than any other method. Bert albert.e.manfredi@boeing.com From owner-mpls@UU.NET Thu Oct 26 22:35:09 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10521 for ; Thu, 26 Oct 2000 22:35:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmqs06401; Fri, 27 Oct 2000 02:34:47 GMT Received: by mail-control.mail.uu.net id QQjmqs27628 for mpls-outgoing; Fri, 27 Oct 2000 02:33:15 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmqs27605 for ; Fri, 27 Oct 2000 02:33:02 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmqs29466 for ; Fri, 27 Oct 2000 02:31:36 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmqs26000 for ; Fri, 27 Oct 2000 02:31:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA27197 for mpls@uu.net; Thu, 26 Oct 2000 22:31:34 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmqs27200 for ; Fri, 27 Oct 2000 02:30:46 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmqj12685 for ; Fri, 27 Oct 2000 00:27:07 GMT Received: from omega.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmqj03059 for ; Fri, 27 Oct 2000 00:27:06 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA25527; Thu, 26 Oct 2000 17:27:03 -0700 (PDT) Message-Id: <200010270027.RAA25527@omega.cisco.com> To: darren.freeland@bt.com cc: mpls@UU.NET, alan.mcguire@bt.com, andy.bd.reid@bt.com Subject: Re: Two orthogonal issue In-reply-to: Your message of "Thu, 26 Oct 2000 16:16:54 BST." <71DA16F18D32D2119A1D0000F8FE9A940920C785@mbtlipnt01.btlabs.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25525.972606423.1@cisco.com> Date: Thu, 26 Oct 2000 17:27:03 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Darren, > >>> Putting aside this questionable "okay, here is the answers - now what > >>> was the question" type approach, I have another big problem with > >>> draft-awduche-mpls-te-optical-02.txt. Lets pretend that we HAVE > >>> actually considered operators requirements, and the major consensus > >>> among operators is that the reuse of IP protocols is perfect for OTN. > > > > No, it is not "perfect" - it is just pragmatic. > > So you consider coming up with the answers prior to fully asking the > questions to be pragmatic? Yes. And to see why, note that quite a few OXC vendors ship today proprietory/closed control planes, and service providers buy this equipment, even despite the fact these control planes have been developed well prior "to fully asking the question". At the same time, I have nothing against people working on a PSFGTC (Perfect Solution For Generations To Come). I've seen such efforts in the past, and I hope they'll continue unabated in the future. > >>> If I'm to > >>> start out on this approach with draft-awduche-mpls-te-optical-02.txt > >>> then I'm going to be building my OTN for IP only. > > > > Could you point to any specific text in > > draft-awduche-mpls-te-optical-02.txt > > to support this ? > > It's implicit from the part of text that has clear bias towards the peer > model (see below). For reasons that I'm not going into again because > they've been beated out on this list over the last week or so (see a number > of previous mails from myself & Neil Harrison with regards to client/server > relationships). > > >>> The draft shows a clear bias towards the peer option. > > > > Perhaps you should re-read the following (Section 8 of the draft): > > And perhaps you should re-read the following (section 6 of the draft): > > Given that that both OXCs and LSRs require control planes, one option > would be to have two separate, independent, and incompatible control > planes - one for OXCs, and another for LSRs. To understand the > drawbacks of this approach, especially in IP-centric optical > internetworking systems, one need to look no further than the > experience with IP over ATM, where IP has its own control plane (BGP, > IS-IS, OSPF), and ATM its own control plane (PNNI) [12]. For some of > the drawbacks see [1,2]. > > Given that the control planes for both OXCs and LSRs have relatively > similar requirements, an alternative approach is to develop a > coherent control plane technology that can be used for LSRs and for > OXCs. Such a uniform control plane will eliminate the administrative > complexity of managing hybrid optical internetworking systems with > separate, dissimilar control and operational semantics. > Specializations may be introduced in the control plane, as necessary, > to account for inherent peculiarities of the underlying technologies > and networking contexts. > > All of the above observations suggest, therefore, that the MPLS > Traffic Engineering control plane (with some minor extensions) would > be very suitable as the control plane for OXCs. An OXC that uses the > MPLS traffic engineering control plane would effectively become an IP > addressable device. Thus, this proposition also solves the problem of > addressing for OXCs. The above section points to some of the problems associated with the overlay model, and especially with the overlay model where you have multiple control planes that have separate, dissimilar control and operational semantics. One may call these problems "bias", or one may just ignore them, but that isn't going to make these problems disappear. Yakov. From owner-mpls@UU.NET Thu Oct 26 22:47:53 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14589 for ; Thu, 26 Oct 2000 22:47:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmqt02039; Fri, 27 Oct 2000 02:47:32 GMT Received: by mail-control.mail.uu.net id QQjmqt28528 for mpls-outgoing; Fri, 27 Oct 2000 02:47:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmqt28523 for ; Fri, 27 Oct 2000 02:47:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmqt02884 for ; Fri, 27 Oct 2000 02:46:23 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmqt21025 for ; Fri, 27 Oct 2000 02:46:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA01433 for mpls@uu.net; Thu, 26 Oct 2000 22:46:20 -0400 (EDT) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmqs27412 for ; Fri, 27 Oct 2000 02:31:19 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmpq18981 for ; Thu, 26 Oct 2000 19:31:51 GMT Received: from ogma.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjmpq24747 for ; Thu, 26 Oct 2000 19:31:51 GMT Received: from london.cisco.com (london.cisco.com [144.254.32.10]) by ogma.cisco.com (Postfix) with ESMTP id 91A9DA5; Thu, 26 Oct 2000 21:31:50 +0200 (MET DST) Received: from jguichar-8kcdt.cisco.com (jguichar-isdn-home.cisco.com [10.49.131.222]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id VAA15675; Thu, 26 Oct 2000 21:31:49 +0200 (MET DST) Message-Id: <200010261931.VAA15675@london.cisco.com> X-Sender: jguichar@uk.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 26 Oct 2000 20:28:58 +0100 To: Vijay Gill , mpls@UU.NET From: Jim Guichard Subject: Re: VPN solution - White flag ? In-Reply-To: References: <200010261725.NAA24952@erosen-sun.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Vijay, I do not think that anyone is saying that this is the only option, it is just one of several. If there are a few customers that wish to receive full routes, and in my experience this is not a great number, then you can of course offload the eBGP session from your PE router and let the customer run directly with the internet exit point (or router that can establish the best exit point). It is clear that not all PE routers will have VPN customers attached that require internet access, or if they do, they do not require full routing. So maybe the question should be what percentage of VPN customers will want full routes, and where will these customer sites be located ? if the answer to this is a small number with certain sites requiring full routes then the answer may be dedicated Internet boxes, multi-hop sessions or even restriction of VPN attachment to the PE holding the full routes (with non-full route VPN customers perhaps located on other PE routers within that POP) .. Jim At 14:04 26/10/2000 -0400, Vijay Gill wrote: > >[ folks, it doesn't hurt to trim headers ] > >On Thu, 26 Oct 2000, Eric Rosen wrote: > >> Randy> if an enterprise wanting to deploy it is not an isp, then they'll >> Randy> need their own layer 1 or2 connectivity between all endpoints. >> >> Just to be clear, you are saying that, to the best of your knowledge, all >> networks fall into one of the following two categories: >> >> 1. needs to carry all Internet routes to every edge > >Having worked at one or two promising local ISPs, I assure you that the >plan of deploying two routers where one will do (and where one is just to >aggregate VPN customers) is something that will not fly very well. > >This of course leads to a realistic scenario where you have the minimum >number of routers necessary to satisfy the business need at the edge and >since a couple of customers insist on having full routes, well.... > >I suspect this is where Randy is coming from. Given that routers _barely_ >work as it is, we'd much rather wish this additional problem onto someone >else than have it sit in the ISP core, where routers crashing lead to SLA >violations and asosciated pain. > >> 2. needs complete mesh of layer 2 connections between all endpoints. >> >> I had no idea that all networks fell into one of these two categories! I >> don't know how I missed that ;-) > >Just most _realistic_ ISP networks fall into case 1. > >/vijay > Jim Guichard CCIE #2069 Network Design Consultant EMEA Global Solutions Engineering +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Thu Oct 26 22:57:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17640 for ; Thu, 26 Oct 2000 22:57:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmqs04720; Fri, 27 Oct 2000 02:33:43 GMT Received: by mail-control.mail.uu.net id QQjmqs27610 for mpls-outgoing; Fri, 27 Oct 2000 02:33:05 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmqs27594 for ; Fri, 27 Oct 2000 02:33:01 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmqs28148 for ; Fri, 27 Oct 2000 02:30:59 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmqs25069 for ; Fri, 27 Oct 2000 02:30:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA26740 for mpls@uu.net; Thu, 26 Oct 2000 22:30:58 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmqs26999 for ; Fri, 27 Oct 2000 02:30:26 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmqh00301 for ; Thu, 26 Oct 2000 23:47:34 GMT Received: from omega.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmqh13781 for ; Thu, 26 Oct 2000 23:47:34 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA21641; Thu, 26 Oct 2000 16:47:03 -0700 (PDT) Message-Id: <200010262347.QAA21641@omega.cisco.com> To: Janardan Ramesh cc: "'mpls@uu.net'" Subject: Re: Question on vpn-ipv4 address format In-reply-to: Your message of "Thu, 26 Oct 2000 11:25:00 PDT." <940E42DB5D7FD4119C420004ACE6E0A08101D1@mailserver.shastanets.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21637.972604022.1@cisco.com> Date: Thu, 26 Oct 2000 16:47:03 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Janardan, > RFC-2547.bis says that format for vpn-ipv4 address > is 8 byte RD + 4 byte prefix. Suresh sent out a > question regarding the prefix length. > > In the reply received from Yakov, it said that the > prefix length is endoded as per multiprotocol extensions to > BGP (rfc2858). > > My undertanding of the MPLS_REACH_NLRI (based on 2858 and > carrying labels in BGP draft is as follows) > > > NLRI Len (1 byte), Label (3bytes), NLRI variable. Not exactly - the label part may carry one or more labels (see the carrying labels in BGP draft). > The draft says that the length includes the length of the label and > the NLRI length. yes, as with any TLV-style encoding... > > > For the VPN-ipv4 case, the MP_REACH_NLRI will look like > > NLRI Len (1byte) = 14, Label (bytes), NLRI Len=prefixlen, 8 byte NLRI + 4 > byte prefix. No, this is not correct. From draft-ietf-mpls-bgp4-mpls-03.txt: The Length field indicates the length in bits of the address prefix plus the label(s). > > I feel that this model has deviated from the representation of IP prefix in > traditional > ipv4 BGP. > > Should the format for vpn-ipv4 address be as follows? > > 8 byte RD + 1 byte prefix len + 4 bytes prefix (with trailing zeros) No, the address prefix that is handled by BGP in the BGP/MPLS VPN case is *not* an IPv4 prefix, but a VPN-IPv4 prefix. > What is the current format used both when conveying the information > and storing the routes in the routing table? I am not sure I understand this question. Please elaborate. Yakov. From owner-mpls@UU.NET Thu Oct 26 23:16:59 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23709 for ; Thu, 26 Oct 2000 23:16:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmqv08548; Fri, 27 Oct 2000 03:16:22 GMT Received: by mail-control.mail.uu.net id QQjmqv11666 for mpls-outgoing; Fri, 27 Oct 2000 03:15:55 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmqv11661 for ; Fri, 27 Oct 2000 03:15:47 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmqv10384 for ; Fri, 27 Oct 2000 03:15:09 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmqv27017 for ; Fri, 27 Oct 2000 03:15:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA03569 for mpls@uu.net; Thu, 26 Oct 2000 23:15:08 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmqu11430 for ; Fri, 27 Oct 2000 03:14:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmqu08395 for ; Fri, 27 Oct 2000 03:13:40 GMT Received: from che-cse-115.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: che-cse-115.cisco.com [161.44.128.23]) id QQjmqu05097 for ; Fri, 27 Oct 2000 03:13:39 GMT Received: (from eosborne@localhost) by che-cse-115.cisco.com (8.8.5/CA/950118) id XAA25117; Thu, 26 Oct 2000 23:13:04 -0400 (EDT) Date: Thu, 26 Oct 2000 23:13:04 -0400 From: Eric Osborne To: Randy Bush Cc: Eric Gray , mpls@UU.NET Subject: Re: VPN solution - White flag ? Message-ID: <20001026231304.A25090@che-cse-115.cisco.com> References: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from randy@psg.com on Thu, Oct 26, 2000 at 03:37:31PM -0700 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Oct 26, 2000 at 03:37:31PM -0700, Randy Bush wrote: > > On a technical note (:-)) - I believe it is > > possible to support a logarithmic growth in the > > number of "boxes" relative to services. I suspect > > this would make service providers happier than a > > linear growth. > > but not as happy as zero growth, which solutions such as > ipsec provide. remember, for a provider, management cost > is a function of number of customers, which we want to > increase, and routers,which we prefer not to increase. Sure, but consider what you can sell. If the customer usees IPSec, they they have to manage the VPN themselves, as well as needing to approximate something close to N^2 connections. If the (I)SP sells VPN service, then the customer has offloaded the work onto the ISP. There's a few ways you can give private-network solutions to an enterprise. The ones I can think of are: 1) dedicated line (ATM/FR/Leased Line) 2) IPSec sessions over Internet connectivity 3) MPLS VPN With #1, the customer can't do full-mesh, becuase with a large enough number of sites, full-mesh is just too expensive and too much to manage. Plus Internet connectivity is not inherent in the mechanism you use to build your VPN, so has to be managed on top of that. With #2, the customer has to manage the IPSec sessions. Sure, you could manage the CPE, but then *you* have to manage the IPSec sessions. And full-mesh is still a problem with many (hundreds to thousands) of sites, so you have to have hub and spoke again. One place IPSec works real well, though, is for roaming access - plug in anywhere, and IPSec-tunnel back to your corporate access point. SO I'm not saying IPSec is dissmissable just yet. With #3, the customer has nothing to manage. And the provider has to manage a technology whose main scalability concern is BGP. Sure, you can overload BGP on anybody's box if you add too many routes and/or neighbors. But it seems to me that there are design schemes to make it so that your PE does not have to do all the work. So yes, you have to do more work and buy more routers. And no, MPLS BGP VPNs are not the solution to every possible VPN or VPN-like scenario you could come up with. But the assumption here is that it is less expensive for the (I)SP to manage an MPLS VPN setup (conectivity information distributed by BGP) than to manage/administer a large number of IPSec sessions. My assumption may be wrong, but certainly there are enough people out there who are actively pursuing MPLS VPN as a connectivity service that I don't think the assumption is too far off-base. So customers give you money to provide a VPN service. You give some of this money to your vendor of choice, give some to your infrastructure buildout, and keep the rest. :) eric > > and, as it seems to be agreed that the 2547 cleverness is > not really for isps, it's lucky we have a useful alternative. > > randy From owner-mpls@UU.NET Fri Oct 27 01:21:51 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28834 for ; Fri, 27 Oct 2000 01:21:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmrd28738; Fri, 27 Oct 2000 05:19:03 GMT Received: by mail-control.mail.uu.net id QQjmrd11364 for mpls-outgoing; Fri, 27 Oct 2000 05:18:36 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmrd11359 for ; Fri, 27 Oct 2000 05:18:33 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmrd23705 for ; Fri, 27 Oct 2000 05:18:18 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjmrd01652 for ; Fri, 27 Oct 2000 05:18:18 GMT Received: from gketell-lt.juniper.net (ssh.juniper.net [207.17.136.39]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id WAA13319; Thu, 26 Oct 2000 22:17:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20001026221318.04c1aec8@localhost> X-Sender: gketell@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Oct 2000 22:16:33 -0700 To: Eric Osborne , Randy Bush From: Greg Ketell Subject: Re: VPN solution - White flag ? Cc: Eric Gray , mpls@UU.NET In-Reply-To: <20001026231304.A25090@che-cse-115.cisco.com> References: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk You are forgetting the obvious, which is being sold around the world today (and has been being sold since at least 1995 when I was installing it): managed router service. IPSec at the edges with the customer paying the (I)SP to manage the CPE. Add some CoS capabilities in the core to give priority to the IPSec traffic and you have a very good service offering. With the correct tools the management of it scales well too. GK At 11:13 PM 10/26/2000 -0400, Eric Osborne wrote: >On Thu, Oct 26, 2000 at 03:37:31PM -0700, Randy Bush wrote: > > > On a technical note (:-)) - I believe it is > > > possible to support a logarithmic growth in the > > > number of "boxes" relative to services. I suspect > > > this would make service providers happier than a > > > linear growth. > > > > but not as happy as zero growth, which solutions such as > > ipsec provide. remember, for a provider, management cost > > is a function of number of customers, which we want to > > increase, and routers,which we prefer not to increase. > >Sure, but consider what you can sell. If the customer usees IPSec, >they they have to manage the VPN themselves, as well as needing to >approximate something close to N^2 connections. If the (I)SP sells >VPN service, then the customer has offloaded the work onto the ISP. > >There's a few ways you can give private-network solutions to an >enterprise. The ones I can think of are: > >1) dedicated line (ATM/FR/Leased Line) >2) IPSec sessions over Internet connectivity >3) MPLS VPN > >With #1, the customer can't do full-mesh, becuase with a large enough >number of sites, full-mesh is just too expensive and too much to >manage. Plus Internet connectivity is not inherent in the mechanism >you use to build your VPN, so has to be managed on top of that. > >With #2, the customer has to manage the IPSec sessions. Sure, you >could manage the CPE, but then *you* have to manage the IPSec >sessions. And full-mesh is still a problem with many (hundreds to >thousands) of sites, so you have to have hub and spoke again. One >place IPSec works real well, though, is for roaming access - plug in >anywhere, and IPSec-tunnel back to your corporate access point. SO >I'm not saying IPSec is dissmissable just yet. > >With #3, the customer has nothing to manage. And the provider has to >manage a technology whose main scalability concern is BGP. Sure, you >can overload BGP on anybody's box if you add too many routes and/or >neighbors. But it seems to me that there are design schemes to make >it so that your PE does not have to do all the work. > >So yes, you have to do more work and buy more routers. And no, MPLS >BGP VPNs are not the solution to every possible VPN or VPN-like >scenario you could come up with. But the assumption here is that it >is less expensive for the (I)SP to manage an MPLS VPN setup >(conectivity information distributed by BGP) than to manage/administer >a large number of IPSec sessions. My assumption may be wrong, but >certainly there are enough people out there who are actively pursuing >MPLS VPN as a connectivity service that I don't think the assumption >is too far off-base. > >So customers give you money to provide a VPN service. You give some >of this money to your vendor of choice, give some to your >infrastructure buildout, and keep the rest. :) > > > > >eric > > > > > > and, as it seems to be agreed that the 2547 cleverness is > > not really for isps, it's lucky we have a useful alternative. > > > > randy From owner-mpls@UU.NET Fri Oct 27 02:19:23 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05727 for ; Fri, 27 Oct 2000 02:19:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmrh11280; Fri, 27 Oct 2000 06:18:20 GMT Received: by mail-control.mail.uu.net id QQjmrh26380 for mpls-outgoing; Fri, 27 Oct 2000 06:17:56 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmrh26375 for ; Fri, 27 Oct 2000 06:17:55 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmrh25838 for ; Fri, 27 Oct 2000 06:15:58 GMT Received: from rip.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjmrh20759 for ; Fri, 27 Oct 2000 06:15:57 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13p2o0-000Jvh-00; Thu, 26 Oct 2000 23:15:56 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Osborne Cc: mpls@UU.NET Subject: Re: VPN solution - White flag ? References: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> <20001026231304.A25090@che-cse-115.cisco.com> Message-Id: Date: Thu, 26 Oct 2000 23:15:56 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > If the customer usees IPSec, they they have to manage the VPN themselves, bzzzt! next contestant. > as well as needing to approximate something close to N^2 connections. no. though as many security associations as vpns need to be created. of course, as 2547 has no securith, there is no such problem there. of course, being security conscious when selling a vpn, i don't see that as a benefit. > If the (I)SP sells VPN service, then the customer has offloaded the work > onto the ISP. indeed. > There's a few ways you can give private-network solutions to an > enterprise. The ones I can think of are: > 1) dedicated line (ATM/FR/Leased Line) > 2) IPSec sessions over Internet connectivity > 3) MPLS VPN yup. except i worry about the privacy in 1 and 3. but they can run ipsec over l2 or over the l2.5 tunnel. > With #1, the customer can't do full-mesh, becuase with a large enough > number of sites, full-mesh is just too expensive and too much to > manage. agreed. but many customers have the layer 2 solution today and want to convert. kompella's solution looks tasty, but i want to see more about how to provision it. > Plus Internet connectivity is not inherent in the mechanism you use to > build your VPN, so has to be managed on top of that. isps think of it as overlaying managed ipsec services on top of internet connectivity. > With #2, the customer has to manage the IPSec sessions. not any more than they do for 2547. the isp can maintain the cpe, the tunnel can originate on the isp's router a la 2547, or one can use one of the ipsec aggregation boxes. > Sure, you could manage the CPE, but then *you* have to manage the IPSec > sessions. as i have to manage the lsps. no biger deal. except with ipsec there is no weight in the middle of my network. internet architecture 101, unlike the phone network, the internet is a stupid middle with smart edges. > And full-mesh is still a problem with many (hundreds to thousands) of > sites, so you have to have hub and spoke again. not at all. it's all in the provisioning tools. > With #3, the customer has nothing to manage. And the provider has to > manage a technology whose main scalability concern is BGP. it violates a basic architectural principal. bgp is the first bad consequence we see. i am far from sanguine it will be the only one. > So yes, you have to do more work and buy more routers. thanks anyway. > So customers give you money to provide a VPN service. You give some of > this money to your vendor of choice, give some to your infrastructure > buildout, and keep the rest. :) or give them security and vpns, and keep all the cash (or charge less). plus i have some hope of my network continuing to scale. and scaling is what the internet is about. randy From owner-mpls@UU.NET Fri Oct 27 02:24:14 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07746 for ; Fri, 27 Oct 2000 02:24:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmrh17765; Fri, 27 Oct 2000 06:23:28 GMT Received: by mail-control.mail.uu.net id QQjmrh26682 for mpls-outgoing; Fri, 27 Oct 2000 06:23:10 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmrh26677 for ; Fri, 27 Oct 2000 06:23:05 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmrh11279 for ; Fri, 27 Oct 2000 06:22:54 GMT Received: from alvin.loniis.spb.su by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gw1.loniis.spb.su [195.201.37.253]) id QQjmrh29151 for ; Fri, 27 Oct 2000 06:22:42 GMT Received: from inser.loniis.spb.su (inser.loniis.spb.su [195.201.37.61] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id e9R6MVG26445 for ; Fri, 27 Oct 2000 10:22:31 +0400 (MSD) Received: from af.ten.loniis.int ([192.168.10.65]) by inser.loniis.spb.su (8.9.3/8.9.3) with SMTP id KAA01124 for ; Fri, 27 Oct 2000 10:22:26 +0400 (MSD) Message-ID: <000901c03fe6$b8290d60$410aa8c0@ten.loniis.int> From: "Andrew A. Philippoff" To: Subject: ubsubscribe Date: Fri, 27 Oct 2000 10:22:47 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From owner-mpls@UU.NET Fri Oct 27 04:05:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16842 for ; Fri, 27 Oct 2000 04:05:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmro24887; Fri, 27 Oct 2000 08:05:23 GMT Received: by mail-control.mail.uu.net id QQjmro24987 for mpls-outgoing; Fri, 27 Oct 2000 08:04:49 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmro24982 for ; Fri, 27 Oct 2000 08:04:43 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmro04318 for ; Fri, 27 Oct 2000 08:04:14 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmro05799 for ; Fri, 27 Oct 2000 08:04:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA18705 for mpls@uu.net; Fri, 27 Oct 2000 04:04:13 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmro24676 for ; Fri, 27 Oct 2000 08:03:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmro15859 for ; Fri, 27 Oct 2000 08:02:53 GMT Received: from ogma.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjmro04021 for ; Fri, 27 Oct 2000 08:02:53 GMT Received: from london.cisco.com (london.cisco.com [144.254.32.10]) by ogma.cisco.com (Postfix) with ESMTP id C4AEA134; Fri, 27 Oct 2000 10:02:44 +0200 (MET DST) Received: from jguichar-8kcdt.cisco.com (jguichar-isdn-home.cisco.com [10.49.131.222]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id KAA17675; Fri, 27 Oct 2000 10:02:43 +0200 (MET DST) Message-Id: <200010270802.KAA17675@london.cisco.com> X-Sender: jguichar@uk.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 27 Oct 2000 08:59:53 +0100 To: Randy Bush , Eric Gray From: Jim Guichard Subject: RE: VPN solution - White flag ? Cc: mpls@UU.NET In-Reply-To: References: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Randy, I think there are many ISPs that would disagree with you, especially here in Europe. Therefore, we are not all agreed that 2547 is a useless alternative to overlay or other types of peer-to-peer VPN connectivity. So, if the glove does not fit, do not wear it, this is fine .... but it is a solution that many ISPs have adopted and are implementing as we speak, so we cannot make a generalization .. Jim At 15:37 26/10/2000 -0700, Randy Bush wrote: >> On a technical note (:-)) - I believe it is >> possible to support a logarithmic growth in the >> number of "boxes" relative to services. I suspect >> this would make service providers happier than a >> linear growth. > >but not as happy as zero growth, which solutions such as >ipsec provide. remember, for a provider, management cost >is a function of number of customers, which we want to >increase, and routers,which we prefer not to increase. > >and, as it seems to be agreed that the 2547 cleverness is >not really for isps, it's lucky we have a useful alternative. > >randy > Jim Guichard CCIE #2069 Network Design Consultant EMEA Global Solutions Engineering +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Fri Oct 27 09:37:04 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25700 for ; Fri, 27 Oct 2000 09:37:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsk14151; Fri, 27 Oct 2000 13:36:08 GMT Received: by mail-control.mail.uu.net id QQjmsk11696 for mpls-outgoing; Fri, 27 Oct 2000 13:35:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmsk11691 for ; Fri, 27 Oct 2000 13:35:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmsk27032 for ; Fri, 27 Oct 2000 13:34:40 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmsk26668 for ; Fri, 27 Oct 2000 13:34:39 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA21351; Fri, 27 Oct 2000 06:34:39 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA28015; Fri, 27 Oct 2000 09:34:37 -0400 (EDT) Message-Id: <200010271334.JAA28015@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Vijay Gill cc: mpls@UU.NET Subject: Re: VPN solution - White flag ? In-reply-to: Your message of Thu, 26 Oct 2000 14:04:04 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Oct 2000 09:34:37 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk I think Vijay's message reveals a presupposition about the business model which is worth pointing out, viz., that Internet access is the primary business and VPN service a side line. All Internet routes are brought to the edge because "a couple of customers insist on having full routes". And one doesn't deploy equipment "just to aggregate VPN customers". If one's business were primarily VPN service, one would be a lot more likely to say "I'm not going to bring full routes to the edge just for the few customers which want them; those customers are already running EBGP, they can just run it multi-hop". I'm sure someone will respond that there are no SPs who are primarily in the VPN business and only secondarily in the Internet access business ;-) From owner-mpls@UU.NET Fri Oct 27 10:11:40 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05057 for ; Fri, 27 Oct 2000 10:11:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsl15782; Fri, 27 Oct 2000 13:59:17 GMT Received: by mail-control.mail.uu.net id QQjmsl13136 for mpls-outgoing; Fri, 27 Oct 2000 13:58:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmsl13124 for ; Fri, 27 Oct 2000 13:58:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmsl05999 for ; Fri, 27 Oct 2000 13:57:00 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmsl12559 for ; Fri, 27 Oct 2000 13:57:00 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA02137; Fri, 27 Oct 2000 06:56:57 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA28073; Fri, 27 Oct 2000 09:56:58 -0400 (EDT) Message-Id: <200010271356.JAA28073@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Greg Ketell cc: Eric Osborne , Randy Bush , Eric Gray , mpls@UU.NET Subject: Re: VPN solution - White flag ? In-reply-to: Your message of Thu, 26 Oct 2000 22:16:33 -0700. <4.3.2.7.2.20001026221318.04c1aec8@localhost> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Oct 2000 09:56:57 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Greg> You are forgetting the obvious, which is being sold around the world Greg> today (and has been being sold since at least 1995 when I was Greg> installing it): managed router service. No one is forgetting this. Most of the SPs who are moving to layer 3 VPNs have been doing this for years. Many of the SPs who actually have been offering managed router services over layer 2 backbones don't seem to think it's so scalable. Greg> IPSec at the edges with the customer paying the (I)SP to manage the Greg> CPE. Add some CoS capabilities in the core to give priority to the Greg> IPSec traffic and you have a very good service offering. With the Greg> correct tools the management of it scales well too. Well, we could have a long discussion of the alleged scalability of IPsec, but I doubt we'd reach much of a consensus. You will note that there seems to be a considerable market for PE-based IPsec capabilities. Given the fact that CPE-based IPsec provides a lot more security, the existence of this market perhaps says something about what many SPs think of CPE-based solutions. Whether layer 3 VPNs or a managed router service over layer 2 VPNs is the best solution for a Service Provider to offer is certainly something that each Service Provider can decide for himself. From owner-mpls@UU.NET Fri Oct 27 10:27:56 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09787 for ; Fri, 27 Oct 2000 10:27:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsn27462; Fri, 27 Oct 2000 14:25:42 GMT Received: by mail-control.mail.uu.net id QQjmsn26655 for mpls-outgoing; Fri, 27 Oct 2000 14:25:01 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmsn26634 for ; Fri, 27 Oct 2000 14:24:42 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmsn22926; Fri, 27 Oct 2000 14:24:09 GMT Received: from smtprch1.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjmsn20414; Fri, 27 Oct 2000 14:24:08 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 27 Oct 2000 09:19:05 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 27 Oct 2000 09:19:01 -0500 Message-ID: <6DDA62170439D31185750000F80826AC0430F9A7@zmerd004.ca.nortel.com> From: "David Allan" To: Mark Stewart Cc: alchiu , "'Yakov Rekhter'" , ip-optical , mpls , sc , xuyg , yxue Subject: RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh Date: Fri, 27 Oct 2000 09:18:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04020.D6B08E40" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04020.D6B08E40 Content-Type: text/plain Mark: I would agree that this is true if we are looking at a relatively invariant network topology and the entity in the network performing the "design" of the protection scheme for the new paths and SLA has a comprehensive view of network state. I also think that the optical space has a lot of complexity (consideration for amplifiers, regen etc.) which would suggest that we are going to have a relatively invariant topology for a while (although we are all working hard to eliminate much of this complexity or at least the need for its visibility to higher layers). At some point though, when it is common that a fiber carries 80 OC192s so I have a capacity to configure some 15000 STS-1s on a given span in varying degress of concatenation, and we are trying to get STS provisioning down to LSP setup times, then we need to acknowledge that some central entity doing all of this is eventually going to break. At that point we need distributed algorithms and possibly hierarchical routing, with all the issues that entails (including the possiblity of "no-solution"). At the risk of inflamming the audience, as far as SLAs are concerned, what is an ATM SVC, and PNNI, other than a distributed means of establishing paths with a given SLA? If the expectation is that we are only going to do "gross tweaking" and the granulatity of the managed paths is always going to track technology at some fixed fraction of what is capable (e.g. if STSn is the biggest path, then STSn/x (where 'x' is fixed), will be the smallest granularity manipulated regardless of the value of 'n'.), then we are doing a lot of work simply to preserve the status quo and probably assuming that there is only going to be one type of payload (e.g. IP packets). We are limiting ourselves to traffic engineering. Given all the points brought up on this thread so far, that is not a good assumption. It is probably more reasonable to say that the core of the network needs to scale faster that the requirements for bandwidth of individual clients and centralized path establishment will be inadequate at some point. regards Dave > -----Original Message----- > From: Mark Stewart [SMTP:Mstewart@nexen.com] > Sent: Thursday, October 26, 2000 9:41 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; yxue > Subject: Re: [IP-Optical] RE: Optical link bundling. Was Re: > DraftMinutes From Pittsburgh > > Hi Dave > > The concept of jointly routing primary and protection paths has been > well accepted by Bell heads looking at optimizing their networks for a > long time. Part of the reason for this is the assumption that protection > path(s) must also be conformant to the same SLA as the primary path, and > joint routing is the most likely to achieve this. > > This does not of course address your concerns about race conditions at > connection establishment. But joint routing is guaranteed to produce a > solution not worse than independent routing, and results in a lower > commitment of network resources. > > ciao > > mark ------_=_NextPart_001_01C04020.D6B08E40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] RE: Optical link bundling. Was Re: DraftMinutes = From Pittsburgh

Mark:

I would agree that = this is true if we are looking at a relatively invariant network = topology and the entity in the network performing the = "design" of the protection scheme for the new paths and SLA = has a comprehensive view of network state. I also think that the = optical space has a lot of complexity (consideration for amplifiers, = regen etc.) which would suggest that we are going to have a relatively = invariant topology for a while (although we are all working hard to = eliminate much of this complexity or at least the need for its = visibility to higher layers).

At some point = though, when it is common that a fiber carries 80 OC192s so I have a = capacity to configure some 15000 STS-1s on a given span in varying = degress of concatenation, and we are trying to get STS provisioning = down to LSP setup times, then we need to acknowledge that some central = entity doing all of this is eventually going to break. At that point we = need distributed algorithms and possibly hierarchical routing, with all = the issues that entails (including the possiblity of = "no-solution"). At the risk of inflamming the audience, as = far as SLAs are concerned, what is an ATM SVC, and PNNI, other than a = distributed means of establishing paths with a given SLA?

If the expectation = is that we are only going to do "gross tweaking" and the = granulatity of the managed paths is always going to track technology at = some fixed fraction of what is capable (e.g. if STSn is the biggest = path, then STSn/x (where 'x' is fixed), will be the smallest = granularity manipulated regardless of the value of 'n'.), then we are = doing a lot of work simply to preserve the status quo and probably = assuming that there is only going to be one type of payload (e.g. IP = packets). We are limiting ourselves to traffic engineering. Given all = the points brought up on this thread so far, that is not a good = assumption. It is probably more reasonable to say that the core of the = network needs to scale faster that the requirements for bandwidth of = individual clients and centralized path establishment will be = inadequate at some point.

regards
Dave




    -----Original Message-----
    From:   Mark Stewart [SMTP:Mstewart@nexen.com]
    Sent:   Thursday, October 26, 2000 9:41 AM
    To:     Allan, David [CAR:NS00:EXCH]
    Cc:     alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; = yxue
    Subject:       = Re: [IP-Optical] RE: Optical link = bundling. Was Re: DraftMinutes From  Pittsburgh

    Hi Dave

    The concept of jointly routing primary = and protection paths has been
    well accepted by Bell heads looking = at optimizing their networks for a
    long time. Part of the reason for = this is the assumption that protection
    path(s) must also be conformant to = the same SLA as the primary path, and
    joint routing is the most likely to = achieve this.

    This does not of course address your = concerns about race conditions at
    connection establishment. But joint = routing is guaranteed to produce a
    solution not worse than independent = routing, and results in a lower
    commitment of network = resources.

    ciao

    mark
    <snip>

------_=_NextPart_001_01C04020.D6B08E40-- From owner-mpls@UU.NET Fri Oct 27 11:07:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19730 for ; Fri, 27 Oct 2000 11:07:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsq01425; Fri, 27 Oct 2000 15:06:20 GMT Received: by mail-control.mail.uu.net id QQjmsq10887 for mpls-outgoing; Fri, 27 Oct 2000 15:05:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmsq10456 for ; Fri, 27 Oct 2000 15:04:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmsq06824 for ; Fri, 27 Oct 2000 15:04:30 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQjmsq28222 for ; Fri, 27 Oct 2000 15:04:29 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id LAA24507 for ; Fri, 27 Oct 2000 11:04:29 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; FRI, 27 Oct 2000 10:55:15 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 10:55:15 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E5614F26A@newman.tenornet.com> From: "Arvind, K" To: mpls@UU.NET Cc: "Arvind, K" Subject: Bandwidth encoding in draft-ietf-mpls-generalized-signaling-00.tx t Date: Fri, 27 Oct 2000 10:55:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk According to the draft, bandwidth encodings "are carried in 32 bit number in IEEE floating point format (the unit is bytes per second)". However, the encodings provided in Section 3.1.4 appear to be for bits per sec rather than bytes per sec. Would someone be kind enough to double check the numbers and correct any "binary blindness" on my part? :-) Thanks. Regards, Arvind. As per RFC1832, a floating point number is represented as follows (if the following appears garbled, please use a fixed width font such as courier) The standard defines the floating-point data type "float" (32 bits or 4 bytes). The encoding used is the IEEE standard for normalized single-precision floating-point numbers [3]. The following three fields describe the single-precision floating-point number: S: The sign of the number. Values 0 and 1 represent positive and negative, respectively. One bit. E: The exponent of the number, base 2. 8 bits are devoted to this field. The exponent is biased by 127. F: The fractional part of the number's mantissa, base 2. 23 bits are devoted to this field. Therefore, the floating-point number is described by: (-1)**S * 2**(E-Bias) * 1.F It is declared as follows: float identifier; +-------+-------+-------+-------+ |byte 0 |byte 1 |byte 2 |byte 3 | SINGLE-PRECISION S| E | F | FLOATING-POINT NUMBER +-------+-------+-------+-------+ 1|<- 8 ->|<-------23 bits------>| <------------32 bits------------> A bit rate of DS0 = 0.064 Mbps = 64000 bps = 8000 Bytes per sec = 4096*1.953125 = (-1)**0 * 2**15 * 1.953125 = (-1)**0 * 2**(142-127) * 1.953125 (=> S=0, E=142, F=953125) = 0 10001110 00011101000101100100101 = 0x470D8B25 A similar calculation using 64000 instead of 8000 yields 0x477A0000 (the value provided in the draft for DS0). The same is true for DS1. The floating point representation provided in the draft (0x49BC7A00) corresponds to 1.544 Mbps and not 193000 bytes/sec. Based on these 2 samples, it appears all the numbers are off by a factor of 8 (i.e., bits per sec rather than bytes per sec). From owner-mpls@UU.NET Fri Oct 27 11:09:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19985 for ; Fri, 27 Oct 2000 11:09:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsq28846; Fri, 27 Oct 2000 15:04:49 GMT Received: by mail-control.mail.uu.net id QQjmsq08407 for mpls-outgoing; Fri, 27 Oct 2000 15:04:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmsq07486 for ; Fri, 27 Oct 2000 15:03:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmsq29760; Fri, 27 Oct 2000 15:02:28 GMT Received: from nexen.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maelstrom.nexen.com [204.249.97.5]) id QQjmsq23696; Fri, 27 Oct 2000 15:02:27 GMT Received: from phish.nexen.com (phish-98 [204.249.98.14]) by nexen.com (8.11.0/8.11.0) with ESMTP id e9RF2Sl15168; Fri, 27 Oct 2000 10:02:28 -0500 (EST) Received: from nexen.com (bhome [204.249.97.124]) by phish.nexen.com (8.8.5/8.8.5) with ESMTP id LAA08602; Fri, 27 Oct 2000 11:02:15 -0400 (EDT) Message-ID: <39F99901.FB2899A3@nexen.com> Date: Fri, 27 Oct 2000 11:02:26 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Allan CC: alchiu , "'Yakov Rekhter'" , ip-optical , mpls , sc , xuyg , yxue Subject: Re: [IP-Optical] Joint Routing was RE: Optical link bundling. Was Re: DraftMinutes From Pittsburgh References: <6DDA62170439D31185750000F80826AC0430F9A7@zmerd004.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dave Why are we equating joint routing with centralized computation? Few (if any) members of the IETF would dispute that centralized computation has nasty scaling problems; but I thought we were discussing joint routing. Mark David Allan wrote: > > > Mark: > > I would agree that this is true if we are looking at a relatively > invariant network topology and the entity in the network performing > the "design" of the protection scheme for the new paths and SLA has a > comprehensive view of network state. I also think that the optical > space has a lot of complexity (consideration for amplifiers, regen > etc.) which would suggest that we are going to have a relatively > invariant topology for a while (although we are all working hard to > eliminate much of this complexity or at least the need for its > visibility to higher layers). > > At some point though, when it is common that a fiber carries 80 OC192s > so I have a capacity to configure some 15000 STS-1s on a given span in > varying degress of concatenation, and we are trying to get STS > provisioning down to LSP setup times, then we need to acknowledge that > some central entity doing all of this is eventually going to break. At > that point we need distributed algorithms and possibly hierarchical > routing, with all the issues that entails (including the possiblity of > "no-solution"). At the risk of inflamming the audience, as far as SLAs > are concerned, what is an ATM SVC, and PNNI, other than a distributed > means of establishing paths with a given SLA? > > If the expectation is that we are only going to do "gross tweaking" > and the granulatity of the managed paths is always going to track > technology at some fixed fraction of what is capable (e.g. if STSn is > the biggest path, then STSn/x (where 'x' is fixed), will be the > smallest granularity manipulated regardless of the value of 'n'.), > then we are doing a lot of work simply to preserve the status quo and > probably assuming that there is only going to be one type of payload > (e.g. IP packets). We are limiting ourselves to traffic engineering. > Given all the points brought up on this thread so far, that is not a > good assumption. It is probably more reasonable to say that the core > of the network needs to scale faster that the requirements for > bandwidth of individual clients and centralized path establishment > will be inadequate at some point. > > regards > Dave > > > > -----Original Message----- > From: Mark Stewart [SMTP:Mstewart@nexen.com] > Sent: Thursday, October 26, 2000 9:41 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; yxue > > Subject: Re: [IP-Optical] RE: Optical link bundling. Was > Re: DraftMinutes From Pittsburgh > > Hi Dave > > The concept of jointly routing primary and protection paths has > been > well accepted by Bell heads looking at optimizing their networks > for a > long time. Part of the reason for this is the assumption that > protection > path(s) must also be conformant to the same SLA as the primary > path, and > joint routing is the most likely to achieve this. > > This does not of course address your concerns about race > conditions at > connection establishment. But joint routing is guaranteed to > produce a > solution not worse than independent routing, and results in a > lower > commitment of network resources. > > ciao > > mark > > From owner-mpls@UU.NET Fri Oct 27 11:11:39 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20624 for ; Fri, 27 Oct 2000 11:11:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsq07206; Fri, 27 Oct 2000 15:09:59 GMT Received: by mail-control.mail.uu.net id QQjmsq11176 for mpls-outgoing; Fri, 27 Oct 2000 15:09:11 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmsq11170 for ; Fri, 27 Oct 2000 15:09:09 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmsq09022 for ; Fri, 27 Oct 2000 15:08:37 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmsq12695 for ; Fri, 27 Oct 2000 15:08:36 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA19152 for mpls@uu.net; Fri, 27 Oct 2000 11:08:35 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmsq11092 for ; Fri, 27 Oct 2000 15:08:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmsq08207 for ; Fri, 27 Oct 2000 15:07:09 GMT Received: from mail2.packetengines.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail2.packetengines.com [208.227.187.173]) id QQjmsq25361 for ; Fri, 27 Oct 2000 15:07:08 GMT Received: from hostr607.alcatel.com by mail2.packetengines.com via smtpd (for cmr1.ash.ops.us.uu.net [198.5.241.39]) with SMTP; 27 Oct 2000 15:07:08 UT Received: by steam with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 08:06:41 -0700 Message-ID: From: Dan Graybeal To: "'mpls@UU.NET'" Subject: unsubscribe Date: Fri, 27 Oct 2000 08:06:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Fri Oct 27 11:19:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22541 for ; Fri, 27 Oct 2000 11:19:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsr20021; Fri, 27 Oct 2000 15:18:46 GMT Received: by mail-control.mail.uu.net id QQjmsr12006 for mpls-outgoing; Fri, 27 Oct 2000 15:18:08 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmsr11981 for ; Fri, 27 Oct 2000 15:17:57 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmsr27966 for ; Fri, 27 Oct 2000 15:16:42 GMT Received: from ns1.arch.bellsouth.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.arch.bellsouth.net [205.152.173.2]) id QQjmsr16850 for ; Fri, 27 Oct 2000 15:16:41 GMT Received: (from ck@localhost) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) id LAA13706; Fri, 27 Oct 2000 11:16:25 -0400 (EDT) Date: Fri, 27 Oct 2000 11:16:25 -0400 From: Christian Kuhtz To: Randy Bush Cc: Eric Osborne , mpls@UU.NET Subject: Re: VPN solution - White flag ? Message-ID: <20001027111625.L26378@ns1.arch.bellsouth.net> References: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> <20001026231304.A25090@che-cse-115.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Randy Bush on Thu, Oct 26, 2000 at 11:15:56PM -0700 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Oct 26, 2000 at 11:15:56PM -0700, Randy Bush wrote: > no. though as many security associations as vpns need to be created. of > course, as 2547 has no securith, there is no such problem there. of course, > being security conscious when selling a vpn, i don't see that as a benefit. Hmm, so, what percentage of l2 VPN customers would you say are buying crypto gear to crypt their frame and cell shredder ckts? -- Christian Kuhtz Architecture, BellSouth.net -wk, -hm Atlanta, GA "Speaking for myself only." From owner-mpls@UU.NET Fri Oct 27 11:26:12 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24529 for ; Fri, 27 Oct 2000 11:26:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsr19935; Fri, 27 Oct 2000 15:24:42 GMT Received: by mail-control.mail.uu.net id QQjmsr12427 for mpls-outgoing; Fri, 27 Oct 2000 15:24:12 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmsr12418 for ; Fri, 27 Oct 2000 15:24:09 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmsr12865; Fri, 27 Oct 2000 15:23:37 GMT Received: from smtprch1.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjmsr03776; Fri, 27 Oct 2000 15:23:37 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 27 Oct 2000 10:10:37 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 27 Oct 2000 10:10:31 -0500 Message-ID: <6DDA62170439D31185750000F80826AC0430FAED@zmerd004.ca.nortel.com> From: "David Allan" To: Mark Stewart Cc: alchiu , "'Yakov Rekhter'" , ip-optical , mpls , sc , xuyg , yxue Subject: RE: [IP-Optical] Joint Routing Date: Fri, 27 Oct 2000 10:10:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04028.05EBE8B0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04028.05EBE8B0 Content-Type: text/plain True, they are separate concepts. Centralzied computing is A solution to the problem of ensuring a synchronized and authoriative view of the network which is what I would assume joint routing requires. So what I am really discussing is the scaling limitations that a synched and comprehensive network view has regardless of how the algorithm is implemented, especially as the dynamic behavior of the network increases with time. Dave > -----Original Message----- > From: Mark Stewart [SMTP:Mstewart@nexen.com] > Sent: Friday, October 27, 2000 11:02 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; yxue > Subject: Re: [IP-Optical] Joint Routing was RE: Optical link > bundling. Was Re: DraftMinutes From Pittsburgh > > Hi Dave > > Why are we equating joint routing with centralized computation? Few (if > any) members of the IETF would dispute that centralized computation has > nasty scaling problems; but I thought we were discussing joint routing. > > Mark > ------_=_NextPart_001_01C04028.05EBE8B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] Joint Routing

True, they are = separate concepts. Centralzied computing is A solution to the problem = of ensuring a synchronized and authoriative view of the network which = is what I would assume joint routing requires. So what I am really = discussing is the scaling limitations that a synched and comprehensive = network view has regardless of how the algorithm is implemented, = especially as the dynamic behavior of the network increases with = time.

Dave

    -----Original Message-----
    From:   Mark Stewart [SMTP:Mstewart@nexen.com]
    Sent:   Friday, October 27, 2000 11:02 AM
    To:     Allan, David [CAR:NS00:EXCH]
    Cc:     alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; = yxue
    Subject:       = Re: [IP-Optical] Joint Routing was = RE: Optical link bundling. Was Re:  DraftMinutes From = Pittsburgh

    Hi Dave

    Why are we equating joint routing with = centralized computation? Few (if
    any) members of the IETF would = dispute that centralized computation has
    nasty scaling problems; but I thought = we were discussing joint routing.

    Mark

    <snip>

------_=_NextPart_001_01C04028.05EBE8B0-- From owner-mpls@UU.NET Fri Oct 27 11:32:08 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27045 for ; Fri, 27 Oct 2000 11:32:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmss07218; Fri, 27 Oct 2000 15:30:52 GMT Received: by mail-control.mail.uu.net id QQjmss13087 for mpls-outgoing; Fri, 27 Oct 2000 15:30:19 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmss13082 for ; Fri, 27 Oct 2000 15:30:17 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmsr25920 for ; Fri, 27 Oct 2000 15:29:51 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjmsr12481 for ; Fri, 27 Oct 2000 15:29:50 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA23661 for ; Fri, 27 Oct 2000 08:29:50 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA28560 for mpls@uu.net; Fri, 27 Oct 2000 11:29:49 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmsr12314 for ; Fri, 27 Oct 2000 15:22:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmsr14163 for ; Fri, 27 Oct 2000 15:19:32 GMT Received: from baynet.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20]) id QQjmsr21330 for ; Fri, 27 Oct 2000 15:19:31 GMT Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id IAA14770 for ; Fri, 27 Oct 2000 08:17:57 -0700 (PDT) Received: from shasta-exch.shastanets.com (mailserver.shastanets.com [47.82.16.150]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA19249 for ; Fri, 27 Oct 2000 08:17:56 -0700 (PDT) Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 08:17:18 -0700 Message-ID: <940E42DB5D7FD4119C420004ACE6E0A08101D5@mailserver.shastanets.com> From: Janardan Ramesh To: "'mpls@uu.net'" Cc: shasta-routing Subject: Encoding of MP_REACH_NLRI Date: Fri, 27 Oct 2000 08:17:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk draft-ietf-mpls-bgp4-mpls-04.txt has the following sentence for the NLRI. Length(1), Label (3 - octest 1 or more labels), Prefix (variable) The description of length says: The length field indicates the length in bits of the address prefix plus the label(s). - First interpretation of this is that the label lengths are also encoded in bits. Take the example of 2 labels (48 bits) and a 26 bit prefix. The count will be 74. From the count it is not possible to say whether we have 2 labels (48 bits) and a 26 bit prefix or 3 labels (72 bits) and a 4 bit prefix. - Second interpretation of this is that the length field contains the label counbt and prefix length in bits. Take tha example of 2 labels and a 26 bit prefix. The length field will contain a count of 28. Assuming that there is always 1 label, this can mean that either we have 1 label and a 27 bir prefix or 2 labels and a 26 bit prefix. It would be really helpful to expand the semantics of this field and include a few examples to avoid ambiguity. Regards Ramesh From owner-mpls@UU.NET Fri Oct 27 11:44:54 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02668 for ; Fri, 27 Oct 2000 11:44:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmss24214; Fri, 27 Oct 2000 15:43:19 GMT Received: by mail-control.mail.uu.net id QQjmss14190 for mpls-outgoing; Fri, 27 Oct 2000 15:42:40 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmss14185 for ; Fri, 27 Oct 2000 15:42:39 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmss25562; Fri, 27 Oct 2000 15:42:26 GMT Received: from nexen.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: maelstrom.nexen.com [204.249.97.5]) id QQjmss22986; Fri, 27 Oct 2000 15:42:26 GMT Received: from phish.nexen.com (phish [204.249.97.14]) by nexen.com (8.11.0/8.11.0) with ESMTP id e9RFgRl16486; Fri, 27 Oct 2000 10:42:27 -0500 (EST) Received: from nexen.com (bhome [204.249.97.124]) by phish.nexen.com (8.8.5/8.8.5) with ESMTP id LAA09293; Fri, 27 Oct 2000 11:42:13 -0400 (EDT) Message-ID: <39F9A260.33EB31C3@nexen.com> Date: Fri, 27 Oct 2000 11:42:24 -0400 From: Mark Stewart X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Allan CC: alchiu , "'Yakov Rekhter'" , ip-optical , mpls , sc , xuyg , yxue Subject: Re: [IP-Optical] Joint Routing References: <6DDA62170439D31185750000F80826AC0430FAED@zmerd004.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------CFE6B3DC5D9E240CBFCC570F" Sender: owner-mpls@UU.NET Precedence: bulk --------------CFE6B3DC5D9E240CBFCC570F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Dave Well I certainly hope no one is proposing to mandate a centralized mechanism to implement joint routing. It's quite possible to do a source based solution which simply invokes dykstra twice instead of once and then has the same scaling and synchronization issues as OSPF. ciao mark David Allan wrote: > > > True, they are separate concepts. Centralzied computing is A solution > to the problem of ensuring a synchronized and authoriative view of the > network which is what I would assume joint routing requires. So what I > am really discussing is the scaling limitations that a synched and > comprehensive network view has regardless of how the algorithm is > implemented, especially as the dynamic behavior of the network > increases with time. > > Dave > > -----Original Message----- > From: Mark Stewart [SMTP:Mstewart@nexen.com] > Sent: Friday, October 27, 2000 11:02 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; yxue > > Subject: Re: [IP-Optical] Joint Routing was RE: Optical > link bundling. Was Re: DraftMinutes From Pittsburgh > > Hi Dave > > Why are we equating joint routing with centralized computation? > Few (if > any) members of the IETF would dispute that centralized > computation has > nasty scaling problems; but I thought we were discussing joint > routing. > > Mark > > > --------------CFE6B3DC5D9E240CBFCC570F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Dave

Well I certainly hope no one is proposing to mandate a centralized mechanism to implement joint routing. It's quite possible to do a source based solution which simply invokes dykstra twice instead of once and then has the same scaling and synchronization issues as OSPF.

ciao

mark

David Allan wrote:

 

True, they are separate concepts. Centralzied computing is A solution to the problem of ensuring a synchronized and authoriative view of the network which is what I would assume joint routing requires. So what I am really discussing is the scaling limitations that a synched and comprehensive network view has regardless of how the algorithm is implemented, especially as the dynamic behavior of the network increases with time.

Dave

    -----Original Message-----
    From:   Mark Stewart [SMTP:Mstewart@nexen.com]
    Sent:   Friday, October 27, 2000 11:02 AM
    To:     Allan, David [CAR:NS00:EXCH]
    Cc:     alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; yxue
    Subject:        Re: [IP-Optical] Joint Routing was RE: Optical link bundling. Was Re:  DraftMinutes From Pittsburgh

    Hi Dave

    Why are we equating joint routing with centralized computation? Few (if
    any) members of the IETF would dispute that centralized computation has
    nasty scaling problems; but I thought we were discussing joint routing.

    Mark

    <snip>

--------------CFE6B3DC5D9E240CBFCC570F-- From owner-mpls@UU.NET Fri Oct 27 11:54:41 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06910 for ; Fri, 27 Oct 2000 11:54:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmst06944; Fri, 27 Oct 2000 15:52:26 GMT Received: by mail-control.mail.uu.net id QQjmst14914 for mpls-outgoing; Fri, 27 Oct 2000 15:51:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmst14906 for ; Fri, 27 Oct 2000 15:51:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmst29231 for ; Fri, 27 Oct 2000 15:50:55 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmst04809 for ; Fri, 27 Oct 2000 15:50:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA27454 for mpls@uu.net; Fri, 27 Oct 2000 11:50:54 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmst14857 for ; Fri, 27 Oct 2000 15:50:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmst24998 for ; Fri, 27 Oct 2000 15:49:33 GMT Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmst23708 for ; Fri, 27 Oct 2000 15:49:33 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA10689; Fri, 27 Oct 2000 08:49:02 -0700 (PDT) Message-Id: <200010271549.IAA10689@omega.cisco.com> To: Janardan Ramesh cc: "'mpls@uu.net'" , shasta-routing Subject: Re: Encoding of MP_REACH_NLRI In-reply-to: Your message of "Fri, 27 Oct 2000 08:17:09 PDT." <940E42DB5D7FD4119C420004ACE6E0A08101D5@mailserver.shastanets.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10687.972661741.1@cisco.com> Date: Fri, 27 Oct 2000 08:49:01 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Janardan, > draft-ietf-mpls-bgp4-mpls-04.txt has the following sentence > for the NLRI. > > Length(1), Label (3 - octest 1 or more labels), Prefix (variable) > > The description of length says: > > The length field indicates the length in bits of the address > prefix plus the label(s). > > > - First interpretation of this is that the label lengths are also > encoded in bits. > > Take the example of 2 labels (48 bits) and a 26 bit prefix. > The count will be 74. From the count it is not possible > to say whether we have 2 labels (48 bits) and a 26 bit prefix or > 3 labels (72 bits) and a 4 bit prefix. > > - Second interpretation of this is that the length field contains the > label counbt and prefix length in bits. > > Take tha example of 2 labels and a 26 bit prefix. The length > field will contain a count of 28. Assuming that there is > always 1 label, this can mean that either we have 1 label > and a 27 bir prefix or 2 labels and a 26 bit prefix. quoting from the Internet Draft: a) Length: The Length field indicates the length in bits of the address prefix plus the label(s). b) Label: The Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). The following high-order three bits must be zero. The remaining 20 bits contain the label value. From (a) is seems quite clear that the length is the length in bits of the address prefix *plus* the label field. From (b) it seems quite clear that the label field could carry one or more labels, and that the number of labels carried in the label field is determined by looking at the "Bottom of Stack" field of each label. Yakov. From owner-mpls@UU.NET Fri Oct 27 12:17:40 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14597 for ; Fri, 27 Oct 2000 12:17:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsv17181; Fri, 27 Oct 2000 16:17:01 GMT Received: by mail-control.mail.uu.net id QQjmsv28426 for mpls-outgoing; Fri, 27 Oct 2000 16:16:19 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmsv28387 for ; Fri, 27 Oct 2000 16:16:03 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmsv14346 for ; Fri, 27 Oct 2000 16:15:30 GMT Received: from rip.psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjmsv28510 for ; Fri, 27 Oct 2000 16:15:30 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13pCAC-000OSH-00; Fri, 27 Oct 2000 09:15:28 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jim Guichard Cc: mpls@UU.NET Subject: RE: VPN solution - White flag ? References: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> <200010270802.KAA17675@london.cisco.com> Message-Id: Date: Fri, 27 Oct 2000 09:15:28 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I think there are many ISPs that would disagree with you, especially here > in Europe. unfortunately, all these big isps who are successfully deploying 2547 seem to have broken keyboards. i did not expect keyboard damage to be a scaling consequence of 2547, but surprises happen. :-) luckily, they seem to have many people with cisco email addresses to speak for them. randy From owner-mpls@UU.NET Fri Oct 27 12:21:42 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16131 for ; Fri, 27 Oct 2000 12:21:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsv22394; Fri, 27 Oct 2000 16:20:32 GMT Received: by mail-control.mail.uu.net id QQjmsv28769 for mpls-outgoing; Fri, 27 Oct 2000 16:20:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmsv28754 for ; Fri, 27 Oct 2000 16:19:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmsv07704; Fri, 27 Oct 2000 16:18:47 GMT Received: from smtprch2.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15]) id QQjmsv19837; Fri, 27 Oct 2000 16:18:47 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Fri, 27 Oct 2000 11:13:26 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 27 Oct 2000 11:17:28 -0500 Message-ID: <6DDA62170439D31185750000F80826AC0430FC60@zmerd004.ca.nortel.com> From: "David Allan" To: Mark Stewart Cc: alchiu , "'Yakov Rekhter'" , ip-optical , mpls , sc , xuyg , yxue Subject: RE: [IP-Optical] Joint Routing Date: Fri, 27 Oct 2000 11:17:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04031.624ECB00" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C04031.624ECB00 Content-Type: text/plain Mark: The original purpose of my observation was discussing joint vs, sequential, not centralized vs. distributed. This seems to be getting lost. Dave > -----Original Message----- > From: Mark Stewart [SMTP:Mstewart@nexen.com] > Sent: Friday, October 27, 2000 11:42 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; yxue > Subject: Re: [IP-Optical] Joint Routing > > Hi Dave > > Well I certainly hope no one is proposing to mandate a centralized > mechanism to implement joint routing. It's quite possible to do a source > based solution which simply invokes dykstra twice instead of once and then > has the same scaling and synchronization issues as OSPF. > > ciao > > mark > > David Allan wrote: > > > > True, they are separate concepts. Centralzied computing is A > solution to the problem of ensuring a synchronized and authoriative view > of the network which is what I would assume joint routing requires. So > what I am really discussing is the scaling limitations that a synched and > comprehensive network view has regardless of how the algorithm is > implemented, especially as the dynamic behavior of the network increases > with time. > > Dave > > -----Original Message----- > From: Mark Stewart [SMTP:Mstewart@nexen.com] > Sent: Friday, October 27, 2000 11:02 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; yxue > Subject: Re: [IP-Optical] Joint Routing was RE: Optical link > bundling. Was Re: DraftMinutes From Pittsburgh > > Hi Dave > > Why are we equating joint routing with centralized > computation? Few (if > any) members of the IETF would dispute that centralized computation > has > nasty scaling problems; but I thought we were discussing joint > routing. > > Mark > > > ------_=_NextPart_001_01C04031.624ECB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] Joint Routing

Mark:

The original purpose = of my observation was discussing joint vs, sequential, not centralized = vs. distributed. This seems to be getting lost.

Dave

    -----Original Message-----
    From:   Mark Stewart [SMTP:Mstewart@nexen.com]
    Sent:   Friday, October 27, 2000 11:42 AM
    To:     Allan, David [CAR:NS00:EXCH]
    Cc:     alchiu; 'Yakov Rekhter'; ip-optical; mpls; sc; xuyg; = yxue
    Subject:       = Re: [IP-Optical] Joint = Routing

    Hi Dave

    Well I certainly hope no one is proposing to = mandate a centralized mechanism to implement joint routing. It's quite = possible to do a source based solution which simply invokes dykstra = twice instead of once and then has the same scaling and synchronization = issues as OSPF.

    ciao

    mark

    David Allan wrote:

      =A0

      True, they are = separate concepts. Centralzied computing is A solution to the problem = of ensuring a synchronized and authoriative view of the network which = is what I would assume joint routing requires. So what I am really = discussing is the scaling limitations that a synched and comprehensive = network view has regardless of how the algorithm is implemented, = especially as the dynamic behavior of the network increases with = time.

      Dave

              -----Original Message-----
      From:=A0=A0 Mark Stewart = [SMTP:Mstewart@nexen.com]
      Sent:=A0=A0 Friday, October = 27, 2000 11:02 AM
      To:=A0=A0=A0=A0 Allan, David = [CAR:NS00:EXCH]
      Cc:=A0=A0=A0=A0 alchiu; 'Yakov = Rekhter'; ip-optical; mpls; sc; xuyg; yxue
      Subject:=A0=A0=A0=A0=A0=A0=A0 Re: [IP-Optical] = Joint Routing was RE: Optical link bundling. Was Re:=A0 DraftMinutes = From Pittsburgh

              Hi Dave

              Why are we equating joint routing with centralized = computation? Few (if
      any) members of the IETF would = dispute that centralized computation has
      nasty scaling problems; but I = thought we were discussing joint routing. =

              Mark

              <snip>

------_=_NextPart_001_01C04031.624ECB00-- From owner-mpls@UU.NET Fri Oct 27 12:27:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18130 for ; Fri, 27 Oct 2000 12:27:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsv23409; Fri, 27 Oct 2000 16:26:55 GMT Received: by mail-control.mail.uu.net id QQjmsv29309 for mpls-outgoing; Fri, 27 Oct 2000 16:26:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmsv29300 for ; Fri, 27 Oct 2000 16:26:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmsv27959 for ; Fri, 27 Oct 2000 16:25:46 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjmsv29565 for ; Fri, 27 Oct 2000 16:25:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA03185 for mpls@uu.net; Fri, 27 Oct 2000 12:25:45 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmsv29201 for ; Fri, 27 Oct 2000 16:25:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmsv23766 for ; Fri, 27 Oct 2000 16:24:21 GMT Received: from omega.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjmsv10846 for ; Fri, 27 Oct 2000 16:24:21 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA13422; Fri, 27 Oct 2000 09:23:45 -0700 (PDT) Message-Id: <200010271623.JAA13422@omega.cisco.com> To: Randy Bush cc: Eric Gray , mpls@UU.NET Subject: Re: VPN solution - White flag ? In-reply-to: Your message of "Thu, 26 Oct 2000 15:37:31 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13420.972663825.1@cisco.com> Date: Fri, 27 Oct 2000 09:23:45 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Randy, > > On a technical note (:-)) - I believe it is > > possible to support a logarithmic growth in the > > number of "boxes" relative to services. I suspect > > this would make service providers happier than a > > linear growth. > > but not as happy as zero growth, which solutions such as > ipsec provide. remember, for a provider, management cost > is a function of number of customers, which we want to > increase, and routers,which we prefer not to increase. > > and, as it seems to be agreed that the 2547 cleverness is > not really for isps, it's lucky we have a useful alternative. All I can say that the usefulness of various alternatives is unlikely to be determined by the debates on this list, but is likely to be determined by the competition on the marketplace. With this in mind, what exactly are you trying to accomplish by continuing this debate ? Yakov. From owner-mpls@UU.NET Fri Oct 27 12:33:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20202 for ; Fri, 27 Oct 2000 12:33:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsw08093; Fri, 27 Oct 2000 16:32:07 GMT Received: by mail-control.mail.uu.net id QQjmsw29599 for mpls-outgoing; Fri, 27 Oct 2000 16:31:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmsw29591 for ; Fri, 27 Oct 2000 16:31:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmsw12388 for ; Fri, 27 Oct 2000 16:30:33 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQjmsw19249 for ; Fri, 27 Oct 2000 16:30:33 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id MAA02528 for ; Fri, 27 Oct 2000 12:30:32 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; FRI, 27 Oct 2000 12:21:20 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 12:21:19 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E5614F26C@newman.tenornet.com> From: "Arvind, K" To: "'mpls@uu.net'" Cc: "Arvind, K" Subject: RE: Bandwidth encoding in draft-ietf-mpls-generalized-signaling-0 0.txt Date: Fri, 27 Oct 2000 12:21:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Attached is the output of a little C program that dumps floating point values in hex (unsigned long l = *(unsigned long *)&f). It confirms my observation that the encodings provided assume units of bits/sec rather than bytes/sec, and therefore conflict with the units specified earlier in the draft. Regards, Arvind 6.4e+04 : 477a0000 1.544e+06 : 49bc7a00 2.048e+06 : 49fa0000 6.312e+06 : 4ac0a080 8.448e+06 : 4b00e800 1e+07 : 4b189680 34 : 42080000 3.68e+08 : 4daf79e0 4.474e+07 : 4c2aa780 5.184e+07 : 4c45c100 1e+08 : 4cbebc20 1.393e+08 : 4d04d000 1.555e+08 : 4d1450c0 6.221e+08 : 4e1450c0 1e+09 : 4e6e6b28 2.488e+09 : 4f1450c0 9.953e+09 : 501450c0 1e+10 : 501502f9 8000 : 45fa0000 1.93e+05 : 483c7a00 2.56e+05 : 487a0000 7.89e+05 : 4940a080 1.056e+06 : 4980e800 1.25e+06 : 49989680 4.25 : 40880000 4.6e+07 : 4c2f79e0 5.592e+06 : 4aaaa780 6.48e+06 : 4ac5c100 1.25e+07 : 4b3ebc20 1.741e+07 : 4b84d000 1.944e+07 : 4b9450c0 7.776e+07 : 4c9450c0 1.25e+08 : 4cee6b28 3.11e+08 : 4d9450c0 1.244e+09 : 4e9450c0 1.25e+09 : 4e9502f9 PS: The encoding that I computed for 8000 bytes/sec in my previous message doesn't quite match the above table because of a few silly errors. Please ignore that computation. From owner-mpls@UU.NET Fri Oct 27 12:44:14 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23734 for ; Fri, 27 Oct 2000 12:44:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsw15656; Fri, 27 Oct 2000 16:43:41 GMT Received: by mail-control.mail.uu.net id QQjmsw29927 for mpls-outgoing; Fri, 27 Oct 2000 16:43:18 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmsw29922 for ; Fri, 27 Oct 2000 16:43:09 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmsw15006 for ; Fri, 27 Oct 2000 16:42:41 GMT Received: from rip.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjmsw21792 for ; Fri, 27 Oct 2000 16:42:41 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13pCa9-000Oeq-00; Fri, 27 Oct 2000 09:42:17 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: Vijay Gill , mpls@UU.NET Subject: Re: VPN solution - White flag ? References: <200010271334.JAA28015@erosen-sun.cisco.com> Message-Id: Date: Fri, 27 Oct 2000 09:42:17 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > If one's business were primarily VPN service, one would be a lot more likely > to say "I'm not going to bring full routes to the edge just for the few > customers which want them; those customers are already running EBGP, they > can just run it multi-hop". > > I'm sure someone will respond that there are no SPs who are primarily in the > VPN business and only secondarily in the Internet access business ;-) you're probably right. the vpn-only provider will have to pay for the layer 1/2 circuits and compete in price with those who sell both vpns and ip. so they'll soon sell anything they can to try and survive. randy From owner-mpls@UU.NET Fri Oct 27 13:20:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03713 for ; Fri, 27 Oct 2000 13:20:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsz25079; Fri, 27 Oct 2000 17:20:15 GMT Received: by mail-control.mail.uu.net id QQjmsz13732 for mpls-outgoing; Fri, 27 Oct 2000 17:19:38 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmsz13722 for ; Fri, 27 Oct 2000 17:19:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmsz02126 for ; Fri, 27 Oct 2000 17:19:20 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmsz23584 for ; Fri, 27 Oct 2000 17:19:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA27834 for ; Fri, 27 Oct 2000 10:19:17 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA28883 for mpls@uu.net; Fri, 27 Oct 2000 13:19:18 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmsr12314 for ; Fri, 27 Oct 2000 15:22:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmsr14163 for ; Fri, 27 Oct 2000 15:19:32 GMT Received: from baynet.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.BayNetworks.COM [134.177.3.20]) id QQjmsr21330 for ; Fri, 27 Oct 2000 15:19:31 GMT Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id IAA14770 for ; Fri, 27 Oct 2000 08:17:57 -0700 (PDT) Received: from shasta-exch.shastanets.com (mailserver.shastanets.com [47.82.16.150]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA19249 for ; Fri, 27 Oct 2000 08:17:56 -0700 (PDT) Received: by mailserver.shastanets.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 08:17:18 -0700 Message-ID: <940E42DB5D7FD4119C420004ACE6E0A08101D5@mailserver.shastanets.com> From: Janardan Ramesh To: "'mpls@uu.net'" Cc: shasta-routing Subject: Encoding of MP_REACH_NLRI Date: Fri, 27 Oct 2000 08:17:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk draft-ietf-mpls-bgp4-mpls-04.txt has the following sentence for the NLRI. Length(1), Label (3 - octest 1 or more labels), Prefix (variable) The description of length says: The length field indicates the length in bits of the address prefix plus the label(s). - First interpretation of this is that the label lengths are also encoded in bits. Take the example of 2 labels (48 bits) and a 26 bit prefix. The count will be 74. From the count it is not possible to say whether we have 2 labels (48 bits) and a 26 bit prefix or 3 labels (72 bits) and a 4 bit prefix. - Second interpretation of this is that the length field contains the label counbt and prefix length in bits. Take tha example of 2 labels and a 26 bit prefix. The length field will contain a count of 28. Assuming that there is always 1 label, this can mean that either we have 1 label and a 27 bir prefix or 2 labels and a 26 bit prefix. It would be really helpful to expand the semantics of this field and include a few examples to avoid ambiguity. Regards Ramesh From owner-mpls@UU.NET Fri Oct 27 13:21:18 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03809 for ; Fri, 27 Oct 2000 13:21:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsz11633; Fri, 27 Oct 2000 17:20:32 GMT Received: by mail-control.mail.uu.net id QQjmsz13744 for mpls-outgoing; Fri, 27 Oct 2000 17:19:58 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmsz13736 for ; Fri, 27 Oct 2000 17:19:40 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmsz10525 for ; Fri, 27 Oct 2000 17:19:30 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmsz23769 for ; Fri, 27 Oct 2000 17:19:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA28012 for ; Fri, 27 Oct 2000 10:19:27 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA28887 for mpls@uu.net; Fri, 27 Oct 2000 13:19:28 -0400 (EDT) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmsx00509 for ; Fri, 27 Oct 2000 16:54:11 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmsx11895 for ; Fri, 27 Oct 2000 16:54:08 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjmsx29770 for ; Fri, 27 Oct 2000 16:54:08 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA03522; Fri, 27 Oct 2000 09:54:05 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA28815; Fri, 27 Oct 2000 12:54:06 -0400 (EDT) Message-Id: <200010271654.MAA28815@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Randy Bush cc: Vijay Gill , mpls@UU.NET Subject: Re: VPN solution - White flag ? In-reply-to: Your message of Fri, 27 Oct 2000 09:42:17 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Fri, 27 Oct 2000 12:54:06 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk At this point, I would say there is adequate information in this thread for everyone to form an opinion as to who knows what they're talking about and who doesn't. From owner-mpls@UU.NET Fri Oct 27 13:23:16 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04476 for ; Fri, 27 Oct 2000 13:23:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmsz14434; Fri, 27 Oct 2000 17:22:17 GMT Received: by mail-control.mail.uu.net id QQjmsz13964 for mpls-outgoing; Fri, 27 Oct 2000 17:21:56 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmsz13948 for ; Fri, 27 Oct 2000 17:21:53 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmsz14541 for ; Fri, 27 Oct 2000 17:20:52 GMT Received: from ix.eng.level3.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: machine77.Level3.com [209.244.4.106]) id QQjmsz12219 for ; Fri, 27 Oct 2000 17:20:52 GMT Received: from level3.net (IDENT:luca@localhost [127.0.0.1]) by ix.eng.level3.net (8.9.3/8.9.3) with ESMTP id LAA19909; Fri, 27 Oct 2000 11:20:15 -0600 Message-ID: <39F9B94F.3AB97763@level3.net> Date: Fri, 27 Oct 2000 17:20:15 +0000 From: Luca Martini Organization: Level 3 Communications X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: it,fr-CA,fr-FR,en-US MIME-Version: 1.0 To: robbie.harrell@callisma.com CC: mpls@UU.NET Subject: Re: MPLS over L2 References: <000301c03ce7$36e7b280$4bad98cd@all.callisma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robbie Harrell wrote: > > Luca, I was reading the Internet draft "Transport of Layer 2 frames over > MPLS" and had the following questions. Using the example given with R1 an > R2, does the ingress L2 protocol and the egress L2 protocol have to be the > same. For instance can I bring in a L2 ATM cell over ATM at R1, transport > over my MPLS tunnel and deliver over an Ethernet egress interface at R2. Yes, they have to be the same. THere is a statement made about not doing internetworking in this implementation. > This doesn't seem possible to me unless the router reads the L3 information > and makes a routing decision on the L3 information irregardless of the L2 > encapsulation. I am working on a project to build a next generation NAP and > this would be an ideal scenario for one to many peering connections with > multiple ingress encapsulations. We are trying to eliminate the > intermediate routers found in the NAP so that peers are from ISP router to > ISP router (like R1 and R2 in the document). My major concern is whether or > not this works for a provider who connects on the ingress with say an ATM > pipe and wants to peer with other providers who may have Frame-Relay, > Ethernet, or ATM. There would be multiple peering sessions over MPLS > tunnels. It would have to come into the MPLS cloud under one L2 > encapsulation and leave under another. I am assuming the router would have > to be involved to assume protocol translations at the egress edge. Any > thoughts, hints or clarifications. > It could be possible to actually do the internetworking function in the end router device. In this case the traffic would transit the network in native mode. If it came in ATM AAL5, the PDUs would be transported unchanged to the egress router , where they would be converted to a different protocol. This could be a vendor specific feature, and does not have to be done "in the network". In this case the end router doing the conversion has all the information it could possibly need to do internetworking successfully. Luca Martini > Robbie Harrell > Senior Consultant > Callisma > 866-543-5737 pager > 8772079316@skytel.com -- Just say no to summer. Ski all year ! Luca Martini Senior Network Architect, Level 3 Communications - Broomfield, CO luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager page-luca@level3.net From owner-mpls@UU.NET Fri Oct 27 22:31:36 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01569 for ; Fri, 27 Oct 2000 22:31:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmuk22039; Sat, 28 Oct 2000 02:31:06 GMT Received: by mail-control.mail.uu.net id QQjmuk02557 for mpls-outgoing; Sat, 28 Oct 2000 02:30:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmuk02390 for ; Sat, 28 Oct 2000 02:30:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmtd04346 for ; Fri, 27 Oct 2000 18:29:31 GMT Received: from postal.redback.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: postal.redback.com [155.53.12.9]) id QQjmtd07853 for ; Fri, 27 Oct 2000 18:29:30 GMT Received: from tradrat.redback.com (tradrat.redback.com [155.53.36.49]) by postal.redback.com (Postfix) with ESMTP id CF4A417BC14; Fri, 27 Oct 2000 11:29:29 -0700 (PDT) Received: (from tor@localhost) by tradrat.redback.com (8.8.8/8.8.8/null redback bsdclient) id LAA19277; Fri, 27 Oct 2000 11:29:29 -0700 (PDT) Date: Fri, 27 Oct 2000 11:29:29 -0700 From: Rene Tio To: Randy Bush Cc: Eric Osborne , mpls@UU.NET Subject: Re: VPN solution - White flag ? Message-ID: <20001027112929.D19169@redback.com> References: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> <20001026231304.A25090@che-cse-115.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from randy@psg.com on Thu, Oct 26, 2000 at 11:15:56PM -0700 Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Oct 26, 2000 at 11:15:56PM -0700, Randy Bush wrote: > > If the customer usees IPSec, they they have to manage the VPN themselves, > > bzzzt! next contestant. Speaking as an impartial third party, I have to say that given your requirement for zero router growth you're expecting customers to manage the routers themselves. Otherwise what's the difference between buying PE routers and passing the cost to the customer or buying CE [IPsec] routers and passing the cost to the customer? From owner-mpls@UU.NET Fri Oct 27 22:31:53 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01775 for ; Fri, 27 Oct 2000 22:31:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmuk22844; Sat, 28 Oct 2000 02:31:31 GMT Received: by mail-control.mail.uu.net id QQjmuk02673 for mpls-outgoing; Sat, 28 Oct 2000 02:30:53 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmuk02641 for ; Sat, 28 Oct 2000 02:30:40 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmta16145 for ; Fri, 27 Oct 2000 17:35:02 GMT Received: from rip.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjmta01243 for ; Fri, 27 Oct 2000 17:35:01 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13pDP1-000P7G-00; Fri, 27 Oct 2000 10:34:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yakov Rekhter Cc: Eric Gray , mpls@UU.NET Subject: Re: VPN solution - White flag ? References: <200010271623.JAA13422@omega.cisco.com> Message-Id: Date: Fri, 27 Oct 2000 10:34:51 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > All I can say that the usefulness of various alternatives is unlikely > to be determined by the debates on this list, but is likely to be > determined by the competition on the marketplace. With this in mind, > what exactly are you trying to accomplish by continuing this debate ? the ever-dauntful task of getting operational input into the vendor driven steam-roller. randy From owner-mpls@UU.NET Fri Oct 27 22:32:45 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02238 for ; Fri, 27 Oct 2000 22:32:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmuk24480; Sat, 28 Oct 2000 02:32:31 GMT Received: by mail-control.mail.uu.net id QQjmuk02721 for mpls-outgoing; Sat, 28 Oct 2000 02:31:01 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmuk02654 for ; Sat, 28 Oct 2000 02:30:44 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmtg08331 for ; Fri, 27 Oct 2000 19:03:15 GMT Received: from rip.psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjmtg14833 for ; Fri, 27 Oct 2000 19:03:14 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13pEmX-000Pt0-00; Fri, 27 Oct 2000 12:03:13 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rene Tio Cc: Eric Osborne , mpls@UU.NET Subject: Re: VPN solution - White flag ? References: <4611AD058694D4118FD5009027B0A6625D8BB1@ICARIAN> <20001026231304.A25090@che-cse-115.cisco.com> <20001027112929.D19169@redback.com> Message-Id: Date: Fri, 27 Oct 2000 12:03:13 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Speaking as an impartial third party, I have to say that given your > requirement for zero router growth zero would be nice. very small would be reasonable. > you're expecting customers to manage the routers themselves. nope. we're selling a managed service, whether it's at the cpe or in aggregation. > Otherwise what's the difference between buying PE routers and passing the > cost to the customer or buying CE [IPsec] routers and passing the cost to > the customer? there seems to be some confusion. for cpe-based ipsec, the customer's normal single router does not need to be replecated. randy From owner-mpls@UU.NET Fri Oct 27 22:32:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02305 for ; Fri, 27 Oct 2000 22:32:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmuk29574; Sat, 28 Oct 2000 02:32:40 GMT Received: by mail-control.mail.uu.net id QQjmuk02943 for mpls-outgoing; Sat, 28 Oct 2000 02:32:05 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmuk02784 for ; Sat, 28 Oct 2000 02:31:14 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmtd10088 for ; Fri, 27 Oct 2000 18:25:41 GMT Received: from smtprch1.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjmtd02647 for ; Fri, 27 Oct 2000 18:25:40 GMT Received: from zcard00n.ca.nortel.com by smtprch1.nortel.com; Fri, 27 Oct 2000 12:56:43 -0500 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VWQNXDXP; Fri, 27 Oct 2000 13:56:36 -0400 Received: from nortelnetworks.com (H9704002 [47.129.10.146]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VNHG1NQZ; Fri, 27 Oct 2000 13:56:33 -0400 Message-ID: <39F9C1D9.CAF9EC28@nortelnetworks.com> Date: Fri, 27 Oct 2000 13:56:41 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Hamid Ould-Brahim" X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Luca Martini CC: robbie.harrell@callisma.com, mpls@UU.NET Subject: Re: MPLS over L2 References: <000301c03ce7$36e7b280$4bad98cd@all.callisma.com> <39F9B94F.3AB97763@level3.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Maybe another approach to support this particular case is to use a generic layer 2 encapsulation over MPLS (sort of "GRE" principles for layer-2 over MPLS - something like "GLE": generic layer 2 ensapsulartion over MPLS-). Therefore the end router will translate from one layer-2 to the other (no need for interworking). In reality the translation can happen anywhere in the network. Assume you have a FR layer-2 carried over MPLS, and you want the egress point to be ATM. Then you can negotiate up front how you want to do this translation (between the source and exit point). as if you have a frame relay over atm interworking interfaces (of course in this case you don't need anymore interworking interfaces). Hamid Luca Martini wrote: > > > It could be possible to actually do the internetworking function in the > end router device. > In this case the traffic would transit the network in native mode. If it > came in ATM AAL5, > the PDUs would be transported unchanged to the egress router , where > they would be converted to a different protocol. This could be a vendor > specific feature, and does not have to be done "in the network". > In this case the end router doing the conversion has all the information > it could possibly need to do internetworking successfully. > > Luca Martini > > > Robbie Harrell > > Senior Consultant > > Callisma > > 866-543-5737 pager > > 8772079316@skytel.com > > -- > Just say no to summer. Ski all year ! > Luca Martini Senior Network Architect, Level 3 Communications - > Broomfield, CO > luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager > page-luca@level3.net From owner-mpls@UU.NET Fri Oct 27 22:33:48 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02582 for ; Fri, 27 Oct 2000 22:33:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmuk00932; Sat, 28 Oct 2000 02:33:30 GMT Received: by mail-control.mail.uu.net id QQjmuk02971 for mpls-outgoing; Sat, 28 Oct 2000 02:32:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmuk02849 for ; Sat, 28 Oct 2000 02:31:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjmue18155 for ; Sat, 28 Oct 2000 01:10:06 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f305.law11.hotmail.com [64.4.16.180]) id QQjmue18140 for ; Sat, 28 Oct 2000 01:10:06 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 27 Oct 2000 18:10:05 -0700 Received: from 155.53.32.18 by lw11fd.law11.hotmail.msn.com with HTTP; Sat, 28 Oct 2000 01:10:05 GMT X-Originating-IP: [155.53.32.18] From: "Raj Jakkampudi" To: vijay@umbc.edu, mpls@UU.NET Subject: Re: VPN solution - White flag ? Date: Sat, 28 Oct 2000 01:10:05 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Oct 2000 01:10:05.0407 (UTC) FILETIME=[CE622EF0:01C0407B] Sender: owner-mpls@UU.NET Precedence: bulk Hi Vijay, I'm somewhat leary about entering into this debate but ... At the one promising ISP that both of us worked at, not all routers carried the full Internet routing table (or all edges aren't the same). In particular, the routers servicing the dial access and the DSL networks did not carry the full routing table. I would also say that there were other specialized routers in the network e.g. the peering routers, the dedicated customer routers, and the multicast routers. It does not seem inconceivable to me that they would not have used specialized routers to provide VPN solutions especially if the solutions were needed to scale or had special business requiremnets (e.g. management or troubleshooting). In fact with that type of solution the scaling of the VPN network could be independant of the scaling of the rest of the network. thanks, /Raj >From: Vijay Gill >To: mpls@UU.NET >Subject: Re: VPN solution - White flag ? >Date: Thu, 26 Oct 2000 14:04:04 -0400 > > >[ folks, it doesn't hurt to trim headers ] > >On Thu, 26 Oct 2000, Eric Rosen wrote: > > > Randy> if an enterprise wanting to deploy it is not an isp, then they'll > > Randy> need their own layer 1 or2 connectivity between all endpoints. > > > > Just to be clear, you are saying that, to the best of your knowledge, >all > > networks fall into one of the following two categories: > > > > 1. needs to carry all Internet routes to every edge > >Having worked at one or two promising local ISPs, I assure you that the >plan of deploying two routers where one will do (and where one is just to >aggregate VPN customers) is something that will not fly very well. > >This of course leads to a realistic scenario where you have the minimum >number of routers necessary to satisfy the business need at the edge and >since a couple of customers insist on having full routes, well.... > >I suspect this is where Randy is coming from. Given that routers _barely_ >work as it is, we'd much rather wish this additional problem onto someone >else than have it sit in the ISP core, where routers crashing lead to SLA >violations and asosciated pain. > > > 2. needs complete mesh of layer 2 connections between all endpoints. > > > > I had no idea that all networks fell into one of these two >categories! I > > don't know how I missed that ;-) > >Just most _realistic_ ISP networks fall into case 1. > >/vijay > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Fri Oct 27 22:34:10 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02705 for ; Fri, 27 Oct 2000 22:34:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmuk11607; Sat, 28 Oct 2000 02:33:45 GMT Received: by mail-control.mail.uu.net id QQjmuk03080 for mpls-outgoing; Sat, 28 Oct 2000 02:33:23 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjmuk03011 for ; Sat, 28 Oct 2000 02:32:50 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmtc04850; Fri, 27 Oct 2000 18:09:55 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe16.law10.hotmail.com [64.4.14.120]) id QQjmtc02456; Fri, 27 Oct 2000 18:09:55 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 27 Oct 2000 11:09:54 -0700 X-Originating-IP: [12.124.181.202] From: "Frank Hujber" To: "Mark Stewart" , "David Allan" Cc: "alchiu" , "'Yakov Rekhter'" , "ip-optical" , "mpls" , "sc" , "xuyg" , "yxue" References: <6DDA62170439D31185750000F80826AC0430FAED@zmerd004.ca.nortel.com> <39F9A260.33EB31C3@nexen.com> Subject: Re: [IP-Optical] Joint Routing Date: Fri, 27 Oct 2000 14:11:15 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C0401F.C49ED000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: X-OriginalArrivalTime: 27 Oct 2000 18:09:54.0246 (UTC) FILETIME=[1B5C4E60:01C04041] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C0401F.C49ED000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dave, Mark, et al, I've been watching this one for a while and I cannot let it go by = without offering my viewpoint. Which is... There ought to be a compromise between the distributed approach and the = centralized approach whereby the ingress (or maybe the egress) router = has a picture of the topology and from that makes the explicit route. A = distributed approach will not assure diverse paths and will force the = computation to be delayed until the fault has occurred and some fault = analysis algorithm takes some time to specify which link or node to = avoid. A fully centralized approach clearly has scaling problems. I = agree, keeping the topology picture uniform will be a challenge. If it = wasn't it would've been done already. However, consider that the amount = of time that a lightpath is likely to exist may be longer than the = average datagram. The time constant associated with router updates may = be longer as well, so this eases the burden a bit when it comes to = updating the topology picture (i.e. the optical link state.) I've seen hints of this compromise passing by over the past few days, = but somehow I think it keeps getting lost in the definitions of = "centralized" and "distributed." It just doesn't seem to me like a = three-sigma answer is the right one. Frank Hujber fhujber@hotmail.com ------=_NextPart_000_001E_01C0401F.C49ED000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =FF=FE<=00!=00D=00O=00C=00T=00Y=00P=00E=00 =00H=00T=00M=00L=00 = =00P=00U=00B=00L=00I=00C=00 = =00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 = =004=00.=000=00 = =00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00= =0D=00=0A= =00<=00H=00T=00M=00L=00>=00<=00H=00E=00A=00D=00>=00=0D=00=0A= =00<=00M=00E=00T=00A=00 = =00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00t=00e=00x=00t=00/=00h=00t=00m=00= l=00;=00 = =00c=00h=00a=00r=00s=00e=00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00 = =00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00t=00e=00n=00= t=00-=00T=00y=00p=00e=00>=00=0D=00=0A= =00<=00M=00E=00T=00A=00 = =00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 = =005=00.=000=000=00.=002=003=001=004=00.=001=000=000=000=00"=00 = =00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00=0D=00=0A= =00<=00S=00T=00Y=00L=00E=00>=00<=00/=00S=00T=00Y=00L=00E=00>=00=0D=00=0A= =00<=00/=00H=00E=00A=00D=00>=00=0D=00=0A= =00<=00B=00O=00D=00Y=00 = =00b=00g=00C=00o=00l=00o=00r=00=3D=00#=00f=00f=00f=00f=00f=00f=00>=00=0D=00=0A= =00<=00D=00I=00V=00>=00<=00F=00O=00N=00T=00 = =00f=00a=00c=00e=00=3D=00A=00r=00i=00a=00l=00 = =00s=00i=00z=00e=00=3D=002=00>=00D=00a=00v=00e=00,=00 = =00M=00a=00r=00k=00,=00 =00e=00t=00 = =00a=00l=00,=00<=00/=00F=00O=00N=00T=00>=00<=00/=00D=00I=00V=00>=00=0D=00=0A= =00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D= =00=0A= =00<=00D=00I=00V=00>=00<=00F=00O=00N=00T=00 = =00f=00a=00c=00e=00=3D=00A=00r=00i=00a=00l=00 = =00s=00i=00z=00e=00=3D=002=00>=00I=00'=00v=00e=00 =00b=00e=00e=00n=00 = =00w=00a=00t=00c=00h=00i=00n=00g=00 =00t=00h=00i=00s=00 =00o=00n=00e=00 = =00f=00o=00r=00 =00a=00 =00w=00h=00i=00l=00e=00 =00a=00n=00d=00 =00I=00 = =00=0D=00=0A= =00c=00a=00n=00n=00o=00t=00 =00l=00e=00t=00 =00i=00t=00 =00g=00o=00 = =00b=00y=00 =00w=00i=00t=00h=00o=00u=00t=00 = =00o=00f=00f=00e=00r=00i=00n=00g=00 =00m=00y=00 = =00v=00i=00e=00w=00p=00o=00i=00n=00t=00.=00 =00W=00h=00i=00c=00h=00 = =00i=00s=00.=00.=00.=00<=00/=00F=00O=00N=00T=00>=00<=00/=00D=00I=00V=00>=00= =0D=00=0A= =00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D= =00=0A= =00<=00D=00I=00V=00>=00<=00F=00O=00N=00T=00 = =00f=00a=00c=00e=00=3D=00A=00r=00i=00a=00l=00 = =00s=00i=00z=00e=00=3D=002=00>=00T=00h=00e=00r=00e=00 = =00o=00u=00g=00h=00t=00 =00t=00o=00 =00b=00e=00 =00a=00 = =00c=00o=00m=00p=00r=00o=00m=00i=00s=00e=00 = =00b=00e=00t=00w=00e=00e=00n=00 =00t=00h=00e=00 =00=0D=00=0A= =00d=00i=00s=00t=00r=00i=00b=00u=00t=00e=00d=00 = =00a=00p=00p=00r=00o=00a=00c=00h=00 =00a=00n=00d=00 =00t=00h=00e=00 = =00c=00e=00n=00t=00r=00a=00l=00i=00z=00e=00d=00 = =00a=00p=00p=00r=00o=00a=00c=00h=00 =00w=00h=00e=00r=00e=00b=00y=00 = =00t=00h=00e=00 =00i=00n=00g=00r=00e=00s=00s=00 =00(=00o=00r=00 = =00m=00a=00y=00b=00e=00 =00=0D=00=0A= =00t=00h=00e=00 =00e=00g=00r=00e=00s=00s=00)=00 = =00r=00o=00u=00t=00e=00r=00 =00h=00a=00s=00 =00a=00 = =00p=00i=00c=00t=00u=00r=00e=00 =00o=00f=00 =00t=00h=00e=00 = =00t=00o=00p=00o=00l=00o=00g=00y=00 =00a=00n=00d=00 =00f=00r=00o=00m=00 = =00t=00h=00a=00t=00 =00m=00a=00k=00e=00s=00 =00t=00h=00e=00 =00=0D=00=0A= =00e=00x=00p=00l=00i=00c=00i=00t=00 =00r=00o=00u=00t=00e=00.=00 =00A=00 = =00d=00i=00s=00t=00r=00i=00b=00u=00t=00e=00d=00 = =00a=00p=00p=00r=00o=00a=00c=00h=00 =00w=00i=00l=00l=00 =00n=00o=00t=00 = =00a=00s=00s=00u=00r=00e=00 =00d=00i=00v=00e=00r=00s=00e=00 = =00p=00a=00t=00h=00s=00 =00a=00n=00d=00 =00w=00i=00l=00l=00 =00=0D=00=0A= =00f=00o=00r=00c=00e=00 =00t=00h=00e=00 = =00c=00o=00m=00p=00u=00t=00a=00t=00i=00o=00n=00 =00t=00o=00 =00b=00e=00 = =00d=00e=00l=00a=00y=00e=00d=00 =00u=00n=00t=00i=00l=00 =00t=00h=00e=00 = =00f=00a=00u=00l=00t=00 =00h=00a=00s=00 = =00o=00c=00c=00u=00r=00r=00e=00d=00 =00a=00n=00d=00 =00s=00o=00m=00e=00 = =00f=00a=00u=00l=00t=00 =00=0D=00=0A= =00a=00n=00a=00l=00y=00s=00i=00s=00 = =00a=00l=00g=00o=00r=00i=00t=00h=00m=00 =00t=00a=00k=00e=00s=00 = =00s=00o=00m=00e=00 =00t=00i=00m=00e=00 =00t=00o=00 = =00s=00p=00e=00c=00i=00f=00y=00 =00w=00h=00i=00c=00h=00 = =00l=00i=00n=00k=00 =00o=00r=00 =00n=00o=00d=00e=00 =00t=00o=00 = =00a=00v=00o=00i=00d=00.=00 =00A=00 =00=0D=00=0A= =00f=00u=00l=00l=00y=00 =00c=00e=00n=00t=00r=00a=00l=00i=00z=00e=00d=00 = =00a=00p=00p=00r=00o=00a=00c=00h=00 =00c=00l=00e=00a=00r=00l=00y=00 = =00h=00a=00s=00 =00s=00c=00a=00l=00i=00n=00g=00 = =00p=00r=00o=00b=00l=00e=00m=00s=00.=00 =00I=00 = =00a=00g=00r=00e=00e=00,=00 =00k=00e=00e=00p=00i=00n=00g=00 = =00t=00h=00e=00 =00=0D=00=0A= =00t=00o=00p=00o=00l=00o=00g=00y=00 =00p=00i=00c=00t=00u=00r=00e=00 = =00u=00n=00i=00f=00o=00r=00m=00 =00w=00i=00l=00l=00 =00b=00e=00 =00a=00 = =00c=00h=00a=00l=00l=00e=00n=00g=00e=00.=00 =00I=00f=00 =00i=00t=00 = =00w=00a=00s=00n=00'=00t=00 =00i=00t=00 = =00w=00o=00u=00l=00d=00'=00v=00e=00 =00b=00e=00e=00n=00 = =00d=00o=00n=00e=00 =00=0D=00=0A= =00a=00l=00r=00e=00a=00d=00y=00.=00 =00H=00o=00w=00e=00v=00e=00r=00,=00 = =00c=00o=00n=00s=00i=00d=00e=00r=00 =00t=00h=00a=00t=00 =00t=00h=00e=00 = =00a=00m=00o=00u=00n=00t=00 =00o=00f=00 =00t=00i=00m=00e=00 = =00t=00h=00a=00t=00 =00a=00 =00l=00i=00g=00h=00t=00p=00a=00t=00h=00 = =00i=00s=00 =00l=00i=00k=00e=00l=00y=00 =00t=00o=00 =00=0D=00=0A= =00e=00x=00i=00s=00t=00 =00m=00a=00y=00 =00b=00e=00 = =00l=00o=00n=00g=00e=00r=00 =00t=00h=00a=00n=00 =00t=00h=00e=00 = =00a=00v=00e=00r=00a=00g=00e=00 =00d=00a=00t=00a=00g=00r=00a=00m=00.=00 = =00T=00h=00e=00 =00t=00i=00m=00e=00 =00c=00o=00n=00s=00t=00a=00n=00t=00 = =00a=00s=00s=00o=00c=00i=00a=00t=00e=00d=00 =00w=00i=00t=00h=00 =00=0D=00=0A= =00r=00o=00u=00t=00e=00r=00 =00u=00p=00d=00a=00t=00e=00s=00 = =00m=00a=00y=00 =00b=00e=00 =00l=00o=00n=00g=00e=00r=00 =00a=00s=00 = =00w=00e=00l=00l=00,=00 =00s=00o=00 =00t=00h=00i=00s=00 = =00e=00a=00s=00e=00s=00 =00t=00h=00e=00 =00b=00u=00r=00d=00e=00n=00 = =00a=00 =00b=00i=00t=00 =00w=00h=00e=00n=00 =00i=00t=00 =00=0D=00=0A= =00c=00o=00m=00e=00s=00 =00t=00o=00 =00u=00p=00d=00a=00t=00i=00n=00g=00 = =00t=00h=00e=00 =00t=00o=00p=00o=00l=00o=00g=00y=00 = =00p=00i=00c=00t=00u=00r=00e=00 =00(=00i=00.=00e=00.=00 = =00t=00h=00e=00&=00n=00b=00s=00p=00;=00o=00p=00t=00i=00c=00a=00l=00 = =00l=00i=00n=00k=00 =00=0D=00=0A= =00s=00t=00a=00t=00e=00.=00)=00<=00/=00F=00O=00N=00T=00>=00<=00/=00D=00I=00= V=00>=00=0D=00=0A= =00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D= =00=0A= =00<=00D=00I=00V=00>=00<=00F=00O=00N=00T=00 = =00f=00a=00c=00e=00=3D=00A=00r=00i=00a=00l=00 = =00s=00i=00z=00e=00=3D=002=00>=00I=00'=00v=00e=00 =00s=00e=00e=00n=00 = =00h=00i=00n=00t=00s=00 =00o=00f=00 =00t=00h=00i=00s=00 = =00c=00o=00m=00p=00r=00o=00m=00i=00s=00e=00 = =00p=00a=00s=00s=00i=00n=00g=00 =00b=00y=00 =00o=00v=00e=00r=00 =00=0D=00=0A= =00t=00h=00e=00 =00p=00a=00s=00t=00 =00f=00e=00w=00 = =00d=00a=00y=00s=00,=00 =00b=00u=00t=00 =00s=00o=00m=00e=00h=00o=00w=00 = =00I=00 =00t=00h=00i=00n=00k=00 =00i=00t=00 =00k=00e=00e=00p=00s=00 = =00g=00e=00t=00t=00i=00n=00g=00 =00l=00o=00s=00t=00 =00i=00n=00 = =00t=00h=00e=00 =00d=00e=00f=00i=00n=00i=00t=00i=00o=00n=00s=00 =00=0D=00=0A= =00o=00f=00 =00"=00c=00e=00n=00t=00r=00a=00l=00i=00z=00e=00d=00"=00 = =00a=00n=00d=00 = =00"=00d=00i=00s=00t=00r=00i=00b=00u=00t=00e=00d=00.=00"=00 =00I=00t=00 = =00j=00u=00s=00t=00 =00d=00o=00e=00s=00n=00'=00t=00 =00s=00e=00e=00m=00 = =00t=00o=00 =00m=00e=00 =00l=00i=00k=00e=00 =00a=00 =00=0D=00=0A= =00t=00h=00r=00e=00e=00-=00s=00i=00g=00m=00a=00 = =00a=00n=00s=00w=00e=00r=00 =00i=00s=00 =00t=00h=00e=00 = =00r=00i=00g=00h=00t=00 = =00o=00n=00e=00.=00<=00/=00F=00O=00N=00T=00>=00<=00/=00D=00I=00V=00>=00=0D= =00=0A= =00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D= =00=0A= =00<=00D=00I=00V=00>=00<=00F=00O=00N=00T=00 = =00f=00a=00c=00e=00=3D=00A=00r=00i=00a=00l=00 = =00s=00i=00z=00e=00=3D=002=00>=00F=00r=00a=00n=00k=00 = =00H=00u=00j=00b=00e=00r=00<=00/=00F=00O=00N=00T=00>=00<=00/=00D=00I=00V=00= >=00=0D=00=0A= =00<=00D=00I=00V=00>=00<=00F=00O=00N=00T=00 = =00f=00a=00c=00e=00=3D=00A=00r=00i=00a=00l=00 = =00s=00i=00z=00e=00=3D=002=00>=00<=00A=00 =00=0D=00=0A= =00h=00r=00e=00f=00=3D=00"=00m=00a=00i=00l=00t=00o=00:=00f=00h=00u=00j=00= b=00e=00r=00@=00h=00o=00t=00m=00a=00i=00l=00.=00c=00o=00m=00"=00>=00f=00h= =00u=00j=00b=00e=00r=00@=00h=00o=00t=00m=00a=00i=00l=00.=00c=00o=00m=00<=00= /=00A=00>=00<=00/=00F=00O=00N=00T=00>=00<=00/=00D=00I=00V=00>=00<=00/=00B= =00O=00D=00Y=00>=00<=00/=00H=00T=00M=00L=00>=00=0D=00=0A= =00 ------=_NextPart_000_001E_01C0401F.C49ED000-- From owner-mpls@UU.NET Sat Oct 28 10:04:41 2000 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27519 for ; Sat, 28 Oct 2000 10:04:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmwe28631; Sat, 28 Oct 2000 14:00:31 GMT Received: by mail-control.mail.uu.net id QQjmwe18169 for mpls-outgoing; Sat, 28 Oct 2000 14:00:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjmwe17894 for ; Sat, 28 Oct 2000 14:00:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmwd07023 for ; Sat, 28 Oct 2000 13:59:53 GMT Received: from janus.cypress.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: janus.cypress.com [157.95.1.1]) id QQjmwd27696 for ; Sat, 28 Oct 2000 13:59:53 GMT Received: from cobweb.mis.cypress.com (cobweb.mis.cypress.com [172.16.2.5]) by janus.cypress.com (8.9.1a/8.9.1) with ESMTP id GAA26061; Sat, 28 Oct 2000 06:59:52 -0700 (PDT) Received: from cypress.com ([157.95.237.156]) by cobweb.mis.cypress.com (8.8.8/8.8.8) with ESMTP id HAA24687; Sat, 28 Oct 2000 07:00:27 -0700 (PDT) Message-ID: <39FADBFC.79FE2001@cypress.com> Date: Sat, 28 Oct 2000 07:00:28 -0700 From: Pankaj K Jha Organization: Cypress Semiconductor Corp. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hamid Ould-Brahim CC: mpls@UU.NET Subject: Re: MPLS over L2 References: <000301c03ce7$36e7b280$4bad98cd@all.callisma.com> <39F9B94F.3AB97763@level3.net> <39F9C1D9.CAF9EC28@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit We are finalizing a draft that does just this (and more) - provides a way, for instance, for ATM to be sent over non-ATM MPLS links (e.g. with frame relay) and reach a destination node without intermediate translations. This would be true for any layer 2 packet transport over any other layer 2 n/w using MPLS, providing a multiservice transport with end-to-end native packets. Multiservice also allows multiple types of native packets from one or more nodes to share a single LSP (for common bandwidth sharing) and in general transport of different types of native packets over a single link, over same or different LSPs. -Pankaj Hamid Ould-Brahim wrote: > Maybe another approach to support this particular case is to use a > generic layer 2 encapsulation over MPLS (sort of "GRE" principles > for layer-2 over MPLS - something like "GLE": generic > layer 2 ensapsulartion over MPLS-). Therefore the end router will > translate from one layer-2 to the other (no need for > interworking). In reality the translation can happen > anywhere in the network. > > Assume you have a FR layer-2 carried over MPLS, and > you want the egress point to be ATM. Then you can negotiate up front > how you want to do this translation (between the source and exit point). > as if you have a frame relay over atm interworking interfaces > (of course in this case you don't need anymore > interworking interfaces). > > Hamid > > Luca Martini wrote: > > > > > > It could be possible to actually do the internetworking function in the > > end router device. > > In this case the traffic would transit the network in native mode. If it > > came in ATM AAL5, > > the PDUs would be transported unchanged to the egress router , where > > they would be converted to a different protocol. This could be a vendor > > specific feature, and does not have to be done "in the network". > > In this case the end router doing the conversion has all the information > > it could possibly need to do internetworking successfully. > > > > Luca Martini > > > > > Robbie Harrell > > > Senior Consultant > > > Callisma > > > 866-543-5737 pager > > > 8772079316@skytel.com > > > > -- > > Just say no to summer. Ski all year ! > > Luca Martini Senior Network Architect, Level 3 Communications - > > Broomfield, CO > > luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager > > page-luca@level3.net From owner-mpls@UU.NET Sun Oct 29 03:36:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10416 for ; Sun, 29 Oct 2000 03:36:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmza15709; Sun, 29 Oct 2000 08:34:55 GMT Received: by mail-control.mail.uu.net id QQjmza00311 for mpls-outgoing; Sun, 29 Oct 2000 08:34:38 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjmza00306 for ; Sun, 29 Oct 2000 08:34:25 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmza22269 for ; Sun, 29 Oct 2000 08:34:24 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjmza24575 for ; Sun, 29 Oct 2000 08:34:24 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Sun, 29 Oct 2000 08:33:37 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id <4C8F8YJ9>; Sun, 29 Oct 2000 08:33:23 -0000 Message-ID: To: randy@psg.com, tor@redback.com Cc: eric@cisco.com, mpls@UU.NET Subject: RE: VPN solution - White flag ? Date: Sun, 29 Oct 2000 08:33:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > you're expecting customers to manage the routers themselves. > > nope. we're selling a managed service, whether it's at the cpe or in > aggregation. Randy....given my previous mail......ie I am still unclear on what QoS/availability SLAs MPLS and IPSec based VPNs will provide, since I don't fully understand the likely outage behaviour for various defects.......have you therefore got these nailed down for IPSec? And are there any objective/metric relationships in acccess/national_core/international portions of some global reference network? thanks, neil From owner-mpls@UU.NET Sun Oct 29 03:37:25 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11144 for ; Sun, 29 Oct 2000 03:37:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmza26795; Sun, 29 Oct 2000 08:36:09 GMT Received: by mail-control.mail.uu.net id QQjmza00346 for mpls-outgoing; Sun, 29 Oct 2000 08:35:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmza00338 for ; Sun, 29 Oct 2000 08:35:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjmza25980 for ; Sun, 29 Oct 2000 08:34:10 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjmza13329 for ; Sun, 29 Oct 2000 08:34:10 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Sun, 29 Oct 2000 08:34:57 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id <41BNHQCL>; Sun, 29 Oct 2000 08:33:32 -0000 Message-ID: To: yakov@cisco.com, randy@psg.com Cc: egray@zaffire.com, mpls@UU.NET Subject: RE: VPN solution - White flag ? Date: Sun, 29 Oct 2000 08:33:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > All I can say that the usefulness of various alternatives is unlikely > to be determined by the debates on this list, but is likely to be > determined by the competition on the marketplace. With this in mind, > what exactly are you trying to accomplish by continuing this debate ? > > Yakov. > NH=> I agree. My/BT take here is that we need L1, L2, MPLS and IPSec solutions in our VPN portfolio. So they are not mutually exclusive and one is not 'right' over the other....depends on customer and application. If an operator chooses not to deploy all types then that is OK, but then it is up to the operator/customer to decide if the customer requirements can be met with whatever VPN technology is being used...so, in addition to functionality, clarity on QoS and availability performance seems essential (I have not fully understood this yet for latter 2). neil From owner-mpls@UU.NET Sun Oct 29 04:51:44 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15486 for ; Sun, 29 Oct 2000 04:51:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjmzf28807; Sun, 29 Oct 2000 09:51:02 GMT Received: by mail-control.mail.uu.net id QQjmzf15977 for mpls-outgoing; Sun, 29 Oct 2000 09:50:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjmzf15972 for ; Sun, 29 Oct 2000 09:50:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjmzf14818 for ; Sun, 29 Oct 2000 09:48:50 GMT Received: from rip.psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjmzf25958 for ; Sun, 29 Oct 2000 09:48:50 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 13pp50-000Ip0-00; Sun, 29 Oct 2000 01:48:42 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: neil.2.harrison@bt.com Cc: mpls@UU.NET Subject: RE: VPN solution - White flag ? References: Message-Id: Date: Sun, 29 Oct 2000 01:48:42 -0800 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I am still unclear on what QoS/availability SLAs MPLS and IPSec based VPNs > will provide it is probably best to wander over to the nbvpn list. From owner-mpls@UU.NET Mon Oct 30 17:45:18 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27249 for ; Mon, 30 Oct 2000 17:45:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnew27107; Mon, 30 Oct 2000 22:42:57 GMT Received: by mail-control.mail.uu.net id QQjnew12445 for mpls-outgoing; Mon, 30 Oct 2000 22:42:36 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnew12434 for ; Mon, 30 Oct 2000 22:42:28 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnew14568 for ; Mon, 30 Oct 2000 22:41:38 GMT Received: from smtprch1.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjnew25153 for ; Mon, 30 Oct 2000 22:41:37 GMT Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Mon, 30 Oct 2000 14:23:15 -0600 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VTYQBPWJ; Mon, 30 Oct 2000 15:23:08 -0500 Received: from nortelnetworks.com (H9704002 [47.152.7.214]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VNHG1RCD; Mon, 30 Oct 2000 15:23:07 -0500 Message-ID: <39FDD8AF.EAA4B902@nortelnetworks.com> Date: Mon, 30 Oct 2000 15:23:11 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Hamid Ould-Brahim" X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Karthik Muthukrishnan CC: "Morgan, Richard" , "Hamid Ould-Brahim" , Paul Tasillo , nbvpn@bbo.com, mpls@UU.NET Subject: Re: FW: VPN solution - White flag ? References: <39F8524C.F5C3BD0D@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Richard, When deployed over an MPLS infrastructure the VR model can use a two label approach to forward vpn packets transparently over the service provider network. Depending on the MPLS deployment scenario, the inner label can be bound to the VR or to the vpn prefix within the VR context. In the latter case, the VR is responsible to distribute the vpn labels attached to the private reachability information. Each VR may or may not run MPLS. Both schemes can also be used. As an example, the per vpn label distribution can be tunneled (with MPLS or not), where the inner label is bound to the VR. Once it is distributed to each VPN, the data path will just use the two labels, one for the vpn prefix (attached in VR context), and the top label within the PE (or backbone VR). Because each VR is independent from the others, some VRs may be running MPLS, some may use IPSec, etc. Regards Hamid > > "Morgan, Richard" wrote: > > > > Does the Virtual Router soluntion take advantage of the 'hierrachy of > > routing knowledge' ie use two labels, one to get the PE and another to > > identify the VR - or does it create individual LSP's between each other VR's > > and not use the label stack ? > > > > Richard Morgan > > From owner-mpls@UU.NET Mon Oct 30 20:48:24 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20742 for ; Mon, 30 Oct 2000 20:48:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnfj19718; Tue, 31 Oct 2000 01:47:44 GMT Received: by mail-control.mail.uu.net id QQjnfj28092 for mpls-outgoing; Tue, 31 Oct 2000 01:47:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnfj28087 for ; Tue, 31 Oct 2000 01:47:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnfj17991 for ; Tue, 31 Oct 2000 01:46:30 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjnfj18055 for ; Tue, 31 Oct 2000 01:46:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA11200 for ; Mon, 30 Oct 2000 17:46:28 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id UAA10293 for mpls@uu.net; Mon, 30 Oct 2000 20:46:28 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjndr29000 for ; Mon, 30 Oct 2000 14:57:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjndr24001 for ; Mon, 30 Oct 2000 14:57:04 GMT Received: from rt1solut.iserver.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rt1solut.iserver.net [161.58.243.184]) id QQjndr07530 for ; Mon, 30 Oct 2000 14:57:03 GMT Received: from RTH1WS01 ([205.152.173.75]) by rt1solut.iserver.net (8.8.8) id HAA87705; Mon, 30 Oct 2000 07:57:01 -0700 (MST) Reply-To: From: "Robbie Harrell" To: Cc: Subject: RE: MPLS over L2 Date: Mon, 30 Oct 2000 09:56:51 -0500 Message-ID: <000801c04281$a3662a50$4bad98cd@all.callisma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <39F9B94F.3AB97763@level3.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit SO I can infer from your answer that a router is necessary to do the translation between protocols. -----Original Message----- From: luca@level3.net [mailto:luca@level3.net] Sent: Friday, October 27, 2000 1:20 PM To: robbie.harrell@callisma.com Cc: mpls@uu.net Subject: Re: MPLS over L2 Robbie Harrell wrote: > > Luca, I was reading the Internet draft "Transport of Layer 2 frames over > MPLS" and had the following questions. Using the example given with R1 an > R2, does the ingress L2 protocol and the egress L2 protocol have to be the > same. For instance can I bring in a L2 ATM cell over ATM at R1, transport > over my MPLS tunnel and deliver over an Ethernet egress interface at R2. Yes, they have to be the same. THere is a statement made about not doing internetworking in this implementation. > This doesn't seem possible to me unless the router reads the L3 information > and makes a routing decision on the L3 information irregardless of the L2 > encapsulation. I am working on a project to build a next generation NAP and > this would be an ideal scenario for one to many peering connections with > multiple ingress encapsulations. We are trying to eliminate the > intermediate routers found in the NAP so that peers are from ISP router to > ISP router (like R1 and R2 in the document). My major concern is whether or > not this works for a provider who connects on the ingress with say an ATM > pipe and wants to peer with other providers who may have Frame-Relay, > Ethernet, or ATM. There would be multiple peering sessions over MPLS > tunnels. It would have to come into the MPLS cloud under one L2 > encapsulation and leave under another. I am assuming the router would have > to be involved to assume protocol translations at the egress edge. Any > thoughts, hints or clarifications. > It could be possible to actually do the internetworking function in the end router device. In this case the traffic would transit the network in native mode. If it came in ATM AAL5, the PDUs would be transported unchanged to the egress router , where they would be converted to a different protocol. This could be a vendor specific feature, and does not have to be done "in the network". In this case the end router doing the conversion has all the information it could possibly need to do internetworking successfully. Luca Martini > Robbie Harrell > Senior Consultant > Callisma > 866-543-5737 pager > 8772079316@skytel.com -- Just say no to summer. Ski all year ! Luca Martini Senior Network Architect, Level 3 Communications - Broomfield, CO luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager page-luca@level3.net From owner-mpls@UU.NET Mon Oct 30 20:49:42 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21161 for ; Mon, 30 Oct 2000 20:49:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnfj25483; Tue, 31 Oct 2000 01:49:12 GMT Received: by mail-control.mail.uu.net id QQjnfj28131 for mpls-outgoing; Tue, 31 Oct 2000 01:48:45 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnfj28112 for ; Tue, 31 Oct 2000 01:48:25 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnfj26626 for ; Tue, 31 Oct 2000 01:45:40 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjnfj16998 for ; Tue, 31 Oct 2000 01:45:40 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA10744 for ; Mon, 30 Oct 2000 17:45:38 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id UAA10283 for mpls@uu.net; Mon, 30 Oct 2000 20:45:38 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjncw11747 for ; Mon, 30 Oct 2000 09:44:33 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjncw16314 for ; Mon, 30 Oct 2000 09:44:23 GMT Received: from mail.hkwebbank.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [210.177.53.39]) id QQjncw19228 for ; Mon, 30 Oct 2000 09:44:21 GMT Received: from wchancpx (202.130.178.195 [202.130.178.195]) by mail.hkwebbank.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 4RJA16SR; Mon, 30 Oct 2000 18:22:07 +0800 Message-ID: <009101c04255$d7fd02b0$48041bac@jnpr.net> From: "Wayne" To: Subject: Route Exchange between CE and PE Date: Mon, 30 Oct 2000 17:43:18 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01C04298.E3444BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_008E_01C04298.E3444BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am reading the RFC2547bis and came up with a question for route = exchange between the CE and PE. Suppose there are 2 CEs belongs to = different VRFs and connect to the same PE. RIP is used to exchange = routing. Though there is 2 different VRFs in the PE, would the RIP = process in it re-advertise the learned routes to the other CE in another = VPN? The RFC also suggests other routing options. Other the static route = implementation, I cannot find an answer for it. But I may miss some = important point while reading. Could anyone show me how this can be = solved? Thanks, Wayne ------=_NextPart_000_008E_01C04298.E3444BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am reading the RFC2547bis and came up = with a=20 question for route exchange between the CE and PE. Suppose = there are 2 CEs=20 belongs to different VRFs and connect to the same PE. RIP is used to = exchange=20 routing. Though there is 2 different VRFs in the PE, would the RIP = process in it=20 re-advertise the learned routes to the other CE in another VPN? The RFC = also=20 suggests other routing options. Other the static route implementation, I = cannot=20 find an answer for it. But I may miss some important point while = reading. Could=20 anyone show me how this can be solved?
 
Thanks,
Wayne
------=_NextPart_000_008E_01C04298.E3444BE0-- From owner-mpls@UU.NET Tue Oct 31 01:37:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17151 for ; Tue, 31 Oct 2000 01:37:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjngc23246; Tue, 31 Oct 2000 06:36:57 GMT Received: by mail-control.mail.uu.net id QQjngc12145 for mpls-outgoing; Tue, 31 Oct 2000 06:36:33 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjngc12140 for ; Tue, 31 Oct 2000 06:36:26 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjngc14181 for ; Tue, 31 Oct 2000 06:33:59 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjngc18763 for ; Tue, 31 Oct 2000 06:33:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA27054 for mpls@uu.net; Tue, 31 Oct 2000 01:33:57 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjngc11976 for ; Tue, 31 Oct 2000 06:33:36 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjngc12973 for ; Tue, 31 Oct 2000 06:33:27 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjngc18793 for ; Tue, 31 Oct 2000 06:33:27 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA05021; Mon, 30 Oct 2000 22:33:27 -0800 (PST) Received: from cisco.com (rtp-dial-1-6.cisco.com [10.83.97.6]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id WAA24770; Mon, 30 Oct 2000 22:33:24 -0800 (PST) Message-ID: <39FE68F6.6A150260@cisco.com> Date: Mon, 30 Oct 2000 22:38:46 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Wayne CC: mpls@UU.NET Subject: Re: Route Exchange between CE and PE References: <009101c04255$d7fd02b0$48041bac@jnpr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Wayne wrote: > > Hi, > > I am reading the RFC2547bis and came up with a question for route > exchange between the CE and PE. Suppose there are 2 CEs belongs to > different VRFs and connect to the same PE. RIP is used to exchange > routing. Though there is 2 different VRFs in the PE, would the RIP > process in it re-advertise the learned routes to the other CE in > another VPN? Not really. RIP on PE-CE1 would be isolated by implementation with the RIP PE-CE2. Re-advertising or inter-vrf importing is done via bgp based on the ext comunities values. > The RFC also suggests other routing options. Other the > static route implementation, I cannot find an answer for it. But I may > miss some important point while reading. Could anyone show me how this > can be solved? You can in fact implement any IGP between PE-CE. All you need to make sure that the routes learned by one context will be isolated by another inside your PE. R. From owner-mpls@UU.NET Tue Oct 31 04:06:18 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16932 for ; Tue, 31 Oct 2000 04:06:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjngm28463; Tue, 31 Oct 2000 09:05:46 GMT Received: by mail-control.mail.uu.net id QQjngm24564 for mpls-outgoing; Tue, 31 Oct 2000 09:05:14 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjngm24555 for ; Tue, 31 Oct 2000 09:04:59 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjngm15347 for ; Tue, 31 Oct 2000 09:04:32 GMT Received: from smtp4.cluster.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62]) id QQjngm26253 for ; Tue, 31 Oct 2000 09:04:31 GMT Received: from oleane (dyn-1-1-204.Vin.dialup.oleane.fr [195.25.4.204]) by smtp4.cluster.oleane.net with SMTP id KAA53265 for ; Tue, 31 Oct 2000 10:04:30 +0100 (CET) Message-ID: <000c01c0431a$0535da80$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: The first MPLS exhibition Date: Tue, 31 Oct 2000 10:07:39 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C04322.66958D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C04322.66958D40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The first MPLS exhibition ever organized will take place during MPLS = World in Paris.=20 Three exhibiting options are available. Please visit: http://www.upperside.fr/congress/exhi.htm ------=_NextPart_000_0009_01C04322.66958D40 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The first MPLS exhibition ever = organized will take=20 place during MPLS World
in Paris.
Three exhibiting options are=20 available.
Please visit:
http://www.upperside.f= r/congress/exhi.htm
------=_NextPart_000_0009_01C04322.66958D40-- From owner-mpls@UU.NET Tue Oct 31 09:55:41 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19219 for ; Tue, 31 Oct 2000 09:55:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhj27733; Tue, 31 Oct 2000 14:54:34 GMT Received: by mail-control.mail.uu.net id QQjnhj13878 for mpls-outgoing; Tue, 31 Oct 2000 14:54:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnhj13871 for ; Tue, 31 Oct 2000 14:53:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnhj10817 for ; Tue, 31 Oct 2000 14:53:22 GMT Received: from acmez.gatech.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: acmez.gatech.edu [130.207.165.24]) id QQjnhj20743 for ; Tue, 31 Oct 2000 14:53:22 GMT Received: (from gte358s@localhost) by acmez.gatech.edu (8.9.2/8.9.2) id JAA25725 for mpls@UU.NET; Tue, 31 Oct 2000 09:53:21 -0500 (EST) From: Sung-eok Jeon Message-Id: <200010311453.JAA25725@acmez.gatech.edu> Subject: Mapping TOS field onto EXP field? To: mpls@UU.NET Date: Tue, 31 Oct 2000 09:53:21 -0500 (EST) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Have you tried to combine DiffServ and MPLS ? Now we want to do that but I don't know how to map TOS of IP onto EXP field of MPLS. We used ds-2.2.10(? I am not sure if it is the correct name) for DiffServ implementation and linux-mpls-ldp.pre7-0.200 for MPLS implementation. If you have some experience, Please tell me something. thanks in advance, Jeon From owner-mpls@UU.NET Tue Oct 31 10:52:50 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19831 for ; Tue, 31 Oct 2000 10:52:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhn18864; Tue, 31 Oct 2000 15:52:06 GMT Received: by mail-control.mail.uu.net id QQjnhn29533 for mpls-outgoing; Tue, 31 Oct 2000 15:51:25 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnhn29502 for ; Tue, 31 Oct 2000 15:51:22 GMT Received: from cmr0.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnhn11117 for ; Tue, 31 Oct 2000 15:50:36 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnhn16558 for ; Tue, 31 Oct 2000 15:50:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA02318 for mpls@uu.net; Tue, 31 Oct 2000 10:50:34 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnhn29403 for ; Tue, 31 Oct 2000 15:50:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnhn03521 for ; Tue, 31 Oct 2000 15:47:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjnhn06172 for ; Tue, 31 Oct 2000 15:47:05 GMT Received: from spector.cisco.com (mirapoint@spector.cisco.com [161.44.234.46]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA08853 for ; Tue, 31 Oct 2000 10:47:04 -0500 (EST) Received: from bevsmith-w2k.cisco.com (ch2-dhcp137-191.cisco.com [161.44.137.191]) by spector.cisco.com (Mirapoint) with ESMTP id AAL04401; Tue, 31 Oct 2000 10:47:03 -0500 (EST) Message-Id: <4.3.2.7.2.20001031105144.00b3ae38@spector.cisco.com> X-Sender: bevsmith@spector.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Oct 2000 10:52:26 -0800 To: mpls@UU.NET From: Beverly Smith Subject: Help Needed with MPLS Project Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_8505710==_" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_8505710==_ Content-Type: text/plain; charset="us-ascii"; format=flowed --=====================_8505710==_ Content-Type: application/msword; name="MPLS.doc" Content-Disposition: attachment; filename="MPLS.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIgAAAAAAAAAA EAAAJAAAAAEAAAD+////AAAAACEAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAMwkAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIhAAADd8AAA3fAAAMwUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAGIBAAAAAAAAYgEAAGIB AAAAAAAAYgEAAAAAAABiAQAAAAAAAGIBAAAAAAAAYgEAABQAAAAAAAAAAAAAAHYBAAAAAAAAigMA AAAAAACKAwAAAAAAAIoDAAAAAAAAigMAAAwAAACWAwAADAAAAHYBAAAAAAAApwgAALYAAACuAwAA AAAAAK4DAAAAAAAArgMAAAAAAACuAwAAAAAAAK4DAAAAAAAArgMAAAAAAACuAwAAAAAAAK4DAAAA AAAAJggAAAIAAAAoCAAAAAAAACgIAAAAAAAAKAgAAAAAAAAoCAAAAAAAACgIAAAAAAAAKAgAACQA AABdCQAAIAIAAH0LAABYAAAATAgAABUAAAAAAAAAAAAAAAAAAAAAAAAAYgEAAAAAAACuAwAAAAAA AAAAAAAAAAAAAAAAAAAAAACuAwAAAAAAAK4DAAAAAAAArgMAAAAAAACuAwAAAAAAAEwIAAAAAAAA LgUAAAAAAABiAQAAAAAAAGIBAAAAAAAArgMAAAAAAAAAAAAAAAAAAK4DAAAAAAAAYQgAABYAAAAu BQAAAAAAAC4FAAAAAAAALgUAAAAAAACuAwAAFgAAAGIBAAAAAAAArgMAAAAAAABiAQAAAAAAAK4D AAAAAAAAJggAAAAAAAAAAAAAAAAAAC4FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAArgMAAAAAAAAmCAAAAAAAAC4FAAD4AgAALgUAAAAAAAAAAAAA AAAAACYIAAAAAAAAYgEAAAAAAABiAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJggAAAAAAACuAwAAAAAAAKIDAAAMAAAA0Ph4f2tD wAF2AQAAFAIAAIoDAAAAAAAAxAMAAC4AAAAmCAAAAAAAAAAAAAAAAAAAJggAAAAAAAB3CAAAMAAA AKcIAAAAAAAAJggAAAAAAADVCwAApwEAAPIDAAA8AQAAfA0AAAAAAAAmCAAAAAAAAC4FAAAAAAAA dgEAAAAAAAB2AQAAAAAAAGIBAAAAAAAAYgEAAAAAAABiAQAAAAAAAGIBAAAAAAAAAgDZAAAADUhp LCBJJ20gQmV2ZXJseSBTbWl0aCBhbmQgSSB3b3JrIGZvciBDaXNjbyBTeXN0ZW0ncyBTZXJ2aWNl IFByb3ZpZGVyIExpbmUNb2YgQnVzaW5lc3MgaW4gQ2hlbG1zZm9yZCwgTUEuICBJIG9idGFpbmVk IHlvdXIgYWRkcmVzcyBmcm9tIGEgd2ViIHBhZ2Ugb24gdGhlIEludGVybmV0LiBJJ3ZlIGJlZW4g dGFza2VkIHdpdGggaGVscGluZyBhIHZlcnkgaW1wb3J0YW50IHByb2plY3Qgd2l0aGluIG91ciBN UExTIA1UcmFmZmljIEVuZ2luZWVyaW5nIG9yZ2FuaXphdGlvbiwgYW5kIHdhcyB3b25kZXJpbmcg aWYgeW91IGNvdWxkIGhlbHAgbWUuIEknbSBuZXcgDXRvIHRoaXMgc2VjdG9yIG9mIHRoZSBpbmR1 c3RyeSBhbmQgbmVlZCB0byBuZXR3b3JrIHdpdGggZ29vZCBmb2xrcyB3aG8gbWF5IGtub3cgc29t ZW9uZSBpbnRlcmVzdGVkIGluIGpvaW5pbmcgb3VyIHJhcGlkbHkgZ3Jvd2luZyB0ZWFtLiANDVNp bmNlIHlvdSBhcmUgaW4gdGhpcyBidXNpbmVzcywgeW91IG1heSBiZSBhYmxlIHRvIGhlbHAgbWUg bmV0d29yay4gSSdtIGxvb2tpbmcgZm9yIHBlb3BsZSB3aXRoIHNvZnR3YXJlIGRldmVsb3BtZW50 IGFuZC9vciB0ZXN0IGV4cGVyaWVuY2Ugd2hvIGFyZSBmYW1pbGlhciB3aXRoIHRoaXMgc2VjdG9y LCBldmVuIGlmIHRoZXkgYXJlIG5vdCBpbiB0aGlzIGdlb2dyYXBoaWMgYXJlYS4gUGxlYXNlIGxl dCBtZSBrbm93IGlmIGFueSBvZiB5b3VyIGZyaWVuZHMsIHBlZXJzIG9yIGNvbnRhY3RzIHdvdWxk IGJlIGludGVyZXN0ZWQgaW4gdGFsa2luZyB3aXRoIG1lIGFib3V0IHRoaXMgb3Bwb3J0dW5pdHkN b3Iga25vdyBzb21lb25lIGluIHRoZSBvcHRpY2FsIG5ldHdvcmtpbmcgYnVzaW5lc3MuIEFsc28s IGFueSBzdWdnZXN0aW9ucyBvbiB3aGVyZSBlbHNlIHRvIG5ldHdvcmsgd291bGQgYmUgYXBwcmVj aWF0ZWQhDQ1JZiBJIHNob3VsZCBjb250YWN0IHlvdSBieSBvdGhlciBtZWFucywgb3IgYXQgYW5v dGhlciBhZGRyZXNzLCBwbGVhc2UgcmVwbHkgb3IgY2FsbC4NT3IsIGlmIHlvdSBrbm93IHNvbWVv bmUgd2hvIGlzIGludGVyZXN0ZWQsIGZlZWwgZnJlZSB0byBzaW1wbHkgZm9yd2FyZCB0aGlzIG1l c3NhZ2UuDQ1UaGFua3MgaW4gYWR2YW5jZSBmb3IgeW91ciBhc3Npc3RhbmNlIQ0NQmV2ZXJseSBC LiBTbWl0aCANSW50ZXJuZXQgUmVjcnVpdGVyIA1EaXJlY3Q6IDk3OC4yNDQuNjk1NCBGYXg6IDk3 OC4yNDQuODc4NSANRW1haWw6IGJldnNtaXRoQGNpc2NvLmNvbSANQyBpIHMgYyBvIFMgeSBzIHQg ZSBtIHMsIEkgbiBjIA0iRW1wb3dlcmluZyB0aGUgSW50ZXJuZXQgR2VuZXJhdGlvbiIgDS4uLkFy ZSBZb3UgUmVhZHk/IA0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAG4I AAAwCQAAMwkAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEXkoCAAMABAAAAQQA AEsEAADsBAAAPwUAAMgFAADJBQAAIQcAAJoHAACbBwAA8AcAAEUIAABGCAAAbQgAAG4IAACACAAA lAgAALwIAADXCAAA9wgAAB0JAAAwCQAAMQkAADIJAAAzCQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAERAAABAAAAGAAEAAAzCQAA /QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQEBIAAxkGgBH7DQ LyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUABIACgABAGkA DwADAAAAAAAAAAAAOAAAQPH/AgA4AAwABgBOAG8AcgBtAGEAbAAAAAIAAAAYAENKGABfSAEEYUoY AG1ICQRzSAkEdEgJBAAAAAAAAAAAAAAAAAAAAAAAADwAQUDy/6EAPAAMABYARABlAGYAYQB1AGwA dAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAuAFVAogDxAC4ADAAJ AEgAeQBwAGUAcgBsAGkAbgBrAAAADAA+KgFCKgJwaAAA/wA+AFZAogABAT4ADAARAEYAbwBsAGwA bwB3AGUAZABIAHkAcABlAHIAbABpAG4AawAAAAwAPioBQioMcGiAAIAASAD+b/H/EgFIAAwACQBI AFQATQBMACAAQgBvAGQAeQAAAAsAEQA3JAA4JABIJAAAGABPSgIAUUoCAF9IAQRtSAkEc0gJBHRI CQQAAAAAMwUAAAcAABAAAAYA/////wAAAAABAAAASwAAAOwAAAA/AQAAyAEAAMkBAAAhAwAAmgMA AJsDAADwAwAARQQAAEYEAABtBAAAbgQAAIAEAACUBAAAvAQAANcEAAD3BAAAHQUAADAFAAAxBQAA MgUAADUFAACYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAA AAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAA AAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAETAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAIAABAAAMwkAAAUAAAAABAAA MwkAAAYAAAAABAAAMwkAAAcAAAAAAAAA2QQAANoEAAA1BQAABwAcAAcAAAAAAD8BAABBAQAAVQIA AFgCAAAhAwAAIwMAADUFAAAHADMABwAzAAcAMwAHAAAAAAABAAAACQAAABYAAABWAAAAawAAAG0A AAB2AAAArQAAAK4AAADlAAAADAEAAD4BAAA/AQAAVAEAAFUBAAChAQAAogEAAMcBAADHAQAAyQEA AAQCAAApAgAASgIAAFwCAABdAgAAawIAAHYCAACSAgAAlAIAAJ8CAACgAgAA6wIAAOwCAAAgAwAA IQMAADcDAAA4AwAAWQMAAFoDAACDAwAAmQMAAJsDAACbAwAA2QMAANoDAADvAwAA8QMAACQEAAAl BAAARgQAADIFAAA1BQAABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwD//wwAAAAKAEMAaQBzAGMAbwAgAFUAcwBlAHIAZQBEADoAXABEAG8AYwB1AG0AZQBuAHQA cwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAYgBlAHYAcwBtAGkAdABoAFwAQQBwAHAAbABp AGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEA dQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAEQAbwBjAHUAbQBlAG4AdAAy AC4AYQBzAGQACgBDAGkAcwBjAG8AIABVAHMAZQByABsARAA6AFwATQB5ACAARABvAGMAdQBtAGUA bgB0AHMAXABNAFAATABTACAAQQBkAC4AZABvAGMACgBDAGkAcwBjAG8AIABVAHMAZQByABsARAA6 AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABNAFAATABTACAAQQBkAC4AZABvAGMACgBDAGkA cwBjAG8AIABVAHMAZQByABsARAA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABNAFAATABT ACAAQQBkAC4AZABvAGMACgBDAGkAcwBjAG8AIABVAHMAZQByAGMARAA6AFwARABvAGMAdQBtAGUA bgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGIAZQB2AHMAbQBpAHQAaABcAEEAcABw AGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQA XABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABNAFAATABTACAAQQBk AC4AYQBzAGQACgBDAGkAcwBjAG8AIABVAHMAZQByABgARAA6AFwATQB5ACAARABvAGMAdQBtAGUA bgB0AHMAXABNAFAATABTAC4AZABvAGMA/0ABgAEAfwQAAH8EAABok3QAZwBnAH8EAAAAAAAAfwQA AAAAAAACEAAAAAAAAAAzBQAAcAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAA AAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAAAwAAAEcWkAEAAAICBgMFBAUC AwSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAA ADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMm kAEAAAILBgQCAgICAgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAAiAAQAcQiI GADw0ALkBGgBAAAAALL6Skay+kpGAAAAAAIAAgAAAMAAAABJBAAAAQACAAAABAADEAkAAAAAAAAA AAAAAAEAAQAAAAEAAAAAAAAAIQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAegBbQA tACBgTIwAAAQABkAZAAAABkAAABDBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAMwUAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAMoMRAPAQAAgAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAAAMASABpACwAAAAAAAAACgBDAGkAcwBj AG8AIABVAHMAZQByAAoAQwBpAHMAYwBvACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAABrw BgAAAAAAwAAAAAAAAEYGAAAAZ8mIDAAAAADggOlaAAAAAAAAAAAAAAAA4IDpWuCA6VoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQAAACkARHJhZnQgb2YgZW1haWwgdG8gTVBMUyBkaXN0cmlidXRpb24g bGlzdHMAACMBytwBAAAAAAAAACMBytwBAAAAAQAAAAoAAAA4jSMAAwAVDAEAAAAeAAEwEwBiZXZz bWl0aEBjaXNjby5jb20AHgADMBMAYmV2c21pdGhAY2lzY28uY29tAB4AAjAFAFNNVFAAAgH/D0MA AAAAAIErH6S+oxAZnW4A3QEPVAIAAAEAYmV2c21pdGhAY2lzY28uY29tAFNNVFAAYmV2c21pdGhA Y2lzY28uY29tAAMA/g8GAAAAAwD/XwAAAAADAP1fAQAAAB4A9l8TAGJldnNtaXRoQGNpc2NvLmNv bQACAfdfQwAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAQBiZXZzbWl0aEBjaXNjby5jb20AU01UUABi ZXZzbWl0aEBjaXNjby5jb20AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAA AAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAcAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAA AKQAAAAEAAAAsAAAAAUAAADEAAAABgAAANAAAAAHAAAA3AAAAAgAAADwAAAACQAAAAQBAAASAAAA EAEAAAoAAAAsAQAADAAAADgBAAANAAAARAEAAA4AAABQAQAADwAAAFgBAAAQAAAAYAEAABMAAABo AQAAAgAAAOQEAAAeAAAABAAAAEhpLAAeAAAAAQAAAABpLAAeAAAACwAAAENpc2NvIFVzZXIAAB4A AAABAAAAAGlzYx4AAAABAAAAAGlzYx4AAAALAAAATm9ybWFsLmRvdAAAHgAAAAsAAABDaXNjbyBV c2VyAAAeAAAAAgAAADIAc2MeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMAAAQAAAAACMhkcAAAAA QAAAAAA89F5rQ8ABQAAAAAA89F5rQ8ABAwAAAAEAAAADAAAAwAAAAAMAAABJBAAAAwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEA AAAC1c3VnC4bEJOXCAArLPmuMAAAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACMAAAABgAA AJQAAAARAAAAnAAAABcAAACkAAAACwAAAKwAAAAQAAAAtAAAABMAAAC8AAAAFgAAAMQAAAANAAAA zAAAAAwAAADcAAAAAgAAAOQEAAAeAAAAFAAAAENpc2NvIFN5c3RlbXMsIEluYy4AAwAAAAkAAAAD AAAAAgAAAAMAAABDBQAAAwAAAPwKCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4Q AAABAAAABAAAAEhpLAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAP7/ //8KAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAA/v///xIAAAATAAAAFAAAABUAAAAWAAAAFwAA ABgAAAD+////GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAAP7////9////IwAAAP7////+//// /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAA AAAARgAAAAAAAAAAAAAAANBikX9rQ8ABJQAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAABAAAAAAAABXAG8AcgBk AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAi EAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUA YwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW AAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAADQYpF/a0PAAdBikX9rQ8ABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9z b2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA --=====================_8505710==_-- From owner-mpls@UU.NET Tue Oct 31 10:57:55 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22206 for ; Tue, 31 Oct 2000 10:57:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhn26520; Tue, 31 Oct 2000 15:57:09 GMT Received: by mail-control.mail.uu.net id QQjnhn29881 for mpls-outgoing; Tue, 31 Oct 2000 15:56:47 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnhn29872 for ; Tue, 31 Oct 2000 15:56:45 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnhn04217 for ; Tue, 31 Oct 2000 15:54:49 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjnhn23066 for ; Tue, 31 Oct 2000 15:54:46 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA15461; Tue, 31 Oct 2000 21:22:41 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA17030; Tue, 31 Oct 2000 21:24:42 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Tue, 31 Oct 2000 21:24:41 +0530 (IST) From: Ramanjaneyulu Y T To: Beverly Smith cc: mpls@UU.NET Subject: Re: Help Needed with MPLS Project In-Reply-To: <4.3.2.7.2.20001031105144.00b3ae38@spector.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, please send your file in *.txt file or *.pdf file. Regards Ramanjaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ------------------------------------------------------------------------------ Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@123india.com BANGALORE - 560012 | kingytr@excite.com PH: 91 - 80 - 3092622 ( HOSTEL ) | 91 - 80 - 3092658 ( HFCL LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- On Tue, 31 Oct 2000, Beverly Smith wrote: From owner-mpls@UU.NET Tue Oct 31 11:00:18 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23429 for ; Tue, 31 Oct 2000 11:00:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhn00654; Tue, 31 Oct 2000 15:59:44 GMT Received: by mail-control.mail.uu.net id QQjnhn00018 for mpls-outgoing; Tue, 31 Oct 2000 15:59:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnhn29991 for ; Tue, 31 Oct 2000 15:59:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnhn07583 for ; Tue, 31 Oct 2000 15:58:35 GMT Received: from shrimp.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns4.BayNetworks.COM [192.32.253.7]) id QQjnhn23558 for ; Tue, 31 Oct 2000 15:58:34 GMT Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id KAA17701; Tue, 31 Oct 2000 10:51:25 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id KAA28562; Tue, 31 Oct 2000 10:58:32 -0500 (EST) Received: from lead.engeast (lead [192.32.148.52]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA11312; Tue, 31 Oct 2000 10:58:31 -0500 for Received: from nortelnetworks.com by lead.engeast (SMI-8.6/SMI-SVR4) id KAA21746; Tue, 31 Oct 2000 10:57:39 -0500 Message-ID: <39FEEBF3.AEF042C0@nortelnetworks.com> Date: Tue, 31 Oct 2000 10:57:39 -0500 From: Rajesh Saluja X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Robert Raszuk CC: Wayne , mpls@UU.NET Subject: Re: Route Exchange between CE and PE References: <009101c04255$d7fd02b0$48041bac@jnpr.net> <39FE68F6.6A150260@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert Raszuk wrote: > > Wayne wrote: > > > > Hi, > > > > I am reading the RFC2547bis and came up with a question for route > > exchange between the CE and PE. Suppose there are 2 CEs belongs to > > different VRFs and connect to the same PE. RIP is used to exchange > > routing. Though there is 2 different VRFs in the PE, would the RIP > > process in it re-advertise the learned routes to the other CE in > > another VPN? > > Not really. RIP on PE-CE1 would be isolated by implementation with the > RIP PE-CE2. Re-advertising or inter-vrf importing is done via bgp based > on the ext comunities values. > > In the above example, If these two VRFs have at least one common VPN, shouldn't RIP readvertise the routes learnt from one CE to other CE? Thanks, Rajesh From owner-mpls@UU.NET Tue Oct 31 11:01:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24170 for ; Tue, 31 Oct 2000 11:01:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnho27699; Tue, 31 Oct 2000 16:00:59 GMT Received: by mail-control.mail.uu.net id QQjnho02052 for mpls-outgoing; Tue, 31 Oct 2000 16:00:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnho01123 for ; Tue, 31 Oct 2000 16:00:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnhn00290 for ; Tue, 31 Oct 2000 15:59:23 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f138.law11.hotmail.com [64.4.17.138]) id QQjnhn29707 for ; Tue, 31 Oct 2000 15:59:22 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Oct 2000 07:59:20 -0800 Received: from 63.108.78.2 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 31 Oct 2000 15:59:20 GMT X-Originating-IP: [63.108.78.2] From: "Charles Smith" To: bevsmith@cisco.com, mpls@UU.NET Subject: Re: Help Needed with MPLS Project Date: Tue, 31 Oct 2000 15:59:20 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Oct 2000 15:59:20.0250 (UTC) FILETIME=[879661A0:01C04353] Sender: owner-mpls@UU.NET Precedence: bulk It's sad when Cisco must resort to openly recruiting on an IETF working group list... >From: Beverly Smith >To: mpls@UU.NET >Subject: Help Needed with MPLS Project >Date: Tue, 31 Oct 2000 10:52:26 -0800 > ><< MPLS.doc >> _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Tue Oct 31 11:29:26 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05784 for ; Tue, 31 Oct 2000 11:29:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhp07115; Tue, 31 Oct 2000 16:28:13 GMT Received: by mail-control.mail.uu.net id QQjnhp14460 for mpls-outgoing; Tue, 31 Oct 2000 16:27:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnhp14453 for ; Tue, 31 Oct 2000 16:27:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnhp04272 for ; Tue, 31 Oct 2000 16:27:06 GMT Received: from mercury.polarisnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnai-216-15-8-227.cust.dnai.com [216.15.8.227]) id QQjnhp09891 for ; Tue, 31 Oct 2000 16:27:06 GMT Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Tue, 31 Oct 2000 08:30:50 -0800 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <469622J7>; Tue, 31 Oct 2000 08:29:13 -0800 Message-ID: From: "Huang, Thomas" To: mpls@UU.NET Subject: Test message in LMP Date: Tue, 31 Oct 2000 08:29:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Authors of LMP and all: In LMP draft, section 8.1.3.5 Test Message and section 8.1.3.6 TestStatusSuccess showed a method to test the connectivity of a link of some type. Could someone help me and explain how this test message is transmitted over the link to the far-end and far-end decode this message and then ack back? I am familar with the COT testing for trunks done in voice network. It seems awefully difficult to do what the draft suggested here. Regards, Thomas From owner-mpls@UU.NET Tue Oct 31 11:38:19 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08756 for ; Tue, 31 Oct 2000 11:38:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhq21023; Tue, 31 Oct 2000 16:37:43 GMT Received: by mail-control.mail.uu.net id QQjnhq15567 for mpls-outgoing; Tue, 31 Oct 2000 16:37:11 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnhq15562 for ; Tue, 31 Oct 2000 16:37:01 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnhq11865 for ; Tue, 31 Oct 2000 16:36:32 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f29.law4.hotmail.com [216.33.149.29]) id QQjnhq22881 for ; Tue, 31 Oct 2000 16:36:31 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Oct 2000 08:36:31 -0800 Received: from 138.96.192.3 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 31 Oct 2000 16:36:31 GMT X-Originating-IP: [138.96.192.3] From: "Rares SERBAN" To: bevsmith@cisco.com Cc: mpls@UU.NET Subject: Re: Help Needed with MPLS Project Date: Tue, 31 Oct 2000 16:36:31 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Oct 2000 16:36:31.0572 (UTC) FILETIME=[B98F1940:01C04358] Sender: owner-mpls@UU.NET Precedence: bulk Hi Smith, The following persons are working for CISCO with MPLS: Dr. Yakov Rekhter, Cisco Fellow George Swallow, Cisco Systems On 6-th - 9th February 2001 in Paris will be MPLS World 2000 Congress. http://www.upperside.fr/congress/scien.htm May be you will find the right persons there! :) Best regards, R. >From: Beverly Smith >To: mpls@UU.NET >Subject: Help Needed with MPLS Project >Date: Tue, 31 Oct 2000 10:52:26 -0800 > ><< MPLS.doc >> _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Tue Oct 31 11:49:24 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12788 for ; Tue, 31 Oct 2000 11:49:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhr07019; Tue, 31 Oct 2000 16:48:37 GMT Received: by mail-control.mail.uu.net id QQjnhr16665 for mpls-outgoing; Tue, 31 Oct 2000 16:48:14 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnhr16657 for ; Tue, 31 Oct 2000 16:48:05 GMT Received: from cmr2.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnhr23335 for ; Tue, 31 Oct 2000 16:47:55 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f189.law11.hotmail.com [64.4.17.189]) id QQjnhr05869 for ; Tue, 31 Oct 2000 16:47:54 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Oct 2000 08:47:52 -0800 Received: from 63.108.78.2 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 31 Oct 2000 16:47:52 GMT X-Originating-IP: [63.108.78.2] From: "Charles Smith" To: serban_rares@hotmail.com Cc: mpls@UU.NET Subject: Re: Help Needed with MPLS Project Date: Tue, 31 Oct 2000 16:47:52 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Oct 2000 16:47:52.0299 (UTC) FILETIME=[4F4DCBB0:01C0435A] Sender: owner-mpls@UU.NET Precedence: bulk Are you serious? Beverly works for Cisco and knows who is currently working on the MPLS project from Cisco...read the attachment - Beverly is recruiting! Hello! -----Original Message----- From: Rares SERBAN [mailto:serban_rares@hotmail.com] Sent: Tuesday, October 31, 2000 10:37 AM To: bevsmith@cisco.com Cc: mpls@UU.NET Subject: Re: Help Needed with MPLS Project Hi Smith, The following persons are working for CISCO with MPLS: Dr. Yakov Rekhter, Cisco Fellow George Swallow, Cisco Systems On 6-th - 9th February 2001 in Paris will be MPLS World 2000 Congress. http://www.upperside.fr/congress/scien.htm May be you will find the right persons there! :) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Tue Oct 31 12:04:30 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18010 for ; Tue, 31 Oct 2000 12:04:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhs00992; Tue, 31 Oct 2000 17:03:23 GMT Received: by mail-control.mail.uu.net id QQjnhs24750 for mpls-outgoing; Tue, 31 Oct 2000 17:02:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnhs24740 for ; Tue, 31 Oct 2000 17:02:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnhs13095 for ; Tue, 31 Oct 2000 17:01:50 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f260.law4.hotmail.com [216.33.148.138]) id QQjnhs28784 for ; Tue, 31 Oct 2000 17:01:50 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Oct 2000 09:01:50 -0800 Received: from 138.96.192.3 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 31 Oct 2000 17:01:49 GMT X-Originating-IP: [138.96.192.3] From: "Rares SERBAN" To: chasmith9@hotmail.com Cc: mpls@UU.NET Subject: Re: Help Needed with MPLS Project Date: Tue, 31 Oct 2000 17:01:49 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Oct 2000 17:01:50.0205 (UTC) FILETIME=[42BC1AD0:01C0435C] Sender: owner-mpls@UU.NET Precedence: bulk Hello! Yes, I am joking because he "obtained your address from a web page on the Internet".... :) Happy Halloween! R. >From: "Charles Smith" >To: serban_rares@hotmail.com >CC: mpls@UU.NET >Subject: Re: Help Needed with MPLS Project >Date: Tue, 31 Oct 2000 16:47:52 GMT > >Are you serious? Beverly works for Cisco and knows who is currently working >on the MPLS project from Cisco...read the attachment - Beverly is >recruiting! Hello! > > >-----Original Message----- >From: Rares SERBAN [mailto:serban_rares@hotmail.com] >Sent: Tuesday, October 31, 2000 10:37 AM >To: bevsmith@cisco.com >Cc: mpls@UU.NET >Subject: Re: Help Needed with MPLS Project > > >Hi Smith, > >The following persons are working for CISCO with MPLS: > >Dr. Yakov Rekhter, Cisco Fellow >George Swallow, Cisco Systems > >On 6-th - 9th February 2001 in Paris will be MPLS World 2000 Congress. >http://www.upperside.fr/congress/scien.htm >May be you will find the right persons there! :) > >_________________________________________________________________________ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > >Share information about yourself, create your own public profile at >http://profiles.msn.com. > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Tue Oct 31 12:05:29 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18350 for ; Tue, 31 Oct 2000 12:05:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhs02676; Tue, 31 Oct 2000 17:04:25 GMT Received: by mail-control.mail.uu.net id QQjnhs26314 for mpls-outgoing; Tue, 31 Oct 2000 17:03:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnhs25501 for ; Tue, 31 Oct 2000 17:03:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnhs17804 for ; Tue, 31 Oct 2000 17:03:27 GMT Received: from cat01s2.catenanet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host-229.catenanet.maxlink.com [216.221.199.229]) id QQjnhs27591 for ; Tue, 31 Oct 2000 17:03:27 GMT Received: by CAT01S2 with Internet Mail Service (5.5.2448.0) id ; Tue, 31 Oct 2000 12:03:27 -0500 Message-ID: <310508EDF557D31188FA0050DA0A3752BCDAB1@CAT01S2> From: Yapeng Wu To: "'Charles Smith'" , serban_rares@hotmail.com Cc: mpls@UU.NET Subject: RE: Help Needed with MPLS Project Date: Tue, 31 Oct 2000 12:03:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Could we stop at here? I think most in this mailing list don't expect this kind of messages. Thanks. -----Original Message----- From: Charles Smith [mailto:chasmith9@hotmail.com] Sent: Tuesday, October 31, 2000 11:48 AM To: serban_rares@hotmail.com Cc: mpls@UU.NET Subject: Re: Help Needed with MPLS Project Are you serious? Beverly works for Cisco and knows who is currently working on the MPLS project from Cisco...read the attachment - Beverly is recruiting! Hello! -----Original Message----- From: Rares SERBAN [mailto:serban_rares@hotmail.com] Sent: Tuesday, October 31, 2000 10:37 AM To: bevsmith@cisco.com Cc: mpls@UU.NET Subject: Re: Help Needed with MPLS Project Hi Smith, The following persons are working for CISCO with MPLS: Dr. Yakov Rekhter, Cisco Fellow George Swallow, Cisco Systems On 6-th - 9th February 2001 in Paris will be MPLS World 2000 Congress. http://www.upperside.fr/congress/scien.htm May be you will find the right persons there! :) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Tue Oct 31 12:23:02 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25445 for ; Tue, 31 Oct 2000 12:23:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnht28333; Tue, 31 Oct 2000 17:22:26 GMT Received: by mail-control.mail.uu.net id QQjnht01989 for mpls-outgoing; Tue, 31 Oct 2000 17:21:54 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnht01963 for ; Tue, 31 Oct 2000 17:21:43 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnht20781 for ; Tue, 31 Oct 2000 17:18:49 GMT Received: from osf1.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQjnht23025 for ; Tue, 31 Oct 2000 17:18:48 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id MAA08348; Tue, 31 Oct 2000 12:18:43 -0500 (EST) Date: Tue, 31 Oct 2000 12:18:43 -0500 (EST) From: Rajiv Papneja To: Peter Lewis cc: mpls@UU.NET Subject: Re: The first MPLS exhibition In-Reply-To: <000c01c0431a$0535da80$8001a8c0@oleane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Peter, I wanted to mention here that the first MPLS exhibition was held in conjunction with the MPLS 2000 that concluded last week at George Mason University, Fairfax, VA, USA. This conference was jointly sponsored by Advanced Internet lab and UUNET technologies, and was third in the series. There were more than 15 exhibiting companies. Regards, -Rajiv On Tue, 31 Oct 2000, Peter Lewis wrote: > The first MPLS exhibition ever organized will take place during MPLS World > in Paris. > Three exhibiting options are available. > Please visit: > http://www.upperside.fr/congress/exhi.htm > From owner-mpls@UU.NET Tue Oct 31 12:59:02 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10422 for ; Tue, 31 Oct 2000 12:59:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhv16617; Tue, 31 Oct 2000 17:58:26 GMT Received: by mail-control.mail.uu.net id QQjnhv06330 for mpls-outgoing; Tue, 31 Oct 2000 17:58:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjnhv06281 for ; Tue, 31 Oct 2000 17:57:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnhv05320 for ; Tue, 31 Oct 2000 17:57:47 GMT Received: from mercury.polarisnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnai-216-15-8-227.cust.dnai.com [216.15.8.227]) id QQjnhv17517 for ; Tue, 31 Oct 2000 17:57:46 GMT Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Tue, 31 Oct 2000 10:01:31 -0800 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <469622MJ>; Tue, 31 Oct 2000 09:59:53 -0800 Message-ID: From: "Huang, Thomas" To: "Huang, Thomas" , mpls@UU.NET Subject: Additional info for my previous question on LMP test/teststatussu ccess RE: Test message in LMP Date: Tue, 31 Oct 2000 09:59:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk My question in the previous email are referring to non-packet link media type, such as TDM, lamda, FR or ATM. /Thomas -----Original Message----- From: Huang, Thomas [mailto:THuang@PolarisNetworks.com] Sent: Tuesday, October 31, 2000 8:29 AM To: mpls@UU.NET Subject: Test message in LMP Authors of LMP and all: In LMP draft, section 8.1.3.5 Test Message and section 8.1.3.6 TestStatusSuccess showed a method to test the connectivity of a link of some type. Could someone help me and explain how this test message is transmitted over the link to the far-end and far-end decode this message and then ack back? I am familar with the COT testing for trunks done in voice network. It seems awefully difficult to do what the draft suggested here. Regards, Thomas From owner-mpls@UU.NET Tue Oct 31 13:26:32 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20906 for ; Tue, 31 Oct 2000 13:26:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhx24901; Tue, 31 Oct 2000 18:25:42 GMT Received: by mail-control.mail.uu.net id QQjnhx20772 for mpls-outgoing; Tue, 31 Oct 2000 18:25:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnhx20760 for ; Tue, 31 Oct 2000 18:25:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnhx02902 for ; Tue, 31 Oct 2000 18:23:54 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjnhx23391 for ; Tue, 31 Oct 2000 18:23:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA00644 for mpls@uu.net; Tue, 31 Oct 2000 13:23:53 -0500 (EST) Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnhx20545 for ; Tue, 31 Oct 2000 18:23:33 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnhx29287 for ; Tue, 31 Oct 2000 18:21:10 GMT Received: from smtprch1.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch1.nortelnetworks.com [192.135.215.14]) id QQjnhx19657 for ; Tue, 31 Oct 2000 18:21:09 GMT Received: from zcard00m.ca.nortel.com by smtprch1.nortel.com; Tue, 31 Oct 2000 10:51:21 -0600 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VTYQFHD9; Tue, 31 Oct 2000 11:51:12 -0500 Received: from nortelnetworks.com (sandicknt.corpeast.baynetworks.com [132.245.252.71]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VB4D3AKW; Tue, 31 Oct 2000 11:51:06 -0500 Message-ID: <39FEF884.73B54046@nortelnetworks.com> Date: Tue, 31 Oct 2000 11:51:16 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Hal Sandick" Reply-To: "Hal Sandick" Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Charles Smith CC: mpls@UU.NET Subject: Re: Help Needed with MPLS Project References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit But somewhat entertaining ;-) Regards, Hal Charles Smith wrote: > It's sad when Cisco must resort to openly recruiting on an IETF working > group list... > > >From: Beverly Smith > >To: mpls@UU.NET > >Subject: Help Needed with MPLS Project > >Date: Tue, 31 Oct 2000 10:52:26 -0800 > > > ><< MPLS.doc >> > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. From owner-mpls@UU.NET Tue Oct 31 13:42:09 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26423 for ; Tue, 31 Oct 2000 13:42:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhy18758; Tue, 31 Oct 2000 18:41:38 GMT Received: by mail-control.mail.uu.net id QQjnhy21906 for mpls-outgoing; Tue, 31 Oct 2000 18:41:04 GMT Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjnhy21893 for ; Tue, 31 Oct 2000 18:41:00 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnhy28957 for ; Tue, 31 Oct 2000 18:39:40 GMT Received: from csa.iisc.ernet.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjnhy15575 for ; Tue, 31 Oct 2000 18:39:33 GMT Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id AAA17150; Wed, 1 Nov 2000 00:06:36 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id AAA21911; Wed, 1 Nov 2000 00:08:36 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Wed, 1 Nov 2000 00:08:35 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET, rsvp@isi.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk How does RSVP-TE identify whether the mesage recived is RSVP-TE message or normal RSVP message?? _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Tue, 31 Oct 2000 13:49:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnhz27695; Tue, 31 Oct 2000 18:48:30 GMT Received: by mail-control.mail.uu.net id QQjnhz22499 for mpls-outgoing; Tue, 31 Oct 2000 18:48:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnhz22482 for ; Tue, 31 Oct 2000 18:48:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjnhz15088 for ; Tue, 31 Oct 2000 18:47:23 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f72.law11.hotmail.com [64.4.17.72]) id QQjnhz20186 for ; Tue, 31 Oct 2000 18:47:22 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Oct 2000 10:47:20 -0800 Received: from 63.108.78.2 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 31 Oct 2000 18:47:20 GMT X-Originating-IP: [63.108.78.2] From: "Charles Smith" To: ywu@Catena.com Cc: mpls@UU.NET Subject: RE: Help Needed with MPLS Project Date: Tue, 31 Oct 2000 18:47:20 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Oct 2000 18:47:20.0608 (UTC) FILETIME=[FFF2F200:01C0436A] Sender: owner-mpls@UU.NET Precedence: bulk Really? I beg to differ. The overall intelect of the list was very clearly illustrated during the now famous Eric Rosen versus Paul Doolan thread. Just refer to the archives and look for: VPN solution - White flag ? Need I say more? >From: Yapeng Wu >To: 'Charles Smith' , serban_rares@hotmail.com >CC: mpls@UU.NET >Subject: RE: Help Needed with MPLS Project >Date: Tue, 31 Oct 2000 12:03:26 -0500 > >Could we stop at here? I think most in this mailing list don't expect this >kind of messages. > >Thanks. > >-----Original Message----- >From: Charles Smith [mailto:chasmith9@hotmail.com] >Sent: Tuesday, October 31, 2000 11:48 AM >To: serban_rares@hotmail.com >Cc: mpls@UU.NET >Subject: Re: Help Needed with MPLS Project > > >Are you serious? Beverly works for Cisco and knows who is currently working >on the MPLS project from Cisco...read the attachment - Beverly is >recruiting! Hello! > > >-----Original Message----- >From: Rares SERBAN [mailto:serban_rares@hotmail.com] >Sent: Tuesday, October 31, 2000 10:37 AM >To: bevsmith@cisco.com >Cc: mpls@UU.NET >Subject: Re: Help Needed with MPLS Project > > >Hi Smith, > >The following persons are working for CISCO with MPLS: > >Dr. Yakov Rekhter, Cisco Fellow >George Swallow, Cisco Systems > >On 6-th - 9th February 2001 in Paris will be MPLS World 2000 Congress. >http://www.upperside.fr/congress/scien.htm >May be you will find the right persons there! :) > >_________________________________________________________________________ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > >Share information about yourself, create your own public profile at >http://profiles.msn.com. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-mpls@UU.NET Tue Oct 31 19:38:07 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26982 for ; Tue, 31 Oct 2000 19:38:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjniw10328; Wed, 1 Nov 2000 00:37:39 GMT Received: by mail-control.mail.uu.net id QQjniw06226 for mpls-outgoing; Wed, 1 Nov 2000 00:37:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjniw06217 for ; Wed, 1 Nov 2000 00:37:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjniw22906 for ; Wed, 1 Nov 2000 00:35:45 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjniw11081 for ; Wed, 1 Nov 2000 00:35:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA16274 for mpls@uu.net; Tue, 31 Oct 2000 19:35:44 -0500 (EST) Received: from ashimr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr1.ash.ops.us.uu.net [153.39.43.46]) id QQjniw06023 for ; Wed, 1 Nov 2000 00:35:18 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjniw17344 for ; Wed, 1 Nov 2000 00:34:50 GMT Received: from shrimp.baynetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns4.BayNetworks.COM [192.32.253.7]) id QQjniw06660 for ; Wed, 1 Nov 2000 00:34:50 GMT Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id TAA29938 for ; Tue, 31 Oct 2000 19:27:23 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id TAA18334 for ; Tue, 31 Oct 2000 19:34:24 -0500 (EST) Received: from nortelnetworks.com (sandkey [192.32.148.98]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id TAA19428; Tue, 31 Oct 2000 19:34:23 -0500 for Message-ID: <39FF650F.54FB9AD0@nortelnetworks.com> Date: Tue, 31 Oct 2000 19:34:23 -0500 From: "Chavali, Srikanth [BAY:BL60:DS44]" Organization: Nortel Networks X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit subscribe schavali@nortelnetworks.com From owner-mpls@UU.NET Tue Oct 31 21:51:36 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03988 for ; Tue, 31 Oct 2000 21:51:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnjf08343; Wed, 1 Nov 2000 02:51:05 GMT Received: by mail-control.mail.uu.net id QQjnjf06645 for mpls-outgoing; Wed, 1 Nov 2000 02:50:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjnjf06640 for ; Wed, 1 Nov 2000 02:50:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjnjf09616 for ; Wed, 1 Nov 2000 02:49:58 GMT Received: from cms2.etri.re.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cms2.etri.re.kr [129.254.16.12]) id QQjnjf06784 for ; Wed, 1 Nov 2000 02:49:57 GMT Received: by cms2.etri.re.kr with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Nov 2000 11:50:04 +0900 Received: from mhson (mhson.etri.re.kr [129.254.197.141]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id V3DZHPDQ; Wed, 1 Nov 2000 11:50:00 +0900 From: =?EUC-KR?B?vNW47cjx?= To: rbonica@mci.net, tappan@cisco.com, dhg@juniper.net Cc: mpls@UU.NET Message-ID: <000f01c043ae$b50ca850$8dc5fe81@etri.re.kr> Subject: ICMP message body size Date: Wed, 1 Nov 2000 11:52:00 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C043FA.24D75270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C043FA.24D75270 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C043FA.24D8D910" ------=_NextPart_001_000C_01C043FA.24D8D910 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sIGV2ZXJ5b25lLg0KIA0KSSBoYXZlIHNvbWUgcXVlc3Rpb24gYWJvdXQgSUNNUCBFeHRl bnNpb25zIGZvciBNUExTLg0KSW4gb3JkZXIgdG8gb2J0YWluIHdpdGggbW9zdCBwZW9wbGUgdGhp cyBkcmFmdCBtdXN0IGJlIG5lZWRlZCB0byBmb2xsb3cNClJGQy0xODEyDQpiZWNhdXNlIGNvbW1v biBJQ01QIGRhdGEgZmllbGQgc2l6ZSBpcyAyOGJ5dGVzKGlwIGhlYWRlciA6IDIwYnl0ZXMgKw0K VUxQIGRhdGEgOiA4Ynl0ZXMpIGluIFJGQy03OTIsIGlzIGl0IHJpZ2h0Pw0KIA0KUkZDLTE4MTIg c2F5cyB0aGF0IElDTVAgZGF0YWdyYW0gc2hvdWxkIGNvbnRhaW4gYXMgbXVjaCBvZiB0aGUgb3Jp Z2luYWwNCmRhdGFncmFtDQphcyBwb3NzaWJsZSB3aXRob3V0IHRoZSBsZW5ndGggb2YgdGhlIElD TVAgZGF0YWdyYW0gZXhjZWVkaW5nIDU3NiBieXRlcy4NCkFjY29yZGluZyB0byB0aGlzIGRyYWZ0 IHRoZSBmaW5hbCBmaWVsZCBvZiB0aGUgSUNNUCBtdXN0IGNvbnRhaW4gdGhlDQpmaXJzdCAxMjgg Ynl0ZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UsIGhvdyBkbyB5b3UgZGVjaWRlIHRoZSBudW1i ZXINCm9mIDEyOCAgYW5kIGNhbiB5b3UgZXhwbGFpbiB0aGUgYmFzZSBvZiB0aGF0IG51bWJlciBp biBkZXRhaWwgPw0KIA0KQmVzdCByZWdhcmRzLA0KTXl1bmdoZWUsIFNvbi4gDQogDQogDQogDQo= ------=_NextPart_001_000C_01C043FA.24D8D910 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPEJBU0UgDQpocmVmPSJmaWxlOi8vQzpcUHJvZ3JhbSBGaWxl c1xDb21tb24gRmlsZXNcTWljcm9zb2Z0IFNoYXJlZFxTdGF0aW9uZXJ5XCI+DQo8U1RZTEU+Qk9E WSB7DQoJQ09MT1I6ICMwMDAwMDA7IEZPTlQtRkFNSUxZOiAisby4siI7IEZPTlQtU0laRTogMTJw dA0KfQ0KUFJFIHsNCglDT0xPUjogIzAwMDAwMDsgRk9OVC1GQU1JTFk6ICKxvLiyIjsgRk9OVC1T SVpFOiAxMnB0DQp9DQpCTE9DS1FVT1RFIHsNCglDT0xPUjogIzAwMDAwMDsgRk9OVC1GQU1JTFk6 ICKxvLiyIjsgRk9OVC1TSVpFOiAxMnB0DQp9DQpBIHsNCglDT0xPUjogIzAwMDAwMDsgRk9OVC1G QU1JTFk6ICKxvLiyIjsgRk9OVC1TSVpFOiAxMnB0DQp9DQpNRU5VIHsNCglDT0xPUjogIzAwMDAw MDsgRk9OVC1GQU1JTFk6ICKxvLiyIjsgRk9OVC1TSVpFOiAxMnB0DQp9DQpERCB7DQoJQ09MT1I6 ICMwMDAwMDA7IEZPTlQtRkFNSUxZOiAisby4siI7IEZPTlQtU0laRTogMTJwdA0KfQ0KVUwgew0K CUNPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogIrG8uLIiOyBGT05ULVNJWkU6IDEycHQNCn0N CkRUIHsNCglDT0xPUjogIzAwMDAwMDsgRk9OVC1GQU1JTFk6ICKxvLiyIjsgRk9OVC1TSVpFOiAx MnB0DQp9DQpESVIgew0KCUNPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogIrG8uLIiOyBGT05U LVNJWkU6IDEycHQNCn0NCkFERFJFU1Mgew0KCUNPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTog IrG8uLIiOyBGT05ULVNJWkU6IDEycHQNCn0NCkgxIHsNCglDT0xPUjogIzAwMDAwMDsgRk9OVC1G QU1JTFk6ICKxvLiyIjsgRk9OVC1TSVpFOiAxMnB0DQp9DQpIMiB7DQoJQ09MT1I6ICMwMDAwMDA7 IEZPTlQtRkFNSUxZOiAisby4siI7IEZPTlQtU0laRTogMTJwdA0KfQ0KSDMgew0KCUNPTE9SOiAj MDAwMDAwOyBGT05ULUZBTUlMWTogIrG8uLIiOyBGT05ULVNJWkU6IDEycHQNCn0NCkg0IHsNCglD T0xPUjogIzAwMDAwMDsgRk9OVC1GQU1JTFk6ICKxvLiyIjsgRk9OVC1TSVpFOiAxMnB0DQp9DQpI NSB7DQoJQ09MT1I6ICMwMDAwMDA7IEZPTlQtRkFNSUxZOiAisby4siI7IEZPTlQtU0laRTogMTJw dA0KfQ0KSDYgew0KCUNPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogIrG8uLIiOyBGT05ULVNJ WkU6IDEycHQNCn0NCkhSIHsNCglDT0xPUjogIzAwMDAwMDsgRk9OVC1GQU1JTFk6ICKxvLiyIjsg Rk9OVC1TSVpFOiAxMnB0DQp9DQo8L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTE5LjYzMDciIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIGJhY2tncm91bmQ9Y2lk OjAwMGEwMWMwNDNhZSRiNGU5OGZmMCQ4ZGM1ZmU4MUBldHJpLnJlLmtyIGJnQ29sb3I9I2ZmZmZm Zj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLCBldmVyeW9uZS48L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBoYXZlIHNvbWUgcXVlc3Rpb24gYWJv dXQgSUNNUCBFeHRlbnNpb25zIGZvciANCk1QTFMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+SW4gb3JkZXImbmJzcDt0byBvYnRhaW4gd2l0aCBtb3N0IHBlb3BsZSB0aGlzIGRyYWZ0 Jm5ic3A7bXVzdCANCmJlIG5lZWRlZCB0byBmb2xsb3cgUkZDLTE4MTI8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5iZWNhdXNlJm5ic3A7Y29tbW9uIElDTVAgZGF0YSBmaWVsZCBzaXpl IGlzIDI4Ynl0ZXMoaXAgaGVhZGVyIA0KOiAyMGJ5dGVzICsgVUxQIGRhdGEgOiA4Ynl0ZXMpIGlu Jm5ic3A7UkZDLTc5MiwgaXMgaXQgcmlnaHQ/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPlJGQy0xODEyIHNheXMgdGhhdCBJQ01QIGRhdGFncmFtIHNo b3VsZCBjb250YWluIGFzIG11Y2ggb2YgdGhlIA0Kb3JpZ2luYWwgZGF0YWdyYW08L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5hcyBwb3NzaWJsZSB3aXRob3V0IHRoZSBsZW5ndGggb2Yg dGhlIElDTVAgZGF0YWdyYW0gZXhjZWVkaW5nIA0KNTc2IGJ5dGVzLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPkFjY29yZGluZyB0byB0aGlzIGRyYWZ0IHRoZSBmaW5hbCBmaWVsZCBv ZiB0aGUgSUNNUCBtdXN0IA0KY29udGFpbiB0aGUgZmlyc3QgMTI4IGJ5dGVzIG9mIHRoZSBvcmln aW5hbCBtZXNzYWdlLCBob3cgZG8geW91IGRlY2lkZSB0aGUgDQpudW1iZXIgb2YgMTI4Jm5ic3A7 IGFuZCZuYnNwO2NhbiB5b3UgZXhwbGFpbiB0aGUgYmFzZSBvZiB0aGF0IG51bWJlciBpbiBkZXRh aWwgDQo/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+QmVzdCByZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPk15dW5naGVlLCBTb24uPC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+ DQo= ------=_NextPart_001_000C_01C043FA.24D8D910-- ------=_NextPart_000_000B_01C043FA.24D75270 Content-Type: image/gif; name="tech.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c043ae$b4e98ff0$8dc5fe81@etri.re.kr> Content-Transfer-Encoding: base64 R0lGODlhFAAUAPcAAP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MAP+Z//+ZzP+Z mf+ZZv+ZM/+ZAP9m//9mzP9mmf9mZv9mM/9mAP8z//8zzP8zmf8zZv8zM/8zAP8A//8AzP8Amf8A Zv8AM/8AAMz//8z/zMz/mcz/Zsz/M8z/AMzM/8zMzMzMmczMZszMM8zMAMyZ/8yZzMyZmcyZZsyZ M8yZAMxm/8xmzMxmmcxmZsxmM8xmAMwz/8wzzMwzmcwzZswzM8wzAMwA/8wAzMwAmcwAZswAM8wA AJn//5n/zJn/mZn/Zpn/M5n/AJnM/5nMzJnMmZnMZpnMM5nMAJmZ/5mZzJmZmZmZZpmZM5mZAJlm /5lmzJlmmZlmZplmM5lmAJkz/5kzzJkzmZkzZpkzM5kzAJkA/5kAzJkAmZkAZpkAM5kAAGb//2b/ zGb/mWb/Zmb/M2b/AGbM/2bMzGbMmWbMZmbMM2bMAGaZ/2aZzGaZmWaZZmaZM2aZAGZm/2ZmzGZm mWZmZmZmM2ZmAGYz/2YzzGYzmWYzZmYzM2YzAGYA/2YAzGYAmWYAZmYAM2YAADP//zP/zDP/mTP/ ZjP/MzP/ADPM/zPMzDPMmTPMZjPMMzPMADOZ/zOZzDOZmTOZZjOZMzOZADNm/zNmzDNmmTNmZjNm MzNmADMz/zMzzDMzmTMzZjMzMzMzADMA/zMAzDMAmTMAZjMAMzMAAAD//wD/zAD/mQD/ZgD/MwD/ AADM/wDMzADMmQDMZgDMMwDMAACZ/wCZzACZmQCZZgCZMwCZAABm/wBmzABmmQBmZgBmMwBmAAAz /wAzzAAzmQAzZgAzMwAzAAAA/wAAzAAAmQAAZgAAMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAFAAUAEAIQwBJCBxI sKBBAAgTKlyYUCDDhwsdQpwoceLDihYjksh4cSNHjR9BhmzocSQAjCFRflTJkWVGlxZhUiw5UiZE gzhzBgQAOw== ------=_NextPart_000_000B_01C043FA.24D75270-- From owner-mpls@UU.NET Tue Oct 31 22:20:43 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10222 for ; Tue, 31 Oct 2000 22:20:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjnjh17009; Wed, 1 Nov 2000 03:20:23 GMT Received: by mail-control.mail.uu.net id QQjnjh20062 for mpls-outgoing; Wed, 1 Nov 2000 03:20:02 GMT Received: from ashimr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: ashimr0.ash.ops.us.uu.net [153.39.43.11]) id QQjnjh20047 for ; Wed, 1 Nov 2000 03:19:59 GMT Received: from cmr1.ash.ops.us.uu.net by ashimr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjnjh24382 for ; Wed, 1 Nov 2000 03:19:50 GMT Received: from fridge.docomo-usa.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.98.102.228]) id QQjnjh10083 for ; Wed, 1 Nov 2000 03:19:49 GMT Received: from NTTD2GMTPW5TAN (dhcp24.docomo-usa.com [172.21.96.24]) by fridge.docomo-usa.com (Postfix) with SMTP id 5726A7F801; Tue, 31 Oct 2000 19:21:35 -0800 (PST) Message-ID: <001701c043b2$804921d0$186015ac@NTTD2GMTPW5TAN> From: "Johnny Matta" To: Cc: Subject: Integration of Mobile IP and MPLS - Issues and Current Work Date: Tue, 31 Oct 2000 19:19:10 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C0436F.7219ACD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0436F.7219ACD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, This is to ask for references on the integration of Mobile IP and MPLS = in terms of analysis of issues and current work. Has there been more = documents besides the draft "Integration of Mobile IP and MPLS" = ? Thank you. Johnny M MATTA Research Engineer DoCoMo Communications Laboratories USA, Inc. Email: matta@dcl.docomo-usa.com Phone: 1-408-451-4727 Fax: 1-408-573-1090 181 Metro Drive Suite 300 San Jose, CA 95110 ------=_NextPart_000_0014_01C0436F.7219ACD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
This is to ask for references on the = integration of=20 Mobile IP and MPLS in terms of analysis of issues and current work. Has = there=20 been more documents besides the draft "Integration of Mobile IP and MPLS"=20 <draft-zhong-mobile-ip-mpls-01.txt>?
 
Thank you.
 
Johnny M MATTA
Research = Engineer
DoCoMo=20 Communications Laboratories USA, Inc.
Email: matta@dcl.docomo-usa.com
Phone:=20 1-408-451-4727
Fax: 1-408-573-1090
181 Metro Drive Suite = 300
San Jose,=20 CA 95110
------=_NextPart_000_0014_01C0436F.7219ACD0--