From owner-mpls@UU.NET Fri Nov 1 02:16:48 2002 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 ESMTP id CAA10276 for ; Fri, 1 Nov 2002 02:16:48 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnbh21751 for ; Fri, 1 Nov 2002 07:19:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnbh20838; Fri, 1 Nov 2002 07:18:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnbh16835 for mpls-outgoing; Fri, 1 Nov 2002 07:18:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnbh16830 for ; Fri, 1 Nov 2002 07:18:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnbh16657 for ; Fri, 1 Nov 2002 07:18:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnbh08994 for ; Fri, 1 Nov 2002 07:18:10 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnnbh08987 for ; Fri, 1 Nov 2002 07:18:10 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA17I2810612; Fri, 1 Nov 2002 02:18:02 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 02:18:03 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05D80177@zcard031.ca.nortel.com> From: "David Allan" To: Kireeti Kompella Cc: mpls@UU.NET Subject: RE: RE: Latest MPLS Ping draft... Date: Fri, 1 Nov 2002 02:18:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28176.D095359E" 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_01C28176.D095359E Content-Type: text/plain; charset="iso-8859-1" Hi Kireeti: Don't know if we closed on a few items...or just got busy ;-) 1) TTL decrements to zero - if LSP ping not on top label (uniform model), discard message (Y/N) 2) Sequence number - repeated issue of same or always monotonically increase 3) Definition of FEC - if different from MPLSARCH then define? cheers Dave ------_=_NextPart_001_01C28176.D095359E Content-Type: text/html; charset="iso-8859-1" RE: RE: Latest MPLS Ping draft...

Hi Kireeti:

Don't know if we closed on a few items...or just got busy ;-)

1) TTL decrements to zero - if LSP ping not on top label (uniform model), discard message (Y/N)

2) Sequence number - repeated issue of same or always monotonically increase

3) Definition of FEC - if different from MPLSARCH then define?

cheers
Dave

------_=_NextPart_001_01C28176.D095359E-- From owner-mpls@UU.NET Fri Nov 1 02:34:32 2002 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 ESMTP id CAA10496 for ; Fri, 1 Nov 2002 02:34:32 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnbi21006 for ; Fri, 1 Nov 2002 07:36:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnbi19486; Fri, 1 Nov 2002 07:36:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnbi17887 for mpls-outgoing; Fri, 1 Nov 2002 07:35:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnbi17882 for ; Fri, 1 Nov 2002 07:35:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnbi25792 for ; Fri, 1 Nov 2002 07:35:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnbi06640 for ; Fri, 1 Nov 2002 07:35:21 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnnbi06630 for ; Fri, 1 Nov 2002 07:35:21 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA17Z3d25499; Fri, 1 Nov 2002 02:35:03 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Nov 2002 02:35:04 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05D80179@zcard031.ca.nortel.com> From: "David Allan" To: Kireeti Kompella Cc: mpls@UU.NET Subject: RESEND: RE: Latest MPLS Ping draft... Date: Fri, 1 Nov 2002 02:35:01 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Resend: apologies for last formatting Hi Kireeti: Don't know if we closed on a few items...or just got busy ;-) 1) TTL decrements to zero - if LSP ping not on top label (uniform model), discard message (Y/N) 2) Sequence number - repeated issue of same or always monotonically increase 3) Definition of FEC - if different from MPLSARCH then define? cheers Dave From owner-mpls@UU.NET Fri Nov 1 09:48:24 2002 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 ESMTP id JAA12859 for ; Fri, 1 Nov 2002 09:48:23 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnncl29945 for ; Fri, 1 Nov 2002 14:50:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnncl28106; Fri, 1 Nov 2002 14:49:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnncl16639 for mpls-outgoing; Fri, 1 Nov 2002 14:49:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnncl16632 for ; Fri, 1 Nov 2002 14:49:10 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 QQnncl08085 for ; Fri, 1 Nov 2002 14:49:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnncl09386 for ; Fri, 1 Nov 2002 14:49:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnncl09378 for ; Fri, 1 Nov 2002 14:49:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA27621 for ; Fri, 1 Nov 2002 09:49:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA1En2k11612 for mpls@uu.net; Fri, 1 Nov 2002 09:49:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnncl16556 for ; Fri, 1 Nov 2002 14:47:54 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 QQnncl00757 for ; Fri, 1 Nov 2002 14:46:49 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnncl07407 for ; Fri, 1 Nov 2002 14:46:48 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 QQnncl07399 for ; Fri, 1 Nov 2002 14:46:48 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA1El0bV019479; Fri, 1 Nov 2002 09:47:00 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn1-34.cisco.com [10.86.240.34]) by bucket.cisco.com (Mirapoint) with ESMTP id ACA97551; Fri, 1 Nov 2002 09:46:43 -0500 (EST) Message-Id: <4.3.2.7.2.20021101094249.03164288@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Nov 2002 09:46:40 -0500 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: LSP Ping Draft Comment/Question Cc: Kireeti Kompella , swallow@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, One question about the LSP Ping draft after reading it again yesterday. It appears that implementation of all of the different modes of operation are mandatory, since there is no mention of minimum level(s) of implementation for conformance with the standard. I personally do not feel that it is a good idea to require that the entire draft be implemented to comply, since some of the alternate modes of operation might either not be supported by certain devices, or simply too much work to implement for some time for a vendor. --Tom Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Sat Nov 2 10:34:46 2002 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 ESMTP id KAA07303 for ; Sat, 2 Nov 2002 10:34:46 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnngg28643 for ; Sat, 2 Nov 2002 15:37:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnngg27811; Sat, 2 Nov 2002 15:36:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnngg02825 for mpls-outgoing; Sat, 2 Nov 2002 15:36:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnngg02808 for ; Sat, 2 Nov 2002 15:36:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnngg23821 for ; Sat, 2 Nov 2002 15:36:05 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnngg27523 for ; Sat, 2 Nov 2002 15:36:05 GMT Received: from granger.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: granger.mail.mindspring.net [207.69.200.148]) id QQnngg27519 for ; Sat, 2 Nov 2002 15:36:05 GMT Received: from dialup-63.214.103.60.dial1.boston1.level3.net ([63.214.103.60] helo=jluciani-laptop) by granger.mail.mindspring.net with smtp (Exim 3.33 #1) id 1880Ja-0004d8-00; Sat, 02 Nov 2002 10:35:58 -0500 Message-Id: <3.0.1.32.20021102104423.006d5a8c@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 02 Nov 2002 10:44:23 -0500 To: Neil Jerram , "'hans@ipunplugged.com'" , jcucchiara@mindspring.com, james_luciani@mindspring.com Subject: Re: Questions on LDP MIB v9 Cc: "'mpls@uu.net'" In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F817F260@baker.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi Neil, At 03:32 PM 10/30/02 -0000, Neil Jerram wrote: >>>> ArialThe latest LDP MIB draft looks generally good, but I see three problems with the new mplsLdpLspTable, which could be genuine, or could indicate misunderstanding on my part -- so I would appreciate your thoughts on them. I also have one question. Arial1. It isn't possible to represent an egress or transit LSP (A) at the same time as an ingress LSP (B), if LSP A's incoming (interface, label) are the same as LSP B's outgoing (interface, label), because the index in both cases is the same: (i1, l1). The old XCMapTable could represent both at the same time, using indices (i1, l1, 0, 0) or (i1, l1, i2, l2) for LSP A and (0, 0, i1, l1) for LSP B. <<<<<<<< I agree that the XCMap Table was a little bit nicer because it gave the Lib IN and LIB Out info as part of the index (which could possibly help in LIB lookups). However, this is also duplicated information because it exists in the LSR-MIB's XCTable. One of the primary concerns from the IESG review was to reduce the number of objects in the LDP MIB because it is such a huge MIB. All 3 of the Mapping tables were collapsed into this one table which simply lists the LSPs (by IfIndex, Label) within each Session (represented by mplsLdpEntityLdpId, mplsLdpEntityIndex, and mplsLdpPeerLdpId). The Mapping to the LSR MIB is done by using Row Pointers. So, this increases the burden on the agent to now retrieve the info from the LSR MIB to get label in/out indices. The mplsLdpLspType was added to give a hint as to the type of LSP, terminating, originating or XC, so that the appropriate RowPointer could be retrieved. >>>> Arial2. There is no mplsLdpLspType value to indicate a liberally retained label. <<<<<<<< This is a configurable option for the Entity, mplsLdpEntityLabelRetentionMode. So although it is true that it is not defined on a per Lsp basis, it is defined for the session. >>>> Arial3. In the description mplsLdpLspType, your uses of "ingress" and "egress" (as verbs describing the LSP's relationship to the LSR) are exactly opposite to the conventional usage (which describes a data packet's relationship to an LSP). This could be rather confusing! <<<<<<<< I agree! Will be fixed in the TC MIB's description and LDP MIB's description. >>>> Arial4. Do you expect implicit and explicit null labels to appear in this table, and, if so, how? The point is that implicit and explicit null labels can be distributed multiple times for different FECs in the same session, and it isn't clear in this case how the MIB indexing will work. <<<<<<<< Good question. Would the ifIndex be different in this case? The goal would be to have this table be able to list all LDP LSPs uniquely and then have pointers to their counter-parts in the LSR-MIB's InSegment/OutSegment/XC tables. Thanks for your questions, -Joan >>>> ArialBest regards, ArialNeil ArialNeil Jerram Network Protocols Group Data Connection Ltd. <www.dataconnection.com <<<<<<<< From owner-mpls@UU.NET Sun Nov 3 10:58:08 2002 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 ESMTP id KAA09004 for ; Sun, 3 Nov 2002 10:58:08 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnka01197 for ; Sun, 3 Nov 2002 16:00:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnka00229; Sun, 3 Nov 2002 16:00:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnjz00337 for mpls-outgoing; Sun, 3 Nov 2002 15:59:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnjz00332 for ; Sun, 3 Nov 2002 15:59:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnjz09438 for ; Sun, 3 Nov 2002 15:58:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnjz17140 for ; Sun, 3 Nov 2002 15:58:40 GMT Received: from blooper.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnnjz17129 for ; Sun, 3 Nov 2002 15:58:40 GMT Received: from utfors.se ([195.58.105.130]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id gA3FwF28013261; Sun, 3 Nov 2002 16:58:15 +0100 (MET) Message-ID: <3DC54798.5050806@utfors.se> Date: Sun, 03 Nov 2002 10:58:16 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg CC: Scott Bradner , George Swallow , Bert Wijnen Subject: mpls wg document status - update Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, at the last IESG meeting "a pile of mpls docs were discussed". This is a short update on doc status. We have five new documents approved for publishing as proposed standard And one as an informational RFC draft-ietf-mpls-recovery-frmwrk-08.txt All the documents will shortly show up on the RFC-editors queue. Please join us in congratulating all the authors who have done a great job! One document were returned to the working group to be coordinated with a parallel work in the idr wg Contact has been taken with idr wg chair to see if there is anything that needs/could to be done from the mpls to speed up the process. One document were returned to the authors (i.e. the mpls wg chairs :) ) for "word tweaking". Plan to "tweak" tomorrow, and hopefully the doc is back on the IESG agenda shortly. Further information at: http://urax.utfors.net/~loa/MPLS_WG_Drafts.htm Loa and George. -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Sun Nov 3 21:55:57 2002 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 ESMTP id VAA20174 for ; Sun, 3 Nov 2002 21:55:57 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnlr28700 for ; Mon, 4 Nov 2002 02:58:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnlr27348; Mon, 4 Nov 2002 02:57:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnlr24270 for mpls-outgoing; Mon, 4 Nov 2002 02:57:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnlr24265 for ; Mon, 4 Nov 2002 02:57: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 QQnnlr14961 for ; Mon, 4 Nov 2002 02:56:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnlr26545 for ; Mon, 4 Nov 2002 02:56:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnlr26521 for ; Mon, 4 Nov 2002 02:56:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA29644 for ; Sun, 3 Nov 2002 21:56:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA42u2F24648 for mpls@uu.net; Sun, 3 Nov 2002 21:56:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnlr24029 for ; Mon, 4 Nov 2002 02:54: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 QQnnlr08988 for ; Mon, 4 Nov 2002 02:53:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnlr10536 for ; Mon, 4 Nov 2002 02:53:53 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 QQnnlr10532 for ; Mon, 4 Nov 2002 02:53:53 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA42rlJK009362; Sun, 3 Nov 2002 21:53:48 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn2-22.cisco.com [10.86.244.22]) by bucket.cisco.com (Mirapoint) with ESMTP id ACB18264; Sun, 3 Nov 2002 21:53:30 -0500 (EST) Message-Id: <4.3.2.7.2.20021103214743.0319db00@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 03 Nov 2002 21:53:27 -0500 To: "Yuan Gu" From: "Thomas D. Nadeau" Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Cc: , , , , , "mpls group" In-Reply-To: References: <3.0.1.32.20021017164954.007170f0@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > >Although, it may be necessary to clarify this a tad, I don't > >believe there is a conflict. Perhaps, this description > >should simply state: > >For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. > >Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two >bytes LSPID can't identify an unique LSP. Don't need to mention transit >node, even within single ingress node it's not unique right? The MPLS-LSR MIB has to (and does) work for all existing applications of MPLS. Because of this there may be overlaps between the application-specific MIBs so that the MIB can work on its own. My recollection is that this is probably one of the only cases of that. In defense of the redundant information, this information is useful on LSRs where the MPLS-TE MIB might not be implemented since one can still see the LSP for the tunnel. --Tom Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Mon Nov 4 08:32:45 2002 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 ESMTP id IAA12140 for ; Mon, 4 Nov 2002 08:32:42 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnnh12788 for ; Mon, 4 Nov 2002 13:16:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnnh11510; Mon, 4 Nov 2002 13:15:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnnh14524 for mpls-outgoing; Mon, 4 Nov 2002 13:15:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnnh14519 for ; Mon, 4 Nov 2002 13:15:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnnh08820 for ; Mon, 4 Nov 2002 13:15:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnnh10647 for ; Mon, 4 Nov 2002 13:15:05 GMT Received: from auemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQnnnh10636 for ; Mon, 4 Nov 2002 13:15:05 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA4DF3E08212 for ; Mon, 4 Nov 2002 08:15:03 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Nov 2002 14:15:02 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: Loa Andersson , "MPLS wg (E-mail)" Cc: Scott Bradner , George Swallow , Bert Wijnen Subject: RE: mpls wg document status - update Date: Mon, 4 Nov 2002 14:14:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 IAA12140 Loa, I am really impressed with your efforts to keep us (ADs) and the WG so well informed of the status of documents in the WG. I wish all WG chairs did such a fantastic job. Thanks, Bert > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: zondag 3 november 2002 16:58 > To: MPLS wg > Cc: Scott Bradner; George Swallow; Bert Wijnen > Subject: mpls wg document status - update > > > All, > > at the last IESG meeting "a pile of mpls docs were discussed". This > is a short update on doc status. > > We have five new documents approved for publishing as > proposed standard > > > > > > > And one as an informational RFC > draft-ietf-mpls-recovery-frmwrk-08.txt > > All the documents will shortly show up on the RFC-editors queue. > > Please join us in congratulating all the authors who have done > a great job! > > One document were returned to the working group to be coordinated > with a parallel work in the idr wg > > > > Contact has been taken with idr wg chair to see if there is anything > that needs/could to be done from the mpls to speed up the process. > > One document were returned to the authors (i.e. the mpls wg > chairs :) ) > for "word tweaking". > > > > Plan to "tweak" tomorrow, and hopefully the doc is back on the IESG > agenda shortly. > > Further information at: > > http://urax.utfors.net/~loa/MPLS_WG_Drafts.htm > > Loa and George. > > > -- > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > Råsundavägen 12 > Box 525, 169 29 Solna > Office +46 8 5270 2000 > Office direct +46 8 5270 5038 > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > WWW www.utfors.se > > From owner-mpls@UU.NET Mon Nov 4 10:12:04 2002 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 ESMTP id KAA17180 for ; Mon, 4 Nov 2002 10:12:04 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnno00030 for ; Mon, 4 Nov 2002 15:14:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnno28442; Mon, 4 Nov 2002 15:13:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnno27136 for mpls-outgoing; Mon, 4 Nov 2002 15:13:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnno27123 for ; Mon, 4 Nov 2002 15:13: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 QQnnno28716 for ; Mon, 4 Nov 2002 15:13:01 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnno27655 for ; Mon, 4 Nov 2002 15:13:00 GMT Received: from blooper.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnnno27548 for ; Mon, 4 Nov 2002 15:12:54 GMT Received: from utfors.se ([195.58.105.86]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id gA4FCl28024311; Mon, 4 Nov 2002 16:12:47 +0100 (MET) Message-ID: <3DC68E70.6090008@utfors.se> Date: Mon, 04 Nov 2002 16:12:48 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@merit.edu, MPLS wg Subject: Last Call: draft-ietf-mpls-bgp-mpls-restart-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit idr working group, (mpls wg copied for information) this is to initiate a last call on The last call has been requested by the ADs and OKed by idr wg chairs. The draft is a product of the mpls working group. In some scenarios BGP is used a the Label Distribution Protocol. A mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart is described in "Graceful Restart Mechanism for BGP" . extends this mechanism to also minimize the negative effects on MPLS forwarding caused by a restart of BGP when BGP is used to carry MPLS labels and the LSR (Label Switching Router) is capable of preserving the MPLS forwarding state across the restart. Since the IETF meeting is upcoming and this is normally busy weeks, this last call ends November 29th 5 PM EST. /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Mon Nov 4 13:18:24 2002 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 ESMTP id NAA26809 for ; Mon, 4 Nov 2002 13:18:24 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnob02310 for ; Mon, 4 Nov 2002 18:20:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnob00877; Mon, 4 Nov 2002 18:20:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnob01173 for mpls-outgoing; Mon, 4 Nov 2002 18:19:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnob01164 for ; Mon, 4 Nov 2002 18:19:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnob10009 for ; Mon, 4 Nov 2002 18:18:40 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnob01676 for ; Mon, 4 Nov 2002 18:18:39 GMT Received: from auds951.usa.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auds951.usa.alcatel.com [143.209.238.80]) id QQnnob01670 for ; Mon, 4 Nov 2002 18:18:39 GMT Received: from morgoth.pet.usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id gA4IIcp24521 for ; Mon, 4 Nov 2002 12:18:38 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by morgoth.pet.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id gA4IJ6G07717 for ; Mon, 4 Nov 2002 10:19:06 -0800 (PST) Message-ID: <3DC6B9FC.DF6F39FD@alcatel.com> Date: Mon, 04 Nov 2002 10:18:36 -0800 From: Mudhafar Hassan-Ali Organization: Alcatel, USA X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: MPLS wg Subject: MPLS LSP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can any one help me answer these questions: Would LSRs process IP frames that don't have MPLS shim header? Imagine there are two edge LSRs (LER -A and LER-B) using an LSP, is it possible for another router (non-MPLS) to send frames (using the IP address used in this LSP, say LER-A's)? If so, is possible to have denial of service over this LSP? Thank, Mudhafar From owner-mpls@UU.NET Mon Nov 4 13:33:07 2002 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 ESMTP id NAA27676 for ; Mon, 4 Nov 2002 13:33:07 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoc18003 for ; Mon, 4 Nov 2002 18:35:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnoc16350; Mon, 4 Nov 2002 18:34:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnoc02152 for mpls-outgoing; Mon, 4 Nov 2002 18:34:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnoc02143 for ; Mon, 4 Nov 2002 18:34:20 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 QQnnoc15368 for ; Mon, 4 Nov 2002 18:32:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoc16897 for ; Mon, 4 Nov 2002 18:32:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnoc16891 for ; Mon, 4 Nov 2002 18:32:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA18710 for ; Mon, 4 Nov 2002 13:32:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA4IW2K09740 for mpls@uu.net; Mon, 4 Nov 2002 13:32:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnoc01994 for ; Mon, 4 Nov 2002 18:30: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 QQnnoc10365 for ; Mon, 4 Nov 2002 18:30:40 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoc11216 for ; Mon, 4 Nov 2002 18:30:39 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 QQnnoc11154 for ; Mon, 4 Nov 2002 18:30:34 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27386; Mon, 4 Nov 2002 13:28:05 -0500 (EST) Message-Id: <200211041828.NAA27386@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Protocol Action: Graceful Restart Mechanism for LDP to Proposed Standard Date: Mon, 04 Nov 2002 13:28:04 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'Graceful Restart Mechanism for LDP' as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Scott Bradner and Bert Wijnen. Technical Summary This document describes a mechanism that helps minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter need to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. Working Group Summary The mpls working group supported publication of this document. Protocol Quality This document was reviewed for the IESG by Scott Bradner. From owner-mpls@UU.NET Mon Nov 4 13:34:58 2002 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 ESMTP id NAA27774 for ; Mon, 4 Nov 2002 13:34:58 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoc19384 for ; Mon, 4 Nov 2002 18:37:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnoc18008; Mon, 4 Nov 2002 18:36:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnoc02253 for mpls-outgoing; Mon, 4 Nov 2002 18:36:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnoc02211 for ; Mon, 4 Nov 2002 18:35:57 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 QQnnoc22547 for ; Mon, 4 Nov 2002 18:34:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoc18888 for ; Mon, 4 Nov 2002 18:34:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnoc18879 for ; Mon, 4 Nov 2002 18:34:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA18872 for ; Mon, 4 Nov 2002 13:34:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA4IY1b09825 for mpls@uu.net; Mon, 4 Nov 2002 13:34:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnoc02073 for ; Mon, 4 Nov 2002 18:32:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnoc29888 for ; Mon, 4 Nov 2002 18:31:34 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoc12068 for ; Mon, 4 Nov 2002 18:31:33 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 QQnnoc12051 for ; Mon, 4 Nov 2002 18:31:33 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27449; Mon, 4 Nov 2002 13:28:59 -0500 (EST) Message-Id: <200211041828.NAA27449@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Protocol Action: LSP Hierarchy with Generalized MPLS TE to Proposed Standard Date: Mon, 04 Nov 2002 13:28:59 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft LSP Hierarchy with Generalized MPLS TE as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. Technical Summary This document describes the mechanisms to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. These mechanisms can be used to improve scalability of Generalized Multi-Protocol Label Switching (GMPLS). Such a hierarchy can be created by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). Working Group Summary The MPLS working group supported publication of this document. Protocol Quality This document was reviewed for the IESG by Scott Bradner. From owner-mpls@UU.NET Mon Nov 4 14:04:32 2002 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 ESMTP id OAA29554 for ; Mon, 4 Nov 2002 14:04:32 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoe17137 for ; Mon, 4 Nov 2002 19:06:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnoe14299; Mon, 4 Nov 2002 19:05:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnoe20700 for mpls-outgoing; Mon, 4 Nov 2002 19:04:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnoe20386 for ; Mon, 4 Nov 2002 19:04:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnoe13237 for ; Mon, 4 Nov 2002 19:04:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoe13442 for ; Mon, 4 Nov 2002 19:04:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnoe13431 for ; Mon, 4 Nov 2002 19:04:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA21998 for ; Mon, 4 Nov 2002 14:04:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA4J41813387 for mpls@uu.net; Mon, 4 Nov 2002 14:04:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnoe15148 for ; Mon, 4 Nov 2002 19:03:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnoe10082 for ; Mon, 4 Nov 2002 19:02:44 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoe12348 for ; Mon, 4 Nov 2002 19:02:44 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 QQnnoe12334 for ; Mon, 4 Nov 2002 19:02:43 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA4J2w6X027181; Mon, 4 Nov 2002 14:02:59 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn2-22.cisco.com [10.86.244.22]) by bucket.cisco.com (Mirapoint) with ESMTP id ACB27704; Mon, 4 Nov 2002 14:02:41 -0500 (EST) Message-Id: <4.3.2.7.2.20021104140207.03432230@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Nov 2002 14:02:38 -0500 To: "Yuan Gu" From: "Thomas D. Nadeau" Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 08:24 AM 11/4/2002 -0500, Yuan Gu wrote: >>-----Original Message----- >>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas D. >>Nadeau >>Sent: Sunday, November 03, 2002 6:53 PM >>To: Yuan Gu >>Cc: jcucchiara@mindspring.com; jcucchiara@crescentnetworks.com; >>cheenu@paramanet.com; arun@force10networks.com; hans@ipunplugged.com; >>mpls group >>Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt >> >> >> >> > >Although, it may be necessary to clarify this a tad, I don't >> > >believe there is a conflict. Perhaps, this description >> > >should simply state: >> > >For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. >> > >> >Then for RSVP-TE, what's the sense to define LSP ID in XC table? This two >> >bytes LSPID can't identify an unique LSP. Don't need to mention transit >> >node, even within single ingress node it's not unique right? >> >> The MPLS-LSR MIB has to (and does) work for all existing >>applications of MPLS. Because of this there may be overlaps between >>the application-specific MIBs so that the MIB can work on its >>own. My recollection is that this is probably one of the only cases of >>that. In defense of the redundant information, this information is >>useful on LSRs where the MPLS-TE MIB might not be implemented >>since one can still see the LSP for the tunnel. >> >> --Tom > >Tom: > >I agree with you. What I suggested is that use multiple fields ( >ingressid+(extended ingress id)+egressid+tunnelid+lspid) to identify a >RSVP-TE LSP instead of only 2 bytes LSPID in MPLS-TC mib. Please refer my >early emails to Joan. What do you propose we do in cases where the LSP is not a TE LSP? --Tom Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Mon Nov 4 14:25:47 2002 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 ESMTP id OAA00830 for ; Mon, 4 Nov 2002 14:25:46 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnof02618 for ; Mon, 4 Nov 2002 19:28:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnof01405; Mon, 4 Nov 2002 19:27:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnof23884 for mpls-outgoing; Mon, 4 Nov 2002 19:27:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnof23879 for ; Mon, 4 Nov 2002 19:27: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 QQnnof16596 for ; Mon, 4 Nov 2002 19:27:19 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnof07199 for ; Mon, 4 Nov 2002 19:27:19 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnnof07176 for ; Mon, 4 Nov 2002 19:27:18 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA4JREm31023 for ; Mon, 4 Nov 2002 11:27:18 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gA4JRAR10225 for ; Mon, 4 Nov 2002 11:27:14 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 4 Nov 2002 11:27:10 -0800 (PST) From: Kireeti Kompella To: Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-Reply-To: <200211010058.gA10wQm04088@merlot.juniper.net> Message-ID: <20021104110215.J10006-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I'd like to re-iterate Der-Hwa's question: On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > It is perhaps more appropriate to ask what is the technical reason that a > new ID is required to get bandwidth decrease? Is there a technical reason that someone can articulate? Along the same lines, is make-before-break needed on bandwidth *decrease*? Thanks, Kireeti. From owner-mpls@UU.NET Mon Nov 4 19:26:25 2002 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 ESMTP id TAA16090 for ; Mon, 4 Nov 2002 19:26:24 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoz25411 for ; Tue, 5 Nov 2002 00:28:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnoz24728; Tue, 5 Nov 2002 00:28:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnoz10592 for mpls-outgoing; Tue, 5 Nov 2002 00:28:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnoz10587 for ; Tue, 5 Nov 2002 00:28:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnoz17648 for ; Tue, 5 Nov 2002 00:27:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnoz23668 for ; Tue, 5 Nov 2002 00:27:14 GMT Received: from mgw.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.88.104.199]) id QQnnoz23659 for ; Tue, 5 Nov 2002 00:27:14 GMT Received: from imchub1.cosinecom.com (imchub1.cosinecom.com [172.21.8.23]) by mgw.cosinecom.com (Mirapoint) with ESMTP id ABX60954; Mon, 4 Nov 2002 16:27:13 -0800 (PST) Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2655.55) id ; Mon, 4 Nov 2002 16:27:14 -0800 Message-ID: <9F92A36A29DA854785B3ECCD75D04ABC77993D@exchsrv3.cosinecom.com> From: Francois Lemarchand To: "'Kireeti Kompella'" , mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Mon, 4 Nov 2002 16:27:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28462.11C06C80" 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_01C28462.11C06C80 Content-Type: text/plain; charset="iso-8859-1" Hello ! For re-optimisation I guess. If there is a need to change the path when bandwidth increase then it's probably usefull to return to the old path when bandwidth decrease (probably more optimal). So changing path probably justify make-before-break and LSP-ID change. Did I miss somthing ? Francois -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: lundi 4 novembre 2002 20:27 To: mpls@UU.NET Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Hi All, I'd like to re-iterate Der-Hwa's question: On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > It is perhaps more appropriate to ask what is the technical reason that a > new ID is required to get bandwidth decrease? Is there a technical reason that someone can articulate? Along the same lines, is make-before-break needed on bandwidth *decrease*? Thanks, Kireeti. ------_=_NextPart_001_01C28462.11C06C80 Content-Type: text/html; charset="iso-8859-1" RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)

Hello !

For re-optimisation I guess. If there is a need to change
the path when bandwidth increase then it's probably usefull
to return to the old path when bandwidth decrease (probably
more optimal).

So changing path probably justify make-before-break and
LSP-ID change.

Did I miss somthing ?

Francois

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: lundi 4 novembre 2002 20:27
To: mpls@UU.NET
Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)



Hi All,

I'd like to re-iterate Der-Hwa's question:

On Thu, 31 Oct 2002, Der-Hwa Gan wrote:

> It is perhaps more appropriate to ask what is the technical reason that a
> new ID is required to get bandwidth decrease?

Is there a technical reason that someone can articulate?  Along the
same lines, is make-before-break needed on bandwidth *decrease*?

Thanks,
Kireeti.

------_=_NextPart_001_01C28462.11C06C80-- From owner-mpls@UU.NET Tue Nov 5 01:14:48 2002 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 ESMTP id BAA25135 for ; Tue, 5 Nov 2002 01:14:48 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnpx24731 for ; Tue, 5 Nov 2002 06:17:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnpx23232; Tue, 5 Nov 2002 06:16:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnpx17929 for mpls-outgoing; Tue, 5 Nov 2002 06:15:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnpx17924 for ; Tue, 5 Nov 2002 06:15:47 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 QQnnpx08585 for ; Tue, 5 Nov 2002 06:15:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnpx21242 for ; Tue, 5 Nov 2002 06:15:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnpx21137 for ; Tue, 5 Nov 2002 06:15:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA05735 for ; Tue, 5 Nov 2002 01:15:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA56F2m17702 for mpls@uu.net; Tue, 5 Nov 2002 01:15:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnpw17640 for ; Tue, 5 Nov 2002 06:14: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 QQnnpw03850 for ; Tue, 5 Nov 2002 06:13:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnpw19990 for ; Tue, 5 Nov 2002 06:13:41 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnnpw19972 for ; Tue, 5 Nov 2002 06:13:41 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 BAA99884; Tue, 5 Nov 2002 01:11:42 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200211050611.BAA99884@workhorse.fictitious.org> To: Kireeti Kompella cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of "Mon, 04 Nov 2002 11:27:10 PST." <20021104110215.J10006-100000@kummer.juniper.net> Date: Tue, 05 Nov 2002 01:11:41 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021104110215.J10006-100000@kummer.juniper.net>, Kireeti Kompella writes: > Hi All, > > I'd like to re-iterate Der-Hwa's question: > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > > > It is perhaps more appropriate to ask what is the technical reason that a > > new ID is required to get bandwidth decrease? > > Is there a technical reason that someone can articulate? Along the > same lines, is make-before-break needed on bandwidth *decrease*? > > Thanks, > Kireeti. Does interoperating with a major router vendor (which is neither Juniper or Avici) qualify as technical? After all, this is the IETF so improving interoperability must count for something. Right? If not, then I can't think of any reason to increment the LSP-ID and if you don't change the LSP-ID, then you don't need to do make-before-break. OTOH - Do you see any reason to NOT increment the ID and do make-before-break. If you do so you interoperate with the major router vendors (Juniper, Avici, others which do either one right, plus one which seems to be in denial about their router not handling bandwidth decrease reliably). We do the latter (change the LSP-ID and do make-before-break) and I think it is a better strategy because no major router can't handle that case. The only thing besides improved interoperability that borders on a technical reason is that the same mechanism is then used for both bandwidth increase and decrease. Curtis From owner-mpls@UU.NET Tue Nov 5 09:00:45 2002 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 ESMTP id JAA18905 for ; Tue, 5 Nov 2002 09:00:45 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnrc00537 for ; Tue, 5 Nov 2002 14:03:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnrc28974; Tue, 5 Nov 2002 14:02:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnrc27383 for mpls-outgoing; Tue, 5 Nov 2002 14:02:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnrc27282 for ; Tue, 5 Nov 2002 14:02:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnrc10385 for ; Tue, 5 Nov 2002 14:01:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnrc26794 for ; Tue, 5 Nov 2002 14:01:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnrc26778 for ; Tue, 5 Nov 2002 14:01:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA25385 for ; Tue, 5 Nov 2002 09:01:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA5E14x09662 for mpls@uu.net; Tue, 5 Nov 2002 09:01:04 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnrc21293 for ; Tue, 5 Nov 2002 14:00:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnrc21542 for ; Tue, 5 Nov 2002 14:00:20 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnrc26370 for ; Tue, 5 Nov 2002 14:00:19 GMT Received: from fido.nc.rr.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu57-1-013.nc.rr.com [66.57.1.13]) id QQnnrc26346 for ; Tue, 5 Nov 2002 14:00:18 GMT Received: from localhost (jboyle@localhost) by fido.nc.rr.com (8.11.2/8.11.2) with ESMTP id gA5DXIx10033; Tue, 5 Nov 2002 08:33:18 -0500 X-Authentication-Warning: fido.nc.rr.com: jboyle owned process doing -bs Date: Tue, 5 Nov 2002 08:33:18 -0500 (EST) From: Jim Boyle X-X-Sender: To: Francois Lemarchand cc: Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-Reply-To: <9F92A36A29DA854785B3ECCD75D04ABC77993D@exchsrv3.cosinecom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Yes, we all agree that as the spec states, when the path changes the LSP ID should be changed. The issue is that one implementation has issues if the LSP ID of a transit LSP does not change when the bandwidth decreases. Alternatively you could state that the issue is that one (or two) implementations are unique in that they don't change the LSP ID when they decrease the bandwidth. So the options at this point are: o) address the implementation with transit issue when bandwidth decreases and LSP ID is not changed. o) require LSP ID change during BW decrease in the spec and address the implementation(s) which currently don't do this. We've had a few people weigh in on both sides of this, so I'm not sure if there is any resolution. Jim On Mon, 4 Nov 2002, Francois Lemarchand wrote: > Hello ! > > For re-optimisation I guess. If there is a need to change > the path when bandwidth increase then it's probably usefull > to return to the old path when bandwidth decrease (probably > more optimal). > > So changing path probably justify make-before-break and > LSP-ID change. > > Did I miss somthing ? > > Francois > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: lundi 4 novembre 2002 20:27 > To: mpls@UU.NET > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > > > > Hi All, > > I'd like to re-iterate Der-Hwa's question: > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > > > It is perhaps more appropriate to ask what is the technical reason that a > > new ID is required to get bandwidth decrease? > > Is there a technical reason that someone can articulate? Along the > same lines, is make-before-break needed on bandwidth *decrease*? > > Thanks, > Kireeti. > From owner-mpls@UU.NET Tue Nov 5 09:49:25 2002 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 ESMTP id JAA21023 for ; Tue, 5 Nov 2002 09:49:25 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnrf22936 for ; Tue, 5 Nov 2002 14:51:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnrf21427; Tue, 5 Nov 2002 14:51:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnrf08788 for mpls-outgoing; Tue, 5 Nov 2002 14:51:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnrf08773 for ; Tue, 5 Nov 2002 14:50:53 GMT Received: from imr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnrf21239 for ; Tue, 5 Nov 2002 14:50:46 GMT Received: from uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: poseidon.corp.us.uu.net [153.39.143.89]) id QQnnrf21199; Tue, 5 Nov 2002 14:50:45 GMT Message-ID: <3DC7DAC5.343D4F2D@uu.net> Date: Tue, 05 Nov 2002 09:50:45 -0500 From: Blaine Christian Reply-To: blaine.christian@wcom.com X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jim Boyle CC: Francois Lemarchand , mpls@UU.NET Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Quite simply... If there is no agreement amongst what are considered the primary MPLS vendors then you HAVE to specify it in within the draft. So, all vendors should consent to allow for significant permutations or define in the RFC. The whole point of the IETF is to help prevent or resolve issues such as this. At this point the change in the RFC seems to be straightforward and vendor agreement to support the permutations does not appear to exist (yet). Jim, I think you could also argue that a third option exists. o) Require in the RFC that an LSP ID NOT change during BW decrease. Not that I like the third option but we should be fair in presenting it. Jim Boyle wrote: > > Yes, we all agree that as the spec states, when the path changes the LSP > ID should be changed. > > The issue is that one implementation has issues if the LSP ID of > a transit LSP does not change when the bandwidth decreases. Alternatively > you could state that the issue is that one (or two) implementations are > unique in that they don't change the LSP ID when they decrease the > bandwidth. > > So the options at this point are: > > o) address the implementation with transit issue when bandwidth decreases > and LSP ID is not changed. > > o) require LSP ID change during BW decrease in the spec and address the > implementation(s) which currently don't do this. > > We've had a few people weigh in on both sides of this, so I'm not sure > if there is any resolution. > > Jim > > On Mon, 4 Nov 2002, Francois Lemarchand wrote: > > > Hello ! > > > > For re-optimisation I guess. If there is a need to change > > the path when bandwidth increase then it's probably usefull > > to return to the old path when bandwidth decrease (probably > > more optimal). > > > > So changing path probably justify make-before-break and > > LSP-ID change. > > > > Did I miss somthing ? > > > > Francois > > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: lundi 4 novembre 2002 20:27 > > To: mpls@UU.NET > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > > > > > > > > Hi All, > > > > I'd like to re-iterate Der-Hwa's question: > > > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > > > > > It is perhaps more appropriate to ask what is the technical reason that a > > > new ID is required to get bandwidth decrease? > > > > Is there a technical reason that someone can articulate? Along the > > same lines, is make-before-break needed on bandwidth *decrease*? > > > > Thanks, > > Kireeti. > > From owner-mpls@UU.NET Tue Nov 5 15:47:08 2002 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 ESMTP id PAA13198 for ; Tue, 5 Nov 2002 15:47:07 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnsd24278 for ; Tue, 5 Nov 2002 20:49:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnsd22288; Tue, 5 Nov 2002 20:48:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnsd16580 for mpls-outgoing; Tue, 5 Nov 2002 20:47:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnsd16571 for ; Tue, 5 Nov 2002 20:47: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 QQnnsd01763 for ; Tue, 5 Nov 2002 20:47:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnsd29640 for ; Tue, 5 Nov 2002 20:47:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnsd29633 for ; Tue, 5 Nov 2002 20:47:08 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01677 for ; Tue, 5 Nov 2002 15:47:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA5Kl2700304 for mpls@uu.net; Tue, 5 Nov 2002 15:47:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnsd16291 for ; Tue, 5 Nov 2002 20:45: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 QQnnsd24955 for ; Tue, 5 Nov 2002 20:45:33 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnsd20042 for ; Tue, 5 Nov 2002 20:45:32 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnnsd20029 for ; Tue, 5 Nov 2002 20:45:32 GMT Received: from juniper.net (lookout.juniper.net [172.17.20.54]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA5KjES60644; Tue, 5 Nov 2002 12:45:14 -0800 (PST) (envelope-from dhg@juniper.net) Message-Id: <200211052045.gA5KjES60644@merlot.juniper.net> To: curtis@fictitious.org cc: Kireeti Kompella , mpls@UU.NET Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of 05 Nov 2002 06:11:41 +0000. <200211050611.BAA99884@workhorse.fictitious.org> Date: Tue, 05 Nov 2002 12:45:07 -0800 From: Der-Hwa Gan Sender: owner-mpls@UU.NET Precedence: bulk > > In message <20021104110215.J10006-100000@kummer.juniper.net>, Kireeti Kompell a > writes: > > Hi All, > > > > I'd like to re-iterate Der-Hwa's question: > > > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > > > > > It is perhaps more appropriate to ask what is the technical reason that a > > > new ID is required to get bandwidth decrease? > > > > Is there a technical reason that someone can articulate? Along the > > same lines, is make-before-break needed on bandwidth *decrease*? > > > > Thanks, > > Kireeti. > > > Does interoperating with a major router vendor (which is neither > Juniper or Avici) qualify as technical? After all, this is the IETF > so improving interoperability must count for something. Right? If > not, then I can't think of any reason to increment the LSP-ID and if > you don't change the LSP-ID, then you don't need to do > make-before-break. > > OTOH - Do you see any reason to NOT increment the ID and do > make-before-break. If you do so you interoperate with the major > router vendors (Juniper, Avici, others which do either one right, plus > one which seems to be in denial about their router not handling > bandwidth decrease reliably). Suppose the reservation style is FF, then incrementing the ID might cause b/w decrease action to fail, since make-before-break may run out of b/w at certain bottle-neck. We can argue that FF style isn't in wide spread use, but it isn't precluded from RSVP-TE framework so far. Thanks, Der-hwa > > We do the latter (change the LSP-ID and do make-before-break) and I > think it is a better strategy because no major router can't handle > that case. > > The only thing besides improved interoperability that borders on a > technical reason is that the same mechanism is then used for both > bandwidth increase and decrease. > > Curtis > From owner-mpls@UU.NET Tue Nov 5 18:17:31 2002 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 ESMTP id SAA24064 for ; Tue, 5 Nov 2002 18:17:31 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnsn00409 for ; Tue, 5 Nov 2002 23:19:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnsn28536; Tue, 5 Nov 2002 23:18:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnsn17788 for mpls-outgoing; Tue, 5 Nov 2002 23:18:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnsn17780 for ; Tue, 5 Nov 2002 23:18:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnsn19871 for ; Tue, 5 Nov 2002 23:18:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnsn02645 for ; Tue, 5 Nov 2002 23:18:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnsn02636 for ; Tue, 5 Nov 2002 23:18:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA13463 for ; Tue, 5 Nov 2002 18:18:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA5NI2Q08260; Tue, 5 Nov 2002 18:18:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnsn17712 for ; Tue, 5 Nov 2002 23:16: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 QQnnsn24097 for ; Tue, 5 Nov 2002 23:15:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnsn19945 for ; Tue, 5 Nov 2002 23:15:06 GMT Received: from uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [69.0.187.215]) id QQnnsn19934 for ; Tue, 5 Nov 2002 23:15:06 GMT Message-Id: To: ian@raman.almaden.ibm.com Reply-To: ian@raman.almaden.ibm.com From: ian@raman.almaden.ibm.com Subject: No. 1 Franchise Date: Tue, 05 Nov 2002 14:32:22 -080 Content-Type: text/html Sender: owner-mpls@UU.NET Precedence: bulk Hi Frank

 

 

 

No. 1 Franchise Investment Opportunity

Join the nation’s leading mobile media company.  Franchise opportunities are now available, potentially earn over $500,000 in their first year, while helping clients achieve their advertising goals. These clients include media giants like ABC, CBS and Fox; major fast food giants like McDonald’s, and mega corporations that include IBM, Smirnoff and Coca-Cola. You’ll also benefit from working with top advertisers in your area.

 Let’s share the success. We’re looking for dedicated, motivated individuals to grow with us. Realize your financial goals by helping us achieve ours. We want to “light up” the nation’s top 100 markets, and we hope you’ll be part of the excitement. It will put you a step closer to being in the driver’s seat of your own business.

Financial Assistance Available

Don't let this opportunity pass you by, Contact us Now, No obligation

Fill the form below or call 1.800.823.0044: 

To Unsubscribe CLICK HERE

 
Name
 Email
Street Address
City
 State
 Zip
Home Phone
 Work Phone

 

From owner-mpls@UU.NET Tue Nov 5 18:36:19 2002 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 ESMTP id SAA24789 for ; Tue, 5 Nov 2002 18:36:19 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnso09876 for ; Tue, 5 Nov 2002 23:38:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnso08639; Tue, 5 Nov 2002 23:38:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnso19285 for mpls-outgoing; Tue, 5 Nov 2002 23:37:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnso19276 for ; Tue, 5 Nov 2002 23:37:54 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 QQnnso03043 for ; Tue, 5 Nov 2002 23:37:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnso16033 for ; Tue, 5 Nov 2002 23:37:21 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnnso16023 for ; Tue, 5 Nov 2002 23:37:20 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LB4ACZL>; Tue, 5 Nov 2002 18:37:20 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EC63@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Der-Hwa Gan'" Cc: mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Tue, 5 Nov 2002 18:37:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Der-hwa, Here we have a trade-off between a small potential for simplification represented by using a symmetrical approach (the same approach used for increasing or decreasing the TE-LSP bandwidth) and the potential risk of not being able to make a new reservation with a lesser bandwidth in the unusual use of FF reservation style. Please tell me again why this is a hard choice? Note that - if we were using the FF reservation style and trying to increase the bandwidth - the problem would be worse because it would be both more likely to cause trouble and less likely to be remediable. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Der-Hwa Gan [mailto:dhg@juniper.net] > Sent: Tuesday, November 05, 2002 3:45 PM > To: curtis@fictitious.org > Cc: Kireeti Kompella; mpls@UU.NET > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > > > > > > In message <20021104110215.J10006-100000@kummer.juniper.net>, Kireeti > Kompell > a > > writes: > > > Hi All, > > > > > > I'd like to re-iterate Der-Hwa's question: > > > > > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > > > > > > > It is perhaps more appropriate to ask what is the technical reason > that a > > > > new ID is required to get bandwidth decrease? > > > > > > Is there a technical reason that someone can articulate? Along the > > > same lines, is make-before-break needed on bandwidth *decrease*? > > > > > > Thanks, > > > Kireeti. > > > > > > Does interoperating with a major router vendor (which is neither > > Juniper or Avici) qualify as technical? After all, this is the IETF > > so improving interoperability must count for something. Right? If > > not, then I can't think of any reason to increment the LSP-ID and if > > you don't change the LSP-ID, then you don't need to do > > make-before-break. > > > > OTOH - Do you see any reason to NOT increment the ID and do > > make-before-break. If you do so you interoperate with the major > > router vendors (Juniper, Avici, others which do either one right, plus > > one which seems to be in denial about their router not handling > > bandwidth decrease reliably). > > Suppose the reservation style is FF, then incrementing the ID might > cause b/w decrease action to fail, since make-before-break may run > out of b/w at certain bottle-neck. > > We can argue that FF style isn't in wide spread use, but it isn't > precluded from RSVP-TE framework so far. > > Thanks, > Der-hwa > > > > > We do the latter (change the LSP-ID and do make-before-break) and I > > think it is a better strategy because no major router can't handle > > that case. > > > > The only thing besides improved interoperability that borders on a > > technical reason is that the same mechanism is then used for both > > bandwidth increase and decrease. > > > > Curtis > > From owner-mpls@UU.NET Tue Nov 5 19:06:05 2002 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 ESMTP id TAA26427 for ; Tue, 5 Nov 2002 19:06:05 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnsq03346 for ; Wed, 6 Nov 2002 00:08:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnsq00806; Wed, 6 Nov 2002 00:07:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnsq07427 for mpls-outgoing; Wed, 6 Nov 2002 00:06:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnsq07422 for ; Wed, 6 Nov 2002 00:06:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnsq00094 for ; Wed, 6 Nov 2002 00:06:04 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnsq08431 for ; Wed, 6 Nov 2002 00:06:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnsq08423 for ; Wed, 6 Nov 2002 00:06:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA16237 for ; Tue, 5 Nov 2002 19:06:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6062m11372 for mpls@uu.net; Tue, 5 Nov 2002 19:06:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnsq07171 for ; Wed, 6 Nov 2002 00:05:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnsq12901 for ; Wed, 6 Nov 2002 00:03:47 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnsq05206 for ; Wed, 6 Nov 2002 00:03:47 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnnsq05177 for ; Wed, 6 Nov 2002 00:03:46 GMT Received: from juniper.net (lookout.juniper.net [172.17.20.54]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA603jS78616; Tue, 5 Nov 2002 16:03:45 -0800 (PST) (envelope-from dhg@juniper.net) Message-Id: <200211060003.gA603jS78616@merlot.juniper.net> To: "Gray, Eric" cc: mpls@UU.NET Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of Tue, 05 Nov 2002 18:37:20 -0500. <1117F7D44159934FB116E36F4ABF221B0267EC63@celox-ma1-ems1.celoxnetworks.com> Date: Tue, 05 Nov 2002 16:03:45 -0800 From: Der-Hwa Gan Sender: owner-mpls@UU.NET Precedence: bulk > Der-hwa, > > Here we have a trade-off between a small potential for > simplification represented by using a symmetrical approach > (the same approach used for increasing or decreasing the > TE-LSP bandwidth) and the potential risk of not being able > to make a new reservation with a lesser bandwidth in the > unusual use of FF reservation style. It is not a question of simplication. If FF reservation style is excluded from RSVP-TE spec, then we won't discuss it. But if FF remains a potential option (perhaps a future application may make use of it?), then it is fair to consider it. My response was mainly to the point that Curtis raised - could there be a reason that changing ID is bad? > > Please tell me again why this is a hard choice? There are other benefits to not changing the ID. It was those considerations that drove the original choice - it is more optimal, less states, and less overhead to the network. Do you see a easy choice? Der-Hwa > > Note that - if we were using the FF reservation style > and trying to increase the bandwidth - the problem would be > worse because it would be both more likely to cause trouble > and less likely to be remediable. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > -----Original Message----- > > From: Der-Hwa Gan [mailto:dhg@juniper.net] > > Sent: Tuesday, November 05, 2002 3:45 PM > > To: curtis@fictitious.org > > Cc: Kireeti Kompella; mpls@UU.NET > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > > > > > > > > > > In message <20021104110215.J10006-100000@kummer.juniper.net>, Kireeti > > Kompell > > a > > > writes: > > > > Hi All, > > > > > > > > I'd like to re-iterate Der-Hwa's question: > > > > > > > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > > > > > > > > > It is perhaps more appropriate to ask what is the technical reason > > that a > > > > > new ID is required to get bandwidth decrease? > > > > > > > > Is there a technical reason that someone can articulate? Along the > > > > same lines, is make-before-break needed on bandwidth *decrease*? > > > > > > > > Thanks, > > > > Kireeti. > > > > > > > > > Does interoperating with a major router vendor (which is neither > > > Juniper or Avici) qualify as technical? After all, this is the IETF > > > so improving interoperability must count for something. Right? If > > > not, then I can't think of any reason to increment the LSP-ID and if > > > you don't change the LSP-ID, then you don't need to do > > > make-before-break. > > > > > > OTOH - Do you see any reason to NOT increment the ID and do > > > make-before-break. If you do so you interoperate with the major > > > router vendors (Juniper, Avici, others which do either one right, plus > > > one which seems to be in denial about their router not handling > > > bandwidth decrease reliably). > > > > Suppose the reservation style is FF, then incrementing the ID might > > cause b/w decrease action to fail, since make-before-break may run > > out of b/w at certain bottle-neck. > > > > We can argue that FF style isn't in wide spread use, but it isn't > > precluded from RSVP-TE framework so far. > > > > Thanks, > > Der-hwa > > > > > > > > We do the latter (change the LSP-ID and do make-before-break) and I > > > think it is a better strategy because no major router can't handle > > > that case. > > > > > > The only thing besides improved interoperability that borders on a > > > technical reason is that the same mechanism is then used for both > > > bandwidth increase and decrease. > > > > > > Curtis > > > From owner-mpls@UU.NET Wed Nov 6 03:57:17 2002 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 ESMTP id DAA09570 for ; Wed, 6 Nov 2002 03:57:17 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnntz16316 for ; Wed, 6 Nov 2002 08:59:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnntz15385; Wed, 6 Nov 2002 08:59:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnntz03111 for mpls-outgoing; Wed, 6 Nov 2002 08:58:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnntz03106 for ; Wed, 6 Nov 2002 08: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 QQnntz27211 for ; Wed, 6 Nov 2002 08:58:21 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnntz16641 for ; Wed, 6 Nov 2002 08:58:21 GMT Received: from relay2.clb.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relay2.clb.oleane.net [213.56.31.22]) id QQnntz16629 for ; Wed, 6 Nov 2002 08:58:20 GMT Received: from chantal (upper-side.rain.fr [194.250.212.114]) by relay2.clb.oleane.net with SMTP id gA68wJ3u025608 for ; Wed, 6 Nov 2002 09:58:19 +0100 Message-ID: <00dd01c28573$6d8a2b20$0701a8c0@upperside> From: "Peter Lewis" To: Subject: ETHERNET IN THE ACCESS: Call for Paper Date: Wed, 6 Nov 2002 10:03:51 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01C2857B.CF03CE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D9_01C2857B.CF03CE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ETHERNET IN THE ACCESS Delivering OAMP capabilities to Ethernet in the Last Mile Ethernet services are now a reality at the metropolitan as well as at the access level. Carriers and ISPs will deploy such services beside their Frame Relay, ATM and MPLS networks. Above all, delivering OAMP capabilities is a key issue for them as they want to leverage their existing methods and proceedures in the last mile and until now, haven't been able to with Ethernet. The second edition of "Ethernet in the Access" conference, to be held on June 17 to 20, 2003 in Paris La Defense, will serve as a backdrop for bringing together normalization body representatives, equipment vendors and operators involved actively developing ways to allow Ethernet to become a credible protocol in the access network. A call for proposals is online at: http://www.upperside.fr/ethernet2003/ethernet03intro.htm ------=_NextPart_000_00D9_01C2857B.CF03CE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ETHERNET IN THE=20 ACCESS
Delivering OAMP capabilities to Ethernet in = the Last=20 Mile

Ethernet services=20 are now a reality at the metropolitan as well as at the access level. = Carriers=20 and ISPs will deploy such services beside their Frame Relay, ATM and = MPLS=20 networks. Above all, delivering OAMP capabilities is a key issue for = them as=20 they want to leverage their existing methods and proceedures in the last = mile=20 and until now, haven't been able to with Ethernet.

The second = edition of=20 "Ethernet in the Access" conference, to be held on June 17 to 20, 2003 = in Paris=20 La Defense, will serve as a backdrop for bringing together normalization = body=20 representatives, equipment vendors and operators involved actively = developing=20 ways to allow Ethernet to become a credible protocol in the access = network.=20
 
A call for proposals is online = at:
http://= www.upperside.fr/ethernet2003/ethernet03intro.htm
 
 
------=_NextPart_000_00D9_01C2857B.CF03CE80-- From owner-mpls@UU.NET Wed Nov 6 06:06:48 2002 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 ESMTP id GAA11389 for ; Wed, 6 Nov 2002 06:06:48 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnui07417 for ; Wed, 6 Nov 2002 11:09:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnui05909; Wed, 6 Nov 2002 11:08:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnui01476 for mpls-outgoing; Wed, 6 Nov 2002 11:08:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnui01441 for ; Wed, 6 Nov 2002 11:07:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnui17164 for ; Wed, 6 Nov 2002 11:07:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnui05118 for ; Wed, 6 Nov 2002 11:07:38 GMT Received: from blooper.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnnui05111 for ; Wed, 6 Nov 2002 11:07:37 GMT Received: from utfors.se ([195.58.105.93]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id gA6B7H28015904; Wed, 6 Nov 2002 12:07:17 +0100 (MET) Message-ID: <3DC8F7E6.30705@utfors.se> Date: Wed, 06 Nov 2002 12:07:18 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg CC: Scott Bradner , Bert Wijnen , George Swallow Subject: agenda for the mpls mib review meeting Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, the agenda for the open MPLS MIG review meeting will be found at: http://urax.utfors.net/~loa/mpls-mib-review.htm and in a text version below. Comments/questions/additions/changes to me before the meeting start. /Loa -------------------- MPLS MIB review Atlanta November 16, 12 AM to 6 PM, at the Cisco office at: The Point Complex, Building 500 Agenda (to be bashed) 1. Opening remarks (Loa) 2. AD views (Bert) 3. On behalf of the mib - authors (proposed Tom and/or Joan) 4. MPLS MIB overview (Tom/Joan) 5. The MIBs one by one in some logical order 5.1 lsr mib 5.2 ldp mib 5.3 ftn mib 5.4 te mib 5.5 tc mib 5.6 bundle mib (Tom) 5.7 tewg mib (Kireeti) 6. GMPLS considerations 7. Summary of input and actions. 7.1 Report to mpls wg meeting 7.2 id tracker input ------------------------------ Directions from the airport: At the Atlanta Airport: Leave the airport following direction indicators toward I-75 North. Take I-75 North to the I-85 North exit. Travel on I-85 North to Hwy GA-400 North (toll road) While traveling on GA-400, look for the Northridge Road Exit Turn right at the top of the exit and cross over GA-400. Turn right into The Point complex. Building 500 is on the right inside the complex. Note: According to the hosts it is "quite close to the hotel, take a taxi" -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Wed Nov 6 06:21:15 2002 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 ESMTP id GAA11616 for ; Wed, 6 Nov 2002 06:21:14 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuj03666 for ; Wed, 6 Nov 2002 11:23:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnuj01971; Wed, 6 Nov 2002 11:22:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnuj03478 for mpls-outgoing; Wed, 6 Nov 2002 11:22:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnuj03473 for ; Wed, 6 Nov 2002 11:22: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 QQnnuj01310 for ; Wed, 6 Nov 2002 11:22:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuj12221 for ; Wed, 6 Nov 2002 11:22:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnuj12214 for ; Wed, 6 Nov 2002 11:22:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA16587 for ; Wed, 6 Nov 2002 06:22:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6BM5m12459 for mpls@uu.net; Wed, 6 Nov 2002 06:22:05 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnuj03270 for ; Wed, 6 Nov 2002 11:20:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnuj20407 for ; Wed, 6 Nov 2002 11:20:40 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuj11553 for ; Wed, 6 Nov 2002 11:20:40 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: amsterdam.cisco.com [144.254.74.238]) id QQnnuj11549 for ; Wed, 6 Nov 2002 11:20:40 GMT Received: from MBEHRING-W2K1.cisco.com ([64.103.96.184]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA29011; Wed, 6 Nov 2002 12:20:37 +0100 (MET) Message-Id: <4.3.2.7.2.20021105162125.04e0ec60@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Nov 2002 15:24:48 +0100 To: George Swallow , Loa Andersson From: "Michael H. Behringer" Subject: Request for Speaking Slot: draft-behringer-mpls-security-03.txt Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk George, Loa, Recently I submitted an updated version of draft-behringer-mpls-security-03.txt. If you consider this work of interest to the MPLS WG, I would like to request a speaking slot at the Atlanta meeting. Thanks, Michael A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of the Security of the MPLS Architecture Author(s) : M. Behringer Filename : draft-behringer-mpls-security-03.txt Pages : 14 Date : 2002-11-4 This document analyses the security of the BGP/MPLS VPN architecture as described in RFC 2547, especially in comparison with other VPN technologies such as ATM and Frame Relay. The target audience is service providers and VPN users. The document consists of two main parts: First the requirements for security in VPN services are defined, second MPLS is examined with respect to these requirements. The analysis shows that MPLS VPN networks can be equally secured as traditional layer-2 VPN networks such as ATM and Frame Relay. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-03.txt From owner-mpls@UU.NET Wed Nov 6 06:25:15 2002 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 ESMTP id GAA11698 for ; Wed, 6 Nov 2002 06:25:14 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuj16879 for ; Wed, 6 Nov 2002 11:27:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnuj15368; Wed, 6 Nov 2002 11:26:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnuj03848 for mpls-outgoing; Wed, 6 Nov 2002 11:26:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnuj03826 for ; Wed, 6 Nov 2002 11:26:32 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 QQnnuj04235 for ; Wed, 6 Nov 2002 11:26:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuj08494 for ; Wed, 6 Nov 2002 11:26:10 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnnuj07604 for ; Wed, 6 Nov 2002 11:25:43 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA6BPWe12634; Wed, 6 Nov 2002 06:25:32 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 06:25:32 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05EB4DEE@zcard031.ca.nortel.com> From: "David Allan" To: Der-Hwa Gan , "Gray, Eric" Cc: mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Wed, 6 Nov 2002 06:25:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28587.3754B976" 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_01C28587.3754B976 Content-Type: text/plain; charset="iso-8859-1" Der-Hwa/Eric: Only scenario that comes to my mind is that some form of data plane probing of the LSP is going on (be it LSP-PING, Y.1711 or whatever). Changing the ID means there is a small window in which it may appear as a transient fault to the probing system. cheers Dave > -----Original Message----- > From: Der-Hwa Gan [mailto:dhg@juniper.net] > Sent: Tuesday, November 05, 2002 7:04 PM > To: Gray, Eric > Cc: mpls@UU.NET > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability > issue" (fwd) > > > > > > Der-hwa, > > > > Here we have a trade-off between a small potential for > > simplification represented by using a symmetrical approach > > (the same approach used for increasing or decreasing the > > TE-LSP bandwidth) and the potential risk of not being able > > to make a new reservation with a lesser bandwidth in the > > unusual use of FF reservation style. > > It is not a question of simplication. If FF reservation style is > excluded from RSVP-TE spec, then we won't discuss it. But if > FF remains > a potential option (perhaps a future application may make use of it?), > then it is fair to consider it. > > My response was mainly to the point that Curtis raised - > could there be > a reason that changing ID is bad? > > > > > Please tell me again why this is a hard choice? > > There are other benefits to not changing the ID. It was those > considerations > that drove the original choice - it is more optimal, less > states, and less overhead to the network. > > Do you see a easy choice? > Der-Hwa > > > > > Note that - if we were using the FF reservation style > > and trying to increase the bandwidth - the problem would be > > worse because it would be both more likely to cause trouble > > and less likely to be remediable. > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > > -----Original Message----- > > > From: Der-Hwa Gan [mailto:dhg@juniper.net] > > > Sent: Tuesday, November 05, 2002 3:45 PM > > > To: curtis@fictitious.org > > > Cc: Kireeti Kompella; mpls@UU.NET > > > Subject: Re: Decreasing TE-LSP bandwidth, > "interoperability issue" (fwd) > > > > > > > > > > > > > > In message > <20021104110215.J10006-100000@kummer.juniper.net>, Kireeti > > > Kompell > > > a > > > > writes: > > > > > Hi All, > > > > > > > > > > I'd like to re-iterate Der-Hwa's question: > > > > > > > > > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > > > > > > > > > > > It is perhaps more appropriate to ask what is the > technical reason > > > that a > > > > > > new ID is required to get bandwidth decrease? > > > > > > > > > > Is there a technical reason that someone can > articulate? Along the > > > > > same lines, is make-before-break needed on bandwidth > *decrease*? > > > > > > > > > > Thanks, > > > > > Kireeti. > > > > > > > > > > > > Does interoperating with a major router vendor (which is neither > > > > Juniper or Avici) qualify as technical? After all, > this is the IETF > > > > so improving interoperability must count for something. > Right? If > > > > not, then I can't think of any reason to increment the > LSP-ID and if > > > > you don't change the LSP-ID, then you don't need to do > > > > make-before-break. > > > > > > > > OTOH - Do you see any reason to NOT increment the ID and do > > > > make-before-break. If you do so you interoperate with the major > > > > router vendors (Juniper, Avici, others which do either > one right, plus > > > > one which seems to be in denial about their router not handling > > > > bandwidth decrease reliably). > > > > > > Suppose the reservation style is FF, then incrementing > the ID might > > > cause b/w decrease action to fail, since make-before-break may run > > > out of b/w at certain bottle-neck. > > > > > > We can argue that FF style isn't in wide spread use, but it isn't > > > precluded from RSVP-TE framework so far. > > > > > > Thanks, > > > Der-hwa > > > > > > > > > > > We do the latter (change the LSP-ID and do > make-before-break) and I > > > > think it is a better strategy because no major router > can't handle > > > > that case. > > > > > > > > The only thing besides improved interoperability that > borders on a > > > > technical reason is that the same mechanism is then > used for both > > > > bandwidth increase and decrease. > > > > > > > > Curtis > > > > > > ------_=_NextPart_001_01C28587.3754B976 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Decreasing TE-LSP bandwidth, "interoperability = issue" (fwd)

Der-Hwa/Eric:

Only scenario that comes to my mind is that some form = of data plane probing of the LSP is going on (be it LSP-PING, Y.1711 or = whatever). Changing the ID means there is a small window in which it = may appear as a transient fault to the probing system.

cheers
Dave

> -----Original Message-----
> From: Der-Hwa Gan [mailto:dhg@juniper.net]
> Sent: Tuesday, November 05, 2002 7:04 PM
> To: Gray, Eric
> Cc: mpls@UU.NET
> Subject: Re: Decreasing TE-LSP bandwidth, = "interoperability
> issue" (fwd)
>
>
>
>
> > Der-hwa,
> >
> >     Here we have a = trade-off between a small potential for
> > simplification represented by using a = symmetrical approach
> > (the same approach used for increasing or = decreasing the
> > TE-LSP bandwidth) and the potential risk = of not being able
> > to make a new reservation with a lesser = bandwidth in the
> > unusual use of FF reservation style.  =
>
> It is not a question of simplication. If FF = reservation style is
> excluded from RSVP-TE spec, then we won't = discuss it. But if
> FF remains
> a potential option (perhaps a future = application may make use of it?),
> then it is fair to consider it.
>
> My response was mainly to the point that Curtis = raised -
> could there be
> a reason that changing ID is bad?
>
> >
> >     Please tell me again = why this is a hard choice?
>
> There are other benefits to not changing the = ID. It was those
> considerations
> that drove the original choice - it is more = optimal, less
> states, and less overhead to the = network.
>
> Do you see a easy choice?
> Der-Hwa
>
> >
> >     Note that - if we were = using the FF reservation style
> > and trying to increase the bandwidth - the = problem would be
> > worse because it would be both more likely = to cause trouble
> > and less likely to be remediable.
> >
> > Eric W. Gray
> > Systems Architect
> > Celox Networks, Inc.
> > egray@celoxnetworks.com
> > 508 305 7214
> >
> >
> > > -----Original Message-----
> > > From: Der-Hwa Gan [mailto:dhg@juniper.net]
> > > Sent: Tuesday, November 05, 2002 3:45 = PM
> > > To: curtis@fictitious.org
> > > Cc: Kireeti Kompella; = mpls@UU.NET
> > > Subject: Re: Decreasing TE-LSP = bandwidth,
> "interoperability issue" (fwd)
> > >
> > >
> > > >
> > > > In message
> = <20021104110215.J10006-100000@kummer.juniper.net>, Kireeti
> > > Kompell
> > > a
> > > > writes:
> > > > > Hi All,
> > > > >
> > > > > I'd like to re-iterate = Der-Hwa's question:
> > > > >
> > > > > On Thu, 31 Oct 2002, = Der-Hwa Gan wrote:
> > > > >
> > > > > > It is perhaps more = appropriate to ask what is the
> technical reason
> > > that a
> > > > > > new ID is required to = get bandwidth decrease?
> > > > >
> > > > > Is there a technical reason = that someone can
> articulate?  Along the
> > > > > same lines, is = make-before-break needed on bandwidth
> *decrease*?
> > > > >
> > > > > Thanks,
> > > > > Kireeti.
> > > >
> > > >
> > > > Does interoperating with a major = router vendor (which is neither
> > > > Juniper or Avici) qualify as = technical?  After all,
> this is the IETF
> > > > so improving interoperability = must count for something.
>  Right?  If
> > > > not, then I can't think of any = reason to increment the
> LSP-ID and if
> > > > you don't change the LSP-ID, = then you don't need to do
> > > > make-before-break.
> > > >
> > > > OTOH - Do you see any reason to = NOT increment the ID and do
> > > > make-before-break.  If you = do so you interoperate with the major
> > > > router vendors (Juniper, Avici, = others which do either
> one right, plus
> > > > one which seems to be in denial = about their router not handling
> > > > bandwidth decrease = reliably).
> > >
> > > Suppose the reservation style is FF, = then incrementing
> the ID might
> > > cause b/w decrease action to fail, = since make-before-break may run
> > > out of b/w at certain = bottle-neck.
> > >
> > > We can argue that FF style isn't in = wide spread use, but it isn't
> > > precluded from RSVP-TE framework so = far.
> > >
> > > Thanks,
> > > Der-hwa
> > >
> > > >
> > > > We do the latter (change the = LSP-ID and do
> make-before-break) and I
> > > > think it is a better strategy = because no major router
> can't handle
> > > > that case.
> > > >
> > > > The only thing besides improved = interoperability that
> borders on a
> > > > technical reason is that the = same mechanism is then
> used for both
> > > > bandwidth increase and = decrease.
> > > >
> > > > Curtis
> > > >
>
>

------_=_NextPart_001_01C28587.3754B976-- From owner-mpls@UU.NET Wed Nov 6 06:27:51 2002 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 ESMTP id GAA11875 for ; Wed, 6 Nov 2002 06:27:51 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuk02216 for ; Wed, 6 Nov 2002 11:30:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnuj29644; Wed, 6 Nov 2002 11:29:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnuj03916 for mpls-outgoing; Wed, 6 Nov 2002 11:28:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnuj03893 for ; Wed, 6 Nov 2002 11:28:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnuj24473 for ; Wed, 6 Nov 2002 11:27:51 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuj17165 for ; Wed, 6 Nov 2002 11:27:50 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnnuj16643 for ; Wed, 6 Nov 2002 11:27:33 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA6BRPe12638; Wed, 6 Nov 2002 06:27:25 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 06:27:25 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05EB4DEF@zcard031.ca.nortel.com> From: "David Allan" To: "David Allan" , Der-Hwa Gan , "Gray, Eric" Cc: mpls@UU.NET Subject: RESEND: Decreasing TE-LSP bandwidth, "interoperability issue" (fw d) Date: Wed, 6 Nov 2002 06:27:24 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Der-Hwa/Eric: Only scenario that comes to my mind is that some form of data plane probing of the LSP is going on (be it LSP-PING, Y.1711 or whatever). Changing the ID means there is a small window in which it may appear as a transient fault to the probing system. cheers Dave > > -----Original Message----- > > From: Der-Hwa Gan [mailto:dhg@juniper.net] > > Sent: Tuesday, November 05, 2002 7:04 PM > > To: Gray, Eric > > Cc: mpls@UU.NET > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability > > issue" (fwd) > > > > > > > > > > > Der-hwa, > > > > > > Here we have a trade-off between a small potential for > > > simplification represented by using a symmetrical approach > > > (the same approach used for increasing or decreasing the > > > TE-LSP bandwidth) and the potential risk of not being able > > > to make a new reservation with a lesser bandwidth in the > > > unusual use of FF reservation style. > > > > It is not a question of simplication. If FF reservation style is > > excluded from RSVP-TE spec, then we won't discuss it. But if > > FF remains > > a potential option (perhaps a future application may make > use of it?), > > then it is fair to consider it. > > > > My response was mainly to the point that Curtis raised - > > could there be > > a reason that changing ID is bad? > > > > > > > > Please tell me again why this is a hard choice? > > > > There are other benefits to not changing the ID. It was those > > considerations > > that drove the original choice - it is more optimal, less > > states, and less overhead to the network. > > > > Do you see a easy choice? > > Der-Hwa > > > > > > > > Note that - if we were using the FF reservation style > > > and trying to increase the bandwidth - the problem would be > > > worse because it would be both more likely to cause trouble > > > and less likely to be remediable. > > > > > > Eric W. Gray > > > Systems Architect > > > Celox Networks, Inc. > > > egray@celoxnetworks.com > > > 508 305 7214 > > > > > > > > > > -----Original Message----- > > > > From: Der-Hwa Gan [mailto:dhg@juniper.net] > > > > Sent: Tuesday, November 05, 2002 3:45 PM > > > > To: curtis@fictitious.org > > > > Cc: Kireeti Kompella; mpls@UU.NET > > > > Subject: Re: Decreasing TE-LSP bandwidth, > > "interoperability issue" (fwd) > > > > > > > > > > > > > > > > > > In message > > <20021104110215.J10006-100000@kummer.juniper.net>, Kireeti > > > > Kompell > > > > a > > > > > writes: > > > > > > Hi All, > > > > > > > > > > > > I'd like to re-iterate Der-Hwa's question: > > > > > > > > > > > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > > > > > > > > > > > > > It is perhaps more appropriate to ask what is the > > technical reason > > > > that a > > > > > > > new ID is required to get bandwidth decrease? > > > > > > > > > > > > Is there a technical reason that someone can > > articulate? Along the > > > > > > same lines, is make-before-break needed on bandwidth > > *decrease*? > > > > > > > > > > > > Thanks, > > > > > > Kireeti. > > > > > > > > > > > > > > > Does interoperating with a major router vendor (which > is neither > > > > > Juniper or Avici) qualify as technical? After all, > > this is the IETF > > > > > so improving interoperability must count for something. > > Right? If > > > > > not, then I can't think of any reason to increment the > > LSP-ID and if > > > > > you don't change the LSP-ID, then you don't need to do > > > > > make-before-break. > > > > > > > > > > OTOH - Do you see any reason to NOT increment the ID and do > > > > > make-before-break. If you do so you interoperate > with the major > > > > > router vendors (Juniper, Avici, others which do either > > one right, plus > > > > > one which seems to be in denial about their router > not handling > > > > > bandwidth decrease reliably). > > > > > > > > Suppose the reservation style is FF, then incrementing > > the ID might > > > > cause b/w decrease action to fail, since > make-before-break may run > > > > out of b/w at certain bottle-neck. > > > > > > > > We can argue that FF style isn't in wide spread use, > but it isn't > > > > precluded from RSVP-TE framework so far. > > > > > > > > Thanks, > > > > Der-hwa > > > > > > > > > > > > > > We do the latter (change the LSP-ID and do > > make-before-break) and I > > > > > think it is a better strategy because no major router > > can't handle > > > > > that case. > > > > > > > > > > The only thing besides improved interoperability that > > borders on a > > > > > technical reason is that the same mechanism is then > > used for both > > > > > bandwidth increase and decrease. > > > > > > > > > > Curtis > > > > > > > > > > From owner-mpls@UU.NET Wed Nov 6 06:35:44 2002 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 ESMTP id GAA13101 for ; Wed, 6 Nov 2002 06:35:43 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuk25316 for ; Wed, 6 Nov 2002 11:38:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnuk17368; Wed, 6 Nov 2002 11:34:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnuk04389 for mpls-outgoing; Wed, 6 Nov 2002 11:34:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnuk04371 for ; Wed, 6 Nov 2002 11:34:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnuk25105 for ; Wed, 6 Nov 2002 11:34:16 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuk25994 for ; Wed, 6 Nov 2002 11:34:16 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnuk25986 for ; Wed, 6 Nov 2002 11:34:15 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA17146 for ; Wed, 6 Nov 2002 06:34:15 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6BYFD14480 for mpls@uu.net; Wed, 6 Nov 2002 06:34:15 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnuk04326 for ; Wed, 6 Nov 2002 11:33:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnuk22796 for ; Wed, 6 Nov 2002 11:33:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuk25616 for ; Wed, 6 Nov 2002 11:33:20 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnnuk25612 for ; Wed, 6 Nov 2002 11:33:19 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12505; Wed, 6 Nov 2002 06:30:49 -0500 (EST) Message-Id: <200211061130.GAA12505@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-bundle-mib-04.txt Date: Wed, 06 Nov 2002 06:30:49 -0500 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 : Link Bundling Management Information Base Author(s) : M. Dubuc et al. Filename : draft-ietf-mpls-bundle-mib-04.txt Pages : 52 Date : 2002-11-5 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling link bundling as described in the Link Bundling in MPLS Traffic Engineer- ing Internet Draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-bundle-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-bundle-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-5193405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bundle-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bundle-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193405.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Nov 6 06:38:31 2002 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 ESMTP id GAA13267 for ; Wed, 6 Nov 2002 06:38:31 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuk06905 for ; Wed, 6 Nov 2002 11:40:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnuk28187; Wed, 6 Nov 2002 11:37:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnuk04650 for mpls-outgoing; Wed, 6 Nov 2002 11:36:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnuk04637 for ; Wed, 6 Nov 2002 11:36:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnuk14472 for ; Wed, 6 Nov 2002 11:35:41 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuk26685 for ; Wed, 6 Nov 2002 11:35:41 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnuk26676 for ; Wed, 6 Nov 2002 11:35:40 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA17208 for ; Wed, 6 Nov 2002 06:35:40 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6BZeI14575 for mpls@uu.net; Wed, 6 Nov 2002 06:35:40 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnuk04332 for ; Wed, 6 Nov 2002 11:33:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnuk22619 for ; Wed, 6 Nov 2002 11:33:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuk25587 for ; Wed, 6 Nov 2002 11:33:15 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnnuk25581 for ; Wed, 6 Nov 2002 11:33:15 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12493; Wed, 6 Nov 2002 06:30:45 -0500 (EST) Message-Id: <200211061130.GAA12493@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-rsvp-lsp-fastreroute-01.txt Date: Wed, 06 Nov 2002 06:30:44 -0500 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 : Fast Reroute Extensions to RSVP-TE for LSP Tunnels Author(s) : P. Pan et al. Filename : draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt Pages : 34 Date : 2002-11-5 This document defines extensions to and describes the use of RSVP [RSVP, RSVP-TE] to establish backup LSP tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of protected LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow LERs and LSRs to implement either or both methods and to interoperate in a mixed network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-5193356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5193356.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Nov 6 08:24:15 2002 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 ESMTP id IAA16950 for ; Wed, 6 Nov 2002 08:24:14 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnur21033 for ; Wed, 6 Nov 2002 13:26:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnur13001; Wed, 6 Nov 2002 13:22:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnur16642 for mpls-outgoing; Wed, 6 Nov 2002 13:22:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnur16628 for ; Wed, 6 Nov 2002 13:22: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 QQnnur21171 for ; Wed, 6 Nov 2002 13:21:33 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnur11360 for ; Wed, 6 Nov 2002 13:21:32 GMT Received: from emerson.torrentnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: emerson.torrentnet.com [198.78.51.110]) id QQnnur11351 for ; Wed, 6 Nov 2002 13:21:32 GMT Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id gA6DLM410717; Wed, 6 Nov 2002 08:21:22 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id gA6DLLV80911; Wed, 6 Nov 2002 08:21:21 -0500 (EST) Received: from oldmonk (oldmonk.torrentnet.com [4.18.161.44]) by castillo.torrentnet.com (8.9.3/8.9.3) with SMTP id IAA07924; Wed, 6 Nov 2002 08:21:21 -0500 (EST) From: "Sumit Garg" To: "'Michael H. Behringer'" , "'George Swallow'" , "'Loa Andersson'" Cc: Subject: RE: Request for Speaking Slot: draft-behringer-mpls-security-03.txt Date: Wed, 6 Nov 2002 08:21:20 -0500 Message-ID: <001401c28597$658d9a50$2ca11204@torrentnet.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.2911.0) In-reply-to: <4.3.2.7.2.20021105162125.04e0ec60@madrid.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Got only as far as page 6. Some comments: -------------- Page 6, you write: "Traffic separation is achieved by prepending VPN-specific labels to the packets, so that a packet can also on the core be identified as belonging to a specific VPN. " This assumes and implies that the core LSRs know that the label is a VPN label; OR more generically that there is something special about a VPN label. My understanding is there isn't. Labels are not looked at in any specific context. Infact with independent LSP setup, teardown and local repair one can run into scenarios where the VPN traffic doesn't stay so private. Example: VPN1----A----B----C----D----VPN2 A and D are PEs and B and C and Ps. LSP from A to D comes up (or goes down) independently and for this example assume the LSP segment between B and C is missing. A thinks there is a LSP to D (doesn't know of the hole between B and C) Traffic from A goes to B with the outer label for the LSP to D and the inner label for VPN sites connected at A and D B doesn't have an outgoing label; does a pop of the outer label and then as the end of stack bit is not set looks at the inner label. This label might have local significance at B and so the traffic may ge switched to the wrong LSP and therefore the wrong desitation. This is a consequence of independent LSP setup. End to end LSP continuty cannot be guaranteed. One possible option is to set the opcode on the incoming lable on B as discard and not pop and lookup. Hope you get the idea. And maybe the MPLS gurus can clarify my ideas? Some nits: ---------- Page number on page 1 is missing. Page 2, after the bullet list there is a type ">From " Doc formatting can be improved so that page numbers do fall on end of page; most authors do it by embedding a form feed (a CTRL-L). General observations: --------------------- Don't see the point of this document wrt the WG. What are we trying to achieve? Seems more like a white paper. But then these are my 2c. /Sumit > George, Loa, > > Recently I submitted an updated version of > draft-behringer-mpls-security-03.txt. If you consider this > work of interest > to the MPLS WG, I would like to request a speaking slot at > the Atlanta > meeting. > > Thanks, > Michael > From owner-mpls@UU.NET Wed Nov 6 08:24:31 2002 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 ESMTP id IAA16973 for ; Wed, 6 Nov 2002 08:24:31 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnur21819 for ; Wed, 6 Nov 2002 13:26:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnur20512; Wed, 6 Nov 2002 13:26:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnur16885 for mpls-outgoing; Wed, 6 Nov 2002 13:25:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnur16833 for ; Wed, 6 Nov 2002 13:25:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnur21393 for ; Wed, 6 Nov 2002 13:24:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnur14300 for ; Wed, 6 Nov 2002 13:24:18 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnnur14283 for ; Wed, 6 Nov 2002 13:24:17 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA6DOFh00581 for ; Wed, 6 Nov 2002 08:24:16 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 14:24:14 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: Loa Andersson , MPLS wg Cc: Scott Bradner , Bert Wijnen , George Swallow Subject: RE: agenda for the mpls mib review meeting Date: Wed, 6 Nov 2002 14:24:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Comments/questions/additions/changes to me before the meeting start. > > 5.5 tc mib > I think the TC-MIB is at rev 05. Bert From owner-mpls@UU.NET Wed Nov 6 08:36:05 2002 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 ESMTP id IAA17381 for ; Wed, 6 Nov 2002 08:36:05 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnus03410 for ; Wed, 6 Nov 2002 13:38:27 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnus01538; Wed, 6 Nov 2002 13:37:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnus17848 for mpls-outgoing; Wed, 6 Nov 2002 13:37:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnus17842 for ; Wed, 6 Nov 2002 13:36: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 QQnnus09791 for ; Wed, 6 Nov 2002 13:36:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnus04531 for ; Wed, 6 Nov 2002 13:36:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnus04526 for ; Wed, 6 Nov 2002 13:36:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA22033 for ; Wed, 6 Nov 2002 08:36:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6Da5i22986 for mpls@uu.net; Wed, 6 Nov 2002 08:36:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnus17598 for ; Wed, 6 Nov 2002 13:34: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 QQnnus00913 for ; Wed, 6 Nov 2002 13:33:28 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnus02642 for ; Wed, 6 Nov 2002 13:33:28 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnus02633 for ; Wed, 6 Nov 2002 13:33:27 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA21678; Wed, 6 Nov 2002 08:29:13 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA01919; Wed, 6 Nov 2002 08:29:13 -0500 (EST) Message-Id: <200211061329.IAA01919@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Der-Hwa Gan cc: "Gray, Eric" , mpls@UU.NET, swallow@cisco.com Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of "Tue, 05 Nov 2002 16:03:45 PST." <200211060003.gA603jS78616@merlot.juniper.net> Date: Wed, 06 Nov 2002 08:29:13 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk There were actually two reasons for the design choice of changing the LSP-ID. The first was already described by Eric - > Here we have a trade-off between a small potential for > simplification represented by using a symmetrical approach > (the same approach used for increasing or decreasing the > TE-LSP bandwidth) The other has to do with optimizing bandwidth across multiple parallel links. If the ERO is node specific but not link specific, then the choice of which link to place a tunnel on is a local decision. One option for doing this is to pack tunnels on links where they fit so as to leave as large a free block of bandwidth as possible in anticipation of being able to handle a large request. When you decrease bandwidth, it the tunnel will now fit on one of the other links, allowing a large free pool, thenyou may want to move it. Changing the LSP-ID allows this in the same way as nay make-before-break. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 6 08:41:12 2002 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 ESMTP id IAA17534 for ; Wed, 6 Nov 2002 08:41:12 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnus11432 for ; Wed, 6 Nov 2002 13:43:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnus09158; Wed, 6 Nov 2002 13:42:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnus18286 for mpls-outgoing; Wed, 6 Nov 2002 13:41:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnus18267 for ; Wed, 6 Nov 2002 13:41:21 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnus23168 for ; Wed, 6 Nov 2002 13:41:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnus08099 for ; Wed, 6 Nov 2002 13:41:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnus08090 for ; Wed, 6 Nov 2002 13:41:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA22305 for ; Wed, 6 Nov 2002 08:41:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6Df6t23505 for mpls@uu.net; Wed, 6 Nov 2002 08:41:06 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnus17892 for ; Wed, 6 Nov 2002 13:37:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnus13247 for ; Wed, 6 Nov 2002 13:37:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnus05521 for ; Wed, 6 Nov 2002 13:37:25 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnus05516 for ; Wed, 6 Nov 2002 13:37:25 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA22103; Wed, 6 Nov 2002 08:37:24 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA02046; Wed, 6 Nov 2002 08:37:24 -0500 (EST) Message-Id: <200211061337.IAA02046@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "David Allan" cc: Der-Hwa Gan , "Gray, Eric" , mpls@UU.NET, swallow@cisco.com Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of "Wed, 06 Nov 2002 06:25:31 EST." <9FBD322B7824D511B36900508BF93C9C05EB4DEE@zcard031.ca.nortel.com> Date: Wed, 06 Nov 2002 08:37:24 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Only scenario that comes to my mind is that some form of data plane probing > of the LSP is going on (be it LSP-PING, Y.1711 or whatever). Changing the ID > means there is a small window in which it may appear as a transient fault to > the probing system. With LSP ping, you would ping the first LSP until the second is set up. Once that is complete you can start pinging it as well. You can even wait for a successful reply before ceasing pinging the first and tearing it down. (Though I think that's probably overkill.) So you don't have a gap, you actually have an overlap. With Y.1711 I don't understand how you would map an RSVP tunnel/lsp-id to a TTSI. There are just enough bits to fit both RSVP fields into the TTSI LSP-ID, but that doesn't leave anying for LDP, BGP, etc. Maybe you can enlighten us. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 6 08:49:18 2002 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 ESMTP id IAA17923 for ; Wed, 6 Nov 2002 08:49:18 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnut20692 for ; Wed, 6 Nov 2002 13:51:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnut19050; Wed, 6 Nov 2002 13:50:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnut19454 for mpls-outgoing; Wed, 6 Nov 2002 13:50:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnut19445 for ; Wed, 6 Nov 2002 13:50:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnut17841 for ; Wed, 6 Nov 2002 13:50:26 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnut22235 for ; Wed, 6 Nov 2002 13:50:25 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnnut22225 for ; Wed, 6 Nov 2002 13:50:25 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA6Do4e17848; Wed, 6 Nov 2002 08:50:04 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 08:50:04 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05EB4EAD@zcard031.ca.nortel.com> From: "David Allan" To: George Swallow Cc: Der-Hwa Gan , "Gray, Eric" , mpls@UU.NET, swallow@cisco.com Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Wed, 6 Nov 2002 08:50:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2859B.681D888A" 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_01C2859B.681D888A Content-Type: text/plain; charset="iso-8859-1" Hi George: I was envisioning a case where a bandwidth change was not a separate tunnel setup, the LSP ID changed without any interruption or change in the conntectivity of the path . If there is build the new then tear down the old, then there is no gap in any monitoring case. As for TTSI, it's simply a node specific LSP Identifier that allows for an IPv4/v6 LSR ID and 32 bits for an LSP identifier. The assumption is that the originating LSR most usefully administers LSP-IDs independently of the individual control protocol used. The initial draft of Y.1711 was focused on P2P ER-LSPs which meant RSVP-TE or CR-LDP, hence the stipulation that the first two bytes of the LSP-ID were padded with zeros to align with LSP-ID as defined in the signalling protocols. If there is a problem with this, it is not leaping out at me.... cheers Dave > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, November 06, 2002 8:37 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: Der-Hwa Gan; Gray, Eric; mpls@UU.NET; swallow@cisco.com > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability > issue" (fwd) > > > > > Only scenario that comes to my mind is that some form of > data plane probing > > of the LSP is going on (be it LSP-PING, Y.1711 or > whatever). Changing the ID > > means there is a small window in which it may appear as a > transient fault to > > the probing system. > > With LSP ping, you would ping the first LSP until the second is set > up. Once that is complete you can start pinging it as well. You can > even wait for a successful reply before ceasing pinging the first and > tearing it down. (Though I think that's probably overkill.) So you > don't have a gap, you actually have an overlap. > > With Y.1711 I don't understand how you would map an RSVP tunnel/lsp-id > to a TTSI. There are just enough bits to fit both RSVP fields into > the TTSI LSP-ID, but that doesn't leave anying for LDP, BGP, etc. > Maybe you can enlighten us. > > ...George > > > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > ------_=_NextPart_001_01C2859B.681D888A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Decreasing TE-LSP bandwidth, "interoperability = issue" (fwd)

Hi George:

I was envisioning a case where a bandwidth change was = not a separate tunnel setup, the LSP ID changed without any = interruption or change in the conntectivity of the path . If there is = build the new then tear down the old, then there is no gap in any = monitoring case.

As for TTSI, it's simply a node specific LSP = Identifier that allows for an IPv4/v6 LSR ID and 32 bits for an LSP = identifier. The assumption is that the originating LSR most usefully = administers LSP-IDs independently of the individual control protocol = used. The initial draft of Y.1711 was focused on P2P ER-LSPs which = meant RSVP-TE or CR-LDP, hence the stipulation that the first two bytes = of the LSP-ID were padded with zeros to align with LSP-ID as defined in = the signalling protocols. If there is a problem with this, it is not = leaping out at me....

cheers
Dave

> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Wednesday, November 06, 2002 8:37 = AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Der-Hwa Gan; Gray, Eric; mpls@UU.NET; = swallow@cisco.com
> Subject: Re: Decreasing TE-LSP bandwidth, = "interoperability
> issue" (fwd)
>
>
>
> > Only scenario that comes to my mind is = that some form of
> data plane probing
> > of the LSP is going on (be it LSP-PING, = Y.1711 or
> whatever). Changing the ID
> > means there is a small window in which it = may appear as a
> transient fault to
> > the probing system.
>
> With LSP ping, you would ping the first LSP = until the second is set
> up.  Once that is complete you can start = pinging it as well.  You can
> even wait for a successful reply before ceasing = pinging the first and
> tearing it down.  (Though I think that's = probably overkill.)  So you
> don't have a gap, you actually have an = overlap.
>
> With Y.1711 I don't understand how you would = map an RSVP tunnel/lsp-id
> to a TTSI.  There are just enough bits to = fit both RSVP fields into
> the TTSI LSP-ID, but that doesn't leave anying = for LDP, BGP, etc.
> Maybe you can enlighten us.
>
> ...George
>
>
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> George = Swallow       Cisco = Systems           = ;       (978) 497-8143
>        &= nbsp;           &= nbsp; 250 Apollo Drive
>          = ;            = Chelmsford, Ma 01824
>

------_=_NextPart_001_01C2859B.681D888A-- From owner-mpls@UU.NET Wed Nov 6 10:21:15 2002 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 ESMTP id KAA25919 for ; Wed, 6 Nov 2002 10:21:15 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuz06086 for ; Wed, 6 Nov 2002 15:23:39 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnuz04376; Wed, 6 Nov 2002 15:22:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnuz00574 for mpls-outgoing; Wed, 6 Nov 2002 15:22:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnuz00562 for ; Wed, 6 Nov 2002 15:22:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnuz15346 for ; Wed, 6 Nov 2002 15:20:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuz15918 for ; Wed, 6 Nov 2002 15:20:08 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnuz15895 for ; Wed, 6 Nov 2002 15:20:08 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA29290 for ; Wed, 6 Nov 2002 10:20:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6FK7m03726 for mpls@uu.net; Wed, 6 Nov 2002 10:20:07 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnuz00304 for ; Wed, 6 Nov 2002 15:18:43 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 QQnnuz18546 for ; Wed, 6 Nov 2002 15:17:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnuz13392 for ; Wed, 6 Nov 2002 15:17:43 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnuz13382 for ; Wed, 6 Nov 2002 15:17:42 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA29071; Wed, 6 Nov 2002 10:17:42 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA03219; Wed, 6 Nov 2002 10:17:42 -0500 (EST) Message-Id: <200211061517.KAA03219@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "David Allan" cc: George Swallow , Der-Hwa Gan , "Gray, Eric" , mpls@UU.NET, swallow@cisco.com Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of "Wed, 06 Nov 2002 08:50:03 EST." <9FBD322B7824D511B36900508BF93C9C05EB4EAD@zcard031.ca.nortel.com> Date: Wed, 06 Nov 2002 10:17:42 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > I was envisioning a case where a bandwidth change was not a separate tunnel > setup, the LSP ID changed without any interruption or change in the > conntectivity of the path . If there is build the new then tear down the > old, then there is no gap in any monitoring case. If you change the LSP-ID, that changes the sender-template. Ipso facto a new setup. > As for TTSI, it's simply a node specific LSP Identifier that allows for an > IPv4/v6 LSR ID and 32 bits for an LSP identifier. The assumption is that the > originating LSR most usefully administers LSP-IDs independently of the > individual control protocol used. The initial draft of Y.1711 was focused on > P2P ER-LSPs which meant RSVP-TE or CR-LDP, hence the stipulation that the > first two bytes of the LSP-ID were padded with zeros to align with LSP-ID as > defined in the signalling protocols. If there is a problem with this, it is > not leaping out at me.... As we use it, an (RSVP-TE) LSP-ID is *only* unique to the tunnel. We just use it as an instance number and increment it when we reroute or change bandwidth. If I setup five tunnels they will have five different tunnel-IDs, but they can *all* have the same LSP-ID. To uniquely identify a TE-Tunnel LSP. you need *all* of the fields in the session and sender-template objects. That why we carry those in LSP ping. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 6 10:57:14 2002 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 ESMTP id KAA28817 for ; Wed, 6 Nov 2002 10:57:14 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvb27605 for ; Wed, 6 Nov 2002 15:59:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnvb26045; Wed, 6 Nov 2002 15:59:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnvb03478 for mpls-outgoing; Wed, 6 Nov 2002 15:58:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnvb03467 for ; Wed, 6 Nov 2002 15:58:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnvb26309 for ; Wed, 6 Nov 2002 15:57:32 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvb10188 for ; Wed, 6 Nov 2002 15:57:31 GMT Received: from emerson.torrentnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: emerson.torrentnet.com [198.78.51.110]) id QQnnvb10184 for ; Wed, 6 Nov 2002 15:57:31 GMT Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id gA6FvQN12501; Wed, 6 Nov 2002 10:57:26 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id gA6FvPS92657; Wed, 6 Nov 2002 10:57:25 -0500 (EST) Received: from oldmonk (oldmonk.torrentnet.com [4.18.161.44]) by castillo.torrentnet.com (8.9.3/8.9.3) with SMTP id KAA11300; Wed, 6 Nov 2002 10:57:24 -0500 (EST) From: "Sumit Garg" To: "'Miguel Angel Chana \(machana\)'" Cc: Subject: RE: Request for Speaking Slot: draft-behringer-mpls-security-03.txt Date: Wed, 6 Nov 2002 10:57:24 -0500 Message-ID: <001801c285ad$33351b30$2ca11204@torrentnet.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01C28583.4A5F1330" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <5488D11C72941E4BA6A17C247CA67609BA8A15@xbe-ams-303.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-MS-TNEF-Correlator: 0000000096237D8E1BE5D311B0B00008C74B54A7E479BD00 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C28583.4A5F1330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit [snip] > > LDP specifications says: > > "An LSR is responsible for the consistency of the label > mappings it has distributed, and that its peers have these mappings" > > Assuming Downstream Unsolicited operation, with Independent > control mapping, that is the scenario you have in mind, I > think. At a given moment, LSP link between B and C is > working, and B binds a legitimate label, and B send it to its > peers. B is since then responsible of the consistency. Should > the LSP link fail, and no LSP continuity can be locally > assured, there are withdrawal mechanisms to deal with this. > If they don't work, this is a case of malfunction, or poor > implementation. 2 scearios: setup, teardown setup B has routing info, no binding from C, decides to send a map to A for D (this is independent) D sends a binding to C and also sends to A (via BGP). C has yet not propagated this to B (whatever reasons). A thinks LSP is up. We have the legitimate hole. teardown C withdraws from B. B is independent; doesn't withdraw from A. Or worst (even if ordered mode is used) is supposed to send a release to C before sending the withdraw to A. Again a LSP hole iff only for the transient Both these have nothing to do with malfunction/ sloppy implementation. Nowhere have the bindings got in-consistent. the problem is that B and C are agnostic of the VPN label. A and D are agnostic of the LSP end-to-end continuty. Inherent problem with the protocol and its multiple variations. Work arounds exist but demand "intelligent" config. And that independent mode not be used. These aren't the only holes. What if D had given explicit NULL to C. And then given a VPN label to A. Traffic on link b/w B and C would have the VPN as the inner label and the outer label would be link specific. Now what label is C supposed to slap on before forwarding it to D? Explicit NULL (remember end-of-stack bit MUST be set of explicit NULL) So now D will interpret incoming VPN traffic as IP traffic !! Soln: Don't use explicit NULL labels with VPNs. [snip] > > > My opinion is that only in case of malfunction this can > happen and that any reasonable implementation is able to deal > with this. And in any case, Ordered Control Mapping could be > a solution. > ordered is a certainly a solution. ------=_NextPart_000_0019_01C28583.4A5F1330 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhkPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHCwAGAAoAOQAAAAMAMAEB A5AGAHgKAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAABAAAAAUmVxdWVzdCBmb3IgU3BlYWtpbmcgU2xvdDogZHJhZnQtYmVocmluZ2Vy LW1wbHMtc2VjdXJpdHktMDMudHh0AAIBcQABAAAAFgAAAAHCha0yg/QnXrbj5EqOmdN9hdqmzWAA AAIBHQwBAAAAGQAAAFNNVFA6R0FSR0BUT1JSRU5UTkVULkNPTQAAAAALAAEOAAAAAEAABg4A7gUk rYXCAQIBCg4BAAAAGAAAAAAAAACWI32OG+XTEbCwAAjHS1SnIoMAAAMAFA4BAAAACwAfDgEAAAAC AQkQAQAAAFkGAABVBgAA9woAAExaRnXQJyrlAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD 5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsY Hw4wNREiDGBjAFAzCwkBZDM2FlALpiBbcnMDAHBdCqIKhAqAPgMK4x3yTERQIHNwxwWQBpAN4GF0 aQIgBCAgc2F5czodviJBoQOgTFNSIAQAIBggyx7wH6FpAmBlIAIQBcBcdGgigAWgAIFzDrBuYGN5 IG9mItMLYGJOZQMhHcUAwHBwC4Bn3QQgaQVAE+AEIGQjYQUQRGJ1DrBkLCAAcGT/ItEfcCWxBCAf AASQBCAT4F52IoAi4RQQJSciHb5BCQQQdW0lcSBEb3eDAIAmYGVhbSBVAIC/BvAN4CXACYAj0B8A ch9zpybgA/Ai4CBJJxBlHwD/LYECMB4nIyEmYAbwJSYm4H8nRAQgIuIE8AnwCsAfkCB+eQhgKCQL gCUgC4Am0UlnHici4AuAay4QwAVAYfggZ2koUDGxA3At8SbgLyFwHtAr8DMAICRwdHdpCeEgQibz QyGiHbZ33QWway9zJwI1gGIx4QQg/zNwInAzkB+AAMAOsCRENyb3FBAnESXBdDDwJ5IdtifT/zMg NYAhsQCQI6AoYwOgIeqnI+UjKTMgU2gIYGwnILcyWCKANHdmC3A5FW4w8Pc0ci6yC4B1JcAjwB9g A6DLJHAkQG8fYGxsI8Adtv8mACqQGCEvogSQIoAKwCKA9S0iZCygdwdAJSAFkBPg+QMAc20wITDw AQBFIS0jtzLRO1Edtkkj8yPAZAIg/icFQDayL6IhsSGxM3AfYMcosSPhAMBsZnUjoCzEvwWxIhAF sR22B3ALUGU0Ev8fczMgHiUdVBRAMIEwwiAQ8TmRdHVwL6FN8UgwKyD/HVpOcx1aNYAl8gNgJqAq wv8LgAIQJuBA4TeiKsIDUhIg+ybgBYFpAQBF4zmjM3AlMcU6EkEik0QgKEj2MeH9LaYpVYE5ojfi UqY6ITXgnycCB0Ar0FclVQModgcwcTVwR1ApTME14CXyebcUIEDRBUBwA2AKsGc4kU8nIjASMPA1 gCh3J1Fl/yhQBcArYSvQAIBaQlUwMtPfBCA0ciGxTqBMwVcigCg29zgaPpAicC4dWk7vHYE14LdE pgQgUyNCO2VWSTtIIa8HkEhTRLVTFEFMwU8FwP82sSNwVaBdAQOgBpBK0QSB7yxBBGJewxQQZFbw O6JOoP8iEGlBVBkYICJwSaJYMyRw/yKhMGEtwVfzIvFl91UCMyF/W7AxoTNwNHJgwmfxaBFu/0LB IqYmYAByLfFQe1swRrL/KKIoM1shMuFYE0gwLRRKGb4vHuAXsCVQI8BL704rEG9EE1+HUqUEIGdb MQuALf0jJ3QzICLiW2EiYSuQMBP/J2E1hkRiW6BA4CNwDeAj1vhWUE4kRF3TJwJVkHpv6z+FLcEt OiAtObJBVUHQ/0zBLXBEEi4BeOZGhXjDOiB3F5Em8yeSbT6wH4BMASD+djDBH3RfIjbBRFEIYDfC fw7AI2E08CagRiEDgScgIqcLgA6wQrBpZy3xIiMS/R9AZ13SJxctiWizWyJCQfdpMmELHVRUKJNE YUhSIuL3bzNgwjtRVydTI/BVkBPgPycgM5QOwAtQLAIHsFVM/kxYI4cHM8EzlDNwe6dtdb5ULKAB IHsCA6A0tC8H4P81hjawPrJfh3uiJgEi4guA/m4SgSRUJwQ9ISahlMaS5P9CQjTCHvZ1pC0QJ1Ik VCGx/zXgacsLYFTgkaFrxSKhRRCHCyBR0zoDRD8gRY3bfigYIAeABtASgX5iI+AtDyNwANA04SXB TVVTVN9CMhQRI9KNy1bwUzDwQOD/B+BVkAPwQrAxkZXhW2Ba8X874QNwKsJ7onABkVMmAUkzHtCj BiEhHVqgsGxu/05QKwBIUmkxjb0kUwQgLSN3e6E7UImfChz/Hgkdtk3/I8ElYR+ReVdvMzGhSZ+R of9I80ICHbYT4CVQj9InFgBw/yPAXVQBoG7CS/tJMyJiRgb/NjdGmIcybhKwoa1CJuBnEPdoVAhQ LtRNJUQjEZalQvf/HuAG8FGxTKEdvGg2SUQEkC8BkAuAQsG4T328YAAAAB4AQhABAAAAPwAAADw1 NDg4RDExQzcyOTQxRTRCQTZBMTdDMjQ3Q0E2NzYwOUJBOEExNUB4YmUtYW1zLTMwMy5jaXNjby5j b20+AAADAAlZAQAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAEgAggBgAAAAAA wAAAAAAAAEYAAAAAEYUAAAAAAAADABGACCAGAAAAAADAAAAAAAAARgAAAABShQAAtnQBAB4AEoAI IAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAADACOACCAGAAAAAADAAAAAAAAARgAA AAABhQAAAAAAAAsAJYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwAmgAggBgAAAAAAwAAA AAAAAEYAAAAADoUAAAAAAAADACeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAZoAIIAYA AAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAgH4DwEAAAAQAAAAliN9jhvl0xGwsAAIx0tUpwIB+g8B AAAAEAAAAJYjfY4b5dMRsLAACMdLVKcCAfsPAQAAAFUAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAA bXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEQ6XFVzZXJzXGdhcmdcT3V0bG9va1xzdW1p dC5wc3QAAAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwOTYyMzdEOEUxQkU1 RDMxMUIwQjAwMDA4Qzc0QjU0QTdFNDc5QkQwMAAAAAADAAYQJACPpAMABxD/BgAAAwAQEAEAAAAD ABEQAQAAAB4ACBABAAAAZQAAAFNOSVBMRFBTUEVDSUZJQ0FUSU9OU1NBWVM6IkFOTFNSSVNSRVNQ T05TSUJMRUZPUlRIRUNPTlNJU1RFTkNZT0ZUSEVMQUJFTE1BUFBJTkdTSVRIQVNESVNUUklCVVRF RCxBTkQAAAAAwAI= ------=_NextPart_000_0019_01C28583.4A5F1330-- From owner-mpls@UU.NET Wed Nov 6 11:01:32 2002 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 ESMTP id LAA28974 for ; Wed, 6 Nov 2002 11:01:32 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvc07548 for ; Wed, 6 Nov 2002 16:03:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnvc05852; Wed, 6 Nov 2002 16:03:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnvc14177 for mpls-outgoing; Wed, 6 Nov 2002 16:02:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnvc14123 for ; Wed, 6 Nov 2002 16:02: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 QQnnvc06477 for ; Wed, 6 Nov 2002 16:02:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvc04800 for ; Wed, 6 Nov 2002 16:02:18 GMT Received: from zcars04e.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnnvc04795 for ; Wed, 6 Nov 2002 16:02:17 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA6G1nv14655; Wed, 6 Nov 2002 11:01:49 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 11:01:50 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05EB513B@zcard031.ca.nortel.com> From: "David Allan" To: George Swallow Cc: Der-Hwa Gan , "Gray, Eric" , mpls@UU.NET, swallow@cisco.com Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Wed, 6 Nov 2002 11:01:44 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi George: Thanks for the clarification, tells me I shouldn't have been the person to answer this question as I appear to be confusing tunnel ID and LSP ID. rgds Dave > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, November 06, 2002 10:18 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: George Swallow; Der-Hwa Gan; Gray, Eric; mpls@UU.NET; > swallow@cisco.com > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability > issue" (fwd) > > > > > I was envisioning a case where a bandwidth change was not a > separate tunnel > > setup, the LSP ID changed without any interruption or change in the > > conntectivity of the path . If there is build the new then > tear down the > > old, then there is no gap in any monitoring case. > > If you change the LSP-ID, that changes the sender-template. Ipso > facto a new setup. > > > As for TTSI, it's simply a node specific LSP Identifier > that allows for an > > IPv4/v6 LSR ID and 32 bits for an LSP identifier. The > assumption is that the > > originating LSR most usefully administers LSP-IDs > independently of the > > individual control protocol used. The initial draft of > Y.1711 was focused on > > P2P ER-LSPs which meant RSVP-TE or CR-LDP, hence the > stipulation that the > > first two bytes of the LSP-ID were padded with zeros to > align with LSP-ID as > > defined in the signalling protocols. If there is a problem > with this, it is > > not leaping out at me.... > > As we use it, an (RSVP-TE) LSP-ID is *only* unique to the tunnel. We > just use it as an instance number and increment it when we reroute or > change bandwidth. If I setup five tunnels they will have five > different tunnel-IDs, but they can *all* have the same LSP-ID. > > To uniquely identify a TE-Tunnel LSP. you need *all* of the fields in > the session and sender-template objects. That why we carry those in > LSP ping. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Wed Nov 6 11:05:02 2002 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 ESMTP id LAA29175 for ; Wed, 6 Nov 2002 11:05:02 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvc23063 for ; Wed, 6 Nov 2002 16:07:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnvc21453; Wed, 6 Nov 2002 16:06:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnvc20012 for mpls-outgoing; Wed, 6 Nov 2002 16:06:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnvc19988 for ; Wed, 6 Nov 2002 16:06:18 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 QQnnvc27109 for ; Wed, 6 Nov 2002 16:04:39 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvc19534 for ; Wed, 6 Nov 2002 16:04:39 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnnvc19530 for ; Wed, 6 Nov 2002 16:04:38 GMT Received: from utfors.se ([195.58.105.93]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id gA6G4A28028905; Wed, 6 Nov 2002 17:04:10 +0100 (MET) Message-ID: <3DC93D7B.8020906@utfors.se> Date: Wed, 06 Nov 2002 17:04:11 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: MPLS wg , Scott Bradner , George Swallow Subject: Re: agenda for the mpls mib review meeting References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit maybe - but it does not show up in the repository yet, will change when I see the annoucment. Have made a note. /Loa Wijnen, Bert (Bert) wrote: >>Comments/questions/additions/changes to me before the meeting start. >> >> 5.5 tc mib >> > > > I think the TC-MIB is at rev 05. > > Bert -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Wed Nov 6 11:32:56 2002 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 ESMTP id LAA00496 for ; Wed, 6 Nov 2002 11:32:56 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnve13748 for ; Wed, 6 Nov 2002 16:35:22 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnve11821; Wed, 6 Nov 2002 16:34:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnve22957 for mpls-outgoing; Wed, 6 Nov 2002 16:34:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnve22950 for ; Wed, 6 Nov 2002 16:34:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnve17713 for ; Wed, 6 Nov 2002 16:33:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnve10663 for ; Wed, 6 Nov 2002 16:33:19 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnnve10656 for ; Wed, 6 Nov 2002 16:33:18 GMT Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA6GXHQ05418 for ; Wed, 6 Nov 2002 11:33:17 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 11:33:17 -0500 Message-ID: From: "Houck, David J (David)" To: "'George Swallow'" , David Allan Cc: Der-Hwa Gan , "Gray, Eric" , mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Wed, 6 Nov 2002 11:33:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I have a question about the "build the new then tear down the old" approach for decreasing TE-LSP bandwidth. If a link in the path is at capacity, then wouldn't the "build new" request be denied. If so, it would be a lot easier just to decrease the bandwidth on the existing TE-LSP. Dave Houck 732-949-1290 -----Original Message----- From: George Swallow [mailto:swallow@cisco.com] Sent: Wednesday, November 06, 2002 10:18 AM To: David Allan Cc: George Swallow; Der-Hwa Gan; Gray, Eric; mpls@UU.NET; swallow@cisco.com Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > I was envisioning a case where a bandwidth change was not a separate tunnel > setup, the LSP ID changed without any interruption or change in the > conntectivity of the path . If there is build the new then tear down the > old, then there is no gap in any monitoring case. If you change the LSP-ID, that changes the sender-template. Ipso facto a new setup. > As for TTSI, it's simply a node specific LSP Identifier that allows for an > IPv4/v6 LSR ID and 32 bits for an LSP identifier. The assumption is that the > originating LSR most usefully administers LSP-IDs independently of the > individual control protocol used. The initial draft of Y.1711 was focused on > P2P ER-LSPs which meant RSVP-TE or CR-LDP, hence the stipulation that the > first two bytes of the LSP-ID were padded with zeros to align with LSP-ID as > defined in the signalling protocols. If there is a problem with this, it is > not leaping out at me.... As we use it, an (RSVP-TE) LSP-ID is *only* unique to the tunnel. We just use it as an instance number and increment it when we reroute or change bandwidth. If I setup five tunnels they will have five different tunnel-IDs, but they can *all* have the same LSP-ID. To uniquely identify a TE-Tunnel LSP. you need *all* of the fields in the session and sender-template objects. That why we carry those in LSP ping. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 6 11:40:02 2002 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 ESMTP id LAA00822 for ; Wed, 6 Nov 2002 11:40:01 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnve26268 for ; Wed, 6 Nov 2002 16:42:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnve23958; Wed, 6 Nov 2002 16:41:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnve23395 for mpls-outgoing; Wed, 6 Nov 2002 16:40:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnve23381 for ; Wed, 6 Nov 2002 16:40:14 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 QQnnve08526 for ; Wed, 6 Nov 2002 16:39:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnve25254 for ; Wed, 6 Nov 2002 16:39:10 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnve25250 for ; Wed, 6 Nov 2002 16:39:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA09241 for ; Wed, 6 Nov 2002 11:39:09 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6Gd9710717 for mpls@uu.net; Wed, 6 Nov 2002 11:39:09 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnve23272 for ; Wed, 6 Nov 2002 16:38:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnve08516 for ; Wed, 6 Nov 2002 16:36:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnve14833 for ; Wed, 6 Nov 2002 16:35:52 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnnve14387 for ; Wed, 6 Nov 2002 16:35:40 GMT Received: (qmail 21551 invoked by uid 104); 6 Nov 2002 16:35:25 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4231. . Clean. Processed in 0.838904 secs); 06 Nov 2002 16:35:25 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 6 Nov 2002 16:35:24 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id gA6GZOQ11574; Wed, 6 Nov 2002 08:35:24 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id <40J3PXKK>; Wed, 6 Nov 2002 08:35:23 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03A5E@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , David Allan Cc: Der-Hwa Gan , "Gray, Eric" , mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Wed, 6 Nov 2002 08:35:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk The LSP-ID defined in Y.1711 is essentially a combination of LSP-ID + Tunnel-ID as defined in RSVP-TE. In the current version of Y.1711, 4 bytes are assigned to this. However the current version of Y.1711 sets the first 2 octets of this field to zero for future use. Therefore two methods are possible: 1) Compress the LSP-ID + Tunnel-ID in to 2 bytes 2) You could use the first 2 octets, and encode the 2-byte RSVP-TE LSP-ID in the first 2 octets of Y.1711 LSP-ID and encode the 2-byte RSVP-TE Tunnel-ID in the last 2 octets of Y.1711 LSP-ID. Just a question, isn't it possible to change the LSP by changing the Tunnel-ID, rather than LSP-ID? -Shahram > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, November 06, 2002 10:18 AM > To: David Allan > Cc: George Swallow; Der-Hwa Gan; Gray, Eric; mpls@UU.NET; > swallow@cisco.com > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability > issue" (fwd) > > > > > I was envisioning a case where a bandwidth change was not a > separate tunnel > > setup, the LSP ID changed without any interruption or change in the > > conntectivity of the path . If there is build the new then > tear down the > > old, then there is no gap in any monitoring case. > > If you change the LSP-ID, that changes the sender-template. Ipso > facto a new setup. > > > As for TTSI, it's simply a node specific LSP Identifier > that allows for an > > IPv4/v6 LSR ID and 32 bits for an LSP identifier. The > assumption is that the > > originating LSR most usefully administers LSP-IDs > independently of the > > individual control protocol used. The initial draft of > Y.1711 was focused on > > P2P ER-LSPs which meant RSVP-TE or CR-LDP, hence the > stipulation that the > > first two bytes of the LSP-ID were padded with zeros to > align with LSP-ID as > > defined in the signalling protocols. If there is a problem > with this, it is > > not leaping out at me.... > > As we use it, an (RSVP-TE) LSP-ID is *only* unique to the tunnel. We > just use it as an instance number and increment it when we reroute or > change bandwidth. If I setup five tunnels they will have five > different tunnel-IDs, but they can *all* have the same LSP-ID. > > To uniquely identify a TE-Tunnel LSP. you need *all* of the fields in > the session and sender-template objects. That why we carry those in > LSP ping. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Wed Nov 6 12:42:26 2002 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 ESMTP id MAA03613 for ; Wed, 6 Nov 2002 12:42:26 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvi17119 for ; Wed, 6 Nov 2002 17:44:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnvi14936; Wed, 6 Nov 2002 17:43:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnvi15825 for mpls-outgoing; Wed, 6 Nov 2002 17:43:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnvi15817 for ; Wed, 6 Nov 2002 17:43:08 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 QQnnvi03167 for ; Wed, 6 Nov 2002 17:42:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvi25514 for ; Wed, 6 Nov 2002 17:42:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnvi25499 for ; Wed, 6 Nov 2002 17:42:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA14176 for ; Wed, 6 Nov 2002 12:42:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6Hg5d17066 for mpls@uu.net; Wed, 6 Nov 2002 12:42:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnvi15582 for ; Wed, 6 Nov 2002 17:40:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnvi17219 for ; Wed, 6 Nov 2002 17:39:09 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvi11640 for ; Wed, 6 Nov 2002 17:39:09 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnnvi11629 for ; Wed, 6 Nov 2002 17:39:08 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA6HdHBj001944; Wed, 6 Nov 2002 12:39:17 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn1-93.cisco.com [10.86.240.93]) by bucket.cisco.com (Mirapoint) with ESMTP id ACB61915; Wed, 6 Nov 2002 12:38:58 -0500 (EST) Message-Id: <4.3.2.7.2.20021106123815.02e22570@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Nov 2002 12:38:53 -0500 To: Loa Andersson From: "Thomas D. Nadeau" Subject: Re: agenda for the mpls mib review meeting Cc: MPLS wg , Scott Bradner , Bert Wijnen , George Swallow In-Reply-To: <3DC8F7E6.30705@utfors.se> 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 MAA03613 Also, FYI Joan and I have agreed to give the summary of events to the WG during the full meeting, so we will work up some slides after the Sat. meeting to lead the discussion during the full MPLS WG meeting. --Tom >the agenda for the open MPLS MIG review meeting will be found at: > >http://urax.utfors.net/~loa/mpls-mib-review.htm > >and in a text version below. > >Comments/questions/additions/changes to me before the meeting start. > >/Loa > >-------------------- > >MPLS MIB review >Atlanta November 16, 12 AM to 6 PM, >at the Cisco office at: > >The Point Complex, Building 500 > >Agenda (to be bashed) >1. Opening remarks (Loa) >2. AD views (Bert) >3. On behalf of the mib - authors (proposed Tom and/or Joan) >4. MPLS MIB overview (Tom/Joan) > >5. The MIBs one by one in some logical order > 5.1 lsr mib > > 5.2 ldp mib > > 5.3 ftn mib > > 5.4 te mib > > 5.5 tc mib > > 5.6 bundle mib (Tom) > > 5.7 tewg mib (Kireeti) > >6. GMPLS considerations >7. Summary of input and actions. > 7.1 Report to mpls wg meeting > 7.2 id tracker input >------------------------------ >Directions from the airport: > >At the Atlanta Airport: Leave the airport following direction indicators >toward I-75 North. >Take I-75 North to the I-85 North exit. >Travel on I-85 North to Hwy GA-400 North (toll road) >While traveling on GA-400, look for the Northridge Road Exit >Turn right at the top of the exit and cross over GA-400. >Turn right into The Point complex. >Building 500 is on the right inside the complex. >Note: According to the hosts it is "quite close to the hotel, take a taxi" > >-- > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > Råsundavägen 12 > Box 525, 169 29 Solna > Office +46 8 5270 2000 > Office direct +46 8 5270 5038 > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > WWW www.utfors.se > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Wed Nov 6 12:49:50 2002 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 ESMTP id MAA04040 for ; Wed, 6 Nov 2002 12:49:49 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvj08484 for ; Wed, 6 Nov 2002 17:52:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnvj06513; Wed, 6 Nov 2002 17:51:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnvj16823 for mpls-outgoing; Wed, 6 Nov 2002 17:50:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnvj16815 for ; Wed, 6 Nov 2002 17:50:42 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 QQnnvj26263 for ; Wed, 6 Nov 2002 17:49:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvj24093 for ; Wed, 6 Nov 2002 17:49:03 GMT Received: from blooper.utfors.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnnvj23783 for ; Wed, 6 Nov 2002 17:48:53 GMT Received: from utfors.se ([195.58.105.122]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id gA6HmC28001772; Wed, 6 Nov 2002 18:48:12 +0100 (MET) Message-ID: <3DC955DD.2090603@utfors.se> Date: Wed, 06 Nov 2002 18:48:13 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: MPLS wg , Scott Bradner , Bert Wijnen , George Swallow Subject: Re: agenda for the mpls mib review meeting References: <4.3.2.7.2.20021106123815.02e22570@bucket.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Yes - on the preliminary agenda I've put together you are right close to the top of it http://62.119.0.68/~loa/MPLS-agenda-for-Atlanta.htm George will put out the first versioniof the final agenda. /Loa Thomas D. Nadeau wrote: > > Also, FYI Joan and I have agreed to give the summary > of events to the WG during the full meeting, so we will > work up some slides after the Sat. meeting to lead the > discussion during the full MPLS WG meeting. > > --Tom > > >> the agenda for the open MPLS MIG review meeting will be found at: >> >> http://urax.utfors.net/~loa/mpls-mib-review.htm >> >> and in a text version below. >> >> Comments/questions/additions/changes to me before the meeting start. >> >> /Loa >> >> -------------------- >> >> MPLS MIB review >> Atlanta November 16, 12 AM to 6 PM, >> at the Cisco office at: >> >> The Point Complex, Building 500 >> >> Agenda (to be bashed) >> 1. Opening remarks (Loa) >> 2. AD views (Bert) >> 3. On behalf of the mib - authors (proposed Tom and/or Joan) >> 4. MPLS MIB overview (Tom/Joan) >> >> 5. The MIBs one by one in some logical order >> 5.1 lsr mib >> >> 5.2 ldp mib >> >> 5.3 ftn mib >> >> 5.4 te mib >> >> 5.5 tc mib >> >> 5.6 bundle mib (Tom) >> >> 5.7 tewg mib (Kireeti) >> >> 6. GMPLS considerations >> 7. Summary of input and actions. >> 7.1 Report to mpls wg meeting >> 7.2 id tracker input >> ------------------------------ >> Directions from the airport: >> >> At the Atlanta Airport: Leave the airport following direction indicators >> toward I-75 North. >> Take I-75 North to the I-85 North exit. >> Travel on I-85 North to Hwy GA-400 North (toll road) >> While traveling on GA-400, look for the Northridge Road Exit >> Turn right at the top of the exit and cross over GA-400. >> Turn right into The Point complex. >> Building 500 is on the right inside the complex. >> Note: According to the hosts it is "quite close to the hotel, take a >> taxi" >> >> -- >> Loa Andersson >> Chief Architect, >> Utfors Research, Architecture and Future Lab (URAX) >> Utfors AB >> Råsundavägen 12 >> Box 525, 169 29 Solna >> Office +46 8 5270 2000 >> Office direct +46 8 5270 5038 >> Mobile +46 70 848 5038 >> Email loa.andersson@utfors.se >> WWW www.utfors.se >> > > Success is relative; the more success, the more relatives. -Anonymous > > -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Wed Nov 6 13:39:21 2002 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 ESMTP id NAA06123 for ; Wed, 6 Nov 2002 13:39:21 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnuy25181; Wed, 6 Nov 2002 15:00:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnuy14455 for mpls-outgoing; Wed, 6 Nov 2002 15:00:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnuy13882 for ; Wed, 6 Nov 2002 15:00:25 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 QQnnux08254 for ; Wed, 6 Nov 2002 14:59:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnux25079 for ; Wed, 6 Nov 2002 14:59:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnux25061 for ; Wed, 6 Nov 2002 14:59:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA27594 for ; Wed, 6 Nov 2002 09:59:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6Ex5r01147 for mpls@uu.net; Wed, 6 Nov 2002 09:59:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnux11647 for ; Wed, 6 Nov 2002 14:58:07 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 QQnnux11804 for ; Wed, 6 Nov 2002 14:57:42 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnux22792 for ; Wed, 6 Nov 2002 14:57:42 GMT Received: from ams-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ams-msg-core-1.cisco.com [144.254.74.60]) id QQnnux22784 for ; Wed, 6 Nov 2002 14:57:41 GMT Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA6EuI7K020508; Wed, 6 Nov 2002 15:56:20 +0100 (MET) Received: from xbe-ams-303.cisco.com ([144.254.75.93]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 6 Nov 2002 15:57:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Request for Speaking Slot: draft-behringer-mpls-security-03.txt Date: Wed, 6 Nov 2002 15:57:16 +0100 Message-ID: <5488D11C72941E4BA6A17C247CA67609BA8A15@xbe-ams-303.cisco.com> Thread-Topic: Request for Speaking Slot: draft-behringer-mpls-security-03.txt Thread-Index: AcKFl6lphvSS7QBSTnKwBQ50QjN4vwABqtNg From: "Miguel Angel Chana (machana)" To: "Sumit Garg" Cc: X-OriginalArrivalTime: 06 Nov 2002 14:57:16.0964 (UTC) FILETIME=[CC5E0640:01C285A4] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA06123 Hello: Some comments in line: > -----Original Message----- > From: Sumit Garg [mailto:garg@torrentnet.com] > Sent: miércoles, 06 de noviembre de 2002 14:21 > To: Michael Behringer (mbehring); George Swallow (swallow); > 'Loa Andersson' > Cc: mpls@UU.NET > Subject: RE: Request for Speaking Slot: > draft-behringer-mpls-security-03.txt > > > Got only as far as page 6. > > Some comments: > -------------- > > Page 6, you write: > > "Traffic separation is achieved by prepending VPN-specific > labels to the packets, so that a packet can also on the core > be identified as belonging to a specific VPN. " > > This assumes and implies that the core LSRs know that the > label is a VPN label; OR more generically that there is > something special about a VPN label. My understanding is > there isn't. Labels are not looked at in any specific > context. Infact with independent LSP setup, teardown and > local repair one can run into scenarios where the VPN traffic > doesn't stay so private. Example: > > VPN1----A----B----C----D----VPN2 > > A and D are PEs and B and C and Ps. LSP from A to D comes up (or goes > down) independently and for this example assume the LSP > segment between B and C is missing. A thinks there is a LSP LDP specifications says: "An LSR is responsible for the consistency of the label mappings it has distributed, and that its peers have these mappings" Assuming Downstream Unsolicited operation, with Independent control mapping, that is the scenario you have in mind, I think. At a given moment, LSP link between B and C is working, and B binds a legitimate label, and B send it to its peers. B is since then responsible of the consistency. Should the LSP link fail, and no LSP continuity can be locally assured, there are withdrawal mechanisms to deal with this. If they don't work, this is a case of malfunction, or poor implementation. > to D (doesn't know of the hole between B and C) Traffic from > A goes to B with the outer label for the LSP to D and the > inner label for VPN sites connected at A and D > > B doesn't have an outgoing label; does a pop of the outer > label and then as the end of stack bit is not set looks at > the inner label. This label might have local significance at > B and so the traffic may ge switched to the wrong LSP and > therefore the wrong desitation. > > This is a consequence of independent LSP setup. End to end > LSP continuty cannot be guaranteed. One possible option is > to set the opcode on the incoming lable on B as discard and > not pop and lookup. > > Hope you get the idea. And maybe the MPLS gurus can clarify my ideas? > My opinion is that only in case of malfunction this can happen and that any reasonable implementation is able to deal with this. And in any case, Ordered Control Mapping could be a solution. > Some nits: > ---------- > > Page number on page 1 is missing. > > Page 2, after the bullet list there is a type ">From " > > Doc formatting can be improved so that page numbers do fall > on end of page; most authors do it by embedding a form feed > (a CTRL-L). > > > General observations: > --------------------- > > Don't see the point of this document wrt the WG. What are we > trying to achieve? Seems more like a white paper. But then > these are my 2c. > > > /Sumit > > > George, Loa, > > > > Recently I submitted an updated version of > > draft-behringer-mpls-security-03.txt. If you consider this work of > > interest to the MPLS WG, I would like to request a speaking slot at > > the Atlanta > > meeting. > > > > Thanks, > > Michael > > > > From owner-mpls@UU.NET Wed Nov 6 16:21:49 2002 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 ESMTP id QAA12831 for ; Wed, 6 Nov 2002 16:21:49 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvx25780 for ; Wed, 6 Nov 2002 21:24:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnvx23741; Wed, 6 Nov 2002 21:23:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnvx09941 for mpls-outgoing; Wed, 6 Nov 2002 21:22:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnvx09936 for ; Wed, 6 Nov 2002 21:22: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 QQnnvx29635 for ; Wed, 6 Nov 2002 21:22:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvx18476 for ; Wed, 6 Nov 2002 21:22:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnvx18467 for ; Wed, 6 Nov 2002 21:22:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA05976 for ; Wed, 6 Nov 2002 16:22:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6LM5r00970 for mpls@uu.net; Wed, 6 Nov 2002 16:22:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnvx09852 for ; Wed, 6 Nov 2002 21:20:41 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 QQnnvx21822 for ; Wed, 6 Nov 2002 21:19:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvx16206 for ; Wed, 6 Nov 2002 21:19:45 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnvx16198 for ; Wed, 6 Nov 2002 21:19:44 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA05780; Wed, 6 Nov 2002 16:19:44 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA05809; Wed, 6 Nov 2002 16:19:44 -0500 (EST) Message-Id: <200211062119.QAA05809@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: "'George Swallow'" , David Allan , Der-Hwa Gan , "Gray, Eric" , mpls@UU.NET, swallow@cisco.com Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of "Wed, 06 Nov 2002 08:35:22 PST." <4B6D09F3B826D411A67300D0B706EFDEB03A5E@nt-exch-yow.pmc-sierra.bc.ca> Date: Wed, 06 Nov 2002 16:19:43 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Shahram - > The LSP-ID defined in Y.1711 is essentially a combination of LSP-ID + Tunnel-ID > as defined in RSVP-TE. > > In the current version of Y.1711, 4 bytes are assigned to > this. However the current version of Y.1711 sets the first 2 octets of > this field to zero for future use. Therefore two methods are possible: > > 1) Compress the LSP-ID + Tunnel-ID in to 2 bytes This uses up all the space. If RSVP-TE is the only application for Y.1711 then this would be acceptable. But since it's called MPLS OAM, I assume there were other apps in mind as well. > 2) You could use the first 2 octets, and encode the 2-byte RSVP-TE > LSP-ID in the first 2 octets of Y.1711 LSP-ID and encode the 2-byte > RSVP-TE Tunnel-ID in the last 2 octets of Y.1711 LSP-ID. Not enough space to be future proof. We already have requests to support thousands of tunnels. If I give just 4 bits to LSP-ID that only leaves 4k tunnels. > Just a question, isn't it possible to change the LSP by changing the > Tunnel-ID, rather than LSP-ID? You cannot share bandwidth between different RSVP sessions only between different senders. The tunnel ID is in the session ID to say "the various LSPs with this identification all belong to the same tunnel". The LSP-ID is in the sender template so that they can be distingueshed, yet associated via the session and thus can share bandwidth. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 6 16:30:14 2002 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 ESMTP id QAA13155 for ; Wed, 6 Nov 2002 16:30:14 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvy08343 for ; Wed, 6 Nov 2002 21:32:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnvy05491; Wed, 6 Nov 2002 21:30:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnvy10749 for mpls-outgoing; Wed, 6 Nov 2002 21:30:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnvy10728 for ; Wed, 6 Nov 2002 21:30:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnvx17501 for ; Wed, 6 Nov 2002 21:29:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvx24608 for ; Wed, 6 Nov 2002 21:29:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnvx24604 for ; Wed, 6 Nov 2002 21:29:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA06632 for ; Wed, 6 Nov 2002 16:29:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6LT7O02068 for mpls@uu.net; Wed, 6 Nov 2002 16:29:07 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnvx10489 for ; Wed, 6 Nov 2002 21:27:25 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 QQnnvx15402 for ; Wed, 6 Nov 2002 21:27:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvx22619 for ; Wed, 6 Nov 2002 21:27:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnvx22611 for ; Wed, 6 Nov 2002 21:27:04 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA06462; Wed, 6 Nov 2002 16:27:04 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA05834; Wed, 6 Nov 2002 16:27:04 -0500 (EST) Message-Id: <200211062127.QAA05834@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "Houck, David J (David)" cc: "'George Swallow'" , David Allan , Der-Hwa Gan , "Gray, Eric" , mpls@UU.NET, swallow@cisco.com Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of "Wed, 06 Nov 2002 11:33:15 EST." Date: Wed, 06 Nov 2002 16:27:04 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > I have a question about the "build the new then tear down the old" > approach for decreasing TE-LSP bandwidth. If a link in the path is at > capacity, then wouldn't the "build new" request be denied. No. Suggest you read RFC3209 section 4.6.4. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 6 16:30:15 2002 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 ESMTP id QAA13167 for ; Wed, 6 Nov 2002 16:30:15 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvy26578 for ; Wed, 6 Nov 2002 21:32:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnvy25577; Wed, 6 Nov 2002 21:32:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnvy10940 for mpls-outgoing; Wed, 6 Nov 2002 21:31:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnvy10935 for ; Wed, 6 Nov 2002 21:31:38 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 QQnnvy27159 for ; Wed, 6 Nov 2002 21:30:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvy05228 for ; Wed, 6 Nov 2002 21:30:43 GMT Received: from mgw.cosinecom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.88.104.199]) id QQnnvy05210 for ; Wed, 6 Nov 2002 21:30:42 GMT Received: from imchub1.cosinecom.com (imchub1.cosinecom.com [172.21.8.23]) by mgw.cosinecom.com (Mirapoint) with ESMTP id ABX73842; Wed, 6 Nov 2002 13:29:59 -0800 (PST) Received: by imchub1.cosinecom.com with Internet Mail Service (5.5.2655.55) id ; Wed, 6 Nov 2002 13:30:00 -0800 Message-ID: <9F92A36A29DA854785B3ECCD75D04ABC97FF00@exchsrv3.cosinecom.com> From: Francois Lemarchand To: Jim Boyle Cc: mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Wed, 6 Nov 2002 13:29:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C285DB.A7E797E0" 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_01C285DB.A7E797E0 Content-Type: text/plain; charset="iso-8859-1" Ok, Then it's maybe not a technical argument as such but a best practice to reduce the number of special cases : changing the LSP-ID for bandwidth increase/ decrease regardless of a path change. Although it's not optimal it didn't prevent using FF style. So I didn't see a contradiction by generalising this LSP-ID change while keeping FF as one of the reservation style. Francois -----Original Message----- From: Jim Boyle [mailto:jboyle@pdnets.com] Sent: mardi 5 novembre 2002 14:33 To: Francois Lemarchand Cc: mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Yes, we all agree that as the spec states, when the path changes the LSP ID should be changed. The issue is that one implementation has issues if the LSP ID of a transit LSP does not change when the bandwidth decreases. Alternatively you could state that the issue is that one (or two) implementations are unique in that they don't change the LSP ID when they decrease the bandwidth. So the options at this point are: o) address the implementation with transit issue when bandwidth decreases and LSP ID is not changed. o) require LSP ID change during BW decrease in the spec and address the implementation(s) which currently don't do this. We've had a few people weigh in on both sides of this, so I'm not sure if there is any resolution. Jim On Mon, 4 Nov 2002, Francois Lemarchand wrote: > Hello ! > > For re-optimisation I guess. If there is a need to change > the path when bandwidth increase then it's probably usefull > to return to the old path when bandwidth decrease (probably > more optimal). > > So changing path probably justify make-before-break and > LSP-ID change. > > Did I miss somthing ? > > Francois > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: lundi 4 novembre 2002 20:27 > To: mpls@UU.NET > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > > > > Hi All, > > I'd like to re-iterate Der-Hwa's question: > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote: > > > It is perhaps more appropriate to ask what is the technical reason that a > > new ID is required to get bandwidth decrease? > > Is there a technical reason that someone can articulate? Along the > same lines, is make-before-break needed on bandwidth *decrease*? > > Thanks, > Kireeti. > ------_=_NextPart_001_01C285DB.A7E797E0 Content-Type: text/html; charset="iso-8859-1" RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)

Ok,

Then it's maybe not a technical argument as such
but a best practice to reduce the number of special
cases : changing the LSP-ID for bandwidth increase/
decrease regardless of a path change.

Although it's not optimal it didn't prevent using FF
style. So I didn't see a contradiction by generalising
this LSP-ID change while keeping FF as one of the
reservation style.

Francois


-----Original Message-----
From: Jim Boyle [mailto:jboyle@pdnets.com]
Sent: mardi 5 novembre 2002 14:33
To: Francois Lemarchand
Cc: mpls@UU.NET
Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)




Yes, we all agree that as the spec states, when the path changes the LSP
ID should be changed.

The issue is that one implementation has issues if the LSP ID of
a transit LSP does not change when the bandwidth decreases.  Alternatively
you could state that the issue is that one (or two) implementations are
unique in that they don't change the LSP ID when they decrease the
bandwidth.

So the options at this point are:

o) address the implementation with transit issue when bandwidth decreases
and LSP ID is not changed.

o) require LSP ID change during BW decrease in the spec and address the
implementation(s) which currently don't do this.

We've had a few people weigh in on both sides of this, so I'm not sure
if there is any resolution.

Jim

On Mon, 4 Nov 2002, Francois Lemarchand wrote:

> Hello !
>
> For re-optimisation I guess. If there is a need to change
> the path when bandwidth increase then it's probably usefull
> to return to the old path when bandwidth decrease (probably
> more optimal).
>
> So changing path probably justify make-before-break and
> LSP-ID change.
>
> Did I miss somthing ?
>
> Francois
>
> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: lundi 4 novembre 2002 20:27
> To: mpls@UU.NET
> Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)
>
>
>
> Hi All,
>
> I'd like to re-iterate Der-Hwa's question:
>
> On Thu, 31 Oct 2002, Der-Hwa Gan wrote:
>
> > It is perhaps more appropriate to ask what is the technical reason that a
> > new ID is required to get bandwidth decrease?
>
> Is there a technical reason that someone can articulate?  Along the
> same lines, is make-before-break needed on bandwidth *decrease*?
>
> Thanks,
> Kireeti.
>


------_=_NextPart_001_01C285DB.A7E797E0-- From owner-mpls@UU.NET Wed Nov 6 16:45:28 2002 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 ESMTP id QAA13861 for ; Wed, 6 Nov 2002 16:45:28 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvz11265 for ; Wed, 6 Nov 2002 21:47:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnvz10115; Wed, 6 Nov 2002 21:47:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnvz12511 for mpls-outgoing; Wed, 6 Nov 2002 21:46:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnvz12502 for ; Wed, 6 Nov 2002 21:46: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 QQnnvz17340 for ; Wed, 6 Nov 2002 21:46:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnvz23140 for ; Wed, 6 Nov 2002 21:46:05 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 QQnnvz23122 for ; Wed, 6 Nov 2002 21:46: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 QAA01065 for ; Wed, 6 Nov 2002 16:46:02 -0500 (EST) 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 QAA01846 for ; Wed, 6 Nov 2002 16:46:04 -0500 (EST) Message-ID: <3DC98DEA.6030900@marconi.com> Date: Wed, 06 Nov 2002 16:47:22 -0500 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Houck, David J (David) wrote: > > I have a question about the "build the new then tear down the old" > approach for decreasing TE-LSP bandwidth. If a link in the path is > at capacity, then wouldn't the "build new" request be denied. If so, > it would be a lot easier just to decrease the bandwidth on the > existing TE-LSP. Not if the LSP is signaled using RSVP SE-style. With SE style, the reservations for all LSPs in a single session share a common reservation which is normally the least-upper-bound of all the individual reservations. So if the new LSP has less bandwidth than the existing LSPs, it won't cause new resources to be reserved, and shouldn't fail. This assumes, of course, that the hardware and software on the router in question is capable of properly implementing SE style. But all of make-before-break depends on this. -- David From owner-mpls@UU.NET Wed Nov 6 17:11:00 2002 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 ESMTP id RAA14930 for ; Wed, 6 Nov 2002 17:11:00 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnwa05801 for ; Wed, 6 Nov 2002 22:13:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnwa03440; Wed, 6 Nov 2002 22:11:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnwa01248 for mpls-outgoing; Wed, 6 Nov 2002 22:11:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnwa01239 for ; Wed, 6 Nov 2002 22:11:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnwa12913 for ; Wed, 6 Nov 2002 22:11:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnwa07587 for ; Wed, 6 Nov 2002 22:11:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnwa07583 for ; Wed, 6 Nov 2002 22:11:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA09938 for ; Wed, 6 Nov 2002 17:11:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6MB5Y07024 for mpls@uu.net; Wed, 6 Nov 2002 17:11:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnwa00291 for ; Wed, 6 Nov 2002 22:10:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnwa06682 for ; Wed, 6 Nov 2002 22:08:45 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnwa20958 for ; Wed, 6 Nov 2002 22:08:44 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnnwa20949 for ; Wed, 6 Nov 2002 22:08:44 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA6M8YL8010627; Wed, 6 Nov 2002 17:08:35 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn1-93.cisco.com [10.86.240.93]) by bucket.cisco.com (Mirapoint) with ESMTP id ACB68495; Wed, 6 Nov 2002 17:08:16 -0500 (EST) Message-Id: <4.3.2.7.2.20021106170614.02f69f50@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Nov 2002 17:08:12 -0500 To: George Swallow From: "Thomas D. Nadeau" Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Cc: Shahram Davari , "'George Swallow'" , David Allan , Der-Hwa Gan , "Gray, Eric" , mpls@UU.NET, swallow@cisco.com In-Reply-To: <200211062119.QAA05809@bifocal.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Since George beat me to the punch, I will just add a few points to his. >Shahram - > > > The LSP-ID defined in Y.1711 is essentially a combination of LSP-ID + > Tunnel-ID > > as defined in RSVP-TE. > > > > In the current version of Y.1711, 4 bytes are assigned to > > this. However the current version of Y.1711 sets the first 2 octets of > > this field to zero for future use. Therefore two methods are possible: > > > > 1) Compress the LSP-ID + Tunnel-ID in to 2 bytes > >This uses up all the space. If RSVP-TE is the only application for >Y.1711 then this would be acceptable. But since it's called MPLS OAM, >I assume there were other apps in mind as well. Yes, for example, what do we do for L2/L3 VPN given this logic? > > 2) You could use the first 2 octets, and encode the 2-byte RSVP-TE > > LSP-ID in the first 2 octets of Y.1711 LSP-ID and encode the 2-byte > > RSVP-TE Tunnel-ID in the last 2 octets of Y.1711 LSP-ID. > >Not enough space to be future proof. We already have requests to >support thousands of tunnels. If I give just 4 bits to LSP-ID that >only leaves 4k tunnels. There are several deployments with tens-of-thousands of tunnels, so this will definitely not work there. --Tom > > Just a question, isn't it possible to change the LSP by changing the > > Tunnel-ID, rather than LSP-ID? > >You cannot share bandwidth between different RSVP sessions only >between different senders. The tunnel ID is in the session ID to say >"the various LSPs with this identification all belong to the same >tunnel". > >The LSP-ID is in the sender template so that they can be >distingueshed, yet associated via the session and thus can share >bandwidth. > >...George > >================================================================== >George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Wed Nov 6 17:29:12 2002 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 ESMTP id RAA15578 for ; Wed, 6 Nov 2002 17:29:12 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnwc02725 for ; Wed, 6 Nov 2002 22:31:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnwc00515; Wed, 6 Nov 2002 22:30:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnwc02826 for mpls-outgoing; Wed, 6 Nov 2002 22:30:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnwc02819 for ; Wed, 6 Nov 2002 22:30:15 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 QQnnwb08281 for ; Wed, 6 Nov 2002 22:29:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnwb29108 for ; Wed, 6 Nov 2002 22:29:23 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnwb29095 for ; Wed, 6 Nov 2002 22:29:23 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA11221 for ; Wed, 6 Nov 2002 17:29:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA6MTAs09640 for mpls@uu.net; Wed, 6 Nov 2002 17:29:10 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnwb02739 for ; Wed, 6 Nov 2002 22:28: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 QQnnwb00784 for ; Wed, 6 Nov 2002 22:27:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnwb26586 for ; Wed, 6 Nov 2002 22:27:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnwb26578 for ; Wed, 6 Nov 2002 22:27:06 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA11065; Wed, 6 Nov 2002 17:27:05 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA06237; Wed, 6 Nov 2002 17:27:05 -0500 (EST) Message-Id: <200211062227.RAA06237@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: mpls@UU.NET Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of "Wed, 06 Nov 2002 16:19:43 EST." <200211062119.QAA05809@bifocal.cisco.com> Date: Wed, 06 Nov 2002 17:27:05 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Shahram - Just realized that I mis-spoke when I said: > > The LSP-ID defined in Y.1711 is essentially a combination of LSP-ID + Tunnel-ID > > as defined in RSVP-TE. > > > > In the current version of Y.1711, 4 bytes are assigned to > > this. However the current version of Y.1711 sets the first 2 octets of > > this field to zero for future use. Therefore two methods are possible: > > > > 1) Compress the LSP-ID + Tunnel-ID in to 2 bytes > > This uses up all the space. If RSVP-TE is the only application for > Y.1711 then this would be acceptable. But since it's called MPLS OAM, > I assume there were other apps in mind as well. This is not even sufficient for RSVP-TE. When I set up backup paths, the means of identification is to keep the same Session_Object, and the same LSP-ID. The source_IP address is set to the router setting up the backup tunnel. Thats the only change. So suppose (a most common situation) router A has tunnel number 1, LSP number 1. this tunnel passes through some other router B router B has its own tunnel number 1, LSP number 1. router B sets up a backup to protect tunnel A,1,1. it would like to ping (i.e. verify connectivity) the backup tunnel after it is set up to make certain that it is working It can't set the TTSI to B,1,1 - since that is the ID for his own tunnel. He can't set it to A,1,1 because that is the working path and he wants to check the protect path. So the TTSI does not seem to be sufficient even for RSVP-TE! ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 7 00:01:36 2002 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 ESMTP id AAA23629 for ; Thu, 7 Nov 2002 00:01:36 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnxc01427 for ; Thu, 7 Nov 2002 05:04:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnxc29708; Thu, 7 Nov 2002 05:03:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnxc26421 for mpls-outgoing; Thu, 7 Nov 2002 05:02:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnxc25663 for ; Thu, 7 Nov 2002 05:02:34 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 QQnnxc12374 for ; Thu, 7 Nov 2002 05:02:03 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnxc25236 for ; Thu, 7 Nov 2002 05:02:02 GMT Received: from tama5.ecl.ntt.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQnnxc25108 for ; Thu, 7 Nov 2002 05:01:56 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/21/02) with ESMTP id OAA05064 for ; Thu, 7 Nov 2002 14:01:54 +0900 (JST) (envelope-from yasukawa.seisho@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id gA751r3F001255 for ; Thu, 7 Nov 2002 14:01:53 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id gA751rDT013905 for ; Thu, 7 Nov 2002 14:01:53 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id OAA21372; Thu, 7 Nov 2002 14:01:52 +0900 (JST) Received: from [129.60.144.177] by imc.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id OAA29359; Thu, 7 Nov 2002 14:01:49 +0900 (JST) X-Authentication-Warning: imc.m.ecl.ntt.co.jp: [129.60.144.177] didn't use HELO protocol Message-Id: <4.3.2-J.20021107102017.051c1038@imc.m.ecl.ntt.co.jp> X-Sender: sy003@imc.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Thu, 07 Nov 2002 11:15:33 +0900 To: mpls@UU.NET From: Seisho Yasukawa Subject: draft-yasukawa-mpls-rsvp-multicast-01 Cc: m-mpls@lab.ntt.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi all, We have reposted a revised version of the "Extended RSVP-TE for Multicast LSP Tunnels" draft (01). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-multicast-01.txt We have modified following points. -Modify Graft/Prune mechanism. -Add the TERO operation mechanism. -Add the Multicast Notify message. -Add the Error handling mechanism. -Remove MP-to-MP LSP setup mechanism for further study. We welcome any comments and discussions. Thanks, Seisho From owner-mpls@UU.NET Thu Nov 7 04:34:00 2002 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 ESMTP id EAA08153 for ; Thu, 7 Nov 2002 04:33:59 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnxu15168 for ; Thu, 7 Nov 2002 09:36:26 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnxu13504; Thu, 7 Nov 2002 09:35:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnxu26812 for mpls-outgoing; Thu, 7 Nov 2002 09:35:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnxu26807 for ; Thu, 7 Nov 2002 09:35:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnxu17193 for ; Thu, 7 Nov 2002 09:35:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnxu11216 for ; Thu, 7 Nov 2002 09:35:03 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnnxu11205 for ; Thu, 7 Nov 2002 09:35:03 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA79YkS02380; Thu, 7 Nov 2002 04:34:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 04:34:46 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05EB56A3@zcard031.ca.nortel.com> From: "David Allan" To: George Swallow , Shahram Davari Cc: mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Thu, 7 Nov 2002 04:34:46 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk George: You are misunderstanding some of the intent of Y.1711 CV in your example. It is designed to do path availability measurement/path failure detection for the tunnel and possibly facilitate path based protection switching. It does not do ad-hoc ping verification from arbitrary points in the tunnel to support FRR, that is a more complex function (see below). So in your example lets add LSR 'E' which is where the tunnel terminates. A,1,1 is working fine and CV flows from A to E. At some point B switches traffic to the backup path also terminating at E (or remerging with the original tunnel somewhere downstream) , and CV continues to flow from A to E (with a slight detour ;-). This assumes the protection works perfectly. If it did not, then CV would be interrupted, and the failed LSR-ID/Tunnel ID would be flagged to mgmt or for some other corrective action. CV does not need to have sufficient information to disambiguate ping flows from arbitrary points in the network. This would bring to mind an interesting question which I wouldn't mind your answer for my education. In FRR, let's add 'D' which is a merge point for detours upstream of the egress. ST SO (A,1)(E,1)-> A------------B-----------D-------------E \_________/ ST SO (B,1) (D or E,1) A detour set up from B to D presumably only propagates the backup paths session object and sender template as far as 'D', so that the existence of the backup path B-D is not known to E. Any ping for ad-hoc verification of the backup path would flow B-E, so a change in the sender template that B would use when pinging for the path would not be known to E. So in this case E needs some extra logic to pry 'A' out of the extended tunnel ID and figure out that this ping is from 'B' for the LSP originating at 'A'? In other words, if the extended tunnel ID is not zero then it effectively overrides the ID in the sender template for the purposes of identifying what is being tested and the sender template identifies who is doing the testing and some of the LSP details? DO I have this correct? thks Dave > -----Original Message---- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, November 06, 2002 5:27 PM > To: Shahram Davarion > Cc: mpls@UU.NET > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability > issue" (fwd) > > > > Shahram - > > Just realized that I mis-spoke when I said: > > > > The LSP-ID defined in Y.1711 is essentially a combination > of LSP-ID + Tunnel-ID > > > as defined in RSVP-TE. > > > > > > In the current version of Y.1711, 4 bytes are assigned to > > > this. However the current version of Y.1711 sets the > first 2 octets of > > > this field to zero for future use. Therefore two methods > are possible: > > > > > > 1) Compress the LSP-ID + Tunnel-ID in to 2 bytes > > > > This uses up all the space. If RSVP-TE is the only application for > > Y.1711 then this would be acceptable. But since it's > called MPLS OAM, > > I assume there were other apps in mind as well. > > This is not even sufficient for RSVP-TE. When I set up backup paths, > the means of identification is to keep the same > Session_Object, and the > same LSP-ID. The source_IP address is set to the router setting up > the backup tunnel. Thats the only change. > > So suppose (a most common situation) > > router A has tunnel number 1, LSP number 1. > this tunnel passes through some other router B > > router B has its own tunnel number 1, LSP number 1. > > router B sets up a backup to protect tunnel A,1,1. > > it would like to ping (i.e. verify connectivity) the backup tunnel > after it is set up to make certain that it is working > > It can't set the TTSI to B,1,1 - since that is the ID for his own > tunnel. He can't set it to A,1,1 because that is the working path and > he wants to check the protect path. > > So the TTSI does not seem to be sufficient even for RSVP-TE! > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Thu Nov 7 04:55:23 2002 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 ESMTP id EAA08577 for ; Thu, 7 Nov 2002 04:55:23 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnxv25410 for ; Thu, 7 Nov 2002 09:57:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnxv23969; Thu, 7 Nov 2002 09:57:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnxv28550 for mpls-outgoing; Thu, 7 Nov 2002 09:56:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnxv28543 for ; Thu, 7 Nov 2002 09:56:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnnxv11180 for ; Thu, 7 Nov 2002 09:56:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnxv17299 for ; Thu, 7 Nov 2002 09:56:31 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnnxv17289 for ; Thu, 7 Nov 2002 09:56:30 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA79u3S02556; Thu, 7 Nov 2002 04:56:04 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 04:56:03 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05EB56A4@zcard031.ca.nortel.com> From: "David Allan" To: George Swallow , Shahram Davari Cc: mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Thu, 7 Nov 2002 04:56:03 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk George, ignore the question al the end of my last message, I answered it myself ;-) rgds Dave > -----Original Message----- > From: Allan, David [CAR:NS00:EXCH] > Sent: Thursday, November 07, 2002 4:35 AM > To: George Swallow; Shahram Davari > Cc: mpls@UU.NET > Subject: RE: Decreasing TE-LSP bandwidth, "interoperability > issue" (fwd) > > > > > > George: > > You are misunderstanding some of the intent of Y.1711 CV in > your example. It > is designed to do path availability measurement/path failure > detection for > the tunnel and possibly facilitate path based protection > switching. It does > not do ad-hoc ping verification from arbitrary points in the tunnel to > support FRR, that is a more complex function (see below). > > So in your example lets add LSR 'E' which is where the tunnel > terminates. > A,1,1 is working fine and CV flows from A to E. At some point > B switches > traffic to the backup path also terminating at E (or > remerging with the > original tunnel somewhere downstream) , and CV continues to > flow from A to E > (with a slight detour ;-). This assumes the protection works > perfectly. If > it did not, then CV would be interrupted, and the failed > LSR-ID/Tunnel ID > would be flagged to mgmt or for some other corrective action. > CV does not > need to have sufficient information to disambiguate ping flows from > arbitrary points in the network. > > This would bring to mind an interesting question which I > wouldn't mind your > answer for my education. In FRR, let's add 'D' which is a > merge point for > detours upstream of the egress. > ST SO > (A,1)(E,1)-> > A------------B-----------D-------------E > \_________/ > > ST SO > (B,1) (D or E,1) > > A detour set up from B to D presumably only propagates the > backup paths > session object and sender template as far as 'D', so that the > existence of > the backup path B-D is not known to E. Any ping for ad-hoc > verification of > the backup path would flow B-E, so a change in the sender > template that B > would use when pinging for the path would not be known to E. > So in this case > E needs some extra logic to pry 'A' out of the extended > tunnel ID and figure > out that this ping is from 'B' for the LSP originating at > 'A'? In other > words, if the extended tunnel ID is not zero then it > effectively overrides > the ID in the sender template for the purposes of identifying > what is being > tested and the sender template identifies who is doing the > testing and some > of the LSP details? DO I have this correct? > > thks > Dave > > > > > -----Original Message---- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Wednesday, November 06, 2002 5:27 PM > > To: Shahram Davarion > > Cc: mpls@UU.NET > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability > > issue" (fwd) > > > > > > > > Shahram - > > > > Just realized that I mis-spoke when I said: > > > > > > The LSP-ID defined in Y.1711 is essentially a combination > > of LSP-ID + Tunnel-ID > > > > as defined in RSVP-TE. > > > > > > > > In the current version of Y.1711, 4 bytes are assigned to > > > > this. However the current version of Y.1711 sets the > > first 2 octets of > > > > this field to zero for future use. Therefore two methods > > are possible: > > > > > > > > 1) Compress the LSP-ID + Tunnel-ID in to 2 bytes > > > > > > This uses up all the space. If RSVP-TE is the only > application for > > > Y.1711 then this would be acceptable. But since it's > > called MPLS OAM, > > > I assume there were other apps in mind as well. > > > > This is not even sufficient for RSVP-TE. When I set up > backup paths, > > the means of identification is to keep the same > > Session_Object, and the > > same LSP-ID. The source_IP address is set to the router setting up > > the backup tunnel. Thats the only change. > > > > So suppose (a most common situation) > > > > router A has tunnel number 1, LSP number 1. > > this tunnel passes through some other router B > > > > router B has its own tunnel number 1, LSP number 1. > > > > router B sets up a backup to protect tunnel A,1,1. > > > > it would like to ping (i.e. verify connectivity) the backup tunnel > > after it is set up to make certain that it is working > > > > It can't set the TTSI to B,1,1 - since that is the ID for his own > > tunnel. He can't set it to A,1,1 because that is the > working path and > > he wants to check the protect path. > > > > So the TTSI does not seem to be sufficient even for RSVP-TE! > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > From owner-mpls@UU.NET Thu Nov 7 05:02:36 2002 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 ESMTP id FAA08658 for ; Thu, 7 Nov 2002 05:02:36 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnxw07429 for ; Thu, 7 Nov 2002 10:05:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnxw04699; Thu, 7 Nov 2002 10:03:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnxw14228 for mpls-outgoing; Thu, 7 Nov 2002 10:03:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnxw14215 for ; Thu, 7 Nov 2002 10:03:29 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 QQnnxw06593 for ; Thu, 7 Nov 2002 10:03:06 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnxw10786 for ; Thu, 7 Nov 2002 10:03:05 GMT Received: from cbibipnt05.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnnxw10779 for ; Thu, 7 Nov 2002 10:03:05 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 7 Nov 2002 10:03:21 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389E1C0D3@i2km07-ukbr.domain1.systemhost.net> To: dallan@nortelnetworks.com, swallow@cisco.com, Shahram_Davari@pmc-sierra.com Cc: mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Thu, 7 Nov 2002 10:02:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Dave....small point, please in-line below. regards, Neil David Allan wrote 07 November 2002 09:35 > George: > > You are misunderstanding some of the intent of Y.1711 CV in > your example. It > is designed to do path availability measurement/path failure > detection for > the tunnel and possibly facilitate path based protection > switching. It does > not do ad-hoc ping verification from arbitrary points in the tunnel to > support FRR, that is a more complex function (see below). > > So in your example lets add LSR 'E' which is where the tunnel > terminates. > A,1,1 is working fine and CV flows from A to E. At some point > B switches > traffic to the backup path also terminating at E (or > remerging with the > original tunnel somewhere downstream) , and CV continues to > flow from A to E > (with a slight detour ;-). This assumes the protection works > perfectly. If > it did not, then CV would be interrupted, and the failed > LSR-ID/Tunnel ID > would be flagged to mgmt or for some other corrective action. NH=> This is quite correct.....in fact anything else would not be. The example shows subnetwork protection. Further, all of the link-connections between adajacent pairs of nodes will be served by lower layer trails (maybe SDH VC4 say). One would *not* require a client trail to go changing any of its identifiers for topology changes in any lower server network layers...and this case is architecturally no different. Indeed, the only thing that is relevant for the LSP fault management is the verification that the correct source point is connected to the correct sink point....arbitrary lower layer routing changes should not (and indeed must not) have any impact on the client (unless any prot-sw therein fails to react in some time T, after which the client trail will detect a failure (missing CV with correct TTSI) and can take its own action....but *please* don't make T too small, like <1s, else you will end up uncessarily switching on each/every error event at the client level....compounded for those who think bumping/pre-emption is a good idea). From owner-mpls@UU.NET Thu Nov 7 06:29:32 2002 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 ESMTP id GAA11498 for ; Thu, 7 Nov 2002 06:29:32 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyc17918 for ; Thu, 7 Nov 2002 11:32:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnyc16345; Thu, 7 Nov 2002 11:31:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnyc08809 for mpls-outgoing; Thu, 7 Nov 2002 11:30:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnyc08800 for ; Thu, 7 Nov 2002 11:30: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 QQnnyc12110 for ; Thu, 7 Nov 2002 11:30:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyc28183 for ; Thu, 7 Nov 2002 11:30:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnyc28174 for ; Thu, 7 Nov 2002 11:30:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA18802 for ; Thu, 7 Nov 2002 06:30:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA7BU5m19550 for mpls@uu.net; Thu, 7 Nov 2002 06:30:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnyb08736 for ; Thu, 7 Nov 2002 11:29:18 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 QQnnyb22596 for ; Thu, 7 Nov 2002 11:29:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyb27633 for ; Thu, 7 Nov 2002 11:29:15 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnnyb27628 for ; Thu, 7 Nov 2002 11:29:14 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11163; Thu, 7 Nov 2002 06:26:43 -0500 (EST) Message-Id: <200211071126.GAA11163@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-te-mib-09.txt Date: Thu, 07 Nov 2002 06:26:38 -0500 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 : Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-te-mib-09.txt Pages : 68 Date : 2002-11-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-te-mib-09.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-te-mib-09.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: <2002-11-6175112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6175112.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 7 06:30:14 2002 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 ESMTP id GAA11590 for ; Thu, 7 Nov 2002 06:30:13 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyc20409 for ; Thu, 7 Nov 2002 11:32:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnyc16536; Thu, 7 Nov 2002 11:31:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnyc08797 for mpls-outgoing; Thu, 7 Nov 2002 11:30:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnyc08782 for ; Thu, 7 Nov 2002 11:30:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnyc12953 for ; Thu, 7 Nov 2002 11:30:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyc28195 for ; Thu, 7 Nov 2002 11:30:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnyc28186 for ; Thu, 7 Nov 2002 11:30:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA18806 for ; Thu, 7 Nov 2002 06:30:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA7BU6u19560 for mpls@uu.net; Thu, 7 Nov 2002 06:30:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnyb08737 for ; Thu, 7 Nov 2002 11:29:18 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 QQnnyb22586 for ; Thu, 7 Nov 2002 11:29:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyb27629 for ; Thu, 7 Nov 2002 11:29:14 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnnyb27623 for ; Thu, 7 Nov 2002 11:29:14 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11162; Thu, 7 Nov 2002 06:26:43 -0500 (EST) Message-Id: <200211071126.GAA11162@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-fastreroute-mib-01.txt Date: Thu, 07 Nov 2002 06:26:43 -0500 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 : Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute Author(s) : R. Cetin et al. Filename : draft-ietf-mpls-fastreroute-mib-01.txt Pages : 31 Date : 2002-11-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based fast rerouting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-fastreroute-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-fastreroute-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-6175121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-fastreroute-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-fastreroute-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6175121.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 7 08:12:47 2002 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 ESMTP id IAA20791 for ; Thu, 7 Nov 2002 08:12:47 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnyc20448; Thu, 7 Nov 2002 11:32:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnyc08997 for mpls-outgoing; Thu, 7 Nov 2002 11:32:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnyc08973 for ; Thu, 7 Nov 2002 11:31:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnyc15980 for ; Thu, 7 Nov 2002 11:31:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyc28801 for ; Thu, 7 Nov 2002 11:31:14 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnyc28791 for ; Thu, 7 Nov 2002 11:31:14 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA18844 for ; Thu, 7 Nov 2002 06:31:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA7BV6i19612 for mpls@uu.net; Thu, 7 Nov 2002 06:31:06 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnyc08781 for ; Thu, 7 Nov 2002 11:30:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnyb10214 for ; Thu, 7 Nov 2002 11:29:05 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyb27514 for ; Thu, 7 Nov 2002 11:29:04 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnnyb27508 for ; Thu, 7 Nov 2002 11:29:04 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11135; Thu, 7 Nov 2002 06:26:33 -0500 (EST) Message-Id: <200211071126.GAA11135@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-tc-mib-05.txt Date: Thu, 07 Nov 2002 06:26:33 -0500 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 : Definitions of Textual for Multiprotocol Label Switching (MPLS) Management Author(s) : T. Nadeau et al. Filename : draft-ietf-mpls-tc-mib-05.txt Pages : 18 Date : 2002-11-6 This memo describes Textual Conventions for use in definitions of management information for Multiprotocol Label Switching (MPLS) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tc-mib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-tc-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-tc-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-6175102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-tc-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-tc-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6175102.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 7 09:22:49 2002 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 ESMTP id JAA25468 for ; Thu, 7 Nov 2002 09:22:48 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyn15903 for ; Thu, 7 Nov 2002 14:25:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnyn14431; Thu, 7 Nov 2002 14:24:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnyn12510 for mpls-outgoing; Thu, 7 Nov 2002 14:24:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnyn12505 for ; Thu, 7 Nov 2002 14:24:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnyn16677 for ; Thu, 7 Nov 2002 14:23:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyn27076 for ; Thu, 7 Nov 2002 14:23:42 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnnyn27071 for ; Thu, 7 Nov 2002 14:23:42 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LB4AL0J>; Thu, 7 Nov 2002 09:23:42 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267EC69@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'David Allan'" Cc: mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Thu, 7 Nov 2002 09:23:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk David, Some questions/comments below... Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: David Allan [mailto:dallan@nortelnetworks.com] > Sent: Thursday, November 07, 2002 4:35 AM > To: George Swallow; Shahram Davari > Cc: mpls@UU.NET > Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > > > > George: > > You are misunderstanding some of the intent of Y.1711 CV in your example. > It > is designed to do path availability measurement/path failure detection for > the tunnel and possibly facilitate path based protection switching. It > does > not do ad-hoc ping verification from arbitrary points in the tunnel to > support FRR, that is a more complex function (see below). > > So in your example lets add LSR 'E' which is where the tunnel > terminates. A,1,1 is working fine and CV flows from A to E. > At some point B switches traffic to the backup path also > terminating at E (or remerging with the original tunnel somewhere > downstream), ... What does this mean? Downstream of where? Surely not downstream of E which is the egress for the tunnel... > ... and CV continues to flow from A to E (with a slight detour ;-). > This assumes the protection works perfectly. If it did not, then > CV would be interrupted, and the failed LSR-ID/Tunnel ID would be > flagged to mgmt or for some other corrective action. CV does not > need to have sufficient information to disambiguate ping flows from > arbitrary points in the network. This sounds like correct and expected behavior. CV is interrupted as a result of a failure. Is there something wrong with this? :-) > > This would bring to mind an interesting question which I wouldn't > mind your answer for my education. In FRR, let's add 'D' which is > a merge point for detours upstream of the egress. > ST SO > (A,1)(E,1)-> > A------------B-----------D-------------E > \_________/ > ST SO > (B,1) (D or E,1) > > A detour set up from B to D presumably only propagates the backup > paths session object and sender template as far as 'D', so that > the existence of the backup path B-D is not known to E. Any ping > for ad-hoc verification of the backup path would flow B-E, so a > change in the sender template that B would use when pinging for > the path would not be known to E. So in this case E needs some > extra logic to pry 'A' out of the extended tunnel ID and figure > out that this ping is from 'B' for the LSP originating at 'A'? > In other words, if the extended tunnel ID is not zero then it > effectively overrides the ID in the sender template for the > purposes of identifying what is being tested and the sender > template identifies who is doing the testing and some of the > LSP details? DO I have this correct? Wouldn't you expect D - as the merge point - to convert the tunnel information to something known in common with its downstream E? > > thks > Dave > > > > > -----Original Message---- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Wednesday, November 06, 2002 5:27 PM > > To: Shahram Davarion > > Cc: mpls@UU.NET > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability > > issue" (fwd) > > > > > > > > Shahram - > > > > Just realized that I mis-spoke when I said: > > > > > > The LSP-ID defined in Y.1711 is essentially a combination > > of LSP-ID + Tunnel-ID > > > > as defined in RSVP-TE. > > > > > > > > In the current version of Y.1711, 4 bytes are assigned to > > > > this. However the current version of Y.1711 sets the > > first 2 octets of > > > > this field to zero for future use. Therefore two methods > > are possible: > > > > > > > > 1) Compress the LSP-ID + Tunnel-ID in to 2 bytes > > > > > > This uses up all the space. If RSVP-TE is the only application for > > > Y.1711 then this would be acceptable. But since it's > > called MPLS OAM, > > > I assume there were other apps in mind as well. > > > > This is not even sufficient for RSVP-TE. When I set up backup paths, > > the means of identification is to keep the same > > Session_Object, and the > > same LSP-ID. The source_IP address is set to the router setting up > > the backup tunnel. Thats the only change. > > > > So suppose (a most common situation) > > > > router A has tunnel number 1, LSP number 1. > > this tunnel passes through some other router B > > > > router B has its own tunnel number 1, LSP number 1. > > > > router B sets up a backup to protect tunnel A,1,1. > > > > it would like to ping (i.e. verify connectivity) the backup tunnel > > after it is set up to make certain that it is working > > > > It can't set the TTSI to B,1,1 - since that is the ID for his own > > tunnel. He can't set it to A,1,1 because that is the working path and > > he wants to check the protect path. > > > > So the TTSI does not seem to be sufficient even for RSVP-TE! > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 497-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Thu Nov 7 10:51:34 2002 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 ESMTP id KAA28973 for ; Thu, 7 Nov 2002 10:51:34 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyt15760 for ; Thu, 7 Nov 2002 15:54:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnyt14565; Thu, 7 Nov 2002 15:53:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnyt06158 for mpls-outgoing; Thu, 7 Nov 2002 15:53:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnyt06153 for ; Thu, 7 Nov 2002 15:53:01 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 QQnnyt23530 for ; Thu, 7 Nov 2002 15:52:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnyt14645 for ; Thu, 7 Nov 2002 15:52:12 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnnyt14640 for ; Thu, 7 Nov 2002 15:52:11 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA7Fq4G00865; Thu, 7 Nov 2002 10:52:04 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 10:52:04 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05F40460@zcard031.ca.nortel.com> From: "David Allan" To: "Gray, Eric" Cc: mpls@UU.NET Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) Date: Thu, 7 Nov 2002 10:52:02 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric: > > You are misunderstanding some of the intent of Y.1711 CV in > your example. > > It > > is designed to do path availability measurement/path > failure detection for > > the tunnel and possibly facilitate path based protection > switching. It > > does > > not do ad-hoc ping verification from arbitrary points in > the tunnel to > > support FRR, that is a more complex function (see below). > > > > So in your example lets add LSR 'E' which is where the tunnel > > terminates. A,1,1 is working fine and CV flows from A to E. > > At some point B switches traffic to the backup path also > > terminating at E (or remerging with the original tunnel somewhere > > downstream), ... > > What does this mean? Downstream of where? Surely not downstream > of E which is the egress for the tunnel... No certainly not downstream of E. Re-merges somewhere between B and E is more precise. > > > ... and CV continues to flow from A to E (with a slight detour ;-). > > This assumes the protection works perfectly. If it did not, then > > CV would be interrupted, and the failed LSR-ID/Tunnel ID would be > > flagged to mgmt or for some other corrective action. CV does not > > need to have sufficient information to disambiguate ping flows from > > arbitrary points in the network. > > This sounds like correct and expected behavior. CV is interrupted > as a result of a failure. Is there something wrong with this? :-) Nope. > > > > > This would bring to mind an interesting question which I wouldn't > > mind your answer for my education. In FRR, let's add 'D' which is > > a merge point for detours upstream of the egress. > > ST SO > > (A,1)(E,1)-> > > A------------B-----------D-------------E > > \_________/ > > ST SO > > (B,1) (D or E,1) > > > > A detour set up from B to D presumably only propagates the backup > > paths session object and sender template as far as 'D', so that > > the existence of the backup path B-D is not known to E. Any ping > > for ad-hoc verification of the backup path would flow B-E, so a > > change in the sender template that B would use when pinging for > > the path would not be known to E. So in this case E needs some > > extra logic to pry 'A' out of the extended tunnel ID and figure > > out that this ping is from 'B' for the LSP originating at 'A'? > > In other words, if the extended tunnel ID is not zero then it > > effectively overrides the ID in the sender template for the > > purposes of identifying what is being tested and the sender > > template identifies who is doing the testing and some of the > > LSP details? DO I have this correct? > > Wouldn't you expect D - as the merge point - to convert the tunnel > information to something known in common with its downstream E? yes, I figured out the piece I was missing (reading and understanding being unsynched).....it just took a second to grok when extended tunnel ID is zero and when you use it. And how it would work with LSP PING (which except in traceroute mode will not stop to sightsee at 'D' but then B can fix that). rgds Dave >> From owner-mpls@UU.NET Thu Nov 7 16:06:37 2002 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 ESMTP id QAA12442 for ; Thu, 7 Nov 2002 16:06:37 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnzl16449; Thu, 7 Nov 2002 20:20:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnzl20132 for mpls-outgoing; Thu, 7 Nov 2002 20:19:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnnzl20127 for ; Thu, 7 Nov 2002 20:19:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnnzl23015 for ; Thu, 7 Nov 2002 20:18:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnzl26173 for ; Thu, 7 Nov 2002 20:18:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnzl26168 for ; Thu, 7 Nov 2002 20:18:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01935 for ; Thu, 7 Nov 2002 15:18:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA7KI6F18225 for mpls@uu.net; Thu, 7 Nov 2002 15:18:06 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnnzl19898 for ; Thu, 7 Nov 2002 20:16:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnnzl06741 for ; Thu, 7 Nov 2002 20:15:47 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnzl08107 for ; Thu, 7 Nov 2002 20:15:47 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnnzl08073 for ; Thu, 7 Nov 2002 20:15:43 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: "All.IETF.Working.Groups":; Subject: Note Well Statement x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Sender: owner-mpls@UU.NET Precedence: bulk >From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-mpls@UU.NET Thu Nov 7 18:10:22 2002 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 ESMTP id SAA17414 for ; Thu, 7 Nov 2002 18:10:22 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnzw05979 for ; Thu, 7 Nov 2002 23:12:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnnzw27550; Thu, 7 Nov 2002 23:08:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnnzw22607 for mpls-outgoing; Thu, 7 Nov 2002 23:08:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnnzw22602 for ; Thu, 7 Nov 2002 23:08:10 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 QQnnzw19870 for ; Thu, 7 Nov 2002 23:07:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnzw25512 for ; Thu, 7 Nov 2002 23:07:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnnzw25500 for ; Thu, 7 Nov 2002 23:07:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA15470 for ; Thu, 7 Nov 2002 18:07:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA7N75q26972 for mpls@uu.net; Thu, 7 Nov 2002 18:07:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnnzh29293 for ; Thu, 7 Nov 2002 19:26:36 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 QQnnzh15877 for ; Thu, 7 Nov 2002 19:26:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnnzh03111 for ; Thu, 7 Nov 2002 19:26:07 GMT Received: from web21003.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21003.mail.yahoo.com [216.136.227.57]) id QQnnzh03093 for ; Thu, 7 Nov 2002 19:26:07 GMT Message-ID: <20021107192602.58049.qmail@web21003.mail.yahoo.com> Received: from [63.67.101.6] by web21003.mail.yahoo.com via HTTP; Thu, 07 Nov 2002 11:26:02 PST Date: Thu, 7 Nov 2002 11:26:02 -0800 (PST) From: S Leung Subject: Fwd: Question on RSVP-TE admission control To: mpls@UU.NET, mpls-ops@mplsrc.com In-Reply-To: <20021104221236.92719.qmail@web21005.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am trying to understand how admission control should work in RSVP-TE, and would very much appreciate if anyone can give me some feedbacks on the following questions that I have. Thanks, S Leung. > Hi, > > I have a question on RSVP-TE admission control. > My understanding is that the actual bandwidth > reservation is done when the RESV message is > received, and the bandwidth is reserved on the > interface from which the RESV message is received. > > However, in RFC 3209 Section 4.7.3 it indicates that > admission control happens upon the receipt of the > PATH message. > > "When a new Path message is considered for > admission, > the bandwidth requested is compared with the > bandwidth > available at the priority specified in the Setup > Prio. > > If the requested bandwidth is not available a > PathErr > message is returned with an Error Code of 01, > Admission Control Failure, and an Error Value of > 0x0002..." > > As reservation takes place at the outbound interface > of the Path message, in order to do admission > control > that means the outbound interface of the Path > message > needs to be determined before CAC can be applied, my > question is that why don't we wait until the Resv > message is received, considering that the bandwidth > requested can be modified/decreased by the egress > router? > > Also, I assume that the bandwidth requested is > compared with the bandwidth available on the > outbound > interface, and pre-emption should only affect the > LSPs > that are routed on the same outbound interface, is > that correct? > > Thanks very much for your reply in advance. > > S. Leung __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From owner-mpls@UU.NET Thu Nov 7 20:45:20 2002 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 ESMTP id UAA20743 for ; Thu, 7 Nov 2002 20:45:20 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoah27832 for ; Fri, 8 Nov 2002 01:47:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnoah25775; Fri, 8 Nov 2002 01:46:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnoah08999 for mpls-outgoing; Fri, 8 Nov 2002 01:45:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnoah08994 for ; Fri, 8 Nov 2002 01:45:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnoah05646 for ; Fri, 8 Nov 2002 01:45:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoah24628 for ; Fri, 8 Nov 2002 01:45:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnoah24611 for ; Fri, 8 Nov 2002 01:45:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA23704 for ; Thu, 7 Nov 2002 20:45:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA81j5b05103 for mpls@uu.net; Thu, 7 Nov 2002 20:45:05 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnoag08677 for ; Fri, 8 Nov 2002 01:43:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnoag02244 for ; Fri, 8 Nov 2002 01:43:05 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoag15169 for ; Fri, 8 Nov 2002 01:43:04 GMT Received: from sj-msg-core-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQnoag15160 for ; Fri, 8 Nov 2002 01:43:04 GMT Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA81gnxF016447; Thu, 7 Nov 2002 17:42:49 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA81gutb000527; Thu, 7 Nov 2002 17:42:57 -0800 (PST) Received: from rajiva-w2k02.cisco.com (rtp-vpn1-911.cisco.com [10.82.227.143]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA04761; Thu, 7 Nov 2002 17:42:54 -0800 (PST) Message-Id: <4.3.2.7.2.20021107203656.0216ca08@dingdong.cisco.com> X-Sender: rajiva@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Nov 2002 20:42:53 -0500 To: S Leung From: Rajiv Asati Subject: Re: [MPLS-OPS]: Fwd: Question on RSVP-TE admission control Cc: mpls@UU.NET, mpls-ops@mplsrc.com In-Reply-To: <20021107192602.58049.qmail@web21003.mail.yahoo.com> References: <20021104221236.92719.qmail@web21005.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi S Leung, Please see inline.. At 02:26 PM 11/7/2002, S Leung wrote: >Hi, > >I am trying to understand how admission control >should work in RSVP-TE, and would very much appreciate >if anyone can give me some feedbacks on the following >questions that I have. > >Thanks, >S Leung. > > > Hi, > > > > I have a question on RSVP-TE admission control. > > My understanding is that the actual bandwidth > > reservation is done when the RESV message is > > received, and the bandwidth is reserved on the > > interface from which the RESV message is received. Nope. What you have listed below is the correct behavior. > > > > However, in RFC 3209 Section 4.7.3 it indicates that > > admission control happens upon the receipt of the > > PATH message. > > > > "When a new Path message is considered for > > admission, > > the bandwidth requested is compared with the > > bandwidth > > available at the priority specified in the Setup > > Prio. > > > > If the requested bandwidth is not available a > > PathErr > > message is returned with an Error Code of 01, > > Admission Control Failure, and an Error Value of > > 0x0002..." > > > > As reservation takes place at the outbound interface > > of the Path message, in order to do admission > > control > > that means the outbound interface of the Path > > message > > needs to be determined before CAC can be applied, my > > question is that why don't we wait until the Resv > > message is received, considering that the bandwidth > > requested can be modified/decreased by the egress > > router? So when the PATH message is received, the CAC is applied and if granted, the PATH message gets sent to the downstream router. The BW is reserved (not really allocated) to this specific PATH message. If the RESV message comes back (for this PATH message), then the BW is allocated. Now, if there is another PATH message received in between, and the requested BW is not available, then this PATH message is not sent to the downstream router. Waiting for the RESV message for the BW reservation is not a good idea, since sending PATH message to the downstream routers (and all the way to the tunnel tail) when there is not sufficient BW available, doesn't make sense. > > > > Also, I assume that the bandwidth requested is > > compared with the bandwidth available on the > > outbound interface, and pre-emption should only affect the > > LSPs that are routed on the same outbound interface, is > > that correct? Yes. hope this helps. Cheers, Rajiv > > > > Thanks very much for your reply in advance. > > > > S. Leung > > >__________________________________________________ >Do you Yahoo!? >U2 on LAUNCH - Exclusive greatest hits videos >http://launch.yahoo.com/u2 > >------- >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 Nov 8 07:41:33 2002 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 ESMTP id HAA16480 for ; Fri, 8 Nov 2002 07:41:32 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoby10344 for ; Fri, 8 Nov 2002 12:43:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnoby03844; Fri, 8 Nov 2002 12:40:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnoby01283 for mpls-outgoing; Fri, 8 Nov 2002 12:40:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnoby01275 for ; Fri, 8 Nov 2002 12:40:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnoby01337 for ; Fri, 8 Nov 2002 12:39:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoby10705 for ; Fri, 8 Nov 2002 12:39:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnoby10699 for ; Fri, 8 Nov 2002 12:39:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA22700 for ; Fri, 8 Nov 2002 07:39:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA8Cd5906803 for mpls@uu.net; Fri, 8 Nov 2002 07:39:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnoby01201 for ; Fri, 8 Nov 2002 12:38:05 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 QQnoby02462 for ; Fri, 8 Nov 2002 12:38:00 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoby07560 for ; Fri, 8 Nov 2002 12:38:00 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQnoby07551 for ; Fri, 8 Nov 2002 12:37:59 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15788; Fri, 8 Nov 2002 07:35:27 -0500 (EST) Message-Id: <200211081235.HAA15788@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-ftn-mib-05.txt Date: Fri, 08 Nov 2002 07:35:26 -0500 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 : Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base Author(s) : T. Nadeau, C. Srinivasan, A. Viswanathan Filename : draft-ietf-mpls-ftn-mib-05.txt Pages : 30 Date : 2002-11-7 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring and monitoring Forwarding Equivalent Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ftn-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ftn-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ftn-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ftn-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160248.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Nov 8 18:28:08 2002 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 ESMTP id SAA22211 for ; Fri, 8 Nov 2002 18:28:08 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnodq27970 for ; Fri, 8 Nov 2002 23:30:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnodp26192; Fri, 8 Nov 2002 23:29:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnodp04418 for mpls-outgoing; Fri, 8 Nov 2002 23:29:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnodp04391 for ; Fri, 8 Nov 2002 23:29: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 QQnodp02109 for ; Fri, 8 Nov 2002 23:28:50 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnodp25714 for ; Fri, 8 Nov 2002 23:28:50 GMT Received: from excalibur.santera.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnodp25710 for ; Fri, 8 Nov 2002 23:28:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: MIB Report 1/3: About Coding Convention Date: Fri, 8 Nov 2002 17:28:46 -0600 Message-ID: Thread-Topic: MIB Report 1/3: About Coding Convention Thread-Index: AcKHfpS+6F+arxS0QfKsu1mC2LdksA== From: "Zhu, Rupert" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA22211 Dear MPLS MIB Authors: I read through the latest version of MPLS MIB drafts. Some of my findings are recorded in this and next two Emails. This Email talks about coding styles in MIB design. Next two Emails bring up a style anomaly issue and a MIB structural issue, respectively. ---------------------------------------- MIB Report 1/3: About Coding Style Similar to conventional programming, coding style of MIB object syntax may affect the overall quality of a MIB definition. For those companies that do automated code generation directly from MIB definition file, the MIB coding style becomes an issue. The following are two simple guidelines (or best practices) that are often overlooked by MIB authors. 1. DO NOT assign 0 (zero) to any valid ENUM element. ENUM value list should always start from 1. RATIONALE: A piece of fresh memory may carry all zeros. Engineers often erase a something by writing with all zeros. When a variable has value 0, it's hard to tell whether this 0 is accidentally carried over or intentionally assigned. (Ambiguity!) 2. DO NOT over-use INTEGER type. Since SMIv2, INTEGER is mainly for ENUM definition. Use more specific SMIv2 data types for all other scenarios. (E.g., BITS, Integer32, Unsigned32, Counter32, Gauge32, etc.) RATIONALE: Using distinctive and precise data types enables authors to specify intended usage in an accurate and machine-readable fashion. It enhances readability and helps in automated code generation. (E.g., generate C++/Java programs.) Consisistency, Clarity, Readability. To date, most published MIB definitions (in RFCs) are in good style. The MIBs in Internet Draft stage tend to contain violations of the best practice described above. -- Rupert Rupert Zhu System Engineering Santera Systems Inc 3605 E. Plano Parkway Plano, TX 75074 Phone: 972-461-6383 From owner-mpls@UU.NET Fri Nov 8 18:47:27 2002 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 ESMTP id SAA22687 for ; Fri, 8 Nov 2002 18:47:26 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnodr13864 for ; Fri, 8 Nov 2002 23:49:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnodr12351; Fri, 8 Nov 2002 23:49:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnodr05991 for mpls-outgoing; Fri, 8 Nov 2002 23:49:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnodr05986 for ; Fri, 8 Nov 2002 23:48:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnodr14673 for ; Fri, 8 Nov 2002 23:47:56 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnodr12391 for ; Fri, 8 Nov 2002 23:47:56 GMT Received: from excalibur.santera.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnodr12385 for ; Fri, 8 Nov 2002 23:47:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: MIB Report 2/3: Coding Anomalies Date: Fri, 8 Nov 2002 17:47:51 -0600 Message-ID: Thread-Topic: MIB Report 2/3: Coding Anomalies Thread-Index: AcKHgT+9dNRiS4ncSfSzrV7KuXpY/g== From: "Zhu, Rupert" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA22687 ------------------------------------------------------------ MIB Report 2/3: Coding Style Anomalies I run a "lint" (i.e., coding style checking) over the latest version of MPLS MIB drafts and generated a report. draft-ietf-mpls-bundle-mib-04.fmt draft-ietf-mpls-fastreroute-mib-01.fmt draft-ietf-mpls-ftn-mib-04.fmt draft-ietf-mpls-ldp-mib-09.fmt draft-ietf-mpls-lsr-mib-09.fmt draft-ietf-mpls-tc-mib-05.fmt draft-ietf-mpls-te-mib-09.fmt 9 coding style anomalies are detected. (A small number, compared with 525 object types and 22 TCs in total.) The anomalies fall in 2 categories. 1. ENUM value list started with zero (0). GUIDELINE: All ENUM value list should start from 1 and up. 2. Define Numeric range with INTEGER. GUIDELINE: All numeric range should be defined with Integer32 or Unsigned32. These are not errors, but coding style anomalies. See details below. -- Rupert #==================================================================== # Checking on Objects MODULE=LINK-BUNDLING-MIB MODULE=MPLS-FRR-MIB WARNING: ENUM Starts with Zero (0) mplsFrrConstProtectionMethod INTEGER { oneToOneBackup (0), facilityBackup (1) } WARNING: ENUM Starts with Zero (0) mplsFrrConstProtectionType INTEGER { linkProtection (0), nodeProtection (1) } WARNING: ENUM Starts with Zero (0) mplsFrrDetourMerging INTEGER { none (0), protectedTunnel (1), detour(2) } MODULE=MPLS-FTN-MIB MODULE=MPLS-LDP-MIB WARNING: ENUM Starts with Zero (0) mplsLdpEntityAtmMergeCap INTEGER { notSupported (0), vcMerge (2) } WARNING: ENUM Starts with Zero (0) mplsLdpEntityAtmVcDirectionality INTEGER { bidirectional (0), unidirectional (1) } WARNING: ENUM Starts with Zero (0) mplsLdpEntityFrMergeCap INTEGER { notSupported (0), supported (1) } WARNING: ENUM Starts with Zero (0) mplsLdpEntityFrLength INTEGER { tenDlciBits (0), twentyThreeDlciBits (2) } WARNING: ENUM Starts with Zero (0) mplsLdpEntityFrVcDirectionality INTEGER { bidirectional (0), unidirection (1) } WARNING: ENUM Starts with Zero (0) mplsLdpFrSesLength INTEGER { tenDlciBits (0), twentyThreeDlciBits (2) } MODULE=MPLS-LSR-MIB MODULE=MPLS-TE-MIB Total Warnings: 9 From owner-mpls@UU.NET Fri Nov 8 19:24:12 2002 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 ESMTP id TAA23892 for ; Fri, 8 Nov 2002 19:24:12 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnodt18178 for ; Sat, 9 Nov 2002 00:26:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnodt16474; Sat, 9 Nov 2002 00:25:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnodt25338 for mpls-outgoing; Sat, 9 Nov 2002 00:25:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnodt25320 for ; Sat, 9 Nov 2002 00:25:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnodt11564 for ; Sat, 9 Nov 2002 00:25:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnodt15805 for ; Sat, 9 Nov 2002 00:25:08 GMT Received: from excalibur.santera.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnodt15792 for ; Sat, 9 Nov 2002 00:25:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C28786.726B1BF8" Subject: MIB Report 3/3: A Structural Issue Date: Fri, 8 Nov 2002 18:25:03 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: MIB Report 3/3: A Structural Issue Thread-Index: AcKHhnFzOR7mHPIPTiWG5D01mi7BHQ== From: "Zhu, Rupert" To: Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C28786.726B1BF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------------------------------------------------------------ MIB Report 3/3: A Structural Issue Similar to relational database design, a very important aspect of MIB design is its overall structure. That is, how to partition total data, or how to group basic data items to form tables. In MIB design process, general object modeling techniques and principles should apply. For example, any of the following. o Entity-Relationship Model (E-R Model). o Relational Data Model. o Common Information Model (CIM) by DMTF. o Universal Modeling Methodology (UML) by Rumbaugh, etc. As a rule of thumb, each object class should be mapped to a distinct MIB table. In particular, if two object classes have a one-to-many relationship, DO NOT combine them into the same MIB table. The current MPLS-TE-MIB design does not comply with object modeling principles because it lumps two distinct object classes in a single MIB table. It results in a big, 37-field table. This design causes undesirable data duplications and obscures logical relationship to MPLS-FTN-MIB. I would like to recommend a modular design that splits the big monolithic table into two separate tables, each representing exactly one object class. Although I won't be able to attend the upcoming MPLS MIB Review in Atlanta, I hope this proposal could be considered. Rupert Zhu System Engineering Santera Systems Inc 3605 E. Plano Parkway Plano, TX 75074 Phone: 972-461-6383 ------_=_NextPart_001_01C28786.726B1BF8 Content-Type: application/msword; name="MPLSTE.v2.doc" Content-Description: MPLSTE.v2.doc Content-Disposition: attachment; filename="MPLSTE.v2.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAQQAAAAAAAAAA EAAAQwAAAAEAAAD+////AAAAAEAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAHBoAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAK0AAADd8AAA3fAAAHBYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAEoOAAAAAAAASg4AAEoO AAAAAAAASg4AAAAAAABKDgAAAAAAAEoOAAAAAAAASg4AABQAAAAAAAAAAAAAAF4OAAAAAAAA6hQA AAAAAADqFAAAAAAAAOoUAAAAAAAA6hQAABQAAAD+FAAAJAAAAF4OAAAAAAAAERkAAHYBAAAuFQAA AAAAAC4VAAAAAAAALhUAAAAAAAAuFQAAAAAAAC4VAAAAAAAALhUAAAAAAAAuFQAAAAAAAC4VAAAA AAAAkBgAAAIAAACSGAAAAAAAAJIYAAAAAAAAkhgAAAAAAACSGAAAAAAAAJIYAAAAAAAAkhgAACQA AACHGgAAIAIAAKccAAB+AAAAthgAABUAAAAAAAAAAAAAAAAAAAAAAAAASg4AAAAAAAAuFQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAuFQAAAAAAAC4VAAAAAAAALhUAAAAAAAAuFQAAAAAAALYYAAAAAAAA ThgAAAAAAABKDgAAAAAAAEoOAAAAAAAALhUAAAAAAAAAAAAAAAAAAC4VAAAAAAAAyxgAABYAAABO GAAAAAAAAE4YAAAAAAAAThgAAAAAAAAuFQAAogEAAEoOAAAAAAAALhUAAAAAAABKDgAAAAAAAC4V AAAAAAAAkBgAAAAAAAAAAAAAAAAAAE4YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAALhUAAAAAAACQGAAAAAAAAE4YAABCAAAAThgAAAAAAAAAAAAA AAAAAJAYAAAAAAAASg4AAAAAAABKDgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkBgAAAAAAAAuFQAAAAAAACIVAAAMAAAAwND5/HyH wgFeDgAAjAYAAOoUAAAAAAAA0BYAAH4BAACQGAAAAAAAAAAAAAAAAAAAkBgAAAAAAADhGAAAMAAA ABEZAAAAAAAAkBgAAAAAAAAlHQAAAAAAAE4YAAAAAAAAJR0AAAAAAACQGAAAAAAAAE4YAAAAAAAA Xg4AAAAAAABeDgAAAAAAAEoOAAAAAAAASg4AAAAAAABKDgAAAAAAAEoOAAAAAAAAAgDZAAAADUEg U3RydWN0dXJhbCBDaGFuZ2UgaW4gTVBMUy1URS1NSUINUnVwZXJ0IFpodQ1TYW50ZXJhIFN5c3Rl bXMgSW5jLg0oRHJhZnQgMS4wLCAyMDAyLTA2LTA3KQ0oRHJhZnQgMS4xLCAyMDAyLTExLTA3KQ0N Q29udGVudHMgDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANbyAgQmFja2dyb3VuZCANbyAg VGhlIElzc3VlIGluIE1QTFMtVEUtTUlCIA1vICBUaGUgSXNzdWUgaW4gTVBMUy1GVE4tTUlCIA1v ICBSZWNvbW1lbmRhdGlvbiANLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0NQWJzdHJhY3Qg DVRoaXMgc2hvcnQgbWVtbyBhbmFseXplcyBpc3N1ZXMgaW4gTVBMUy1URS1NSUIgYW5kIE1QTFMt RlROLU1JQiBkZXNpZ24gYW5kIHJlY29tbWVuZHMgYSBzdHJ1Y3R1cmFsIG1vZGlmaWNhdGlvbi4g DUJhY2tncm91bmQgDVRoZSBjb25jZXB0IG9mICJ0cmFmZmljIHRydW5rIiBhbmQgInBhdGgiIChM U1ApIGFyZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgaW4gYSBudW1iZXIgb2YgSUVURiBSRkMgZG9j dW1lbnRzLiAgSW4gcGFydGljdWxhciwgdGhlIGZvbGxvd2luZyBleGNlcnB0IGlzIGZyb20gUlNW UC1URSBzcGVjIFtSRkMzMjA5XS4gDSJUaGUgTFNQcyBjcmVhdGVkIHdpdGggUlNWUCBjYW4gYmUg dXNlZCB0byBjYXJyeSB0aGUgIlRyYWZmaWMgVHJ1bmtzIiBkZXNjcmliZWQgaW4gW1JGQzI3MDJd LiAgVGhlIExTUCB3aGljaCBjYXJyaWVzIGEgdHJhZmZpYyB0cnVuayBhbmQgYSB0cmFmZmljIHRy dW5rIGFyZSBkaXN0aW5jdCB0aG91Z2ggY2xvc2VseSByZWxhdGVkIGNvbmNlcHRzLiIgDSJGb3Ig ZXhhbXBsZSwgdHdvIExTUHMgYmV0d2VlbiB0aGUgc2FtZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9u IGNvdWxkIGJlIGxvYWQgc2hhcmVkIHRvIGNhcnJ5IGEgc2luZ2xlIHRyYWZmaWMgdHJ1bmsuIiAN IkNvbnZlcnNlbHkgc2V2ZXJhbCB0cmFmZmljIHRydW5rcyBjb3VsZCBiZSBjYXJyaWVkIGluIHRo ZSBzYW1lIExTUCBpZiwgZm9yIGluc3RhbmNlLCB0aGUgTFNQIHdlcmUgY2FwYWJsZSBvZiBjYXJy eWluZyBzZXZlcmFsIHNlcnZpY2UgY2xhc3Nlcy4gIFRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZXNl IGV4dGVuc2lvbnMgaXMgZGlzY3Vzc2VkIGZ1cnRoZXIgaW4gW1JGQzMyMTBdLiIgDUNvbWJpbmlu ZyB0aGUgZGlzY3Vzc2lvbnMgaW4gUkZDMjcwMiAoTVBMUyBURSksIFJGQzMyMDkgYW5kIFJGQzMy MTAgKFJTVlAtVEUpLCB3ZSBjYW4gc2VlIHRoYXQgInRyYWZmaWMgdHJ1bmsiIGFuZCAicGF0aCIg KExTUCkgYXJlIHR3byBkaXN0aW5jdCBjb25jZXB0cy4gIFRoZSBmb3JtZXIgaXMgYW4gYWJzdHJh Y3QgbG9naWNhbCBlbnRpdHkgd2hpbGUgdGhlIGxhdHRlciBpcyB0aGUgdW5kZXJseWluZyBjb25j cmV0ZSBlbnRpdHkuICBBIHNpbmdsZSAidHJhZmZpYyB0cnVuayIgbWF5IGNvcnJlc3BvbmQgdG8g YSBncm91cCBvZiAicGF0aHMiIHZpYSBsb2FkIHNoYXJpbmcsIGJhY2t1cCBwcm90ZWN0aW9uIG9y IG90aGVyIHNjaGVtZXMuIA1UaGUgZGlzdGluY3Rpb24gb2YgInRyYWZmaWMgdHJ1bmsiIGZyb20g dGhlIHVuZGVybHlpbmcgcGF0aChzKSByZXByZXNlbnRzIGEgbGV2ZWwgb2YgaW5kaR9yZWN0aW9u LiANVGhlIElzc3VlIGluIE1QTFMtVEUtTUlCIA1UaGUgZGlzY3Vzc2lvbiBpcyBiYXNlZCBvbiB0 aGUgbW9zdCByZWNlbnQgaW50ZXJuZXQgZHJhZnRzIA0gICAgICBkcmFmdC1pZXRmLW1wbHMtZnRu LW1pYi0wNC50eHQgICAgICAgTVBMUy1GVE4tTUlCIA0gICAgICBkcmFmdC1pZXRmLW1wbHMtdGUt bWliLTA5LnR4dCAgICAgICAgTVBMUy1URS1NSUIgDQ1JbiBNUExTLVRFLU1JQiwgdGhlIGxvZ2lj YWwgZW50aXR5ICJ0cmFmZmljIHRydW5rIiBpcyBtb2RlbGVkIGFzICJsb2dpY2FsIHR1bm5lbCIg d2hpbGUgdGhlIHVuZGVybHlpbmcgInBhdGgiIGVudGl0eSBpcyBtb2RlbGVkIGFzICJ0dW5uZWwg aW5zdGFuY2UiLiAgVGhpcyBtYWtlcyBnb29kIGRpcx90aW5jdGlvbi4gDVVuZm9ydHVuYXRlbHks IHRoZXNlIHR3byBkaXN0aW5jdCBlbnRpdHkgY2xhc3NlcyBhcmUgaW50ZXJ0d2luZWQgaW50byBh IHNpbmdsZSBNSUIgdGFibGUgKG1wbHNUdW5uZWxUYWJsZSkuICBUaGlzIGNhdXNlcyBmb2xsb3dp bmcgcHJvYmxlbXMuIA1BLglBbWJpZ3VpdHkgb2YgUHJvcGVydGllcyANVGhlIG1wbHNUdW5uZWxU YWJsZSBoYXMgYXMgbWFueSBhcyAzNyBjb2x1bW5zLiAgU29tZSBvZiB0aGVtIHJlcHJlc2VudCBw cm9wZXJ0aWVzIG9mICJsb2dpY2FsIHR1bm5lbCIgZW50aXR5IHdoaWxlIG90aGVycyBhcmUgcHJv cGVydGllcyBvZiB1bmRlcmx5aW5nICJ0dW4fbmVsIGluc3RhbmNlIiBlbnRpdHkuIFRoZXJlIGlz IG5vIGNsZWFyIGRpc3RpbmN0aW9uIG9mIHRoZXNlIHR3byBjYXRlZ29yaWVzIHdoZW4gaW50ZXJt aXhpbmcgdGhlbSBpbiB0aGUgc2FtZSB0YWJsZS4gDUIuCUR1cGxpY2F0aW9uIG9mIEluZm9ybWF0 aW9uIA1BICJsb2dpY2FsIHR1bm5lbCIgY29ycmVzcG9uZHMgdG8gYSBncm91cCBvZiAidHVubmVs IGluc3RhbmNlcyIuIEZvciBhbGwgInR1bm5lbCBpbnN0YW5jZXMiIGluIG9uZSAidHVubmVsIGlu c3RhbmNlIGdyb3VwIiwgdGhlaXIgImxvZ2ljYWwgdHVubmVsIiBhdHRyaWJ1dGVzIChpLmUuLCB0 YWJsZSBmaWVsZHMpIG11c3QgaGF2ZSBpZGVudGljYWwgdmFsdWUuICBGb3IgZXhhbXBsZSwgDSAg ICAgICAgIG1wbHNUdW5uZWxJbmRleEluZGV4IA0gICAgICAgICBtcGxzVHVubmVsSW5ncmVzc0xT UklkIA0gICAgICAgICBtcGxzVHVubmVsRWdyZXNzTFNSSWQgDSAgICAgICAgIG1wbHNUdW5uZWxO YW1lIA0gICAgICAgICBtcGxzVHVubmVsRGVzY3IgDSAgICAgICAgIG1wbHNUdW5uZWxJc0lmIA0g ICAgICAgICBtcGxzVHVubmVsSWZJbmRleCANICAgICAgICAgbXBsc1R1bm5lbFByaW1hcnlJbnN0 YW5jZSANICAgICAgICAgbXBsc1R1bm5lbFByaW1hcnlUaW1lVXAgDSAgICAgICAgIG1wbHNUdW5u ZWxQYXRoQ2hhbmdlcyANICAgICAgICAgbXBsc1R1bm5lbExhc3RQYXRoQ2hhbmdlIA0gICAgICAg ICBtcGxzVHVubmVsQ3JlYXRpb25UaW1lIA0gICAgICAgICBtcGxzVHVubmVsUGF0aEluVXNlIA0g ICAgICAgICBtcGxzVHVubmVsUm9sZSANICAgICAgICAgbXBsc1R1bm5lbFRvdGFsVXBUaW1lIA0N VGhlcmVmb3JlLCB0aGVzZSBmaWVsZHMgbXVzdCBiZSBkdXBsaWNhdGVkIGFjcm9zcyBhbGwgcm93 cyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgInR1bm5lbCBpbnN0YW5jZSBncm91cCIuIChBIHZpb2xh dGlvbiBvZiByZWxhdGlvbmFsIGRhdGEgbW9kZWwgcHJpbmNpcGxlcy4pIEZ1cnRoZXIfbW9yZSwg aWYgbmV0d29yayBhZG1pbmlzdHJhdG9yIGFjY2lkZW50YWxseSBwdXQgZGlmZmVyZW50IHZhbHVl cyB0byB0d28gcm93cyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgaW5zdGFuY2UgZ3JvdXAsIE1JQiBp bnRlZ3JpdHkgd291bGQgYmUgY29tcHJvbWlzZWQuIA1UaGUgSXNzdWUgaW4gTVBMUy1GVE4tTUlC IA1BLglGVE4gTWFwcGluZyBTaG91bGQgQmUgQmFzZWQgb24gIkxvZ2ljYWwgVHVubmVsIiANSW4g TVBMUy1GVE4tTUlCLCB0aGUgRkVDIGlzIGN1cnJlbnRseSBtYXBwZWQgdG8gYSAidHVubmVsIGlu c3RhbmNlIiBpbnN0ZWFkIG9mICJsb2dpY2FsIHR1bm5lbCIsIGVmZmVjdGl2ZWx5IG5haWxpbmcg YW4gRkVDIHRvIGFuIGluZGl2aWR1YWwgInR1bm5lbCBpbnN0YW5jZSIuICBUaGlzIGRlZmVhdHMg dGhlIHdob2xlIGNvbmNlcHQgb2YgImxvZ2ljYWwgdHVubmVsIiBvciAidHJhZmZpYyB0cnVuayIu IA0gICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSANICAgICAgKEVYQ0VSUFQgRlJPTSBDVVJSRU5UIE1QTFMtRlROLU1JQikgDSAg ICAgIG1wbHNGVE5BY3Rpb25Qb2ludGVyIE9CSkVDVC1UWVBFIA0gICAgICAgICBTWU5UQVggICAg ICAgICAgICAgUm93UG9pbnRlciANICAgICAgICAgREVTQ1JJUFRJT04gDSAgICAgICAgICAgICAi SWYgbXBsc0ZUTkFjdGlvblR5cGUgaXMgcmVkaXJlY3RMc3AoMiksIHRoZW4gdGhpcyANICAgICAg ICAgICAgICBvYmplY3QgaW5kaWNhdGVzIHRoZSBpbnN0YW5jZSBvZiBtcGxzWENFbnRyeSBmb3Ig dGhlIA0gICAgICAgICAgICAgIExTUCB0byByZWRpcmVjdCBtYXRjaGluZyBwYWNrZXRzIHRvLiBJ ZiANICAgICAgICAgICAgICBtcGxzRlROQWN0aW9uVHlwZSBpcyByZWRpcmVjdFR1bm5lbCgzKSwg dGhlbiB0aGlzIA0gICAgICAgICAgICAgIG9iamVjdCBpbmRpY2F0ZXMgdGhlIGluc3RhbmNlIG9m IG1wbHNUdW5uZWxFbnRyeSBmb3IgDSAgICAgICAgICAgICAgdGhlIE1QTFMgdHVubmVsIHRvIHJl ZGlyZWN0IG1hdGNoaW5nIHBhY2tldHMgdG8uIA0gICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANDUFzIG1lbnRpb25lZCBlYXJs aWVyLCBhICJsb2dpY2FsIHR1bm5lbCIgaXMgYW4gYWJzdHJhY3Rpb24gb2YgYSBncm91cCBvZiB0 dW5uZWwgaW5zdGFuY2VzLiAgVGFraW5nIGFkdmFudGFnZSBvZiB0aGlzIGxldmVsIG9mIGluZGly ZWN0aW9uLCB3ZSBzaG91bGQgaGF2ZSBGRUMtdG8tTkhMRkUgbWFwcGluZyBlc3RhYmxpc2hlZCBp biB0aGUgbG9naWNhbCBsYXllciAoYmFzZWQgb24gImxvZ2ljYWwgdHVubmVscyIpLiAgTG9hZCBz aGFyaW5nLCBwYXRoIHNlbGVjdGlvbiBhbmQgZmFpbC1vdmVyIHNjaGVtZXMgc2hvdWxkIGJlIGhp ZGRlbiBpbiB0aGUgdW5kZXIfbHlpbmcgcGF0aCBsYXllciAoYmFzZWQgb24gInR1bm5lbCBpbnN0 YW5jZXMiKS4gU3VjaCBzY2hlbWVzIHNob3VsZCBiZSB0cmFuc3Bhch9lbnQgdG8gRlROIG1hcHBp bmcuIA1HaXZlbiB0aGF0IGN1cnJlbnRseSAibG9naWNhbCB0dW5uZWwiIGVudGl0eSBjbGFzcyBh bmQgInR1bm5lbCBpbnN0YW5jZSIgZW50aXR5IGNsYXNzIGFyZSBpbnRlcnR3aW5lZCBpbiB0aGUg c2FtZSBNSUIgdGFibGUsIHRoZXJlIGlzIG5vIHdheSB0byBtYWtlIEZFQyBtYXAgdG8gImxvZ2kf Y2FsIHR1bm5lbCIuICAoVGhpcyBtaWdodCBleHBsYWluIHdoeSAiRlROQWN0aW9uUG9pbnRlciIg aXMgbWFkZSB0byBwb2ludCB0byBhICJ0dW5uZWwgaW5zdGFuY2UiIGluIGN1cnJlbnQgTUlCIGRl ZmluaXRpb24uKSANUmVjb21tZW5kYXRpb24gDVRoZSBpc3N1ZXMgaW4gTVBMUy1URS1NSUIgYW5k IE1QTFMtRlROLU1JQiBhcmUgcmVhbGx5IGR1ZSB0byBhIHN0cnVjdHVyYWwgcHJvYh9sZW0gb2Yg bXBsc1R1bm5lbFRhYmxlLiAgV2UgY2FuIHJlc29sdmUgdGhlc2UgaXNzdWVzIGJ5IHNwbGl0aW5n IHRoZSBiaWcsIG1vbm9saXRoaWMgIm1wbHNUdW5uZWxUYWJsZSIgaW50byB0d28gc21hbGxlciB0 YWJsZXMsIGVhY2ggbW9kZWxpbmcgZXhhY3RseSBvbmUgZW50aXR5IGNsYXNzLiANICAgICAgICAg bXBsc0xvZ2ljYWxUdW5uZWxUYWJsZSANICAgICAgICAgbXBsc1R1bm5lbEluc3RhbmNlVGFibGUg DQ1UaGVuIG1vZGlmeSBtcGxzRlROQWN0aW9uUG9pbnRlciBkZWZpbml0aW9uIHRvIG1ha2UgaXQg cG9pbnRpbmcgdG8gYSByb3cgaW4gdGhlIGZpcnN0IHRhYmxlLiAgTm90ZSB0aGF0IGEgcm93IGlu IHRoZSBmaXJzdCB0YWJsZSBtYXkgY29ycmVzcG9uZCB0byBtdWx0aXBsZSByb3dzIGluIHRoZSBz ZWNvbmQgdGFibGUuIA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAABBAAAJAQAAEQEAAB0BAAAdQQAAH4E AAB/BAAAmwQAAJwEAACqBAAAqwQAAMcEAADIBAAA5QQAAOYEAAD4BAAA+QQAABUFAAAWBQAAFwUA ACAFAAAhBQAAngUAAJ8FAABbCgAAXAoAAJgKAADQCgAA0QoAAAgLAAAJCwAACgsAAHgOAACWDgAA lw4AALcOAAC4DgAA1w4AANgOAADwDgAA8Q4AAAoPAAALDwAAIw8AACQPAAA/DwAAQA8AAGMPAABk DwAAhQ8AAIYPAAClDwAApg8AAMgPAADJDwAA6Q8AAOoPAAAHEAAACBAAACAQAAAhEAAAQBAAAEEQ AABCEAAAmREAAJoRAAC3EgAA+RIAAPoSAAAkEwAAJRMAAEwTAABNEwAAdBMAAHUTAACKEwAAixMA APvy6+Ld1uvd693r3evd693r3evP3cTdxN3E3dbr3evP3dbr3evd693r3evd693r3evd693r3evd 693r3evd68/dxN3W693r3evd693rAAAAFDUIgUIqAENKFABeSgAAcGgAAAD/AAxDShgAT0oEAFFK BAAADUIqAF5KAwBwaAAAAP8JQioAcGgAAAD/EDUIgUIqAENKFgBwaAAAAP8ADDUIgUIqAHBoAAAA /wAQNQiBQioAQ0ogAHBoAAAA/wAIQ0oYAF5KAwBNAAQAAAEEAAAkBAAALwQAAEQEAABcBAAAdAQA AHUEAAB/BAAAnAQAAKsEAADIBAAA5gQAAPkEAAAWBQAAFwUAACEFAACTBQAAnwUAAFMGAAAcBwAA +wAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAA AAAAAAAAAAD0AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADjAAAAAAAAAAAA AAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOMA AAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAL8AAAAAAAAAAAAAAAC6AAAAAAAA AAAAAAAAvwAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAotAA3GBwG0BwFUDQAUpMgA MSQBBRAAFKTIADEkAQ4uAA3GBwE4BAFoAQAPhGgBFKTIADEkAV6EaAEHEAATpMgAFKTIADEkAQAO AAANxhQABqAFQAvgEIAWIBzAIQAAAAAAADEkAQcZAA3GBQABwCEAMSQBAAUZAA3GBQABwCEAAAMP ABSkyAAABg8AAyQBFKTIAGEkAQADAAAUpMgAABQABAAAHBoAAP0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBARwHAACTBwAAbwgAAN4JAABCCgAAXAoAAJgKAADR CgAACQsAAAoLAADACwAATgwAAGoMAAB8DQAAmw0AAHgOAACXDgAAuA4AANgOAADxDgAACw8AACQP AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA4gAA AAAAAAAAAAAAAOcAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAAMwAAAAAAAAA AAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA tQAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAA AAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAAAAAAs1AA3GCgE4 BAJoAdACAAAUpMgAMSQBAAo2AA3GCAACaAHQAgAAFKTIADEkAQAOAAANxhQABqAFQAvgEIAWIBzA IQAAAAAAADEkAQcZAA3GBQABwCEAMSQBBRAAFKTIADEkAQ4uAA3GBwE4BAFoAQAPhGgBFKTIADEk AV6EaAEKLQANxgcBtAcBVA0AFKTIADEkAQAVJA8AAEAPAABkDwAAhg8AAKYPAADJDwAA6g8AAAgQ AAAhEAAAQRAAAEIQAAB/EQAAmhEAAM4RAAC3EgAA+hIAACUTAABNEwAAdRMAAIsTAADMEwAAEBQA AEcUAACIFAAAzBQAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA AAAA+AAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAAM8A AAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAo2AA3GCAACaAHQAgAA FKTIADEkAQUQABSkyAAxJAEKLQANxgcBtAcBVA0AFKTIADEkAQAOAAANxhQABqAFQAvgEIAWIBzA IQAAAAAAADEkAQcZAA3GBQABwCEAMSQBABiLEwAAyxMAAMwTAAAPFAAAEBQAAEYUAABHFAAAhxQA AIgUAADLFAAAzBQAAAsVAAAMFQAAThUAAE8VAABQFQAAKBgAACkYAAAhGQAAQRkAAEIZAABjGQAA ZBkAAGUZAAAcGgAA+vP68/rz+vP68/rz+vPs+uH62vP68+z6AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADUIqAF5KAwBwaAAAAP8UNQiBQioAQ0oUAF5KAABwaAAAAP8ADENKGABPSgQAUUoEAAAM NQiBQioAcGgAAAD/AAlCKgBwaAAAAP8AGMwUAAAMFQAATxUAAFAVAAD1FgAAGRgAACkYAAAhGQAA QhkAAGQZAABlGQAAHBoAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAN8A AAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAAMwAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4uAA3GBwE4BAFoAQAPhGgBFKTIADEk AV6EaAEFEAAUpMgAMSQBCi0ADcYHAbQHAVQNABSkyAAxJAEADgAADcYUAAagBUAL4BCAFiAcwCEA AAAAAAAxJAEHGQANxgUAAcAhADEkAQALKQAJMAARMAESMAAcUAEAH7DQLyCw4D0hsKAFIrCgBSOQ oAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAD0ACgABAGkADwADAAAAAAAAAAAASAAAQPH/AgBIAAwA BgBOAG8AcgBtAGEAbAAAAA4AAAAxJAA3JAA4JABIJAAcAE9KAwBRSgMAX0gBBGFKGABtSAkEc0gJ BHRICQQAAAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQAZQBmAGEAdQBsAHQAIABQAGEA cgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAALgD+TwEA8gAuAAwABABCAG8AZAB5 AAAAAgAPABEAQioBQ0oYAF5KAwBwaAAAAAAAOAD+TwEAAgE4AAwACABCAG8AbABkAEIAbwBkAHkA AAACABAAFAA1CIFCKgFDShgAXkoDAHBoAAAAAFIA/k8BABIBUgAMAAgAQgB1AGwAbABlAHQAZQBk AAAAHQARAA3GCAAC0AI4BAAAD4TQAhGEmP5ehNACYISY/gARAEIqAUNKGABeSgMAcGgAAAAAAFAA /k8BACIBUAAMAAkAQgB1AGwAbABlAHQAZQBkADIAAAAaABIADcYFAAFoAQAPhGgBEYSY/l6EaAFg hJj+EQBCKgFDShgAXkoDAHBoAAAAAABIAP5PAQAyAUgADAAJAEIAdQBsAGwAZQB0AGUAZAAzAAAA EgATAA3GBQABAAAAEYSY/mCEmP4RAEIqAUNKGABeSgMAcGgAAAAAADwA/k8BAEIBPAAMAAgAQwBl AGwAbABCAG8AZAB5AAAACAAUAAMkAWEkAREAQioBQ0oYAF5KAwBwaAAAAAAARAD+TwEAUgFEAAwA CwBDAGUAbABsAEgAZQBhAGQAaQBuAGcAAAAIABUAAyQBYSQBFAA1CIFCKgFDShgAXkoDAHBoAAAA AFQA/k8BAGIBVAAMAAsAQwBvAHUAcgBpAGUAcgBCAG8AZAB5AAAAFgAWAA3GEQAFoAVAC+AQgBYg HAAAAAAAFQBCKgFDShgAT0oEAFFKBABwaAAAAAAAVAD+TwEAcgFUAAwADQBDAG8AdQByAGkAZQBy AEIAbwBkAHkAMQAwAAAAFgAXAA3GEQAFoAVAC+AQgBYgHAAAAAAAEQBCKgFPSgQAUUoEAHBoAAAA AABYAP5PAQCCAVgADAANAEMAbwB1AHIAaQBlAHIAQgBvAGQAeQAxADEAAAAWABgADcYRAAWgBUAL 4BCAFiAcAAAAAAAVAEIqAUNKFgBPSgQAUUoEAHBoAAAAAABaAP5PAQCSAVoADAAPAEMAbwB1AHIA aQBlAHIAQgBvAGwAZABCAG8AZAB5AAAAFgAZAA3GEQAFoAVAC+AQgBYgHAAAAAAAFAA1CIFCKgFP SgQAUUoEAHBoAAAAAFgA/k8BAKIBWAAMAA8AQwBvAHUAcgBpAGUAcgBJAG4AZABlAG4AdABlAGQA AAASABoADcYFAAHQAgAPhNACXoTQAhUAQioBQ0oYAE9KBABRSgQAcGgAAAAAAFoA/k8BALIBWgAM ABAAQwBvAHUAcgBpAGUAcgBJAG4AZABlAG4AdABlAGQAMgAAABIAGwANxgUAAWgBAA+EaAFehGgB FQBCKgFDShgAT0oEAFFKBABwaAAAAAAAUgD+TwEAwgFSAAwAEABDAG8AdQByAGkAZQByAEkAbgBk AGUAbgB0AGUAZAAzAAAACgAcAA3GBQABAAAAFQBCKgFDShgAT0oEAFFKBABwaAAAAAAARAD+TwEA 0gFEAAwACwBGAGkAZwB1AHIAZQBUAGkAdABsAGUAAAAIAB0AAyQBYSQBFAA1CIFCKgFDShgAXkoD AHBoAAAAAD4AIEABAOIBPgAMAAYARgBvAG8AdABlAHIAAAANAB4ADcYIAAKoDPAeAQIAEQBCKgFD ShAAXkoDAHBoAAAAAABeAP5PAQDyAV4ADAAIAEYAbwBvAHQAbgBvAHQAZQAAACUAHwANxggAAlID OAQAAA6EaAEPhFIDEYQa/12EaAFehFIDYIQa/wAVAEIqAU9KBQBRSgUAXkoFAHBoAAAAAABAAB9A AQACAkAADAAGAEgAZQBhAGQAZQByAAAAEwAgAAMkAw3GCAACqAycHwECYSQDAA0AQioBXkoDAHBo AAAAAABUAP5PAQASAlQADAAIAEgAZQBhAGQAaQBuAGcAMQAAAB0AIQANxggAAvwCoAUAAA+EjAMR hOz9XoSMA2CE7P0AFAA1CIFCKgFDShgAXkoDAHBoAAAAAEAA/k8BACICQAAMAAgASABlAGEAZABp AG4AZwAyAAAACgAiAA3GBQAB+AEAFAA1CIFCKgFDShgAXkoDAHBoAAAAAFwA/k8BADICXAAMAAgA SABlAGEAZABpAG4AZwAzAAAAJQAjAA3GCAACIAGzAgAADoTmAA+EswIRhK33XYTmAF6EswJghK33 ABQANQiBQioBQ0oYAF5KAwBwaAAAAAA4AP5PAQBCAjgADAAIAEgAZQBhAGQAaQBuAGcANAAAAAIA JAAUADUIgUIqAUNKGABeSgMAcGgAAAAASAD+TwEAUgJIAAwACABIAGUAYQBkAGkAbgBnADUAAAAS ACUAD4TYABGEOPtehNgAYIQ4+xQANQiBQioBQ0oYAF5KAwBwaAAAAABIAP5PAQBiAkgADAAIAEgA ZQBhAGQAaQBuAGcANgAAABIAJgANxgUAAQAAABGEYPpghGD6FAA1CIFCKgFDShgAXkoDAHBoAAAA AFIA/k8BAHICUgAMAAgASABlAGEAZABpAG4AZwA3AAAAHQAnAA3GCAACIAFoAQAAD4RoARGE+Phe hGgBYIT4+AARAEIqAUNKGABeSgMAcGgAAAAAAEgA/k8BAIICSAAMAAwASABlAGEAZABpAG4AZwBS AHUAbgBJAG4AAAACACgAHAA1CIFCKgFDShgAT0oFAFFKBQBeSgUAcGgAAAAAQAD+TwEAkgJAAAwA DQBIAGUAbAB2AGUAdABpAGMAYQBCAG8AZAB5AAAAAgApABEAQioBQ0oYAF5KAwBwaAAAAAAAUAD+ TwEAogJQAAwAEQBIAGUAbAB2AGUAdABpAGMAYQBJAG4AZABlAG4AdABlAGQAAAAKACoAD4TQAl6E 0AIRAEIqAUNKGABeSgMAcGgAAAAAAFoA/k8BALICWgAMABIASABlAGwAdgBlAHQAaQBjAGEASQBu AGQAZQBuAHQAZQBkADIAAAASACsADcYFAAFoAQAPhGgBXoRoAREAQioBQ0oYAF5KAwBwaAAAAAAA UgD+TwEAwgJSAAwAEgBIAGUAbAB2AGUAdABpAGMAYQBJAG4AZABlAG4AdABlAGQAMwAAAAoALAAN xgUAAQAAABEAQioBQ0oYAF5KAwBwaAAAAAAASgD+TwEA0gJKAAwACABJAG4AZABlAG4AdABlAGQA AAAVAC0ADcYIAALQArQHAAAPhNACXoTQAgARAEIqAUNKGABeSgMAcGgAAAAAAEgA/k8BAOICSAAM AAkASQBuAGQAZQBuAHQAZQBkADAAAAASAC4ADcYFAAE4BAAPhDgEXoQ4BBEAQioBQ0oYAF5KAwBw aAAAAAAATAD+TwEA8gJMAAwACQBJAG4AZABlAG4AdABlAGQAMgAAABUALwANxggAAmgBtAcAAA+E aAFehGgBABEAQioBQ0oYAF5KAwBwaAAAAAAAQAD+TwEAAgNAAAwACQBJAG4AZABlAG4AdABlAGQA MwAAAAoAMAANxgUAAQAAABEAQioBQ0oYAF5KAwBwaAAAAAAAUgD+TwEAEgNSAAwACABOAHUAbQBi AGUAcgBlAGQAAAAdADEADcYIAALQAjgEAAAPhNACEYSY/l6E0AJghJj+ABEAQioBQ0oYAF5KAwBw aAAAAAAASAD+TwEAIgNIAAwACQBOAHUAbQBiAGUAcgBlAGQAMQAAABIAMgAPhNACEYSY/l6E0AJg hJj+EQBCKgFDShgAXkoDAHBoAAAAAABQAP5PAQAyA1AADAAJAE4AdQBtAGIAZQByAGUAZAAyAAAA GgAzAA3GBQABaAEAD4RoARGEmP5ehGgBYISY/hEAQioBQ0oYAF5KAwBwaAAAAAAATAD+TwEAQgNM AAwACwBOAHUAbQBiAGUAcgBlAGQAMgAtADEAAAASADQAD4RoARGEmP5ehGgBYISY/hEAQioBQ0oY AF5KAwBwaAAAAAAAUAD+TwEAUgNQAAwACQBOAHUAbQBiAGUAcgBlAGQAQQAAABoANQANxgUAATgE AA+E0AIRhJj+XoTQAmCEmP4RAEIqAUNKGABeSgMAcGgAAAAAAEwA/k8BAGIDTAAMAAsATgB1AG0A YgBlAHIAZQBkAEEALQAxAAAAEgA2AA+E0AIRhJj+XoTQAmCEmP4RAEIqAUNKGABeSgMAcGgAAAAA ADQA/k8BAHIDNAAMAAcAcABnAGMAbwB1AG4AdAAAAAIANwARAEIqAUNKGABeSgMAcGgAAAAAAFwA /k8BAIIDXAAMAA0AVABhAGIAbABlAEYAbwBvAHQAbgBvAHQAZQAAABoAOAAOhGgBD4RSAxGEGv9d hGgBXoRSA2CEGv8VAEIqAU9KBQBRSgUAXkoFAHBoAAAAAABCAP5PAQCSA0IADAAKAFQAYQBiAGwA ZQBUAGkAdABsAGUAAAAIADkAAyQBYSQBFAA1CIFCKgFDShgAXkoDAHBoAAAAAD4APkABAKIDPgAM AAUAVABpAHQAbABlAAAADgA6AAMkARJkVAEAAGEkARQANQiBQioBQ0osAF5KAwBwaAAAAAAkAFhA ogCxAyQADAAIAEUAbQBwAGgAYQBzAGkAcwAAAAMANgiBADYA/k/y/8EDNgAMABEARQBxAHUAYQB0 AGkAbwBuAFYAYQByAGkAYQBiAGwAZQBzAAAAAwA2CIEAAAAAABwWAAAGAABAAAABAP////8AAAAA AQAAACQAAAAvAAAARAAAAFwAAAB0AAAAdQAAAH8AAACcAAAAqwAAAMgAAADmAAAA+QAAABYBAAAX AQAAIQEAAJMBAACfAQAAUwIAABwDAACTAwAAbwQAAN4FAABCBgAAXAYAAJgGAADRBgAACQcAAAoH AADABwAATggAAGoIAAB8CQAAmwkAAHgKAACXCgAAuAoAANgKAADxCgAACwsAACQLAABACwAAZAsA AIYLAACmCwAAyQsAAOoLAAAIDAAAIQwAAEEMAABCDAAAfw0AAJoNAADODQAAtw4AAPoOAAAlDwAA TQ8AAHUPAACLDwAAzA8AABAQAABHEAAAiBAAAMwQAAAMEQAATxEAAFARAAD1EgAAGRQAACkUAAAh FQAAQhUAAGQVAABlFQAAHhYAAJgAAAAAMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgA AAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAA AAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAA AACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAQMAAAAAAAAACAAAAAgJgAAAAuMAAAAAAAAACAAAAAgJgAAAAQMAAAAAAAAACAAAAA gJgAAAAuMAAAAAAAAACAAAAAgJgAAAAtMAAAAAAAAACAAAAAgJgAAAAtMAAAAAAAAACAAAAAgJgA AAAtMAAAAAAAAACAAAAAgJgAAAAuMAAAAAAAAACAAAAAgJgAAAAuMAAAAAAAAACAAAAAgJgAAAAQ MAAAAAAAAACAAAAAgJgAAAAuMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAuMAAAAAAAAACAAAAAgJgAAAAuMAAAAAAA AACAAAAAgJgAAAA2MAAAAAAAAACAAAAAgJgAAAAtMAAAAAAAAACAAAAAgJgAAAA1MAAAAAAAAACA AAAAgJgAAAAtMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAA gJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgA AAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZ MAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAA AAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAtMAAAAAAAAACAAAAAgJgAAAAQMAAAAAAAAACA AAAAgJgAAAA2MAAAAAAAAACAAAAAgJgAAAAtMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAA gJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgA AAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZ MAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAA AAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAtMAAAAAAA AACAAAAAgJgAAAAtMAAAAAAAAACAAAAAgJgAAAAQMAAAAAAAAACAAAAAgJgAAAAuMAAAAAAAAACA AAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAZMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAuMAAAAAAAAACAAAAAgAAEAACLEwAAHBoAABkAAAAeAAAAAAQAABwHAAAkDwAAzBQAABwa AAAaAAAAHAAAAB0AAAAfAAAAAAQAABwaAAAbAAAAAAAAAFgCAABcAgAALgMAADIDAAAaCAAAKQgA AG4IAAB9CAAAgQoAAJUKAACgCgAAtgoAAMEKAADWCgAA4QoAAO8KAAD6CgAACQsAABQLAAAiCwAA LQsAAD4LAABJCwAAYgsAAG0LAACECwAAjwsAAKQLAACvCwAAxwsAANILAADoCwAA8wsAAAYMAAAR DAAAHwwAACoMAAA/DAAAKw8AAD8PAABpDwAAcw8AAJwPAACtDwAAsQ8AALwPAAD7DwAABhAAAFUQ AABmEAAAahAAAHgQAAC3EAAAxhAAAMITAADSEwAAfxQAAI4UAACwFAAAuBQAAM4UAADdFAAAKhUA AEAVAABLFQAAYhUAAHEVAACFFQAAHhYAAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAACcAAAA qQAAAKsAAACxAAAAyAAAAM4AAADmAAAA9wAAAIcGAACPBgAAngYAAKMGAADXBgAA3AYAAIEKAACV CgAAoAoAALYKAADBCgAA1goAAOEKAADvCgAA+goAAAkLAAAUCwAAIgsAAC0LAAA+CwAASQsAAGIL AABtCwAAhAsAAI8LAACkCwAArwsAAMcLAADSCwAA6AsAAPMLAAAGDAAAEQwAAB8MAAAqDAAAPwwA ACsPAAA/DwAAsQ8AAL0PAADaDwAA4A8AAB4QAABCEAAAVRAAAGYQAACWEAAAnBAAANoQAADdEAAA KhUAAEAVAABLFQAAYhUAAB4WAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwD//wIAAAAEAHIAegBoAHUAGABVADoAXABE AFwAUwBFAFwATgBNAFwATQBQAEwAUwBUAEUALgB2ADIALgBkAG8AYwD/QAOAAQB0AAAAdAAAAFgh vwIBAAAAdAAAAAAAAAB0AAAAAAAAAAIQAAAAAAAAABwWAABgAAAIAEAAAP//AQAAAAcAVQBuAGsA bgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAG AAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4A ZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAA AFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEA cgBpAGEAbAAAADsmkAEAAAILBgQCAgICAgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABIAGUAbAB2 AGUAdABpAGMAYQAAAE8xkAEACAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAG8A dQByAGkAZQByAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAMxaQAQAAAgIGAwUEBQIDBId6ACAA AACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAAACIABABBAIgYAPDQAgAAaAEAAAAAUURrplFE a6YAAAAAAgAEAAAAMgMAADsSAAABAAkAAAAEAAMAJgAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAk AwDwEAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHeAB4AIMAMgAAAAAAAAAAAAAAAAAA AGMWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAA3wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD//xIAAAAAAAAAIgBBACAAUwB0AHIAdQBjAHQAdQByAGEAbAAgAEMAaABhAG4AZwBlACAA aQBuACAATQBQAEwAUwAtAFQARQAtAE0ASQBCAAAAAAAAAAQAcgB6AGgAdQAEAHIAegBoAHUAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACI AQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAxAAAAAQAAADQAAAABQAAAOAAAAAGAAAA7AAAAAcA AAD4AAAACAAAAAwBAAAJAAAAHAEAABIAAAAoAQAACgAAAEQBAAAMAAAAUAEAAA0AAABcAQAADgAA AGgBAAAPAAAAcAEAABAAAAB4AQAAEwAAAIABAAACAAAA5AQAAB4AAAAjAAAAQSBTdHJ1Y3R1cmFs IENoYW5nZSBpbiBNUExTLVRFLU1JQgBzHgAAAAEAAAAAIFN0HgAAAAUAAAByemh1AHVjdB4AAAAB AAAAAHpodR4AAAABAAAAAHpodR4AAAALAAAATm9ybWFsLmRvdABsHgAAAAUAAAByemh1AGwuZB4A AAACAAAAMgBodR4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4wACBAAAAAABgNjwAAAABAAAAAAL55 8HyHwgFAAAAAAL558HyHwgEDAAAAAQAAAAMAAAAyAwAAAwAAADsSAAADAAAAAAAAAAAAAAAAAAAA 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 /v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAIAEAAAwAAAAB AAAAaAAAAA8AAABwAAAABQAAAJAAAAAGAAAAmAAAABEAAACgAAAAFwAAAKgAAAALAAAAsAAAABAA AAC4AAAAEwAAAMAAAAAWAAAAyAAAAA0AAADQAAAADAAAAP8AAAACAAAA5AQAAB4AAAAWAAAAU2Fu dGVyYSBTeXN0ZW1zLCBJbmMuAGEAAwAAACYAAAADAAAACQAAAAMAAABjFgAAAwAAAKAKCQALAAAA AAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAIwAAAEEgU3RydWN0dXJhbCBDaGFu Z2UgaW4gTVBMUy1URS1NSUIADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAA AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAAR AAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8A AAAgAAAA/v///yIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAA AC4AAAAvAAAA/v///zEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAD+////OQAAADoAAAA7AAAA PAAAAD0AAAA+AAAAPwAAAP7////9////QgAAAP7////+/////v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////UgBvAG8AdAAg AEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYA BQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAoGT+/HyHwgFEAAAAgAAA AAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACEAAAAlHQAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBQAAAP//////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACtAAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAABAAAAAAAAAFAEQAbwBjAHUA bQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAAC Af///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAEAAA AAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAASAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGoAAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAKBk/vx8h8IBoGT+/HyHwgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////AQD+/wMKAAD///// BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9j ABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_001_01C28786.726B1BF8-- From owner-mpls@UU.NET Fri Nov 8 20:34:34 2002 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 ESMTP id UAA25761 for ; Fri, 8 Nov 2002 20:34:33 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnody07709 for ; Sat, 9 Nov 2002 01:37:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnody05714; Sat, 9 Nov 2002 01:35:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnody17489 for mpls-outgoing; Sat, 9 Nov 2002 01:35:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnody17482 for ; Sat, 9 Nov 2002 01:35:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnody07401 for ; Sat, 9 Nov 2002 01:35:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnody04991 for ; Sat, 9 Nov 2002 01:35:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnody04981 for ; Sat, 9 Nov 2002 01:35:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA21596 for ; Fri, 8 Nov 2002 20:35:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gA91Z5014348 for mpls@uu.net; Fri, 8 Nov 2002 20:35:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnody17439 for ; Sat, 9 Nov 2002 01:33: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 QQnody18071 for ; Sat, 9 Nov 2002 01:33:44 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnody04233 for ; Sat, 9 Nov 2002 01:33:44 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnody04229 for ; Sat, 9 Nov 2002 01:33:43 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 UAA30869; Fri, 8 Nov 2002 20:30:56 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200211090130.UAA30869@workhorse.fictitious.org> To: "Zhu, Rupert" cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: MIB Report 3/3: A Structural Issue In-reply-to: Your message of "Fri, 08 Nov 2002 18:25:03 CST." Date: Fri, 08 Nov 2002 20:30:56 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk Speaking of style problems, please DON'T send doc files to the mailing list. Microsoft free sites can't read these files. Curtis From owner-mpls@UU.NET Sun Nov 10 09:18:15 2002 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 ESMTP id JAA16929 for ; Sun, 10 Nov 2002 09:18:14 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnojp10815 for ; Sun, 10 Nov 2002 14:20:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnojp09192; Sun, 10 Nov 2002 14:19:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQnojp14998 for mpls-outgoing; Sun, 10 Nov 2002 14:19:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnojp14993 for ; Sun, 10 Nov 2002 14:19:22 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 QQnojp01035 for ; Sun, 10 Nov 2002 14:19:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnojp15663 for ; Sun, 10 Nov 2002 14:19:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnojp15653 for ; Sun, 10 Nov 2002 14:19:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA04578 for ; Sun, 10 Nov 2002 09:19:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAAEJ5824315 for mpls@uu.net; Sun, 10 Nov 2002 09:19:05 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnojp14971 for ; Sun, 10 Nov 2002 14:18:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnojp05168 for ; Sun, 10 Nov 2002 14:18:05 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnojp15069 for ; Sun, 10 Nov 2002 14:18:05 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnojp15059 for ; Sun, 10 Nov 2002 14:18:05 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAAEIMkK022826; Sun, 10 Nov 2002 09:18:23 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-31.cisco.com [10.86.242.31]) by bucket.cisco.com (Mirapoint) with ESMTP id ACC13139; Sun, 10 Nov 2002 09:18:02 -0500 (EST) Message-Id: <4.3.2.7.2.20021110090347.054e5878@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Nov 2002 09:17:57 -0500 To: "Zhu, Rupert" From: "Thomas D. Nadeau" Subject: Re: MIB Report 3/3: A Structural Issue Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Let me answer your questions as part of a plain ASCII text response (we do not pass around WORD files at the IETF). > In MPLS-TE-MIB, the logical entity "traffic trunk" is modeled as "logical tunnel" while the underlying "path" entity is modeled as "tunnel instance". This makes > > good distinction. > Unfortunately, these two distinct entity classes are intertwined into a single MIB table (mplsTunnelTable). This causes following problems. > A. Ambiguity of Properties > The mplsTunnelTable has as many as 37 columns. Some of them represent properties of "logical tunnel" entity while others are properties of underlying "tunnel > instance" entity. There is no clear distinction of these two categories when intermixing them in the same table. A single table was used for simplicity, and frankly has been around for about 2 years with very few complains and much more positive responses from over a dozen implementations. This is not the time to re-engineer the world simply because you do not think that it fits into your object model. Although I will submit that this might not be the most optimal approach, it still works and is being used by many successfully, thus I do not think it is prudent to completely change the design at this point in time. To this end, we have been pretty clear which objects apply when, and have further suggested how to index the tunnels to provide a consistent view of tunnels or tunnel instances. If you do not think the text is clear, please make suggestions to improve the descriptions. > B. Duplication of Information > A "logical tunnel" corresponds to a group of "tunnel instances". For all "tunnel instances" in one "tunnel instance group", their "logical tunnel" attributes (i.e., > table fields) must have identical value. For example, > mplsTunnelIndexIndex > mplsTunnelIngressLSRId > mplsTunnelEgressLSRId > mplsTunnelName > mplsTunnelDescr > mplsTunnelIsIf > mplsTunnelIfIndex > mplsTunnelPrimaryInstance > mplsTunnelPrimaryTimeUp > mplsTunnelPathChanges > mplsTunnelLastPathChange > mplsTunnelCreationTime > mplsTunnelPathInUse > mplsTunnelRole > mplsTunnelTotalUpTime > > Therefore, these fields must be duplicated across all rows belonging to the same "tunnel instance group". (A violation of relational data model principles.) The first set of objects is duplicated between entries to keep the indexing consistent between tunnel heads and instances. The remaining objects that you claim are redundant are in fact there so that managers can keep track of the specifics of what the head or instance is doing (or have done). > Furthermore, if network administrator accidentally put different values to two rows belonging to the same instance group, > MIB integrity would be compromised This statement is too vague, please be more specific so that we can address your concerns. --Tom >------------------------------------------------------------ >MIB Report 3/3: A Structural Issue > > >Similar to relational database design, a very important aspect of >MIB design is its overall structure. That is, how to partition >total data, or how to group basic data items to form tables. > >In MIB design process, general object modeling techniques and principles >should apply. For example, any of the following. > >o Entity-Relationship Model (E-R Model). >o Relational Data Model. >o Common Information Model (CIM) by DMTF. >o Universal Modeling Methodology (UML) by Rumbaugh, etc. > >As a rule of thumb, each object class should be mapped to a distinct >MIB table. In particular, if two object classes have a one-to-many >relationship, DO NOT combine them into the same MIB table. > >The current MPLS-TE-MIB design does not comply with object modeling >principles because it lumps two distinct object classes in a single >MIB table. It results in a big, 37-field table. This design causes >undesirable data duplications and obscures logical relationship >to MPLS-FTN-MIB. > >I would like to recommend a modular design that splits the big >monolithic table into two separate tables, each representing >exactly one object class. > >Although I won't be able to attend the upcoming MPLS MIB Review in >Atlanta, I hope this proposal could be considered. > > >Rupert Zhu >System Engineering >Santera Systems Inc >3605 E. Plano Parkway >Plano, TX 75074 >Phone: 972-461-6383 Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Sun Nov 10 13:10:30 2002 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 ESMTP id NAA20757 for ; Sun, 10 Nov 2002 13:10:30 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoke14809 for ; Sun, 10 Nov 2002 18:12:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnoke12699; Sun, 10 Nov 2002 18:11:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnoke09403 for mpls-outgoing; Sun, 10 Nov 2002 18:11:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnoke09398 for ; Sun, 10 Nov 2002 18:11:38 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 QQnoke11726 for ; Sun, 10 Nov 2002 18:11:18 GMT From: jcucchiara@mindspring.com Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoke04563 for ; Sun, 10 Nov 2002 18:11:17 GMT Received: from mclean.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mclean.mail.mindspring.net [207.69.200.57]) id QQnoke04558 for ; Sun, 10 Nov 2002 18:11:17 GMT Received: from dialup-63.214.127.235.dial1.boston1.level3.net ([63.214.127.235] helo=jluciani-laptop) by mclean.mail.mindspring.net with smtp (Exim 3.33 #1) id 18AwYG-00064X-00; Sun, 10 Nov 2002 13:11:16 -0500 Message-Id: <3.0.1.32.20021110132129.006e4b78@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 10 Nov 2002 13:21:29 -0500 To: "Zhu, Rupert" , Subject: Re: MIB Report 2/3: Coding Anomalies In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello Rupert, Thank you for the comments. Please see in-line. At 05:47 PM 11/8/02 -0600, Zhu, Rupert wrote: >------------------------------------------------------------ >MIB Report 2/3: Coding Style Anomalies > > >I run a "lint" (i.e., coding style checking) over the latest >version of MPLS MIB drafts and generated a report. > > draft-ietf-mpls-bundle-mib-04.fmt > draft-ietf-mpls-fastreroute-mib-01.fmt > draft-ietf-mpls-ftn-mib-04.fmt > draft-ietf-mpls-ldp-mib-09.fmt > draft-ietf-mpls-lsr-mib-09.fmt > draft-ietf-mpls-tc-mib-05.fmt > draft-ietf-mpls-te-mib-09.fmt > > >9 coding style anomalies are detected. (A small number, compared with >525 object types and 22 TCs in total.) > >The anomalies fall in 2 categories. > >1. ENUM value list started with zero (0). > GUIDELINE: All ENUM value list should start from 1 and up. This was due to SMIv1 but SMIv2 does allow 0. Admittedly, many MIB authors were concerned with backwards compatibility issues and start enums at 1 where it makes sense to do so. In the LDP-MIB the reason that these enums start with 0 is because the actual values sent on the wire for these values would be 0. I didn't see any reason that there should be "extra" code in there checking an enum and then re-interrupting the value to zero to send on the wire. Thanks, Joan > >2. Define Numeric range with INTEGER. > GUIDELINE: All numeric range should be defined with > Integer32 or Unsigned32. > >These are not errors, but coding style anomalies. See details below. > >-- Rupert > > >#==================================================================== ># Checking on Objects > >MODULE=LINK-BUNDLING-MIB > >MODULE=MPLS-FRR-MIB > >WARNING: ENUM Starts with Zero (0) > mplsFrrConstProtectionMethod > INTEGER { oneToOneBackup (0), facilityBackup (1) } > >WARNING: ENUM Starts with Zero (0) > mplsFrrConstProtectionType > INTEGER { linkProtection (0), nodeProtection (1) } > >WARNING: ENUM Starts with Zero (0) > mplsFrrDetourMerging > INTEGER { none (0), protectedTunnel (1), detour(2) } > >MODULE=MPLS-FTN-MIB > >MODULE=MPLS-LDP-MIB > >WARNING: ENUM Starts with Zero (0) > mplsLdpEntityAtmMergeCap > INTEGER { notSupported (0), vcMerge (2) } > >WARNING: ENUM Starts with Zero (0) > mplsLdpEntityAtmVcDirectionality > INTEGER { bidirectional (0), unidirectional (1) } > >WARNING: ENUM Starts with Zero (0) > mplsLdpEntityFrMergeCap > INTEGER { notSupported (0), supported (1) } > >WARNING: ENUM Starts with Zero (0) > mplsLdpEntityFrLength > INTEGER { tenDlciBits (0), twentyThreeDlciBits (2) } > >WARNING: ENUM Starts with Zero (0) > mplsLdpEntityFrVcDirectionality > INTEGER { bidirectional (0), unidirection (1) } > >WARNING: ENUM Starts with Zero (0) > mplsLdpFrSesLength > INTEGER { tenDlciBits (0), twentyThreeDlciBits (2) } > >MODULE=MPLS-LSR-MIB > >MODULE=MPLS-TE-MIB > >Total Warnings: 9 > > From owner-mpls@UU.NET Sun Nov 10 13:31:53 2002 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 ESMTP id NAA21278 for ; Sun, 10 Nov 2002 13:31:53 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnokg02637 for ; Sun, 10 Nov 2002 18:34:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnokg00864; Sun, 10 Nov 2002 18:33:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQnokg11114 for mpls-outgoing; Sun, 10 Nov 2002 18:33:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnokg11109 for ; Sun, 10 Nov 2002 18:33:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnokg14651 for ; Sun, 10 Nov 2002 18:32:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnokg02547 for ; Sun, 10 Nov 2002 18:32:07 GMT Received: from excalibur.santera.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnokg02536 for ; Sun, 10 Nov 2002 18:32:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MIB Report 3/3: A Structural Issue Date: Sun, 10 Nov 2002 12:32:02 -0600 Message-ID: Thread-Topic: MIB Report 3/3: A Structural Issue Thread-Index: AcKHkAjZ7ioE8IQnRn2/3KsIHRgIlgBVtI7g From: "Zhu, Rupert" To: Cc: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA21278 Curtis, Sorry for the inconvenience. Here is the plain text version. ----------------------------------------------- A Structural Change in MPLS-TE-MIB (Draft 1.0, 2002-06-07) (Draft 1.1, 2002-11-07) Contents --------------------------- o Background o The Issue in MPLS-TE-MIB o The Issue in MPLS-FTN-MIB o Recommendation --------------------------- -- Abstract This short memo analyzes issues in MPLS-TE-MIB and MPLS-FTN-MIB design and recommends a structural modification. -- Background The concept of "traffic trunk" and "path" (LSP) are discussed extensively in a number of IETF RFC documents. In particular, the following excerpt is from RSVP-TE spec [RFC3209]. "The LSPs created with RSVP can be used to carry the "Traffic Trunks" described in [RFC2702]. The LSP which carries a traffic trunk and a traffic trunk are distinct though closely related concepts." "For example, two LSPs between the same source and destination could be load shared to carry a single traffic trunk." "Conversely several traffic trunks could be carried in the same LSP if, for instance, the LSP were capable of carrying several service classes. The applicability of these extensions is discussed further in [RFC3210]." Combining the discussions in RFC2702 (MPLS TE), RFC3209 and RFC3210 (RSVP-TE), we can see that "traffic trunk" and "path" (LSP) are two distinct concepts. The former is an abstract logical entity while the latter is the underlying concrete entity. A single "traffic trunk" may correspond to a group of "paths" via load sharing, backup protection or other schemes. The distinction of "traffic trunk" from the underlying path(s) represents a level of indirection. -- The Issue in MPLS-TE-MIB The discussion is based on the most recent internet drafts draft-ietf-mpls-ftn-mib-04.txt MPLS-FTN-MIB draft-ietf-mpls-te-mib-09.txt MPLS-TE-MIB In MPLS-TE-MIB, the logical entity "traffic trunk" is modeled as "logical tunnel" while the underlying "path" entity is modeled as "tunnel instance". This makes good distinction. Unfortunately, these two distinct entity classes are intertwined into a single MIB table (mplsTunnelTable). This causes following problems. -- Ambiguity of Properties The mplsTunnelTable has as many as 37 columns. Some of them represent properties of "logical tunnel" entity while others are properties of underlying "tunnel instance" entity. There is no clear distinction of these two categories when intermixing them in the same table. -- Duplication of Information A "logical tunnel" corresponds to a group of "tunnel instances". For all "tunnel instances" in one "tunnel instance group", their "logical tunnel" attributes (i.e., table fields) must have identical value. For example, mplsTunnelIndexIndex mplsTunnelIngressLSRId mplsTunnelEgressLSRId mplsTunnelName mplsTunnelDescr mplsTunnelIsIf mplsTunnelIfIndex mplsTunnelPrimaryInstance mplsTunnelPrimaryTimeUp mplsTunnelPathChanges mplsTunnelLastPathChange mplsTunnelCreationTime mplsTunnelPathInUse mplsTunnelRole mplsTunnelTotalUpTime Therefore, these fields must be duplicated across all rows belonging to the same "tunnel instance group". Therefore, these fields must be duplicated across all rows belonging to the same "tunnel instance group". (A violation of relational data model principles.) Furthermore, if network administrator accidentally put different values to two rows belonging to the same instance group, MIB integrity would be compromised. -- The Issue in MPLS-FTN-MIB -- FTN Mapping Should Be Based on "Logical Tunnel" In MPLS-FTN-MIB, the FEC is currently mapped to a "tunnel instance" instead of "logical tunnel", effectively nailing an FEC to an individual "tunnel instance". This defeats the whole concept of "logical tunnel" or "traffic trunk". ----------------------------------------------------------- (EXCERPT FROM CURRENT MPLS-FTN-MIB) mplsFTNActionPointer OBJECT-TYPE SYNTAX RowPointer DESCRIPTION "If mplsFTNActionType is redirectLsp(2), then this object indicates the instance of mplsXCEntry for the LSP to redirect matching packets to. If mplsFTNActionType is redirectTunnel(3), then this object indicates the instance of mplsTunnelEntry for the MPLS tunnel to redirect matching packets to. ----------------------------------------------------------- As mentioned earlier, a "logical tunnel" is an abstraction of a group of tunnel instances. Taking advantage of this level of indirection, we should have FEC-to-NHLFE mapping established in the logical layer (based on "logical tunnels"). Load sharing, path selection and fail-over schemes should be hidden in the underlying path layer (based on "tunnel instances"). Such schemes should be transparent to FTN mapping. Given that currently "logical tunnel" entity class and "tunnel instance" entity class are intertwined in the same MIB table, there is no way to make FEC map to "logical tunnel". (This might explain why "FTNActionPointer" is made to point to a "tunnel instance" in current MIB definition.) -- Recommendation The issues in MPLS-TE-MIB and MPLS-FTN-MIB are really due to a structural problem of mplsTunnelTable. We can resolve these issues by spliting the big, monolithic "mplsTunnelTable" into two smaller tables, each modeling exactly one entity class. mplsLogicalTunnelTable mplsTunnelInstanceTable Then modify mplsFTNActionPointer definition to make it pointing to a row in the first table. Note that a row in the first table may correspond to multiple rows in the second table. Rupert Zhu System Engineering Santera Systems Inc. 972-461-6383 (TX, USA) > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Friday, November 08, 2002 7:31 PM > To: Zhu, Rupert > Cc: mpls@UU.NET > Subject: Re: MIB Report 3/3: A Structural Issue > > > > Speaking of style problems, please DON'T send doc files to the mailing > list. Microsoft free sites can't read these files. > > Curtis > From owner-mpls@UU.NET Sun Nov 10 14:32:02 2002 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 ESMTP id OAA22215 for ; Sun, 10 Nov 2002 14:32:01 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnokk15996 for ; Sun, 10 Nov 2002 19:34:29 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnokk14067; Sun, 10 Nov 2002 19:33:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnokk02504 for mpls-outgoing; Sun, 10 Nov 2002 19:33:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnokk02499 for ; Sun, 10 Nov 2002 19:32: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 QQnokk26559 for ; Sun, 10 Nov 2002 19:32:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnokk14232 for ; Sun, 10 Nov 2002 19:32:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnokk14217 for ; Sun, 10 Nov 2002 19:32:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12477 for ; Sun, 10 Nov 2002 14:32:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAAJW6l10735 for mpls@uu.net; Sun, 10 Nov 2002 14:32:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnokk02276 for ; Sun, 10 Nov 2002 19:30:29 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 QQnokk19220 for ; Sun, 10 Nov 2002 19:30:11 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnokk13118 for ; Sun, 10 Nov 2002 19:30:11 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnokk13112 for ; Sun, 10 Nov 2002 19:30:10 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAAJUSKi009151; Sun, 10 Nov 2002 14:30:28 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-31.cisco.com [10.86.242.31]) by bucket.cisco.com (Mirapoint) with ESMTP id ACC13863; Sun, 10 Nov 2002 14:30:08 -0500 (EST) Message-Id: <4.3.2.7.2.20021110142647.055752c8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Nov 2002 14:30:04 -0500 To: jcucchiara@mindspring.com From: "Thomas D. Nadeau" Subject: Re: MIB Report 2/3: Coding Anomalies Cc: "Zhu, Rupert" , In-Reply-To: <3.0.1.32.20021110132129.006e4b78@pop.mindspring.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Rupert, Two points inline. >Hello Rupert, > >Thank you for the comments. Please see in-line. > >At 05:47 PM 11/8/02 -0600, Zhu, Rupert wrote: > >------------------------------------------------------------ > >MIB Report 2/3: Coding Style Anomalies > > > > > >I run a "lint" (i.e., coding style checking) over the latest > >version of MPLS MIB drafts and generated a report. > > > > draft-ietf-mpls-bundle-mib-04.fmt > > draft-ietf-mpls-fastreroute-mib-01.fmt > > draft-ietf-mpls-ftn-mib-04.fmt > > draft-ietf-mpls-ldp-mib-09.fmt > > draft-ietf-mpls-lsr-mib-09.fmt > > draft-ietf-mpls-tc-mib-05.fmt > > draft-ietf-mpls-te-mib-09.fmt > > > > > >9 coding style anomalies are detected. (A small number, compared with > >525 object types and 22 TCs in total.) > > > >The anomalies fall in 2 categories. > > > >1. ENUM value list started with zero (0). > > GUIDELINE: All ENUM value list should start from 1 and up. > >This was due to SMIv1 but SMIv2 does allow 0. Admittedly, >many MIB authors were concerned with backwards compatibility >issues and start enums at 1 where it makes sense to do so. > >In the LDP-MIB the reason that these enums start with 0 is because >the actual values sent on the wire for these values would be 0. >I didn't see any reason that there should be "extra" code in there >checking an enum and then re-interrupting the value to zero to >send on the wire. > >Thanks, Joan I concur with Joan. SNMPv2 allows for enumerations to begin with 0, and thus there are no coding conventions being violated. > >2. Define Numeric range with INTEGER. > > GUIDELINE: All numeric range should be defined with > > Integer32 or Unsigned32. I do not see any examples below of the use of INTEGER with a range; they all look like enumerations to me. --Tom > > > >These are not errors, but coding style anomalies. See details below. > > > >-- Rupert > > > > > >#==================================================================== > ># Checking on Objects > > > >MODULE=LINK-BUNDLING-MIB > > > >MODULE=MPLS-FRR-MIB > > > >WARNING: ENUM Starts with Zero (0) > > mplsFrrConstProtectionMethod > > INTEGER { oneToOneBackup (0), facilityBackup (1) } > > > >WARNING: ENUM Starts with Zero (0) > > mplsFrrConstProtectionType > > INTEGER { linkProtection (0), nodeProtection (1) } > > > >WARNING: ENUM Starts with Zero (0) > > mplsFrrDetourMerging > > INTEGER { none (0), protectedTunnel (1), detour(2) } > > > >MODULE=MPLS-FTN-MIB > > > >MODULE=MPLS-LDP-MIB > > > >WARNING: ENUM Starts with Zero (0) > > mplsLdpEntityAtmMergeCap > > INTEGER { notSupported (0), vcMerge (2) } > > > >WARNING: ENUM Starts with Zero (0) > > mplsLdpEntityAtmVcDirectionality > > INTEGER { bidirectional (0), unidirectional (1) } > > > >WARNING: ENUM Starts with Zero (0) > > mplsLdpEntityFrMergeCap > > INTEGER { notSupported (0), supported (1) } > > > >WARNING: ENUM Starts with Zero (0) > > mplsLdpEntityFrLength > > INTEGER { tenDlciBits (0), twentyThreeDlciBits (2) } > > > >WARNING: ENUM Starts with Zero (0) > > mplsLdpEntityFrVcDirectionality > > INTEGER { bidirectional (0), unidirection (1) } > > > >WARNING: ENUM Starts with Zero (0) > > mplsLdpFrSesLength > > INTEGER { tenDlciBits (0), twentyThreeDlciBits (2) } > > > >MODULE=MPLS-LSR-MIB > > > >MODULE=MPLS-TE-MIB > > > >Total Warnings: 9 > > > > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Sun Nov 10 15:45:07 2002 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 ESMTP id PAA23673 for ; Sun, 10 Nov 2002 15:45:06 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnokp25688 for ; Sun, 10 Nov 2002 20:47:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnokp24358; Sun, 10 Nov 2002 20:46:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnokp24947 for mpls-outgoing; Sun, 10 Nov 2002 20:46:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnokp24859 for ; Sun, 10 Nov 2002 20:45:56 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnokp15275 for ; Sun, 10 Nov 2002 20:45:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnokp28317 for ; Sun, 10 Nov 2002 20:45:16 GMT Received: from excalibur.santera.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnokp28309 for ; Sun, 10 Nov 2002 20:45:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MIB Report 2/3: Coding Anomalies Date: Sun, 10 Nov 2002 14:45:15 -0600 Message-ID: Thread-Topic: MIB Report 2/3: Coding Anomalies Thread-Index: AcKI75X2POQqqk0kRm6NV6EthROvFwACdhPg From: "Zhu, Rupert" To: "Thomas D. Nadeau" , Cc: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA23673 Tom, Joan: Thanks for the reply. I agree that there is no "syntax violation", but the issue I raised is "coding style violation". An analogy below. ---------------- In every software programming guideline, we would see instructions like "DO NOT use magic number in code, use symbolic constant instead." Using magic number (e.g., 24, 168) in C/C++/Java program would pass compilation perfectly. But seasoned software managers won't allow it because it is a bad style. ---------------- As explained in my report 1/3, "ENUM starting from 1" is a good coding style in MIB design. Most existing IETF MIBs stick with this practice pretty well. However, I do think Joan made a good case in retaining the same coding across protocol message and SNMP message. In engineering world, every rule has an exception. :-) Regarding your point #2, you are right. My first run of "lint" was over a set of earlier MPLS MIB drafts. It generated 16 warnings on coding style violation. Before posting, I noticed the new release of MIB drafts and did a second run. The total number of warnings dropped to 9 and the anomalies of second case disappeared. Apparently, MIB drafts are getting better. BTW, I am reading the latest version of MPLS-TE-MIB. I will provide my comments soon. Regards, -- Rupert > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Sunday, November 10, 2002 1:30 PM > To: jcucchiara@mindspring.com > Cc: Zhu, Rupert; mpls@UU.NET > Subject: Re: MIB Report 2/3: Coding Anomalies > > > > Rupert, > > Two points inline. > > >Hello Rupert, > > > >Thank you for the comments. Please see in-line. > > > >At 05:47 PM 11/8/02 -0600, Zhu, Rupert wrote: > > >------------------------------------------------------------ > > >MIB Report 2/3: Coding Style Anomalies > > > > > > > > >I run a "lint" (i.e., coding style checking) over the latest > > >version of MPLS MIB drafts and generated a report. > > > > > > draft-ietf-mpls-bundle-mib-04.fmt > > > draft-ietf-mpls-fastreroute-mib-01.fmt > > > draft-ietf-mpls-ftn-mib-04.fmt > > > draft-ietf-mpls-ldp-mib-09.fmt > > > draft-ietf-mpls-lsr-mib-09.fmt > > > draft-ietf-mpls-tc-mib-05.fmt > > > draft-ietf-mpls-te-mib-09.fmt > > > > > > > > >9 coding style anomalies are detected. (A small number, > compared with > > >525 object types and 22 TCs in total.) > > > > > >The anomalies fall in 2 categories. > > > > > >1. ENUM value list started with zero (0). > > > GUIDELINE: All ENUM value list should start from 1 and up. > > > >This was due to SMIv1 but SMIv2 does allow 0. Admittedly, > >many MIB authors were concerned with backwards compatibility > >issues and start enums at 1 where it makes sense to do so. > > > >In the LDP-MIB the reason that these enums start with 0 is because > >the actual values sent on the wire for these values would be 0. > >I didn't see any reason that there should be "extra" code in there > >checking an enum and then re-interrupting the value to zero to > >send on the wire. > > > >Thanks, Joan > > I concur with Joan. SNMPv2 allows for enumerations > to begin with 0, and thus there are no coding conventions > being violated. > > > >2. Define Numeric range with INTEGER. > > > GUIDELINE: All numeric range should be defined with > > > Integer32 or Unsigned32. > > I do not see any examples below of the use of > INTEGER with a range; they all look like enumerations > to me. > > --Tom > > > > > > > >These are not errors, but coding style anomalies. See > details below. > > > > > >-- Rupert > > > > > > > > > >#==================================================================== > > ># Checking on Objects > > > > > >MODULE=LINK-BUNDLING-MIB > > > > > >MODULE=MPLS-FRR-MIB > > > > > >WARNING: ENUM Starts with Zero (0) > > > mplsFrrConstProtectionMethod > > > INTEGER { oneToOneBackup (0), facilityBackup (1) } > > > > > >WARNING: ENUM Starts with Zero (0) > > > mplsFrrConstProtectionType > > > INTEGER { linkProtection (0), nodeProtection (1) } > > > > > >WARNING: ENUM Starts with Zero (0) > > > mplsFrrDetourMerging > > > INTEGER { none (0), protectedTunnel (1), detour(2) } > > > > > >MODULE=MPLS-FTN-MIB > > > > > >MODULE=MPLS-LDP-MIB > > > > > >WARNING: ENUM Starts with Zero (0) > > > mplsLdpEntityAtmMergeCap > > > INTEGER { notSupported (0), vcMerge (2) } > > > > > >WARNING: ENUM Starts with Zero (0) > > > mplsLdpEntityAtmVcDirectionality > > > INTEGER { bidirectional (0), unidirectional (1) } > > > > > >WARNING: ENUM Starts with Zero (0) > > > mplsLdpEntityFrMergeCap > > > INTEGER { notSupported (0), supported (1) } > > > > > >WARNING: ENUM Starts with Zero (0) > > > mplsLdpEntityFrLength > > > INTEGER { tenDlciBits (0), twentyThreeDlciBits (2) } > > > > > >WARNING: ENUM Starts with Zero (0) > > > mplsLdpEntityFrVcDirectionality > > > INTEGER { bidirectional (0), unidirection (1) } > > > > > >WARNING: ENUM Starts with Zero (0) > > > mplsLdpFrSesLength > > > INTEGER { tenDlciBits (0), twentyThreeDlciBits (2) } > > > > > >MODULE=MPLS-LSR-MIB > > > > > >MODULE=MPLS-TE-MIB > > > > > >Total Warnings: 9 > > > > > > > > Success is relative; the more success, the more relatives. -Anonymous > > > From owner-mpls@UU.NET Mon Nov 11 13:33:50 2002 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 ESMTP id NAA26957 for ; Mon, 11 Nov 2002 13:33:50 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnony19388 for ; Mon, 11 Nov 2002 18:36:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnony13296; Mon, 11 Nov 2002 18:33:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnony11592 for mpls-outgoing; Mon, 11 Nov 2002 18:33:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnony11587 for ; Mon, 11 Nov 2002 18:33:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnony10875 for ; Mon, 11 Nov 2002 18:32:03 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnony03996 for ; Mon, 11 Nov 2002 18:32:03 GMT Received: from excalibur.santera.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnony03988 for ; Mon, 11 Nov 2002 18:32:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: MPLS-TE-MIB Report 1/3: Ambiguities Date: Mon, 11 Nov 2002 12:31:58 -0600 Message-ID: Thread-Topic: MPLS-TE-MIB Report 1/3: Ambiguities Thread-Index: AcKJsJ3Or9hFpsTMTeqglhK21voZ/g== From: "Zhu, Rupert" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26957 Tom and MIB Authors: I joined the MPLS mailing list only 5 months ago, so I missed the opportunity to provide my input at early stage of MPLS-TE-MIB. Given this, I can only make "best effort" contribution to the group. In this and next two Emails, I would submit my comments on MIB details. As we all would agree, a well-designed MIB should demonstrate Consistency, Accuracy and Clarity. Often, the easiest approach for clarity is "speak by structure". Instead of wordy descriptions for every table field, let the structure speak for itself. If the authors choose to mix "Tunnel" and "Tunnel Instance" in a single MIB table, then it becomes a burden on the authors to ensure Accuracy. Use clear, unambiguous terminology to indicate which fields are Tunnel's property and which fields are Tunnel Instance's property. A (logical) tunnel consists of a group of tunnel instances. When having these two entity classes in the same table, each row represents a unique tunnel instance while a set of rows, collectively, represent the (logical) tunnel. This distinction is very important. If a field is a property of tunnel, its value has to be copied across all rows that constitute the tunnel. These duplications are undesirable, not only because it's a waste of storage but also because it poses a burden on maintaining data integrity. (When adding or modifying a row, software must remember to propagate the changes to ALL other rows belonging to the same tunnel. Otherwise, system integrity would be lost.) On the other hand, if a field is a property of tunnel instance, then each row is allowed to have its own value for this field. A change on one row does not need to propagate to other rows. Looking at the most recent draft (draft-ietf-mpls-te-mib-09.txt), I found that the ambiguities still remain. Among the 37 fields in mplsTunnelTable, only 5 fields clearly indicated tunnel instance-specific nature. Most of other fields simply mentions "tunnel", leaving readers to guess in the dark. CASE 1: Explicit Indication of Tunnel Instance Property (5 fields) INSTANCE: mplsTunnelInstance INSTANCE: mplsTunnelInstancePriority INSTANCE: mplsTunnelStateTransitions INSTANCE: mplsTunnelRole INSTANCE: mplsTunnelInstanceUpTime CASE 2: No Indication of Tunnel-vs-Tunnel Instance (5 fields) NONE: mplsTunnelIndexIndex NONE: mplsTunnelEgressLSRId NONE: mplsTunnelIncludeAnyAffinity NONE: mplsTunnelIncludeAllAffinity NONE: mplsTunnelExcludeAllAffinity CASE 3: Explicit Indication of Tunnel Property (26 fields) TUNNEL: mplsTunnelIngressLSRId TUNNEL: mplsTunnelName TUNNEL: mplsTunnelDescr TUNNEL: mplsTunnelIsIf TUNNEL: mplsTunnelIfIndex TUNNEL: mplsTunnelXCPointer TUNNEL: mplsTunnelSignallingProto TUNNEL: mplsTunnelSetupPrio TUNNEL: mplsTunnelHoldingPrio TUNNEL: mplsTunnelSessionAttributes TUNNEL: mplsTunnelOwner TUNNEL: mplsTunnelLocalProtectInUse TUNNEL: mplsTunnelResourcePointer TUNNEL: mplsTunnelHopTableIndex TUNNEL: mplsTunnelARHopTableIndex TUNNEL: mplsTunnelCHopTableIndex TUNNEL: mplsTunnelPathChanges TUNNEL: mplsTunnelLastPathChange TUNNEL: mplsTunnelPathInUse TUNNEL: mplsTunnelAdminStatus TUNNEL: mplsTunnelOperStatus TUNNEL: mplsTunnelStorageType TUNNEL: mplsTunnelPrimaryInstance TUNNEL: mplsTunnelPrimaryTimeUp TUNNEL: mplsTunnelCreationTime TUNNEL: mplsTunnelTotalUpTime What bothers me is the 26 fields in Case 3. Are All of These Fields Properties of Tunnel? If the answer is Yes, then we have a huge data duplication issue because the value of these 26 fields must be copied across all rows belonging to the same (logical) tunnel. I think some of these fields actually are properties of tunnel instance. For example, "mplsTunnelSignallingProto" should be a property of tunnel instance instead of tunnel. For a given (logical) tunnel, some of its tunnel instances may be established by RSVP-TE, some by CR-LDP, yet some others by management commands (e.g., SNMP). The rows belonging to the same tunnel do not have to share the same value. Although domain experts may be able to guess the nature of these fields, a more accurate and unambiguous description is preferred. Better yet, if we had chosen a modular MIB structure, these ambiguities wouldn't come into the scene at all. A Structure Is Worth A Thousand Words. :-) -- Rupert Rupert Zhu System Engineering Santera Systems Inc 3605 E. Plano Parkway Plano, TX 75074 Phone: 972-461-6383 From owner-mpls@UU.NET Mon Nov 11 13:55:20 2002 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 ESMTP id NAA27690 for ; Mon, 11 Nov 2002 13:55:19 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnonz22193 for ; Mon, 11 Nov 2002 18:57:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnonz20703; Mon, 11 Nov 2002 18:56:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnonz13802 for mpls-outgoing; Mon, 11 Nov 2002 18:56:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnonz13777 for ; Mon, 11 Nov 2002 18:56: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 QQnonz00239 for ; Mon, 11 Nov 2002 18:55:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnonz19163 for ; Mon, 11 Nov 2002 18:55:14 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnonz19150 for ; Mon, 11 Nov 2002 18:55:13 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA10039 for ; Mon, 11 Nov 2002 13:55:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gABItDP18137 for mpls@uu.net; Mon, 11 Nov 2002 13:55:13 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnonz13675 for ; Mon, 11 Nov 2002 18:54:23 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 QQnonz18459 for ; Mon, 11 Nov 2002 18:53:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnonz17335 for ; Mon, 11 Nov 2002 18:53:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnonz17324 for ; Mon, 11 Nov 2002 18:53:06 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gABIrOas009855; Mon, 11 Nov 2002 13:53:24 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-31.cisco.com [10.86.242.31]) by bucket.cisco.com (Mirapoint) with ESMTP id ACC23939; Mon, 11 Nov 2002 13:53:03 -0500 (EST) Message-Id: <4.3.2.7.2.20021111133805.05880ea0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Nov 2002 13:52:58 -0500 To: "Zhu, Rupert" From: "Thomas D. Nadeau" Subject: Re: MPLS-TE-MIB Report 1/3: Ambiguities Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, Thanks for your additional comments. >Tom and MIB Authors: > >I joined the MPLS mailing list only 5 months ago, so I missed the >opportunity to provide my input at early stage of MPLS-TE-MIB. >Given this, I can only make "best effort" contribution to the group. >In this and next two Emails, I would submit my comments on MIB details. > >As we all would agree, a well-designed MIB should demonstrate >Consistency, Accuracy and Clarity. Often, the easiest approach >for clarity is "speak by structure". Instead of wordy descriptions >for every table field, let the structure speak for itself. I think that we would also agree that a MIB designed purely for "Consistency, Accuracy and Clarity" sounds good in theory, but sometimes in practice the MIB that is best might not be the best given these three things. Just take a look around at other MIBs that are available. I will assert that although not pretty, they work pretty well in practice. >If the authors choose to mix "Tunnel" and "Tunnel Instance" in a single >MIB table, then it becomes a burden on the authors to ensure Accuracy. >Use clear, unambiguous terminology to indicate which fields are >Tunnel's property and which fields are Tunnel Instance's property. Agreed. If you see descriptions that need improvement, please by all means provide text to correct the situation. >A (logical) tunnel consists of a group of tunnel instances. Only if tunnel instances are signaled successfully given the parameters configured on the tunnel and the state of the network. >When having these two entity classes in the same table, each row >represents a unique tunnel instance while a set of rows, collectively, >represent the (logical) tunnel. This distinction is very important. Correct. >If a field is a property of tunnel, its value has to be copied >across all rows that constitute the tunnel. That makes perfect sense given the fact that many configuration options are copied to the LSP in order to signal it. >These duplications >are undesirable, not only because it's a waste of storage but also >because it poses a burden on maintaining data integrity. There is no redundant storage in a real implementation. Real implementations copy the configured parameters to the active ones in the signaling protocol. This is just how things work. There are however, some cases where the configured parameters may not be reflected in the signaled/active instance of the tunnel. Take the tunnel hops for instance. The configured hop list might vary in several ways on the active tunnel. Leaving the same objects to access on both makes things easier for both the agent and the manager, IMHO. >(When adding or modifying a row, software must remember >to propagate the changes to ALL other rows belonging to >the same tunnel. Otherwise, system integrity would be lost.) It depends on what you mean by "the software". If you mean the agent software, then yes, the agent must keep things consistent. This is not out of the realm of reality. Just look at how the CLI on most boxes is used to configure tunnels. The same model applies there. Furthermore, since the parameters being modified are in general, all within the same software subsystem (i.e.: RSVP-TE), this is not such a burden as an advantage. >On the other hand, if a field is a property of tunnel instance, >then each row is allowed to have its own value for this field. >A change on one row does not need to propagate to other rows. A change in one row must result in a change in the other rows if the instance is part of the main tunnel table or not. If I configure a tunnel head (mplsTunnelTable instance .0), and then signal an LSP for that tunnel, some of the signaled LSP's state information (i.e.: total tunnel uptime ) needs to be "copied" to the head instance as well. Another example would be the hop table configuration in the head for the signaled LSP. In this case the signaled LSP needs to reflect the hop table as the list of hops it was passed. There are BTW, ways to re-use the same entries in the HOP and resource tables between tunnels and their instances. This is spelled out in the descriptions. >Looking at the most recent draft (draft-ietf-mpls-te-mib-09.txt), >I found that the ambiguities still remain. Among the 37 fields >in mplsTunnelTable, only 5 fields clearly indicated >tunnel instance-specific nature. Most of other fields simply >mentions "tunnel", leaving readers to guess in the dark. So please suggest some text to add to the draft. --Tom >CASE 1: Explicit Indication of Tunnel Instance Property (5 fields) > > INSTANCE: mplsTunnelInstance > INSTANCE: mplsTunnelInstancePriority > INSTANCE: mplsTunnelStateTransitions > INSTANCE: mplsTunnelRole > INSTANCE: mplsTunnelInstanceUpTime > > >CASE 2: No Indication of Tunnel-vs-Tunnel Instance (5 fields) > > NONE: mplsTunnelIndexIndex > NONE: mplsTunnelEgressLSRId > NONE: mplsTunnelIncludeAnyAffinity > NONE: mplsTunnelIncludeAllAffinity > NONE: mplsTunnelExcludeAllAffinity > > >CASE 3: Explicit Indication of Tunnel Property (26 fields) > > TUNNEL: mplsTunnelIngressLSRId > TUNNEL: mplsTunnelName > TUNNEL: mplsTunnelDescr > TUNNEL: mplsTunnelIsIf > TUNNEL: mplsTunnelIfIndex > TUNNEL: mplsTunnelXCPointer > TUNNEL: mplsTunnelSignallingProto > TUNNEL: mplsTunnelSetupPrio > TUNNEL: mplsTunnelHoldingPrio > TUNNEL: mplsTunnelSessionAttributes > TUNNEL: mplsTunnelOwner > TUNNEL: mplsTunnelLocalProtectInUse > TUNNEL: mplsTunnelResourcePointer > TUNNEL: mplsTunnelHopTableIndex > TUNNEL: mplsTunnelARHopTableIndex > TUNNEL: mplsTunnelCHopTableIndex > TUNNEL: mplsTunnelPathChanges > TUNNEL: mplsTunnelLastPathChange > TUNNEL: mplsTunnelPathInUse > TUNNEL: mplsTunnelAdminStatus > TUNNEL: mplsTunnelOperStatus > TUNNEL: mplsTunnelStorageType > TUNNEL: mplsTunnelPrimaryInstance > TUNNEL: mplsTunnelPrimaryTimeUp > TUNNEL: mplsTunnelCreationTime > TUNNEL: mplsTunnelTotalUpTime > > >What bothers me is the 26 fields in Case 3. > >Are All of These Fields Properties of Tunnel? > > If the answer is Yes, then we have a huge data duplication issue > because the value of these 26 fields must be copied across all rows > belonging to the same (logical) tunnel. > >I think some of these fields actually are properties of tunnel instance. >For example, "mplsTunnelSignallingProto" should be a property of tunnel >instance instead of tunnel. For a given (logical) tunnel, some of its >tunnel instances may be established by RSVP-TE, some by CR-LDP, yet some >others by management commands (e.g., SNMP). The rows belonging to >the same tunnel do not have to share the same value. > >Although domain experts may be able to guess the nature of these >fields, a more accurate and unambiguous description is preferred. > >Better yet, if we had chosen a modular MIB structure, >these ambiguities wouldn't come into the scene at all. > >A Structure Is Worth A Thousand Words. :-) > > >-- Rupert > > >Rupert Zhu >System Engineering >Santera Systems Inc >3605 E. Plano Parkway >Plano, TX 75074 >Phone: 972-461-6383 Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Mon Nov 11 14:11:58 2002 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 ESMTP id OAA28261 for ; Mon, 11 Nov 2002 14:11:58 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnonz18234 for ; Mon, 11 Nov 2002 18:47:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnony12126; Mon, 11 Nov 2002 18:44:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnony12431 for mpls-outgoing; Mon, 11 Nov 2002 18:44:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnony12407 for ; Mon, 11 Nov 2002 18:44: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 QQnony15835 for ; Mon, 11 Nov 2002 18:43:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnony09812 for ; Mon, 11 Nov 2002 18:43:33 GMT Received: from mailserv.hatteras.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailserv.hatterasnetworks.com [63.89.58.4]) id QQnony09805 for ; Mon, 11 Nov 2002 18:43:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: MPLS-TE-MIB Report 1/3: Ambiguities MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 11 Nov 2002 13:43:32 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA3997140B477C@mailserv.hatteras.com> Thread-Topic: MPLS-TE-MIB Report 1/3: Ambiguities Thread-Index: AcKJsJ3Or9hFpsTMTeqglhK21voZ/gAAQ8Ug From: "Brian Hassink" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA28261 Don't know that it counts for anything, but I just wanted to add my support for Rupert's comments regarding the existing mplsTunnelTable. In implementing support for this table I have found it poorly structured with its merging of "tunnel" and "tunnel instance" attributes. Cheers, Brian --- bhassink@hatterasnetworks.com -----Original Message----- From: Zhu, Rupert [mailto:rupert.zhu@santera.com] Sent: Monday, November 11, 2002 1:32 PM To: mpls@UU.NET Subject: MPLS-TE-MIB Report 1/3: Ambiguities Tom and MIB Authors: I joined the MPLS mailing list only 5 months ago, so I missed the opportunity to provide my input at early stage of MPLS-TE-MIB. Given this, I can only make "best effort" contribution to the group. In this and next two Emails, I would submit my comments on MIB details. As we all would agree, a well-designed MIB should demonstrate Consistency, Accuracy and Clarity. Often, the easiest approach for clarity is "speak by structure". Instead of wordy descriptions for every table field, let the structure speak for itself. If the authors choose to mix "Tunnel" and "Tunnel Instance" in a single MIB table, then it becomes a burden on the authors to ensure Accuracy. Use clear, unambiguous terminology to indicate which fields are Tunnel's property and which fields are Tunnel Instance's property. A (logical) tunnel consists of a group of tunnel instances. When having these two entity classes in the same table, each row represents a unique tunnel instance while a set of rows, collectively, represent the (logical) tunnel. This distinction is very important. If a field is a property of tunnel, its value has to be copied across all rows that constitute the tunnel. These duplications are undesirable, not only because it's a waste of storage but also because it poses a burden on maintaining data integrity. (When adding or modifying a row, software must remember to propagate the changes to ALL other rows belonging to the same tunnel. Otherwise, system integrity would be lost.) On the other hand, if a field is a property of tunnel instance, then each row is allowed to have its own value for this field. A change on one row does not need to propagate to other rows. Looking at the most recent draft (draft-ietf-mpls-te-mib-09.txt), I found that the ambiguities still remain. Among the 37 fields in mplsTunnelTable, only 5 fields clearly indicated tunnel instance-specific nature. Most of other fields simply mentions "tunnel", leaving readers to guess in the dark. CASE 1: Explicit Indication of Tunnel Instance Property (5 fields) INSTANCE: mplsTunnelInstance INSTANCE: mplsTunnelInstancePriority INSTANCE: mplsTunnelStateTransitions INSTANCE: mplsTunnelRole INSTANCE: mplsTunnelInstanceUpTime CASE 2: No Indication of Tunnel-vs-Tunnel Instance (5 fields) NONE: mplsTunnelIndexIndex NONE: mplsTunnelEgressLSRId NONE: mplsTunnelIncludeAnyAffinity NONE: mplsTunnelIncludeAllAffinity NONE: mplsTunnelExcludeAllAffinity CASE 3: Explicit Indication of Tunnel Property (26 fields) TUNNEL: mplsTunnelIngressLSRId TUNNEL: mplsTunnelName TUNNEL: mplsTunnelDescr TUNNEL: mplsTunnelIsIf TUNNEL: mplsTunnelIfIndex TUNNEL: mplsTunnelXCPointer TUNNEL: mplsTunnelSignallingProto TUNNEL: mplsTunnelSetupPrio TUNNEL: mplsTunnelHoldingPrio TUNNEL: mplsTunnelSessionAttributes TUNNEL: mplsTunnelOwner TUNNEL: mplsTunnelLocalProtectInUse TUNNEL: mplsTunnelResourcePointer TUNNEL: mplsTunnelHopTableIndex TUNNEL: mplsTunnelARHopTableIndex TUNNEL: mplsTunnelCHopTableIndex TUNNEL: mplsTunnelPathChanges TUNNEL: mplsTunnelLastPathChange TUNNEL: mplsTunnelPathInUse TUNNEL: mplsTunnelAdminStatus TUNNEL: mplsTunnelOperStatus TUNNEL: mplsTunnelStorageType TUNNEL: mplsTunnelPrimaryInstance TUNNEL: mplsTunnelPrimaryTimeUp TUNNEL: mplsTunnelCreationTime TUNNEL: mplsTunnelTotalUpTime What bothers me is the 26 fields in Case 3. Are All of These Fields Properties of Tunnel? If the answer is Yes, then we have a huge data duplication issue because the value of these 26 fields must be copied across all rows belonging to the same (logical) tunnel. I think some of these fields actually are properties of tunnel instance. For example, "mplsTunnelSignallingProto" should be a property of tunnel instance instead of tunnel. For a given (logical) tunnel, some of its tunnel instances may be established by RSVP-TE, some by CR-LDP, yet some others by management commands (e.g., SNMP). The rows belonging to the same tunnel do not have to share the same value. Although domain experts may be able to guess the nature of these fields, a more accurate and unambiguous description is preferred. Better yet, if we had chosen a modular MIB structure, these ambiguities wouldn't come into the scene at all. A Structure Is Worth A Thousand Words. :-) -- Rupert Rupert Zhu System Engineering Santera Systems Inc 3605 E. Plano Parkway Plano, TX 75074 Phone: 972-461-6383 From owner-mpls@UU.NET Mon Nov 11 14:18:24 2002 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 ESMTP id OAA28385 for ; Mon, 11 Nov 2002 14:18:24 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoob14335 for ; Mon, 11 Nov 2002 19:20:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnoob12152; Mon, 11 Nov 2002 19:19:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnoob02859 for mpls-outgoing; Mon, 11 Nov 2002 19:19:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnoob02854 for ; Mon, 11 Nov 2002 19:19:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnoob26533 for ; Mon, 11 Nov 2002 19:19:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoob14912 for ; Mon, 11 Nov 2002 19:19:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnoob14906 for ; Mon, 11 Nov 2002 19:19:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12054 for ; Mon, 11 Nov 2002 14:19:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gABJJ7j20695 for mpls@uu.net; Mon, 11 Nov 2002 14:19:07 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnoob02820 for ; Mon, 11 Nov 2002 19:17:57 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 QQnoob11266 for ; Mon, 11 Nov 2002 19:17:32 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoob13400 for ; Mon, 11 Nov 2002 19:17:32 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnoob13391 for ; Mon, 11 Nov 2002 19:17:31 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11941 for ; Mon, 11 Nov 2002 14:17:31 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA27344 for ; Mon, 11 Nov 2002 14:17:31 -0500 (EST) Message-Id: <200211111917.OAA27344@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Draft MPLS Agenda Date: Mon, 11 Nov 2002 14:17:31 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk MPLS WG Agenda Atlanta 55th IETF TUESDAY, November 19, 2002 0900-1130 Salon B Agenda bashing 5 min Loa Andersson LDP to draft standard (status) 5 min Joan Cucchiara & Tom Nadeau MPLS MIB review meeting (report) 10 min Alia Atlas Fast Reroute Extensions to RSVP-TE for LSP Tunnels 10 min Stefan DeCnodder Backup Record Route for Fast Reroute Techniques in RSVP-TE 10 min Eric Rosen Encapsulating MPLS in IP or GRE 10 min Dave Allan A Framework for MPLS User Plane OAM 10 min Tom Nadeau IP-based Tool Requirements for MPLS Networks 10 min Kireeti Kompella Detecting MPLS Data Plane Liveness 10 min OAM Discussion 10 min Dave Allan Guidelines for MPLS Load Balancing 10 min Rohit Dube Bi-directional LSPs for classical MPLS 10 min Michel Behringer Analysis of the Security of the MPLS Architecture 10 min Allan Kullberg Extended RSVP-TE for Multicast LSP Tunnels 10 min Loa / George MPLS wg status 20 min ====================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Nov 11 16:17:46 2002 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 ESMTP id QAA01951 for ; Mon, 11 Nov 2002 16:17:45 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnooj08688 for ; Mon, 11 Nov 2002 21:20:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnooj06838; Mon, 11 Nov 2002 21:19:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnooj02331 for mpls-outgoing; Mon, 11 Nov 2002 21:19:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnooj02326 for ; Mon, 11 Nov 2002 21:19:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnooj10890 for ; Mon, 11 Nov 2002 21:18:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnooj05671 for ; Mon, 11 Nov 2002 21:18:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnooj05651 for ; Mon, 11 Nov 2002 21:18:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA22482 for ; Mon, 11 Nov 2002 16:18:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gABLI5b28904 for mpls@uu.net; Mon, 11 Nov 2002 16:18:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnooj02276 for ; Mon, 11 Nov 2002 21:17:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnooj26151 for ; Mon, 11 Nov 2002 21:17:19 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 QQnooi15620 for ; Mon, 11 Nov 2002 21:11:13 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01754; Mon, 11 Nov 2002 16:08:38 -0500 (EST) Message-Id: <200211112108.QAA01754@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Document Action: Framework for MPLS-based Recovery to Informational Date: Mon, 11 Nov 2002 16:08:38 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'Framework for MPLS-based Recovery' as an Informational RFC. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Scott Bradner and Bert Wijnen. From owner-mpls@UU.NET Mon Nov 11 17:26:05 2002 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 ESMTP id RAA04515 for ; Mon, 11 Nov 2002 17:26:04 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoon09141 for ; Mon, 11 Nov 2002 22:28:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnoon07705; Mon, 11 Nov 2002 22:27:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnoon09624 for mpls-outgoing; Mon, 11 Nov 2002 22:27:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnoon09615 for ; Mon, 11 Nov 2002 22:27:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnoon10822 for ; Mon, 11 Nov 2002 22:26:55 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoon29104 for ; Mon, 11 Nov 2002 22:26:54 GMT Received: from excalibur.santera.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnoon29100 for ; Mon, 11 Nov 2002 22:26:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: MPLS-TE-MIB Report 2/3: General Questions and Comments Date: Mon, 11 Nov 2002 16:26:53 -0600 Message-ID: Thread-Topic: MPLS-TE-MIB Report 2/3: General Questions and Comments Thread-Index: AcKJ0W8mykAWwaOhSYqV7cn2SZTvOw== From: "Zhu, Rupert" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA04515 ------------------------------------------------------ MPLS-TE-MIB Report 2/3: General Questions and Comments This Email contains some general questions. Next Email contains specific questions and comments. TOPIC 1: Regarding "mplsTunnelRole". A tunnel instance may take one of three possible roles: Head, Transit, Tail. Among the 37 fields in mplsTunnelTable, some are not applicable to every role. For example, the fields mplsTunnelIsIf mplsTunnelIfIndex are not applicable at Transit nodes. In analogy to ATM SPVC, I guess Head node should have the largest set of applicable fields. Transit node is likely to have the smallest set of applicable fields. Q1: In mplsTunnelTable, exactly which table fields are applicable to which roles? Could the authors make it clear? Q2: For an LSP established through signaling, how can a transit node find out the mplsTunnelIndex? The value of this field is always required because it is part of INDEX of the table. Q3: When the tunnel instances of a (logical) tunnel are diversely routed through signaling, how can a transit node get the info of other tunnel instances that belong to the same tunnel? It seems that the transit node can only record one tunnel instance if it is established through signaling. TOPIC 2: In Relation to MPLS-FTN-MIB Excerpt from MPLS-FTN-MIB (v05) ----------------------------------------------------------- mplsFTNActionPointer OBJECT-TYPE SYNTAX RowPointer DESCRIPTION ........ If mplsFTNActionType is redirectTunnel(3), then this object indicates the instance of mplsTunnelEntry for the MPLS TE tunnel to redirect matching packets to. ----------------------------------------------------------- Q1: Consider a scenario that a (logical) tunnel is composed of 5 diversely routed tunnel instances (LSPs) that run in a load-sharing manner. Which tunnel instance should be selected for this FTN mapping? What's the criteria? Q2: In the same scenario, if administrator delete one of the tunnel instances and that happens to be the one FTN mapped to, what would happen? Orphan pointer? Any succession rules? In my opinion, the MIB definition quoted above is a kludge that twisted the logical relationship and added undesirable complexities. (E.g., Q1 and Q2 above.) The correct design should have FTN mapped to the (logical) tunnel, instead of a member tunnel instance. This way, the member tunnel instances may be added, removed or modified freely, without affecting the FTN mapping. And we wouldn't need to worry about selection criteria, deletion procedure and succession rules. Regards, Rupert Zhu System Engineering Santera Systems Inc 3605 E. Plano Parkway Plano, TX 75074 Phone: 972-461-6383 From owner-mpls@UU.NET Mon Nov 11 20:09:18 2002 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 ESMTP id UAA07496 for ; Mon, 11 Nov 2002 20:09:18 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnooy07871 for ; Tue, 12 Nov 2002 01:11:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnooy06541; Tue, 12 Nov 2002 01:11:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnooy13631 for mpls-outgoing; Tue, 12 Nov 2002 01:10:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnooy13543 for ; Tue, 12 Nov 2002 01:10: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 QQnooy15114 for ; Tue, 12 Nov 2002 01:10:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnooy28884 for ; Tue, 12 Nov 2002 01:10:13 GMT Received: from excalibur.santera.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnooy28876 for ; Tue, 12 Nov 2002 01:10:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: MPLS-TE-MIB Report 3/3: Specific Questions and Comments Date: Mon, 11 Nov 2002 19:10:09 -0600 Message-ID: Thread-Topic: MPLS-TE-MIB Report 3/3: Specific Questions and Comments Thread-Index: AcKJ6D2cDDICRF6BQTKwanaL7Nc2iw== From: "Zhu, Rupert" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA07496 ------------------------------------------------------- MPLS-TE-MIB Report 3/3: Specific Questions and Comments Below is a list of questions and comments on mplsTunnelTable. Some of the questions may simply reflect my own confusions. The quoted MIB text is indented. My question/comment is inserted right after each segment of quoted text. ---------------------------------------------------- OBJECT: mplsTunnelEntry DESCRIPTION: "An entry in this table represents an MPLS tunnel. COMMENT: Incorrect. An entry only represents a tunnel instance. A set of entries (rows), collectively, represent a tunnel. ---------------------------------------------------- OBJECT: mplsTunnelIndexIndex DESCRIPTION: "Uniquely identifies this row." COMMENT: Incorrect. This field alone identifies a tunnel that corresponds to a set of rows. You need all fields in INDEX clause together to identify a row. COMMENT: The naming "....IndexIndex" looks a bit odd. ---------------------------------------------------- OBJECT: mplsTunnelInstance DESCRIPTION: "Uniquely identifies an instance of a tunnel. ...... COMMENT: Good by itself, but in contradiction with next two fields. ---------------------------------------------------- OBJECT: mplsTunnelIngressLSRId DESCRIPTION: "The purpose of this object is to uniquely identity a tunnel within a network. ...... COMMENT: Confusing. This field alone neither uniquely identify a tunnel nor a tunnel instance. ---------------------------------------------------- OBJECT: mplsTunnelEgressLSRId DESCRIPTION: "Specifies the egress LSR ID." QUESTION: Is this in relation to tunnel or tunnel instance? ---------------------------------------------------- OBJECT: mplsTunnelSignallingProto DESCRIPTION: "The signalling protocol, if any, which was used to setup this tunnel." COMMENT: Please substitute "tunnel" with "tunnel instance". (There are quite a few similar ambiguities in this table. Please do the same substitution.) COMMENT: The ENUM range of this field is a subset of ENUM range of mplsTunnelOwner field. Therefore this field becomes redundant and unnecessary because it may be derived from another field. ---------------------------------------------------- OBJECT: mplsTunnelResourcePointer DESCRIPTION: ............ By having the same value of this object, two or more segments can indicate resource sharing." COMMENT: This resource-sharing semantics is very unusual and may cause confusions. SCENARIO 1: Same Tunnel If two tunnel instances on two different interfaces (of the same node) point to the same resource, how to enforce resource sharing? SCENARIO 2: Different Tunnels If two tunnel instances of different tunnels point to the same resource, how can they share resource? ---------------------------------------------------- INDEX { mplsTunnelIndexIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId } COMMENT: I have a hard time to understand why the INDEX clause consists of 4 fields. By definition, INDEX of a MIB table should be a minimal subset of fields that uniquely identify a row. Now we have a) mplsTunnelIndex uniquely identifies a tunnel; b) mplsTunnelIndex and mplsTunnelInstance together uniquely identify a tunnel instance (i.e., a row). So these two fields are sufficient to uniquely identify a row. Why bother to add two extra fields in the INDEX clause? QUESTION: What's the relationship between the 4 INDEX fields? Can there be two rows that have identical value in the first two fields but different values in the last two fields? QUESTION: Since only point-to-point tunnels are supported, all tunnel instances of a tunnel should have the same head LSR and tail LSRs, therefore, same IngressLSRId and EgressLSRId. I may have missed something here. It would be helpful to readers if a clarification on INDEX clause could be added. ---------------------------------------------------- General Suggestions: 1. Please make it crystal clear that a (logical) tunnel is represented by a set of rows rather than a single row. 2. Please use accurate terminology to distinguish (logical) tunnel from tunnel instance in the DESCRIPTION clause of every object. For example, replace "tunnel" with "tunnel instance" when appropriate. Thanks for your attention. Rupert Zhu System Engineering Santera Systems Inc 3605 E. Plano Parkway Plano, TX 75074 Phone: 972-461-6383 From owner-mpls@UU.NET Tue Nov 12 10:18:19 2002 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 ESMTP id KAA02372 for ; Tue, 12 Nov 2002 10:18:18 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnord09261 for ; Tue, 12 Nov 2002 15:20:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnord07147; Tue, 12 Nov 2002 15:19:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnord28137 for mpls-outgoing; Tue, 12 Nov 2002 15:19:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnord28132 for ; Tue, 12 Nov 2002 15:19:08 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 QQnord24596 for ; Tue, 12 Nov 2002 15:18:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnord06033 for ; Tue, 12 Nov 2002 15:18:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnord06025 for ; Tue, 12 Nov 2002 15:18:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA17178 for ; Tue, 12 Nov 2002 10:18:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gACFI5w20115 for mpls@uu.net; Tue, 12 Nov 2002 10:18:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnord28081 for ; Tue, 12 Nov 2002 15:17:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnorc16927 for ; Tue, 12 Nov 2002 15:14:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnorc03645 for ; Tue, 12 Nov 2002 15:14:17 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnorc03640 for ; Tue, 12 Nov 2002 15:14:17 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gACFEVfT012602; Tue, 12 Nov 2002 10:14:32 -0500 (EST) Received: from tnadeau-w2k.cisco.com (dhcp-161-44-145-21.cisco.com [161.44.145.21]) by bucket.cisco.com (Mirapoint) with ESMTP id ACC37091; Tue, 12 Nov 2002 10:14:10 -0500 (EST) Message-Id: <5.2.0.9.0.20021112095952.02183290@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 12 Nov 2002 10:14:06 -0500 To: "Zhu, Rupert" From: "Thomas D. Nadeau" Subject: Re: MPLS-TE-MIB Report 2/3: General Questions and Comments Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 04:26 PM 11/11/2002 -0600, Zhu, Rupert wrote: >------------------------------------------------------ >MPLS-TE-MIB Report 2/3: General Questions and Comments > > >This Email contains some general questions. Next Email contains >specific questions and comments. > > >TOPIC 1: Regarding "mplsTunnelRole". > > A tunnel instance may take one of three possible roles: Head, Transit, > Tail. Among the 37 fields in mplsTunnelTable, some are not applicable > to every role. For example, the fields > > mplsTunnelIsIf > mplsTunnelIfIndex > are not applicable at Transit nodes. Actually, it is possible that an implementation might use an ifIndex for each tunnel instance. There is certainly nothing to preclude this in any of the standards. So to be precise, I think that the BCP is that these only apply to heads, but perhaps not always. > In analogy to ATM SPVC, I guess Head node should > have the largest set of applicable fields. Transit node is likely > to have the smallest set of applicable fields. > >Q1: In mplsTunnelTable, exactly which table fields are applicable > to which roles? Could the authors make it clear? Which objects do you think are not documented? We did add text in some places to update this. >Q2: For an LSP established through signaling, how can a transit node > find out the mplsTunnelIndex? The value of this field is always > required because it is part of INDEX of the table. I don't understand this question. Just look at the tunnelTable. If you want the heads, we recommend these use instanceIndex = 0, but you can also look at the tunnel's role if that is not the case. >Q3: When the tunnel instances of a (logical) tunnel are diversely routed > through signaling, how can a transit node get the info of other > tunnel instances that belong to the same tunnel? It seems that > the transit node can only record one tunnel instance if it is > established through signaling. Two points. First, when is a TE tunnel not established through signaling? Second, I think you can just look at the table to find the tunnel instances in the table. >TOPIC 2: In Relation to MPLS-FTN-MIB > > Excerpt from MPLS-FTN-MIB (v05) > ----------------------------------------------------------- > mplsFTNActionPointer OBJECT-TYPE > SYNTAX RowPointer > DESCRIPTION > ........ > If mplsFTNActionType is redirectTunnel(3), then this > object indicates the instance of mplsTunnelEntry for > the MPLS TE tunnel to redirect matching packets to. > ----------------------------------------------------------- > >Q1: Consider a scenario that a (logical) tunnel is composed of 5 > diversely routed tunnel instances (LSPs) that run in a load-sharing > manner. Which tunnel instance should be selected for this FTN > mapping? What's the criteria? The FTN MIB can use two models for FTN. First, a single tunnel head pointed to by a single FTN entry. The tunnel head uses multiple LSPs. The second mode allows for multiple FTN entries that point at tunnel heads to represent the multiple paths. >Q2: In the same scenario, if administrator delete one of the tunnel > instances and that happens to be the one FTN mapped to, what would > happen? Orphan pointer? Any succession rules? I believe that the FTN MIB's tables have been updated to be very clear what needs to happen in these cases. In essence, the agent must take inappropriate rows out of service. >In my opinion, the MIB definition quoted above is a kludge that >twisted the logical relationship and added undesirable complexities. >(E.g., Q1 and Q2 above.) >The correct design should have FTN mapped to the (logical) tunnel, >instead of a member tunnel instance. This way, the member tunnel >instances may be added, removed or modified freely, without affecting >the FTN mapping. And we wouldn't need to worry about selection >criteria, deletion procedure and succession rules. This is certainly one way that you can use the FTN MIB (as explained above). However, we did not feel that we should restrict the use to just this way. --Tom >Regards, > > >Rupert Zhu >System Engineering >Santera Systems Inc >3605 E. Plano Parkway >Plano, TX 75074 >Phone: 972-461-6383 Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Tue Nov 12 12:21:40 2002 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 ESMTP id MAA07408 for ; Tue, 12 Nov 2002 12:21:40 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnorl14103 for ; Tue, 12 Nov 2002 17:24:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnorl12694; Tue, 12 Nov 2002 17:23:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQnorl14094 for mpls-outgoing; Tue, 12 Nov 2002 17:23:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnorl14089 for ; Tue, 12 Nov 2002 17:22:54 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 QQnorl06837 for ; Tue, 12 Nov 2002 17:22:26 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnorl10738 for ; Tue, 12 Nov 2002 17:22:25 GMT Received: from blooper.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnorl10724 for ; Tue, 12 Nov 2002 17:22:24 GMT Received: from utfors.se ([195.58.105.107]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id gACHMNgd016804 for ; Tue, 12 Nov 2002 18:22:23 +0100 (MET) Message-ID: <3DD138CF.4070606@utfors.se> Date: Tue, 12 Nov 2002 18:22:23 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg Subject: the open wg mib review meeting updates Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, the agend for the mpls MIB review meeting has been updated with info on the goals of the meeting and also info on how to get into the meeting facilities. http://urax.utfors.net/~loa/mpls-mib-review.htm text version below. /Loa ------------------------------------------------------------------------ MPLS MIB review Atlanta November 16, 12 AM to 6 PM, at the Cisco office at: The Point Complex, Building 500 500 Northridge Road Atlanta, GA 30350 678-352-2500 Toll Free: 800-764-4390 (Further info and some instructions at the bottom of the page). Goals at with this meeting: review the mpls mibs to make sure that they have good quality and and usefulness make sure that the mpls mibs as group have a joint scope and common structure; e.g. - internal consistency of the MIBs as a group - interdependencies and structure - commonality and non-overlap between the different mibs - straighten out some of the complexity create a basis for continued work with the gmpls mibs Agenda (to be bashed) 1. Opening remarks (Loa) 2. AD views (Bert) 3. On behalf of the mib - authors (proposed Tom and/or Joan) 4. MPLS MIB overview (Tom/Joan) 5 The MIBs one by one in some logical order 5.1 lsr mib 5.2 ldp mib 5.3 ftn mib 5.4 te mib 5.5 tc mib 5.6 bundle mib (Tom) 5.7 tewg mib (Kireeti) 6. GMPLS cosiderations 7. Summary of input and actions. 7.1 Report to mpls wg meeting 7.2 id tracker input / corrections ------------------------------ Directions from the airport: At the Atlanta Airport: Leave the airport following direction indicators toward I-75 North. Take I-75 North to the I-85 North exit. Travel on I-85 North to Hwy GA-400 North (toll road) While traveling on GA-400, look for the Northridge Road Exit Turn right at the top of the exit and cross over GA-400. Turn right into The Point complex. Building 500 is on the right inside the complex. Note: According to the hosts it is "quite close to the hotel, (~20 min) take a taxi" ------------------------------------------------------- Quote from a mail from Tom Nadeau who is hosting the meeting: I just confirmed the reservation for the East/West Berlin conference room on the 7th floor of the Cisco Atlanta office. People may arrive starting at 11:30AM EST. I have arranged for security personnel to escort visitors up to the conference room after I arrive. They will not let you up until I am there, so please verify that I am there before you ask to go up. Also mention that you are here for "the IETF MIB meeting". If you arrive and there is no one to open to door for you, please call my cell phone at +1.603.548.7958. I have confirmed that the Cisco office is a 45 minute ride from the Atlanta Airport, so please plan accordingly. We can order our pizza or something for delivery to keep us from eating our hands during the meeting. The person setting up the room has confirmed that there are several decent 'za' establishments in the area that should suffice. -- Loa Andersson Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Mobile +46 70 848 5038 Email loa.andersson@utfors.se From owner-mpls@UU.NET Tue Nov 12 13:46:04 2002 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 ESMTP id NAA09980 for ; Tue, 12 Nov 2002 13:46:03 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnorr07306 for ; Tue, 12 Nov 2002 18:48:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnorr06490; Tue, 12 Nov 2002 18:48:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnorr09267 for mpls-outgoing; Tue, 12 Nov 2002 18:47:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnorr09262 for ; Tue, 12 Nov 2002 18:47: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 QQnorr14547 for ; Tue, 12 Nov 2002 18:46:10 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnorr25645 for ; Tue, 12 Nov 2002 18:46:10 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnorr25630 for ; Tue, 12 Nov 2002 18:46:10 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gACIgPI18855; Tue, 12 Nov 2002 13:42:25 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Nov 2002 13:42:24 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C05FE3F82@zcard031.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" , mmorrow@cisco.com, swallow@cisco.com Cc: mpls@UU.NET Subject: draft-nadeau-ip-basedtool-requirements-01 Date: Tue, 12 Nov 2002 13:42:21 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Tom/Monique/George: Interesting document, a "few" comments though ;-) Section 2: "Any error condition that prevents an LSR"....do you mean LSP here? Section 3: 'a' this munges together detection and diagnosis. Shouldn't path liveliness and path tracing be separated out as separate requirements. (They seem to be synonymous in this document). 'b' Are you inheriting all the requirements of the GTTP requirements document by reference. There is a lot of stuff in there that is more generic and may not be applicable. Is there a specific difference between tunnel trace and path trace in this document? 'c' The phrase "automation of path tracing..." are you really discussing misbranching/mismerging detection. My read of this is that I am required to periodically perform traceroute on LSPs. I doubt that is the actual intent. 'd' [LSPPING] for CE to CE verification. Besides violating the "non-prescriptive" claim in the introduction, I didn't think MPLS went CE to CE ;-) The wording seems to confuse path tracing as a response to failure detection, and the mechanism for failure detection as outlined in 'b'. Also some requirements seem to do with the tools, and others with respect to box behaviors (e.g. suggesting a nodal response to failure detection), it might be cleaner simply to stick to what the tools should do, and let folks roll up the system behaviors into applications themselves. 'e' If I understood 'b' correctly, is this not the same thing? 'f' Requirements 'f', 'l' and 'm' seem to be largely overlapping, although I cannot actually parse 'l', and may be interested in latency for reasons other than SLA. 'g' what is a "device" in this context, and that it only "may" take corrective action runs counter to the first sentence suggesting the network MUST self-heal. The general requirement is rather high level. I've preferred the wording that "the network detect faults, and may facilitate automated response to restore service (e.g. via fault notification or whatever)". 'h' Agree 'i' What OAM functions are common to how both P2P and MP2P are instrumented? Presumably one solution that meets the requirement is to overlay P2P on MP2P.... 'j' In general agree, with the proviso that some synchronization of tool usage/frequency is required for availability metrics, e.g. the network needs to function as a system and the OAM functions harmonized across the system. 'k' The wording seems to undermine requirements 'h' and 'r'. IMHO this seems to highlight one problem with instrumenting load balancing (as per ECMP etc.) in general. The approach is that all paths need to be tested, the specific implication is that they all need to be able to be tested from any point. That I do not think is sustainable. If OAM probes are to follow the same path as the user traffic, then ECMP should function independently of both the OAM probes and the user traffic. Otherwise we're into the "monkeys and typewriters" verification model as the OAM probes try various permutations to impersonate user traffic's ECMP characteristics (which by definition is proprietary and therefore unknowable to the probe origin). 'l' See 'f'. 'm' This one is not clear to me, and sort of suggests using bursts of OAM packets to characterize LSP performance, a clarification please..? 'n' The actual example is rather trivial as all the LSPs discussed terminate in a single box. What is required is alarm suppression in all clients regardless of where the client LSP, PW, VCC, VPC etc. terminates. 'o' This seems othogonal to the other requirements, and seems relatively hard not to satisfy. In other words, why is it here? 'p' Seems prescriptive. IMHO detection of, and limitation of damage/disruption done by DOS attacks is the requirement. "How" is for another day. 'q' OAM interworking for fault notification is only a part of the problem. The client may be monitored, therefore timliness of this stuff matters as it either needs to harmonize with the client OAM, or the client OAM needs to be configured to "hold off" before reacting. Which also implies a requirement for bounded detection times, which is one nit I have with current proposals for instrumentation of ECMP and other load sharing mechanisms (one offshoot being the "guidelines for load balancing" draft to be presented later on the WG agenda). 'r' This is a rather long winded way to say that "liveliness must test the actual forwarding path (proxy verification of what systems "think" is happening is insufficient)". And finally, nothing in the document leap out at me as justifying the title (except perhaps the use of SNMP ;-) cheers Dave From owner-mpls@UU.NET Tue Nov 12 16:24:27 2002 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 ESMTP id QAA16560 for ; Tue, 12 Nov 2002 16:24:27 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnosb08987 for ; Tue, 12 Nov 2002 21:26:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnosb07911; Tue, 12 Nov 2002 21:26:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnosb16783 for mpls-outgoing; Tue, 12 Nov 2002 21:26:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnosb16763 for ; Tue, 12 Nov 2002 21:26: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 QQnosb29645 for ; Tue, 12 Nov 2002 21:25:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnosb17913 for ; Tue, 12 Nov 2002 21:25:30 GMT Received: from evita3.cs.fredonia.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: evita2.cs.fredonia.edu [141.238.30.15]) id QQnosb17908 for ; Tue, 12 Nov 2002 21:25:30 GMT Received: from zubairi (zubairi.cs.fredonia.edu [141.238.30.211]) by evita3.cs.fredonia.edu (8.10.2/8.10.2) with SMTP id gACLPSt29972 for ; Tue, 12 Nov 2002 16:25:28 -0500 Message-ID: <003301c28a92$8495bfe0$d31eee8d@zubairi> Reply-To: "Junaid Ahmed Zubairi" From: "Junaid Ahmed Zubairi" To: Subject: ATS2003: Due date Nov 29th Date: Tue, 12 Nov 2002 16:28:57 -0500 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.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The last date for submission of abstracts is Nov 29 for Applied Telecommunication Symposium'2003. Please contribute to this symposium Thanks Junaid CFP is enclosed > *^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^ > > CALL FOR PAPERS > Track on Traffic Engineering With Protocols and Devices > in > Applied Telecommunication Symposium (ATS) > Part of the 2003 Advanced Simulation Technologies Conference (ASTC 2003) > March 30 through April 3, 2003 > Hyatt Orlando Hotel, Orlando, FL, USA > > The Applied Telecommunication Symposium (ATS) is an international forum for > exchange of technical knowledge and presentation of original papers on the > analysis of telecommunication systems and technologies. It is intended for > professionals, engineers, software developers, managers, and others > interested in cellular and packet traffic characteristics, analysis of > telecommunication networks, and practitioners operating telecommunication > networks. We are looking for innovative technical papers describing > projects, applications, and research and development work pertinent to > telecommunication. The following tracks (with track chairs listed) will be > held; the topics are representative of the track, but are not necessarily > exclusive to that track: > > Wireless > Chairs - Dr. Hassan Rajaei, Bowling Green State University > Dr. Mohsen Guizani, University of West Florida > -CDMA > -UMTS > -GSM > -2.5G/3G Wireless > -Wireless Data > -Cell Traffic > -Network Performance and Engineering > > Telecommunications Business and Regulation > Chair - Dr. George Kraft, Stuart School of Business, Illinois Institute of > Technology > -Cost modeling > -Call center operations > -Billing models > -E-commerce > > Measurements > Chair - Dr. Shakil Akhtar, UAE University, Al-Ain, United Arab Emirates > -Measured Internet Traffic Characteristics > -Wireless Traffic Characteristics > -Observed Problems with Current Packet Switching Protocols > -Tools > > Network Management and Security > Chair - Dr. Axel Lehmann, Universitaet der Bundeswehr Muenchen > -Operations, Administration, Maintenance > -Overload control > -Load balancing > -Influence of security measures on network performance > > Networks and Multimedia > Chairs - Dr. Aftab Ahmad, DePaul University > -Internet > -Network performance > -Traffic characterization > -Packet switch architecture evaluation > > Modeling Techniques > Chair - Kamala Murti, Lucent Technologies, Inc. > -Simulation techniques > -Acceleration methods > -Traffic synthesis > -Combined simulation/analytic procedures > > *Traffic Engineering with Protocols and Devices > Chair - Dr. Junaid Zubairi, SUNY at Fredonia > -Traffic Management and control > -Traffic engineering architectures > -Bandwidth management > -GMPLS > > Three copies of a 300 word abstract or a draft paper should be submitted to > the session organizers by November 1, 2002. Please indicate for which > track(s) you wish to have your paper considered for; note that the final > track selection will be at the discretion of the ATS organizers. The > abstract must include the author(s), e-mail address(es), and affiliation. > Abstracts may be submitted electronically to > http://scs.proceedingscentral.com or directly to: > > Dr. Bohdan Bodnar, ATS Chair, Motorola, USA, > bbodnar1@motorola.com, or to > > Dr. Ariel Sharon, Lucent Technologies, Inc., > E-mail: asharon@lucent.com. > > Further information is available at > http://www.scs.org/confernc/astc/astc03/cfp/ats03.htm > > Deadlines > Abstract/Draft paper dueNovember 29, 2002 > Camera-ready paper dueJanuary 31, 2003 > > Conference Committee > General Chair > Dr. Bohdan Bodnar > Motorola, Inc. > bbodnar1@motorola.com > > Co-Chair > Dr. Ariel Sharon > Lucent Technologies, Inc. > asharon@lucent.com > > Program Chair > Dr. George Kraft > Illinois Institute of Technology > > Sponsored by The Society for Modeling and Simulation International > P.O. Box 17900 > San Diego, CA 92177-7900 > Tel 858-277-3888 > Fax: 858-277-3930 > E-mail scs@scs.org > http://www.scs.org > > > > * For more information on the Traffic Engineering track, please contact the > track chair at the following address: > Dr. Junaid Ahmed Zubairi > Department of Mathematics and Computer Science > College at Fredonia, State University of New York > Fredonia, NY 14063, USA > > Tel: +1-716-673-4694 > Fax: +1-508-256-8324 > Email: zubairi@cs.fredonia.edu > > WWW: http://www.cs.fredonia.edu/~zubairi > > From owner-mpls@UU.NET Wed Nov 13 08:58:36 2002 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 ESMTP id IAA01218 for ; Wed, 13 Nov 2002 08:58:36 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnoum11563; Wed, 13 Nov 2002 13:00:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnoum03410 for mpls-outgoing; Wed, 13 Nov 2002 13:00:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnoul03405 for ; Wed, 13 Nov 2002 12:59:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnoul00826 for ; Wed, 13 Nov 2002 12:59:16 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnoul02505 for ; Wed, 13 Nov 2002 12:59:15 GMT Received: from cbibipnt05.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnoul02493 for ; Wed, 13 Nov 2002 12:59:15 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 13 Nov 2002 12:59:10 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389E1C120@i2km07-ukbr.domain1.systemhost.net> To: dallan@nortelnetworks.com Cc: mpls@UU.NET Subject: RE: draft-nadeau-ip-basedtool-requirements-01 Date: Wed, 13 Nov 2002 12:58:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Dave, Good comments. Rather than repeat yours where I agree, I'll just augment and add some new ones.....please see in-line below. regards, Neil > -----Original Message----- > From: David Allan [mailto:dallan@nortelnetworks.com] > Sent: 12 November 2002 18:42 > To: Thomas D. Nadeau; mmorrow@cisco.com; swallow@cisco.com > Cc: mpls@UU.NET > Subject: draft-nadeau-ip-basedtool-requirements-01 > > > Tom/Monique/George: > > Interesting document, a "few" comments though ;-) NH=> 'Abstract': Great to see others now taking fault-management of MPLS more seriously. Thanks. NH=> 'Section 1, Introduction': I know quite a bit of what is in here is drawn from the requirements/principles given in Y.1710. Reference to this work out of courtesy would seem in order. > > Section 2: > "Any error condition that prevents an LSR"....do you mean LSP here? NH=> The focus should be on traffic-affecting defects. Foremost here are all the potential defects that could affect the data-plane LSP, and these should be: - identified 1st - then defined wrt entry/exit criteria and consequent actions that need to be applied, esp at the sink points of the LSPs. The need for this in its own right is obvious I think, but if one then wants consistent behaviour across vendors/operators and also an ability to define SLAs (for both availability and QoS metrics) this is a fundamental requirement. This aspect is still missing. > > Section 3: NH=> I only counted 4 operators in the acknowledgements who have contributed (BT being one of them). I would hesitate to say we have 'much experience running MPLS networks' in all cases....I suspect the primary experience of most operators is with rfc2547 and LDP, and low/zero experience in the RSVP-TE and/or PWE3 XoverMPLS areas. > > 'a' this munges together detection and diagnosis. Shouldn't > path liveliness > and path tracing be separated out as separate requirements. > (They seem to be > synonymous in this document). NH=>It's not just detection and diagnosis (though I agree these are distinct issues).....between these 2 we need to have automatic consequent actions where appropriate. > > 'b' Are you inheriting all the requirements of the GTTP requirements > document by reference. There is a lot of stuff in there that > is more generic > and may not be applicable. Is there a specific difference > between tunnel > trace and path trace in this document? NH=> I'd like some clarification here too. LSP PING has changed significantly from its initial incarnation and now includes path tracing capabilities (include attempting exercising ECMP subnetworks). So how does this now sit with the other 'TUNTRACE' and 'GTTP' references that are given, eg will the latter pair exclude the MPLS case so as not to create overlap with LSP PING , or is something else intended? > > 'c' The phrase "automation of path tracing..." are you really > discussing > misbranching/mismerging detection. My read of this is that I > am required to > periodically perform traceroute on LSPs. I doubt that is the > actual intent. NH=> I was also unclear as to intent here. Surely path trace is an 'on-demand' diagnostic function? The thing we need running continuously is automatic defect detection and handling. > > 'd' [LSPPING] for CE to CE verification. Besides violating the > "non-prescriptive" claim in the introduction, I didn't think > MPLS went CE to > CE ;-) The wording seems to confuse path tracing as a > response to failure > detection, and the mechanism for failure detection as > outlined in 'b'. Also > some requirements seem to do with the tools, and others with > respect to box > behaviors (e.g. suggesting a nodal response to failure > detection), it might > be cleaner simply to stick to what the tools should do, and > let folks roll > up the system behaviors into applications themselves. NH=> IP layer PING is testing the IP layer. That is fine and we want this. But we also want mechanisms for monitoring the MPLS layer(s) that are independent of the client, and consistent across all clients, eg PWE3 case. Take the logic further....I would not be expecting to use an IP PING mechanism to test a SDH VC4 path. Each layer needs independent fault handling mechanisms, else no layer independence (which impacts consistency of usage for any client and ability to evolve layer networks in isolation). > > 'e' If I understood 'b' correctly, is this not the same thing? > > 'f' Requirements 'f', 'l' and 'm' seem to be largely > overlapping, although I > cannot actually parse 'l', and may be interested in latency > for reasons > other than SLA. NH=> Agree with goals stated on being able to say something about QoS performance, but unclear how to get there. I cannot see how we can progress to any meaningful discussion of QoS metrics unless we have first agreed/specified: - defects (entry/exit criteria and consequent actions) - up/down transition states.....since all QoS metrics only have any currency when the entity considered is 'up'. These aspect are all addressed for the case of p2p LSPs in Y.1711. **BTW - what is happening wrt to the various MIBs here?**....I come back on this importnat observation later. > > 'g' what is a "device" in this context, and that it only "may" take > corrective action runs counter to the first sentence > suggesting the network > MUST self-heal. The general requirement is rather high level. > I've preferred > the wording that "the network detect faults, and may > facilitate automated > response to restore service (e.g. via fault notification or > whatever)". NH=> Agree with above observations. Consequent actions are more than just invoking restoration.....one has to specify all the defects and decide on the appropriate consequent actions in each case to make the required behaviour clear. For example, a simple break is quite different (in required consequent actions) to traffic leaking (ie replicated) from one LSP into some other LSP....in latter case there is no observable defect on the 'offending' LSP, but it does create a potential security compromise for that traffic. > > 'h' Agree > > 'i' What OAM functions are common to how both P2P and MP2P > are instrumented? > Presumably one solution that meets the requirement is to > overlay P2P on > MP2P.... NH=> This is a fundamental point....worth explaining so everyone can grasp the inherent problem we have to live with here. co pkt-sw networks can have connectivity failures modes that are not relevant to cnls networks....the *network-unique* address in each/every cnls IP pkt provides the protection, but this is not present with only *link-connection-unique* labels which is the way co pkt-sw networks do forwarding. 'Merging' as a concept does not even exist in IP/cnls networks, here we have multiplexing, ie each/every pkt is always uniquely identifiable as to source and can therefore always be readily selected from any mixed stream of IP pkts. mp2p merging is a weird thing to do when using a co pkt-sw forwarding paradigm (ie where only link-connection-unique labels are used)....and from a fault-management or QoS measurement perspective p2p is OK (=trivial) and p2mp is OK (=reasonably simple) but mp2p is 'difficult'. If you do mp2p using a co pkt-sw paradigm you *must* run some form of p2p above this to remove the effect of the merging. In a PWE3 XoverMPLS sense this is why one must have 2 labels in Martini et al, and even in rfc2547 L3 VPNs there are both p2p BGP4 instantiated LSPs (to resolve to VPN....*not* the specific PE source, since it has been decided that the label issued by given PE to all other PEs is the same) and above this there must be IP pkts (to resolve to the precise destination required within identified VPN). If one could somehow monitor the correct connectivity and the QoS of these 'always must have' higher level p2p constructs one could then have some form of detecting failures at any server level....even to the optics/duct, though 'client proxying for missing server OAM functionality' should not be a general rule...and thus one would only need to have ad hoc on-demand tools to investigate the mp2p constructs once the higher p2p constructs had detected *and* handled (ie apply appropriate consequent actions to) the defect. {Note - if L1 shows a fault then obviously no need to even investigate the mp2p anyway} Worth thinking about IMO....though I suspect not simple to address in all cases. > > 'j' In general agree, with the proviso that some > synchronization of tool > usage/frequency is required for availability metrics, e.g. > the network needs > to function as a system and the OAM functions harmonized > across the system. NH=>Understand sentiment. Also depends on whether we are discussing ad hoc diagnostic tools or continuous defect/detection handling tools. However, if one wants consistent metrics (say availability) this will be hard to achieve unless the behaviour of the defect detection mechanism is specified to be the same in all cases. So where strong SLAs are *not* required then variable OAM behaviour may be fine, but where strong SLAs are required (be they directly with a customer or perhaps another operator in some client/server or tandemed interworking case) then it seems important that all parties would want to have a consistent behavioural view. Currently the pressure is on to get 'anything' from an Ops-only perspective.....but it's unlikely to remain this way IMO, ie more consistency will be required over time, so we need to be thinking about this aspect. > > 'k' The wording seems to undermine requirements 'h' and 'r'. > IMHO this seems > to highlight one problem with instrumenting load balancing > (as per ECMP > etc.) in general. The approach is that all paths need to be > tested, the > specific implication is that they all need to be able to be > tested from any > point. That I do not think is sustainable. If OAM probes are > to follow the > same path as the user traffic, then ECMP should function > independently of > both the OAM probes and the user traffic. Otherwise we're > into the "monkeys > and typewriters" verification model as the OAM probes try various > permutations to impersonate user traffic's ECMP > characteristics (which by > definition is proprietary and therefore unknowable to the > probe origin). NH=> Well if you don't have explicitly controlled routes and you need to load share (to get a form of TE to avoid the SPF IGP route choice) this is an unavoidable consequence. If we were doing consistent defect detection of some higher level p2p entities this may not be such a big problem.....that is, if fault shows up on higher level entity then start investigating ECMP behaviour using ad hoc on-demand tools. However, if we don't/can't do this then one will have some issues here as you note Dave. > > 'l' See 'f'. > > 'm' This one is not clear to me, and sort of suggests using > bursts of OAM > packets to characterize LSP performance, a clarification please..? NH=> I read this as 'compare pkts 'in' with pkts 'out' at source/sink of LSP against some metric, eg delay, loss, errors.'. I can see this is obvious in p2p case, also obvious in p2mp case, but less obvious in mp2p case.....is this what you meant by asking for further clarification, because I'd like to understand this aspect? > > 'n' The actual example is rather trivial as all the LSPs > discussed terminate > in a single box. What is required is alarm suppression in all clients > regardless of where the client LSP, PW, VCC, VPC etc. terminates. NH=> Correct. > > 'o' This seems othogonal to the other requirements, and seems > relatively > hard not to satisfy. In other words, why is it here? NH=> I see what you mean Dave, but I think the MIB relationships are actually very important. I have some concerns they may not have taken all the users requirements into account....after all they seem to have been done *before* the OAM work has been concluded! Further, there are different user-perspectives on the element collected statistics, for example: - Ops would be concerned with day-day fault management....so the nature of the network embedded OAM functions determine the efficacy of the element/MIB parameters collected and acted on; that is, if the inherent network functions provide poor information then any subsequent NMS/OSS manipulation cannot improve it - Design/planning functions work over longer periods and are concerned with TE and growing/changing network topologies according to utilisation observed and forecasts (new traffic) given - Products/services functions need to bill and correlate SLA availability/QoS performance over some period against which the metric objectives are assessed > > 'p' Seems prescriptive. IMHO detection of, and limitation of > damage/disruption done by DOS attacks is the requirement. "How" is for > another day. > > 'q' OAM interworking for fault notification is only a part of > the problem. > The client may be monitored, therefore timliness of this > stuff matters as it > either needs to harmonize with the client OAM, or the client > OAM needs to be > configured to "hold off" before reacting. Which also implies > a requirement > for bounded detection times, which is one nit I have with > current proposals > for instrumentation of ECMP and other load sharing mechanisms > (one offshoot > being the "guidelines for load balancing" draft to be > presented later on the > WG agenda). NH=> The requirement as stated is generally OK with me, and its important. However, the key to being able to do this properly is having harmonised and well specified defect handling behaviour across all layers independently. It's no good specifying apples at layer X if some (client) layer Y is measuring oranges.....and esp if the relationship between the 2 is variable (see comments against point 'j' above for example) and not consistent for all parties even at layer Y. > > 'r' This is a rather long winded way to say that "liveliness > must test the > actual forwarding path (proxy verification of what systems "think" is > happening is insufficient)". NH=> The way this is effectively worded in Y.1710 is to require that the fault-handling of the traffic's data-plane has to be independent of any control-plane protocols (inc case of 'none'). > > And finally, nothing in the document leap out at me as > justifying the title > (except perhaps the use of SNMP ;-) > > cheers > Dave > > > From owner-mpls@UU.NET Wed Nov 13 11:45:37 2002 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 ESMTP id LAA07735 for ; Wed, 13 Nov 2002 11:45:37 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovb16818 for ; Wed, 13 Nov 2002 16:48:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnovb15660; Wed, 13 Nov 2002 16:47:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnovb05262 for mpls-outgoing; Wed, 13 Nov 2002 16:47:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnovb05244 for ; Wed, 13 Nov 2002 16:46: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 QQnovb23726 for ; Wed, 13 Nov 2002 16:46:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovb14728 for ; Wed, 13 Nov 2002 16:46:14 GMT Received: from excalibur.santera.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnovb14718 for ; Wed, 13 Nov 2002 16:46:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Statistics of MPLS MIB Family Date: Wed, 13 Nov 2002 10:46:09 -0600 Message-ID: Thread-Topic: Statistics of MPLS MIB Family Thread-Index: AcKLNCpGNOy6f6OPQ+ipM5Gl3sqrjw== From: "Zhu, Rupert" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07735 FYI. The following statistics depicts an overall picture of MPLS MIB family. (If it skews on your screen, use Notepad on PC or vi/emacs on UNIX.) ------------------------------------------------------- TABLE SIZE STATISTICS mplsInterfaceConfTable 8 (MPLS-LSR-MIB) mplsInterfacePerfTable 4 (MPLS-LSR-MIB) mplsInSegmentTable 9 (MPLS-LSR-MIB) mplsInSegmentPerfTable 6 (MPLS-LSR-MIB) mplsOutSegmentTable 11 (MPLS-LSR-MIB) mplsOutSegmentPerfTable 6 (MPLS-LSR-MIB) mplsXCTable 12 (MPLS-LSR-MIB) mplsLabelStackTable 5 (MPLS-LSR-MIB) mplsTrafficParamTable 6 (MPLS-LSR-MIB) mplsLdpEntityTable 22 (MPLS-LDP-MIB) mplsLdpEntityStatsTable 13 (MPLS-LDP-MIB) mplsLdpPeerTable 3 (MPLS-LDP-MIB) mplsLdpSessionTable 6 (MPLS-LDP-MIB) mplsLdpSesStatsTable 2 (MPLS-LDP-MIB) mplsLdpHelloAdjacencyTable 3 (MPLS-LDP-MIB) mplsLdpLspTable 7 (MPLS-LDP-MIB) mplsFecTable 7 (MPLS-LDP-MIB) mplsLdpLspFecTable 3 (MPLS-LDP-MIB) mplsLdpSesPeerAddrTable 3 (MPLS-LDP-MIB) mplsLdpEntityGenLRTable 5 (MPLS-LDP-GENERIC-MIB) mplsLdpEntityAtmParmsTable 11 (MPLS-LDP-ATM-MIB) mplsLdpEntityAtmLRTable 6 (MPLS-LDP-ATM-MIB) mplsLdpAtmSesTable 4 (MPLS-LDP-ATM-MIB) mplsLdpEntityFrParmsTable 7 (MPLS-LDP-FRAME-RELAY-MIB) mplsLdpEntityFrLRTable 4 (MPLS-LDP-FRAME-RELAY-MIB) mplsLdpFrameRelaySesTable 3 (MPLS-LDP-FRAME-RELAY-MIB) mplsFTNTable 18 (MPLS-FTN-MIB) mplsFTNMapTable 6 (MPLS-FTN-MIB) mplsFTNPerfTable 3 (MPLS-FTN-MIB) mplsTunnelTable 37 (MPLS-TE-MIB) mplsTunnelHopTable 15 (MPLS-TE-MIB) mplsTunnelResourceTable 10 (MPLS-TE-MIB) mplsTunnelARHopTable 8 (MPLS-TE-MIB) mplsTunnelCHopTable 9 (MPLS-TE-MIB) mplsTunnelPerfTable 5 (MPLS-TE-MIB) mplsTunnelCRLDPResTable 7 (MPLS-TE-MIB) teLinkTable 13 (LINK-BUNDLING-MIB) teLinkDescriptorTable 7 (LINK-BUNDLING-MIB) teLinkOspfTeTable 2 (LINK-BUNDLING-MIB) teLinkSrlgTable 3 (LINK-BUNDLING-MIB) teLinkBandwidthTable 5 (LINK-BUNDLING-MIB) componentLinkTable 5 (LINK-BUNDLING-MIB) componentLinkDescriptorTable 7 (LINK-BUNDLING-MIB) componentLinkBandwidthTable 5 (LINK-BUNDLING-MIB) teAdminGroupTable 2 (TE-MIB) teTunnelTable 23 (TE-MIB) tePathTable 18 (TE-MIB) tePathHopTable 7 (TE-MIB) mplsFrrConstTable 12 (MPLS-FRR-MIB) mplsFrrLogTable 6 (MPLS-FRR-MIB) mplsFrrOne2OnePlrTable 11 (MPLS-FRR-MIB) mplsFrrDetourTable 5 (MPLS-FRR-MIB) mplsFrrFacRouteDBTable 10 (MPLS-FRR-MIB) ------------------------------------------------------- MIB MACRO STATISTICS Total Macro Count: 828 Individual Macro Type Count ------------------------------------- MODULE-COMPLIANCE: 17 MODULE-IDENTITY: 11 NOTIFICATION-GROUP: 6 NOTIFICATION-TYPE: 17 OBJECT-GROUP: 42 OBJECT-IDENTIFIER: 65 OBJECT-TYPE: 586 PLAIN: 53 TEXTUAL-CONVENTION: 31 ------------------------------------- ------------------------------------------------------- TABLE SUMMARY STATISTICS TABLES in AllMibFile: 53 Total Fields in Tables: 435 Total Notifications: 17 Total Entities in Tree: 741 TABLES in MODULE MPLS-LSR-MIB: 9 Total Fields in Tables: 67 Total Notifications: 2 Total Entities in Tree: 114 TABLES in MODULE MPLS-LDP-MIB: 10 Total Fields in Tables: 69 Total Notifications: 4 Total Entities in Tree: 117 TABLES in MODULE MPLS-LDP-GENERIC-MIB: 1 Total Fields in Tables: 5 Total Notifications: 0 Total Entities in Tree: 16 TABLES in MODULE MPLS-LDP-ATM-MIB: 3 Total Fields in Tables: 21 Total Notifications: 0 Total Entities in Tree: 37 TABLES in MODULE MPLS-LDP-FRAME-RELAY-MIB: 3 Total Fields in Tables: 14 Total Notifications: 0 Total Entities in Tree: 30 TABLES in MODULE MPLS-FTN-MIB: 3 Total Fields in Tables: 27 Total Notifications: 0 Total Entities in Tree: 45 TABLES in MODULE MPLS-TE-MIB: 7 Total Fields in Tables: 91 Total Notifications: 4 Total Entities in Tree: 135 TABLES in MODULE MPLS-TC-MIB: 0 Total Fields in Tables: 0 Total Notifications: 0 Total Entities in Tree: 1 TABLES in MODULE LINK-BUNDLING-MIB: 8 Total Fields in Tables: 47 Total Notifications: 1 Total Entities in Tree: 78 TABLES in MODULE TE-MIB: 4 Total Fields in Tables: 50 Total Notifications: 4 Total Entities in Tree: 80 TABLES in MODULE MPLS-FRR-MIB: 5 Total Fields in Tables: 44 Total Notifications: 2 Total Entities in Tree: 88 ------------------------------------------------------- This report is generated based on the following MIB files. draft-ietf-mpls-lsr-mib-09 draft-ietf-mpls-ldp-mib-09 draft-ietf-mpls-ftn-mib-05 draft-ietf-mpls-te-mib-09 draft-ietf-mpls-tc-mib-05 draft-ietf-mpls-bundle-mib-04 draft-ietf-tewg-mib-03 draft-ietf-mpls-fastreroute-mib-01 Hope it helps. Rupert Zhu System Engineering Santera Systems Inc 3605 E. Plano Parkway Plano, TX 75074 Phone: 972-461-6383 From owner-mpls@UU.NET Wed Nov 13 13:50:24 2002 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 ESMTP id NAA12531 for ; Wed, 13 Nov 2002 13:50:24 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovj05951 for ; Wed, 13 Nov 2002 18:52:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnovj03970; Wed, 13 Nov 2002 18:51:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnovj20449 for mpls-outgoing; Wed, 13 Nov 2002 18:51:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnovj20437 for ; Wed, 13 Nov 2002 18:51:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnovj06003 for ; Wed, 13 Nov 2002 18:50:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovj10457 for ; Wed, 13 Nov 2002 18:50:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnovj10440 for ; Wed, 13 Nov 2002 18:50:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA03488 for ; Wed, 13 Nov 2002 13:50:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gADIo5n11358 for mpls@uu.net; Wed, 13 Nov 2002 13:50:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnovj20183 for ; Wed, 13 Nov 2002 18:48: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 QQnovj01543 for ; Wed, 13 Nov 2002 18:47:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovj08994 for ; Wed, 13 Nov 2002 18:47:37 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnovj08989 for ; Wed, 13 Nov 2002 18:47:37 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA03283; Wed, 13 Nov 2002 13:47:35 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA18334; Wed, 13 Nov 2002 13:47:35 -0500 (EST) Message-Id: <200211131847.NAA18334@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Cc: agenda@ietf.org Subject: Final MPLS Agenda Date: Wed, 13 Nov 2002 13:47:35 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk MPLS WG Agenda Atlanta 55th IETF TUESDAY, November 19, 2002 Salon B 0900-1130 1. Agenda bashing 5 min 2. Fast Reroute Alia Atlas 10 min Fast Reroute Extensions to RSVP-TE for LSP Tunnels Stefan DeCnodder 10 min Backup Record Route for Fast Reroute Techniques in RSVP-TE Jean-Phillipe Vasseur 5 min Distinguishing link and node failures using RSVP Hellos 3. Encapsulation Eric Rosen 10 min Encapsulating MPLS in IP or GRE 4. OAM Dave Allan 10 min A Framework for MPLS User Plane OAM Tom Nadeau 10 min IP-based Tool Requirements for MPLS Networks Kireeti Kompella 10 min Detecting MPLS Data Plane Liveness OAM Discussion 10 min 5. Load Balancing Dave Allan 10 min Guidelines for MPLS Load Balancing 6. Bi-directional LSPs Rohit Dube 10 min Bi-directional LSPs for classical MPLS 7. MPLS Security Michel Behringer 10 min Analysis of the Security of the MPLS Architecture 8. Multicast Allan Kullberg 10 min Extended RSVP-TE for Multicast LSP Tunnels 9. Workgroup Status Loa Andersson 5 min LDP to draft standard (status) Joan Cucchiara & Tom Nadeau 10 min MPLS MIB review meeting (report) Loa / George 15 min MPLS wg status From owner-mpls@UU.NET Wed Nov 13 13:55:35 2002 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 ESMTP id NAA12642 for ; Wed, 13 Nov 2002 13:55:35 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovj14847 for ; Wed, 13 Nov 2002 18:57:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnovj10365; Wed, 13 Nov 2002 18:55:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnovj20794 for mpls-outgoing; Wed, 13 Nov 2002 18:54:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnovj20741 for ; Wed, 13 Nov 2002 18:54:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnovj16848 for ; Wed, 13 Nov 2002 18:54:17 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovj13593 for ; Wed, 13 Nov 2002 18:54:17 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnovj13585 for ; Wed, 13 Nov 2002 18:54:17 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA03825 for ; Wed, 13 Nov 2002 13:54:16 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gADIsG011632 for mpls@uu.net; Wed, 13 Nov 2002 13:54:16 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnovj20482 for ; Wed, 13 Nov 2002 18:51: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 QQnovj11280 for ; Wed, 13 Nov 2002 18:50:57 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovj03406 for ; Wed, 13 Nov 2002 18:50:56 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQnovj03384 for ; Wed, 13 Nov 2002 18:50:55 GMT Received: from JVASSEUR-W2K.cisco.com (syd-vpn-client-255-20.cisco.com [10.66.255.20]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA01740 for ; Wed, 13 Nov 2002 19:50:52 +0100 (MET) Message-Id: <4.3.2.7.2.20021113134000.081e32c0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Nov 2002 13:50:44 -0500 To: mpls@UU.NET From: Jean Philippe Vasseur Subject: draft-vasseur-mpls-linknode-failure-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, New draft recently posted: draft-vasseur-mpls-linknode-failure-00.txt. Any comment is very welcome. Abstract The aim of this draft is to provide a method to distinguish a link from a node failure using RSVP hello extensions. In a network making use of MPLS Traffic Engineering Fast Reroute as specified in [FAST-REROUTE], efficient use can be made of the network links when protecting against link/node failures. As described in [FACILITY], excess capacity used for bypass tunnels can be shared between bypass tunnels providing protection for mutually exclusive failures of different links or nodes. This results in significant bandwidth savings under the single failure assumption. Making use of the single failure assumption implies the need to distinguish a link from a node failure. However, the mechanisms currently available for failures detection do not always allow to distinguishing a link from a node failure. Thanks. JP. From owner-mpls@UU.NET Wed Nov 13 14:53:21 2002 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 ESMTP id OAA15015 for ; Wed, 13 Nov 2002 14:53:21 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovn00941 for ; Wed, 13 Nov 2002 19:55:46 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnovn29457; Wed, 13 Nov 2002 19:55:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnovn14009 for mpls-outgoing; Wed, 13 Nov 2002 19:54:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnovn14002 for ; Wed, 13 Nov 2002 19:54: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 QQnovn17438 for ; Wed, 13 Nov 2002 19:54:24 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovn28942 for ; Wed, 13 Nov 2002 19:54:24 GMT Received: from web40013.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web40013.mail.yahoo.com [66.218.78.53]) id QQnovn28929 for ; Wed, 13 Nov 2002 19:54:23 GMT Message-ID: <20021113195422.11855.qmail@web40013.mail.yahoo.com> Received: from [130.65.88.108] by web40013.mail.yahoo.com via HTTP; Wed, 13 Nov 2002 11:54:22 PST Date: Wed, 13 Nov 2002 11:54:22 -0800 (PST) From: np rpr Subject: Re: draft-vasseur-mpls-linknode-failure-00.txt To: Jean Philippe Vasseur , mpls@UU.NET In-Reply-To: <4.3.2.7.2.20021113134000.081e32c0@paris.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Jean, I have question about Hello messages in RSVP-TE(RFC 3209). When exactly should the hello message be registered to timer. My thoughts: when RESVP is received on a node(LSR) and which confirms the success in creating the label.If this the right way then how this will be dealed at egress as it(egress) issues the first RESV and doesn't receieve as opposite to another nodes. Please advice me. Thanks, Nitin How --- Jean Philippe Vasseur wrote: > Hi, > > New draft recently posted: > draft-vasseur-mpls-linknode-failure-00.txt. Any > comment is very welcome. > > Abstract > > The aim of this draft is to provide a method to > distinguish a link from > a node failure using RSVP hello extensions. In a > network making use of > MPLS Traffic Engineering Fast Reroute as specified > in [FAST-REROUTE], > efficient use can be made of the network links when > protecting against > link/node failures. As described in [FACILITY], > excess capacity used > for bypass tunnels can be shared between bypass > tunnels providing > protection for mutually exclusive failures of > different links or nodes. > This results in significant bandwidth savings under > the single failure > assumption. Making use of the single failure > assumption implies the > need to distinguish a link from a node failure. > However, the > mechanisms currently available for failures > detection do not always > allow to distinguishing a link from a node failure. > > Thanks. > > JP. > __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From owner-mpls@UU.NET Wed Nov 13 15:03:40 2002 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 ESMTP id PAA15429 for ; Wed, 13 Nov 2002 15:03:40 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovo08212 for ; Wed, 13 Nov 2002 20:06:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnovo06430; Wed, 13 Nov 2002 20:05:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnovo01911 for mpls-outgoing; Wed, 13 Nov 2002 20:04:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnovo01856 for ; Wed, 13 Nov 2002 20:04:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnovo08818 for ; Wed, 13 Nov 2002 20:00:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovo03002 for ; Wed, 13 Nov 2002 20:00:11 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnovo02992 for ; Wed, 13 Nov 2002 20:00:11 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA10117 for ; Wed, 13 Nov 2002 15:00:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gADK0AB17616 for mpls@uu.net; Wed, 13 Nov 2002 15:00:10 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnovn14318 for ; Wed, 13 Nov 2002 19:58:40 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 QQnovn09660 for ; Wed, 13 Nov 2002 19:57:36 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnovn05147 for ; Wed, 13 Nov 2002 19:57:34 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnovn04176 for ; Wed, 13 Nov 2002 19:57:09 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 OAA53571; Wed, 13 Nov 2002 14:53:16 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200211131953.OAA53571@workhorse.fictitious.org> To: Der-Hwa Gan cc: "Gray, Eric" , mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) In-reply-to: Your message of "Tue, 05 Nov 2002 16:03:45 PST." <200211060003.gA603jS78616@merlot.juniper.net> Date: Wed, 13 Nov 2002 14:53:16 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200211060003.gA603jS78616@merlot.juniper.net>, Der-Hwa Gan writes: > > > Der-hwa, > > > > Here we have a trade-off between a small potential for > > simplification represented by using a symmetrical approach > > (the same approach used for increasing or decreasing the > > TE-LSP bandwidth) and the potential risk of not being able > > to make a new reservation with a lesser bandwidth in the > > unusual use of FF reservation style. > > It is not a question of simplication. If FF reservation style is > excluded from RSVP-TE spec, then we won't discuss it. But if FF remains > a potential option (perhaps a future application may make use of it?), > then it is fair to consider it. > > My response was mainly to the point that Curtis raised - could there be > a reason that changing ID is bad? > > > > > Please tell me again why this is a hard choice? > > There are other benefits to not changing the ID. It was those considerations > that drove the original choice - it is more optimal, less > states, and less overhead to the network. > > Do you see a easy choice? > Der-Hwa If we can't agree that one approach is better, then we are stuck with the current situation. The ingress can either change the LSP-ID or not change the LSP-ID and just decrease the bandwidth. wrt you preferences. There is no "less states" advantage since you still have to implement bandwidth increase. The overhead of an additional interim LSP is inconsequential. In either case the flooding of a new reservable bandwidth amount incurs more overhead than the RSVP signaling, is identical for either approach, and is not a big deal either. If we still have two methods available to the ingress, then we have to make sure the midpoints can handle both. If so, then the only thing that we should add is (currently implied if the ingress can do it) that the midpoint LSR must be prepared to handle a decrease in bandwidth on an LSP. Curtis btw - maybe we should be getting rid of use of FF and just use SE but thats a whole new topic. From owner-mpls@UU.NET Thu Nov 14 18:57:02 2002 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 ESMTP id SAA09058 for ; Thu, 14 Nov 2002 18:57:01 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnozv27402 for ; Thu, 14 Nov 2002 23:59:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnozv26297; Thu, 14 Nov 2002 23:58:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnozv02546 for mpls-outgoing; Thu, 14 Nov 2002 23:58:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnozv02539 for ; Thu, 14 Nov 2002 23:58:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnozv07007 for ; Thu, 14 Nov 2002 23:58:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnozv18606 for ; Thu, 14 Nov 2002 23:58:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnozv18601 for ; Thu, 14 Nov 2002 23:58:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA26826 for ; Thu, 14 Nov 2002 18:58:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAENw5q04450 for mpls@uu.net; Thu, 14 Nov 2002 18:58:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnozv02505 for ; Thu, 14 Nov 2002 23:56:59 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 QQnozv26142 for ; Thu, 14 Nov 2002 23:56:37 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnozv24878 for ; Thu, 14 Nov 2002 23:56:36 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnozv24866 for ; Thu, 14 Nov 2002 23:56:36 GMT Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gAENuHS21644; Thu, 14 Nov 2002 15:56:17 -0800 (PST) (envelope-from jboyle@juniper.net) Received: from localhost (jboyle@localhost) by maroon.jnpr.net (8.11.6/8.11.3) with ESMTP id gAENuGc66208; Thu, 14 Nov 2002 15:56:16 -0800 (PST) (envelope-from jboyle@juniper.net) X-Authentication-Warning: maroon.jnpr.net: jboyle owned process doing -bs Date: Thu, 14 Nov 2002 15:56:16 -0800 (PST) From: Jim Boyle X-X-Sender: To: cc: , , Der-Hwa Gan Subject: Re: the complete mail In-Reply-To: <200211142320.gAENKtS18971@merlot.juniper.net> Message-ID: <20021114152458.W28745-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > On 13 Nov 2002 19:53:16 GMT, Curtis wrote: > > To: Der-Hwa Gan > cc: "Gray, Eric" , mpls@UU.NET > From: curtis@fictitious.org (Curtis Villamizar) > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > > > > > If we can't agree that one approach is better, then we are stuck with > the current situation. The ingress can either change the LSP-ID or > not change the LSP-ID and just decrease the bandwidth. > > > > If we still have two methods available to the ingress, then we have to > make sure the midpoints can handle both. If so, then the only thing > that we should add is (currently implied if the ingress can do it) > that the midpoint LSR must be prepared to handle a decrease in > bandwidth on an LSP. > > Curtis > Curtis, this sounds like the best approach. Is this the consensus? How do we proceed? regards, Jim Boyle From owner-mpls@UU.NET Thu Nov 14 23:31:31 2002 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 ESMTP id XAA17883 for ; Thu, 14 Nov 2002 23:31:31 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpao25895 for ; Fri, 15 Nov 2002 04:34:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpao24444; Fri, 15 Nov 2002 04:33:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpao26645 for mpls-outgoing; Fri, 15 Nov 2002 04:32:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpao26635 for ; Fri, 15 Nov 2002 04:32: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 QQnpao24334 for ; Fri, 15 Nov 2002 04:32:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpao25970 for ; Fri, 15 Nov 2002 04:32:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpao25963 for ; Fri, 15 Nov 2002 04:32:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA09016 for ; Thu, 14 Nov 2002 23:32:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAF4W6Y18075 for mpls@uu.net; Thu, 14 Nov 2002 23:32:06 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpao26482 for ; Fri, 15 Nov 2002 04:31: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 QQnpao19435 for ; Fri, 15 Nov 2002 04:30:25 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnozw09750 for ; Fri, 15 Nov 2002 00:10:46 GMT Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gAF0AcS22823; Thu, 14 Nov 2002 16:10:38 -0800 (PST) (envelope-from jboyle@juniper.net) Received: from localhost (jboyle@localhost) by maroon.jnpr.net (8.11.6/8.11.3) with ESMTP id gAF0AcJ66799; Thu, 14 Nov 2002 16:10:38 -0800 (PST) (envelope-from jboyle@juniper.net) X-Authentication-Warning: maroon.jnpr.net: jboyle owned process doing -bs Date: Thu, 14 Nov 2002 16:10:38 -0800 (PST) From: Jim Boyle X-X-Sender: To: cc: , , Der-Hwa Gan Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" In-Reply-To: <20021114152458.W28745-100000@maroon.jnpr.net> Message-ID: <20021114160822.U28745-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Sorry for the strange subject on the last email, had to have someone forward me Curtis's email. The subject is corrected here. On Thu, 14 Nov 2002, Jim Boyle wrote: > > > > On 13 Nov 2002 19:53:16 GMT, Curtis wrote: > > > > To: Der-Hwa Gan > > cc: "Gray, Eric" , mpls@UU.NET > > From: curtis@fictitious.org (Curtis Villamizar) > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > > > > > > > > > > If we can't agree that one approach is better, then we are stuck with > > the current situation. The ingress can either change the LSP-ID or > > not change the LSP-ID and just decrease the bandwidth. > > > > > > > > If we still have two methods available to the ingress, then we have to > > make sure the midpoints can handle both. If so, then the only thing > > that we should add is (currently implied if the ingress can do it) > > that the midpoint LSR must be prepared to handle a decrease in > > bandwidth on an LSP. > > > > Curtis > > > > Curtis, this sounds like the best approach. > > Is this the consensus? How do we proceed? > > regards, > > Jim Boyle > > > From owner-mpls@UU.NET Fri Nov 15 00:48:23 2002 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 ESMTP id AAA19854 for ; Fri, 15 Nov 2002 00:48:22 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpat10234 for ; Fri, 15 Nov 2002 05:50:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpat08881; Fri, 15 Nov 2002 05:50:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpat21141 for mpls-outgoing; Fri, 15 Nov 2002 05:49:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpat21136 for ; Fri, 15 Nov 2002 05:49:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpat13969 for ; Fri, 15 Nov 2002 05:49:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpat14521 for ; Fri, 15 Nov 2002 05:49:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpat14508 for ; Fri, 15 Nov 2002 05:49:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id AAA13676 for ; Fri, 15 Nov 2002 00:49:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAF5n5J22458 for mpls@uu.net; Fri, 15 Nov 2002 00:49:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpat21100 for ; Fri, 15 Nov 2002 05:48: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 QQnpat06476 for ; Fri, 15 Nov 2002 05:46:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpat13085 for ; Fri, 15 Nov 2002 05:46:43 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnpat13058 for ; Fri, 15 Nov 2002 05:46:42 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 AAA69414; Fri, 15 Nov 2002 00:42:42 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200211150542.AAA69414@workhorse.fictitious.org> To: Jim Boyle cc: mpls@UU.NET, curtis@fictitious.org, egray@celoxnetworks.com, Der-Hwa Gan Reply-To: curtis@fictitious.org Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" In-reply-to: Your message of "Thu, 14 Nov 2002 16:10:38 PST." <20021114160822.U28745-100000@maroon.jnpr.net> Date: Fri, 15 Nov 2002 00:42:42 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20021114160822.U28745-100000@maroon.jnpr.net>, Jim Boyle writes: > > Sorry for the strange subject on the last email, had to have someone > forward me Curtis's email. The subject is corrected here. > > On Thu, 14 Nov 2002, Jim Boyle wrote: > > > > > > > > On 13 Nov 2002 19:53:16 GMT, Curtis wrote: > > > > > > To: Der-Hwa Gan > > > cc: "Gray, Eric" , mpls@UU.NET > > > From: curtis@fictitious.org (Curtis Villamizar) > > > Subject: Re: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd) > > > > > > > > > > > > > > > If we can't agree that one approach is better, then we are stuck with > > > the current situation. The ingress can either change the LSP-ID or > > > not change the LSP-ID and just decrease the bandwidth. > > > > > > > > > > > > If we still have two methods available to the ingress, then we have to > > > make sure the midpoints can handle both. If so, then the only thing > > > that we should add is (currently implied if the ingress can do it) > > > that the midpoint LSR must be prepared to handle a decrease in > > > bandwidth on an LSP. > > > > > > Curtis > > > > > > > Curtis, this sounds like the best approach. > > > > Is this the consensus? How do we proceed? > > > > regards, > > > > Jim Boyle Jim, > Is this the consensus? Probably. If so ... > How do we proceed? We have a hypothetical brand A, B, and C. A and B interoperate. A and C interoperate. B and C don't due to B decreasing bandwidth in a way that C can't handle. One option is just let customer U continue to try to beat up C. Or maybe they are beating up both B and C. Not important. The only other option is insist that for RFC3209 to go from PS to DS a paragraph needs to be added to "2.5. Rerouting Traffic Engineered Tunnels" at the very end stating something like: The same technique is used to accomplish a smooth reroute of a tunnel when bandwidth increases or when no bandwidth change occurs but the path changes or any other change which may result in a denial of the changed resource request. If there is no path change and a bandwidth decrease a make-before-break reroute can be done. Alternately, for no path change and a bandwidth decrease or any other change which is certain to pass resource admission tests, the bandwidth request can be reduced without changing the SENDER_TEMPLATE. Midpoint and egress routers MUST be able to handle either case. Now all we have to do is get this past one of the authors of this RFC who works for brand C. You can lead the battle from here. After all B and C are the ones who have to settle this. Curtis ps - no one could possibly guess who A, B, C, and U are. From owner-mpls@UU.NET Fri Nov 15 07:35:09 2002 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 ESMTP id HAA06694 for ; Fri, 15 Nov 2002 07:35:09 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpbu28790 for ; Fri, 15 Nov 2002 12:37:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpbu27683; Fri, 15 Nov 2002 12:37:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpbu29248 for mpls-outgoing; Fri, 15 Nov 2002 12:36:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpbu29241 for ; Fri, 15 Nov 2002 12:36: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 QQnpbu17669 for ; Fri, 15 Nov 2002 12:36:02 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpbu11137 for ; Fri, 15 Nov 2002 12:36:02 GMT Received: from cbibipnt08.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnpbu11104 for ; Fri, 15 Nov 2002 12:36:01 GMT Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Fri, 15 Nov 2002 12:36:05 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389E1C156@i2km07-ukbr.domain1.systemhost.net> To: jvasseur@cisco.com Cc: mpls@UU.NET Subject: RE: draft-vasseur-mpls-linknode-failure-00.txt Date: Fri, 15 Nov 2002 12:35:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jean Philippe, Some comments on your (well-written) draft: 1 Assumption of single failure. Understand the issue very well. However, this is only strictly controllable if one has a full layer view to, and including, the duct network (since all higher layer networks can mesh as much as they like but cannot increase the disjoint connectivity degree inherited from the duct layer). This implies the scope should be restricted to where this (commercial layer ownership issue) is true.....else attach health warnings. 2 Says this is section 2: "Typically a link down event does not tell to a PLR whether the link attached to its NHOP or its NHOP itself has failed." Well it would if proper OAM procedures are used on the server layer technology connecting the nodes. If we get a SDH L1 failure say you ought to be seeing an incoming Forward Defect Indicator (FDI) [aka AIS - Alarm Inhibition Signal] in the relevant VCs. This tells one the failure is *below* the MPLS layer in question and so is clearly a (server) layer/link failure and not a nodal failure. Moreover, it also tells you *not* to raise any alarms at the MPLS layers or indeed higher, eg PWE3 case....assuming the MPLS layers themselves are capable of relaying the FDI correctly. Else alarm storms (which can be organisationally disjoint and geographically widespead in the general case).....this is not a good thing to do to operators. G.805 describes the functional architecture that needs to be taken into account here. Note - In section 8 'Optimisation 1' does, I believe, refer to the above type scenario. However, this should not be considered an optimisation as it is the required default behaviour for the reasons noted above. 3 The basic premise of the proposal is to use a signalling protocol to test the connectivity status of an alternate data-plane path between 2 points, where the working path takes a different route between these 2 points. This is possible, but it is strictly not exercising the data-plane of the alternative path. Note also that the alternative path may or may not be required to become either fully or partially part of the the protection path....as explained in sections 6 and 7. I note in another ID from some of your colleagues (draft-nadeau-ip-basedtool-requirements-00.txt) it says this as a requirement (".....gathered from network operators in various workshops by the authors of this document."): " r) Separation of Data and Control Plane OAM. The inherent separation of control and data planes in MPLS lends itself to being sometimes implemented independently within an MPLS LSR. For example, in a multi-slot LSR, one slot may run a control process responsible for running MPLS control protocols such as LDP and RSVP, and then programming line cards residing in other slots to forward traffic accordingly. In doing so, the switch separates out the data plane from the control plane in such as way that it is possible for the line card to be mis-programmed whilst the control card is unaware. This leads to a potential for the line card to black hole data plane traffic. This is one example of why it is important for LSRs to possess functions that allow an operator to detect data plane liveliness. Data Plane liveliness MUST use the exact same path as data." I agree with the above. This requirement also appears in Y.1710, and effectively says that the traffic's data-plane connectivity verification should be independent of any control-plane protocol (routing or signalling), including case of none. Not only is this for the reasons stated above, but its is also to allow independent development of (data-plane and control-plane) protocols. Can you please comment on this apparent divergence of view? thanks and regards, Neil From owner-mpls@UU.NET Fri Nov 15 10:17:29 2002 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 ESMTP id KAA10197 for ; Fri, 15 Nov 2002 10:17:29 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcf25153 for ; Fri, 15 Nov 2002 15:20:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpcf23763; Fri, 15 Nov 2002 15:19:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpcf07341 for mpls-outgoing; Fri, 15 Nov 2002 15:18:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpcf07336 for ; Fri, 15 Nov 2002 15:18:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpcf20874 for ; Fri, 15 Nov 2002 15:18:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcf22380 for ; Fri, 15 Nov 2002 15:18:22 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnpcf22370 for ; Fri, 15 Nov 2002 15:18:22 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAFFI7524237; Fri, 15 Nov 2002 10:18:07 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 10:18:08 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C06150C69@zcard031.ca.nortel.com> From: "David Allan" To: "Michael H. Behringer" , jguichar@cisco.com Cc: mpls@UU.NET Subject: draft-behringer-mpls-security-03.txt Date: Fri, 15 Nov 2002 10:18:06 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Michael/Jim: If I understand the problem you are addressing correctly, it is incorrect configuration of the RT associated with a CE at the PE. And you wish to do this with no changes to the CE, therefore you are re-using the HMAC/MD5 stuff to achieve this. What you actually want is the RT configured at the CE and a means of checking that there is consistency between the CE and PE. IMHO adding a level of indirection (two provisioned values to get right at the PE) in the network will not achieve this. What I would suggest is that you keep the HMAC/MD5 approach for CE-PE, but have the key configured into the CE algorithmically derived from the RT associated with the VRF (or from the set of RTs in more complex configuration cases). Therefore there is still typically only one value to provision at the PE for the CE (the RT, which is the one that matters). You are not using multiple values across the core (HMAC MD5 and RTs, you only need RTs) so no BGP changes are required, this is purely a S/W issue at the PE. The only issue I can see is that in the more complex VPN cases (hub and spoke/extranet etc.), there is not one key for all CEs, (e.g. hub site is different key than a spoke site or extranet issues). This seems like a small price for no protocol changes and actually closing the hole. Besides I believe a CE can belong to more than one VPN therefore without this approach there is still a gaping head wound as it can only verify membership in one VPN. cheers Dave From owner-mpls@UU.NET Fri Nov 15 10:25:16 2002 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 ESMTP id KAA10391 for ; Fri, 15 Nov 2002 10:25:15 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcf27350 for ; Fri, 15 Nov 2002 15:27:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpcf25391; Fri, 15 Nov 2002 15:26:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpcf07948 for mpls-outgoing; Fri, 15 Nov 2002 15:26:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpcf07873 for ; Fri, 15 Nov 2002 15:26:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpcf11331 for ; Fri, 15 Nov 2002 15:25:26 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcf27927 for ; Fri, 15 Nov 2002 15:25:25 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpcf27913 for ; Fri, 15 Nov 2002 15:25:25 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA11946 for ; Fri, 15 Nov 2002 10:25:24 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAFFPO418891 for mpls@uu.net; Fri, 15 Nov 2002 10:25:24 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpcf07697 for ; Fri, 15 Nov 2002 15:24:27 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpcf04706 for ; Fri, 15 Nov 2002 15:23:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcf19466 for ; Fri, 15 Nov 2002 15:23:12 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: amsterdam.cisco.com [144.254.74.238]) id QQnpcf19428 for ; Fri, 15 Nov 2002 15:23:11 GMT Received: from MMORROW-W2K2.cisco.com (mmorrow-isdn-home.cisco.com [10.49.32.106]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA28220; Fri, 15 Nov 2002 16:23:02 +0100 (MET) Message-Id: <4.3.2.7.2.20021115161955.03b06ab0@amsterdam.cisco.com> X-Sender: mmorrow@amsterdam.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Nov 2002 16:23:01 +0100 To: "David Allan" From: Monique Morrow Subject: Re: draft-nadeau-ip-basedtool-requirements-01 Cc: "Thomas D. Nadeau" , swallow@cisco.com, mpls@UU.NET In-Reply-To: <9FBD322B7824D511B36900508BF93C9C05FE3F82@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dave, A belated "ack": "Interesting document.." I would hope so since the source of these requirements are service operators who in the process of implementing MPLS-based networks! Seriously, many thanks for your valuable comments -- we will integrate these into a next revision for clarity. Best regards, //Monique >Tom/Monique/George: > >Interesting document, a "few" comments though ;-) > >Section 2: >"Any error condition that prevents an LSR"....do you mean LSP here? > >Section 3: > >'a' this munges together detection and diagnosis. Shouldn't path liveliness >and path tracing be separated out as separate requirements. (They seem to be >synonymous in this document). > >'b' Are you inheriting all the requirements of the GTTP requirements >document by reference. There is a lot of stuff in there that is more generic >and may not be applicable. Is there a specific difference between tunnel >trace and path trace in this document? > >'c' The phrase "automation of path tracing..." are you really discussing >misbranching/mismerging detection. My read of this is that I am required to >periodically perform traceroute on LSPs. I doubt that is the actual intent. > >'d' [LSPPING] for CE to CE verification. Besides violating the >"non-prescriptive" claim in the introduction, I didn't think MPLS went CE to >CE ;-) The wording seems to confuse path tracing as a response to failure >detection, and the mechanism for failure detection as outlined in 'b'. Also >some requirements seem to do with the tools, and others with respect to box >behaviors (e.g. suggesting a nodal response to failure detection), it might >be cleaner simply to stick to what the tools should do, and let folks roll >up the system behaviors into applications themselves. > >'e' If I understood 'b' correctly, is this not the same thing? > >'f' Requirements 'f', 'l' and 'm' seem to be largely overlapping, although I >cannot actually parse 'l', and may be interested in latency for reasons >other than SLA. > >'g' what is a "device" in this context, and that it only "may" take >corrective action runs counter to the first sentence suggesting the network >MUST self-heal. The general requirement is rather high level. I've preferred >the wording that "the network detect faults, and may facilitate automated >response to restore service (e.g. via fault notification or whatever)". > >'h' Agree > >'i' What OAM functions are common to how both P2P and MP2P are instrumented? >Presumably one solution that meets the requirement is to overlay P2P on >MP2P.... > >'j' In general agree, with the proviso that some synchronization of tool >usage/frequency is required for availability metrics, e.g. the network needs >to function as a system and the OAM functions harmonized across the system. > >'k' The wording seems to undermine requirements 'h' and 'r'. IMHO this seems >to highlight one problem with instrumenting load balancing (as per ECMP >etc.) in general. The approach is that all paths need to be tested, the >specific implication is that they all need to be able to be tested from any >point. That I do not think is sustainable. If OAM probes are to follow the >same path as the user traffic, then ECMP should function independently of >both the OAM probes and the user traffic. Otherwise we're into the "monkeys >and typewriters" verification model as the OAM probes try various >permutations to impersonate user traffic's ECMP characteristics (which by >definition is proprietary and therefore unknowable to the probe origin). > >'l' See 'f'. > >'m' This one is not clear to me, and sort of suggests using bursts of OAM >packets to characterize LSP performance, a clarification please..? > >'n' The actual example is rather trivial as all the LSPs discussed terminate >in a single box. What is required is alarm suppression in all clients >regardless of where the client LSP, PW, VCC, VPC etc. terminates. > >'o' This seems othogonal to the other requirements, and seems relatively >hard not to satisfy. In other words, why is it here? > >'p' Seems prescriptive. IMHO detection of, and limitation of >damage/disruption done by DOS attacks is the requirement. "How" is for >another day. > >'q' OAM interworking for fault notification is only a part of the problem. >The client may be monitored, therefore timliness of this stuff matters as it >either needs to harmonize with the client OAM, or the client OAM needs to be >configured to "hold off" before reacting. Which also implies a requirement >for bounded detection times, which is one nit I have with current proposals >for instrumentation of ECMP and other load sharing mechanisms (one offshoot >being the "guidelines for load balancing" draft to be presented later on the >WG agenda). > >'r' This is a rather long winded way to say that "liveliness must test the >actual forwarding path (proxy verification of what systems "think" is >happening is insufficient)". > >And finally, nothing in the document leap out at me as justifying the title >(except perhaps the use of SNMP ;-) > >cheers >Dave > > From owner-mpls@UU.NET Fri Nov 15 12:55:31 2002 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 ESMTP id MAA13904 for ; Fri, 15 Nov 2002 12:55:31 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcp07969 for ; Fri, 15 Nov 2002 17:58:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpcp05874; Fri, 15 Nov 2002 17:56:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpcp25948 for mpls-outgoing; Fri, 15 Nov 2002 17:56:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpcp25922 for ; Fri, 15 Nov 2002 17:56:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpcp05560 for ; Fri, 15 Nov 2002 17:56:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcp13165 for ; Fri, 15 Nov 2002 17:56:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpcp13145 for ; Fri, 15 Nov 2002 17:56:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA24668 for ; Fri, 15 Nov 2002 12:56:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAFHu4e27172 for mpls@uu.net; Fri, 15 Nov 2002 12:56:04 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpcp25635 for ; Fri, 15 Nov 2002 17:54:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpcp28745 for ; Fri, 15 Nov 2002 17:53:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcp01106 for ; Fri, 15 Nov 2002 17:53:40 GMT Received: from coltrane.dataconnection.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.dataconnection.com [192.91.191.4]) id QQnpcp01081 for ; Fri, 15 Nov 2002 17:53:39 GMT Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 15 Nov 2002 17:53:25 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F817F2E2@baker.datcon.co.uk> From: Neil Jerram To: "'jcucchiara@mindspring.com'" Cc: "'mpls@uu.net'" , "'hans@ipunplugged.com'" , james_luciani@mindspring.com Subject: RE: Questions on LDP MIB v9 Date: Fri, 15 Nov 2002 17:53:23 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Joan, Thanks for responding to my questions. I'm afraid, though, that your answers don't resolve the issues that I raised under numbers 1, 2 and 4, as follows. 1. Unless I misunderstood, your answer didn't address the specific indexing problem that I raised. Here is a concrete example of the problem. LSR A and LSR B each distribute a label to each other, and by chance they use the same label value, 67. So in LSR A's mplsLdpLspTable, the label that A distributed to B has index: mplsLdpEntityLdpId AA AA AA AA 00 01 mplsLdpEntityIndex 1 mplsLdpPeerLdpId BB BB BB BB 00 01 mplsLdpLspIfIndex 1 mplsLdpLspLabel 67 The label that A received from B has index: mplsLdpEntityLdpId AA AA AA AA 00 01 mplsLdpEntityIndex 1 mplsLdpPeerLdpId BB BB BB BB 00 01 mplsLdpLspIfIndex 1 mplsLdpLspLabel 67 Which is exactly the same. So the mplsLdpLspTable can't hold represent both of these labels at once. 2. You noted the per-entity LabelRetentionMode field. However, as you say, this is not a per-label or per-LSP flag. Whether an LDP label is liberally retained or not is useful information for an administrator, and other well known interfaces provide this. So I repeat my suggestion that we should add a field to the appropriate per-label or per-LSP table in the LDP MIB to indicate whether each downstream label is liberally retained. 4. You ask whether the ifIndex would be different for different mappings. Unfortunately no, and that is the problem. The common scenario here is a non-merging LSR A that is the penultimate hop for an LSP. As it is non-merging, it sends a Label Request to the egress LSR B for every upstream label that it distributes or receives a request for. Because B knows that it is egress, it always sends back an implicit null Label Mapping. So LSR A and LSR B both have multiple Label Mappings, all on the same session and same interface (ifIndex), for the same FEC and with the same label value (3, implicit null). In LDP MIB up to v8, this is impossible to represent in both A's mplsLdpSessionOutLabelTable and B's mplsLdpSessionInLabelTable, because the (ifIndex, label) pairs for all labels are the same. In LDP MIB v9, it is impossible on B for the same reason: all the labels have the same session, ifIndex and label. (It's actually OK on A, but in a rather bizarre way that I doubt you intended: the mplsLdpLspTable entries for the downstream labels on A can be indexed by the session, ifIndex and label for the _upstream labels_ to which they are connected, which must be unique.) Based on these real problems, and having studied the motivations behind the revisions from v8 to v9, I'd like to propose replacing mplsLdpLspTable and mplsLdpLspFecTable with 2 new tables that solve the problems. (If the goal was to minimize the changes with respect to v9, you could also solve the problems by adding two new index fields to the mplsLdpLspTable and mplsLdpLspFecTable: an upstream/downstream flag and (for problem 1) and an arbitrary tie-breaker index (for problem 4). Plus of course the new liberally retained field for problem 2. However, I believe that the tables proposed below also present LDP's label binding information more naturally than those in v9.) I apologise that this proposal comes late in the lifetime of the LDP MIB. On the other hand, I couldn't find any substantial previous discussion of these tables in the archive, so as far as I know this isn't stepping on anyone else's toes. (Please correct me if that's wrong!) Key points of my proposal are as follows. - The new tables are: - mplsLdpUpLabelTable, describing labels distributed to upstream peers - mplsLdpDownLabelTable, describing labels received from downstream peers, including liberally retained and null labels. - Like the tables that they replace in LDP MIB v9, these tables use RowPointers to point to LIB information in the LSR MIB. They don't unnecessarily duplicate any information that can be obtained from the LSR MIB. - Advantages in comparison with LDB MIB v9 are that: - mplsLdpDownLabelTable can show both established and liberally retained labels, and has a flag to indicate which labels are which - mplsLdpDownLabelTable can show multiple label mappings received from the same peer, for the same FEC, and with the same label value (this is most relevant for implicit and explicit null labels, but can also occur in some networks with non-null label values) - mplsLdpUpLabelTable and mplsLdpDownLabelTable can show a distributed label and a received label that share the same session, FEC and label value. - mplsLdpUpLabelTable has a RowPointer to an mplsLdpDownLabelTable entry that can be used to show how upstream and downstream mappings are connected. The full ASN.1 and a note on indexing are appended below. Thank you very much for your time. Neil Indexing ======== The tables are indexed by (LDP session, FEC index, LSP index), where: - LDP session is the usual (entity ldp id, entity index, peer ldp id) - FEC index is a non-predictable index into the mplsFecTable - LSP index is a non-predictable tie-breaker index for non-merging LSPs for the same FEC. The key benefit of this indexing is that it permits the representation, for non-merging FECs, of the labels established by multiple Label Request - Label Mapping exchanges through an LSR, even when the labels distributed for different Label Requests are the same (usually implicit and explicit nulls). ASN.1 ===== -- -- The MPLS LDP Upstream Label Table -- mplsLdpUpLabelTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpUpLabelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table mapping LDP sessions and FECs to the upstream labels distributed for those sessions and FECs, and to the corresponding LIB entries in the LSR MIB." ::= { mplsLdpSessionObjects 6 } mplsLdpUpLabelEntry OBJECT-TYPE SYNTAX MplsLdpUpLabelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a label that has been distributed upstream for a particular session and FEC combination. It is indexed by the session's index triple (mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId), the FEC index (mplsFecIndex) and an LSP index (mplsLdpLspIndex) that distinguishes between non-merging LSPs for the same FEC. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsFecIndex, mplsLdpLspIndex } ::= { mplsLdpUpLabelTable 1 } MplsLdpUpLabelEntry ::= SEQUENCE { mplsLdpUpLabel MplsLabel, mplsLdpUpLabelType MplsLdpLabelType, mplsLdpUpLspType MplsLspType, mplsLdpUpDownLabelPointer RowPointer, mplsLdpUpLsrInSegmentPointer RowPointer, mplsLdpUpLsrXCPointer RowPointer } mplsLdpLspIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A tie-breaker index that distinguishes between multiple non-merging LSPs for the same FEC. Where an LSR merges all LSPs for the same FEC, this field is not needed and should always be zero. Where an LSR does not merge LSPs for the same FEC, it is possible for the LSR to distribute (or receive) multiple label mappings for the same FEC to (or from) the same session, and for some of these labels to be equal (in particular where implicit and explicit null labels are in use). In this case, the entries that describe the labels are distinguished from each other by using a different, non-zero value for this index field." ::= { mplsLdpUpLabelEntry 1 } mplsLdpUpLabel OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The upstream label value." ::= { mplsLdpUpLabelEntry 2 } mplsLdpUpLabelType OBJECT-TYPE SYNTAX MplsLdpLabelType MAX-ACCESS read-only STATUS current DESCRIPTION "The Layer 2 upstream label type." ::= { mplsLdpUpLabelEntry 3 } mplsLdpUpLspType OBJECT-TYPE SYNTAX MplsLspType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of LSP connection for which this label is in use. The possible values are: unknown(1) -- if the LSP is not known to be one of the following. terminatingLsp(2) -- if the LSP terminates on the LSR, then this is an ingressing LSP which ends on the LSR, originatingLsp(3) -- if the LSP originates from the LSR, then this is an egressing LSP which is the head-end of the LSP, crossConnectingLsp(4) -- if the LSP ingresses and egresses on the LSR, then it is cross-connecting on that LSR." ::= { mplsLdpUpLabelEntry 4 } mplsLdpUpDownLabelPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If this label is cross-connected to a received LDP downstream label mapping, this RowPointer should point to the entry in the mplsLdpDownLabelTable that describes the downstream label. Otherwise this field's value is zeroDotzero." ::= { mplsLdpUpLabelEntry 5 } mplsLdpUpLsrInSegmentPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If this label has a corresponding entry in the LSR MIB mplsInSegmentTable, this RowPointer should point to that entry. Otherwise this field's value is zeroDotzero." ::= { mplsLdpUpLabelEntry 6 } mplsLdpUpLsrXCPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If this label is cross-connected to a received LDP downstream label mapping and there is an entry describing this cross-connect in the LSR MIB mplsXCTable, this RowPointer should point to that entry. Otherwise this field's value is zeroDotzero." ::= { mplsLdpUpLabelEntry 7 } -- -- The MPLS LDP Downstream Label Table -- mplsLdpDownLabelTable OBJECT-TYPE SYNTAX SEQUENCE OF MplsLdpDownLabelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table mapping LDP sessions and FECs to the downstream labels received for those sessions and FECs, and to the corresponding LIB entries in the LSR MIB." ::= { mplsLdpSessionObjects 6 } mplsLdpDownLabelEntry OBJECT-TYPE SYNTAX MplsLdpDownLabelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table represents a label that has been received from a downstream peer for a particular session and FEC combination. It is indexed by the session's index triple (mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId), the FEC index (mplsFecIndex) and an LSP index (mplsLdpLspIndex) that distinguishes between non-merging LSPs for the same FEC. The information contained in a row is read-only." INDEX { mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsFecIndex, mplsLdpLspIndex } ::= { mplsLdpDownLabelTable 1 } MplsLdpDownLabelEntry ::= SEQUENCE { mplsLdpDownLabel MplsLabel, mplsLdpDownLabelType MplsLdpLabelType, mplsLdpDownLspType MplsLspType, mplsLdpDownLiberal TruthValue, mplsLdpDownLsrOutSegmentPointer RowPointer, mplsLdpDownLsrXCPointer RowPointer } mplsLdpDownLabel OBJECT-TYPE SYNTAX MplsLabel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The downstream label value." ::= { mplsLdpDownLabelEntry 1 } mplsLdpDownLabelType OBJECT-TYPE SYNTAX MplsLdpLabelType MAX-ACCESS read-only STATUS current DESCRIPTION "The Layer 2 downstream label type." ::= { mplsLdpDownLabelEntry 2 } mplsLdpDownLspType OBJECT-TYPE SYNTAX MplsLspType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of LSP connection for which this label is in use. The possible values are: unknown(1) -- if the LSP is not known to be one of the following. terminatingLsp(2) -- if the LSP terminates on the LSR, then this is an ingressing LSP which ends on the LSR, originatingLsp(3) -- if the LSP originates from the LSR, then this is an egressing LSP which is the head-end of the LSP, crossConnectingLsp(4) -- if the LSP ingresses and egresses on the LSR, then it is cross-connecting on that LSR." ::= { mplsLdpDownLabelEntry 3 } mplsLdpDownLiberal OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Whether this is a liberally retained downstream label." DEFVAL { false } ::= { mplsLdpDownLabelEntry 4 } mplsLdpDownLsrOutSegmentPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If this label has a corresponding entry in the LSR MIB mplsOutSegmentTable, this RowPointer should point to that entry. Otherwise this field's value is zeroDotzero." ::= { mplsLdpDownLabelEntry 5 } mplsLdpDownLsrXCPointer OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "If this label is cross-connected to a distributed LDP upstream label mapping and there is an entry describing this cross-connect in the LSR MIB mplsXCTable, this RowPointer should point to that entry. Otherwise this field's value is zeroDotzero." ::= { mplsLdpDownLabelEntry 6 } -----Original Message----- From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] Sent: 02 November 2002 15:44 To: Neil Jerram; 'hans@ipunplugged.com'; jcucchiara@mindspring.com; james_luciani@mindspring.com Cc: 'mpls@uu.net' Subject: Re: Questions on LDP MIB v9 Hi Neil, At 03:32 PM 10/30/02 -0000, Neil Jerram wrote: >>>> The latest LDP MIB draft looks generally good, but I see three problems with the new mplsLdpLspTable, which could be genuine, or could indicate misunderstanding on my part -- so I would appreciate your thoughts on them. I also have one question. 1. It isn't possible to represent an egress or transit LSP (A) at the same time as an ingress LSP (B), if LSP A's incoming (interface, label) are the same as LSP B's outgoing (interface, label), because the index in both cases is the same: (i1, l1). The old XCMapTable could represent both at the same time, using indices (i1, l1, 0, 0) or (i1, l1, i2, l2) for LSP A and (0, 0, i1, l1) for LSP B. <<<< I agree that the XCMap Table was a little bit nicer because it gave the Lib IN and LIB Out info as part of the index (which could possibly help in LIB lookups). However, this is also duplicated information because it exists in the LSR-MIB's XCTable. One of the primary concerns from the IESG review was to reduce the number of objects in the LDP MIB because it is such a huge MIB. All 3 of the Mapping tables were collapsed into this one table which simply lists the LSPs (by IfIndex, Label) within each Session (represented by mplsLdpEntityLdpId, mplsLdpEntityIndex, and mplsLdpPeerLdpId). The Mapping to the LSR MIB is done by using Row Pointers. So, this increases the burden on the agent to now retrieve the info from the LSR MIB to get label in/out indices. The mplsLdpLspType was added to give a hint as to the type of LSP, terminating, originating or XC, so that the appropriate RowPointer could be retrieved. >>>> 2. There is no mplsLdpLspType value to indicate a liberally retained label. <<<< This is a configurable option for the Entity, mplsLdpEntityLabelRetentionMode. So although it is true that it is not defined on a per Lsp basis, it is defined for the session. >>>> 3. In the description mplsLdpLspType, your uses of "ingress" and "egress" (as verbs describing the LSP's relationship to the LSR) are exactly opposite to the conventional usage (which describes a data packet's relationship to an LSP). This could be rather confusing! <<<< I agree! Will be fixed in the TC MIB's description and LDP MIB's description. >>>> 4. Do you expect implicit and explicit null labels to appear in this table, and, if so, how? The point is that implicit and explicit null labels can be distributed multiple times for different FECs in the same session, and it isn't clear in this case how the MIB indexing will work. <<<< Good question. Would the ifIndex be different in this case? The goal would be to have this table be able to list all LDP LSPs uniquely and then have pointers to their counter-parts in the LSR-MIB's InSegment/OutSegment/XC tables. Thanks for your questions, -Joan >>>> Best regards, Neil Neil Jerram Network Protocols Group Data Connection Ltd. www.dataconnection.com <<<< From owner-mpls@UU.NET Fri Nov 15 13:24:51 2002 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 ESMTP id NAA14778 for ; Fri, 15 Nov 2002 13:24:50 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcr05685 for ; Fri, 15 Nov 2002 18:27:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpcr01337; Fri, 15 Nov 2002 18:25:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpcr16641 for mpls-outgoing; Fri, 15 Nov 2002 18:24:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpcr16625 for ; Fri, 15 Nov 2002 18:24:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpcr28548 for ; Fri, 15 Nov 2002 18:24:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcr08141 for ; Fri, 15 Nov 2002 18:24:30 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpcr08132 for ; Fri, 15 Nov 2002 18:24:30 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA27279 for ; Fri, 15 Nov 2002 13:24:30 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAFIOTf29455 for mpls@uu.net; Fri, 15 Nov 2002 13:24:29 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpcd17085 for ; Fri, 15 Nov 2002 14:57:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpcd19139 for ; Fri, 15 Nov 2002 14:57:13 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpcd09487 for ; Fri, 15 Nov 2002 14:57:12 GMT Received: from web21203.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21203.mail.yahoo.com [216.136.130.22]) id QQnpcd09477 for ; Fri, 15 Nov 2002 14:57:12 GMT Message-ID: <20021115145711.92034.qmail@web21203.mail.yahoo.com> Received: from [47.234.0.52] by web21203.mail.yahoo.com via HTTP; Fri, 15 Nov 2002 06:57:11 PST Date: Fri, 15 Nov 2002 06:57:11 -0800 (PST) From: Rajesh Potti Subject: BGP - 2547 VPNS To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, In BGP for 2547 VPNs, can a VPN-IPv4 route be send with a set of route targets and then a withdraw with only a subset of the route targets. This will be a partial withdraw. How does a router handle a partial withdraw? If the route is removed from only the vpns in which there is an import Route target match, future updates for the route with a set of route targets will result in inconsistencies. Thanks, Rajesh __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com From owner-mpls@UU.NET Fri Nov 15 21:55:28 2002 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 ESMTP id VAA28429 for ; Fri, 15 Nov 2002 21:55:28 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpdz09539 for ; Sat, 16 Nov 2002 02:58:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpdz08098; Sat, 16 Nov 2002 02:57:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpdz23558 for mpls-outgoing; Sat, 16 Nov 2002 02:56:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpdz23550 for ; Sat, 16 Nov 2002 02:56:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpdz03114 for ; Sat, 16 Nov 2002 02:55:58 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpdz03941 for ; Sat, 16 Nov 2002 02:55:57 GMT Received: from kcmso2.proxy.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQnpdz03928 for ; Sat, 16 Nov 2002 02:55:57 GMT Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id gAG2g7hd011017 for ; Fri, 15 Nov 2002 20:55:57 -0600 (CST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3D8B56050140EB8F for mpls@uu.net; Fri, 15 Nov 2002 21:55:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: LDP-MIB Enhancement for Performance Management Date: Fri, 15 Nov 2002 21:55:56 -0500 Message-ID: <28F05913385EAC43AF019413F674A017044A33AF@OCCLUST04EVS1.ugd.att.com> Thread-Topic: LDP-MIB Enhancement for Performance Management Thread-Index: AcKNG9++XQAzxvjiEdaXAERFU1QAAA== From: "Lai, Wai S (Waisum), ALASO" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA28429 There is currently no object in the LDP-MIB to provide necessary counters for both the Generic Label Space Entities and the Per-Interface Label Space Entities. To support LDP entity and session statistics reports for MPLS performance management, we propose the following enhancement to the LDP-MIB. Specifically, we propose the addition of the following new objects to provide summary statistics on the health of LDP entities and sessions to capture the usage/performance of LDP sessions: . Generic Label Space Entity Attempted Counter . Generic Label Space Entity Established Counter . Generic Label Space Entity Disabled Counter · Per-Interface Label Space Entity Attempted Counter · Per-Interface Label Space Entity Established Counter · Per-Interface Label Space Entity Disabled Counter · Generic Label Space Session Attempted Counter · Generic Label Space Session Established Counter · Generic Label Space Session Disabled Counter · Per-Interface Label Space Session Attempted Counter · Per-Interface Label Space Session Established Counter · Per-Interface Label Space Session Disabled Counter In addition, these objects should provide an index to map this LDP entity with associated IfIndex in the IF-MIB. In the above set of counters, (1) The Attempted Counter indicates the specific number of attempts made to establish the LDP entity between two peers where the corresponding label space entity/session would be created, whether those attempts are successful or not. (2) The Established Counter indicates the specific number of successful attempts made to establish the LDP entity between two peers where the corresponding label space entity/session is created. (3) The Disabled Counter indicates the specific number of LDP entities disabled between two peers where the the corresponding label space entity/session were used. Each of the above is a running counter that is only re-initialized when LDP session is re-initialized. These counters will provide a high-level barometer of performance of LDP entity/sessions. Without such variables, elaborate NMS-based processing and extensive MIB walks of the LDP-MIB are required, thus consuming valuable network and NMS resources. Your comments on the above proposal are solicited. Thanks, Wai Sum From owner-mpls@UU.NET Sun Nov 17 03:39:31 2002 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 ESMTP id DAA15056 for ; Sun, 17 Nov 2002 03:39:31 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpio14412 for ; Sun, 17 Nov 2002 08:41:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpio11170; Sun, 17 Nov 2002 08:39:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpio16876 for mpls-outgoing; Sun, 17 Nov 2002 08:39:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpio16860 for ; Sun, 17 Nov 2002 08:39: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 QQnpio12077 for ; Sun, 17 Nov 2002 08:39:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpio10472 for ; Sun, 17 Nov 2002 08:39:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpio10468 for ; Sun, 17 Nov 2002 08:39:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA03854 for ; Sun, 17 Nov 2002 03:39:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAH8d5M12992 for mpls@uu.net; Sun, 17 Nov 2002 03:39:05 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpio16819 for ; Sun, 17 Nov 2002 08:38:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpio16580 for ; Sun, 17 Nov 2002 08:37:01 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpio09392 for ; Sun, 17 Nov 2002 08:37:01 GMT Received: from dvlfn by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [200.174.69.242]) id QQnpio09347 for ; Sun, 17 Nov 2002 08:36:54 GMT From: Wallace Buckman To: Subject: mpls, Don't Miss This Stock Date: Sat, 16 Nov 2002 17:34:30 -0800 Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Message-Id: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: base64 PGh0bWw+DQo8Ym9keT4NCjxjZW50ZXI+DQogIDxiPjxmb250IHNpemU9IisyIiBjb2xvcj0i I0ZGMDAzMyI+QnJlYWtpbmcgTWFya2V0IE5ld3M8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIj RkYwMDMzIj48YnI+DQogIDxiPkFsZXJ0aW5nIFRyYWRlcnMgdG8gT3Zlcmxvb2tlZCAmYW1w OyBVbmRlcnZhbHVlZCBTdG9ja3M8L2I+PGJyPg0KICA8Yj5JbnRlcmFjdGl2ZSBNdWx0aW1l ZGlhIE5ldHdvcmsgSW5jPC9iPjwvZm9udD4gDQo8L2NlbnRlcj4NCjxmb250IHNpemU9LTI+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTwvZm9udD48YnI+DQo8Zm9udCBzaXplPSItMSI+QXMgdGhlIG1hcmtldCB1 bmRlcmdvZXMgZXh0cmVtZSBmbHVjdHVhdGlvbnMgYW5kIHR1cmJ1bGVuY2UsIGZ1bmQgDQpt YW5hZ2VycyBhbmQgbW9uZXkgbWFuYWdlcnMgYXJlIHJhcGlkbHkgc2Vla2luZyBhbHRlcm5h dGl2ZSBpbnZlc3RtZW50cyBTbWFsbCANCnRvIE1pZC1DYXAgY29tcGFuaWVzIGFyZSByYXBp ZGx5IGJlY29taW5nIHRoZSBpbnZlc3RtZW50IG9mJm5ic3A7IHNwZWN1bGF0aXZlIA0KcG9y dGZvbGlvcyBhbmQgaGVkZ2UgZnVuZHMgYXMgdGhleSByZXByZXNlbnQgdGhlIGdyZWF0ZXN0 IG9wcG9ydHVuaXR5IGZvciBhcHByZWNpYXRpb24gDQphbmQmbmJzcDsgZ3Jvd3RoIGluIHRv ZGF5knMgdm9sYXRpbGUgdGltZXMuIFdoYXQgZG9lcyB0aGlzIG1lYW4/PC9mb250PiANCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdCI+SXQg bWVhbnMgTk9XIGlzIHRoZSB0aW1lIA0KICB0byBwb3NpdGlvbiB5b3VyIHBvcnRmb2xpbyB3 aXRoIFVOREVSVkFMVUVEIGNvbXBhbmllcyBhbmQgQ0FQSVRBTElaRSBvbiB0aGUgDQogIG5l dyCTQnVsbJQgbWFya2V0LiZuYnNwOyBBcyBzdWNoPC9zcGFuPjxicj4NCiAgPGZvbnQgc2l6 ZT0tMT4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvZm9udD48YnI+DQogIDxicj4NCiAgPGI+PGZvbnQgc2l6ZT0iMiI+ U3ltYm9sJm5ic3A7IE9UQ0JCOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9m aW5hbmNlLnlhaG9vLmNvbS9xP3M9SU1OSS5PQiI+SU1OSTwvYT48L2ZvbnQ+PC9iPjxmb250 IHNpemU9IjIiPjxicj4NCiAgU2hhcmVzIG91dHN0YW5kaW5nJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDgsMzQwLDk2NDxicj4NCiAg RmxvYXQgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAmbmJzcDsmbmJzcDsgMiw1MDAs MDAwIHNoYXJlczxicj4NCiAgUmF0aW5nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIDEwPGJyPg0KICBDdXJyZW50IFByaWNlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAkMC4yNjxicj4N CiAgNTIgd2VlayBoaWdoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAkMC40NjwvZm9udD48L3A+DQo8cD48 Yj5Db3Jwb3JhdGUgU25hcHNob3Q8L2I+PGJyPg0KICA8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMC4wcHQiPk9UQ0JCOiZuYnNwOyA8YSBocmVmPSJodHRwOi8vZmluYW5jZS55YWhvby5j b20vcT9zPUlNTkkuT0IiPklNTkk8L2E+IA0KICBpcyBhIGdlbnVpbmUgaG9sZGluZ3MgY29t cGFueSBhbGxvY2F0aW5nIGl0cyByZXNvdXJjZXMgdG8gZmlsbCB2YXJpb3VzIG5lZWRzIA0K ICCWIHJhbmdpbmcgZnJvbSBIZWF0aCBDYXJlIHRvIEV5ZSBDYXJlIHRvIEFpcnBvcnQgU2Vj dXJpdHkuJm5ic3A7IEhlYWx0aCBDYXJlIA0KICBhbmQgRXllIENhcmUgY29tcGFuaWVzIGhh dmUgcmVjb2duaXplZCBkZW1hbmRzLCB3aGljaCBJTU5JIGlzIHN0cml2aW5nIHRvIGZ1bGZp bGwuIA0KICBJbiBhZGRpdGlvbiwgSU1OSSBpcyBhbHNvIGludHJvZHVjaW5nIGEgY29tcGxl dGUgYW5kIHRvdGFsIEFpcnBvcnQgU2VjdXJpdHkgDQogIFN5c3RlbSwgdGhlIEdsb2JhbCBQ Lk8uTS4sIHdoaWNoIHNlYW1sZXNzbHkgY29ubmVjdHMgZGF0YSwgcGVvcGxlIGFuZCB0aGVp ciANCiAgYmVsb25naW5ncyBpbnNpZGUsIG91dHNpZGUsIGFuZCB0aHJvdWdob3V0IHRoZSBh aXJwb3J0LiZuYnNwOyBQZWFjZSBvZiBNaW5kLCANCiAgU2VjdXJpdHksIGFuZCBXZWxsbmVz cyB3cmFwcGVkIHVwIGludG8gb25lIHRvdGFsIHBhY2thZ2UuPC9zcGFuPiANCjxwPiA8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQiPjxhIGhyZWY9Imh0dHA6Ly9maW5hbmNlLnlh aG9vLmNvbS9xP3M9SU1OSS5PQiI+SU1OSTwvYT4gDQogIGlzIGRlZGljYXRlZCB0byBpbnRy b2R1Y2luZyBmaXJzdC10by1tYXJrZXQgaGVhbHRoIGFuZCB3ZWxsbmVzcyBwcm9kdWN0cywg cHJvdmlkaW5nIA0KICB1bmlxdWUgbWFuYWdlbWVudCBhbmQgbWFya2V0aW5nIG1ldGhvZHMg dG8gZGV2ZWxvcCwgbWFya2V0IGFuZCBzZWxsIHByb2R1Y3RzIA0KICB0byBjb25zdW1lciBh bmQgYnVzaW5lc3MgY2xpZW50cyB3aG8gaGF2ZSBiZWVuIGVkdWNhdGVkIGFib3V0IGl0cyBw cm9kdWN0cy48L3NwYW4+IA0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IDxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjBwdCI+VGhlIENvbXBhbnkgaGFzIHR3byBvcGVyYXRpbmcgDQogIHN1 YnNpZGlhcmllczogQmVzdCBIZWFsdGgsIEluYy4gYW5kIFNveVNsaW0sIEluYy4mbmJzcDsg Qm90aCBhcmUgZm9jdXNlZCBzcGVjaWZpY2FsbHkgDQogIG9uIHRoZSBkZXZlbG9wbWVudCwg bWFudWZhY3R1cmluZyBhbmQgbWFya2V0aW5nIG9mIGhlYWx0aCBhbmQgd2VsbG5lc3Mgb3Jp ZW50ZWQgDQogIGNvbnN1bWVyIHByb2R1Y3RzLiZuYnNwOyBFYWNoIGFkZHJlc3NlcyBuaWNo ZSBtYXJrZXRzIHRoYXQgYXJlIG9mIHBhcnRpY3VsYXIgDQogIGludGVyZXN0IHRvIHRoZSBs YXJnZXN0IHNpbmdsZSBtYXJrZXQgZGVtb2dyYXBoaWM7IHRoZSCTYmFieSBib29tZXKUIGdl bmVyYXRpb24uJm5ic3A7IA0KICBUaGUgY29tcGFueSBmb2N1c2VzIGl0cyBhdHRlbnRpb24g b24gbWFya2V0aW5nIGhlYWx0aCBhbmQgd2VsbG5lc3MgY29uc3VtZXIgDQogIHByb2R1Y3Rz IHRvIHRoaXMgYWZmbHVlbnQgZGVtb2dyYXBoaWMgbWFya2V0LiZuYnNwOyA8L3NwYW4+PC9w Pg0KPHA+PGZvbnQgc2l6ZT0tMT5TbyB3aGF0IG1ha2VzIHRoZSBwcm9kdWN0IHNvIGRlc2ly YWJsZT8gRW5oYW5jZWQgVHJhbnNhY3Rpb25hbCANCiAgU2VjdXJlIFNvZnR3YXJlICgiRVRT UyIpIGlzIGEgcHJvcHJpZXRhcnkgc29mdHdhcmUgcGFja2FnZSZuYnNwOyB0aGF0IGVtcG93 ZXJzIA0KICBjb25zdW1lcnMgdG8gYWNjb21wbGlzaCBzZWN1cmUgZS1jb21tZXJjZSB0cmFu c2FjdGlvbnMgb24gdGhlIGludGVybmV0IHVzaW5nIA0KICBjcmVkaXQsIGRlYml0IEFUTSwo d2l0aCBwaW4pIG9yIHNtYXJ0IGNhcmRzLiBUaGUgRVRUUyBzeXN0ZW0gaW50ZWdyYXRlcyBh IGNvbnN1bWVyLXNpZGUgDQogIGNhcmQtc3dpcGUgdGVybWluYWwgd2l0aCBhIGJhY2stZW5k IGhvc3QgcHJvY2Vzc2luZyBjZW50ZXIuPC9mb250PiANCjxwPjxiPldlIGhhdmUgR2l2ZW4g PGEgaHJlZj0iaHR0cDovL2ZpbmFuY2UueWFob28uY29tL3E/cz1JTU5JLk9CIj5JTU5JPC9h PiBvdXIgDQogIGhpZ2hlc3QgcmF0aW5nIGEgQklHIDEwIEZvciB0aGUgZm9sbG93aW5nIHJl YXNvbnM6PC9iPjxicj4NCiAgPGI+PHU+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBw dCI+TWFya2V0IFBvdGVudGlhbDwvc3Bhbj48L3U+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwLjBwdCI+Jm5ic3A7Jm5ic3A7IA0KICA8c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNr Ij5XaXRoaW4gdGhlIGhlYWx0aCAmYW1wOyB3ZWxsbmVzcyBtYXJrZXQgYWxvbmUsIGNvbnN1 bWVycyANCiAgc3BlbmQgb3ZlciA8Yj4kMTg0IGJpbGxpb24gZG9sbGFyczwvYj4gaW4gd2Vp Z2h0IGxvc3MgYW5kIG51dHJpdGlvbmFsIHN1cHBsZW1lbnRzIA0KICBhbm51YWxseSB3aGls ZSBzcGVuZGluZyA8Yj4kMi4yIGJpbGxpb248L2I+PC9zcGFuPjxiPiBkb2xsYXJzPC9iPiBm b3IgbGVuc2VzIA0KICBhbmQgY2FyZSBwcm9kdWN0cy4mbmJzcDsgQWNoaWV2aW5nIGp1c3Qg YSBzbGlnaHQgcGVyY2VudGFnZSBvZiB0aGUgbWFya2V0IHNoYXJlIA0KICBjYW4gcG90ZW50 aWFsbHkgZ2VuZXJhdGUgc2V2ZXJhbCBtaWxsaW9uIGRvbGxhcnMgZm9yIElNTkkuPC9zcGFu PiANCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC4wcHQiPjxhIGhyZWY9Imh0dHA6Ly9maW5hbmNlLnlhaG9vLmNvbS9xP3M9SU1OSS5PQiI+ SU1OSTwvYT48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdCI+IA0K ICBpcyBpbiBhIG1hcmtldCB3aXRoIGEgc3Ryb25nIGRlbWFuZCBmb3IgaXRzIHByb2R1Y3Qg liBoZW5jZSBjb250aW51b3VzIHJldmVudWUgDQogIGFuZCBpbmNvbWU8Yj4uIDwvYj48L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0Ij5JTU5JPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQiPiANCiAgaGFzIGFuIGV4Y2VsbGVudCBz aGFyZSBzdHJ1Y3R1cmUgZm9yIG1heGltdW0gYXBwcmVjaWF0aW9uLiZuYnNwOyBXaXRoIHN1 Y2ggYSANCiAgbG93IGZsb2F0LCBhbmQgdGlnaHQgc2hhcmUgc3RydWN0dXJlLCBhbnkgc2ln bmlmaWNhbnQgdm9sdW1lIHdpbGwgcmVzdWx0IGluIA0KICBvbmUgb3V0Y29tZSCWIEFQUFJF Q0lBVElPTiBhbmQgR0FJTlMuPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjBwdDsgZm9udC1mYW1pbHk6IFRpbWVzIE5ldyBSb21hbiI+IA0KICBJTU5JPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7IGZvbnQtZmFtaWx5OiBUaW1lcyBO ZXcgUm9tYW4iPiANCiAgaXMgc2Vla2luZyB0byBleHBhbmQgdGhlaXIgb25saW5lIHByZXNl bmNlIHRocm91Z2ggcHJvZHVjdCBwbGFjZW1lbnQgb24gbXVsdGlwbGUgDQogIG9ubGluZSBy ZXRhaWxlcnM8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0OyBmb250 LWZhbWlseTogVGltZXMgTmV3IFJvbWFuIj4gDQogIElNTkkgPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7IGZvbnQtZmFtaWx5OiBUaW1lcyBOZXcgUm9tYW4i PiANCiAgaGFzIGEgc3Vic3RhbnRpYWwgb3Bwb3J0dW5pdHkgaW4gdGhlIHdvcmxkknMgY29u dGFjdCBtYXJrZXQuJm5ic3A7IFRoZSBvdmVyYWxsIA0KICBtYXJrZXQgZm9yIGNvbnRhY3Qg bGVucyByZWxhdGVkIHByb2R1Y3RzIGlzIGdyb3dpbmcgYXQgYSByYXRlIG9mIDEwJSBwZXIg eWVhci4gDQogIEFzIHByb2plY3RlZCBieSBCYXVzY2ggJmFtcDsgTG9tYiwgdGhlIFVTIG1h cmtldCBmb3IgcmVwbGFjZW1lbnQgY29udGFjdCBsZW5zZXMgDQogIGFuZCBjb250YWN0IGxl bnMgY2FyZSBwcm9kdWN0cyB0b3RhbGVkIDxiPiQyLjIgQmlsbGlvbiBkb2xsYXJzPC9iPiBh dCB0aGUgeWVhci1lbmQgDQogIDIwMDAuJm5ic3A7IFRoZSBtYXJrZXQgZm9yIHNvZnQsIGdh cyBwZXJtZWFibGUgYW5kIFBNTUEgKGhhcmQpIGNvbnRhY3QgbGVucyANCiAgcmVwbGFjZW1l bnRzIGlzIGFwcHJveGltYXRlbHkgPGI+JDEuMyBCaWxsaW9uIGRvbGxhcnM8L2I+IGFuZCBm b3IgbGVucyBjYXJlIA0KICBwcm9kdWN0cyBpdCBpcyBlc3RpbWF0ZWQgdG8gYmUgOTAwIE1p bGxpb24gZG9sbGFycy4gVGhlIGxlbnMgY2FyZSBtYXJrZXQgY29uc2lzdHMgDQogIG9mIGNs ZWFuaW5nLCByaW5zaW5nLCBkaXNpbmZlY3RpbmcsJm5ic3A7IHN0b3JpbmcsIGFuZCBsdWJy aWNhdGluZyBzb2x1dGlvbnMgDQogIGZvciBjb250YWN0IGxlbnNlczwvc3Bhbj48L3A+DQo8 cD48YnI+DQogICZuYnNwOzxicj4NCiAgJm5ic3A7PGJyPg0KICAmbmJzcDs8YnI+DQogICZu YnNwOzxicj4NCiAgJm5ic3A7PGJyPg0KICAmbmJzcDs8YnI+DQogICZuYnNwOzxicj4NCiAg Jm5ic3A7PGJyPg0KICAmbmJzcDs8YnI+DQogICZuYnNwOzxicj4NCiAgJm5ic3A7IA0KPHA+ PGk+PGZvbnQgc2l6ZT0tMj5UaGUgaW5mb3JtYXRpb24sIG9waW5pb25zIGFuZCBhbmFseXNp cyBjb250YWluZWQgaGVyZWluIGFyZSANCiAgYmFzZWQgb24gc291cmNlcyBiZWxpZXZlZCB0 byBiZSByZWxpYWJsZSBidXQgbm8gcmVwcmVzZW50YXRpb24sIGV4cHJlc3NlZCBvciANCiAg aW1wbGllZCwgaXMgbWFkZSBhcyB0byBpdHMgYWNjdXJhY3ksIGNvbXBsZXRlbmVzcyBvciBj b3JyZWN0bmVzcy4mbmJzcDsgUGFzdCANCiAgcGVyZm9ybWFuY2UgaXMgbm8gZ3VhcmFudGVl IG9mIGZ1dHVyZSByZXN1bHRzLiBUaGlzIHJlcG9ydCBpcyBmb3IgaW5mb3JtYXRpb24gDQog IHB1cnBvc2VzIG9ubHkgYW5kIHNob3VsZCBub3QgYmUgdXNlZCBhcyB0aGUgYmFzaXMgZm9y IGFueSBpbnZlc3RtZW50IGRlY2lzaW9uLiANCiAgQ1dJJm5ic3A7IGhhcyBiZWVuIGNvbXBl bnNhdGVkIGZvciBkaXN0cmlidXRpb24gb2YgdGhpcyByZXBvcnQgaW4gdGhlIGFtb3VudCAN CiAgb2YgJDE1LDAwMCBUaGlzIGNvbXBlbnNhdGlvbiBjb25zdGl0dXRlcyBhIGNvbmZsaWN0 IG9mIGludGVyZXN0IGFzIHRvIENXSSBhYmlsaXR5IA0KICB0byByZW1haW4gb2JqZWN0aXZl IGluIGl0cyBjb21tdW5pY2F0aW9uIHJlZ2FyZGluZyB0aGUgc3ViamVjdCBjb21wYW55LiZu YnNwOyANCiAgYnkgUnVsZSAxN2Igb2YgdGhlIFNlY3VyaXRpZXMgQWN0IG9mIDE5MzMvMTkz NC4mbmJzcDsgQ1dJIGlzIG5vdCBhbiBpbnZlc3RtZW50IA0KICBhZHZpc29yIGFuZCB0aGlz IHJlcG9ydCBpcyBub3QgaW52ZXN0bWVudCBhZHZpY2UuJm5ic3A7IFRoaXMgaW5mb3JtYXRp b24gaXMgDQogIG5laXRoZXIgYSBzb2xpY2l0YXRpb24gdG8gYnV5IG5vciBhbiBvZmZlciB0 byBzZWxsIHNlY3VyaXRpZXMuJm5ic3A7IEluZm9ybWF0aW9uIA0KICBjb250YWluZWQgaGVy ZWluIGNvbnRhaW5zIGZvcndhcmQtbG9va2luZyBzdGF0ZW1lbnRzIGFuZCBpcyBzdWJqZWN0 IHRvIHNpZ25pZmljYW50IA0KICByaXNrcyBhbmQgdW5jZXJ0YWludGllcywgd2hpY2ggd2ls bCBhZmZlY3QgdGhlIHJlc3VsdHMuJm5ic3A7IFRoZSBvcGluaW9ucyBjb250YWluZWQgDQog IGhlcmVpbiByZWZsZWN0IG91ciBjdXJyZW50IGp1ZGdtZW50IGFuZCBhcmUgc3ViamVjdCB0 byBjaGFuZ2Ugd2l0aG91dCBub3RpY2UuIA0KICBDV0kgYW5kL29yIGl0cyBhZmZpbGlhdGVz LCBhc3NvY2lhdGVzIGFuZCBlbXBsb3llZXMgZnJvbSB0aW1lIHRvIHRpbWUgbWF5IGhhdmUg DQogIGVpdGhlciBhIGxvbmcgb3Igc2hvcnQgcG9zaXRpb24gaW4gc2VjdXJpdGllcyBtZW50 aW9uZWQuJm5ic3A7IEluZm9ybWF0aW9uIGNvbnRhaW5lZCANCiAgaGVyZWluIG1heSBub3Qg YmUgcmVwcm9kdWNlZCBpbiB3aG9sZSBvciBpbiBwYXJ0IHdpdGhvdXQgdGhlIGV4cHJlc3Mg d3JpdHRlbiANCiAgY29uc2VudCBvZiBDV0k8L2ZvbnQ+PC9pPjxicj4NCiAgJm5ic3A7IA0K PC9ib2R5Pg0KPC9odG1sPg== From owner-mpls@UU.NET Sun Nov 17 17:21:36 2002 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 ESMTP id RAA26592 for ; Sun, 17 Nov 2002 17:21:36 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpkr26170 for ; Sun, 17 Nov 2002 22:24:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpkr25140; Sun, 17 Nov 2002 22:23:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpkr05294 for mpls-outgoing; Sun, 17 Nov 2002 22:23:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpkr05289 for ; Sun, 17 Nov 2002 22:23:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpkr14516 for ; Sun, 17 Nov 2002 22:22:56 GMT From: jcucchiara@mindspring.com Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpkr08645 for ; Sun, 17 Nov 2002 22:22:55 GMT Received: from holt.mail.atl.earthlink.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: holt.mail.mindspring.net [207.69.200.187]) id QQnpkr08640 for ; Sun, 17 Nov 2002 22:22:55 GMT Received: from smui02.slb.mindspring.net ([199.174.114.25]) by holt.mail.atl.earthlink.net with esmtp (Exim 3.33 #1) id 18DXod-00036Z-00; Sun, 17 Nov 2002 17:22:55 -0500 Received: by smui02.slb.mindspring.net id RAA0000010072; Sun, 17 Nov 2002 17:22:54 -0500 (EST) Date: Sun, 17 Nov 2002 17:22:54 -0500 To: "Lai, Wai S (Waisum), ALASO" Cc: mpls@UU.NET Reply-To: jcucchiara@mindspring.com Subject: Re: LDP-MIB Enhancement for Performance Management Message-ID: X-Originating-IP: 204.42.67.201 Sender: owner-mpls@UU.NET Precedence: bulk Hello Wai Sum, On Fri, 15 Nov 2002 21:55:56 -0500 "Lai, Wai S (Waisum), ALASO" wrote: > There is currently no object in the LDP-MIB to > provide necessary counters > for both the Generic Label Space Entities and > the Per-Interface Label Space > Entities. To support LDP entity and session > statistics reports for MPLS > performance management, we propose the > following enhancement to the LDP-MIB. > Specifically, we propose the addition of the > following new objects to > provide summary statistics on the health of LDP > entities and sessions to > capture the usage/performance of LDP sessions: The objects you suggest below for an entity don't make sense to me. The Entity is a collection of configuration/control/status for setting up an LDP session. There is no such thing as an attempted Entity, either a row in the entity table is created or it isn't which can easily be discerned by the RowStatus. Same comment for the Established counter. Not sure what is meant by "Disabled Counter", unless you mean that we keep a count of everytime the mplsLdpEntityOperStatus changes from enabled to disabled, but this is something that an NMS should be polling for (if it cares). Assuming a Session is established which is based on that entity, there will be a notification if the session goes up/down. > > . Generic Label Space Entity Attempted > Counter > . Generic Label Space Entity Established > Counter > . Generic Label Space Entity Disabled Counter > · Per-Interface Label Space Entity Attempted > Counter > · Per-Interface Label Space Entity Established > Counter > · Per-Interface Label Space Entity Disabled > Counter The LDP-MIB does provide the hooks for the counters mentioned below. By this I mean that the LDP-MIB is counting specific errors which could be polled by an NMS (along with the Discontinuity objects), and then divided according to which L2 is associated with the Entity at the NMS. > · Generic Label Space Session Attempted Counter see mplsLdpAttemptedSessions and mplsLdpEntityDiscontinuityTime objects along with the mplsLdpEntityGenLREntries. > · Generic Label Space Session Established > Counter This should be a gauge32-like objects which can be gleened from the number of mplsLdpSessionEntries and from examining the mplsLdpEntityGenLREntries. > · Generic Label Space Session Disabled Counter Don't understand what you are asking for. If you are asking for a count of the glitches in the Session related to Generic Labels this could be figured out by polling the mplsLdpSesDiscontinuityTime object for entities which are associated with a generic label range. > · Per-Interface Label Space Session Attempted > Counter > · Per-Interface Label Space Session Established > Counter > · Per-Interface Label Space Session Disabled > Counter Similar comments for the above, except that instead of the Generic Label range table would look at the interface label tables associated with an Entity. Please note: once a Session is started, the label range tables cannot change. This means that once an NMS retrieves the Entity and LabelRange information, it will be fairly static. The NMS can just poll the mplsLdpEntityLastChange to see if there are changes to the Entity table. > > In addition, these objects should provide an > index to map this LDP entity > with associated IfIndex in the IF-MIB. The Entity is for configuring a session. A session runs over TCP, so are you suggesting to add the ifIndex of the TCP session? Also, as stated in the description of the mplsLdpEntityIndex, "Another way to use this index is to give this the value of ifIndex. However, this is dependent on the implementation." For example, if the ifIndex values are not persistent through a reboot, you may decide to not have the mplsLdpEntityIndex be a value of ifIndex. > > In the above set of counters, > (1) The Attempted Counter indicates the > specific number of attempts made > to establish the LDP entity between two peers > where the corresponding > label space entity/session would be created, > whether those attempts are > successful or not. An Entity is basically a Peer on "this LSR" By "this LSR" I mean the LSR that the NMS is talking to. > > (2) The Established Counter indicates the > specific number of successful > attempts made to establish the LDP entity > between two peers where the > corresponding label space entity/session is > created. > > (3) The Disabled Counter indicates the specific > number of LDP entities > disabled between two peers where the the > corresponding label space > entity/session were used. > > Each of the above is a running counter that is > only re-initialized when > LDP session is re-initialized. An Agent does not usually re-initialize counters, that is why there are usually discontinuity time object associated with counters. > > These counters will provide a high-level > barometer of performance of LDP > entity/sessions. Without such variables, > elaborate NMS-based processing > and extensive MIB walks of the LDP-MIB are > required, thus consuming valuable > network and NMS resources. Initially the NMS will need to poll when it first discovers a device. It will need to understand which Entities are for which L2 (by looking at the Label Range Tables). After that the NMS will need to poll for the mplsLdpEntityLastChange object, the mplsLdpAttemptedSessions object (along with the mplsLdpEntityDiscontinuityTime object) and then the NMS will need to divided these according to the L2 that the LDP Session is configured for. This is not an abnormal amount of polling for an NMS in my opinion. As an aside, would suggest that we move any NMS/Agent specific discussions to the mibs email list. Thanks, -Joan > > Your comments on the above proposal are > solicited. > Thanks, Wai Sum > > From owner-mpls@UU.NET Sun Nov 17 22:18:55 2002 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 ESMTP id WAA00743 for ; Sun, 17 Nov 2002 22:18:54 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpll08166 for ; Mon, 18 Nov 2002 03:21:30 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpll29945; Mon, 18 Nov 2002 03:18:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpll00326 for mpls-outgoing; Mon, 18 Nov 2002 03:17:52 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpll00321 for ; Mon, 18 Nov 2002 03:17:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpll11090 for ; Mon, 18 Nov 2002 03:17:33 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpll14776 for ; Mon, 18 Nov 2002 03:17:33 GMT Received: from wiprom2mx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQnpll14762 for ; Mon, 18 Nov 2002 03:17:31 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id gAI3HQ100158 for ; Mon, 18 Nov 2002 08:47:29 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 18 Nov 2002 08:47:25 +0530 Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-k1-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 18 Nov 2002 08:47:25 +0530 Received: from wslexch.nortel-k1.wipro.com ([192.219.223.59]) by blr-k1-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 18 Nov 2002 08:47:25 +0530 Received: from VANIK ([192.168.101.27]) by wslexch.nortel-k1.wipro.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XBHZJ1ZH; Mon, 18 Nov 2002 09:08:58 +0530 Message-ID: <00bd01c28eb1$222c7650$1b65a8c0@wipro.com> From: "Vani K" To: Date: Mon, 18 Nov 2002 08:48:15 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b514b145-ec08-11d6-ba7c-006067005148" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 18 Nov 2002 03:17:25.0838 (UTC) FILETIME=[04A9AEE0:01C28EB1] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-b514b145-ec08-11d6-ba7c-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01C28EDF.3BBFEC40" ------=_NextPart_000_00BA_01C28EDF.3BBFEC40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ... ------=_NextPart_000_00BA_01C28EDF.3BBFEC40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe = ...
 
------=_NextPart_000_00BA_01C28EDF.3BBFEC40-- ------=_NextPartTM-000-b514b145-ec08-11d6-ba7c-006067005148-- From owner-mpls@UU.NET Sun Nov 17 23:13:38 2002 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 ESMTP id XAA01825 for ; Sun, 17 Nov 2002 23:13:37 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnplp28305 for ; Mon, 18 Nov 2002 04:16:09 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnplo24670; Mon, 18 Nov 2002 04:13:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnplo22802 for mpls-outgoing; Mon, 18 Nov 2002 04:13:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnplo22797 for ; Mon, 18 Nov 2002 04:13:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnplo01483 for ; Mon, 18 Nov 2002 04:12:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnplo05572 for ; Mon, 18 Nov 2002 04:12:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnplo05554 for ; Mon, 18 Nov 2002 04:12:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA07476 for ; Sun, 17 Nov 2002 23:12:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAI4C5u05685 for mpls@uu.net; Sun, 17 Nov 2002 23:12:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnplo22511 for ; Mon, 18 Nov 2002 04:11: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 QQnplo22395 for ; Mon, 18 Nov 2002 04:10:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnplo04887 for ; Mon, 18 Nov 2002 04:10:49 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnplo04879 for ; Mon, 18 Nov 2002 04:10:48 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAI4B9LZ006126; Sun, 17 Nov 2002 23:11:09 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn2-116.cisco.com [10.82.240.116]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD15899; Sun, 17 Nov 2002 23:10:46 -0500 (EST) Message-Id: <5.2.0.9.0.20021117225858.0230ba60@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 17 Nov 2002 23:10:40 -0500 To: jcucchiara@mindspring.com From: "Thomas D. Nadeau" Subject: Re: LDP-MIB Enhancement for Performance Management Cc: "Lai, Wai S (Waisum), ALASO" , mpls@UU.NET In-Reply-To: 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 XAA01825 I agree with Joan's comments with a few things to add. --Tom >Hello Wai Sum, > >On Fri, 15 Nov 2002 21:55:56 -0500 "Lai, Wai S (Waisum), ALASO" >wrote: > > > There is currently no object in the LDP-MIB to > > provide necessary counters > > for both the Generic Label Space Entities and > > the Per-Interface Label Space > > Entities. To support LDP entity and session > > statistics reports for MPLS > > performance management, we propose the > > following enhancement to the LDP-MIB. > > Specifically, we propose the addition of the > > following new objects to > > provide summary statistics on the health of LDP > > entities and sessions to > > capture the usage/performance of LDP sessions: > >The objects you suggest below for an entity >don't make sense to me. The Entity is >a collection of configuration/control/status for >setting up an LDP session. There is >no such thing as an attempted Entity, either >a row in the entity table is created or it >isn't which can easily be discerned by the >RowStatus. Same comment for the Established >counter. Right. The protocol just doesn't work this way. >Not sure what is meant by "Disabled Counter", >unless you mean that we keep a count of >everytime the mplsLdpEntityOperStatus changes >from enabled to disabled, but this is something >that an NMS should be polling for (if it cares). > >Assuming a Session is established which is >based on that entity, there will be a >notification if the session goes up/down. > > > > > . Generic Label Space Entity Attempted > > Counter > > . Generic Label Space Entity Established > > Counter > > . Generic Label Space Entity Disabled Counter > > · Per-Interface Label Space Entity Attempted > > Counter > > · Per-Interface Label Space Entity Established > > Counter > > · Per-Interface Label Space Entity Disabled > > Counter > > > >The LDP-MIB does provide the hooks for >the counters mentioned below. >By this I mean that the LDP-MIB >is counting specific errors which could >be polled by an NMS (along with the Discontinuity >objects), and then divided according to which >L2 is associated with the Entity at the NMS. > > > > · Generic Label Space Session Attempted Counter > >see mplsLdpAttemptedSessions and >mplsLdpEntityDiscontinuityTime objects >along with the mplsLdpEntityGenLREntries. > > > > > · Generic Label Space Session Established > > Counter > > >This should be a gauge32-like objects >which can be gleened from the number >of mplsLdpSessionEntries and from >examining the mplsLdpEntityGenLREntries. > > > · Generic Label Space Session Disabled Counter > >Don't understand what you are asking for. >If you are asking for a count of the >glitches in the Session related to Generic Labels >this could be figured out by polling >the mplsLdpSesDiscontinuityTime object >for entities which are associated with a >generic label range. > > > > > · Per-Interface Label Space Session Attempted > > Counter > > · Per-Interface Label Space Session Established > > Counter > > · Per-Interface Label Space Session Disabled > > Counter > >Similar comments for the above, except that >instead of the Generic Label range table would >look at the interface label tables associated >with an Entity. > >Please note: once a Session is started, the >label range tables cannot change. This >means that once an NMS retrieves the Entity >and LabelRange information, it will >be fairly static. The NMS can just >poll the mplsLdpEntityLastChange to see >if there are changes to the Entity >table. > > > > > > > In addition, these objects should provide an > > index to map this LDP entity > > with associated IfIndex in the IF-MIB. > >The Entity is for configuring a session. Or showing dynamic sessions that the device has instigated. >A session runs over TCP, so are you >suggesting to add the ifIndex of the >TCP session? Can't this information can be found by looking at the destination transport address that you are adding as part of the current set of revisions, and then looking in the routing table for the next hop? >Also, as stated in the >description of the mplsLdpEntityIndex, >"Another way to use this index is to give >this the value of ifIndex. However, this >is dependent on the implementation." For >example, if the ifIndex values are >not persistent through a reboot, you >may decide to not have the mplsLdpEntityIndex >be a value of ifIndex. Another way of protecting against this is to just make sure that in cases where the ifIndex is used and ifIndex persistence is implemented in the device that the NMS understand that a discontinuity has occurred and that it should re-read the table. This sounds like the easiest approach, and one that can be easily handled by just about any NMS out there. > > In the above set of counters, > > (1) The Attempted Counter indicates the > > specific number of attempts made > > to establish the LDP entity between two peers > > where the corresponding > > label space entity/session would be created, > > whether those attempts are > > successful or not. > >An Entity is basically a Peer on "this LSR" >By "this LSR" I mean the LSR that the NMS is >talking to. > > > > > (2) The Established Counter indicates the > > specific number of successful > > attempts made to establish the LDP entity > > between two peers where the > > corresponding label space entity/session is > > created. > > > > (3) The Disabled Counter indicates the specific > > number of LDP entities > > disabled between two peers where the the > > corresponding label space > > entity/session were used. > > > > Each of the above is a running counter that is > > only re-initialized when > > LDP session is re-initialized. > >An Agent does not usually re-initialize counters, >that is why there are usually discontinuity >time object associated with counters. > > > > > These counters will provide a high-level > > barometer of performance of LDP > > entity/sessions. Without such variables, > > elaborate NMS-based processing > > and extensive MIB walks of the LDP-MIB are > > required, thus consuming valuable > > network and NMS resources. > >Initially the NMS will need to poll when >it first discovers a device. It will >need to understand which Entities are >for which L2 (by looking at the >Label Range Tables). After that >the NMS will need to poll for the >mplsLdpEntityLastChange object, the >mplsLdpAttemptedSessions object (along >with the mplsLdpEntityDiscontinuityTime >object) and then the NMS will need to >divided these according to the L2 that >the LDP Session is configured for. > >This is not an abnormal amount >of polling for an NMS in my opinion. And in mine. >As an aside, would suggest that we move >any NMS/Agent specific discussions to the >mibs email list. > >Thanks, > -Joan > > > > > Your comments on the above proposal are > > solicited. > > Thanks, Wai Sum > > > > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Mon Nov 18 10:46:26 2002 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 ESMTP id KAA24300 for ; Mon, 18 Nov 2002 10:46:25 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpnj06162 for ; Mon, 18 Nov 2002 15:48:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpnj04084; Mon, 18 Nov 2002 15:47:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpnj06174 for mpls-outgoing; Mon, 18 Nov 2002 15:46:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpnj06169 for ; Mon, 18 Nov 2002 15:46:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpnj23613 for ; Mon, 18 Nov 2002 15:46:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpnj02081 for ; Mon, 18 Nov 2002 15:46:14 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpnj02077 for ; Mon, 18 Nov 2002 15:46:13 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA09756 for ; Mon, 18 Nov 2002 10:46:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAIFkDu08335 for mpls@uu.net; Mon, 18 Nov 2002 10:46:13 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpnj05929 for ; Mon, 18 Nov 2002 15:45: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 QQnpni13526 for ; Mon, 18 Nov 2002 15:44:38 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpni01211 for ; Mon, 18 Nov 2002 15:44:37 GMT Received: from kohlqf by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [208.251.63.238]) id QQnpni01206 for ; Mon, 18 Nov 2002 15:44:36 GMT From: Godiva Borrelli To: Subject: Dear mpls, Hottest Stock Pick For Monday' Date: Mon, 18 Nov 2002 08:41:48 -0800 Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Message-Id: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: base64 PGh0bWw+DQo8Ym9keT4NCjxjZW50ZXI+DQogIDxiPjxmb250IHNpemU9IisyIiBjb2xvcj0i I0ZGMDAzMyI+QnJlYWtpbmcgTWFya2V0IE5ld3M8L2ZvbnQ+PC9iPjxmb250IGNvbG9yPSIj RkYwMDMzIj48YnI+DQogIDxiPkFsZXJ0aW5nIFRyYWRlcnMgdG8gT3Zlcmxvb2tlZCAmYW1w OyBVbmRlcnZhbHVlZCBTdG9ja3M8L2I+PGJyPg0KICA8Yj5JbnRlcmFjdGl2ZSBNdWx0aW1l ZGlhIE5ldHdvcmsgSW5jPC9iPjwvZm9udD4gDQo8L2NlbnRlcj4NCjxmb250IHNpemU9LTI+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTwvZm9udD48YnI+DQo8Zm9udCBzaXplPSItMSI+QXMgdGhlIG1hcmtldCB1 bmRlcmdvZXMgZXh0cmVtZSBmbHVjdHVhdGlvbnMgYW5kIHR1cmJ1bGVuY2UsIGZ1bmQgDQpt YW5hZ2VycyBhbmQgbW9uZXkgbWFuYWdlcnMgYXJlIHJhcGlkbHkgc2Vla2luZyBhbHRlcm5h dGl2ZSBpbnZlc3RtZW50cyBTbWFsbCANCnRvIE1pZC1DYXAgY29tcGFuaWVzIGFyZSByYXBp ZGx5IGJlY29taW5nIHRoZSBpbnZlc3RtZW50IG9mJm5ic3A7IHNwZWN1bGF0aXZlIA0KcG9y dGZvbGlvcyBhbmQgaGVkZ2UgZnVuZHMgYXMgdGhleSByZXByZXNlbnQgdGhlIGdyZWF0ZXN0 IG9wcG9ydHVuaXR5IGZvciBhcHByZWNpYXRpb24gDQphbmQmbmJzcDsgZ3Jvd3RoIGluIHRv ZGF5knMgdm9sYXRpbGUgdGltZXMuIFdoYXQgZG9lcyB0aGlzIG1lYW4/PC9mb250PiANCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdCI+SXQg bWVhbnMgTk9XIGlzIHRoZSB0aW1lIA0KICB0byBwb3NpdGlvbiB5b3VyIHBvcnRmb2xpbyB3 aXRoIFVOREVSVkFMVUVEIGNvbXBhbmllcyBhbmQgQ0FQSVRBTElaRSBvbiB0aGUgDQogIG5l dyCTQnVsbJQgbWFya2V0LiZuYnNwOyBBcyBzdWNoPC9zcGFuPjxicj4NCiAgPGZvbnQgc2l6 ZT0tMT4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTwvZm9udD48YnI+DQogIDxicj4NCiAgPGI+PGZvbnQgc2l6ZT0iMiI+ U3ltYm9sJm5ic3A7IE9UQ0JCOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9m aW5hbmNlLnlhaG9vLmNvbS9xP3M9SU1OSS5PQiI+SU1OSTwvYT48L2ZvbnQ+PC9iPjxmb250 IHNpemU9IjIiPjxicj4NCiAgU2hhcmVzIG91dHN0YW5kaW5nJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDgsMzQwLDk2NDxicj4NCiAg RmxvYXQgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAmbmJzcDsmbmJzcDsgMiw1MDAs MDAwIHNoYXJlczxicj4NCiAgUmF0aW5nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIDEwPGJyPg0KICBDdXJyZW50IFByaWNlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAkMC4yNjxicj4N CiAgNTIgd2VlayBoaWdoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAkMC40NjwvZm9udD48L3A+DQo8cD48 Yj5Db3Jwb3JhdGUgU25hcHNob3Q8L2I+PGJyPg0KICA8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMC4wcHQiPk9UQ0JCOiZuYnNwOyA8YSBocmVmPSJodHRwOi8vZmluYW5jZS55YWhvby5j b20vcT9zPUlNTkkuT0IiPklNTkk8L2E+IA0KICBpcyBhIGdlbnVpbmUgaG9sZGluZ3MgY29t cGFueSBhbGxvY2F0aW5nIGl0cyByZXNvdXJjZXMgdG8gZmlsbCB2YXJpb3VzIG5lZWRzIA0K ICCWIHJhbmdpbmcgZnJvbSBIZWF0aCBDYXJlIHRvIEV5ZSBDYXJlIHRvIEFpcnBvcnQgU2Vj dXJpdHkuJm5ic3A7IEhlYWx0aCBDYXJlIA0KICBhbmQgRXllIENhcmUgY29tcGFuaWVzIGhh dmUgcmVjb2duaXplZCBkZW1hbmRzLCB3aGljaCBJTU5JIGlzIHN0cml2aW5nIHRvIGZ1bGZp bGwuIA0KICBJbiBhZGRpdGlvbiwgSU1OSSBpcyBhbHNvIGludHJvZHVjaW5nIGEgY29tcGxl dGUgYW5kIHRvdGFsIEFpcnBvcnQgU2VjdXJpdHkgDQogIFN5c3RlbSwgdGhlIEdsb2JhbCBQ Lk8uTS4sIHdoaWNoIHNlYW1sZXNzbHkgY29ubmVjdHMgZGF0YSwgcGVvcGxlIGFuZCB0aGVp ciANCiAgYmVsb25naW5ncyBpbnNpZGUsIG91dHNpZGUsIGFuZCB0aHJvdWdob3V0IHRoZSBh aXJwb3J0LiZuYnNwOyBQZWFjZSBvZiBNaW5kLCANCiAgU2VjdXJpdHksIGFuZCBXZWxsbmVz cyB3cmFwcGVkIHVwIGludG8gb25lIHRvdGFsIHBhY2thZ2UuPC9zcGFuPiANCjxwPiA8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQiPjxhIGhyZWY9Imh0dHA6Ly9maW5hbmNlLnlh aG9vLmNvbS9xP3M9SU1OSS5PQiI+SU1OSTwvYT4gDQogIGlzIGRlZGljYXRlZCB0byBpbnRy b2R1Y2luZyBmaXJzdC10by1tYXJrZXQgaGVhbHRoIGFuZCB3ZWxsbmVzcyBwcm9kdWN0cywg cHJvdmlkaW5nIA0KICB1bmlxdWUgbWFuYWdlbWVudCBhbmQgbWFya2V0aW5nIG1ldGhvZHMg dG8gZGV2ZWxvcCwgbWFya2V0IGFuZCBzZWxsIHByb2R1Y3RzIA0KICB0byBjb25zdW1lciBh bmQgYnVzaW5lc3MgY2xpZW50cyB3aG8gaGF2ZSBiZWVuIGVkdWNhdGVkIGFib3V0IGl0cyBw cm9kdWN0cy48L3NwYW4+IA0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IDxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjBwdCI+VGhlIENvbXBhbnkgaGFzIHR3byBvcGVyYXRpbmcgDQogIHN1 YnNpZGlhcmllczogQmVzdCBIZWFsdGgsIEluYy4gYW5kIFNveVNsaW0sIEluYy4mbmJzcDsg Qm90aCBhcmUgZm9jdXNlZCBzcGVjaWZpY2FsbHkgDQogIG9uIHRoZSBkZXZlbG9wbWVudCwg bWFudWZhY3R1cmluZyBhbmQgbWFya2V0aW5nIG9mIGhlYWx0aCBhbmQgd2VsbG5lc3Mgb3Jp ZW50ZWQgDQogIGNvbnN1bWVyIHByb2R1Y3RzLiZuYnNwOyBFYWNoIGFkZHJlc3NlcyBuaWNo ZSBtYXJrZXRzIHRoYXQgYXJlIG9mIHBhcnRpY3VsYXIgDQogIGludGVyZXN0IHRvIHRoZSBs YXJnZXN0IHNpbmdsZSBtYXJrZXQgZGVtb2dyYXBoaWM7IHRoZSCTYmFieSBib29tZXKUIGdl bmVyYXRpb24uJm5ic3A7IA0KICBUaGUgY29tcGFueSBmb2N1c2VzIGl0cyBhdHRlbnRpb24g b24gbWFya2V0aW5nIGhlYWx0aCBhbmQgd2VsbG5lc3MgY29uc3VtZXIgDQogIHByb2R1Y3Rz IHRvIHRoaXMgYWZmbHVlbnQgZGVtb2dyYXBoaWMgbWFya2V0LiZuYnNwOyA8L3NwYW4+PC9w Pg0KPHA+PGZvbnQgc2l6ZT0tMT5TbyB3aGF0IG1ha2VzIHRoZSBwcm9kdWN0IHNvIGRlc2ly YWJsZT8gRW5oYW5jZWQgVHJhbnNhY3Rpb25hbCANCiAgU2VjdXJlIFNvZnR3YXJlICgiRVRT UyIpIGlzIGEgcHJvcHJpZXRhcnkgc29mdHdhcmUgcGFja2FnZSZuYnNwOyB0aGF0IGVtcG93 ZXJzIA0KICBjb25zdW1lcnMgdG8gYWNjb21wbGlzaCBzZWN1cmUgZS1jb21tZXJjZSB0cmFu c2FjdGlvbnMgb24gdGhlIGludGVybmV0IHVzaW5nIA0KICBjcmVkaXQsIGRlYml0IEFUTSwo d2l0aCBwaW4pIG9yIHNtYXJ0IGNhcmRzLiBUaGUgRVRUUyBzeXN0ZW0gaW50ZWdyYXRlcyBh IGNvbnN1bWVyLXNpZGUgDQogIGNhcmQtc3dpcGUgdGVybWluYWwgd2l0aCBhIGJhY2stZW5k IGhvc3QgcHJvY2Vzc2luZyBjZW50ZXIuPC9mb250PiANCjxwPjxiPldlIGhhdmUgR2l2ZW4g PGEgaHJlZj0iaHR0cDovL2ZpbmFuY2UueWFob28uY29tL3E/cz1JTU5JLk9CIj5JTU5JPC9h PiBvdXIgDQogIGhpZ2hlc3QgcmF0aW5nIGEgQklHIDEwIEZvciB0aGUgZm9sbG93aW5nIHJl YXNvbnM6PC9iPjxicj4NCiAgPGI+PHU+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBw dCI+TWFya2V0IFBvdGVudGlhbDwvc3Bhbj48L3U+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwLjBwdCI+Jm5ic3A7Jm5ic3A7IA0KICA8c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNr Ij5XaXRoaW4gdGhlIGhlYWx0aCAmYW1wOyB3ZWxsbmVzcyBtYXJrZXQgYWxvbmUsIGNvbnN1 bWVycyANCiAgc3BlbmQgb3ZlciA8Yj4kMTg0IGJpbGxpb24gZG9sbGFyczwvYj4gaW4gd2Vp Z2h0IGxvc3MgYW5kIG51dHJpdGlvbmFsIHN1cHBsZW1lbnRzIA0KICBhbm51YWxseSB3aGls ZSBzcGVuZGluZyA8Yj4kMi4yIGJpbGxpb248L2I+PC9zcGFuPjxiPiBkb2xsYXJzPC9iPiBm b3IgbGVuc2VzIA0KICBhbmQgY2FyZSBwcm9kdWN0cy4mbmJzcDsgQWNoaWV2aW5nIGp1c3Qg YSBzbGlnaHQgcGVyY2VudGFnZSBvZiB0aGUgbWFya2V0IHNoYXJlIA0KICBjYW4gcG90ZW50 aWFsbHkgZ2VuZXJhdGUgc2V2ZXJhbCBtaWxsaW9uIGRvbGxhcnMgZm9yIElNTkkuPC9zcGFu PiANCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiA8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC4wcHQiPjxhIGhyZWY9Imh0dHA6Ly9maW5hbmNlLnlhaG9vLmNvbS9xP3M9SU1OSS5PQiI+ SU1OSTwvYT48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdCI+IA0K ICBpcyBpbiBhIG1hcmtldCB3aXRoIGEgc3Ryb25nIGRlbWFuZCBmb3IgaXRzIHByb2R1Y3Qg liBoZW5jZSBjb250aW51b3VzIHJldmVudWUgDQogIGFuZCBpbmNvbWU8Yj4uIDwvYj48L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0Ij5JTU5JPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQiPiANCiAgaGFzIGFuIGV4Y2VsbGVudCBz aGFyZSBzdHJ1Y3R1cmUgZm9yIG1heGltdW0gYXBwcmVjaWF0aW9uLiZuYnNwOyBXaXRoIHN1 Y2ggYSANCiAgbG93IGZsb2F0LCBhbmQgdGlnaHQgc2hhcmUgc3RydWN0dXJlLCBhbnkgc2ln bmlmaWNhbnQgdm9sdW1lIHdpbGwgcmVzdWx0IGluIA0KICBvbmUgb3V0Y29tZSCWIEFQUFJF Q0lBVElPTiBhbmQgR0FJTlMuPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw LjBwdDsgZm9udC1mYW1pbHk6IFRpbWVzIE5ldyBSb21hbiI+IA0KICBJTU5JPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7IGZvbnQtZmFtaWx5OiBUaW1lcyBO ZXcgUm9tYW4iPiANCiAgaXMgc2Vla2luZyB0byBleHBhbmQgdGhlaXIgb25saW5lIHByZXNl bmNlIHRocm91Z2ggcHJvZHVjdCBwbGFjZW1lbnQgb24gbXVsdGlwbGUgDQogIG9ubGluZSBy ZXRhaWxlcnM8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0OyBmb250 LWZhbWlseTogVGltZXMgTmV3IFJvbWFuIj4gDQogIElNTkkgPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7IGZvbnQtZmFtaWx5OiBUaW1lcyBOZXcgUm9tYW4i PiANCiAgaGFzIGEgc3Vic3RhbnRpYWwgb3Bwb3J0dW5pdHkgaW4gdGhlIHdvcmxkknMgY29u dGFjdCBtYXJrZXQuJm5ic3A7IFRoZSBvdmVyYWxsIA0KICBtYXJrZXQgZm9yIGNvbnRhY3Qg bGVucyByZWxhdGVkIHByb2R1Y3RzIGlzIGdyb3dpbmcgYXQgYSByYXRlIG9mIDEwJSBwZXIg eWVhci4gDQogIEFzIHByb2plY3RlZCBieSBCYXVzY2ggJmFtcDsgTG9tYiwgdGhlIFVTIG1h cmtldCBmb3IgcmVwbGFjZW1lbnQgY29udGFjdCBsZW5zZXMgDQogIGFuZCBjb250YWN0IGxl bnMgY2FyZSBwcm9kdWN0cyB0b3RhbGVkIDxiPiQyLjIgQmlsbGlvbiBkb2xsYXJzPC9iPiBh dCB0aGUgeWVhci1lbmQgDQogIDIwMDAuJm5ic3A7IFRoZSBtYXJrZXQgZm9yIHNvZnQsIGdh cyBwZXJtZWFibGUgYW5kIFBNTUEgKGhhcmQpIGNvbnRhY3QgbGVucyANCiAgcmVwbGFjZW1l bnRzIGlzIGFwcHJveGltYXRlbHkgPGI+JDEuMyBCaWxsaW9uIGRvbGxhcnM8L2I+IGFuZCBm b3IgbGVucyBjYXJlIA0KICBwcm9kdWN0cyBpdCBpcyBlc3RpbWF0ZWQgdG8gYmUgOTAwIE1p bGxpb24gZG9sbGFycy4gVGhlIGxlbnMgY2FyZSBtYXJrZXQgY29uc2lzdHMgDQogIG9mIGNs ZWFuaW5nLCByaW5zaW5nLCBkaXNpbmZlY3RpbmcsJm5ic3A7IHN0b3JpbmcsIGFuZCBsdWJy aWNhdGluZyBzb2x1dGlvbnMgDQogIGZvciBjb250YWN0IGxlbnNlczwvc3Bhbj48L3A+DQo8 cD48YnI+DQogICZuYnNwOzxicj4NCiAgJm5ic3A7PGJyPg0KICAmbmJzcDs8YnI+DQogICZu YnNwOzxicj4NCiAgJm5ic3A7PGJyPg0KICAmbmJzcDs8YnI+DQogICZuYnNwOzxicj4NCiAg Jm5ic3A7PGJyPg0KICAmbmJzcDs8YnI+DQogICZuYnNwOzxicj4NCiAgJm5ic3A7IA0KPHA+ PGk+PGZvbnQgc2l6ZT0tMj5UaGUgaW5mb3JtYXRpb24sIG9waW5pb25zIGFuZCBhbmFseXNp cyBjb250YWluZWQgaGVyZWluIGFyZSANCiAgYmFzZWQgb24gc291cmNlcyBiZWxpZXZlZCB0 byBiZSByZWxpYWJsZSBidXQgbm8gcmVwcmVzZW50YXRpb24sIGV4cHJlc3NlZCBvciANCiAg aW1wbGllZCwgaXMgbWFkZSBhcyB0byBpdHMgYWNjdXJhY3ksIGNvbXBsZXRlbmVzcyBvciBj b3JyZWN0bmVzcy4mbmJzcDsgUGFzdCANCiAgcGVyZm9ybWFuY2UgaXMgbm8gZ3VhcmFudGVl IG9mIGZ1dHVyZSByZXN1bHRzLiBUaGlzIHJlcG9ydCBpcyBmb3IgaW5mb3JtYXRpb24gDQog IHB1cnBvc2VzIG9ubHkgYW5kIHNob3VsZCBub3QgYmUgdXNlZCBhcyB0aGUgYmFzaXMgZm9y IGFueSBpbnZlc3RtZW50IGRlY2lzaW9uLiANCiAgQ1dJJm5ic3A7IGhhcyBiZWVuIGNvbXBl bnNhdGVkIGZvciBkaXN0cmlidXRpb24gb2YgdGhpcyByZXBvcnQgaW4gdGhlIGFtb3VudCAN CiAgb2YgJDE1LDAwMCBUaGlzIGNvbXBlbnNhdGlvbiBjb25zdGl0dXRlcyBhIGNvbmZsaWN0 IG9mIGludGVyZXN0IGFzIHRvIENXSSBhYmlsaXR5IA0KICB0byByZW1haW4gb2JqZWN0aXZl IGluIGl0cyBjb21tdW5pY2F0aW9uIHJlZ2FyZGluZyB0aGUgc3ViamVjdCBjb21wYW55LiZu YnNwOyANCiAgYnkgUnVsZSAxN2Igb2YgdGhlIFNlY3VyaXRpZXMgQWN0IG9mIDE5MzMvMTkz NC4mbmJzcDsgQ1dJIGlzIG5vdCBhbiBpbnZlc3RtZW50IA0KICBhZHZpc29yIGFuZCB0aGlz IHJlcG9ydCBpcyBub3QgaW52ZXN0bWVudCBhZHZpY2UuJm5ic3A7IFRoaXMgaW5mb3JtYXRp b24gaXMgDQogIG5laXRoZXIgYSBzb2xpY2l0YXRpb24gdG8gYnV5IG5vciBhbiBvZmZlciB0 byBzZWxsIHNlY3VyaXRpZXMuJm5ic3A7IEluZm9ybWF0aW9uIA0KICBjb250YWluZWQgaGVy ZWluIGNvbnRhaW5zIGZvcndhcmQtbG9va2luZyBzdGF0ZW1lbnRzIGFuZCBpcyBzdWJqZWN0 IHRvIHNpZ25pZmljYW50IA0KICByaXNrcyBhbmQgdW5jZXJ0YWludGllcywgd2hpY2ggd2ls bCBhZmZlY3QgdGhlIHJlc3VsdHMuJm5ic3A7IFRoZSBvcGluaW9ucyBjb250YWluZWQgDQog IGhlcmVpbiByZWZsZWN0IG91ciBjdXJyZW50IGp1ZGdtZW50IGFuZCBhcmUgc3ViamVjdCB0 byBjaGFuZ2Ugd2l0aG91dCBub3RpY2UuIA0KICBDV0kgYW5kL29yIGl0cyBhZmZpbGlhdGVz LCBhc3NvY2lhdGVzIGFuZCBlbXBsb3llZXMgZnJvbSB0aW1lIHRvIHRpbWUgbWF5IGhhdmUg DQogIGVpdGhlciBhIGxvbmcgb3Igc2hvcnQgcG9zaXRpb24gaW4gc2VjdXJpdGllcyBtZW50 aW9uZWQuJm5ic3A7IEluZm9ybWF0aW9uIGNvbnRhaW5lZCANCiAgaGVyZWluIG1heSBub3Qg YmUgcmVwcm9kdWNlZCBpbiB3aG9sZSBvciBpbiBwYXJ0IHdpdGhvdXQgdGhlIGV4cHJlc3Mg d3JpdHRlbiANCiAgY29uc2VudCBvZiBDV0k8L2ZvbnQ+PC9pPjxicj4NCiAgJm5ic3A7IA0K PC9ib2R5Pg0KPC9odG1sPiAgIA== From owner-mpls@UU.NET Mon Nov 18 11:37:08 2002 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 ESMTP id LAA26053 for ; Mon, 18 Nov 2002 11:37:06 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpnm14808 for ; Mon, 18 Nov 2002 16:39:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpnm12695; Mon, 18 Nov 2002 16:38:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpnm28109 for mpls-outgoing; Mon, 18 Nov 2002 16:38:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpnm28100 for ; Mon, 18 Nov 2002 16:38:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpnm06218 for ; Mon, 18 Nov 2002 16:37:56 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpnm11901 for ; Mon, 18 Nov 2002 16:37:56 GMT Received: from web14105.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14105.mail.yahoo.com [216.136.172.135]) id QQnpnm11889 for ; Mon, 18 Nov 2002 16:37:55 GMT Message-ID: <20021118163755.35913.qmail@web14105.mail.yahoo.com> Received: from [47.234.0.51] by web14105.mail.yahoo.com via HTTP; Mon, 18 Nov 2002 08:37:55 PST Date: Mon, 18 Nov 2002 08:37:55 -0800 (PST) From: PamSri Subject: BGP - 2547 VPNS To: rpotti123@yahoo.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk In BGP this is the very basic/fundamental concept involved in withdraw: When sending a withdraw message you dont send all the path attributes that you had advertised along with the prefix before. All you have to do is send the prefix as unfeasible. The short answer for your question is: i. understand the messaging process for "withdraw" in BGP. ii. read & understand the MP-UNREACH message. - pamsri Rajesh wrote: -------- Original Message -------- Subject: BGP - 2547 VPNS Date: Fri, 15 Nov 2002 06:57:11 -0800 (PST) From: Rajesh Potti To: mpls@UU.NET Hi, In BGP for 2547 VPNs, can a VPN-IPv4 route be send with a set of route targets and then a withdraw with only a subset of the route targets. This will be a partial withdraw. How does a router handle a partial withdraw? If the route is removed from only the vpns in which there is an import Route target match, future updates for the route with a set of route targets will result in inconsistencies. Thanks, Rajesh __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com From owner-mpls@UU.NET Mon Nov 18 15:28:23 2002 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 ESMTP id PAA02503 for ; Mon, 18 Nov 2002 15:28:23 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpoc02561 for ; Mon, 18 Nov 2002 20:30:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpoc00890; Mon, 18 Nov 2002 20:30:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpob00391 for mpls-outgoing; Mon, 18 Nov 2002 20:29:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpob00330 for ; Mon, 18 Nov 2002 20:29:42 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 QQnpob25483 for ; Mon, 18 Nov 2002 20:29:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpob29758 for ; Mon, 18 Nov 2002 20:29:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpob29750 for ; Mon, 18 Nov 2002 20:29:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA04165 for ; Mon, 18 Nov 2002 15:29:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAIKT5B22704 for mpls@uu.net; Mon, 18 Nov 2002 15:29:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpob00241 for ; Mon, 18 Nov 2002 20:28: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 QQnpob21367 for ; Mon, 18 Nov 2002 20:27:39 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpob02295 for ; Mon, 18 Nov 2002 20:27:39 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 QQnpob02289 for ; Mon, 18 Nov 2002 20:27:38 GMT Received: from sharahma-ultra.cisco.com (sharahma-ultra.cisco.com [171.69.58.239]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAIKRbNg021942 for ; Mon, 18 Nov 2002 12:27:38 -0800 (PST) Date: Mon, 18 Nov 2002 12:26:29 -0800 (PST) From: Shahriar Rahman To: mpls@UU.NET Subject: Can anybody tell me what happens when an IETF draft expires Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Any other relevant information on IETF draft processes, will be appreciated. thanks, Shahriar From owner-mpls@UU.NET Mon Nov 18 16:28:01 2002 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 ESMTP id QAA04054 for ; Mon, 18 Nov 2002 16:28:00 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpog16452 for ; Mon, 18 Nov 2002 21:30:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpof15026; Mon, 18 Nov 2002 21:29:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpof26192 for mpls-outgoing; Mon, 18 Nov 2002 21:29:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpof26185 for ; Mon, 18 Nov 2002 21:29:15 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 QQnpof26755 for ; Mon, 18 Nov 2002 21:29:01 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpof01481 for ; Mon, 18 Nov 2002 21:29:00 GMT Received: from vivacenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.221.212.131]) id QQnpof01416 for ; Mon, 18 Nov 2002 21:28:55 GMT Received: from AMALIS.vivacenetworks.com ([10.120.0.2] RDNS failed) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 13:28:50 -0800 Message-Id: <5.1.0.14.2.20021118161942.05419f88@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Nov 2002 16:28:40 -0500 To: Shahriar Rahman From: "Andrew G. Malis" Subject: Re: Can anybody tell me what happens when an IETF draft expires Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Nov 2002 21:28:50.0851 (UTC) FILETIME=[7CC5AF30:01C28F49] Sender: owner-mpls@UU.NET Precedence: bulk To answer your first question, expired drafts are removed from the IETF's internet draft online directory. But they often live on in people's memories, hard drives, and implementations, as well as elsewhere on the web (a Google search usually finds most any expired draft). To answer your second question, two good places to start are: http://www.ietf.org/newcomer.htm http://www.ietf.org/tao.html Then, you want to read the actual reference document: http://www.ietf.org/rfc/rfc2026.txt Cheers, Andy At 11/18/2002 12:26 PM -0800, Shahriar Rahman wrote: >Any other relevant information on IETF draft processes, will be >appreciated. > >thanks, >Shahriar From owner-mpls@UU.NET Mon Nov 18 20:26:16 2002 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 ESMTP id UAA09945 for ; Mon, 18 Nov 2002 20:26:16 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpov17826 for ; Tue, 19 Nov 2002 01:28:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpov16742; Tue, 19 Nov 2002 01:28:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpov28850 for mpls-outgoing; Tue, 19 Nov 2002 01:28:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpov28843 for ; Tue, 19 Nov 2002 01:28: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 QQnpov19181 for ; Tue, 19 Nov 2002 01:27:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpov08138 for ; Tue, 19 Nov 2002 01:27:17 GMT Received: from mail1.lge.co.kr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [156.147.1.151]) id QQnpov08088 for ; Tue, 19 Nov 2002 01:27:15 GMT Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail1.lge.co.kr (8.11.3/8.11.3) with ESMTP id gAJ1R1A05070 for ; Tue, 19 Nov 2002 10:27:02 +0900 (KST) Received: from yongjuni ([150.150.40.133]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.0.9a) with SMTP id 2002111910313864:534478 ; Tue, 19 Nov 2002 10:31:38 +0900 Message-ID: <007101c28f6a$cfa752f0$85289696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: Subject: Draft status of "Fast reroute extensions to CRLDP" Date: Tue, 19 Nov 2002 10:27:22 +0900 Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.0.9a |January 7, 2002) at 11/19/2002 10:31:38 AM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.0.9a |January 7, 2002) at 11/19/2002 10:31:40 AM, Serialize complete at 11/19/2002 10:31:40 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ks_c_5601-1987" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Could anyone tell me about the current status of internet draft, "Fast reroute extensions to CRLDP" by Vijayanand C ? (As you know, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" is in WG draft.) Is that draft still progressing or being updated? AFAIK, IETF has decided to discontinue further standardaziation on CR-LDP, since it prefers RSVP-TE to CR-LDP as an MPLS and GMPLS signaling protocol? If IETF made a decision to discontinue any further discussion on fast rerouting extensions to CRLDP, then will that functionality not being supported in CR-LDP? Thanks in advance. Yongjun. From owner-mpls@UU.NET Mon Nov 18 20:38:09 2002 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 ESMTP id UAA10263 for ; Mon, 18 Nov 2002 20:38:09 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpow03172 for ; Tue, 19 Nov 2002 01:40:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpow01309; Tue, 19 Nov 2002 01:39:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpow29591 for mpls-outgoing; Tue, 19 Nov 2002 01:39:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpow29584 for ; Tue, 19 Nov 2002 01:39:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpow18138 for ; Tue, 19 Nov 2002 01:38:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpow16832 for ; Tue, 19 Nov 2002 01:38:12 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnpow16826 for ; Tue, 19 Nov 2002 01:38:11 GMT Received: from utfors.se ([195.58.105.105]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id gAJ1bxgd001797; Tue, 19 Nov 2002 02:37:59 +0100 (MET) Message-ID: <3DD995F6.9090108@utfors.se> Date: Mon, 18 Nov 2002 20:37:58 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yongjun Im CC: mpls@UU.NET Subject: Re: Draft status of "Fast reroute extensions to CRLDP" References: <007101c28f6a$cfa752f0$85289696@lge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit the draft is an individual draft, according to the referred decision it won't become an wg doc, as it falls into the category "new cr-ldp work". /Loa Yongjun Im wrote: > Hello, > Could anyone tell me about the current status of internet draft, > "Fast reroute extensions to CRLDP" by Vijayanand C ? > (As you know, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" is > in WG draft.) > > Is that draft still progressing or being updated? AFAIK, IETF has decided > to discontinue further standardaziation on CR-LDP, since it prefers RSVP-TE > to CR-LDP as an MPLS and GMPLS signaling protocol? > > If IETF made a decision to discontinue any further discussion on fast rerouting > extensions to CRLDP, then will that functionality not being supported in CR-LDP? > > Thanks in advance. > > Yongjun. -- Loa Andersson Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Mobile +46 70 848 5038 Email loa.andersson@utfors.se From owner-mpls@UU.NET Tue Nov 19 08:17:31 2002 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 ESMTP id IAA04381 for ; Tue, 19 Nov 2002 08:17:30 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpqr15300 for ; Tue, 19 Nov 2002 13:20:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpqr13940; Tue, 19 Nov 2002 13:19:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpqr01613 for mpls-outgoing; Tue, 19 Nov 2002 13:19:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpqr01608 for ; Tue, 19 Nov 2002 13:19:05 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 QQnpqr24085 for ; Tue, 19 Nov 2002 13:18:28 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpqr26142 for ; Tue, 19 Nov 2002 13:18:28 GMT Received: from wiprom2mx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQnpqr26102 for ; Tue, 19 Nov 2002 13:18:26 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id gAJDIL128761 for ; Tue, 19 Nov 2002 18:48:24 +0530 (IST) Received: from soflt.ipneg.wipro.com ([10.117.3.193]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H5TRMG00.VJZ for ; Tue, 19 Nov 2002 18:48:16 +0530 Date: Tue, 19 Nov 2002 18:45:49 +0530 (IST) From: "chetan kumar s" X-X-Sender: Reply-To: To: Subject: Conflicting Resernation Style Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi All, The session attribute object as a flag 'SE Style desired', which mandates the egress to respond the resv message with SE style. Now if the Path refersh messages have conflicting flags, how is this handled. I was looking at the classical RSVP mailing list archive, found an interesting thread on this: http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/rsvp/1996-04/0068.html Any comments, especially comments on the response from Bob.. Thanks Chetan S -- ------------ Thinking is progress, non thinking is destruction of individual, organization and nation -Abdul Kalam From owner-mpls@UU.NET Tue Nov 19 10:38:14 2002 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 ESMTP id KAA07741 for ; Tue, 19 Nov 2002 10:38:13 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpra11244 for ; Tue, 19 Nov 2002 15:40:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpra09703; Tue, 19 Nov 2002 15:39:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpra16610 for mpls-outgoing; Tue, 19 Nov 2002 15:39:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpra16605 for ; Tue, 19 Nov 2002 15:39:35 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 QQnpra20698 for ; Tue, 19 Nov 2002 15:39:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpra08845 for ; Tue, 19 Nov 2002 15:39:05 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpra08839 for ; Tue, 19 Nov 2002 15:39:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA04203 for ; Tue, 19 Nov 2002 10:39:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJFd4C17498 for mpls@uu.net; Tue, 19 Nov 2002 10:39:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpra16568 for ; Tue, 19 Nov 2002 15:38:01 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 QQnpra08299 for ; Tue, 19 Nov 2002 15:37:12 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpra19782 for ; Tue, 19 Nov 2002 15:37:12 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnpra19776 for ; Tue, 19 Nov 2002 15:37:11 GMT Received: (qmail 17915 invoked by uid 104); 19 Nov 2002 15:36:56 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4233. . Clean. Processed in 0.576881 secs); 19 Nov 2002 15:36:56 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 19 Nov 2002 15:36:55 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id gAJFaiQ19370 for ; Tue, 19 Nov 2002 07:36:54 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Nov 2002 07:36:44 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03ABE@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'MPLS@UU.net'" Subject: Load balancing draft Date: Tue, 19 Nov 2002 07:36:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, One of the criticism for this draft was that it is designed to overcome Y.1711 limitation, in which a reserved label is used. As I mentioned in the meeting the MPLS-Ping also requires usage of an extra reserved label for non-IP carrying LSPs: "To test an LSP that carries non-IP traffic, before injecting ICMP and MPLS ping messages into the LSP, the IPv4 Explicit NULL label should be prepended to such messages." So this draft is equally applicable to MPLS-ping. Yours, Shahram From owner-mpls@UU.NET Tue Nov 19 10:42:19 2002 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 ESMTP id KAA07809 for ; Tue, 19 Nov 2002 10:42:18 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpra28116 for ; Tue, 19 Nov 2002 15:44:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpra26970; Tue, 19 Nov 2002 15:44:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpra17067 for mpls-outgoing; Tue, 19 Nov 2002 15:43:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpra17009 for ; Tue, 19 Nov 2002 15:43:41 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 QQnpra26299 for ; Tue, 19 Nov 2002 15:42:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpra24245 for ; Tue, 19 Nov 2002 15:42:37 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 QQnpra24232 for ; Tue, 19 Nov 2002 15:42:36 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 KAA13386 for ; Tue, 19 Nov 2002 10:42:35 -0500 (EST) 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 KAA07700 for ; Tue, 19 Nov 2002 10:42:35 -0500 (EST) Message-ID: <3DDA5BF0.5030605@marconi.com> Date: Tue, 19 Nov 2002 10:42:40 -0500 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: Conflicting Resernation Style References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit chetan kumar s wrote: > > The session attribute object as a flag 'SE Style desired', which > mandates the egress to respond the resv message with SE style. Now if the > Path refersh messages have conflicting flags, how is this handled. I was > looking at the classical RSVP mailing list archive, found an interesting > thread on this: > http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/rsvp/1996-04/0068.html You have one critical mistaken assumption here. The flags in SESSION_ATTRIBUTES are not mandatory. They are advisory. An egress node is free to ignore them if it wants to. This should also answer your second question. If the ingress signals a Path requesting SE style, and an SE style Resv is returned, and then the ingress refreshes that LSP (or perhaps creates another LSP in the same session) without the SE-style request, the egress node should simply ignore the change and continue sending back SE-style Resv messages. Now, if the egress node sends back two different Resv messages with two different styles, then the node detecting that conflict should generate a ResvErr message. But this shouldn't happen unless the egress node is broken. A style-conflict error should only happen in a multicast situation, where two different egress nodes for the same session choose different styles. -- David From owner-mpls@UU.NET Tue Nov 19 10:53:01 2002 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 ESMTP id KAA08022 for ; Tue, 19 Nov 2002 10:53:01 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprb28959 for ; Tue, 19 Nov 2002 15:55:36 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprb27227; Tue, 19 Nov 2002 15:54:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprb18323 for mpls-outgoing; Tue, 19 Nov 2002 15:54:20 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnprb18316 for ; Tue, 19 Nov 2002 15:54:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnprb11197 for ; Tue, 19 Nov 2002 15:53:46 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprb03503 for ; Tue, 19 Nov 2002 15:53:46 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQnprb03495 for ; Tue, 19 Nov 2002 15:53:46 GMT Received: from aatlas-lt.avici.com ([10.2.101.11]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id gAJFrXu18339; Tue, 19 Nov 2002 10:53:33 -0500 (EST) Message-Id: <5.1.0.14.2.20021119105042.01f41910@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Nov 2002 10:54:47 -0500 To: Shahram Davari From: Alia Atlas Subject: Re: Load balancing draft Cc: "'MPLS@UU.net'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03ABE@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk The concept of avoiding the reserved labels in an MPLS hash as a "best way" makes some sense, though it would probably only be gradually available as hardware changes. Doing this would make OAM work for pseudo-wires, where there is no underlying packet information which can be examined and where the TTL is fixed. But this does change fast-path hardware... Doing JUST that doesn't have bad impact on load-balancing of microflows (or identifying as small a microflow as possible). Alia At 07:36 AM 11/19/2002 -0800, Shahram Davari wrote: >Hi, > >One of the criticism for this draft was that it is designed to overcome >Y.1711 limitation, in which a reserved label is used. As I mentioned >in the meeting the MPLS-Ping also requires usage of an extra reserved >label for non-IP carrying LSPs: > > "To test an LSP that carries non-IP traffic, before injecting ICMP and > MPLS ping messages into the LSP, the IPv4 Explicit NULL label should > be prepended to such messages." > >So this draft is equally applicable to MPLS-ping. > >Yours, >Shahram From owner-mpls@UU.NET Tue Nov 19 11:04:19 2002 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 ESMTP id LAA08277 for ; Tue, 19 Nov 2002 11:04:18 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprc15029 for ; Tue, 19 Nov 2002 16:06:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprc12473; Tue, 19 Nov 2002 16:05:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprc06774 for mpls-outgoing; Tue, 19 Nov 2002 16:05:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnprc06759 for ; Tue, 19 Nov 2002 16:04: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 QQnprc18936 for ; Tue, 19 Nov 2002 16:04:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprc11139 for ; Tue, 19 Nov 2002 16:04:08 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnprc11132 for ; Tue, 19 Nov 2002 16:04:08 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08278 for ; Tue, 19 Nov 2002 11:04:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJG47g21882 for mpls@uu.net; Tue, 19 Nov 2002 11:04:07 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnprc05206 for ; Tue, 19 Nov 2002 16:03:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnprc02599 for ; Tue, 19 Nov 2002 16:02:26 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprc09654 for ; Tue, 19 Nov 2002 16:02:26 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnprc09645 for ; Tue, 19 Nov 2002 16:02:25 GMT Received: (qmail 7020 invoked by uid 104); 19 Nov 2002 16:02:24 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4233. . Clean. Processed in 0.550801 secs); 19 Nov 2002 16:02:24 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 19 Nov 2002 16:02:23 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id gAJG2NQ28732 for ; Tue, 19 Nov 2002 08:02:23 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Nov 2002 08:02:23 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03ABF@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'mpls@uu.net'" Subject: Requirements and solutions Date: Tue, 19 Nov 2002 08:02:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am very much troubled by a comment raised in MPLS meeting, that in the future the order of first requirements and then solution would quite often change and that hopefully it would not require any modification to the already approved solution. This may be acceptable in occasional cases (may be MPLS-ping is one of those cases), but I am not sure it is a good idea to make this as a general rule. Thanks, Shahram PS- Please not that my comment is not against MPLS-ping, rather about procedures. From owner-mpls@UU.NET Tue Nov 19 11:14:33 2002 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 ESMTP id LAA08557 for ; Tue, 19 Nov 2002 11:14:32 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprd28199 for ; Tue, 19 Nov 2002 16:17:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprd25762; Tue, 19 Nov 2002 16:15:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprd08918 for mpls-outgoing; Tue, 19 Nov 2002 16:15:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnprc08832 for ; Tue, 19 Nov 2002 16:14:54 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 QQnprc13816 for ; Tue, 19 Nov 2002 16:14:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprc24165 for ; Tue, 19 Nov 2002 16:14:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnprc24154 for ; Tue, 19 Nov 2002 16:14:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA09394 for ; Tue, 19 Nov 2002 11:14:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJGE6W24710 for mpls@uu.net; Tue, 19 Nov 2002 11:14:06 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnprc08732 for ; Tue, 19 Nov 2002 16:12: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 QQnprc17185 for ; Tue, 19 Nov 2002 16:12:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprc22732 for ; Tue, 19 Nov 2002 16:12:25 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnprc22717 for ; Tue, 19 Nov 2002 16:12:24 GMT Received: (qmail 4075 invoked by uid 104); 19 Nov 2002 16:12:23 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4233. . Clean. Processed in 1.526988 secs); 19 Nov 2002 16:12:23 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 19 Nov 2002 16:12:21 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id gAJGCLQ02101; Tue, 19 Nov 2002 08:12:21 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Nov 2002 08:12:21 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03AC1@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Gray, Eric'" , "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Tue, 19 Nov 2002 08:12:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric, Understood. -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Tuesday, November 19, 2002 11:09 AM > To: Shahram Davari; 'MPLS@UU.net' > Subject: RE: Load balancing draft > > > Shahram, > > I don't think the issue is whether or not people feel > that this work is applicable. I believe it might be better > to characterize the issue as whether or not it is practical > (or even feasible) to do this given stated constraints. > > As with QoS and other types of value add functionality, > the 9 letter acronym TANSTAAFL applies. There ain't no such > thing as a free lunch - in this case or in any other. Given > the current situation with respect to existing and deployed > hardware, about the only short term approach to ensure that > probe packets follow the data path is likely to be disabling > load sharing. > > In terms of specifying another approach, at least for > the alternatives discussed, these are potentially areas of > product differentiation and/or long term "fixes". Hence it > is probably not something we necessarily want to undertake > at this point. > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Tuesday, November 19, 2002 10:37 AM > > To: 'MPLS@UU.net' > > Subject: Load balancing draft > > > > Hi, > > > > One of the criticism for this draft was that it is designed > to overcome > > Y.1711 limitation, in which a reserved label is used. As I mentioned > > in the meeting the MPLS-Ping also requires usage of an > extra reserved > > label for non-IP carrying LSPs: > > > > "To test an LSP that carries non-IP traffic, before > injecting ICMP and > > MPLS ping messages into the LSP, the IPv4 Explicit NULL > label should > > be prepended to such messages." > > > > So this draft is equally applicable to MPLS-ping. > > > > Yours, > > Shahram > From owner-mpls@UU.NET Tue Nov 19 11:23:24 2002 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 ESMTP id LAA08779 for ; Tue, 19 Nov 2002 11:23:23 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprd01927 for ; Tue, 19 Nov 2002 16:26:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprd00465; Tue, 19 Nov 2002 16:25:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprd10027 for mpls-outgoing; Tue, 19 Nov 2002 16:25:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnprd10016 for ; Tue, 19 Nov 2002 16:25:02 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 QQnprd29564 for ; Tue, 19 Nov 2002 16:24:55 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprd07316 for ; Tue, 19 Nov 2002 16:24:55 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnprd07312 for ; Tue, 19 Nov 2002 16:24:55 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 11:09:29 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ECA0@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Shahram Davari'" , "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Tue, 19 Nov 2002 11:09:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Shahram, I don't think the issue is whether or not people feel that this work is applicable. I believe it might be better to characterize the issue as whether or not it is practical (or even feasible) to do this given stated constraints. As with QoS and other types of value add functionality, the 9 letter acronym TANSTAAFL applies. There ain't no such thing as a free lunch - in this case or in any other. Given the current situation with respect to existing and deployed hardware, about the only short term approach to ensure that probe packets follow the data path is likely to be disabling load sharing. In terms of specifying another approach, at least for the alternatives discussed, these are potentially areas of product differentiation and/or long term "fixes". Hence it is probably not something we necessarily want to undertake at this point. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Tuesday, November 19, 2002 10:37 AM > To: 'MPLS@UU.net' > Subject: Load balancing draft > > Hi, > > One of the criticism for this draft was that it is designed to overcome > Y.1711 limitation, in which a reserved label is used. As I mentioned > in the meeting the MPLS-Ping also requires usage of an extra reserved > label for non-IP carrying LSPs: > > "To test an LSP that carries non-IP traffic, before injecting ICMP and > MPLS ping messages into the LSP, the IPv4 Explicit NULL label should > be prepended to such messages." > > So this draft is equally applicable to MPLS-ping. > > Yours, > Shahram From owner-mpls@UU.NET Tue Nov 19 11:26:59 2002 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 ESMTP id LAA08896 for ; Tue, 19 Nov 2002 11:26:58 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprd09846 for ; Tue, 19 Nov 2002 16:29:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprd01054; Tue, 19 Nov 2002 16:25:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprd10032 for mpls-outgoing; Tue, 19 Nov 2002 16:25:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnprd10021 for ; Tue, 19 Nov 2002 16:25: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 QQnprd29592 for ; Tue, 19 Nov 2002 16:24:56 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprd00049 for ; Tue, 19 Nov 2002 16:24:55 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnprd00043 for ; Tue, 19 Nov 2002 16:24:55 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 11:20:20 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ECA1@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: Requirements and solutions Date: Tue, 19 Nov 2002 11:20:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Shahram, We need to be a little less retentive about terms, documents and ordering. A lot of the time in the IETF, work starts without a formal requirements document. This is because some set of people - nearly always including authors and often including several others as well - believe they understand the requirements well enough without formally documenting them. In many cases, a requirements statement of a sort is included in the draft abstract and/or introduction. Lately, there is a lot of preoccupation with the need for formality. A point I believe was made today is that it is possible for a requirements document to proceed in parallel and the results compared in an applicability document. This is quite reasonable. While some people said something to the effect that - in the event that they don't match up well - a mismatch is an indication of failure on the part of the original draft authors to develop something useful. I think one could go further and argue that the mismatch may be an indication of future work that may be needed for subsequent versions of the work already done. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Tuesday, November 19, 2002 11:02 AM > To: 'mpls@uu.net' > Subject: Requirements and solutions > > Hi, > > I am very much troubled by a comment raised in MPLS meeting, that > in the future the order of first requirements and then solution would > quite often change and that hopefully it would not require any > modification > to the already approved solution. > > This may be acceptable in occasional cases (may be MPLS-ping > is one of those cases), but I am not sure it is a good idea > to make this as a general rule. > > > Thanks, > Shahram > > PS- Please not that my comment is not against MPLS-ping, rather about > procedures. From owner-mpls@UU.NET Tue Nov 19 13:18:05 2002 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 ESMTP id NAA11908 for ; Tue, 19 Nov 2002 13:18:05 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprl18934 for ; Tue, 19 Nov 2002 18:20:37 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprl16402; Tue, 19 Nov 2002 18:19:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprl26315 for mpls-outgoing; Tue, 19 Nov 2002 18:18:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnprl26310 for ; Tue, 19 Nov 2002 18:18:46 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 QQnprl10809 for ; Tue, 19 Nov 2002 18:17:09 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprl06638 for ; Tue, 19 Nov 2002 18:17:08 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnprl06619 for ; Tue, 19 Nov 2002 18:17:08 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20325 for ; Tue, 19 Nov 2002 13:17:07 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJIH7x04738 for mpls@uu.net; Tue, 19 Nov 2002 13:17:07 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnprl26041 for ; Tue, 19 Nov 2002 18:15:41 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 QQnprk12479 for ; Tue, 19 Nov 2002 18:14:57 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprk03824 for ; Tue, 19 Nov 2002 18:14:56 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnprk03812 for ; Tue, 19 Nov 2002 18:14:55 GMT Received: (qmail 9346 invoked by uid 104); 19 Nov 2002 18:14:55 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4233. . Clean. Processed in 1.416245 secs); 19 Nov 2002 18:14:55 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 19 Nov 2002 18:14:53 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id gAJIEqQ20015; Tue, 19 Nov 2002 10:14:52 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Nov 2002 10:14:52 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03AC3@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Gray, Eric'" , "'mpls@uu.net'" Subject: RE: Requirements and solutions Date: Tue, 19 Nov 2002 10:14:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric, As I said in my email, this is not a rule that is written in stone (like ten commandments). But I think it should be the general practice. I understand that in some cases, solution is developed without formal requirements. But I am wondering whether a follow up requirements RFC makes sense in those cases. Yours, -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Tuesday, November 19, 2002 11:20 AM > To: Shahram Davari; 'mpls@uu.net' > Subject: RE: Requirements and solutions > > > Shahram, > > We need to be a little less retentive about terms, > documents and ordering. > > A lot of the time in the IETF, work starts without > a formal requirements document. This is because some set > of people - nearly always including authors and often > including several others as well - believe they understand > the requirements well enough without formally documenting > them. In many cases, a requirements statement of a sort > is included in the draft abstract and/or introduction. > > Lately, there is a lot of preoccupation with the > need for formality. A point I believe was made today is > that it is possible for a requirements document to proceed > in parallel and the results compared in an applicability > document. This is quite reasonable. > > While some people said something to the effect that - > in the event that they don't match up well - a mismatch is > an indication of failure on the part of the original draft > authors to develop something useful. I think one could go > further and argue that the mismatch may be an indication > of future work that may be needed for subsequent versions > of the work already done. > > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Tuesday, November 19, 2002 11:02 AM > > To: 'mpls@uu.net' > > Subject: Requirements and solutions > > > > Hi, > > > > I am very much troubled by a comment raised in MPLS meeting, that > > in the future the order of first requirements and then > solution would > > quite often change and that hopefully it would not require any > > modification > > to the already approved solution. > > > > This may be acceptable in occasional cases (may be MPLS-ping > > is one of those cases), but I am not sure it is a good idea > > to make this as a general rule. > > > > > > Thanks, > > Shahram > > > > PS- Please not that my comment is not against MPLS-ping, > rather about > > procedures. > From owner-mpls@UU.NET Tue Nov 19 13:29:30 2002 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 ESMTP id NAA12144 for ; Tue, 19 Nov 2002 13:29:30 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprm02475 for ; Tue, 19 Nov 2002 18:32:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprm29382; Tue, 19 Nov 2002 18:30:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprm27365 for mpls-outgoing; Tue, 19 Nov 2002 18:30:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnprm27353 for ; Tue, 19 Nov 2002 18:30:04 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 QQnprl20166 for ; Tue, 19 Nov 2002 18:29:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprl17849 for ; Tue, 19 Nov 2002 18:29:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnprl17843 for ; Tue, 19 Nov 2002 18:29:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA21325 for ; Tue, 19 Nov 2002 13:29:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJIT6k07703 for mpls@uu.net; Tue, 19 Nov 2002 13:29:06 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnprl27270 for ; Tue, 19 Nov 2002 18:28:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnprl05615 for ; Tue, 19 Nov 2002 18:28:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprl17043 for ; Tue, 19 Nov 2002 18:28:10 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnprl17027 for ; Tue, 19 Nov 2002 18:28:09 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJIRc22013762; Tue, 19 Nov 2002 13:27:39 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn2-304.cisco.com [10.82.241.48]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD43148; Tue, 19 Nov 2002 13:27:14 -0500 (EST) Message-Id: <5.2.0.9.2.20021119132310.02216b50@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Nov 2002 13:27:07 -0500 To: Alia Atlas From: "Thomas D. Nadeau" Subject: Re: Load balancing draft Cc: Shahram Davari , "'MPLS@UU.net'" In-Reply-To: <5.1.0.14.2.20021119105042.01f41910@mailhost.avici.com> References: <4B6D09F3B826D411A67300D0B706EFDEB03ABE@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >The concept of avoiding the reserved labels in an MPLS hash as a "best >way" makes some sense, Does this mean that we then have to mandate how IP (L2TPV3) does traffic distribution too? What is next? I think that this solution looks good in theory, but in practice there are huge problems with it. >though it would probably only be gradually available as hardware changes. Kireeti or you made a good point that this solution is not evolutionary; it is revolutionary as it will require hardware changes. On the surface it might sound reasonable to say that well, hardware will evolve and as it does it must support this sort of load-balancing. However, the fact of the matter is that one size does not fit all in this case, and thus this will be a burden on both existing and future implementations. --Tom >Doing this would make OAM work for pseudo-wires, where there is no >underlying packet information which can be examined and where the TTL is fixed. > >But this does change fast-path hardware... > >Doing JUST that doesn't have bad impact on load-balancing of microflows >(or identifying as small a microflow as possible). > >Alia > >At 07:36 AM 11/19/2002 -0800, Shahram Davari wrote: >>Hi, >> >>One of the criticism for this draft was that it is designed to overcome >>Y.1711 limitation, in which a reserved label is used. As I mentioned >>in the meeting the MPLS-Ping also requires usage of an extra reserved >>label for non-IP carrying LSPs: >> >> "To test an LSP that carries non-IP traffic, before injecting ICMP and >> MPLS ping messages into the LSP, the IPv4 Explicit NULL label should >> be prepended to such messages." >> >>So this draft is equally applicable to MPLS-ping. >> >>Yours, >>Shahram > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Tue Nov 19 13:35:03 2002 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 ESMTP id NAA12277 for ; Tue, 19 Nov 2002 13:35:02 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprm12163 for ; Tue, 19 Nov 2002 18:37:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprm10073; Tue, 19 Nov 2002 18:36:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprm27980 for mpls-outgoing; Tue, 19 Nov 2002 18:36:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnprm27877 for ; Tue, 19 Nov 2002 18:35:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnprm21541 for ; Tue, 19 Nov 2002 18:34:46 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprm23346 for ; Tue, 19 Nov 2002 18:34:45 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnprm23326 for ; Tue, 19 Nov 2002 18:34:45 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA21910 for ; Tue, 19 Nov 2002 13:34:44 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJIYiY08334 for mpls@uu.net; Tue, 19 Nov 2002 13:34:44 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnprm27623 for ; Tue, 19 Nov 2002 18:32:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnprm04855 for ; Tue, 19 Nov 2002 18:31:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprm19876 for ; Tue, 19 Nov 2002 18:31:36 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnprm19867 for ; Tue, 19 Nov 2002 18:31:36 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJIVuTB014349; Tue, 19 Nov 2002 13:31:56 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn2-304.cisco.com [10.82.241.48]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD43274; Tue, 19 Nov 2002 13:31:31 -0500 (EST) Message-Id: <5.2.0.9.2.20021119132949.02231420@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Nov 2002 13:31:23 -0500 To: "Gray, Eric" From: "Thomas D. Nadeau" Subject: RE: Requirements and solutions Cc: "'Shahram Davari'" , "'mpls@uu.net'" In-Reply-To: <1117F7D44159934FB116E36F4ABF221B0267ECA1@celox-ma1-ems1.ce loxnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:20 AM 11/19/2002 -0500, Gray, Eric wrote: >Shahram, > > We need to be a little less retentive about terms, >documents and ordering. > > A lot of the time in the IETF, work starts without >a formal requirements document. This is because some set >of people - nearly always including authors and often >including several others as well - believe they understand >the requirements well enough without formally documenting >them. In many cases, a requirements statement of a sort >is included in the draft abstract and/or introduction. > > Lately, there is a lot of preoccupation with the >need for formality. A point I believe was made today is >that it is possible for a requirements document to proceed >in parallel and the results compared in an applicability >document. This is quite reasonable. > > While some people said something to the effect that - >in the event that they don't match up well - a mismatch is >an indication of failure on the part of the original draft >authors to develop something useful. I think one could go >further and argue that the mismatch may be an indication >of future work that may be needed for subsequent versions >of the work already done. I totally agree. Many people much smarter than us have tried to produce the grandest, most perfect solutions from the start and failed. IMHO, a mismatch is a reason to just iterate again to evolve the solution. --Tom >Eric W. Gray >Systems Architect >Celox Networks, Inc. >egray@celoxnetworks.com >508 305 7214 > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Tuesday, November 19, 2002 11:02 AM > > To: 'mpls@uu.net' > > Subject: Requirements and solutions > > > > Hi, > > > > I am very much troubled by a comment raised in MPLS meeting, that > > in the future the order of first requirements and then solution would > > quite often change and that hopefully it would not require any > > modification > > to the already approved solution. > > > > This may be acceptable in occasional cases (may be MPLS-ping > > is one of those cases), but I am not sure it is a good idea > > to make this as a general rule. > > > > > > Thanks, > > Shahram > > > > PS- Please not that my comment is not against MPLS-ping, rather about > > procedures. Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Tue Nov 19 13:41:26 2002 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 ESMTP id NAA12530 for ; Tue, 19 Nov 2002 13:41:25 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprm06345 for ; Tue, 19 Nov 2002 18:44:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprm04853; Tue, 19 Nov 2002 18:43:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprm28651 for mpls-outgoing; Tue, 19 Nov 2002 18:42:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnprm28645 for ; Tue, 19 Nov 2002 18:42:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnprm10126 for ; Tue, 19 Nov 2002 18:42:24 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprm01969 for ; Tue, 19 Nov 2002 18:42:24 GMT Received: from mailhost.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQnprm01956 for ; Tue, 19 Nov 2002 18:42:23 GMT Received: from aatlas-lt.avici.com ([10.2.101.15]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id gAJIg8u06863; Tue, 19 Nov 2002 13:42:08 -0500 (EST) Message-Id: <5.1.0.14.2.20021119133246.01f9c1f0@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Nov 2002 13:43:26 -0500 To: "Thomas D. Nadeau" From: Alia Atlas Subject: Re: Load balancing draft Cc: Shahram Davari , "'MPLS@UU.net'" In-Reply-To: <5.2.0.9.2.20021119132310.02216b50@bucket.cisco.com> References: <5.1.0.14.2.20021119105042.01f41910@mailhost.avici.com> <4B6D09F3B826D411A67300D0B706EFDEB03ABE@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk The idea is not to mandate how traffic distribution is done. It's to say that the reserved labels should be excluded from consideration in determining that. I'm certainly against anything which increases the size of the microflows which can be load-balanced - this doesn't do that, b/c only the OAM packets would have those reserved labels. Which huge problems are you seeing with this? I'm not saying that it should be mandated in anyway, simply that it may be superior design, if one chose to implement it thusly. Absolutely, this isn't something to be required and it is revolutionary in that it requires hardware changes. I don't see how it is a burden on existing and future implementations; it is a suggestion for how to make the ECMP friendlier. Didn't we also have discussions about how routers should do microflow classification for the load-balancing instead of doing round-robin to avoid microflow reordering? And that is not what all routers do or, probably, will ever do depending on where in the network they are... Alia At 01:27 PM 11/19/2002 -0500, Thomas D. Nadeau wrote: >>The concept of avoiding the reserved labels in an MPLS hash as a "best >>way" makes some sense, > > > Does this mean that we then have to mandate how IP (L2TPV3) does >traffic distribution too? What is next? I think that this solution looks >good in theory, but in practice there are huge problems with it. > >>though it would probably only be gradually available as hardware changes. > > Kireeti or you made a good point that >this solution is not evolutionary; it is revolutionary as it will require >hardware changes. On the surface it might sound reasonable to >say that well, hardware will evolve and as it does it must support >this sort of load-balancing. However, the fact of the matter is that >one size does not fit all in this case, and thus this will be a burden >on both existing and future implementations. > > --Tom > >>Doing this would make OAM work for pseudo-wires, where there is no >>underlying packet information which can be examined and where the TTL is fixed. >> >>But this does change fast-path hardware... >> >>Doing JUST that doesn't have bad impact on load-balancing of microflows >>(or identifying as small a microflow as possible). >> >>Alia >> >>At 07:36 AM 11/19/2002 -0800, Shahram Davari wrote: >>>Hi, >>> >>>One of the criticism for this draft was that it is designed to overcome >>>Y.1711 limitation, in which a reserved label is used. As I mentioned >>>in the meeting the MPLS-Ping also requires usage of an extra reserved >>>label for non-IP carrying LSPs: >>> >>> "To test an LSP that carries non-IP traffic, before injecting ICMP and >>> MPLS ping messages into the LSP, the IPv4 Explicit NULL label should >>> be prepended to such messages." >>> >>>So this draft is equally applicable to MPLS-ping. >>> >>>Yours, >>>Shahram > >Success is relative; the more success, the more relatives. -Anonymous > > From owner-mpls@UU.NET Tue Nov 19 13:44:18 2002 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 ESMTP id NAA12644 for ; Tue, 19 Nov 2002 13:44:18 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprn24525 for ; Tue, 19 Nov 2002 18:46:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprn22200; Tue, 19 Nov 2002 18:45:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprn29020 for mpls-outgoing; Tue, 19 Nov 2002 18:45:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnprm28802 for ; Tue, 19 Nov 2002 18:44: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 QQnprm17137 for ; Tue, 19 Nov 2002 18:43:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprm03001 for ; Tue, 19 Nov 2002 18:43:41 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnprm02990 for ; Tue, 19 Nov 2002 18:43:41 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA22809 for ; Tue, 19 Nov 2002 13:43:40 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJIhe211420 for mpls@uu.net; Tue, 19 Nov 2002 13:43:40 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnprm28545 for ; Tue, 19 Nov 2002 18:42: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 QQnprm09940 for ; Tue, 19 Nov 2002 18:41:28 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprm18769 for ; Tue, 19 Nov 2002 18:41:25 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: amsterdam.cisco.com [144.254.74.238]) id QQnprm18715 for ; Tue, 19 Nov 2002 18:41:23 GMT Received: from MMORROW-W2K2.cisco.com (rtp-vpn2-135.cisco.com [10.82.240.135]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA08630; Tue, 19 Nov 2002 19:40:38 +0100 (MET) Message-Id: <4.3.2.7.2.20021119193202.039d8258@amsterdam.cisco.com> X-Sender: mmorrow@amsterdam.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Nov 2002 19:40:38 +0100 To: Shahram Davari From: Monique Morrow Subject: RE: Requirements and solutions Cc: "'Gray, Eric'" , "'mpls@uu.net'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03AC3@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Shahram, I believe that we are all striving for a balance between pragmatism and architectural perfectionism - the former being dictated by immediate customer needs. Kireeti has suggested that we run due diligence of these requirements against the proposed solution --- something that is reasonable and can be done in parallel IMHO. Customers want solutions now not later and certainly, we can dialogue on evolving these requirements to the short-term, mid-term and long-term proposed implementations as these develop. Looking forward to a prolific collaborative effort Shahram - Best regards, Monique >Eric, > >As I said in my email, this is not a rule that is written in stone >(like ten commandments). But I think it should be the general practice. > >I understand that in some cases, solution is developed without formal >requirements. But I am wondering whether a follow up requirements RFC >makes sense in those cases. > >Yours, >-Shahram > > > > -----Original Message----- > > From: Gray, Eric [mailto:egray@celoxnetworks.com] > > Sent: Tuesday, November 19, 2002 11:20 AM > > To: Shahram Davari; 'mpls@uu.net' > > Subject: RE: Requirements and solutions > > > > > > Shahram, > > > > We need to be a little less retentive about terms, > > documents and ordering. > > > > A lot of the time in the IETF, work starts without > > a formal requirements document. This is because some set > > of people - nearly always including authors and often > > including several others as well - believe they understand > > the requirements well enough without formally documenting > > them. In many cases, a requirements statement of a sort > > is included in the draft abstract and/or introduction. > > > > Lately, there is a lot of preoccupation with the > > need for formality. A point I believe was made today is > > that it is possible for a requirements document to proceed > > in parallel and the results compared in an applicability > > document. This is quite reasonable. > > > > While some people said something to the effect that - > > in the event that they don't match up well - a mismatch is > > an indication of failure on the part of the original draft > > authors to develop something useful. I think one could go > > further and argue that the mismatch may be an indication > > of future work that may be needed for subsequent versions > > of the work already done. > > > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Tuesday, November 19, 2002 11:02 AM > > > To: 'mpls@uu.net' > > > Subject: Requirements and solutions > > > > > > Hi, > > > > > > I am very much troubled by a comment raised in MPLS meeting, that > > > in the future the order of first requirements and then > > solution would > > > quite often change and that hopefully it would not require any > > > modification > > > to the already approved solution. > > > > > > This may be acceptable in occasional cases (may be MPLS-ping > > > is one of those cases), but I am not sure it is a good idea > > > to make this as a general rule. > > > > > > > > > Thanks, > > > Shahram > > > > > > PS- Please not that my comment is not against MPLS-ping, > > rather about > > > procedures. > > From owner-mpls@UU.NET Tue Nov 19 13:51:38 2002 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 ESMTP id NAA12925 for ; Tue, 19 Nov 2002 13:51:38 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprn12687 for ; Tue, 19 Nov 2002 18:54:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprn11162; Tue, 19 Nov 2002 18:53:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprn00103 for mpls-outgoing; Tue, 19 Nov 2002 18:53:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnprn00098 for ; Tue, 19 Nov 2002 18:53:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnprn05635 for ; Tue, 19 Nov 2002 18:52:53 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprn19300 for ; Tue, 19 Nov 2002 18:52:52 GMT Received: from mail.san.yahoo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQnprn19296 for ; Tue, 19 Nov 2002 18:52:52 GMT Received: from AwducheHPlapt (68.100.184.228) by mail.san.yahoo.com (6.5.029) id 3DDA845D00001E2A; Tue, 19 Nov 2002 10:49:33 -0800 Reply-To: From: "Daniel O. Awduche" To: "'Shahram Davari'" , "'Gray, Eric'" , "'mpls@uu.net'" Subject: RE: Requirements and solutions Date: Tue, 19 Nov 2002 13:51:37 -0500 Message-ID: <001e01c28ffc$b1336060$e4b86444@awduche.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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03AC3@nt-exch-yow.pmc-sierra.bc.ca> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram, This issue can be trivially resolved through an applicability statement. The applicability statement may outline pertinent requirements concerning a particular deployment context, and indicate if and how the target specifications address the requirements. Cheers, /Dan -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Shahram Davari Sent: Tuesday, November 19, 2002 1:15 PM To: 'Gray, Eric'; 'mpls@uu.net' Subject: RE: Requirements and solutions Eric, As I said in my email, this is not a rule that is written in stone (like ten commandments). But I think it should be the general practice. I understand that in some cases, solution is developed without formal requirements. But I am wondering whether a follow up requirements RFC makes sense in those cases. Yours, -Shahram > -----Original Message----- > From: Gray, Eric [mailto:egray@celoxnetworks.com] > Sent: Tuesday, November 19, 2002 11:20 AM > To: Shahram Davari; 'mpls@uu.net' > Subject: RE: Requirements and solutions > > > Shahram, > > We need to be a little less retentive about terms, > documents and ordering. > > A lot of the time in the IETF, work starts without > a formal requirements document. This is because some set > of people - nearly always including authors and often > including several others as well - believe they understand > the requirements well enough without formally documenting > them. In many cases, a requirements statement of a sort > is included in the draft abstract and/or introduction. > > Lately, there is a lot of preoccupation with the > need for formality. A point I believe was made today is > that it is possible for a requirements document to proceed > in parallel and the results compared in an applicability document. > This is quite reasonable. > > While some people said something to the effect that - > in the event that they don't match up well - a mismatch is > an indication of failure on the part of the original draft authors to > develop something useful. I think one could go further and argue that > the mismatch may be an indication of future work that may be needed > for subsequent versions of the work already done. > > > Eric W. Gray > Systems Architect > Celox Networks, Inc. > egray@celoxnetworks.com > 508 305 7214 > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Tuesday, November 19, 2002 11:02 AM > > To: 'mpls@uu.net' > > Subject: Requirements and solutions > > > > Hi, > > > > I am very much troubled by a comment raised in MPLS meeting, that in > > the future the order of first requirements and then > solution would > > quite often change and that hopefully it would not require any > > modification to the already approved solution. > > > > This may be acceptable in occasional cases (may be MPLS-ping is one > > of those cases), but I am not sure it is a good idea to make this as > > a general rule. > > > > > > Thanks, > > Shahram > > > > PS- Please not that my comment is not against MPLS-ping, > rather about > > procedures. > From owner-mpls@UU.NET Tue Nov 19 14:05:22 2002 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 ESMTP id OAA13383 for ; Tue, 19 Nov 2002 14:05:22 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpro00690 for ; Tue, 19 Nov 2002 19:07:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpro27844; Tue, 19 Nov 2002 19:06:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpro18640 for mpls-outgoing; Tue, 19 Nov 2002 19:05:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpro18623 for ; Tue, 19 Nov 2002 19:05: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 QQnpro24573 for ; Tue, 19 Nov 2002 19:04:19 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpro27361 for ; Tue, 19 Nov 2002 19:04:18 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpro27344 for ; Tue, 19 Nov 2002 19:04:18 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24761 for ; Tue, 19 Nov 2002 14:04:17 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJJ4HI14352 for mpls@uu.net; Tue, 19 Nov 2002 14:04:17 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpro16857 for ; Tue, 19 Nov 2002 19:03:18 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 QQnpro10504 for ; Tue, 19 Nov 2002 19:02:41 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpro25334 for ; Tue, 19 Nov 2002 19:02:41 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnpro25325 for ; Tue, 19 Nov 2002 19:02:40 GMT Received: (qmail 20395 invoked by uid 104); 19 Nov 2002 19:02:40 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4233. . Clean. Processed in 0.517338 secs); 19 Nov 2002 19:02:40 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 19 Nov 2002 19:02:39 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id gAJJ2cQ09928; Tue, 19 Nov 2002 11:02:39 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Nov 2002 11:02:38 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03AC5@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Monique Morrow'" Cc: "'Gray, Eric'" , "'mpls@uu.net'" Subject: RE: Requirements and solutions Date: Tue, 19 Nov 2002 11:02:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Monique, I totally agree with you that customers need should be taken to account first. And I have no problem with MPLS-ping or the requirements doc. I understand the urgency, but to get a response in the meeting that people should get used to this kind of process, and expect more to happen in the future was a bit surprising to me. Thanks, -Shahram > -----Original Message----- > From: Monique Morrow [mailto:mmorrow@cisco.com] > Sent: Tuesday, November 19, 2002 1:41 PM > To: Shahram Davari > Cc: 'Gray, Eric'; 'mpls@uu.net' > Subject: RE: Requirements and solutions > > > Shahram, > > I believe that we are all striving for a balance between > pragmatism and > architectural perfectionism - the former being dictated by immediate > customer needs. > > Kireeti has suggested that we run due diligence of these requirements > against the proposed solution --- something that is > reasonable and can be > done in parallel IMHO. > Customers want solutions now not later and certainly, we can > dialogue on > evolving these requirements to the short-term, mid-term and long-term > proposed implementations as these develop. > > Looking forward to a prolific collaborative effort Shahram - > > Best regards, > > >Eric, > > > >As I said in my email, this is not a rule that is written in stone > >(like ten commandments). But I think it should be the > general practice. > > > >I understand that in some cases, solution is developed without formal > >requirements. But I am wondering whether a follow up requirements RFC > >makes sense in those cases. > > > >Yours, > >-Shahram > > > > > > > -----Original Message----- > > > From: Gray, Eric [mailto:egray@celoxnetworks.com] > > > Sent: Tuesday, November 19, 2002 11:20 AM > > > To: Shahram Davari; 'mpls@uu.net' > > > Subject: RE: Requirements and solutions > > > > > > > > > Shahram, > > > > > > We need to be a little less retentive about terms, > > > documents and ordering. > > > > > > A lot of the time in the IETF, work starts without > > > a formal requirements document. This is because some set > > > of people - nearly always including authors and often > > > including several others as well - believe they understand > > > the requirements well enough without formally documenting > > > them. In many cases, a requirements statement of a sort > > > is included in the draft abstract and/or introduction. > > > > > > Lately, there is a lot of preoccupation with the > > > need for formality. A point I believe was made today is > > > that it is possible for a requirements document to proceed > > > in parallel and the results compared in an applicability > > > document. This is quite reasonable. > > > > > > While some people said something to the effect that - > > > in the event that they don't match up well - a mismatch is > > > an indication of failure on the part of the original draft > > > authors to develop something useful. I think one could go > > > further and argue that the mismatch may be an indication > > > of future work that may be needed for subsequent versions > > > of the work already done. > > > > > > > > > Eric W. Gray > > > Systems Architect > > > Celox Networks, Inc. > > > egray@celoxnetworks.com > > > 508 305 7214 > > > > > > > > > > -----Original Message----- > > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > > Sent: Tuesday, November 19, 2002 11:02 AM > > > > To: 'mpls@uu.net' > > > > Subject: Requirements and solutions > > > > > > > > Hi, > > > > > > > > I am very much troubled by a comment raised in MPLS > meeting, that > > > > in the future the order of first requirements and then > > > solution would > > > > quite often change and that hopefully it would not require any > > > > modification > > > > to the already approved solution. > > > > > > > > This may be acceptable in occasional cases (may be MPLS-ping > > > > is one of those cases), but I am not sure it is a good idea > > > > to make this as a general rule. > > > > > > > > > > > > Thanks, > > > > Shahram > > > > > > > > PS- Please not that my comment is not against MPLS-ping, > > > rather about > > > > procedures. > > > > From owner-mpls@UU.NET Tue Nov 19 15:23:34 2002 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 ESMTP id PAA15578 for ; Tue, 19 Nov 2002 15:23:33 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprt29864 for ; Tue, 19 Nov 2002 20:26:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprt28244; Tue, 19 Nov 2002 20:25:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprt16771 for mpls-outgoing; Tue, 19 Nov 2002 20:24:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnprt16761 for ; Tue, 19 Nov 2002 20:24:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnprt16955 for ; Tue, 19 Nov 2002 20:24:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprt18259 for ; Tue, 19 Nov 2002 20:24:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnprt18251 for ; Tue, 19 Nov 2002 20:24:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA01960 for ; Tue, 19 Nov 2002 15:24:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJKO5U21835 for mpls@uu.net; Tue, 19 Nov 2002 15:24:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnprt16712 for ; Tue, 19 Nov 2002 20:22: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 QQnprt01317 for ; Tue, 19 Nov 2002 20:22:25 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprt16414 for ; Tue, 19 Nov 2002 20:22:24 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: london2.cisco.com [64.103.110.74]) id QQnprt16405 for ; Tue, 19 Nov 2002 20:22:24 GMT Received: from JGUICHARW2K (che-vpn-cluster-1-77.cisco.com [10.86.240.77]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id UAA09792; Tue, 19 Nov 2002 20:22:16 GMT From: "Jim Guichard" To: "David Allan" , "Michael H. Behringer" Cc: Subject: RE: draft-behringer-mpls-security-03.txt Date: Tue, 19 Nov 2002 15:18:22 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <9FBD322B7824D511B36900508BF93C9C06150C69@zcard031.ca.nortel.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, sorry for the late response but I have been travelling .. first off, the draft we are talking about is draft-behringer-mpls-vpn-auth-00 and not draft-behringer-mpls-security-03 (I am not a co-author of this draft and have no involvment with it). second - the draft which is posted at the ietf website is the incorrect version and was posted in error - I have the correct version sat here on my laptop but have been unable to re-post until after ietf - I will do this next week. Some comments below .. > >-----Original Message----- > >From: David Allan [mailto:dallan@nortelnetworks.com] > >Sent: Friday, November 15, 2002 10:18 AM > >To: Michael H. Behringer; jguichar@cisco.com > >Cc: mpls@UU.NET > >Subject: draft-behringer-mpls-security-03.txt > > > > > >Michael/Jim: > > > >If I understand the problem you are addressing correctly, it is incorrect > >configuration of the RT associated with a CE at the PE. And you > >wish to do > >this with no changes to the CE, therefore you are re-using the HMAC/MD5 > >stuff to achieve this. correct > > > >What you actually want is the RT configured at the CE and a means of > >checking that there is consistency between the CE and PE. currently the RT belongs to the SP and is maintained/provisioned by the SP - the customer has no involvement or knowledge of this process. Theoretically the customer could tell the SP the RT value it should use for its VPN but then this would be subject to a) overlap with other VPNs & b) difficult to implement into the existing provisioning platforms. This means that the SP would have to tell the customer which RT value to use, which they might get wrong and we are back to square-one. IMHO adding a > >level of indirection (two provisioned values to get right at the > >PE) in the > >network will not achieve this. well it will if the customer provides the key and then routing is authenticated using this key across the SP to customer connections. > > > >What I would suggest is that you keep the HMAC/MD5 approach for > >CE-PE in which case the PE must still be configured with a key to facilitate routing authentication. , but > >have the key configured into the CE algorithmically derived from the RT > >associated with the VRF (or from the set of RTs in more complex > >configuration cases). Therefore there is still typically only > >one value to > >provision at the PE for the CE (the RT, which is the one that > >matters). You > >are not using multiple values across the core (HMAC MD5 and RTs, you only > >need RTs) so no BGP changes are required, this is purely a S/W > >issue at the > >PE. the correct draft specifies that an ingress PE uses a 'generator' value (which is a random number at the PE) and creates a signature by using the key against the 'generator'. The result of this operation is carried within BGP so that a receiving PE can run its local key against the 'generator' and compare the result with the signature that was created by the originating PE. Jim > > > >The only issue I can see is that in the more complex VPN cases (hub and > >spoke/extranet etc.), there is not one key for all CEs, (e.g. hub site is > >different key than a spoke site or extranet issues). This seems > >like a small > >price for no protocol changes and actually closing the hole. Besides I > >believe a CE can belong to more than one VPN therefore without > >this approach > >there is still a gaping head wound as it can only verify > >membership in one > >VPN. > > > >cheers > >Dave From owner-mpls@UU.NET Tue Nov 19 16:24:38 2002 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 ESMTP id QAA17014 for ; Tue, 19 Nov 2002 16:24:38 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprx15996 for ; Tue, 19 Nov 2002 21:27:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprx14356; Tue, 19 Nov 2002 21:26:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprx11125 for mpls-outgoing; Tue, 19 Nov 2002 21:26:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnprx11028 for ; Tue, 19 Nov 2002 21:26:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnprx16791 for ; Tue, 19 Nov 2002 21:25:58 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprx17099 for ; Tue, 19 Nov 2002 21:25:57 GMT Received: from lxmail.xebeo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.xebeo.com [204.192.44.242]) id QQnprx17086 for ; Tue, 19 Nov 2002 21:25:57 GMT Received: (qmail 15131 invoked from network); 19 Nov 2002 21:25:57 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 19 Nov 2002 21:25:57 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id QAA10835 for ; Tue, 19 Nov 2002 16:25:57 -0500 Message-Id: <200211192125.QAA10835@bigbird.xebeo.com> To: mpls@UU.NET Subject: bi-directional LSPs Date: Tue, 19 Nov 2002 16:25:57 -0500 From: Rohit Dube Sender: owner-mpls@UU.NET Precedence: bulk Hello, At the MPLS WG meeting, the question came up that GMPLS already supports bi-directional LSPs. As Rahul pointed out, this only works for generalized labels and not for "classical" labels. Here is some further clarification on the topic. For classical mpls networks there are two ways of supporting bidirectional lsps. One method is to make the UPSTREAM_LABEL objects applicable to classic MPLS labels. The other is to exchange "generalized" labels between nodes that want to support bidirectional LSPs while continuing with classical labels for uni-directional ones. The draft presented uses the former approach. While both approaches are valid, for nodes that run classical MPLS already and which need to support uni-directional as well as bi-directional LSPs, this seems to be the easier approach as the operator and the implementor need to deal with just one type of label. The -01 version of the draft proposes an UPSTREAM_FLOWSPEC object which allows for asymmetric bandwidth reservation by carrying the required information for the reverse path in the PATH message. The updated draft is available at http://members.tripod.com/~rohit_dube/papers/draft-dube-bidirectional-lsp-01.txt The updated version of the draft should appear on ietf's web-site when the draft queue starts getting processed again. Regards, --rohit. From owner-mpls@UU.NET Tue Nov 19 16:30:11 2002 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 ESMTP id QAA17194 for ; Tue, 19 Nov 2002 16:30:11 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpry27106 for ; Tue, 19 Nov 2002 21:32:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpry24847; Tue, 19 Nov 2002 21:31:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpry13085 for mpls-outgoing; Tue, 19 Nov 2002 21:31:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpry13059 for ; Tue, 19 Nov 2002 21:31:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpry12013 for ; Tue, 19 Nov 2002 21:30:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpry20893 for ; Tue, 19 Nov 2002 21:30:49 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnpry20881 for ; Tue, 19 Nov 2002 21:30:48 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAJLTMW27469; Tue, 19 Nov 2002 16:29:23 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 16:29:23 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C061EF7FA@zcard031.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" , Alia Atlas Cc: Shahram Davari , "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Tue, 19 Nov 2002 16:29:16 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Tom: > >The concept of avoiding the reserved labels in an MPLS hash > as a "best > >way" makes some sense, > > > Does this mean that we then have to mandate how IP > (L2TPV3) does > traffic distribution too? What is next? L2TPv3 from what I can tell does not have a mechanism by which I could distinguish any type of PE-PE probe of a PW so the example is moot. I can only use payload probes (I.610, ICMP, whatever). I think that this > solution looks > good in theory, but in practice there are huge problems with it. Only problem I can think of is that one cannot simply hash an arbitrary length of the MPLS frame. The implementation is a bit more complex, that's the price of testabilty. > > >though it would probably only be gradually available as > hardware changes. > > Kireeti or you made a good point that > this solution is not evolutionary; it is revolutionary as it > will require > hardware changes. Many things eventually migrate to hardware. Some formerly hardware functions migrate to microcode. This years core LSR is next years edge box. Are we saying that MPLS is frozen in time based upon last year or the year before's implementation? If so, lets skip draft and simply promote everything to STD and go home. On the surface it might sound reasonable to > say that well, hardware will evolve and as it does it must support > this sort of load-balancing. However, the fact of the matter is that > one size does not fit all in this case, and thus this will be a burden > on both existing and future implementations. At the moment you're stipulating that one size fits all. That's what the draft was trying to avoid. rgds Dave From owner-mpls@UU.NET Tue Nov 19 16:46:35 2002 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 ESMTP id QAA17753 for ; Tue, 19 Nov 2002 16:46:34 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprz13998 for ; Tue, 19 Nov 2002 21:49:08 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnprz10804; Tue, 19 Nov 2002 21:47:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnprz15297 for mpls-outgoing; Tue, 19 Nov 2002 21:47:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnprz15282 for ; Tue, 19 Nov 2002 21:47: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 QQnpry28990 for ; Tue, 19 Nov 2002 21:43:57 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpry08595 for ; Tue, 19 Nov 2002 21:43:56 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnpry08589 for ; Tue, 19 Nov 2002 21:43:56 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAJLheW28528; Tue, 19 Nov 2002 16:43:40 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 16:43:41 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C061EF81E@zcard031.ca.nortel.com> From: "David Allan" To: Jim Guichard , "Michael H. Behringer" Cc: mpls@UU.NET Subject: RE: draft-behringer-mpls-vpn-auth-00.txt Date: Tue, 19 Nov 2002 16:43:31 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Jim: Thanks for replying, apologies for confusing the two drafts. Replies in line.... > Hi David, > > sorry for the late response but I have been travelling .. > > first off, the draft we are talking about is > draft-behringer-mpls-vpn-auth-00 and not > draft-behringer-mpls-security-03 (I > am not a co-author of this draft and have no involvment with it). > > second - the draft which is posted at the ietf website is the > incorrect > version and was posted in error - I have the correct version > sat here on my > laptop but have been unable to re-post until after ietf - I > will do this > next week. > > Some comments below .. > > > >-----Original Message----- > > >From: David Allan [mailto:dallan@nortelnetworks.com] > > >Sent: Friday, November 15, 2002 10:18 AM > > >To: Michael H. Behringer; jguichar@cisco.com > > >Cc: mpls@UU.NET > > >Subject: draft-behringer-mpls-security-03.txt > > > > > > > > >Michael/Jim: > > > > > >If I understand the problem you are addressing correctly, > it is incorrect > > >configuration of the RT associated with a CE at the PE. And you > > >wish to do > > >this with no changes to the CE, therefore you are re-using > the HMAC/MD5 > > >stuff to achieve this. > > correct > > > > > > >What you actually want is the RT configured at the CE and > a means of > > >checking that there is consistency between the CE and PE. > > currently the RT belongs to the SP and is > maintained/provisioned by the SP - > the customer has no involvement or knowledge of this process. > Theoretically > the customer could tell the SP the RT value it should use for > its VPN but > then this would be subject to a) overlap with other VPNs & b) > difficult to > implement into the existing provisioning platforms. This > means that the SP > would have to tell the customer which RT value to use, which > they might get > wrong and we are back to square-one. You misunderstand me. I assume the RTs are service provider administered. What I understand the draft is proposing is a mechanism of having a consistency check between the CEs and PEs. > > IMHO adding a > > >level of indirection (two provisioned values to get right at the > > >PE) in the > > >network will not achieve this. > > well it will if the customer provides the key and then routing is > authenticated using this key across the SP to customer connections. What I interpreted this to require was some additional token provisioned in all boxes, so there is still room for finger trouble. I was suggesting a way to minimize finger trouble by having the token provisioned into the CE provided by the service provider and derived from the RT. If they still got it wrong...... > > > > > > >What I would suggest is that you keep the HMAC/MD5 approach for > > >CE-PE > > in which case the PE must still be configured with a key to facilitate > routing authentication. Which is derived from the RTs associated with the VRF. That way the only additional configuration step is at the CE. > > , but > > >have the key configured into the CE algorithmically > derived from the RT > > >associated with the VRF (or from the set of RTs in more complex > > >configuration cases). Therefore there is still typically only > > >one value to > > >provision at the PE for the CE (the RT, which is the one that > > >matters). You > > >are not using multiple values across the core (HMAC MD5 > and RTs, you only > > >need RTs) so no BGP changes are required, this is purely a S/W > > >issue at the > > >PE. > > the correct draft specifies that an ingress PE uses a > 'generator' value > (which is a random number at the PE) and creates a signature > by using the > key against the 'generator'. The result of this operation is > carried within > BGP so that a receiving PE can run its local key against the > 'generator' and > compare the result with the signature that was created by the > originating > PE. Jim I'll have to look at the revised draft. My original take was that the goal of the draft was to provide a mechanism to ensure consistency between PE/VRF and CE with repsect to VPN membership. PE to PE consistency was achieved via correct configuration of RTs and whatever inter-PE security mechanism you chose to employ. cheers Dave From owner-mpls@UU.NET Tue Nov 19 17:01:54 2002 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 ESMTP id RAA18500 for ; Tue, 19 Nov 2002 17:01:53 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsa29553 for ; Tue, 19 Nov 2002 22:04:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpsa26711; Tue, 19 Nov 2002 22:02:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpsa26755 for mpls-outgoing; Tue, 19 Nov 2002 22:02:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpsa26542 for ; Tue, 19 Nov 2002 22:02:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpsa02166 for ; Tue, 19 Nov 2002 22:02:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsa11694 for ; Tue, 19 Nov 2002 22:02:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpsa11690 for ; Tue, 19 Nov 2002 22:02:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA10518 for ; Tue, 19 Nov 2002 17:02:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJM25U28690 for mpls@uu.net; Tue, 19 Nov 2002 17:02:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpsa21289 for ; Tue, 19 Nov 2002 22:00:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnprz26172 for ; Tue, 19 Nov 2002 21:59:49 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnprz09904 for ; Tue, 19 Nov 2002 21:59:49 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: london2.cisco.com [64.103.110.74]) id QQnprz09897 for ; Tue, 19 Nov 2002 21:59:48 GMT Received: from JGUICHARW2K (che-vpn-cluster-1-77.cisco.com [10.86.240.77]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id VAA15726; Tue, 19 Nov 2002 21:59:41 GMT From: "Jim Guichard" To: "David Allan" , "Michael H. Behringer" Cc: Subject: RE: draft-behringer-mpls-vpn-auth-00.txt Date: Tue, 19 Nov 2002 16:55:47 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <9FBD322B7824D511B36900508BF93C9C061EF81E@zcard031.ca.nortel.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, thanks for the comments - the main reason that we selected MD5 was that it is generally available (for all routing protocols) and is recommended to many Enterprises as a 'best practice' for their IGP deployment. The key (please pardon the pun) advantage of using the MD5 key is that we cannot receive incorrect routing information from the attached site and therefore if we misconfigure either the key or the RT, routing information will either be a) rejected at source, or b) rejected at a remote PE due to key mismatch. Some further comments below .. > >> > >-----Original Message----- > >> > >From: David Allan [mailto:dallan@nortelnetworks.com] > >> > >Sent: Friday, November 15, 2002 10:18 AM > >> > >To: Michael H. Behringer; jguichar@cisco.com > >> > >Cc: mpls@UU.NET > >> > >Subject: draft-behringer-mpls-security-03.txt > >> > > > >> > > > >> > >Michael/Jim: > >> > > > >> > >If I understand the problem you are addressing correctly, > >> it is incorrect > >> > >configuration of the RT associated with a CE at the PE. And you > >> > >wish to do > >> > >this with no changes to the CE, therefore you are re-using > >> the HMAC/MD5 > >> > >stuff to achieve this. > >> > >> correct > >> > >> > > > >> > >What you actually want is the RT configured at the CE and > >> a means of > >> > >checking that there is consistency between the CE and PE. > >> > >> currently the RT belongs to the SP and is > >> maintained/provisioned by the SP - > >> the customer has no involvement or knowledge of this process. > >> Theoretically > >> the customer could tell the SP the RT value it should use for > >> its VPN but > >> then this would be subject to a) overlap with other VPNs & b) > >> difficult to > >> implement into the existing provisioning platforms. This > >> means that the SP > >> would have to tell the customer which RT value to use, which > >> they might get > >> wrong and we are back to square-one. > > > >You misunderstand me. I assume the RTs are service provider administered. > >What I understand the draft is proposing is a mechanism of having a > >consistency check between the CEs and PEs. yes, but at the routing authentication level .. > >> > >> IMHO adding a > >> > >level of indirection (two provisioned values to get right at the > >> > >PE) in the > >> > >network will not achieve this. > >> > >> well it will if the customer provides the key and then routing is > >> authenticated using this key across the SP to customer connections. > > > >What I interpreted this to require was some additional token > >provisioned in > >all boxes, so there is still room for finger trouble. yes, both the PE and CE require the key to be configured - finger trouble could still occur but the difference is that the possibility of leaking information into another VPN due to this misconfiguration is avoided. I was > >suggesting a way > >to minimize finger trouble by having the token provisioned into the CE > >provided by the service provider and derived from the RT. If > >they still got > >it wrong...... > > > >> > >> > > > >> > >What I would suggest is that you keep the HMAC/MD5 approach for > >> > >CE-PE > >> > >> in which case the PE must still be configured with a key to facilitate > >> routing authentication. > > > >Which is derived from the RTs associated with the VRF. That way the only > >additional configuration step is at the CE. but if you derive the key from the configured RT, and the RT as configured is incorrect, the key becomes irrelevant. Could you explain the flow of how the RT relates to the key and how this is communicated to the CE ? Jim > > > >> > >> , but > >> > >have the key configured into the CE algorithmically > >> derived from the RT > >> > >associated with the VRF (or from the set of RTs in more complex > >> > >configuration cases). Therefore there is still typically only > >> > >one value to > >> > >provision at the PE for the CE (the RT, which is the one that > >> > >matters). You > >> > >are not using multiple values across the core (HMAC MD5 > >> and RTs, you only > >> > >need RTs) so no BGP changes are required, this is purely a S/W > >> > >issue at the > >> > >PE. > >> > >> the correct draft specifies that an ingress PE uses a > >> 'generator' value > >> (which is a random number at the PE) and creates a signature > >> by using the > >> key against the 'generator'. The result of this operation is > >> carried within > >> BGP so that a receiving PE can run its local key against the > >> 'generator' and > >> compare the result with the signature that was created by the > >> originating > >> PE. Jim > > > >I'll have to look at the revised draft. My original take was > >that the goal > >of the draft was to provide a mechanism to ensure consistency > >between PE/VRF > >and CE with repsect to VPN membership. PE to PE consistency was > >achieved via > >correct configuration of RTs and whatever inter-PE security > >mechanism you > >chose to employ. > > > >cheers > >Dave > > > > > > From owner-mpls@UU.NET Tue Nov 19 17:29:19 2002 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 ESMTP id RAA19042 for ; Tue, 19 Nov 2002 17:29:19 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsc20311 for ; Tue, 19 Nov 2002 22:31:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpsb13580; Tue, 19 Nov 2002 22:28:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpsb07540 for mpls-outgoing; Tue, 19 Nov 2002 22:28:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpsb07530 for ; Tue, 19 Nov 2002 22:28: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 QQnpsb04491 for ; Tue, 19 Nov 2002 22:27:39 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsb12452 for ; Tue, 19 Nov 2002 22:27:39 GMT Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnpsb12441 for ; Tue, 19 Nov 2002 22:27:38 GMT Received: by mbibipnt08.nat.bt.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 22:27:43 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389E1C18A@i2km07-ukbr.domain1.systemhost.net> To: tnadeau@cisco.com, egray@celoxnetworks.com Cc: Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: Requirements and solutions Date: Tue, 19 Nov 2002 22:27:33 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk There is a balance to be struck between the effort/time-spent capturing/agreeing requirements and the effort/time-spent defining solutions. Common sense really. However, there are set of functional attributes that all network technologies require.....and fault-management is amongst one of the most basic no-brainers. So having said that, if we cannot point to where the defects are identified/documented/specified (wrt to entry/exit criteria and consequent actions.....which IMO ought to be the starting point) then I think we are in a pretty poor shape to be making any statements about trying to achieve perfection. BTW - sometimes its not looking for solutions to the problems caused by technology X that is the answer, the real answer maybe that technology X itself is the problem. However, this is far harder to recognise/accept and deal with for many reasons. regards, Neil > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: 19 November 2002 18:31 > To: Gray, Eric > Cc: 'Shahram Davari'; 'mpls@uu.net' > Subject: RE: Requirements and solutions > > > At 11:20 AM 11/19/2002 -0500, Gray, Eric wrote: > >Shahram, > > > > We need to be a little less retentive about terms, > >documents and ordering. > > > > A lot of the time in the IETF, work starts without > >a formal requirements document. This is because some set > >of people - nearly always including authors and often > >including several others as well - believe they understand > >the requirements well enough without formally documenting > >them. In many cases, a requirements statement of a sort > >is included in the draft abstract and/or introduction. > > > > Lately, there is a lot of preoccupation with the > >need for formality. A point I believe was made today is > >that it is possible for a requirements document to proceed > >in parallel and the results compared in an applicability > >document. This is quite reasonable. > > > > While some people said something to the effect that - > >in the event that they don't match up well - a mismatch is > >an indication of failure on the part of the original draft > >authors to develop something useful. I think one could go > >further and argue that the mismatch may be an indication > >of future work that may be needed for subsequent versions > >of the work already done. > > I totally agree. Many people much smarter than > us have tried to produce the grandest, most perfect solutions > from the start and failed. IMHO, a mismatch is a reason to just > iterate again to evolve the solution. > > --Tom > > > > >Eric W. Gray > >Systems Architect > >Celox Networks, Inc. > >egray@celoxnetworks.com > >508 305 7214 > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Tuesday, November 19, 2002 11:02 AM > > > To: 'mpls@uu.net' > > > Subject: Requirements and solutions > > > > > > Hi, > > > > > > I am very much troubled by a comment raised in MPLS meeting, that > > > in the future the order of first requirements and then > solution would > > > quite often change and that hopefully it would not require any > > > modification > > > to the already approved solution. > > > > > > This may be acceptable in occasional cases (may be MPLS-ping > > > is one of those cases), but I am not sure it is a good idea > > > to make this as a general rule. > > > > > > > > > Thanks, > > > Shahram > > > > > > PS- Please not that my comment is not against MPLS-ping, > rather about > > > procedures. > > Success is relative; the more success, the more relatives. -Anonymous > > From owner-mpls@UU.NET Tue Nov 19 17:42:45 2002 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 ESMTP id RAA19425 for ; Tue, 19 Nov 2002 17:42:44 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsd00054 for ; Tue, 19 Nov 2002 22:45:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpsc26736; Tue, 19 Nov 2002 22:43:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpsc08603 for mpls-outgoing; Tue, 19 Nov 2002 22:43:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpsc08595 for ; Tue, 19 Nov 2002 22:43: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 QQnpsc11538 for ; Tue, 19 Nov 2002 22:43:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsc07723 for ; Tue, 19 Nov 2002 22:43:06 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnpsc07719 for ; Tue, 19 Nov 2002 22:43:06 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAJMgpd08168; Tue, 19 Nov 2002 17:42:51 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Nov 2002 17:42:52 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C061EF89B@zcard031.ca.nortel.com> From: "David Allan" To: Jim Guichard , "Michael H. Behringer" Cc: mpls@UU.NET Subject: RE: draft-behringer-mpls-vpn-auth-00.txt Date: Tue, 19 Nov 2002 17:42:49 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Jim: > > but if you derive the key from the configured RT, and the RT > as configured > is incorrect, the key becomes irrelevant. Could you explain > the flow of how > the RT relates to the key and how this is communicated to the CE ? > Phrasing issue, CE configured with info derived from the RT(s) to be provisioned in the PE. (some off line process). So if CE is provisioned incorrectly, there is a PE-CE mismatch. If RT provisioned at the PE is wrong there is a PE-CE mismatch. If the RT(s) assigned to the CE/VRF in the first place is wrong (which would be pretty much the same as which VPN the CE should be in) I think you are dead regardless of the approach... cheers Dave > Jim > > > > > > >> > > >> , but > > >> > >have the key configured into the CE algorithmically > > >> derived from the RT > > >> > >associated with the VRF (or from the set of RTs in > more complex > > >> > >configuration cases). Therefore there is still typically only > > >> > >one value to > > >> > >provision at the PE for the CE (the RT, which is the one that > > >> > >matters). You > > >> > >are not using multiple values across the core (HMAC MD5 > > >> and RTs, you only > > >> > >need RTs) so no BGP changes are required, this is purely a S/W > > >> > >issue at the > > >> > >PE. > > >> > > >> the correct draft specifies that an ingress PE uses a > > >> 'generator' value > > >> (which is a random number at the PE) and creates a signature > > >> by using the > > >> key against the 'generator'. The result of this operation is > > >> carried within > > >> BGP so that a receiving PE can run its local key against the > > >> 'generator' and > > >> compare the result with the signature that was created by the > > >> originating > > >> PE. Jim > > > > > >I'll have to look at the revised draft. My original take was > > >that the goal > > >of the draft was to provide a mechanism to ensure consistency > > >between PE/VRF > > >and CE with repsect to VPN membership. PE to PE consistency was > > >achieved via > > >correct configuration of RTs and whatever inter-PE security > > >mechanism you > > >chose to employ. > > > > > >cheers > > >Dave > > > > > > > > > > > From owner-mpls@UU.NET Tue Nov 19 17:47:20 2002 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 ESMTP id RAA19552 for ; Tue, 19 Nov 2002 17:47:19 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsd07368 for ; Tue, 19 Nov 2002 22:49:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpsd04499; Tue, 19 Nov 2002 22:48:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpsd09446 for mpls-outgoing; Tue, 19 Nov 2002 22:47:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpsd09436 for ; Tue, 19 Nov 2002 22:47:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpsd25272 for ; Tue, 19 Nov 2002 22:47:16 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsd10011 for ; Tue, 19 Nov 2002 22:47:15 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpsd10004 for ; Tue, 19 Nov 2002 22:47:15 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA13889 for ; Tue, 19 Nov 2002 17:47:15 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJMlFi02485 for mpls@uu.net; Tue, 19 Nov 2002 17:47:15 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpsd09225 for ; Tue, 19 Nov 2002 22:46:16 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 QQnpsd19927 for ; Tue, 19 Nov 2002 22:45:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsd02713 for ; Tue, 19 Nov 2002 22:45:43 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnpsd02709 for ; Tue, 19 Nov 2002 22:45:43 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJMk0Oq018356; Tue, 19 Nov 2002 17:46:01 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-681.cisco.com [10.82.226.169]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD49459; Tue, 19 Nov 2002 17:45:35 -0500 (EST) Message-Id: <5.2.0.9.2.20021119174038.020c2e00@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Nov 2002 17:45:30 -0500 To: "David Allan" From: "Thomas D. Nadeau" Subject: RE: Load balancing draft Cc: "'MPLS@UU.net'" In-Reply-To: <9FBD322B7824D511B36900508BF93C9C061EF7FA@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 04:29 PM 11/19/2002 -0500, David Allan wrote: >Tom: > > > >The concept of avoiding the reserved labels in an MPLS hash > > as a "best > > >way" makes some sense, > > > > > > Does this mean that we then have to mandate how IP > > (L2TPV3) does traffic distribution too? What is next? > >L2TPv3 from what I can tell does not have a mechanism by which I could >distinguish any type of PE-PE probe of a PW so the example is moot. I can >only use payload probes (I.610, ICMP, whatever). >I think that this > > solution looks > > good in theory, but in practice there are huge problems with it. > >Only problem I can think of is that one cannot simply hash an arbitrary >length of the MPLS frame. The implementation is a bit more complex, that's >the price of testabilty. Not necessarily. I think you can test/trace the paths using LSP ping, but of course, there is a price to pay for that too; there is no free lunch. The advantage of the latter is that it works with all of the hardware deployed today. > > >though it would probably only be gradually available as > > hardware changes. > > > > Kireeti or you made a good point that > > this solution is not evolutionary; it is revolutionary as it > > will require > > hardware changes. > >Many things eventually migrate to hardware. Some formerly hardware functions >migrate to microcode. This years core LSR is next years edge box. Are we >saying that MPLS is frozen in time based upon last year or the year before's >implementation? If so, lets skip draft and simply promote everything to STD >and go home. No, I am saying that there are always going to be low-end platforms that have hardware limitations and thus might not be able to use the load share algorithm you specify in this document. What do we do for those? I think we are just back in the situation that we are in today: proprietary load balancing. It works for IP and other technologies, why do we need to mandate an algorithm here? >On the surface it might sound reasonable to > > say that well, hardware will evolve and as it does it must support > > this sort of load-balancing. However, the fact of the matter is that > > one size does not fit all in this case, and thus this will be a burden > > on both existing and future implementations. > >At the moment you're stipulating that one size fits all. That's what the >draft was trying to avoid. No, I am saying that what we have today is many sizes fit all (in the case of load balancing) because that is a reality of routers/switches. --Tom >rgds >Dave > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Tue Nov 19 17:57:33 2002 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 ESMTP id RAA19801 for ; Tue, 19 Nov 2002 17:57:33 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpse20182 for ; Tue, 19 Nov 2002 23:00:06 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpsd17913; Tue, 19 Nov 2002 22:58:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpsd10123 for mpls-outgoing; Tue, 19 Nov 2002 22:58:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpsd10117 for ; Tue, 19 Nov 2002 22:58:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpsd29961 for ; Tue, 19 Nov 2002 22:58:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsd17461 for ; Tue, 19 Nov 2002 22:58:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpsd17449 for ; Tue, 19 Nov 2002 22:58:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA14718 for ; Tue, 19 Nov 2002 17:58:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAJMw5P04796 for mpls@uu.net; Tue, 19 Nov 2002 17:58:05 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpsd10100 for ; Tue, 19 Nov 2002 22:57:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpsd27103 for ; Tue, 19 Nov 2002 22:56:55 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsd15973 for ; Tue, 19 Nov 2002 22:56:55 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnpsd15960 for ; Tue, 19 Nov 2002 22:56:55 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJMusYe019413; Tue, 19 Nov 2002 17:56:54 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-681.cisco.com [10.82.226.169]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD49665; Tue, 19 Nov 2002 17:56:30 -0500 (EST) Message-Id: <5.2.0.9.2.20021119175448.0219fe48@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Nov 2002 17:56:20 -0500 To: Alia Atlas From: "Thomas D. Nadeau" Subject: Re: Load balancing draft Cc: Shahram Davari , "'MPLS@UU.net'" In-Reply-To: <5.1.0.14.2.20021119133246.01f9c1f0@mailhost.avici.com> References: <5.2.0.9.2.20021119132310.02216b50@bucket.cisco.com> <5.1.0.14.2.20021119105042.01f41910@mailhost.avici.com> <4B6D09F3B826D411A67300D0B706EFDEB03ABE@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 01:43 PM 11/19/2002 -0500, Alia Atlas wrote: >The idea is not to mandate how traffic distribution is done. It's to say >that the reserved labels should be excluded from consideration in >determining that. I'm certainly against anything which increases the size >of the microflows which can be load-balanced - this doesn't do that, b/c >only the OAM packets would have those reserved labels. > >Which huge problems are you seeing with this? I'm not saying that it >should be mandated in anyway, simply that it may be superior design, if >one chose to implement it thusly. I think it might be a great design if EVERYONE implemented it. However, I think that is a not possible. >Absolutely, this isn't something to be required and it is revolutionary in >that it requires hardware changes. I don't see how it is a burden on >existing and future implementations; it is a suggestion for how to make >the ECMP friendlier. It is a burden because some hardware from vendors may not be able to support the algorithm (i.e.: look at that many labels). Also your point of wanting to look at more labels than might be mandated would prohibit better load sharing behavior. --Tom > Didn't we also have discussions about how routers should do microflow > classification for the load-balancing instead of doing round-robin to > avoid microflow reordering? And that is not what all routers do or, > probably, will ever do depending on where in the network they are... > >Alia > >At 01:27 PM 11/19/2002 -0500, Thomas D. Nadeau wrote: > >>>The concept of avoiding the reserved labels in an MPLS hash as a "best >>>way" makes some sense, >> >> >> Does this mean that we then have to mandate how IP (L2TPV3) does >>traffic distribution too? What is next? I think that this solution looks >>good in theory, but in practice there are huge problems with it. >> >>>though it would probably only be gradually available as hardware changes. >> >> Kireeti or you made a good point that >>this solution is not evolutionary; it is revolutionary as it will require >>hardware changes. On the surface it might sound reasonable to >>say that well, hardware will evolve and as it does it must support >>this sort of load-balancing. However, the fact of the matter is that >>one size does not fit all in this case, and thus this will be a burden >>on both existing and future implementations. >> >> --Tom >> >>>Doing this would make OAM work for pseudo-wires, where there is no >>>underlying packet information which can be examined and where the TTL is fixed. >>> >>>But this does change fast-path hardware... >>> >>>Doing JUST that doesn't have bad impact on load-balancing of microflows >>>(or identifying as small a microflow as possible). >>> >>>Alia >>> >>>At 07:36 AM 11/19/2002 -0800, Shahram Davari wrote: >>>>Hi, >>>> >>>>One of the criticism for this draft was that it is designed to overcome >>>>Y.1711 limitation, in which a reserved label is used. As I mentioned >>>>in the meeting the MPLS-Ping also requires usage of an extra reserved >>>>label for non-IP carrying LSPs: >>>> >>>> "To test an LSP that carries non-IP traffic, before injecting ICMP and >>>> MPLS ping messages into the LSP, the IPv4 Explicit NULL label should >>>> be prepended to such messages." >>>> >>>>So this draft is equally applicable to MPLS-ping. >>>> >>>>Yours, >>>>Shahram >> >>Success is relative; the more success, the more relatives. -Anonymous >> > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Tue Nov 19 18:07:06 2002 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 ESMTP id SAA20113 for ; Tue, 19 Nov 2002 18:07:06 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpse03047 for ; Tue, 19 Nov 2002 23:09:43 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpse01286; Tue, 19 Nov 2002 23:08:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpse28448 for mpls-outgoing; Tue, 19 Nov 2002 23:08:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpse28428 for ; Tue, 19 Nov 2002 23:08: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 QQnpse18766 for ; Tue, 19 Nov 2002 23:08:17 GMT From: neil.2.harrison@bt.com Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpse25900 for ; Tue, 19 Nov 2002 23:08:17 GMT Received: from cbibipnt05.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQnpse25888 for ; Tue, 19 Nov 2002 23:08:16 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 19 Nov 2002 23:08:17 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A35389E1C18D@i2km07-ukbr.domain1.systemhost.net> To: dallan@nortelnetworks.com, tnadeau@cisco.com, aatlas@avici.com Cc: Shahram_Davari@pmc-sierra.com, MPLS@UU.NET Subject: RE: Load balancing draft Date: Tue, 19 Nov 2002 23:08:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk David Allan wrote 19 November 2002 21:29 > Tom: > > > >The concept of avoiding the reserved labels in an MPLS hash > > as a "best > > >way" makes some sense, > > > > > > Does this mean that we then have to mandate how IP > > (L2TPV3) does > > traffic distribution too? What is next? > > L2TPv3 from what I can tell does not have a mechanism by which I could > distinguish any type of PE-PE probe of a PW so the example is > moot. I can > only use payload probes (I.610, ICMP, whatever). NH=> Agreed Dave but this misses a key point....IP does not have the same potential failure modes as LDP mp2p. IP is architecturally a cnls network so it *multiplexes* pkts, it does not *merge* pkts......indeed, merging in a co pkt-sw network forwarding paradigm is a very weird thing to do and it demands some level of 'demerging' above it. This is a fundamentally important observation. > > I think that this > > solution looks > > good in theory, but in practice there are huge problems with it. > > Only problem I can think of is that one cannot simply hash an > arbitrary > length of the MPLS frame. The implementation is a bit more > complex, that's > the price of testabilty. NH=> It's one of the hidden charges in the search for a free-lunch. > > > > > >though it would probably only be gradually available as > > hardware changes. > > > > Kireeti or you made a good point that > > this solution is not evolutionary; it is revolutionary as it > > will require > > hardware changes. > > Many things eventually migrate to hardware. Some formerly > hardware functions > migrate to microcode. This years core LSR is next years edge > box. Are we > saying that MPLS is frozen in time based upon last year or > the year before's > implementation? If so, lets skip draft and simply promote > everything to STD > and go home. NH=> Totally agreed. > > > On the surface it might sound reasonable to > > say that well, hardware will evolve and as it does it must support > > this sort of load-balancing. However, the fact of the matter is that > > one size does not fit all in this case, and thus this will > be a burden > > on both existing and future implementations. > > At the moment you're stipulating that one size fits all. > That's what the > draft was trying to avoid. NH=> Agreed....speaking as an operator and looking ahead, we want choice here. Bit spooky but we were discussing these very issues today in a CTO mtg. > > rgds > Dave > > From owner-mpls@UU.NET Tue Nov 19 20:26:01 2002 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 ESMTP id UAA23041 for ; Tue, 19 Nov 2002 20:26:00 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsn02847 for ; Wed, 20 Nov 2002 01:28:35 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpsn01292; Wed, 20 Nov 2002 01:27:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpsn13334 for mpls-outgoing; Wed, 20 Nov 2002 01:27:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpsn13320 for ; Wed, 20 Nov 2002 01:27:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpsn03319 for ; Wed, 20 Nov 2002 01:26:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsn10493 for ; Wed, 20 Nov 2002 01:26:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpsn10483 for ; Wed, 20 Nov 2002 01:26:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA23083 for ; Tue, 19 Nov 2002 20:26:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAK1Q6F14426 for mpls@uu.net; Tue, 19 Nov 2002 20:26:06 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpsn13160 for ; Wed, 20 Nov 2002 01:24:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpsn21549 for ; Wed, 20 Nov 2002 01:23:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsn08827 for ; Wed, 20 Nov 2002 01:23:41 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnpsn08820 for ; Wed, 20 Nov 2002 01:23:40 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAK1O06u001197; Tue, 19 Nov 2002 20:24:01 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn2-318.cisco.com [10.82.241.62]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD51680; Tue, 19 Nov 2002 20:23:36 -0500 (EST) Message-Id: <5.2.0.9.2.20021119201936.01a6e170@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Nov 2002 20:21:56 -0500 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: Requirements and solutions Cc: "'Gray, Eric'" , "'mpls@uu.net'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03AC3@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:14 AM 11/19/2002 -0800, Shahram Davari wrote: >Eric, > >As I said in my email, this is not a rule that is written in stone >(like ten commandments). But I think it should be the general practice. > >I understand that in some cases, solution is developed without formal >requirements. But I am wondering whether a follow up requirements RFC >makes sense in those cases. As we discussed during the meeting, LSP ping was designed to be flexible and EVOLUTIONARY, so yes, if we need to fix something that we discover is wrong, we can fix it incrementally later. For now, I think that LSP ping is a tool that is quite useful to solve the problems it was designed to solve. If we discover later that it needs some patching, it was designed to handle this. --Tom >Yours, >-Shahram > > > > -----Original Message----- > > From: Gray, Eric [mailto:egray@celoxnetworks.com] > > Sent: Tuesday, November 19, 2002 11:20 AM > > To: Shahram Davari; 'mpls@uu.net' > > Subject: RE: Requirements and solutions > > > > > > Shahram, > > > > We need to be a little less retentive about terms, > > documents and ordering. > > > > A lot of the time in the IETF, work starts without > > a formal requirements document. This is because some set > > of people - nearly always including authors and often > > including several others as well - believe they understand > > the requirements well enough without formally documenting > > them. In many cases, a requirements statement of a sort > > is included in the draft abstract and/or introduction. > > > > Lately, there is a lot of preoccupation with the > > need for formality. A point I believe was made today is > > that it is possible for a requirements document to proceed > > in parallel and the results compared in an applicability > > document. This is quite reasonable. > > > > While some people said something to the effect that - > > in the event that they don't match up well - a mismatch is > > an indication of failure on the part of the original draft > > authors to develop something useful. I think one could go > > further and argue that the mismatch may be an indication > > of future work that may be needed for subsequent versions > > of the work already done. > > > > > > Eric W. Gray > > Systems Architect > > Celox Networks, Inc. > > egray@celoxnetworks.com > > 508 305 7214 > > > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Tuesday, November 19, 2002 11:02 AM > > > To: 'mpls@uu.net' > > > Subject: Requirements and solutions > > > > > > Hi, > > > > > > I am very much troubled by a comment raised in MPLS meeting, that > > > in the future the order of first requirements and then > > solution would > > > quite often change and that hopefully it would not require any > > > modification > > > to the already approved solution. > > > > > > This may be acceptable in occasional cases (may be MPLS-ping > > > is one of those cases), but I am not sure it is a good idea > > > to make this as a general rule. > > > > > > > > > Thanks, > > > Shahram > > > > > > PS- Please not that my comment is not against MPLS-ping, > > rather about > > > procedures. > > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Tue Nov 19 22:38:13 2002 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 ESMTP id WAA13769 for ; Tue, 19 Nov 2002 22:38:13 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsw28355 for ; Wed, 20 Nov 2002 03:40:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpsw27115; Wed, 20 Nov 2002 03:40:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpsw27509 for mpls-outgoing; Wed, 20 Nov 2002 03:40:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpsw27500 for ; Wed, 20 Nov 2002 03:39:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpsw10652 for ; Wed, 20 Nov 2002 03:39:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsw00259 for ; Wed, 20 Nov 2002 03:39:45 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQnpsw00249 for ; Wed, 20 Nov 2002 03:39:45 GMT Received: from aatlas-lt.avici.com ([10.2.101.123]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id gAK3dUu01404; Tue, 19 Nov 2002 22:39:30 -0500 (EST) Message-Id: <5.1.0.14.2.20021119223854.01fa0a00@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Nov 2002 22:40:48 -0500 To: "Thomas D. Nadeau" From: Alia Atlas Subject: RE: Load balancing draft Cc: "David Allan" , "'MPLS@UU.net'" In-Reply-To: <5.2.0.9.2.20021119174038.020c2e00@bucket.cisco.com> References: <9FBD322B7824D511B36900508BF93C9C061EF7FA@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 05:45 PM 11/19/2002 -0500, Thomas D. Nadeau wrote: > Not necessarily. I think you can test/trace the paths using LSP ping, >but of course, there is a price to pay for that too; there is no free lunch. >The advantage of the latter is that it works with all of the hardware >deployed today. How does it work today with the pseudo-wire case? From the draft, it seems that the same PW label is used, but it is not the bottom of stack, b/c there is an explicit NULL underneath. So, suddenly one must forward based not only on the MPLS label but also the bottom-of-stack bit... Tell me I'm missing something here, but if the above is really what is intended in the draft, I don't understand how you can claim that it is compatible with current MPLS hardware. Alia From owner-mpls@UU.NET Tue Nov 19 22:40:39 2002 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 ESMTP id WAA14905 for ; Tue, 19 Nov 2002 22:40:39 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsw04270 for ; Wed, 20 Nov 2002 03:43:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpsw01962; Wed, 20 Nov 2002 03:42:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpsw27565 for mpls-outgoing; Wed, 20 Nov 2002 03:41:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpsw27548 for ; Wed, 20 Nov 2002 03:41:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpsw11667 for ; Wed, 20 Nov 2002 03:41:29 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsw27826 for ; Wed, 20 Nov 2002 03:41:28 GMT Received: from wiprom2mx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQnpsw27772 for ; Wed, 20 Nov 2002 03:41:24 GMT Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id gAK3fI123849 for ; Wed, 20 Nov 2002 09:11:23 +0530 (IST) Received: from soflt.ipneg.wipro.com ([10.117.3.193]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H5UVKO00.9JN; Wed, 20 Nov 2002 09:11:12 +0530 Date: Wed, 20 Nov 2002 09:08:46 +0530 (IST) From: "chetan kumar s" X-X-Sender: Reply-To: To: David Charlap cc: IETF MPLS List Subject: Re: Conflicting Resernation Style In-Reply-To: <3DDA5BF0.5030605@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 19 Nov 2002, David Charlap wrote: > chetan kumar s wrote: > > > > The session attribute object as a flag 'SE Style desired', which > > mandates the egress to respond the resv message with SE style. Now if the > > Path refersh messages have conflicting flags, how is this handled. I was > > looking at the classical RSVP mailing list archive, found an interesting > > thread on this: > > http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/rsvp/1996-04/0068.html > > You have one critical mistaken assumption here. The flags in > SESSION_ATTRIBUTES are not mandatory. They are advisory. An egress Yea, the session_attribute flags are not mandatory, but however, if the flags are present(and set) the egress node SHOULD use SE style, the RFC says. So it may not be good for egress to ignore. The SE style desired flag is required in the session attribute so that ingress can control the reservation style, since it is the ingress node that decides if there is requirement for rerouting of tunnel without tearing it down. Now if the egress node ignore any such request, one can not expect consistent network operations.. Thanks Chetan S > node is free to ignore them if it wants to. > > This should also answer your second question. If the ingress signals a > Path requesting SE style, and an SE style Resv is returned, and then the > ingress refreshes that LSP (or perhaps creates another LSP in the same > session) without the SE-style request, the egress node should simply > ignore the change and continue sending back SE-style Resv messages. > > Now, if the egress node sends back two different Resv messages with two > different styles, then the node detecting that conflict should generate > a ResvErr message. But this shouldn't happen unless the egress node is > broken. A style-conflict error should only happen in a multicast > situation, where two different egress nodes for the same session choose > different styles. > > -- David > From owner-mpls@UU.NET Tue Nov 19 22:46:53 2002 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 ESMTP id WAA15391 for ; Tue, 19 Nov 2002 22:46:53 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsx14100 for ; Wed, 20 Nov 2002 03:49:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpsx12104; Wed, 20 Nov 2002 03:48:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpsx28177 for mpls-outgoing; Wed, 20 Nov 2002 03:48:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpsx28163 for ; Wed, 20 Nov 2002 03:47:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpsx26394 for ; Wed, 20 Nov 2002 03:47:24 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpsx11311 for ; Wed, 20 Nov 2002 03:47:24 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQnpsx11307 for ; Wed, 20 Nov 2002 03:47:23 GMT Received: from aatlas-lt.avici.com ([10.2.101.123]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id gAK3l1u02031; Tue, 19 Nov 2002 22:47:01 -0500 (EST) Message-Id: <5.1.0.14.2.20021119224258.01fab348@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Nov 2002 22:48:18 -0500 To: "Thomas D. Nadeau" From: Alia Atlas Subject: Re: Load balancing draft Cc: Shahram Davari , "'MPLS@UU.net'" In-Reply-To: <5.2.0.9.2.20021119175448.0219fe48@bucket.cisco.com> References: <5.1.0.14.2.20021119133246.01f9c1f0@mailhost.avici.com> <5.2.0.9.2.20021119132310.02216b50@bucket.cisco.com> <5.1.0.14.2.20021119105042.01f41910@mailhost.avici.com> <4B6D09F3B826D411A67300D0B706EFDEB03ABE@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 05:56 PM 11/19/2002 -0500, Thomas D. Nadeau wrote: >At 01:43 PM 11/19/2002 -0500, Alia Atlas wrote: >>The idea is not to mandate how traffic distribution is done. It's to say >>that the reserved labels should be excluded from consideration in >>determining that. I'm certainly against anything which increases the >>size of the microflows which can be load-balanced - this doesn't do that, >>b/c only the OAM packets would have those reserved labels. >> >>Which huge problems are you seeing with this? I'm not saying that it >>should be mandated in anyway, simply that it may be superior design, if >>one chose to implement it thusly. > > I think it might be a great design if EVERYONE implemented it. >However, I think that is a not possible. The fewer places where the OAM label causes the streams to diverge, the better. This isn't an all-or-nothing. What I am saying is simply that not including reserved MPLS labels in a label hash for load-balancing would be a better way of doing the hardware. It's proprietary now; this is still something which can be proprietary. I am NOT suggesting that the draft go forward and certainly not the way it is. I am simply saying that just as it is "known" that if one is load-balancing IP, it is good not to reorder microflows, it makes sense to have it "known" that if one is load-balancing MPLS based on the label-stack, it would be good not to include MPLS reserved labels. >>Absolutely, this isn't something to be required and it is revolutionary >>in that it requires hardware changes. I don't see how it is a burden on >>existing and future implementations; it is a suggestion for how to make >>the ECMP friendlier. > > It is a burden because some hardware from vendors may not be able to >support the algorithm (i.e.: look at that many labels). Also your point of >wanting to look at more labels than might be mandated would prohibit >better load sharing behavior. I do not think it is a good idea to control the depth of the labels looked at. This is a vendor-proprietary detail, based on what the hardware can do and how much granularity they want in microflows. Again, all I'm saying is if one is to look at labels for a hash for load-balancing, don't include the reserved MPLS labels. That's it. Alia > --Tom > >> Didn't we also have discussions about how routers should do microflow >> classification for the load-balancing instead of doing round-robin to >> avoid microflow reordering? And that is not what all routers do or, >> probably, will ever do depending on where in the network they are... >> >>Alia >> >>At 01:27 PM 11/19/2002 -0500, Thomas D. Nadeau wrote: >> >>>>The concept of avoiding the reserved labels in an MPLS hash as a "best >>>>way" makes some sense, >>> >>> >>> Does this mean that we then have to mandate how IP (L2TPV3) does >>>traffic distribution too? What is next? I think that this solution looks >>>good in theory, but in practice there are huge problems with it. >>> >>>>though it would probably only be gradually available as hardware changes. >>> >>> Kireeti or you made a good point that >>>this solution is not evolutionary; it is revolutionary as it will require >>>hardware changes. On the surface it might sound reasonable to >>>say that well, hardware will evolve and as it does it must support >>>this sort of load-balancing. However, the fact of the matter is that >>>one size does not fit all in this case, and thus this will be a burden >>>on both existing and future implementations. >>> >>> --Tom >>> >>>>Doing this would make OAM work for pseudo-wires, where there is no >>>>underlying packet information which can be examined and where the TTL is fixed. >>>> >>>>But this does change fast-path hardware... >>>> >>>>Doing JUST that doesn't have bad impact on load-balancing of microflows >>>>(or identifying as small a microflow as possible). >>>> >>>>Alia >>>> >>>>At 07:36 AM 11/19/2002 -0800, Shahram Davari wrote: >>>>>Hi, >>>>> >>>>>One of the criticism for this draft was that it is designed to overcome >>>>>Y.1711 limitation, in which a reserved label is used. As I mentioned >>>>>in the meeting the MPLS-Ping also requires usage of an extra reserved >>>>>label for non-IP carrying LSPs: >>>>> >>>>> "To test an LSP that carries non-IP traffic, before injecting ICMP and >>>>> MPLS ping messages into the LSP, the IPv4 Explicit NULL label should >>>>> be prepended to such messages." >>>>> >>>>>So this draft is equally applicable to MPLS-ping. >>>>> >>>>>Yours, >>>>>Shahram >>> >>>Success is relative; the more success, the more relatives. -Anonymous > >Success is relative; the more success, the more relatives. -Anonymous > > From owner-mpls@UU.NET Wed Nov 20 01:23:01 2002 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 ESMTP id BAA18742 for ; Wed, 20 Nov 2002 01:23:01 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpth05499 for ; Wed, 20 Nov 2002 06:25:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpth03924; Wed, 20 Nov 2002 06:24:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpth00449 for mpls-outgoing; Wed, 20 Nov 2002 06:24:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpth00439 for ; Wed, 20 Nov 2002 06:24:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpth07605 for ; Wed, 20 Nov 2002 06:23:43 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpth20309 for ; Wed, 20 Nov 2002 06:23:43 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnpth20305 for ; Wed, 20 Nov 2002 06:23:42 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAK6N7t10837; Wed, 20 Nov 2002 01:23:07 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Nov 2002 01:23:08 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C061EF97A@zcard031.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" Cc: "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Wed, 20 Nov 2002 01:23:00 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom: > > Not necessarily. I think you can test/trace the > paths using LSP ping, > but of course, there is a price to pay for that too; there is > no free lunch. > The advantage of the latter is that it works with all of the hardware > deployed today. Agreed on the free lunch piece, in this case it is that LSP PING needs to run cycling the destination address until a message is missed. I'd assume this is data plane return so I am loading both ends of the LSP . Mind you with the one way option I guess availability can be measured at the far end (and skip the "is the return path broken?" step) although unless I am sending multiple copies of each address tuple, I still have simple congestive loss to consider, or port rate limiting at the egress. In other words although the ingress is cycling the address conbinations, I cannot really infer anything from missing one message at the egress, and if I have to send each address tuple multiple times as matter of course, testing all useful combinations is going to be very slow. So lets call one way mode a non-starter in this case and stick with real ping. So I remember the address tuple used on the suspect non-return case, then I try it a few more times to ensure it is not congestive loss or port rate limiting, then I try it with various return options to make sure it is not a break in the return path, (which loads the control plane of all intervening LSRs) at which point I then believe I have a real problem and I try to traceroute it. Of course I need to run much of this at a slower rate than the network convergence time as otherwise simple non-converged network state will give me spurious results. I understand your argument w.r.t. a solution retrofittable to existing gear, bit I find the sheer number of messages required to a) identify a potential problem and then b) determine it is real followed by c) isolating it, a rather depressing prospect. Esp. with a protocol that will not lend itself to easy hardware assist. I'm echoing control plane information in TLVs..... this is the essence of my concern with bounded detection times and I would observe that we are painted into a bit of a corner. If we can work towards fate sharing between the probes and the path or at least provide that option for folks who care, then we obviate the need for address cycling or multiple resends, can move to egress detection and I elimintate 90% of the maintenance overhead required to detect a problem. rgds Dave > > > > >though it would probably only be gradually available as > > > hardware changes. > > > > > > Kireeti or you made a good point that > > > this solution is not evolutionary; it is revolutionary as it > > > will require > > > hardware changes. > > > >Many things eventually migrate to hardware. Some formerly > hardware functions > >migrate to microcode. This years core LSR is next years edge > box. Are we > >saying that MPLS is frozen in time based upon last year or > the year before's > >implementation? If so, lets skip draft and simply promote > everything to STD > >and go home. > > No, I am saying that there are always going to be > low-end platforms > that have hardware limitations and thus might not be able to > use the load > share algorithm you specify in this document. What do we do > for those? > I think we are just back in the situation that we are in > today: proprietary > load balancing. It works for IP and other technologies, why > do we need > to mandate an algorithm here? > > >On the surface it might sound reasonable to > > > say that well, hardware will evolve and as it does it must support > > > this sort of load-balancing. However, the fact of the > matter is that > > > one size does not fit all in this case, and thus this > will be a burden > > > on both existing and future implementations. > > > >At the moment you're stipulating that one size fits all. > That's what the > >draft was trying to avoid. > > No, I am saying that what we have today is many sizes > fit all (in the case of load balancing) because that is a reality > of routers/switches. > > --Tom > > > >rgds > >Dave > > > > Success is relative; the more success, the more relatives. -Anonymous > > > From owner-mpls@UU.NET Wed Nov 20 09:16:23 2002 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 ESMTP id JAA19457 for ; Wed, 20 Nov 2002 09:16:23 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpun22999 for ; Wed, 20 Nov 2002 14:18:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpun20975; Wed, 20 Nov 2002 14:17:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpun21072 for mpls-outgoing; Wed, 20 Nov 2002 14:17:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpun21067 for ; Wed, 20 Nov 2002 14:17:23 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 QQnpun26806 for ; Wed, 20 Nov 2002 14:16:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpun23208 for ; Wed, 20 Nov 2002 14:16:07 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpun23199 for ; Wed, 20 Nov 2002 14:16:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA26654 for ; Wed, 20 Nov 2002 09:16:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAKEG6w23062 for mpls@uu.net; Wed, 20 Nov 2002 09:16:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpun20868 for ; Wed, 20 Nov 2002 14:15:42 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 QQnpun21268 for ; Wed, 20 Nov 2002 14:15:36 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpun14234 for ; Wed, 20 Nov 2002 14:15:35 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnpun14224 for ; Wed, 20 Nov 2002 14:15:35 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAKEFQCV029130; Wed, 20 Nov 2002 09:15:26 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn1-920.cisco.com [10.82.227.152]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD56523; Wed, 20 Nov 2002 09:15:00 -0500 (EST) Message-Id: <5.2.0.9.2.20021120091409.01aa0fd8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 20 Nov 2002 09:14:55 -0500 To: Alia Atlas From: "Thomas D. Nadeau" Subject: RE: Load balancing draft Cc: "David Allan" , "'MPLS@UU.net'" In-Reply-To: <5.1.0.14.2.20021119223854.01fa0a00@mailhost.avici.com> References: <5.2.0.9.2.20021119174038.020c2e00@bucket.cisco.com> <9FBD322B7824D511B36900508BF93C9C061EF7FA@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:40 PM 11/19/2002 -0500, Alia Atlas wrote: >At 05:45 PM 11/19/2002 -0500, Thomas D. Nadeau wrote: >> Not necessarily. I think you can test/trace the paths using LSP >> ping, >>but of course, there is a price to pay for that too; there is no free lunch. >>The advantage of the latter is that it works with all of the hardware >>deployed today. > >How does it work today with the pseudo-wire case? From the draft, it >seems that the same PW label is used, but it is not the bottom of stack, >b/c there is an explicit NULL underneath. > >So, suddenly one must forward based not only on the MPLS label but also >the bottom-of-stack bit... > >Tell me I'm missing something here, but if the above is really what is >intended in the draft, I don't understand how you can claim that it is >compatible with current MPLS hardware. It is my understanding that tracing the PW "tunnel" LSP is the same as any other MPLS LSP. --Tom From owner-mpls@UU.NET Wed Nov 20 09:22:21 2002 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 ESMTP id JAA19589 for ; Wed, 20 Nov 2002 09:22:21 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpun02237 for ; Wed, 20 Nov 2002 14:24:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpun00904; Wed, 20 Nov 2002 14:24:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpun21598 for mpls-outgoing; Wed, 20 Nov 2002 14:23:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpun21585 for ; Wed, 20 Nov 2002 14:23: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 QQnpun21589 for ; Wed, 20 Nov 2002 14:23:42 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpun29930 for ; Wed, 20 Nov 2002 14:23:42 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQnpun29917 for ; Wed, 20 Nov 2002 14:23:41 GMT Received: from aatlas-lt.avici.com ([10.2.101.113]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id gAKENNu13450; Wed, 20 Nov 2002 09:23:23 -0500 (EST) Message-Id: <5.1.0.14.2.20021120092127.01fa4dc0@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Nov 2002 09:24:42 -0500 To: "Thomas D. Nadeau" From: Alia Atlas Subject: RE: Load balancing draft Cc: "David Allan" , "'MPLS@UU.net'" In-Reply-To: <5.2.0.9.2.20021120091409.01aa0fd8@bucket.cisco.com> References: <5.1.0.14.2.20021119223854.01fa0a00@mailhost.avici.com> <5.2.0.9.2.20021119174038.020c2e00@bucket.cisco.com> <9FBD322B7824D511B36900508BF93C9C061EF7FA@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:14 AM 11/20/2002 -0500, Thomas D. Nadeau wrote: >At 10:40 PM 11/19/2002 -0500, Alia Atlas wrote: >>At 05:45 PM 11/19/2002 -0500, Thomas D. Nadeau wrote: >>> Not necessarily. I think you can test/trace the paths using LSP >>> ping, >>>but of course, there is a price to pay for that too; there is no free lunch. >>>The advantage of the latter is that it works with all of the hardware >>>deployed today. >> >>How does it work today with the pseudo-wire case? From the draft, it >>seems that the same PW label is used, but it is not the bottom of stack, >>b/c there is an explicit NULL underneath. >> >>So, suddenly one must forward based not only on the MPLS label but also >>the bottom-of-stack bit... >> >>Tell me I'm missing something here, but if the above is really what is >>intended in the draft, I don't understand how you can claim that it is >>compatible with current MPLS hardware. > > It is my understanding that tracing the PW "tunnel" LSP is the > same as any >other MPLS LSP. > > --Tom To quote from the current draft: "To test an LSP that carries non-IP traffic, before injecting ICMP and MPLS ping messages into the LSP, the IPv4 Explicit NULL label should be prepended to such messages. The ingress and egress LSR's must follow the procedures defined in [LABEL-STACKING]." Thus, as I understand it, one would have the tunnel label followed by the VC label followed by the IPv4 Explicit NULL label. Unfortunately, at the Pseudowire egress, the ingress interface would look at the VC label and forward it to the egress interface to be transmitted as a layer 2 frame. To avoid this, one would have to look at the bottom-of-stack bit... So, this sounds to me as if part of the forwarding decision is being made based upon the BOS bit. Alia From owner-mpls@UU.NET Wed Nov 20 09:32:03 2002 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 ESMTP id JAA20033 for ; Wed, 20 Nov 2002 09:32:03 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuo29765 for ; Wed, 20 Nov 2002 14:34:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpuo28351; Wed, 20 Nov 2002 14:34:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpuo22423 for mpls-outgoing; Wed, 20 Nov 2002 14:33:45 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpuo22413 for ; Wed, 20 Nov 2002 14:33:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpuo06555 for ; Wed, 20 Nov 2002 14:33:31 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuo27986 for ; Wed, 20 Nov 2002 14:33:31 GMT Received: from mail.timetra.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.104.212.2]) id QQnpuo27975 for ; Wed, 20 Nov 2002 14:33:30 GMT Received: from vkompella ([192.168.2.8]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 06:33:10 -0800 Reply-To: From: "Vach Kompella" To: "Thomas D. Nadeau" , "Alia Atlas" Cc: "David Allan" , "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Wed, 20 Nov 2002 06:32:57 -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.2911.0) In-Reply-To: <5.2.0.9.2.20021120091409.01aa0fd8@bucket.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-OriginalArrivalTime: 20 Nov 2002 14:33:10.0206 (UTC) FILETIME=[BFD0C5E0:01C290A1] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yes, the "tunnel" labels don't change. However, if an implementation "indiscriminately" uses all labels to hash on, then it would use the VC label for data packets, and VC + OAM label for OAM packets, yielding a not so nice result. In that sense, it "would be nice" to suggest that a BCP should be to ignore reserved labels. While various implementations may not be able to follow this guideline, it is still a reasonable suggestion, somewhat along the lines of saying don't use certain fields in the IP header for hashing. -Vach > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Thomas D. > Nadeau > Sent: Wednesday, November 20, 2002 6:15 AM > To: Alia Atlas > Cc: David Allan; 'MPLS@UU.net' > Subject: RE: Load balancing draft > > > At 10:40 PM 11/19/2002 -0500, Alia Atlas wrote: > >At 05:45 PM 11/19/2002 -0500, Thomas D. Nadeau wrote: > >> Not necessarily. I think you can test/trace the paths using LSP > >> ping, > >>but of course, there is a price to pay for that too; there is no free lunch. > >>The advantage of the latter is that it works with all of the hardware > >>deployed today. > > > >How does it work today with the pseudo-wire case? From the draft, it > >seems that the same PW label is used, but it is not the bottom of stack, > >b/c there is an explicit NULL underneath. > > > >So, suddenly one must forward based not only on the MPLS label but also > >the bottom-of-stack bit... > > > >Tell me I'm missing something here, but if the above is really what is > >intended in the draft, I don't understand how you can claim that it is > >compatible with current MPLS hardware. > > It is my understanding that tracing the PW "tunnel" LSP is the > same as any > other MPLS LSP. > > --Tom > > > From owner-mpls@UU.NET Wed Nov 20 09:46:50 2002 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 ESMTP id JAA20516 for ; Wed, 20 Nov 2002 09:46:50 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpup16423 for ; Wed, 20 Nov 2002 14:49:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpup13306; Wed, 20 Nov 2002 14:47:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpup23950 for mpls-outgoing; Wed, 20 Nov 2002 14:46:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpup23841 for ; Wed, 20 Nov 2002 14:46:35 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 QQnpup04900 for ; Wed, 20 Nov 2002 14:46:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpup21659 for ; Wed, 20 Nov 2002 14:46:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpup21652 for ; Wed, 20 Nov 2002 14:46:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28554 for ; Wed, 20 Nov 2002 09:46:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAKEk5T26726 for mpls@uu.net; Wed, 20 Nov 2002 09:46:05 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpuo23333 for ; Wed, 20 Nov 2002 14:44:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpuo02773 for ; Wed, 20 Nov 2002 14:44:23 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuo11240 for ; Wed, 20 Nov 2002 14:44:23 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnpuo11236 for ; Wed, 20 Nov 2002 14:44:22 GMT Received: (qmail 3119 invoked by uid 104); 20 Nov 2002 14:44:18 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4233. . Clean. Processed in 0.502494 secs); 20 Nov 2002 14:44:18 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 20 Nov 2002 14:44:17 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id gAKEiGQ14558; Wed, 20 Nov 2002 06:44:17 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 20 Nov 2002 06:44:16 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03ACF@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'vkompella@timetranetworks.com'" , "Thomas D. Nadeau" , Alia Atlas Cc: David Allan , "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Wed, 20 Nov 2002 06:44:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk This equally applies to MPLS-ping for non-IP carrying LSPs. Because for non-IP carrying LSPs there is no IP address to be cycled through (as is the case for IP-carrying LSPs) to exercise all the ICMP paths. And the inclusion of Explicit Null label in the hashing could cause MPLS-ping to take a different path from data. May be this could be captured in an Information draft. -Shahram > -----Original Message----- > From: Vach Kompella [mailto:vkompella@timetranetworks.com] > Sent: Wednesday, November 20, 2002 9:33 AM > To: Thomas D. Nadeau; Alia Atlas > Cc: David Allan; 'MPLS@UU.net' > Subject: RE: Load balancing draft > > > Yes, the "tunnel" labels don't change. However, if an implementation > "indiscriminately" uses all labels to hash on, then it would > use the VC label > for data packets, and VC + OAM label for OAM packets, > yielding a not so nice > result. > > In that sense, it "would be nice" to suggest that a BCP > should be to ignore > reserved labels. While various implementations may not be > able to follow this > guideline, it is still a reasonable suggestion, somewhat > along the lines of > saying don't use certain fields in the IP header for hashing. > > -Vach > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Thomas D. > > Nadeau > > Sent: Wednesday, November 20, 2002 6:15 AM > > To: Alia Atlas > > Cc: David Allan; 'MPLS@UU.net' > > Subject: RE: Load balancing draft > > > > > > At 10:40 PM 11/19/2002 -0500, Alia Atlas wrote: > > >At 05:45 PM 11/19/2002 -0500, Thomas D. Nadeau wrote: > > >> Not necessarily. I think you can test/trace the > paths using LSP > > >> ping, > > >>but of course, there is a price to pay for that too; > there is no free lunch. > > >>The advantage of the latter is that it works with all of > the hardware > > >>deployed today. > > > > > >How does it work today with the pseudo-wire case? From > the draft, it > > >seems that the same PW label is used, but it is not the > bottom of stack, > > >b/c there is an explicit NULL underneath. > > > > > >So, suddenly one must forward based not only on the MPLS > label but also > > >the bottom-of-stack bit... > > > > > >Tell me I'm missing something here, but if the above is > really what is > > >intended in the draft, I don't understand how you can > claim that it is > > >compatible with current MPLS hardware. > > > > It is my understanding that tracing the PW > "tunnel" LSP is the > > same as any > > other MPLS LSP. > > > > --Tom > > > > > > > From owner-mpls@UU.NET Wed Nov 20 09:49:49 2002 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 ESMTP id JAA20622 for ; Wed, 20 Nov 2002 09:49:49 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpup25139 for ; Wed, 20 Nov 2002 14:52:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpup22408; Wed, 20 Nov 2002 14:50:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpup24255 for mpls-outgoing; Wed, 20 Nov 2002 14:50:33 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpup24193 for ; Wed, 20 Nov 2002 14:50:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpup22649 for ; Wed, 20 Nov 2002 14:50:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpup24922 for ; Wed, 20 Nov 2002 14:50:07 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpup24914 for ; Wed, 20 Nov 2002 14:50:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28920 for ; Wed, 20 Nov 2002 09:50:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAKEo6S27162 for mpls@uu.net; Wed, 20 Nov 2002 09:50:06 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpup24087 for ; Wed, 20 Nov 2002 14:49: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 QQnpup13895 for ; Wed, 20 Nov 2002 14:48:50 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpup23784 for ; Wed, 20 Nov 2002 14:48:49 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpup23778 for ; Wed, 20 Nov 2002 14:48:49 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28779; Wed, 20 Nov 2002 09:48:48 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA00835; Wed, 20 Nov 2002 09:48:48 -0500 (EST) Message-Id: <200211201448.JAA00835@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: vkompella@timetranetworks.com cc: "Thomas D. Nadeau" , "Alia Atlas" , "David Allan" , "'MPLS@UU.net'" , swallow@cisco.com Subject: Re: Load balancing draft In-reply-to: Your message of "Wed, 20 Nov 2002 06:32:57 PST." Date: Wed, 20 Nov 2002 09:48:48 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > In that sense, it "would be nice" to suggest that a BCP should be to ignore > reserved labels. While various implementations may not be able to follow this > guideline, it is still a reasonable suggestion, somewhat along the lines of > saying don't use certain fields in the IP header for hashing. This is a poor analogy. It is easy to avoid sepecific fields. Avoiding specific values means testing whether the label is one of those values. Burns cycles! (or gates, take your pick) ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 20 10:01:17 2002 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 ESMTP id KAA21066 for ; Wed, 20 Nov 2002 10:01:17 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuq09367 for ; Wed, 20 Nov 2002 15:03:48 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpuq06758; Wed, 20 Nov 2002 15:02:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpuq00532 for mpls-outgoing; Wed, 20 Nov 2002 15:01:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpuq00377 for ; Wed, 20 Nov 2002 15:01: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 QQnpuq20584 for ; Wed, 20 Nov 2002 15:00:53 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuq05714 for ; Wed, 20 Nov 2002 15:00:53 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpuq05710 for ; Wed, 20 Nov 2002 15:00:52 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA29797 for ; Wed, 20 Nov 2002 10:00:52 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAKF0q702359 for mpls@uu.net; Wed, 20 Nov 2002 10:00:52 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpup25256 for ; Wed, 20 Nov 2002 14:58: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 QQnpup11940 for ; Wed, 20 Nov 2002 14:58:15 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpup03937 for ; Wed, 20 Nov 2002 14:58:15 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpup03930 for ; Wed, 20 Nov 2002 14:58:14 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA29587; Wed, 20 Nov 2002 09:58:09 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA00955; Wed, 20 Nov 2002 09:58:09 -0500 (EST) Message-Id: <200211201458.JAA00955@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Alia Atlas cc: Shahram Davari , "'MPLS@UU.net'" , swallow@cisco.com Subject: Re: Load balancing draft In-reply-to: Your message of "Tue, 19 Nov 2002 10:54:47 EST." <5.1.0.14.2.20021119105042.01f41910@mailhost.avici.com> Date: Wed, 20 Nov 2002 09:58:09 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > The concept of avoiding the reserved labels in an MPLS hash as a "best way" > makes some sense, though it would probably only be gradually available as > hardware changes. One should observe that the technique is not useful unless you are 100% sure that very box in the path from source to destination is behaving this way. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 20 10:06:32 2002 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 ESMTP id KAA21192 for ; Wed, 20 Nov 2002 10:06:31 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuq18726 for ; Wed, 20 Nov 2002 15:09:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpuq16708; Wed, 20 Nov 2002 15:08:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpuq13872 for mpls-outgoing; Wed, 20 Nov 2002 15:07:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpuq13812 for ; Wed, 20 Nov 2002 15:07: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 QQnpuq11506 for ; Wed, 20 Nov 2002 15:07:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuq15267 for ; Wed, 20 Nov 2002 15:07:07 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQnpuq14902 for ; Wed, 20 Nov 2002 15:06:56 GMT Received: from aatlas-lt.avici.com ([10.2.101.107]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id gAKF64u19165; Wed, 20 Nov 2002 10:06:05 -0500 (EST) Message-Id: <5.1.0.14.2.20021120100522.01f3f798@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Nov 2002 10:07:23 -0500 To: George Swallow From: Alia Atlas Subject: Re: Load balancing draft Cc: Shahram Davari , "'MPLS@UU.net'" , swallow@cisco.com In-Reply-To: <200211201458.JAA00955@bifocal.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:58 AM 11/20/2002 -0500, George Swallow wrote: > > The concept of avoiding the reserved labels in an MPLS hash as a "best > way" > > makes some sense, though it would probably only be gradually available as > > hardware changes. > >One should observe that the technique is not useful unless you are >100% sure that very box in the path from source to destination is >behaving this way. Why is it not incrementally useful? Every LSR along the path that does this decreases the cases where an OAM packet may take a different route from the data packet. It does require every LSR to implement to completely avoid OAM packets from taking different routes, but incrementally does simplify determining what happened to the OAM packets as compared to the data plane packets because there are fewer potential branch points. Alia From owner-mpls@UU.NET Wed Nov 20 10:34:48 2002 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 ESMTP id KAA22036 for ; Wed, 20 Nov 2002 10:34:48 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpus26817 for ; Wed, 20 Nov 2002 15:37:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpus24153; Wed, 20 Nov 2002 15:35:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpus23865 for mpls-outgoing; Wed, 20 Nov 2002 15:35:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpus23860 for ; Wed, 20 Nov 2002 15:35:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpus05323 for ; Wed, 20 Nov 2002 15:35:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpus03753 for ; Wed, 20 Nov 2002 15:35:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpus03744 for ; Wed, 20 Nov 2002 15:35:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA02740 for ; Wed, 20 Nov 2002 10:35:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAKFZ5806568 for mpls@uu.net; Wed, 20 Nov 2002 10:35:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpus23769 for ; Wed, 20 Nov 2002 15:34: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 QQnpus09174 for ; Wed, 20 Nov 2002 15:33:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpus09924 for ; Wed, 20 Nov 2002 15:33:19 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 QQnpus09916 for ; Wed, 20 Nov 2002 15:33:19 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAKFX3WT017847; Wed, 20 Nov 2002 10:33:04 -0500 (EST) Received: from tnadeau-w2k.cisco.com (rtp-vpn2-638.cisco.com [10.82.242.126]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD57997; Wed, 20 Nov 2002 10:32:39 -0500 (EST) Message-Id: <5.2.0.9.2.20021120103123.02af4e70@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 20 Nov 2002 10:32:36 -0500 To: Alia Atlas From: "Thomas D. Nadeau" Subject: Re: Load balancing draft Cc: "'MPLS@UU.net'" In-Reply-To: <5.1.0.14.2.20021120100522.01f3f798@mailhost.avici.com> References: <200211201458.JAA00955@bifocal.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:07 AM 11/20/2002 -0500, Alia Atlas wrote: >At 09:58 AM 11/20/2002 -0500, George Swallow wrote: >> > The concept of avoiding the reserved labels in an MPLS hash as a "best >> way" >> > makes some sense, though it would probably only be gradually available as >> > hardware changes. >> >>One should observe that the technique is not useful unless you are >>100% sure that very box in the path from source to destination is >>behaving this way. > >Why is it not incrementally useful? Every LSR along the path that does >this decreases the cases where an OAM packet may take a different route >from the data packet. It does require every LSR to implement to >completely avoid OAM packets from taking different routes, but >incrementally does simplify determining what happened to the OAM packets >as compared to the data plane packets because there are fewer potential >branch points. There are cases where all LSRs need to understand replies via the control plane in LSP Ping. This may not work unless everyone along the path understands what to do. --Tom From owner-mpls@UU.NET Wed Nov 20 10:36:48 2002 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 ESMTP id KAA22192 for ; Wed, 20 Nov 2002 10:36:48 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpus15494 for ; Wed, 20 Nov 2002 15:39:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpus13158; Wed, 20 Nov 2002 15:38:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpus24166 for mpls-outgoing; Wed, 20 Nov 2002 15:37:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpus24160 for ; Wed, 20 Nov 2002 15:37:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpus11483 for ; Wed, 20 Nov 2002 15:37:39 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpus12345 for ; Wed, 20 Nov 2002 15:37:38 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128]) id QQnpus12340 for ; Wed, 20 Nov 2002 15:37:38 GMT Received: from aatlas-lt.avici.com ([10.2.101.107]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id gAKFbTu23061; Wed, 20 Nov 2002 10:37:29 -0500 (EST) Message-Id: <5.1.0.14.2.20021120103543.01f40f80@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Nov 2002 10:38:47 -0500 To: "Thomas D. Nadeau" From: Alia Atlas Subject: Re: Load balancing draft Cc: "'MPLS@UU.net'" In-Reply-To: <5.2.0.9.2.20021120103123.02af4e70@bucket.cisco.com> References: <5.1.0.14.2.20021120100522.01f3f798@mailhost.avici.com> <200211201458.JAA00955@bifocal.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:32 AM 11/20/2002 -0500, Thomas D. Nadeau wrote: >At 10:07 AM 11/20/2002 -0500, Alia Atlas wrote: >>At 09:58 AM 11/20/2002 -0500, George Swallow wrote: >>> > The concept of avoiding the reserved labels in an MPLS hash as a >>> "best way" >>> > makes some sense, though it would probably only be gradually available as >>> > hardware changes. >>> >>>One should observe that the technique is not useful unless you are >>>100% sure that very box in the path from source to destination is >>>behaving this way. >> >>Why is it not incrementally useful? Every LSR along the path that does >>this decreases the cases where an OAM packet may take a different route >>from the data packet. It does require every LSR to implement to >>completely avoid OAM packets from taking different routes, but >>incrementally does simplify determining what happened to the OAM packets >>as compared to the data plane packets because there are fewer potential >>branch points. > > There are cases where all LSRs need to understand >replies via the control plane in LSP Ping. This may not >work unless everyone along the path understands what to >do. Tom, Now I am confused. We are discussing the load-balancing done internally in an LSR. This is currently proprietary and different between different LSRs. How does recommending not including the OAM labels suddenly break MPLS ping? This has nothing to do with understanding the replies via the control plane in MPLS ping. If it did, then we'd already have a problem with MPLS ping, because the load-balancing algorithms currently extant are different. Alia From owner-mpls@UU.NET Wed Nov 20 11:21:43 2002 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 ESMTP id LAA23661 for ; Wed, 20 Nov 2002 11:21:43 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuv16917 for ; Wed, 20 Nov 2002 16:24:19 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpuv15217; Wed, 20 Nov 2002 16:23:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpuv17109 for mpls-outgoing; Wed, 20 Nov 2002 16:22:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpuv17104 for ; Wed, 20 Nov 2002 16:22:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpuv17459 for ; Wed, 20 Nov 2002 16:22:07 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuv14226 for ; Wed, 20 Nov 2002 16:22:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpuv14214 for ; Wed, 20 Nov 2002 16:22:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08826 for ; Wed, 20 Nov 2002 11:22:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAKGM5D11055 for mpls@uu.net; Wed, 20 Nov 2002 11:22:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpuv17006 for ; Wed, 20 Nov 2002 16:20:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpuv12297 for ; Wed, 20 Nov 2002 16:20:02 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuv12848 for ; Wed, 20 Nov 2002 16:20:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpuv12832 for ; Wed, 20 Nov 2002 16:20:01 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08664; Wed, 20 Nov 2002 11:20:01 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA01500; Wed, 20 Nov 2002 11:20:00 -0500 (EST) Message-Id: <200211201620.LAA01500@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Alia Atlas cc: George Swallow , Shahram Davari , "'MPLS@UU.net'" , swallow@cisco.com Subject: Re: Load balancing draft In-reply-to: Your message of "Wed, 20 Nov 2002 10:07:23 EST." <5.1.0.14.2.20021120100522.01f3f798@mailhost.avici.com> Date: Wed, 20 Nov 2002 11:20:00 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Why is it not incrementally useful? Every LSR along the path that does > this decreases the cases where an OAM packet may take a different route > from the data packet. It does require every LSR to implement to > completely avoid OAM packets from taking different routes, but > incrementally does simplify determining what happened to the OAM packets as > compared to the data plane packets because there are fewer potential branch > points. Well if you want your CV OAM to make you pretty sure, then yes, you get surer as you incrementally deploy. But most of the time you can be pretty sure with much lighter overhead. So I was assuming (perhaps incorectly) that someone who want to send a CV OAM packet every second wanted to be 100% sure. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 20 11:46:20 2002 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 ESMTP id LAA24455 for ; Wed, 20 Nov 2002 11:46:20 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpux12709 for ; Wed, 20 Nov 2002 16:48:55 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpux10443; Wed, 20 Nov 2002 16:47:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpux19615 for mpls-outgoing; Wed, 20 Nov 2002 16:47:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpux19605 for ; Wed, 20 Nov 2002 16:46: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 QQnpux06354 for ; Wed, 20 Nov 2002 16:46:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpux06016 for ; Wed, 20 Nov 2002 16:46:07 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpux06000 for ; Wed, 20 Nov 2002 16:46:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA10702 for ; Wed, 20 Nov 2002 11:46:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAKGk6C13733 for mpls@uu.net; Wed, 20 Nov 2002 11:46:06 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpuw18978 for ; Wed, 20 Nov 2002 16:44:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpuw15052 for ; Wed, 20 Nov 2002 16:44:36 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpuw07755 for ; Wed, 20 Nov 2002 16:44:35 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQnpuw07751 for ; Wed, 20 Nov 2002 16:44:35 GMT Received: (qmail 27327 invoked by uid 104); 20 Nov 2002 16:44:34 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4233. . Clean. Processed in 0.472594 secs); 20 Nov 2002 16:44:34 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 20 Nov 2002 16:44:33 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id gAKGiXQ29243; Wed, 20 Nov 2002 08:44:33 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Wed, 20 Nov 2002 08:44:33 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03AD7@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , Alia Atlas Cc: "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Wed, 20 Nov 2002 08:44:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk >But most of the time you can > be pretty sure with much lighter overhead. How? -Shahram From owner-mpls@UU.NET Wed Nov 20 15:26:16 2002 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 ESMTP id PAA29932 for ; Wed, 20 Nov 2002 15:26:16 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpvl09075 for ; Wed, 20 Nov 2002 20:28:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpvl07637; Wed, 20 Nov 2002 20:28:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpvl20869 for mpls-outgoing; Wed, 20 Nov 2002 20:27:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpvl20857 for ; Wed, 20 Nov 2002 20:27:52 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 QQnpvl07172 for ; Wed, 20 Nov 2002 20:27:10 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpvl12852 for ; Wed, 20 Nov 2002 20:27:10 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnpvl12847 for ; Wed, 20 Nov 2002 20:27:09 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAKKQYt29015; Wed, 20 Nov 2002 15:26:34 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Nov 2002 15:26:34 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C0628230B@zcard031.ca.nortel.com> From: "David Allan" To: George Swallow , Alia Atlas Cc: Shahram Davari , "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Wed, 20 Nov 2002 15:26:31 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk George: If you look at my post from rather late last night, I'd question the lighter overhead assertion. This discussion is really orthogonal to the probe frequency and is more concerned with the probe quantity/quality to determine there is a problem. Goodness and scalability (and again my favorite "bounded detection time") can be expressed as how authoritative a test result is in proportion to the messages expended. Also the fewer heuristics required to interpret the test results, the more reliable the overall system is.... rgds Dave > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, November 20, 2002 11:20 AM > To: Alia Atlas > Cc: George Swallow; Shahram Davari; 'MPLS@UU.net'; swallow@cisco.com > Subject: Re: Load balancing draft > > > > Why is it not incrementally useful? Every LSR along the > path that does > > this decreases the cases where an OAM packet may take a > different route > > from the data packet. It does require every LSR to implement to > > completely avoid OAM packets from taking different routes, but > > incrementally does simplify determining what happened to > the OAM packets as > > compared to the data plane packets because there are fewer > potential branch > > points. > > Well if you want your CV OAM to make you pretty sure, then yes, you > get surer as you incrementally deploy. But most of the time you can > be pretty sure with much lighter overhead. So I was assuming (perhaps > incorectly) that someone who want to send a CV OAM packet every second > wanted to be 100% sure. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Wed Nov 20 16:02:01 2002 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 ESMTP id QAA00716 for ; Wed, 20 Nov 2002 16:02:01 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpvo11349 for ; Wed, 20 Nov 2002 21:04:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpvo08230; Wed, 20 Nov 2002 21:02:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpvo03842 for mpls-outgoing; Wed, 20 Nov 2002 21:02:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpvo03780 for ; Wed, 20 Nov 2002 21:01:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpvo08975 for ; Wed, 20 Nov 2002 21:00:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpvo06457 for ; Wed, 20 Nov 2002 21:00:14 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpvo06453 for ; Wed, 20 Nov 2002 21:00:13 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA01005 for ; Wed, 20 Nov 2002 16:00:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAKL0D629462 for mpls@uu.net; Wed, 20 Nov 2002 16:00:13 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpvn23424 for ; Wed, 20 Nov 2002 20:59:09 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 QQnpvn20238 for ; Wed, 20 Nov 2002 20:58:38 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpvn05139 for ; Wed, 20 Nov 2002 20:58:37 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpvn05135 for ; Wed, 20 Nov 2002 20:58:37 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA00869; Wed, 20 Nov 2002 15:58:36 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA03458; Wed, 20 Nov 2002 15:58:36 -0500 (EST) Message-Id: <200211202058.PAA03458@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: "David Allan" cc: George Swallow , Alia Atlas , Shahram Davari , "'MPLS@UU.net'" , swallow@cisco.com Subject: Re: Load balancing draft In-reply-to: Your message of "Wed, 20 Nov 2002 15:26:31 EST." <9FBD322B7824D511B36900508BF93C9C0628230B@zcard031.ca.nortel.com> Date: Wed, 20 Nov 2002 15:58:36 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > If you look at my post from rather late last night, I'd question the lighter > overhead assertion. This discussion is really orthogonal to the probe > frequency and is more concerned with the probe quantity/quality to determine > there is a problem. Goodness and scalability (and again my favorite "bounded > detection time") can be expressed as how authoritative a test result is in > proportion to the messages expended. Also the fewer heuristics required to > interpret the test results, the more reliable the overall system is.... My only point is that if your measurement is based on the assumption that all load-balancing is being done in a prescribed manner, then the quality of that measurement is very much dependent on the certainty that all of the nodes in the path are actually behaving according to that assumption. On node behaving differently could reroute a large portion (or all) of the probes. Thus the measurement could be far from the actual behavior. ...George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Nov 20 22:02:27 2002 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 ESMTP id WAA09640 for ; Wed, 20 Nov 2002 22:01:22 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpwm08819 for ; Thu, 21 Nov 2002 03:03:58 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpwm07100; Thu, 21 Nov 2002 03:03:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpwm14592 for mpls-outgoing; Thu, 21 Nov 2002 03:02:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpwm12137 for ; Thu, 21 Nov 2002 03:02:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpwm23357 for ; Thu, 21 Nov 2002 03:00:57 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpwm05611 for ; Thu, 21 Nov 2002 03:00:57 GMT Received: from lxmail.xebeo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.xebeo.com [204.192.44.242]) id QQnpwm05601 for ; Thu, 21 Nov 2002 03:00:57 GMT Received: (qmail 19311 invoked from network); 21 Nov 2002 03:00:56 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 21 Nov 2002 03:00:56 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id WAA29399; Wed, 20 Nov 2002 22:00:56 -0500 Message-Id: <200211210300.WAA29399@bigbird.xebeo.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Adrian Farrel" cc: mpls@UU.NET Subject: Re: bi-directional LSPs In-Reply-To: Message from "Adrian Farrel" of "Wed, 20 Nov 2002 19:21:01 EST." <005b01c290f3$e02ca4b0$fe14588a@movaz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Nov 2002 22:00:56 -0500 From: Rohit Dube Sender: owner-mpls@UU.NET Precedence: bulk Adrian, On Wed, 20 Nov 2002 19:21:01 -0500 "Adrian Farrel" writes: =>> At the MPLS WG meeting, the question came up that GMPLS already =>> supports bi-directional LSPs. As Rahul pointed out, this only =>> works for generalized labels and not for "classical" labels. => =>Perhaps Rahul can comment, but I don't think that is what he meant at all. => =>What I heard him say (and what is factually correct) is that GMPLS only works =>with the Generalized Label Object. These objects can perfectly well contain =>"normal" 23 bit MPLS labels. The Generalized Label Request can ask for such =>labels. Yes this is what I meant. Sorry if it wasn't clear. => =>His comment was that since some change is needed in the implementation to =>support bidirectional labels it is of no consequence which change is made and > so =>you might as well move the Label Object and Label Request Object to be =>Generalized. => =>> Here is some further clarification on the topic. =>> =>> For classical mpls networks there are two ways of supporting =>> bidirectional lsps. One method is to make the UPSTREAM_LABEL =>> objects applicable to classic MPLS labels. => =>They are already since the upstream label contains a generalized label and =>generalized labels can contain MPLS labels. Yes. But what I am trying to say is that an mpls implementation or a network which uses one can move to supporting bi-directional lsps in two ways. The one that I mentioned simply applies existing operations to regular mpls labels. The alternate is what you mention. Both are feasible and one doesn't exclude the other. => =>> The other is to =>> exchange "generalized" labels between nodes that want to =>> support bidirectional LSPs while continuing with classical =>> labels for uni-directional ones. The draft presented uses =>> the former approach. =>> =>> While both approaches are valid, for nodes that run classical =>> MPLS already and which need to support uni-directional as well =>> as bi-directional LSPs, this seems to be the easier approach as =>> the operator and the implementor need to deal with just one =>> type of label. => => =>I think at this point you really need to differentiate between label objects >and =>the labels they carry. ???? => => =>> The -01 version of the draft proposes an UPSTREAM_FLOWSPEC =>> object which allows for asymmetric bandwidth reservation =>> by carrying the required information for the reverse path =>> in the PATH message. The updated draft is available at =>> =>http://members.tripod.com/~rohit_dube/papers/draft-dube-bidirectional-lsp-01. >txt => =>Asymmetric bidirectional LSPs are a different matter altogether. =>If there is a requirement for this, it should surely be moved to ccamp. Sure I can deal with them separately. The reason why I mention them at all wrt bi-directional lsps is that they make sense only when talking about bi-directional lsps in the first place. => =>> The updated version of the draft should appear on ietf's =>> web-site when the draft queue starts getting processed again. => =>I suggest you notify the ccmap WG of the existence of this draft and the =>discussion on the MPLS list. => =>Adrian => --rohit. From owner-mpls@UU.NET Wed Nov 20 22:38:36 2002 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 ESMTP id WAA10662 for ; Wed, 20 Nov 2002 22:37:30 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpwb05057 for ; Thu, 21 Nov 2002 00:24:18 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpwb29817; Thu, 21 Nov 2002 00:21:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpwb19876 for mpls-outgoing; Thu, 21 Nov 2002 00:21:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpwb19858 for ; Thu, 21 Nov 2002 00:21:23 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 QQnpwb29834 for ; Thu, 21 Nov 2002 00:20:59 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpwb21692 for ; Thu, 21 Nov 2002 00:20:59 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQnpwb21687 for ; Thu, 21 Nov 2002 00:20:59 GMT Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 20 Nov 2002 19:20:57 -0500 Message-ID: <005b01c290f3$e02ca4b0$fe14588a@movaz.com> From: "Adrian Farrel" To: , "Rohit Dube" References: <200211192125.QAA10835@bigbird.xebeo.com> Subject: Re: bi-directional LSPs Date: Wed, 20 Nov 2002 19:21:01 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 21 Nov 2002 00:20:58.0925 (UTC) FILETIME=[DD9C35D0:01C290F3] Sender: owner-mpls@UU.NET Precedence: bulk > At the MPLS WG meeting, the question came up that GMPLS already > supports bi-directional LSPs. As Rahul pointed out, this only > works for generalized labels and not for "classical" labels. Perhaps Rahul can comment, but I don't think that is what he meant at all. What I heard him say (and what is factually correct) is that GMPLS only works with the Generalized Label Object. These objects can perfectly well contain "normal" 23 bit MPLS labels. The Generalized Label Request can ask for such labels. His comment was that since some change is needed in the implementation to support bidirectional labels it is of no consequence which change is made and so you might as well move the Label Object and Label Request Object to be Generalized. > Here is some further clarification on the topic. > > For classical mpls networks there are two ways of supporting > bidirectional lsps. One method is to make the UPSTREAM_LABEL > objects applicable to classic MPLS labels. They are already since the upstream label contains a generalized label and generalized labels can contain MPLS labels. > The other is to > exchange "generalized" labels between nodes that want to > support bidirectional LSPs while continuing with classical > labels for uni-directional ones. The draft presented uses > the former approach. > > While both approaches are valid, for nodes that run classical > MPLS already and which need to support uni-directional as well > as bi-directional LSPs, this seems to be the easier approach as > the operator and the implementor need to deal with just one > type of label. I think at this point you really need to differentiate between label objects and the labels they carry. > The -01 version of the draft proposes an UPSTREAM_FLOWSPEC > object which allows for asymmetric bandwidth reservation > by carrying the required information for the reverse path > in the PATH message. The updated draft is available at > http://members.tripod.com/~rohit_dube/papers/draft-dube-bidirectional-lsp-01.txt Asymmetric bidirectional LSPs are a different matter altogether. If there is a requirement for this, it should surely be moved to ccamp. > The updated version of the draft should appear on ietf's > web-site when the draft queue starts getting processed again. I suggest you notify the ccmap WG of the existence of this draft and the discussion on the MPLS list. Adrian From owner-mpls@UU.NET Wed Nov 20 23:56:41 2002 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 ESMTP id XAA12020 for ; Wed, 20 Nov 2002 23:55:35 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpwe09270 for ; Thu, 21 Nov 2002 01:14:45 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpwe02172; Thu, 21 Nov 2002 01:10:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpwe09959 for mpls-outgoing; Thu, 21 Nov 2002 01:10:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpwe09884 for ; Thu, 21 Nov 2002 01:10:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpwe09145 for ; Thu, 21 Nov 2002 01:09:22 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpwe19842 for ; Thu, 21 Nov 2002 01:09:22 GMT Received: from zcars04e.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnpwe19835 for ; Thu, 21 Nov 2002 01:09:22 GMT Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAL18iC22281; Wed, 20 Nov 2002 20:08:44 -0500 (EST) Received: from zcard0ke.ca.nortel.com ([47.129.242.166]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WJLF8JDL; Wed, 20 Nov 2002 20:08:44 -0500 Received: from nortelnetworks.com (artpt5qn.us.nortel.com [47.140.52.139]) by zcard0ke.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK5D4SK; Wed, 20 Nov 2002 20:08:44 -0500 Message-ID: <3DDC3345.3090503@nortelnetworks.com> Date: Wed, 20 Nov 2002 20:13:41 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Don Fedyk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Swallow CC: "David Allan" , Alia Atlas , Shahram Davari , "'MPLS@UU.net'" Subject: Re: Load balancing draft References: <200211202058.PAA03458@bifocal.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George to be fair I heard Dave say that the load balancing should not use certain fields which are part of the label stack. This does not require that balancing be done in a prescribed manner, freedom is still there. Instead load balancing should be correct with respect to all of MPLS formats including reserved labels. Don George Swallow wrote: >>If you look at my post from rather late last night, I'd question the lighter >>overhead assertion. This discussion is really orthogonal to the probe >>frequency and is more concerned with the probe quantity/quality to determine >>there is a problem. Goodness and scalability (and again my favorite "bounded >>detection time") can be expressed as how authoritative a test result is in >>proportion to the messages expended. Also the fewer heuristics required to >>interpret the test results, the more reliable the overall system is.... >> >> > >My only point is that if your measurement is based on the assumption >that all load-balancing is being done in a prescribed manner, then the >quality of that measurement is very much dependent on the certainty >that all of the nodes in the path are actually behaving according to >that assumption. On node behaving differently could reroute a large >portion (or all) of the probes. Thus the measurement could be far >from the actual behavior. > >...George > >================================================================== >George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Thu Nov 21 02:00:11 2002 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 ESMTP id BAA14446 for ; Thu, 21 Nov 2002 01:59:05 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpwy19364 for ; Thu, 21 Nov 2002 06:12:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpwy17729; Thu, 21 Nov 2002 06:11:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpwy00722 for mpls-outgoing; Thu, 21 Nov 2002 06:11:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpwy00650 for ; Thu, 21 Nov 2002 06:10: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 QQnpwy13277 for ; Thu, 21 Nov 2002 06:10:08 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpwy25157 for ; Thu, 21 Nov 2002 06:10:08 GMT Received: from mail.site.uottawa.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailn.site.uottawa.ca [137.122.89.142]) id QQnpwy25143 for ; Thu, 21 Nov 2002 06:10:04 GMT Received: from bwwil28 (bwwil28.site.uottawa.ca [137.122.91.149]) by mail.site.uottawa.ca (8.9.3/8.9.3) with SMTP id BAA01887; Thu, 21 Nov 2002 01:08:50 -0500 (EST) Message-ID: <003201c29124$d644f9d0$955b7a89@bwwil28> From: "Bin Zhou" To: "Francois Le Faucheur \(flefauch\)" , , "Sasha Vainshtein" Cc: "Vishal M" , , "Shahram Davari" References: Subject: Reservation DiffServ MPLS (E-LSP & L-LSP) Date: Thu, 21 Nov 2002 01:11:26 -0500 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have a question about how to reserve bandwidth for a tunnel (mutiple OA) with E-LSP or L-LSP using rsvp. As I understand it, we can reserve bandwidth for an LSP (single OA) with E-LSP or L-LSP using rsvp. - In E-LSP case, we cann't support mutiple Sender_TSPEC (one TSPEC for one OA, one RSPEC for one TSPEC, but only one TSPEC in the PATH message). - In L-LSP case, we cann't support mutiple OA in one LSP (one LSP for one OA). In another words, my question is how to signal bandwidth for mutiple OA in one E-LSP, or wheather it is possible to have mutiple LSP in one tunnel. Thanks. Bin ZHou From owner-mpls@UU.NET Thu Nov 21 09:38:11 2002 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 ESMTP id JAA04240 for ; Thu, 21 Nov 2002 09:37:06 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpxj02876 for ; Thu, 21 Nov 2002 08:54:53 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpxj01053; Thu, 21 Nov 2002 08:53:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpxj19621 for mpls-outgoing; Thu, 21 Nov 2002 08:53:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpxj19616 for ; Thu, 21 Nov 2002 08:53:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpxj02702 for ; Thu, 21 Nov 2002 08:53:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpxj06065 for ; Thu, 21 Nov 2002 08:53:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpxj06059 for ; Thu, 21 Nov 2002 08:53:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA10160 for ; Thu, 21 Nov 2002 03:53:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAL8r6K05938 for mpls@uu.net; Thu, 21 Nov 2002 03:53:06 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpxj19569 for ; Thu, 21 Nov 2002 08:51:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpxj28686 for ; Thu, 21 Nov 2002 08:50:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpxj04156 for ; Thu, 21 Nov 2002 08:50:08 GMT Received: from xover.netplane.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fwout.maker.com [12.27.183.253] (may be forged)) id QQnpxj04146 for ; Thu, 21 Nov 2002 08:50:07 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HQ4CM>; Thu, 21 Nov 2002 03:50:06 -0500 Message-ID: From: Krishna Mohan Varma To: "'Bin Zhou'" Cc: mpls@UU.NET Subject: RE: Reservation DiffServ MPLS (E-LSP & L-LSP) Date: Thu, 21 Nov 2002 03:52:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk This link http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-02.txt will address your query. Thanks Varma -----Original Message----- From: Bin Zhou [mailto:binzhou@site.uottawa.ca] Sent: Thursday, November 21, 2002 11:41 AM To: Francois Le Faucheur (flefauch); curtis@fictitious.org; Sasha Vainshtein Cc: Vishal M; mpls@UU.NET; Shahram Davari Subject: Reservation DiffServ MPLS (E-LSP & L-LSP) Hello, I have a question about how to reserve bandwidth for a tunnel (mutiple OA) with E-LSP or L-LSP using rsvp. As I understand it, we can reserve bandwidth for an LSP (single OA) with E-LSP or L-LSP using rsvp. - In E-LSP case, we cann't support mutiple Sender_TSPEC (one TSPEC for one OA, one RSPEC for one TSPEC, but only one TSPEC in the PATH message). - In L-LSP case, we cann't support mutiple OA in one LSP (one LSP for one OA). In another words, my question is how to signal bandwidth for mutiple OA in one E-LSP, or wheather it is possible to have mutiple LSP in one tunnel. Thanks. Bin ZHou From owner-mpls@UU.NET Thu Nov 21 10:03:11 2002 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 ESMTP id KAA05585 for ; Thu, 21 Nov 2002 10:03:11 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyg28360 for ; Thu, 21 Nov 2002 14:36:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpyg25793; Thu, 21 Nov 2002 14:34:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpyg13964 for mpls-outgoing; Thu, 21 Nov 2002 14:34:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpyg13938 for ; Thu, 21 Nov 2002 14:34:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpyg02100 for ; Thu, 21 Nov 2002 14:34:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyg25483 for ; Thu, 21 Nov 2002 14:34:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpyg25475 for ; Thu, 21 Nov 2002 14:34:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA23914 for ; Thu, 21 Nov 2002 09:34:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gALEY5q22062 for mpls@uu.net; Thu, 21 Nov 2002 09:34:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpyg13552 for ; Thu, 21 Nov 2002 14:33:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpyg24025 for ; Thu, 21 Nov 2002 14:32:47 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyg24625 for ; Thu, 21 Nov 2002 14:32:46 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpyg24618 for ; Thu, 21 Nov 2002 14:32:46 GMT Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA23853; Thu, 21 Nov 2002 09:32:46 -0500 (EST) Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA11060; Thu, 21 Nov 2002 09:32:45 -0500 (EST) Message-Id: <200211211432.JAA11060@bifocal.cisco.com> X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs To: Don Fedyk cc: George Swallow , "David Allan" , Alia Atlas , Shahram Davari , "'MPLS@UU.net'" , swallow@cisco.com Subject: Re: Load balancing draft In-reply-to: Your message of "Wed, 20 Nov 2002 20:13:41 EST." <3DDC3345.3090503@nortelnetworks.com> Date: Thu, 21 Nov 2002 09:32:45 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Don - This seems to a non-sequitor. I don't see how this comment relates to what I wrote below. Were you trying to answer some other message? ...George > George to be fair I heard Dave say that the load balancing should not > use certain fields which are part of the label stack. This does not > require that balancing be done in a prescribed manner, freedom is still > there. Instead load balancing should be correct with respect to all of > MPLS formats including reserved labels. > > Don > > George Swallow wrote: > > >>If you look at my post from rather late last night, I'd question the lighter > >>overhead assertion. This discussion is really orthogonal to the probe > >>frequency and is more concerned with the probe quantity/quality to determine > >>there is a problem. Goodness and scalability (and again my favorite "bounded > >>detection time") can be expressed as how authoritative a test result is in > >>proportion to the messages expended. Also the fewer heuristics required to > >>interpret the test results, the more reliable the overall system is.... > >> > >> > > > >My only point is that if your measurement is based on the assumption > >that all load-balancing is being done in a prescribed manner, then the > >quality of that measurement is very much dependent on the certainty > >that all of the nodes in the path are actually behaving according to > >that assumption. On node behaving differently could reroute a large > >portion (or all) of the probes. Thus the measurement could be far > >from the actual behavior. > > ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Nov 21 11:16:38 2002 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 ESMTP id LAA08567 for ; Thu, 21 Nov 2002 11:16:38 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpym10650 for ; Thu, 21 Nov 2002 16:14:14 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpym08681; Thu, 21 Nov 2002 16:13:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpym12991 for mpls-outgoing; Thu, 21 Nov 2002 16:12:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpym12986 for ; Thu, 21 Nov 2002 16:12:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpym25200 for ; Thu, 21 Nov 2002 16:12:21 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpym18881 for ; Thu, 21 Nov 2002 16:12:20 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnpym18870 for ; Thu, 21 Nov 2002 16:12:20 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gALGBaw13596; Thu, 21 Nov 2002 11:11:36 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 11:11:37 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C062828BE@zcard031.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" , "Don Fedyk" Cc: George Swallow , "Don Fedyk" , Alia Atlas , Shahram Davari , "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Thu, 21 Nov 2002 11:11:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29178.A9C69BC6" 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_01C29178.A9C69BC6 Content-Type: text/plain; charset="iso-8859-1" Tom: Not entirely true, any point where there is useful predictability reduces the number of possible faults that may only be caught by random process. IMHO that is useful. cheers Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, November 21, 2002 10:59 AM > To: Fedyk, Don [BL60:1A00:EXCH] > Cc: George Swallow; Fedyk, Don [BL60:1A00:EXCH]; Allan, David > [CAR:NS00:EXCH]; Alia Atlas; Shahram Davari; 'MPLS@UU.net' > Subject: Re: Load balancing draft > > > > >George > > > >Let me restate. You Said "All load balancing done in > prescribed manner." > >Which is certainly restrictive. The Draft for load balancing > says not to > >use certain fields. That is not the same. So I added different > >implementations for load balancing following the draft still > have freedoms > >and different vendors can choose different algorithms. > > Not really. If you want things to work the way the > draft aspires > them to, then everyone in the MPLS domain must use the same, > predictable load balancing algorithm. Going halfway doesn't work, > and is arguably no better than what we have today. > > --Tom > > > >Hope that makes it clear, > >Don . > >George Swallow wrote: > > > >>Don - > >> > >>This seems to a non-sequitor. I don't see how this comment > relates to > >>what I wrote below. Were you trying to answer some other message? > >> > >>...George > >> > >> > >> > >>>George to be fair I heard Dave say that the load > balancing should not > >>>use certain fields which are part of the label stack. This > does not > >>>require that balancing be done in a prescribed manner, > freedom is still > >>>there. Instead load balancing should be correct with > respect to all of > >>>MPLS formats including reserved labels. > >>> > >>>Don > >>> > >>>George Swallow wrote: > >>> > >>> > >>> > >>>>>If you look at my post from rather late last night, I'd > question the > >>>>>lighter > >>>>>overhead assertion. This discussion is really orthogonal > to the probe > >>>>>frequency and is more concerned with the probe > quantity/quality to > >>>>>determine > >>>>>there is a problem. Goodness and scalability (and again > my favorite > >>>>>"bounded > >>>>>detection time") can be expressed as how authoritative a > test result is in > >>>>>proportion to the messages expended. Also the fewer > heuristics required to > >>>>>interpret the test results, the more reliable the > overall system is.... > >>>>> > >>>>> > >>>>My only point is that if your measurement is based on the > assumption > >>>>that all load-balancing is being done in a prescribed > manner, then the > >>>>quality of that measurement is very much dependent on the > certainty > >>>>that all of the nodes in the path are actually behaving > according to > >>>>that assumption. On node behaving differently could > reroute a large > >>>>portion (or all) of the probes. Thus the measurement could be far > >>>> > >>>> > >>>>from the actual behavior. > >>> > >> > >>================================================================== > >>George Swallow Cisco Systems (978) 497-8143 > >> 250 Apollo Drive > >> Chelmsford, Ma 01824 > >> > >> > > > > Success is relative; the more success, the more relatives. -Anonymous > > > ------_=_NextPart_001_01C29178.A9C69BC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Load balancing draft

Tom:

Not entirely true, any point where there is useful = predictability reduces the number of possible faults that may only be = caught by random process. IMHO that is useful.

cheers
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Thursday, November 21, 2002 10:59 = AM
> To: Fedyk, Don [BL60:1A00:EXCH]
> Cc: George Swallow; Fedyk, Don = [BL60:1A00:EXCH]; Allan, David
> [CAR:NS00:EXCH]; Alia Atlas; Shahram Davari; = 'MPLS@UU.net'
> Subject: Re: Load balancing draft
>
>
>
> >George
> >
> >Let me restate. You Said "All load = balancing done in
> prescribed manner."
> >Which is certainly restrictive. The Draft = for load balancing
> says  not to
> >use certain fields. That is not the same. = So I added different
> >implementations for load balancing = following the draft still
> have freedoms
> >and different vendors can choose different = algorithms.
>
>          Not = really. If you want things to work the way the
> draft aspires
> them to, then everyone in the MPLS domain must = use the same,
> predictable load balancing algorithm.  = Going halfway doesn't work,
> and is arguably no better than what we have = today.
>
>          = --Tom
>
>
> >Hope that makes it clear,
> >Don .
> >George Swallow wrote:
> >
> >>Don -
> >>
> >>This seems to a non-sequitor.  I = don't see how this comment
> relates to
> >>what I wrote below.  Were you = trying to answer some other message?
> >>
> >>...George
> >>
> >>
> >>
> >>>George to be fair I heard Dave = say  that the load
> balancing should not
> >>>use certain fields which are part = of the label stack. This
> does not
> >>>require that balancing be done in a = prescribed manner,
> freedom is still
> >>>there. Instead load balancing = should be correct with
> respect to all of
> >>>MPLS formats  including = reserved labels.
> >>>
> >>>Don
> >>>
> >>>George Swallow wrote:
> >>>
> >>>
> >>>
> >>>>>If you look at my post from = rather late last night, I'd
> question the
> >>>>>lighter
> >>>>>overhead assertion. This = discussion is really orthogonal
> to the probe
> >>>>>frequency and is more = concerned with the probe
> quantity/quality to
> >>>>>determine
> >>>>>there is a problem. = Goodness and scalability (and again
> my favorite
> >>>>>"bounded
> >>>>>detection time") can = be expressed as how authoritative a
> test result is in
> >>>>>proportion to the messages = expended. Also the fewer
> heuristics required to
> >>>>>interpret the test results, = the more reliable the
> overall system is....
> >>>>>
> >>>>>
> >>>>My only point is that if your = measurement is based on the
> assumption
> >>>>that all load-balancing is = being done in a prescribed
> manner, then the
> >>>>quality of that measurement is = very much dependent on the
> certainty
> >>>>that all of the nodes in the = path are actually behaving
> according to
> >>>>that assumption.  On node = behaving differently could
> reroute a large
> >>>>portion (or all) of the = probes.  Thus the measurement could be far
> >>>>
> >>>>
> >>>>from the actual = behavior.
> >>>
> >>
> = >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>George = Swallow       Cisco = Systems           = ;       (978) 497-8143
> = >>          &nbs= p;          250 Apollo = Drive
> = >>          &nbs= p;          Chelmsford, Ma = 01824
> >>
> >>
> >
>
> Success is relative; the more success, the more = relatives. -Anonymous
>
>
>

------_=_NextPart_001_01C29178.A9C69BC6-- From owner-mpls@UU.NET Thu Nov 21 11:53:13 2002 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 ESMTP id LAA10173 for ; Thu, 21 Nov 2002 11:52:06 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyp12528 for ; Thu, 21 Nov 2002 16:54:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpyp10374; Thu, 21 Nov 2002 16:53:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpyp23205 for mpls-outgoing; Thu, 21 Nov 2002 16:53:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpyp23168 for ; Thu, 21 Nov 2002 16:53:18 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 QQnpyp07069 for ; Thu, 21 Nov 2002 16:52:43 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyp22736 for ; Thu, 21 Nov 2002 16:52:42 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 QQnpyp22732 for ; Thu, 21 Nov 2002 16:52:42 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 LAA20903 for ; Thu, 21 Nov 2002 11:52:40 -0500 (EST) 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 LAA00451 for ; Thu, 21 Nov 2002 11:52:40 -0500 (EST) Message-ID: <3DDD0F65.7000507@marconi.com> Date: Thu, 21 Nov 2002 11:52:53 -0500 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: GMPLS features applicable to MPLS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit During the course of development, I have noticed that there are several features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09) that are applicable to non-generalized MPLS networks. Two immediately come to mind: 1: Support unnumbered links in explicit routes (as defined by draft-ietf-mpls-rsvp-unnum-08) which requires as a prerequisite, support for the IF_ID versions of the HOP and ERROR_SPEC objects (section 8) 2: Fault handling and restart capabilities (section 9) Right now, in order to provide thse features in an MPLS switch, one must either use a proprietary solution, or must attempt a partial implementation of GMPLS for the MPLS environment. What should be done about this? I don't think it's appropriate to simply tell people "use GMPLS or do without the features". Perhaps a section on applicability to MPLS networks can be added to the relevant GMPLS drafts? Or perhaps those sections of GMPLS that are also applicable to MPLS should be broken off into separate drafts? Opinions? -- David From owner-mpls@UU.NET Thu Nov 21 12:04:25 2002 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 ESMTP id MAA10575 for ; Thu, 21 Nov 2002 12:04:24 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyq26408 for ; Thu, 21 Nov 2002 17:06:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpyq23945; Thu, 21 Nov 2002 17:05:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpyq11602 for mpls-outgoing; Thu, 21 Nov 2002 17:05:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpyq11590 for ; Thu, 21 Nov 2002 17:05:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpyq01152 for ; Thu, 21 Nov 2002 17:04:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyq29447 for ; Thu, 21 Nov 2002 17:04:54 GMT Received: from exchange.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50]) id QQnpyq29438 for ; Thu, 21 Nov 2002 17:04:54 GMT Received: from tropicnetworks.com ([10.1.5.206]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 21 Nov 2002 12:04:53 -0500 Message-ID: <3DDD1235.6834F38D@tropicnetworks.com> Date: Thu, 21 Nov 2002 12:04:53 -0500 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <3DDD0F65.7000507@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2002 17:04:53.0912 (UTC) FILETIME=[1C75D180:01C29180] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, This is an excellent point that must surely be a source of concern to many! It is certainly an issue that has been raised before on this mailing list. For various reasons, the authors did not wish to undertake the effort required to change the current drafts. Unnumbered links & graceful restart are not specific to gmpls and I never understood the rational for rolling them into the gmpls drafts. IMHO, it is better to remove the content in 2 separate drafts. However, if this is too much work for the authors at this point then approach of an "MPLS-applicable" section in the GMPLS drafts may be a suitable compromise. Best, Nabil Seddigh nseddigh@tropicnetworks.com David Charlap wrote: > > During the course of development, I have noticed that there are several > features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09) > that are applicable to non-generalized MPLS networks. > > Two immediately come to mind: > > 1: Support unnumbered links in explicit routes (as defined by > draft-ietf-mpls-rsvp-unnum-08) which requires as a prerequisite, support > for the IF_ID versions of the HOP and ERROR_SPEC objects (section 8) > > 2: Fault handling and restart capabilities (section 9) > > Right now, in order to provide thse features in an MPLS switch, one must > either use a proprietary solution, or must attempt a partial > implementation of GMPLS for the MPLS environment. > > What should be done about this? I don't think it's appropriate to > simply tell people "use GMPLS or do without the features". > > Perhaps a section on applicability to MPLS networks can be added to the > relevant GMPLS drafts? Or perhaps those sections of GMPLS that are also > applicable to MPLS should be broken off into separate drafts? > > Opinions? > > -- David From owner-mpls@UU.NET Thu Nov 21 12:33:27 2002 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 ESMTP id MAA11699 for ; Thu, 21 Nov 2002 12:33:27 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyo11325 for ; Thu, 21 Nov 2002 16:42:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpyo08320; Thu, 21 Nov 2002 16:41:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpyo21760 for mpls-outgoing; Thu, 21 Nov 2002 16:40:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpyo21753 for ; Thu, 21 Nov 2002 16:40:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpyo01152 for ; Thu, 21 Nov 2002 16:40:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyo02619 for ; Thu, 21 Nov 2002 16:40:04 GMT Received: from exchange.tropicnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50]) id QQnpyo02594 for ; Thu, 21 Nov 2002 16:40:03 GMT Received: from tropicnetworks.com ([10.1.5.206]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 21 Nov 2002 11:40:03 -0500 Message-ID: <3DDD0C63.482316DD@tropicnetworks.com> Date: Thu, 21 Nov 2002 11:40:03 -0500 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bin Zhou CC: "Francois Le Faucheur (flefauch)" , curtis@fictitious.org, Sasha Vainshtein , Vishal M , mpls@UU.NET, Shahram Davari Subject: Re: Reservation DiffServ MPLS (E-LSP & L-LSP) References: <003201c29124$d644f9d0$955b7a89@bwwil28> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2002 16:40:03.0409 (UTC) FILETIME=[A40D1C10:01C2917C] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bin, The following draft proposes a way to support signaling of bandwidth for multiple OAs in an LSP: http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-02.txt Nabil Seddigh nseddigh@tropicnetworks.com Bin Zhou wrote: > > Hello, > > I have a question about how to reserve bandwidth for a tunnel (mutiple OA) > with E-LSP or L-LSP using rsvp. > > As I understand it, we can reserve bandwidth for an LSP (single OA) with > E-LSP or L-LSP using rsvp. > > - In E-LSP case, we cann't support mutiple Sender_TSPEC (one TSPEC for one > OA, one RSPEC for one TSPEC, but only one TSPEC in the PATH message). > - In L-LSP case, we cann't support mutiple OA in one LSP (one LSP for one > OA). > > In another words, my question is how to signal bandwidth for mutiple OA in > one E-LSP, or wheather it is possible to have mutiple LSP in one tunnel. > > Thanks. > > Bin ZHou From owner-mpls@UU.NET Thu Nov 21 13:20:45 2002 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 ESMTP id NAA13951 for ; Thu, 21 Nov 2002 13:20:45 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyv24170 for ; Thu, 21 Nov 2002 18:23:20 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpyv21906; Thu, 21 Nov 2002 18:22:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpyv21496 for mpls-outgoing; Thu, 21 Nov 2002 18:21:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpyv21466 for ; Thu, 21 Nov 2002 18:21:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpyv04246 for ; Thu, 21 Nov 2002 18:21:14 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyv22894 for ; Thu, 21 Nov 2002 18:21:14 GMT Received: from zcars04e.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQnpyv22876 for ; Thu, 21 Nov 2002 18:21:13 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gALIKxw29698; Thu, 21 Nov 2002 13:21:00 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 13:20:59 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C06282A7A@zcard031.ca.nortel.com> From: "David Allan" To: "Thomas D. Nadeau" Cc: "'MPLS@UU.net'" Subject: RE: Load balancing draft Date: Thu, 21 Nov 2002 13:20:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2918A.BD84D54E" 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_01C2918A.BD84D54E Content-Type: text/plain; charset="iso-8859-1" I don't follow why specific knowledge of boxes is required. The general effect is to englarge the scope of fate sharing between the probe stream and associated traffic. This would be independent of specific knowledge. If box 'A' randomizes stuff between B, C and D, and the probe pathologically follows B then C and D are not tested. If B randomizes stuff to boxes E F and G, and probes sticks with the associated traffic then E F and G are tested. The only truly pathological case I can think of is when all load sharing points implement exactly the same algorithm and have exactly the same number of candidate NHLFEs and are only probed from a single point, otherwise incremental deployment of probe fate sharing pays dividends. rgds Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, November 21, 2002 11:49 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: 'MPLS@UU.net' > Subject: RE: Load balancing draft > > > > >Not entirely true, any point where there is useful > predictability reduces > >the number of > >possible faults that may only be caught by random process. > IMHO that is > >useful. > > In some cases it may help, but in others it does not which > IMHO is the point. It is only useful if you know which > boxes support which algorithms, which gets us back to > where we are today. > > --tom > > > > > >cheers > >Dave > > > > > -----Original Message----- > > > From: Thomas D. Nadeau > > [mailto:tnadeau@cisco.com] > > > Sent: Thursday, November 21, 2002 10:59 AM > > > To: Fedyk, Don [BL60:1A00:EXCH] > > > Cc: George Swallow; Fedyk, Don [BL60:1A00:EXCH]; Allan, David > > > [CAR:NS00:EXCH]; Alia Atlas; Shahram Davari; 'MPLS@UU.net' > > > Subject: Re: Load balancing draft > > > > > > > > > > > > >George > > > > > > > >Let me restate. You Said "All load balancing done in > > > prescribed manner." > > > >Which is certainly restrictive. The Draft for load balancing > > > says not to > > > >use certain fields. That is not the same. So I added different > > > >implementations for load balancing following the draft still > > > have freedoms > > > >and different vendors can choose different algorithms. > > > > > > Not really. If you want things to work the way the > > > draft aspires > > > them to, then everyone in the MPLS domain must use the same, > > > predictable load balancing algorithm. Going halfway doesn't work, > > > and is arguably no better than what we have today. > > > > > > --Tom > > > > > > > > > >Hope that makes it clear, > > > >Don . > > > >George Swallow wrote: > > > > > > > >>Don - > > > >> > > > >>This seems to a non-sequitor. I don't see how this comment > > > relates to > > > >>what I wrote below. Were you trying to answer some > other message? > > > >> > > > >>...George > > > >> > > > >> > > > >> > > > >>>George to be fair I heard Dave say that the load > > > balancing should not > > > >>>use certain fields which are part of the label stack. This > > > does not > > > >>>require that balancing be done in a prescribed manner, > > > freedom is still > > > >>>there. Instead load balancing should be correct with > > > respect to all of > > > >>>MPLS formats including reserved labels. > > > >>> > > > >>>Don > > > >>> > > > >>>George Swallow wrote: > > > >>> > > > >>> > > > >>> > > > >>>>>If you look at my post from rather late last night, I'd > > > question the > > > >>>>>lighter > > > >>>>>overhead assertion. This discussion is really orthogonal > > > to the probe > > > >>>>>frequency and is more concerned with the probe > > > quantity/quality to > > > >>>>>determine > > > >>>>>there is a problem. Goodness and scalability (and again > > > my favorite > > > >>>>>"bounded > > > >>>>>detection time") can be expressed as how authoritative a > > > test result is in > > > >>>>>proportion to the messages expended. Also the fewer > > > heuristics required to > > > >>>>>interpret the test results, the more reliable the > > > overall system is.... > > > >>>>> > > > >>>>> > > > >>>>My only point is that if your measurement is based on the > > > assumption > > > >>>>that all load-balancing is being done in a prescribed > > > manner, then the > > > >>>>quality of that measurement is very much dependent on the > > > certainty > > > >>>>that all of the nodes in the path are actually behaving > > > according to > > > >>>>that assumption. On node behaving differently could > > > reroute a large > > > >>>>portion (or all) of the probes. Thus the measurement > could be far > > > >>>> > > > >>>> > > > >>>>from the actual behavior. > > > >>> > > > >> > > > > >>================================================================== > > > >>George Swallow Cisco Systems > (978) 497-8143 > > > >> 250 Apollo Drive > > > >> Chelmsford, Ma 01824 > > > >> > > > >> > > > > > > > > > > Success is relative; the more success, the more > relatives. -Anonymous > > > > > > > > > > > Success is relative; the more success, the more relatives. -Anonymous > > > ------_=_NextPart_001_01C2918A.BD84D54E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Load balancing draft

I don't follow why specific knowledge of boxes is = required. The general effect is to englarge the scope of fate sharing = between the probe stream and associated traffic. This would be = independent of specific knowledge. If box 'A' randomizes stuff between = B, C and D, and the probe pathologically follows B then C and D are not = tested. If B randomizes stuff to boxes E F and G, and probes sticks = with the associated traffic then E F and G are tested.

The only truly pathological case I can think of is = when all load sharing points implement exactly the same algorithm and = have exactly the same number of candidate NHLFEs and are only probed = from a single point, otherwise incremental deployment of probe fate = sharing pays dividends.

rgds
Dave



> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Thursday, November 21, 2002 11:49 = AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'MPLS@UU.net'
> Subject: RE: Load balancing draft
>
>
>
> >Not entirely true, any point where there is = useful
> predictability reduces
> >the number of
> >possible faults that may only be caught by = random process.
> IMHO that is
> >useful.
>
>          In = some cases it may help, but in others it does not which
> IMHO is the point.  It is only useful if = you know which
> boxes support which algorithms, which gets us = back to
> where we are today.
>
>          = --tom
>
>
>
>
> >cheers
> >Dave
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau
> > [<mailto:tnadeau@cisco.com>mailto:tnadeau@cisco.com]
> > > Sent: Thursday, November 21, 2002 = 10:59 AM
> > > To: Fedyk, Don = [BL60:1A00:EXCH]
> > > Cc: George Swallow; Fedyk, Don = [BL60:1A00:EXCH]; Allan, David
> > > [CAR:NS00:EXCH]; Alia Atlas; Shahram = Davari; 'MPLS@UU.net'
> > > Subject: Re: Load balancing = draft
> > >
> > >
> > >
> > > >George
> > > >
> > > >Let me restate. You Said = "All load balancing done in
> > > prescribed manner."
> > > >Which is certainly restrictive. = The Draft for load balancing
> > > says  not to
> > > >use certain fields. That is not = the same. So I added different
> > > >implementations for load = balancing following the draft still
> > > have freedoms
> > > >and different vendors can choose = different algorithms.
> > >
> > = >          Not really. = If you want things to work the way the
> > > draft aspires
> > > them to, then everyone in the MPLS = domain must use the same,
> > > predictable load balancing = algorithm.  Going halfway doesn't work,
> > > and is arguably no better than what = we have today.
> > >
> > = >          --Tom
> > >
> > >
> > > >Hope that makes it clear,
> > > >Don .
> > > >George Swallow wrote:
> > > >
> > > >>Don -
> > > >>
> > > >>This seems to a = non-sequitor.  I don't see how this comment
> > > relates to
> > > >>what I wrote below.  = Were you trying to answer some
> other message?
> > > >>
> > > >>...George
> > > >>
> > > >>
> > > >>
> > > >>>George to be fair I heard = Dave say  that the load
> > > balancing should not
> > > >>>use certain fields which = are part of the label stack. This
> > > does not
> > > >>>require that balancing be = done in a prescribed manner,
> > > freedom is still
> > > >>>there. Instead load = balancing should be correct with
> > > respect to all of
> > > >>>MPLS formats  = including reserved labels.
> > > >>>
> > > >>>Don
> > > >>>
> > > >>>George Swallow = wrote:
> > > >>>
> > > >>>
> > > >>>
> > > >>>>>If you look at my = post from rather late last night, I'd
> > > question the
> > > >>>>>lighter
> > > >>>>>overhead = assertion. This discussion is really orthogonal
> > > to the probe
> > > >>>>>frequency and is = more concerned with the probe
> > > quantity/quality to
> > > >>>>>determine
> > > >>>>>there is a = problem. Goodness and scalability (and again
> > > my favorite
> > > = >>>>>"bounded
> > > >>>>>detection = time") can be expressed as how authoritative a
> > > test result is in
> > > >>>>>proportion to the = messages expended. Also the fewer
> > > heuristics required to
> > > >>>>>interpret the = test results, the more reliable the
> > > overall system is....
> > > >>>>>
> > > >>>>>
> > > >>>>My only point is that = if your measurement is based on the
> > > assumption
> > > >>>>that all = load-balancing is being done in a prescribed
> > > manner, then the
> > > >>>>quality of that = measurement is very much dependent on the
> > > certainty
> > > >>>>that all of the nodes = in the path are actually behaving
> > > according to
> > > >>>>that = assumption.  On node behaving differently could
> > > reroute a large
> > > >>>>portion (or all) of = the probes.  Thus the measurement
> could be far
> > > >>>>
> > > >>>>
> > > >>>>from the actual = behavior.
> > > >>>
> > > >>
> > >
> = >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > >>George = Swallow       Cisco = Systems           = ;      
> (978) 497-8143
> > > = >>          &nbs= p;          250 Apollo = Drive
> > > = >>          &nbs= p;          Chelmsford, Ma = 01824
> > > >>
> > > >>
> > > >
> > >
> > > Success is relative; the more = success, the more
> relatives. -Anonymous
> > >
> > >
> > >
>
> Success is relative; the more success, the more = relatives. -Anonymous
>
>
>

------_=_NextPart_001_01C2918A.BD84D54E-- From owner-mpls@UU.NET Thu Nov 21 14:00:33 2002 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 ESMTP id OAA15724 for ; Thu, 21 Nov 2002 14:00:32 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyu11798 for ; Thu, 21 Nov 2002 18:14:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpyu09913; Thu, 21 Nov 2002 18:13:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpyu18342 for mpls-outgoing; Thu, 21 Nov 2002 18:13:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpyu18307 for ; Thu, 21 Nov 2002 18:13:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpyu14138 for ; Thu, 21 Nov 2002 18:12:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyu15587 for ; Thu, 21 Nov 2002 18:12:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpyu15583 for ; Thu, 21 Nov 2002 18:12:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14050 for ; Thu, 21 Nov 2002 13:12:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gALIC6h07584 for mpls@uu.net; Thu, 21 Nov 2002 13:12:06 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpyu17355 for ; Thu, 21 Nov 2002 18:11:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpyu08816 for ; Thu, 21 Nov 2002 18:09:57 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyu12359 for ; Thu, 21 Nov 2002 18:09:57 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 QQnpyu12354 for ; Thu, 21 Nov 2002 18:09:57 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gALIAEKU026209; Thu, 21 Nov 2002 13:10:14 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-1-34.cisco.com [10.86.240.34]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD79873; Thu, 21 Nov 2002 13:09:49 -0500 (EST) Message-Id: <5.2.0.9.2.20021121111719.02a40990@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 21 Nov 2002 11:49:03 -0500 To: "David Allan" From: "Thomas D. Nadeau" Subject: RE: Load balancing draft Cc: "'MPLS@UU.net'" In-Reply-To: <9FBD322B7824D511B36900508BF93C9C062828BE@zcard031.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >Not entirely true, any point where there is useful predictability reduces >the number of >possible faults that may only be caught by random process. IMHO that is >useful. In some cases it may help, but in others it does not which IMHO is the point. It is only useful if you know which boxes support which algorithms, which gets us back to where we are today. --tom >cheers >Dave > > > -----Original Message----- > > From: Thomas D. Nadeau > [mailto:tnadeau@cisco.com] > > Sent: Thursday, November 21, 2002 10:59 AM > > To: Fedyk, Don [BL60:1A00:EXCH] > > Cc: George Swallow; Fedyk, Don [BL60:1A00:EXCH]; Allan, David > > [CAR:NS00:EXCH]; Alia Atlas; Shahram Davari; 'MPLS@UU.net' > > Subject: Re: Load balancing draft > > > > > > > > >George > > > > > >Let me restate. You Said "All load balancing done in > > prescribed manner." > > >Which is certainly restrictive. The Draft for load balancing > > says not to > > >use certain fields. That is not the same. So I added different > > >implementations for load balancing following the draft still > > have freedoms > > >and different vendors can choose different algorithms. > > > > Not really. If you want things to work the way the > > draft aspires > > them to, then everyone in the MPLS domain must use the same, > > predictable load balancing algorithm. Going halfway doesn't work, > > and is arguably no better than what we have today. > > > > --Tom > > > > > > >Hope that makes it clear, > > >Don . > > >George Swallow wrote: > > > > > >>Don - > > >> > > >>This seems to a non-sequitor. I don't see how this comment > > relates to > > >>what I wrote below. Were you trying to answer some other message? > > >> > > >>...George > > >> > > >> > > >> > > >>>George to be fair I heard Dave say that the load > > balancing should not > > >>>use certain fields which are part of the label stack. This > > does not > > >>>require that balancing be done in a prescribed manner, > > freedom is still > > >>>there. Instead load balancing should be correct with > > respect to all of > > >>>MPLS formats including reserved labels. > > >>> > > >>>Don > > >>> > > >>>George Swallow wrote: > > >>> > > >>> > > >>> > > >>>>>If you look at my post from rather late last night, I'd > > question the > > >>>>>lighter > > >>>>>overhead assertion. This discussion is really orthogonal > > to the probe > > >>>>>frequency and is more concerned with the probe > > quantity/quality to > > >>>>>determine > > >>>>>there is a problem. Goodness and scalability (and again > > my favorite > > >>>>>"bounded > > >>>>>detection time") can be expressed as how authoritative a > > test result is in > > >>>>>proportion to the messages expended. Also the fewer > > heuristics required to > > >>>>>interpret the test results, the more reliable the > > overall system is.... > > >>>>> > > >>>>> > > >>>>My only point is that if your measurement is based on the > > assumption > > >>>>that all load-balancing is being done in a prescribed > > manner, then the > > >>>>quality of that measurement is very much dependent on the > > certainty > > >>>>that all of the nodes in the path are actually behaving > > according to > > >>>>that assumption. On node behaving differently could > > reroute a large > > >>>>portion (or all) of the probes. Thus the measurement could be far > > >>>> > > >>>> > > >>>>from the actual behavior. > > >>> > > >> > > >>================================================================== > > >>George Swallow Cisco Systems (978) 497-8143 > > >> 250 Apollo Drive > > >> Chelmsford, Ma 01824 > > >> > > >> > > > > > > > Success is relative; the more success, the more relatives. -Anonymous > > > > > > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Thu Nov 21 14:54:18 2002 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 ESMTP id OAA17831 for ; Thu, 21 Nov 2002 14:54:18 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzb25423 for ; Thu, 21 Nov 2002 19:56:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpzb23524; Thu, 21 Nov 2002 19:55:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpzb05230 for mpls-outgoing; Thu, 21 Nov 2002 19:55:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpzb05217 for ; Thu, 21 Nov 2002 19:55:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpzb21208 for ; Thu, 21 Nov 2002 19:55:10 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzb21972 for ; Thu, 21 Nov 2002 19:55:10 GMT Received: from zcars04f.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnpzb21961 for ; Thu, 21 Nov 2002 19:55:09 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gALJsPF03648; Thu, 21 Nov 2002 14:54:26 -0500 (EST) Received: from zcard0ke.ca.nortel.com ([47.129.242.166]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLKCW38Z; Thu, 21 Nov 2002 14:54:26 -0500 Received: from nortelnetworks.com (artpt60g.us.nortel.com [47.140.53.210]) by zcard0ke.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK5DVK9; Thu, 21 Nov 2002 14:54:26 -0500 Message-ID: <3DDD3B1C.7050902@nortelnetworks.com> Date: Thu, 21 Nov 2002 14:59:24 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Don Fedyk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David Allan" , "Thomas D. Nadeau" CC: "Don Fedyk" , George Swallow , Alia Atlas , Shahram Davari , "'MPLS@UU.net'" Subject: Re: Load balancing draft References: <9FBD322B7824D511B36900508BF93C9C062828BE@zcard031.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom You can have MPLS Load balancing that : 1) Follows a predictable algorithm (for a reasonable duration) on each box based on some header fields. 2) Does not use fields that overlap with prescribed fields in the draft (Reserved label, Stack bit etc.). 3) Follows an identical, globally the same, (and hence predictable and repeatable) algorithm on each box. (1) is what we have today. (1) plus (2) are what we would recommend. (and even might be on some boxes today). (2) plus (3) is overkill (and impractical to deploy and is restrictive). I think we agree nobody is saying this one. Don Allan, David [CAR:NS00:EXCH] wrote: > Tom: > > Not entirely true, any point where there is useful predictability > reduces the number of possible faults that may only be caught by > random process. IMHO that is useful. > > cheers > Dave > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Thursday, November 21, 2002 10:59 AM > > To: Fedyk, Don [BL60:1A00:EXCH] > > Cc: George Swallow; Fedyk, Don [BL60:1A00:EXCH]; Allan, David > > [CAR:NS00:EXCH]; Alia Atlas; Shahram Davari; 'MPLS@UU.net' > > Subject: Re: Load balancing draft > > > > > > > > >George > > > > > >Let me restate. You Said "All load balancing done in > > prescribed manner." > > >Which is certainly restrictive. The Draft for load balancing > > says not to > > >use certain fields. That is not the same. So I added different > > >implementations for load balancing following the draft still > > have freedoms > > >and different vendors can choose different algorithms. > > > > Not really. If you want things to work the way the > > draft aspires > > them to, then everyone in the MPLS domain must use the same, > > predictable load balancing algorithm. Going halfway doesn't work, > > and is arguably no better than what we have today. > > > > --Tom > > > > > > >Hope that makes it clear, > > >Don . > From owner-mpls@UU.NET Thu Nov 21 15:27:13 2002 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 ESMTP id PAA18691 for ; Thu, 21 Nov 2002 15:27:13 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyn13597 for ; Thu, 21 Nov 2002 16:19:15 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpyn11898; Thu, 21 Nov 2002 16:18:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpyn13584 for mpls-outgoing; Thu, 21 Nov 2002 16:17:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpyn13554 for ; Thu, 21 Nov 2002 16:17:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpyn20327 for ; Thu, 21 Nov 2002 16:16:23 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyn10108 for ; Thu, 21 Nov 2002 16:16:23 GMT Received: from zcars04f.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnpyn10104 for ; Thu, 21 Nov 2002 16:16:22 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gALGFjF13808; Thu, 21 Nov 2002 11:15:45 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Nov 2002 11:15:46 -0500 Message-ID: <9FBD322B7824D511B36900508BF93C9C062828D6@zcard031.ca.nortel.com> From: "David Allan" To: "David Allan" , "Thomas D. Nadeau" , "Don Fedyk" Cc: George Swallow , "Don Fedyk" , Alia Atlas , Shahram Davari , "'MPLS@UU.net'" Subject: RESEND plain text: Load balancing draft Date: Thu, 21 Nov 2002 11:15:43 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-mpls@UU.NET Precedence: bulk Tom: Not entirely true, any point where there is useful predictability reduces the number of possible faults that may only be caught by random process. IMHO that is useful. cheers Dave > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Thursday, November 21, 2002 10:59 AM > > To: Fedyk, Don [BL60:1A00:EXCH] > > Cc: George Swallow; Fedyk, Don [BL60:1A00:EXCH]; Allan, David > > [CAR:NS00:EXCH]; Alia Atlas; Shahram Davari; 'MPLS@UU.net' > > Subject: Re: Load balancing draft > > > > > > > > >George > > > > > >Let me restate. You Said "All load balancing done in > > prescribed manner." > > >Which is certainly restrictive. The Draft for load balancing > > says not to > > >use certain fields. That is not the same. So I added different > > >implementations for load balancing following the draft still > > have freedoms > > >and different vendors can choose different algorithms. > > > > Not really. If you want things to work the way the > > draft aspires > > them to, then everyone in the MPLS domain must use the same, > > predictable load balancing algorithm. Going halfway doesn't work, > > and is arguably no better than what we have today. > > > > --Tom > > > > > > >Hope that makes it clear, > > >Don . > > >George Swallow wrote: > > > > > >>Don - > > >> > > >>This seems to a non-sequitor. I don't see how this comment > > relates to > > >>what I wrote below. Were you trying to answer some other message? > > >> > > >>...George > > >> > > >> > > >> > > >>>George to be fair I heard Dave say that the load > > balancing should not > > >>>use certain fields which are part of the label stack. This > > does not > > >>>require that balancing be done in a prescribed manner, > > freedom is still > > >>>there. Instead load balancing should be correct with > > respect to all of > > >>>MPLS formats including reserved labels. > > >>> > > >>>Don > > >>> > > >>>George Swallow wrote: > > >>> > > >>> > > >>> > > >>>>>If you look at my post from rather late last night, I'd > > question the > > >>>>>lighter > > >>>>>overhead assertion. This discussion is really orthogonal > > to the probe > > >>>>>frequency and is more concerned with the probe > > quantity/quality to > > >>>>>determine > > >>>>>there is a problem. Goodness and scalability (and again > > my favorite > > >>>>>"bounded > > >>>>>detection time") can be expressed as how authoritative a > > test result is in > > >>>>>proportion to the messages expended. Also the fewer > > heuristics required to > > >>>>>interpret the test results, the more reliable the > > overall system is.... > > >>>>> > > >>>>> > > >>>>My only point is that if your measurement is based on the > > assumption > > >>>>that all load-balancing is being done in a prescribed > > manner, then the > > >>>>quality of that measurement is very much dependent on the > > certainty > > >>>>that all of the nodes in the path are actually behaving > > according to > > >>>>that assumption. On node behaving differently could > > reroute a large > > >>>>portion (or all) of the probes. Thus the measurement > could be far > > >>>> > > >>>> > > >>>>from the actual behavior. > > >>> > > >> > > >>================================================================== > > >>George Swallow Cisco Systems (978) 497-8143 > > >> 250 Apollo Drive > > >> Chelmsford, Ma 01824 > > >> > > >> > > > > > > > Success is relative; the more success, the more relatives. > -Anonymous > > > > > > > From owner-mpls@UU.NET Thu Nov 21 16:01:56 2002 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 ESMTP id QAA20235 for ; Thu, 21 Nov 2002 16:01:55 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzg21462 for ; Thu, 21 Nov 2002 21:04:31 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpzg19770; Thu, 21 Nov 2002 21:03:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpzg20369 for mpls-outgoing; Thu, 21 Nov 2002 21:03:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpzg20296 for ; Thu, 21 Nov 2002 21:03:04 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 QQnpzg04062 for ; Thu, 21 Nov 2002 21:02:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzg22637 for ; Thu, 21 Nov 2002 21:02:07 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpzg22630 for ; Thu, 21 Nov 2002 21:02:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA29676 for ; Thu, 21 Nov 2002 16:02:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gALL26O19317 for mpls@uu.net; Thu, 21 Nov 2002 16:02:06 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpzg14118 for ; Thu, 21 Nov 2002 21:00:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpzf15561 for ; Thu, 21 Nov 2002 20:59:33 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzf16013 for ; Thu, 21 Nov 2002 20:59:33 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQnpzf16002 for ; Thu, 21 Nov 2002 20:59:32 GMT Received: (qmail 6571 invoked by uid 104); 21 Nov 2002 20:59:32 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4234. . Clean. Processed in 0.507297 secs); 21 Nov 2002 20:59:32 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 21 Nov 2002 20:59:31 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id gALKxVQ23992; Thu, 21 Nov 2002 12:59:31 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2656.59) id ; Thu, 21 Nov 2002 12:59:30 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB03AE1@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kireeti Kompella '" Cc: "''mpls@uu.net' '" Subject: RE: Requirements and solutions Date: Thu, 21 Nov 2002 12:59:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, Thanks for your clarifications. Perhaps I misundertood your comments in the meeting. I fully agree with your assertions below. -Shahram -----Original Message----- From: Kireeti Kompella To: Shahram Davari Cc: 'mpls@uu.net' Sent: 02-11-21 ?AEA 12:54 Subject: Re: Requirements and solutions Hi Shahram, On Tue, 19 Nov 2002, Shahram Davari wrote: > I am very much troubled by a comment raised in MPLS meeting, that > in the future the order of first requirements and then solution would > quite often change and that hopefully it would not require any modification > to the already approved solution. There was no such statement made -- at least, that was not my intent. However, since there is this confusion, let me clarify my statement. If a requirements doc is worked on prior to, or simultaneously with, a solutions document, then it makes absolute sense that the solutions doc wait on the reqts doc. In the case of LSP ping, however, a solution document has been around for quite a while, in fact, as a *WG* document and has matured quite a bit. This document clearly (a) is useful (good consensus on that); (b) meets at least some of the requirements; and (c) is extensible. As I said at the meeting, I fully support reviewing the solutions doc (once it's progressed) as part of the reqts doc, and adding extensions as deemed useful or necessary, deprecating TLVs if needed. But we do need to move forward; and real experience would nicely complement the requirements document. Now that I've explained, let me say that I was very troubled by your request: there are no reqts docs for (a) MPLS, (b) RSVP-TE, (c) LDP, etc. What if someone were to say, let's make them all informational while we write the reqts docs and evaluate them? I lie. I wasn't at all troubled :-) Your question really should be addressed to the ADs, or the IESG: should every solutions doc be accompanied by a reqts doc? If not (and I dearly hope not), perhaps when a solutions doc becomes a WG doc, the WG and/or chairs adjudicate whether a reqts doc is needed. That way, a late-breaking reqts doc doesn't stall an in-flight soln doc. Kireeti. From owner-mpls@UU.NET Thu Nov 21 17:32:13 2002 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 ESMTP id RAA24041 for ; Thu, 21 Nov 2002 17:32:12 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzm10068 for ; Thu, 21 Nov 2002 22:34:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpzm07487; Thu, 21 Nov 2002 22:33:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpzm05236 for mpls-outgoing; Thu, 21 Nov 2002 22:33:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpzm05231 for ; Thu, 21 Nov 2002 22:33:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpzm09017 for ; Thu, 21 Nov 2002 22:33:04 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzm24469 for ; Thu, 21 Nov 2002 22:33:03 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnpzm24461 for ; Thu, 21 Nov 2002 22:33:03 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gALMX2S48816; Thu, 21 Nov 2002 14:33:02 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gALMX2P46600; Thu, 21 Nov 2002 14:33:02 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 21 Nov 2002 14:33:02 -0800 (PST) From: Kireeti Kompella To: David Charlap cc: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS In-Reply-To: <3DDD0F65.7000507@marconi.com> Message-ID: <20021121142323.W46529-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi David, On Thu, 21 Nov 2002, David Charlap wrote: > During the course of development, I have noticed that there are several > features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09) > that are applicable to non-generalized MPLS networks. There are those who refer to generalized and non-generalized MPLS networks, those who talk about GMPLS and classical MPLS, etc. I would prefer to view this at two levels: o (A) generalized signaling and (B) non-generalized/classical signaling o (i) non-packet and (ii) packet LSPs (or MPLS networks) (A) can be used for both (i) and (ii) (B) can be used for (ii), but does rather poorly for (i) If an applicability statement is needed to say this, so be it. Kireeti. From owner-mpls@UU.NET Thu Nov 21 20:39:50 2002 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 ESMTP id UAA00630 for ; Thu, 21 Nov 2002 20:39:50 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyk14583 for ; Thu, 21 Nov 2002 15:31:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpyk13193; Thu, 21 Nov 2002 15:30:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpyk17076 for mpls-outgoing; Thu, 21 Nov 2002 15:30:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpyk17025 for ; Thu, 21 Nov 2002 15:30:05 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 QQnpyj25728 for ; Thu, 21 Nov 2002 15:29:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyj11997 for ; Thu, 21 Nov 2002 15:29:22 GMT Received: from zcars04f.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQnpyj11992 for ; Thu, 21 Nov 2002 15:29:22 GMT Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gALFSZF08628; Thu, 21 Nov 2002 10:28:35 -0500 (EST) Received: from zcard0ke.ca.nortel.com ([47.129.242.166]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XJ9A6T1H; Thu, 21 Nov 2002 10:28:36 -0500 Received: from nortelnetworks.com (artpt5qx.us.nortel.com [47.140.52.148]) by zcard0ke.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TLK5D49J; Thu, 21 Nov 2002 10:28:35 -0500 Message-ID: <3DDCFCCD.5050307@nortelnetworks.com> Date: Thu, 21 Nov 2002 10:33:33 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Don Fedyk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Swallow CC: "Don Fedyk" , "David Allan" , Alia Atlas , Shahram Davari , "'MPLS@UU.net'" Subject: Re: Load balancing draft References: <200211211432.JAA11060@bifocal.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George Let me restate. You Said "All load balancing done in prescribed manner." Which is certainly restrictive. The Draft for load balancing says not to use certain fields. That is not the same. So I added different implementations for load balancing following the draft still have freedoms and different vendors can choose different algorithms. Hope that makes it clear, Don . George Swallow wrote: >Don - > >This seems to a non-sequitor. I don't see how this comment relates to >what I wrote below. Were you trying to answer some other message? > >...George > > > >>George to be fair I heard Dave say that the load balancing should not >>use certain fields which are part of the label stack. This does not >>require that balancing be done in a prescribed manner, freedom is still >>there. Instead load balancing should be correct with respect to all of >>MPLS formats including reserved labels. >> >>Don >> >>George Swallow wrote: >> >> >> >>>>If you look at my post from rather late last night, I'd question the lighter >>>>overhead assertion. This discussion is really orthogonal to the probe >>>>frequency and is more concerned with the probe quantity/quality to determine >>>>there is a problem. Goodness and scalability (and again my favorite "bounded >>>>detection time") can be expressed as how authoritative a test result is in >>>>proportion to the messages expended. Also the fewer heuristics required to >>>>interpret the test results, the more reliable the overall system is.... >>>> >>>> >>>> >>>> >>>My only point is that if your measurement is based on the assumption >>>that all load-balancing is being done in a prescribed manner, then the >>>quality of that measurement is very much dependent on the certainty >>>that all of the nodes in the path are actually behaving according to >>>that assumption. On node behaving differently could reroute a large >>>portion (or all) of the probes. Thus the measurement could be far >>> >>> >>>from the actual behavior. >> >> > >================================================================== >George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > From owner-mpls@UU.NET Thu Nov 21 20:57:54 2002 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 ESMTP id UAA01354 for ; Thu, 21 Nov 2002 20:57:53 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzj27505 for ; Thu, 21 Nov 2002 21:54:44 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpzj25778; Thu, 21 Nov 2002 21:53:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpzj13880 for mpls-outgoing; Thu, 21 Nov 2002 21:53:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpzj13865 for ; Thu, 21 Nov 2002 21:53:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpzj03562 for ; Thu, 21 Nov 2002 21:52:56 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzj27560 for ; Thu, 21 Nov 2002 21:52:55 GMT Received: from prattle.redback.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prattle.redback.com [155.53.12.9]) id QQnpzj27554 for ; Thu, 21 Nov 2002 21:52:55 GMT Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by prattle.redback.com (Postfix) with ESMTP id D5D474F41BD; Thu, 21 Nov 2002 13:52:50 -0800 (PST) Received: (from rahul@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id NAA03452; Thu, 21 Nov 2002 13:52:50 -0800 (PST) Date: Thu, 21 Nov 2002 13:52:50 -0800 From: Rahul Aggarwal To: Adrian Farrel Cc: mpls@UU.NET, Rohit Dube Subject: Re: bi-directional LSPs Message-ID: <20021121215250.GA3396@malt.redback.com> References: <200211192125.QAA10835@bigbird.xebeo.com> <005b01c290f3$e02ca4b0$fe14588a@movaz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005b01c290f3$e02ca4b0$fe14588a@movaz.com> User-Agent: Mutt/1.4i Sender: owner-mpls@UU.NET Precedence: bulk Comments inline: On Wed, Nov 20, 2002 at 07:21:01PM -0500, Adrian Farrel wrote: > > At the MPLS WG meeting, the question came up that GMPLS already > > supports bi-directional LSPs. As Rahul pointed out, this only > > works for generalized labels and not for "classical" labels. > > Perhaps Rahul can comment, but I don't think that is what he meant at all. > > What I heard him say (and what is factually correct) is that GMPLS only works > with the Generalized Label Object. These objects can perfectly well contain > "normal" 23 bit MPLS labels. The Generalized Label Request can ask for such > labels. Yes, that is what I meant. > > His comment was that since some change is needed in the implementation to > support bidirectional labels it is of no consequence which change is made and so > you might as well move the Label Object and Label Request Object to be > Generalized. > > > Here is some further clarification on the topic. That is right again. Thanks for clarifying it. > > > > For classical mpls networks there are two ways of supporting > > bidirectional lsps. One method is to make the UPSTREAM_LABEL > > objects applicable to classic MPLS labels. > > They are already since the upstream label contains a generalized label and > generalized labels can contain MPLS labels. > > > The other is to > > exchange "generalized" labels between nodes that want to > > support bidirectional LSPs while continuing with classical > > labels for uni-directional ones. The draft presented uses > > the former approach. > > > > While both approaches are valid, for nodes that run classical > > MPLS already and which need to support uni-directional as well > > as bi-directional LSPs, this seems to be the easier approach as > > the operator and the implementor need to deal with just one > > type of label. > > > I think at this point you really need to differentiate between label objects and > the labels they carry. > > > > The -01 version of the draft proposes an UPSTREAM_FLOWSPEC > > object which allows for asymmetric bandwidth reservation > > by carrying the required information for the reverse path > > in the PATH message. The updated draft is available at > > > http://members.tripod.com/~rohit_dube/papers/draft-dube-bidirectional-lsp-01.txt > > Asymmetric bidirectional LSPs are a different matter altogether. > If there is a requirement for this, it should surely be moved to ccamp. > I would agree with that. > > The updated version of the draft should appear on ietf's > > web-site when the draft queue starts getting processed again. > > I suggest you notify the ccmap WG of the existence of this draft and the > discussion on the MPLS list. > > Adrian > > From owner-mpls@UU.NET Thu Nov 21 21:13:45 2002 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 ESMTP id VAA01877 for ; Thu, 21 Nov 2002 21:12:40 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqab17011 for ; Fri, 22 Nov 2002 02:15:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqaa15174; Fri, 22 Nov 2002 02:14:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqaa04792 for mpls-outgoing; Fri, 22 Nov 2002 02:14:03 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqaa04787 for ; Fri, 22 Nov 2002 02:13:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqaa19838 for ; Fri, 22 Nov 2002 02:12:29 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqaa29638 for ; Fri, 22 Nov 2002 02:12:29 GMT Received: from blooper.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.utfors.se [195.58.103.125]) id QQnqaa29621 for ; Fri, 22 Nov 2002 02:12:28 GMT Received: from utfors.se ([195.58.105.90]) by blooper.utfors.se (8.12.6/8.12.6) with ESMTP id gAM2CMgd006001; Fri, 22 Nov 2002 03:12:22 +0100 (MET) Message-ID: <3DDD9285.4060601@utfors.se> Date: Thu, 21 Nov 2002 21:12:21 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Charlap CC: Kireeti Kompella , IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <20021121142323.W46529-100000@kummer.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, let me see if I understand this correctly. I think that the general problem is -given the definitions by Kireeti below - that: - something specified in a ccamp spec makes perfect sense for something in vanilla ;) mpls (using signaling type B) - the ccamp spec specifies more than what is needed (makes sense) for the vanilla mpls that has to be implemented to comply to the with the spec Then the issue is, how do we handle this? Is this the background for the question? If so, I can see several ways of doing things - split documents, one mpls and another ccamp one, where the ccamp include the mpls doc (by reference) - do it by applicability statements, from the mpls side saying "what is specified in the ccamp if doc is a great idea, but if you apply it to packet mpls you don need to implement ..." - include info in the ccamp doc on what is needed in packet mpls /Loa Kireeti Kompella wrote: > Hi David, > > On Thu, 21 Nov 2002, David Charlap wrote: > > >>During the course of development, I have noticed that there are several >>features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09) >>that are applicable to non-generalized MPLS networks. > > > There are those who refer to generalized and non-generalized MPLS > networks, those who talk about GMPLS and classical MPLS, etc. > > I would prefer to view this at two levels: > o (A) generalized signaling and (B) non-generalized/classical signaling > o (i) non-packet and (ii) packet LSPs (or MPLS networks) > > (A) can be used for both (i) and (ii) > (B) can be used for (ii), but does rather poorly for (i) > > If an applicability statement is needed to say this, so be it. > > Kireeti. > -- /Loa Loa Andersson Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Mobile +46 70 848 5038 Email loa.andersson@utfors.se From owner-mpls@UU.NET Thu Nov 21 21:54:04 2002 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 ESMTP id VAA03197 for ; Thu, 21 Nov 2002 21:54:04 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpym25498; Thu, 21 Nov 2002 16:01:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpym28915 for mpls-outgoing; Thu, 21 Nov 2002 16:01:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpym28814 for ; Thu, 21 Nov 2002 16:01:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpym10992 for ; Thu, 21 Nov 2002 16:01:07 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpym25127 for ; Thu, 21 Nov 2002 16:01:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnpym25121 for ; Thu, 21 Nov 2002 16:01:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02653 for ; Thu, 21 Nov 2002 11:01:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gALG15p28255 for mpls@uu.net; Thu, 21 Nov 2002 11:01:05 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpym24594 for ; Thu, 21 Nov 2002 16:00:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnpyl07299 for ; Thu, 21 Nov 2002 15:59:45 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyl23999 for ; Thu, 21 Nov 2002 15:59:45 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 QQnpyl23995 for ; Thu, 21 Nov 2002 15:59:45 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gALFx8k8009434; Thu, 21 Nov 2002 10:59:10 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-42.cisco.com [10.86.242.42]) by bucket.cisco.com (Mirapoint) with ESMTP id ACD77110; Thu, 21 Nov 2002 10:58:43 -0500 (EST) Message-Id: <5.2.0.9.2.20021121105641.02a17860@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 21 Nov 2002 10:58:40 -0500 To: Don Fedyk From: "Thomas D. Nadeau" Subject: Re: Load balancing draft Cc: George Swallow , "Don Fedyk" , "David Allan" , Alia Atlas , Shahram Davari , "'MPLS@UU.net'" In-Reply-To: <3DDCFCCD.5050307@nortelnetworks.com> References: <200211211432.JAA11060@bifocal.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >George > >Let me restate. You Said "All load balancing done in prescribed manner." >Which is certainly restrictive. The Draft for load balancing says not to >use certain fields. That is not the same. So I added different >implementations for load balancing following the draft still have freedoms >and different vendors can choose different algorithms. Not really. If you want things to work the way the draft aspires them to, then everyone in the MPLS domain must use the same, predictable load balancing algorithm. Going halfway doesn't work, and is arguably no better than what we have today. --Tom >Hope that makes it clear, >Don . >George Swallow wrote: > >>Don - >> >>This seems to a non-sequitor. I don't see how this comment relates to >>what I wrote below. Were you trying to answer some other message? >> >>...George >> >> >> >>>George to be fair I heard Dave say that the load balancing should not >>>use certain fields which are part of the label stack. This does not >>>require that balancing be done in a prescribed manner, freedom is still >>>there. Instead load balancing should be correct with respect to all of >>>MPLS formats including reserved labels. >>> >>>Don >>> >>>George Swallow wrote: >>> >>> >>> >>>>>If you look at my post from rather late last night, I'd question the >>>>>lighter >>>>>overhead assertion. This discussion is really orthogonal to the probe >>>>>frequency and is more concerned with the probe quantity/quality to >>>>>determine >>>>>there is a problem. Goodness and scalability (and again my favorite >>>>>"bounded >>>>>detection time") can be expressed as how authoritative a test result is in >>>>>proportion to the messages expended. Also the fewer heuristics required to >>>>>interpret the test results, the more reliable the overall system is.... >>>>> >>>>> >>>>My only point is that if your measurement is based on the assumption >>>>that all load-balancing is being done in a prescribed manner, then the >>>>quality of that measurement is very much dependent on the certainty >>>>that all of the nodes in the path are actually behaving according to >>>>that assumption. On node behaving differently could reroute a large >>>>portion (or all) of the probes. Thus the measurement could be far >>>> >>>> >>>>from the actual behavior. >>> >> >>================================================================== >>George Swallow Cisco Systems (978) 497-8143 >> 250 Apollo Drive >> Chelmsford, Ma 01824 >> >> > Success is relative; the more success, the more relatives. -Anonymous From owner-mpls@UU.NET Thu Nov 21 22:56:01 2002 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 ESMTP id WAA04590 for ; Thu, 21 Nov 2002 22:56:01 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqah08929 for ; Fri, 22 Nov 2002 03:58:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqah06205; Fri, 22 Nov 2002 03:57:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqah01650 for mpls-outgoing; Fri, 22 Nov 2002 03:57:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqah01640 for ; Fri, 22 Nov 2002 03:56:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqah16256 for ; Fri, 22 Nov 2002 03:56:03 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqah05333 for ; Fri, 22 Nov 2002 03:56:02 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnqah05321 for ; Fri, 22 Nov 2002 03:56:02 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gAM3u1S73827; Thu, 21 Nov 2002 19:56:01 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gAM3u1147595; Thu, 21 Nov 2002 19:56:01 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 21 Nov 2002 19:56:01 -0800 (PST) From: Kireeti Kompella To: Loa Andersson cc: David Charlap , IETF MPLS List Subject: Re: GMPLS features applicable to MPLS In-Reply-To: <3DDD9285.4060601@utfors.se> Message-ID: <20021121191221.B47490-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Loa, On Thu, 21 Nov 2002, Loa Andersson wrote: > let me see if I understand this correctly. > > I think that the general problem is -given the definitions by Kireeti > below - that: > > - something specified in a ccamp spec makes perfect sense > for something in vanilla ;) mpls (using signaling type B) > > - the ccamp spec specifies more than what is needed (makes sense) for > the vanilla mpls that has to be implemented to comply to the with the > spec and sometimes less than what is needed. CCAMP's charter is to produce specs that apply across a multitude of technologies, *one* of them being MPLS. > Then the issue is, how do we handle this? > > Is this the background for the question? If so, I can see several > ways of doing things > > - split documents, one mpls and another ccamp one, where the ccamp > include the mpls doc (by reference) Excellent idea: CCAMP produces the COMMON document, MPLS refines it to tailor it to MPLS. Actually, this was the idea all along. Important change: the mpls doc cites the ccamp doc, not vice versa. Case in point: CCAMP produces a spec for (symmetric bw) bidirectional LSPs. You *can* signal a bidir LSP in MPLS with that. However, you can't do MPLS LSPs with fast reroute (as George pointed out). That's where the second *MPLS* document (check charter first!) that builds on the CCAMP doc comes in. However, a document that does bidir LSPs *another* way helps no one. > - do it by applicability statements, from the mpls side saying "what is > specified in the ccamp if doc is a great idea, but if you apply it to > packet mpls you don need to implement ..." That would be fine, if no protocol changes/additions are needed. > - include info in the ccamp doc on what is needed in packet mpls We've spent a lot of time removing technology-specific work from the COMMON specs. I don't think we want to go this way. Kireeti. From owner-mpls@UU.NET Fri Nov 22 02:18:53 2002 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 ESMTP id CAA18663 for ; Fri, 22 Nov 2002 02:17:48 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpze18243 for ; Thu, 21 Nov 2002 20:32:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpze16676; Thu, 21 Nov 2002 20:32:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpze02416 for mpls-outgoing; Thu, 21 Nov 2002 20:31:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnpze02397 for ; Thu, 21 Nov 2002 20:31:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnpze02538 for ; Thu, 21 Nov 2002 20:30:42 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpze29617 for ; Thu, 21 Nov 2002 20:30:42 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 QQnpze29607 for ; Thu, 21 Nov 2002 20:30:42 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 PAA02608 for ; Thu, 21 Nov 2002 15:30:39 -0500 (EST) 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 PAA10252 for ; Thu, 21 Nov 2002 15:30:40 -0500 (EST) Message-ID: <3DDD427E.5050409@marconi.com> Date: Thu, 21 Nov 2002 15:30:54 -0500 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <3DDD0F65.7000507@marconi.com> <3DDD1235.6834F38D@tropicnetworks.com> <3DDD64E3.4E20FEC1@caspiannetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jeff pickering wrote: > Also note that there is a history of this since the hellos in rfc3209 are > not specific to rsvp-te either. I remember that discussion. But it's not quite the same. RSVP-Hello was originally introduced in the Refresh Reduction draft. The working group elected to get rid of it, on the grounds that Hellos change the fundamental nature of RSVP from soft-state to hard-state. It was adopted MPLS working group (and incorporated into RSVP-TE) because the RSVP working group had rejected it. Without rehashing the merits of that decision, I'd just like to point out that this situation is a bit different. A parallel situation would be if unnumbered links and restart capability were proposed as a part of RSVP-TE, and were then rejected by the MPLS working group, and then adopted by CCAMP for use in generalized-RSVP-TE. But to my knowledge, it didn't go this way. As far as I know, these extensions were originally created as a part of the generalized-RSVP-TE work. And that's fine. Any group that develops something useful should be able to do so. But now that these features are designed, and they are seen as desirable in the non-generalized architecture, the question is how (if at all) they should be ported to that architecture. -- David From owner-mpls@UU.NET Fri Nov 22 02:27:10 2002 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 ESMTP id CAA18783 for ; Fri, 22 Nov 2002 02:27:09 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnpzf10586; Thu, 21 Nov 2002 20:54:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnpzf09583 for mpls-outgoing; Thu, 21 Nov 2002 20:54:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpzf09558 for ; Thu, 21 Nov 2002 20:54: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 QQnpzf20432 for ; Thu, 21 Nov 2002 20:54:19 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzf10182 for ; Thu, 21 Nov 2002 20:54:19 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnpzf10172 for ; Thu, 21 Nov 2002 20:54:18 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gALKsIS38321; Thu, 21 Nov 2002 12:54:18 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gALKsIC46231; Thu, 21 Nov 2002 12:54:18 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 21 Nov 2002 12:54:18 -0800 (PST) From: Kireeti Kompella To: Shahram Davari cc: "'mpls@uu.net'" Subject: Re: Requirements and solutions In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB03ABF@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: <20021121124859.T46207-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Shahram, On Tue, 19 Nov 2002, Shahram Davari wrote: > I am very much troubled by a comment raised in MPLS meeting, that > in the future the order of first requirements and then solution would > quite often change and that hopefully it would not require any modification > to the already approved solution. There was no such statement made -- at least, that was not my intent. However, since there is this confusion, let me clarify my statement. If a requirements doc is worked on prior to, or simultaneously with, a solutions document, then it makes absolute sense that the solutions doc wait on the reqts doc. In the case of LSP ping, however, a solution document has been around for quite a while, in fact, as a *WG* document and has matured quite a bit. This document clearly (a) is useful (good consensus on that); (b) meets at least some of the requirements; and (c) is extensible. As I said at the meeting, I fully support reviewing the solutions doc (once it's progressed) as part of the reqts doc, and adding extensions as deemed useful or necessary, deprecating TLVs if needed. But we do need to move forward; and real experience would nicely complement the requirements document. Now that I've explained, let me say that I was very troubled by your request: there are no reqts docs for (a) MPLS, (b) RSVP-TE, (c) LDP, etc. What if someone were to say, let's make them all informational while we write the reqts docs and evaluate them? I lie. I wasn't at all troubled :-) Your question really should be addressed to the ADs, or the IESG: should every solutions doc be accompanied by a reqts doc? If not (and I dearly hope not), perhaps when a solutions doc becomes a WG doc, the WG and/or chairs adjudicate whether a reqts doc is needed. That way, a late-breaking reqts doc doesn't stall an in-flight soln doc. Kireeti. From owner-mpls@UU.NET Fri Nov 22 10:02:01 2002 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 ESMTP id KAA26498 for ; Fri, 22 Nov 2002 10:02:01 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqca22186 for ; Fri, 22 Nov 2002 15:04:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqca19912; Fri, 22 Nov 2002 15:03:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqca03636 for mpls-outgoing; Fri, 22 Nov 2002 15:03:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqca03615 for ; Fri, 22 Nov 2002 15:02:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqca17358 for ; Fri, 22 Nov 2002 15:02:14 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqca18700 for ; Fri, 22 Nov 2002 15:02:13 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 QQnqca18690 for ; Fri, 22 Nov 2002 15:02:13 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 KAA01092 for ; Fri, 22 Nov 2002 10:02:11 -0500 (EST) 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 KAA02282 for ; Fri, 22 Nov 2002 10:02:12 -0500 (EST) Message-ID: <3DDE4704.1050800@marconi.com> Date: Fri, 22 Nov 2002 10:02:28 -0500 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <20021121142323.W46529-100000@kummer.juniper.net> <3DDD9285.4060601@utfors.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Loa Andersson wrote: > > let me see if I understand this correctly. > > I think that the general problem is -given the definitions by Kireeti > below - that: > > - something specified in a ccamp spec makes perfect sense > for something in vanilla ;) mpls (using signaling type B) > > - the ccamp spec specifies more than what is needed (makes sense) for > the vanilla mpls that has to be implemented to comply to the with the > spec This was my original question. > Then the issue is, how do we handle this? > > Is this the background for the question? If so, I can see several > ways of doing things > > - split documents, one mpls and another ccamp one, where the ccamp > include the mpls doc (by reference) > - do it by applicability statements, from the mpls side saying "what is > specified in the ccamp if doc is a great idea, but if you apply it to > packet mpls you don need to implement ..." > - include info in the ccamp doc on what is needed in packet mpls Any one of these would be fine for me. My main concern here is that MPLS vendors will start implementing those features, and some may ignore the GMPLS approach, thinking that those drafts are not applicable to non-generalized MPLS. This may lead to interop issues. Of course, vendors often ignore drafts anyway, but at least this way they'll know that there is something out there that they can choose to implement or ignore. And those that need to pull pieces of GMPLS into their MPLS implementations will know how much must be pulled in to properly support the features under development. -- David From owner-mpls@UU.NET Fri Nov 22 17:30:09 2002 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 ESMTP id RAA05854 for ; Fri, 22 Nov 2002 17:30:09 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqcr08587 for ; Fri, 22 Nov 2002 19:25:50 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqcr00633; Fri, 22 Nov 2002 19:22:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqcr06395 for mpls-outgoing; Fri, 22 Nov 2002 19:21:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqcr06390 for ; Fri, 22 Nov 2002 19:21:35 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 QQnqcr05731 for ; Fri, 22 Nov 2002 19:21:29 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqcr00187 for ; Fri, 22 Nov 2002 19:21:29 GMT Received: from lxmail.xebeo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.xebeo.com [204.192.44.242]) id QQnqcr00181 for ; Fri, 22 Nov 2002 19:21:29 GMT Received: (qmail 17537 invoked from network); 22 Nov 2002 19:21:29 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 22 Nov 2002 19:21:29 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id OAA14676; Fri, 22 Nov 2002 14:21:28 -0500 Message-Id: <200211221921.OAA14676@bigbird.xebeo.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: David Charlap cc: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS In-Reply-To: Message from David Charlap of "Fri, 22 Nov 2002 10:02:28 EST." <3DDE4704.1050800@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Nov 2002 14:21:27 -0500 From: Rohit Dube Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 22 Nov 2002 10:02:28 -0500 David Charlap writes: [snip] =>Any one of these would be fine for me. My main concern here is that =>MPLS vendors will start implementing those features, and some may ignore =>the GMPLS approach, thinking that those drafts are not applicable to =>non-generalized MPLS. This may lead to interop issues. => =>Of course, vendors often ignore drafts anyway, but at least this way =>they'll know that there is something out there that they can choose to =>implement or ignore. And those that need to pull pieces of GMPLS into =>their MPLS implementations will know how much must be pulled in to =>properly support the features under development. Excellent points David. And in fact this is what happened with the "bidirectional lsps for classical mpls" draft that I presented at the IETF. A quick solution is needed for this class of problems! Regards, --rohit. From owner-mpls@UU.NET Fri Nov 22 20:25:23 2002 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 ESMTP id UAA08668 for ; Fri, 22 Nov 2002 20:24:34 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqag17230 for ; Fri, 22 Nov 2002 03:31:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqag15517; Fri, 22 Nov 2002 03:30:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqag29604 for mpls-outgoing; Fri, 22 Nov 2002 03:30:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqag29596 for ; Fri, 22 Nov 2002 03:30: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 QQnqaf01692 for ; Fri, 22 Nov 2002 03:29:38 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqaf19984 for ; Fri, 22 Nov 2002 03:29:38 GMT Received: from hs22.order-vault.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hs22.order-vault.net [65.18.133.138]) id QQnqaf19978 for ; Fri, 22 Nov 2002 03:29:38 GMT Received: from LB-LAPTOP.labn.net (labn.net [65.18.134.4]) (authenticated (0 bits)) by hs22.order-vault.net (8.11.6/8.11.6) with ESMTP id gAM3TVF19323; Thu, 21 Nov 2002 22:29:31 -0500 Message-Id: <4.3.2.7.2.20021121222400.02555e98@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Nov 2002 22:29:10 -0500 To: Loa Andersson From: Lou Berger Subject: Re: GMPLS features applicable to MPLS Cc: David Charlap , Kireeti Kompella , IETF MPLS List In-Reply-To: <3DDD9285.4060601@utfors.se> References: <20021121142323.W46529-100000@kummer.juniper.net> 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 UAA08668 GMPLS applies to packets as well. It seems that all that is need here is an explanation (app note) of how to use gmpls with packets. This should be a short document... (it just takes using the new label request and label object...) Lou At 09:12 PM 11/21/2002, Loa Andersson wrote: >All, > >let me see if I understand this correctly. > >I think that the general problem is -given the definitions by Kireeti >below - that: > >- something specified in a ccamp spec makes perfect sense > for something in vanilla ;) mpls (using signaling type B) > >- the ccamp spec specifies more than what is needed (makes sense) for > the vanilla mpls that has to be implemented to comply to the with the > spec > >Then the issue is, how do we handle this? > >Is this the background for the question? If so, I can see several >ways of doing things > >- split documents, one mpls and another ccamp one, where the ccamp > include the mpls doc (by reference) >- do it by applicability statements, from the mpls side saying "what is > specified in the ccamp if doc is a great idea, but if you apply it to > packet mpls you don need to implement ..." >- include info in the ccamp doc on what is needed in packet mpls > >/Loa > >Kireeti Kompella wrote: >>Hi David, >>On Thu, 21 Nov 2002, David Charlap wrote: >> >>>During the course of development, I have noticed that there are several >>>features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09) >>>that are applicable to non-generalized MPLS networks. >> >>There are those who refer to generalized and non-generalized MPLS >>networks, those who talk about GMPLS and classical MPLS, etc. >>I would prefer to view this at two levels: >> o (A) generalized signaling and (B) non-generalized/classical signaling >> o (i) non-packet and (ii) packet LSPs (or MPLS networks) >>(A) can be used for both (i) and (ii) >>(B) can be used for (ii), but does rather poorly for (i) >>If an applicability statement is needed to say this, so be it. >>Kireeti. > > >-- > /Loa > > > Loa Andersson > Utfors AB > Råsundavägen 12 > Box 525, 169 29 Solna > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > From owner-mpls@UU.NET Sat Nov 23 22:08:04 2002 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 ESMTP id WAA10604 for ; Sat, 23 Nov 2002 22:06:59 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqhn12169; Sun, 24 Nov 2002 02:54:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqhn24131 for mpls-outgoing; Sun, 24 Nov 2002 02:52:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqhn24110 for ; Sun, 24 Nov 2002 02:52:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqhn19965 for ; Sun, 24 Nov 2002 02:52:26 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqhn09741 for ; Sun, 24 Nov 2002 02:52:26 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqhn09719 for ; Sun, 24 Nov 2002 02:52:25 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA09199 for ; Sat, 23 Nov 2002 21:52:24 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAO2qOp20735 for mpls@uu.net; Sat, 23 Nov 2002 21:52:24 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnpzb05040 for ; Thu, 21 Nov 2002 19:53: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 QQnpzb19227 for ; Thu, 21 Nov 2002 19:52:44 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpzb27657 for ; Thu, 21 Nov 2002 19:52:44 GMT Received: from cmail.packetcom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mr200a.caspiannetworks.com [63.108.173.139]) id QQnpzb27649 for ; Thu, 21 Nov 2002 19:52:43 GMT Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint Messaging Server MOS 3.2.0-GA) with ESMTP id ABM10264; Thu, 21 Nov 2002 11:52:33 -0800 (PST) Message-ID: <3DDD64E3.4E20FEC1@caspiannetworks.com> Date: Thu, 21 Nov 2002 14:57:39 -0800 From: jeff pickering X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nabil Seddigh CC: David Charlap , IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <3DDD0F65.7000507@marconi.com> <3DDD1235.6834F38D@tropicnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Also note that there is a history of this since the hellos in rfc3209 are not specific to rsvp-te either. Jeff Nabil Seddigh wrote: > David, > > This is an excellent point that must surely be a source of concern > to many! It is certainly an issue that has been raised before on > this mailing list. > > For various reasons, the authors did not wish to undertake > the effort required to change the current drafts. > > Unnumbered links & graceful restart are not specific to gmpls > and I never understood the rational for rolling them into > the gmpls drafts. IMHO, it is better to remove the content in > 2 separate drafts. > > However, if this is too much work for the authors at this > point then approach of an "MPLS-applicable" section in the > GMPLS drafts may be a suitable compromise. > > Best, > Nabil Seddigh > nseddigh@tropicnetworks.com > > David Charlap wrote: > > > > During the course of development, I have noticed that there are several > > features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09) > > that are applicable to non-generalized MPLS networks. > > > > Two immediately come to mind: > > > > 1: Support unnumbered links in explicit routes (as defined by > > draft-ietf-mpls-rsvp-unnum-08) which requires as a prerequisite, support > > for the IF_ID versions of the HOP and ERROR_SPEC objects (section 8) > > > > 2: Fault handling and restart capabilities (section 9) > > > > Right now, in order to provide thse features in an MPLS switch, one must > > either use a proprietary solution, or must attempt a partial > > implementation of GMPLS for the MPLS environment. > > > > What should be done about this? I don't think it's appropriate to > > simply tell people "use GMPLS or do without the features". > > > > Perhaps a section on applicability to MPLS networks can be added to the > > relevant GMPLS drafts? Or perhaps those sections of GMPLS that are also > > applicable to MPLS should be broken off into separate drafts? > > > > Opinions? > > > > -- David From owner-mpls@UU.NET Sun Nov 24 00:00:39 2002 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 ESMTP id AAA12167 for ; Sun, 24 Nov 2002 00:00:38 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqhn11901 for ; Sun, 24 Nov 2002 02:53:56 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqhn10069; Sun, 24 Nov 2002 02:52:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqhn24102 for mpls-outgoing; Sun, 24 Nov 2002 02:52:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqhn24094 for ; Sun, 24 Nov 2002 02:52:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqhn18668 for ; Sun, 24 Nov 2002 02:51:52 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqhn09306 for ; Sun, 24 Nov 2002 02:51:52 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqhn09295 for ; Sun, 24 Nov 2002 02:51:51 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA09174 for ; Sat, 23 Nov 2002 21:51:51 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAO2ppc20691 for mpls@uu.net; Sat, 23 Nov 2002 21:51:51 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnpyg17934 for ; Thu, 21 Nov 2002 14:44: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 QQnpyg25926 for ; Thu, 21 Nov 2002 14:44:03 GMT From: Roberto.Guglielmi@alcatel.it Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpyg09170 for ; Thu, 21 Nov 2002 14:44:03 GMT Received: from tlvsca.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.245]) id QQnpyg09144 for ; Thu, 21 Nov 2002 14:44:02 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsca.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gALEhprt003670 for ; Thu, 21 Nov 2002 15:43:51 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002112115460261:3331 ; Thu, 21 Nov 2002 15:46:02 +0100 Message-ID: <3DDCEF89.1080708@alcatel.it> Date: Thu, 21 Nov 2002 15:36:57 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@UU.NET Subject: LSP hierarchy riflected in MIBs X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/21/2002 15:46:02, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/21/2002 15:46:04, Serialize complete at 11/21/2002 15:46:04 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello everyone, the draft-ietf-mpls-lsp-hierarchy-08.txt describes how to set up two different LSP to create a hierarchy of such LSPs. The document states: "2. Abstract .....A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct)....." What is not clear to me is how this LSP hierarchy is reflected inside the MIBs. Suppose I want to set up two nested LSPs beginning both at the ingress node for example to transport ETS flows within an MPLS domain. The Ingress node should push two labels on L2 packets. I have the following questions: 1) Is the LSR MIB sufficient? Or is the TE MIB necessary? From my point of view the LSR is sufficient: the mplsOutSegmentTable contains the top label, while the mplsLabelStackTable contains the bottom label. 2) When the Ingress node receives the Resv message of the inner LSP, how are the MIBs populated, with what information and how the two nested LSPs are matched? 3) What information is used to refer to the entry inside the MIB relating to the outer LSP? Thanks a lot for spending your valuable time to fill my lacks. Regards, Roberto From owner-mpls@UU.NET Sun Nov 24 06:19:21 2002 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 ESMTP id GAA25202 for ; Sun, 24 Nov 2002 06:18:16 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqhn21718 for ; Sun, 24 Nov 2002 02:55:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqhn16453; Sun, 24 Nov 2002 02:52:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqhn24064 for mpls-outgoing; Sun, 24 Nov 2002 02:51:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqhn24059 for ; Sun, 24 Nov 2002 02:51:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqhn18667 for ; Sun, 24 Nov 2002 02:50:33 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqhn07969 for ; Sun, 24 Nov 2002 02:50:33 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqhn07957 for ; Sun, 24 Nov 2002 02:50:32 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA09111 for ; Sat, 23 Nov 2002 21:50:32 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAO2oWV20643 for mpls@uu.net; Sat, 23 Nov 2002 21:50:32 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnpur19742 for ; Wed, 20 Nov 2002 15:20:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnpur04535 for ; Wed, 20 Nov 2002 15:17:57 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnpur12902 for ; Wed, 20 Nov 2002 15:17:56 GMT Received: from gorilla.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQnpur12890 for ; Wed, 20 Nov 2002 15:17:56 GMT Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA23499; Wed, 20 Nov 2002 16:17:42 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA10125; Wed, 20 Nov 2002 16:17:14 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2656.59) id ; Wed, 20 Nov 2002 16:16:38 +0100 Message-ID: From: Hummel Heinrich To: "'claus.bauer@tellabs.com'" , mpls@UU.NET Subject: AW: Date: Wed, 20 Nov 2002 16:16:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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 GAA25202 Claus, I tried to give answers to your questions in draft-hummel-mpls-hierarchical-lsp-03.txt. Heinrich -----Ursprüngliche Nachricht----- Von: claus.bauer@tellabs.com [mailto:claus.bauer@tellabs.com] Gesendet: Montag, 18. Februar 2002 16:36 An: mpls@UU.NET Betreff: The draft-ietf-mpls-lsp-hierarchy defines forwarding adjacencies and explains how these can be used to route LSPs within LSPs with higher switching granularity. Assuming an MPLS, not GMPLS network where the draft hierarchical LSP is not implemented, I got the following questions: LSPs can be tunneled through existing LSPs via label stacking. a. How do routers initiating an LSP know about the existence of these tunnels except by external means ? How can the available BW of the tunnel be known except by external means ? b. Assume a tunnel is known and an LSR initiating an LSP wants to route the LSP through the tunnel, how does the LSR starting the tunnel know that the LSP wants to be routed through this tunnel. From the ERO ? Claus ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From owner-mpls@UU.NET Sun Nov 24 16:36:13 2002 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 ESMTP id QAA02897 for ; Sun, 24 Nov 2002 16:36:13 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqkj28925 for ; Sun, 24 Nov 2002 21:25:41 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqkj26255; Sun, 24 Nov 2002 21:24:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqkj06386 for mpls-outgoing; Sun, 24 Nov 2002 21:24:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqkj06381 for ; Sun, 24 Nov 2002 21:24:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqkj00870 for ; Sun, 24 Nov 2002 21:23:39 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqkj17896 for ; Sun, 24 Nov 2002 21:23:39 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f159.law14.hotmail.com [64.4.21.159]) id QQnqkj17892 for ; Sun, 24 Nov 2002 21:23:38 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Nov 2002 13:23:38 -0800 Received: from 64.168.20.65 by lw14fd.law14.hotmail.msn.com with HTTP; Sun, 24 Nov 2002 21:23:37 GMT X-Originating-IP: [64.168.20.65] From: "Hitesh Kulkarni" To: David.Charlap@marconi.com Cc: mpls@UU.NET Subject: Re: Does a labeled packet go through "Packet Filtering/Policy Routing/Filter Based Forwarding"? Date: Sun, 24 Nov 2002 13:23:37 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Nov 2002 21:23:38.0036 (UTC) FILETIME=[C0CC6740:01C293FF] Sender: owner-mpls@UU.NET Precedence: bulk Sorry for opening this old thread again after a long time.. David, In a few current or next gen boxes hw genarally has capability to look into the payload even for labelled traffic for load distribution purposes on aggr links etc right?? with regards, hkulk >From: David Charlap >To: IETF MPLS List >Subject: Re: Does a labeled packet go through "Packet Filtering/Policy >Routing/Filter Based Forwarding"? >Date: Thu, 24 Oct 2002 12:42:00 -0400 > >Sachin Kalra wrote: >> >>A quick question. Does a labeled packet go through "Packet >>Filtering/Policy Routing/Filter Based Forwarding"? > >What would you have it filter on? A transit router should not make >forwarding decisions based on anything other than the topmost label. If >you start drilling down into the packet payload to make these decisions, >then why bother using MPLS at all? > >One of the key reasons for MPLS these days is the ability to optimize >traffic engineering. You will decide your route through the network when >you set up the LSP. The node at the LSP's ingress will decide which >packets to forward into which LSP. Once that decision is made, the packets >should not be examined again until they emerge from the other end of the >LSP. > >-- David _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-mpls@UU.NET Mon Nov 25 09:46:33 2002 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 ESMTP id JAA00901 for ; Mon, 25 Nov 2002 09:46:32 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnb10150 for ; Mon, 25 Nov 2002 14:49:12 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnb07689; Mon, 25 Nov 2002 14:48:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnb07987 for mpls-outgoing; Mon, 25 Nov 2002 14:47:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqnb07953 for ; Mon, 25 Nov 2002 14:46:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnqnb02207 for ; Mon, 25 Nov 2002 14:45:19 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnb05384 for ; Mon, 25 Nov 2002 14:45:18 GMT Received: from tokyo.ccrle.nec.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQnqnb05378 for ; Mon, 25 Nov 2002 14:45:18 GMT Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gAPEj6Y53875; Mon, 25 Nov 2002 15:45:06 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 8959979E3A; Mon, 25 Nov 2002 15:43:33 +0100 (CET) Date: Mon, 25 Nov 2002 15:43:33 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Kireeti Kompella , David Charlap Cc: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS Message-ID: <18626323.1038239013@[192.168.102.207]> In-Reply-To: <20021121142323.W46529-100000@kummer.juniper.net> References: <20021121142323.W46529-100000@kummer.juniper.net> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I would prefer to view this at two levels: > o (A) generalized signaling and (B) non-generalized/classical signaling > o (i) non-packet and (ii) packet LSPs (or MPLS networks) > > (A) can be used for both (i) and (ii) > (B) can be used for (ii), but does rather poorly for (i) > > If an applicability statement is needed to say this, so be it. Yes, IMHO GMPLS was always sort of a version 2 of MPLS being backward compatible with version 1 (MPLS) still runs for packet space, but extensted to be useful for other technologies. Might be a good idea to write down the applicability of GMPLS to packet networks. Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus From owner-mpls@UU.NET Mon Nov 25 09:51:45 2002 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 ESMTP id JAA01250 for ; Mon, 25 Nov 2002 09:51:45 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqmy04221 for ; Mon, 25 Nov 2002 14:08:28 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqmy01910; Mon, 25 Nov 2002 14:07:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqmy03607 for mpls-outgoing; Mon, 25 Nov 2002 14:06:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqmy03591 for ; Mon, 25 Nov 2002 14:06:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqmy27680 for ; Mon, 25 Nov 2002 14:06:32 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqmy27571 for ; Mon, 25 Nov 2002 14:06:31 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqmy27567 for ; Mon, 25 Nov 2002 14:06:31 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00935 for ; Mon, 25 Nov 2002 09:06:31 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAPE6Vl03480 for mpls@uu.net; Mon, 25 Nov 2002 09:06:31 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqmn27275 for ; Mon, 25 Nov 2002 11:26:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqmn23001 for ; Mon, 25 Nov 2002 11:26:18 GMT From: Roberto.Guglielmi@alcatel.it Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqmn17195 for ; Mon, 25 Nov 2002 11:26:17 GMT Received: from tlvsca.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.245]) id QQnqmn17173 for ; Mon, 25 Nov 2002 11:26:14 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsca.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gAPBQ2rt010793 for ; Mon, 25 Nov 2002 12:26:03 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002112512281335:2177 ; Mon, 25 Nov 2002 12:28:13 +0100 Message-ID: <3DE20719.203@alcatel.it> Date: Mon, 25 Nov 2002 12:18:49 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@UU.NET Subject: TE MIB - LSR MIB integration X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 12:28:13, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 12:28:16, Serialize complete at 11/25/2002 12:28:16 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello everybody, I have a doubt about interactions between LSR MIB and TE MIB for what concerning LSPs nested in TE tunnels. Consider the following scenario: R1 -------- R2 -------- R3 and suppose, for example, I have three incoming flows. I want to insert each flow in one LSP and tunnel the three LSPs in one TE tunnel. My questions are: 1) How are the three LSPs mapped on the same TE tunnel? 2) Is there only one entry in the mplsTunnelTable pointing to one entry in the mplsXCTable? 3) Does this entry in the mplsXCTable have a not-null mplsLabelStackTable? 4) How many entries are there in the mplsXCTable? And what LSP/TE tunnel do they refer to? 5) Are there four different entries in the mplsXCTable and in the mplsOutSegmentTable referring to a TE tunnel interface in the ifTable (by mplsOutSegmentIfIndex)? If not, how are, in the LSR MIB, the LSP entries correlated to the TE tunnel entry? Thanks in advance for your help. Regards Roberto. From owner-mpls@UU.NET Mon Nov 25 10:24:52 2002 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 ESMTP id KAA03211 for ; Mon, 25 Nov 2002 10:24:52 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqmv25788 for ; Mon, 25 Nov 2002 13:28:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqmv18346; Mon, 25 Nov 2002 13:25:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqmv12786 for mpls-outgoing; Mon, 25 Nov 2002 13:25:26 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqmv12776 for ; Mon, 25 Nov 2002 13:25:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqmv04709 for ; Mon, 25 Nov 2002 13:25:06 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqmv29271 for ; Mon, 25 Nov 2002 13:25:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqmv29263 for ; Mon, 25 Nov 2002 13:25:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA28636 for ; Mon, 25 Nov 2002 08:25:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAPDP5d00370 for mpls@uu.net; Mon, 25 Nov 2002 08:25:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqmv12711 for ; Mon, 25 Nov 2002 13:23:30 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 QQnqmv04795 for ; Mon, 25 Nov 2002 13:23:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqmv16245 for ; Mon, 25 Nov 2002 13:23:08 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 QQnqmv15665 for ; Mon, 25 Nov 2002 13:22:37 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26633; Mon, 25 Nov 2002 08:19:53 -0500 (EST) Message-Id: <200211251319.IAA26633@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-te-feed-05.txt Date: Mon, 25 Nov 2002 08:18:48 -0500 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 : Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol Author(s) : P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki Filename : draft-ietf-mpls-te-feed-05.txt Pages : 13 Date : 2002-11-21 One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints, which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. A new mechanism is proposed whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This information is most valuable in failure scenarious but is benificial during other path setup functions as well. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy of the overall routing solution by significantly reducing the database discrepancies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-te-feed-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-te-feed-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-21133908.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-feed-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-feed-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-21133908.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Nov 25 11:29:12 2002 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 ESMTP id LAA06942 for ; Mon, 25 Nov 2002 11:29:12 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqni20236 for ; Mon, 25 Nov 2002 16:31:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqni18491; Mon, 25 Nov 2002 16:30:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqni22842 for mpls-outgoing; Mon, 25 Nov 2002 16:30:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqni22835 for ; Mon, 25 Nov 2002 16:30:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnqni10141 for ; Mon, 25 Nov 2002 16:30:07 GMT From: Emmanuel.Dotaro@alcatel.fr Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqni01212 for ; Mon, 25 Nov 2002 16:30:07 GMT Received: from smail3.alcatel.fr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: colt-na7.alcatel.fr [62.23.212.7]) id QQnqni01202 for ; Mon, 25 Nov 2002 16:30:06 GMT Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id gAPGTxek015667; Mon, 25 Nov 2002 17:29:59 +0100 Received: from alcatel.fr ([172.25.81.137]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2002112517295808:6688 ; Mon, 25 Nov 2002 17:29:58 +0100 Message-ID: <3DE25008.17FDDB82@alcatel.fr> Date: Mon, 25 Nov 2002 17:30:00 +0100 Reply-To: Emmanuel.Dotaro@alcatel.fr Organization: Alcatel X-Mailer: Mozilla 4.78 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: IETF MPLS List CC: David Charlap Subject: Re: GMPLS features applicable to MPLS References: <200211221921.OAA14676@bigbird.xebeo.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/25/2002 17:29:58, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 11/25/2002 17:29:59 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA06942 Hi all, I support the idea that by definition GMPLS is a superset of MPLS. It makes sense to have a document that clarify the applicability of GMPLS for Packet LSPs (and also for L2LSPs –ATM/FR/Eth…- ?). We may also consider their future integration. regards Emmanuel Rohit Dube a écrit : > On Fri, 22 Nov 2002 10:02:28 -0500 David Charlap writes: > [snip] > =>Any one of these would be fine for me. My main concern here is that > =>MPLS vendors will start implementing those features, and some may ignore > =>the GMPLS approach, thinking that those drafts are not applicable to > =>non-generalized MPLS. This may lead to interop issues. > => > =>Of course, vendors often ignore drafts anyway, but at least this way > =>they'll know that there is something out there that they can choose to > =>implement or ignore. And those that need to pull pieces of GMPLS into > =>their MPLS implementations will know how much must be pulled in to > =>properly support the features under development. > > Excellent points David. And in fact this is what happened with the > "bidirectional lsps for classical mpls" draft that I presented at the > IETF. > > A quick solution is needed for this class of problems! > > Regards, > --rohit. From owner-mpls@UU.NET Mon Nov 25 11:55:16 2002 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 ESMTP id LAA08591 for ; Mon, 25 Nov 2002 11:55:16 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnj23992 for ; Mon, 25 Nov 2002 16:57:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnj22581; Mon, 25 Nov 2002 16:57:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnj25124 for mpls-outgoing; Mon, 25 Nov 2002 16:56:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqnj25117 for ; Mon, 25 Nov 2002 16:56: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 QQnqnj07301 for ; Mon, 25 Nov 2002 16:56:04 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnj21625 for ; Mon, 25 Nov 2002 16:56:03 GMT Received: from exchange.tropicnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50]) id QQnqnj21619 for ; Mon, 25 Nov 2002 16:56:03 GMT Received: from tropicnetworks.com ([10.1.5.206]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 25 Nov 2002 11:55:57 -0500 Message-ID: <3DE2561D.345ECF7E@tropicnetworks.com> Date: Mon, 25 Nov 2002 11:55:57 -0500 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lou Berger CC: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <20021121142323.W46529-100000@kummer.juniper.net> <4.3.2.7.2.20021121222400.02555e98@mail.labn.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Nov 2002 16:55:57.0822 (UTC) FILETIME=[8693F9E0:01C294A3] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Lou, In theory, GMPLS is supposed to encompass MPLS and packet-based devices as well. In practise, there appears to be a clear demarcation between MPLS & GMPLS. This is further confirmed by industry usage of GMPLS for application to optical systems. The best approach would have been to denote the lowest common denominator objects as part of MPLS and other extensions as GMPLS. This I believe was David's point wrt to Hitless Restart and Unnumbered Links which could be used with the packet MPLS defined today. Not doing so causes some confusion. Let me try to illustrate with one example. Using 3rd party stack source vendors is becoming more and more commonplace. Such vendors would offer GMPLS & MPLS as separate code offerings. In order to implement a packet-based MPLS device that supports Hitless Restart & Unnum Links, they would need to purchase and integrate an entire GMPLS stack which their device does not otherwise require. Best, Nabil Seddigh Lou Berger wrote: > > GMPLS applies to packets as well. It seems that all that is need here is > an explanation (app note) of how to use gmpls with packets. This should be > a short document... > > (it just takes using the new label request and label object...) > > Lou > > At 09:12 PM 11/21/2002, Loa Andersson wrote: > >All, > > > >let me see if I understand this correctly. > > > >I think that the general problem is -given the definitions by Kireeti > >below - that: > > > >- something specified in a ccamp spec makes perfect sense > > for something in vanilla ;) mpls (using signaling type B) > > > >- the ccamp spec specifies more than what is needed (makes sense) for > > the vanilla mpls that has to be implemented to comply to the with the > > spec > > > >Then the issue is, how do we handle this? > > > >Is this the background for the question? If so, I can see several > >ways of doing things > > > >- split documents, one mpls and another ccamp one, where the ccamp > > include the mpls doc (by reference) > >- do it by applicability statements, from the mpls side saying "what is > > specified in the ccamp if doc is a great idea, but if you apply it to > > packet mpls you don need to implement ..." > >- include info in the ccamp doc on what is needed in packet mpls > > > >/Loa > > > >Kireeti Kompella wrote: > >>Hi David, > >>On Thu, 21 Nov 2002, David Charlap wrote: > >> > >>>During the course of development, I have noticed that there are several > >>>features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09) > >>>that are applicable to non-generalized MPLS networks. > >> > >>There are those who refer to generalized and non-generalized MPLS > >>networks, those who talk about GMPLS and classical MPLS, etc. > >>I would prefer to view this at two levels: > >> o (A) generalized signaling and (B) non-generalized/classical signaling > >> o (i) non-packet and (ii) packet LSPs (or MPLS networks) > >>(A) can be used for both (i) and (ii) > >>(B) can be used for (ii), but does rather poorly for (i) > >>If an applicability statement is needed to say this, so be it. > >>Kireeti. > > > > > >-- > > /Loa > > > > > > Loa Andersson > > Utfors AB > > Råsundavägen 12 > > Box 525, 169 29 Solna > > Mobile +46 70 848 5038 > > Email loa.andersson@utfors.se > > From owner-mpls@UU.NET Mon Nov 25 12:00:34 2002 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 ESMTP id MAA09027 for ; Mon, 25 Nov 2002 12:00:34 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnk05309 for ; Mon, 25 Nov 2002 17:03:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnk03116; Mon, 25 Nov 2002 17:02:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnk05566 for mpls-outgoing; Mon, 25 Nov 2002 17:01:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqnk05508 for ; Mon, 25 Nov 2002 17:01:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnqnk29402 for ; Mon, 25 Nov 2002 17:01:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnk01763 for ; Mon, 25 Nov 2002 17:01:22 GMT Received: from pimout1-ext.prodigy.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pimout1-ext.prodigy.net [207.115.63.77]) id QQnqnk00524 for ; Mon, 25 Nov 2002 17:00:52 GMT Received: from cs.columbia.edu (adsl-64-175-245-22.dsl.sntc01.pacbell.net [64.175.245.22]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id gAPH0bE9236790; Mon, 25 Nov 2002 12:00:38 -0500 Message-ID: <3DE25732.4040900@cs.columbia.edu> Date: Mon, 25 Nov 2002 09:00:34 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emmanuel.Dotaro@alcatel.fr CC: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <200211221921.OAA14676@bigbird.xebeo.com> <3DE25008.17FDDB82@alcatel.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hmmm... have to bite now. Who is confused here? The carriers? Don't think so. They know exactly which feature to have in their networks. The developers? Don't think so either. They know what can and cannot be implemented. So if we have enough solutions floating around in various drafts and RFC's. Why write more document? - Ping From owner-mpls@UU.NET Mon Nov 25 12:14:43 2002 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 ESMTP id MAA10420 for ; Mon, 25 Nov 2002 12:14:43 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnc15235 for ; Mon, 25 Nov 2002 15:12:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnc13137; Mon, 25 Nov 2002 15:11:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnc27842 for mpls-outgoing; Mon, 25 Nov 2002 15:11:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqnc27831 for ; Mon, 25 Nov 2002 15:11:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqnc28937 for ; Mon, 25 Nov 2002 15:11:18 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnc03740 for ; Mon, 25 Nov 2002 15:11:18 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 QQnqnc03733 for ; Mon, 25 Nov 2002 15: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 KAA26211 for ; Mon, 25 Nov 2002 10:11:16 -0500 (EST) 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 KAA00064 for ; Mon, 25 Nov 2002 10:11:17 -0500 (EST) Message-ID: <3DE23D9A.80104@marconi.com> Date: Mon, 25 Nov 2002 10:11:22 -0500 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Does a labeled packet go through "Packet Filtering/Policy Routing/Filter Based Forwarding"? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hitesh Kulkarni wrote: > > In a few current or next gen boxes hw genarally has capability to look > into the payload even for labelled traffic for load distribution > purposes on aggr links etc right?? Was there a question in here? Asking a working group about whether somebody has implemented something in hardware isn't exactly a useful question. You may be better off asking groups that deal with users of protocols, or developers of hardware. I think you meant to ask whether hadware with this capability may use it for forwarding labeled traffic. My answer is that it can use whatever it wants, but it would be a dumb idea. Unless you want your hardware to snoop RSVP LABEL_REQUEST objects and also monitor for Martini-type labels in the stack, _and_ have configured knowledge about any exceptions, your hardware won't always guess correctly about what the LSP's payload is. If it's not the type you think it is, then you will be reading garbage values, and you'll be making incorrect decisions based on that garbage. If you think a packet carries an IP payload when it's really AppleTalk, or IPX, or Ethernet frames, or raw voice data, or something else, and you start doing load-balancing forwarding calculations based on what you think you find in there, you're going to break the traffic. -- David From owner-mpls@UU.NET Mon Nov 25 12:25:24 2002 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 ESMTP id MAA11161 for ; Mon, 25 Nov 2002 12:25:24 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnl03174 for ; Mon, 25 Nov 2002 17:28:00 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnl00836; Mon, 25 Nov 2002 17:26:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnl15980 for mpls-outgoing; Mon, 25 Nov 2002 17:26:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqnl15975 for ; Mon, 25 Nov 2002 17:26:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqnl11135 for ; Mon, 25 Nov 2002 17:26:11 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnl01040 for ; Mon, 25 Nov 2002 17:26:10 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 QQnqnl01029 for ; Mon, 25 Nov 2002 17:26: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 MAA05903 for ; Mon, 25 Nov 2002 12:26:08 -0500 (EST) 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 MAA06727 for ; Mon, 25 Nov 2002 12:26:09 -0500 (EST) Message-ID: <3DE25D36.8030203@marconi.com> Date: Mon, 25 Nov 2002 12:26:14 -0500 From: David Charlap User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <200211221921.OAA14676@bigbird.xebeo.com> <3DE25008.17FDDB82@alcatel.fr> <3DE25732.4040900@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ping Pan wrote: > Hmmm... have to bite now. Who is confused here? The carriers? Don't > think so. They know exactly which feature to have in their networks. The > developers? Don't think so either. They know what can and cannot be > implemented. So if we have enough solutions floating around in various > drafts and RFC's. Why write more document? Because the developers implementing these features for MPLS switches are not necessarily going to do it in the GMPLS way. They may very well review the available documents and conclude "unnumbered links are only specified for GMPLS and not MPLS, so we're free to pursue a proprietary solution for our MPLS products." -- David From owner-mpls@UU.NET Mon Nov 25 12:36:28 2002 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 ESMTP id MAA11963 for ; Mon, 25 Nov 2002 12:36:27 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnm16959 for ; Mon, 25 Nov 2002 17:38:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnm15219; Mon, 25 Nov 2002 17:38:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnm16672 for mpls-outgoing; Mon, 25 Nov 2002 17:37:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqnm16667 for ; Mon, 25 Nov 2002 17:37: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 QQnqnm00005 for ; Mon, 25 Nov 2002 17:36:54 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnm29132 for ; Mon, 25 Nov 2002 17:36:54 GMT Received: from celox-ma1-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) id QQnqnm29122 for ; Mon, 25 Nov 2002 17:36:54 GMT Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Nov 2002 12:36:53 -0500 Message-ID: <1117F7D44159934FB116E36F4ABF221B0267ECCD@celox-ma1-ems1.celoxnetworks.com> From: "Gray, Eric" To: "'Ping Pan'" Cc: IETF MPLS List Subject: RE: GMPLS features applicable to MPLS Date: Mon, 25 Nov 2002 12:36:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Ping, In general, it is not usually a good approach toward achieving interoperability to assume that a large number of vendors will pick the same pieces and put them together in the same way - just because all of the pieces to a solution exist already. Eric W. Gray Systems Architect Celox Networks, Inc. egray@celoxnetworks.com 508 305 7214 > -----Original Message----- > From: Ping Pan [mailto:pingpan@cs.columbia.edu] > Sent: Monday, November 25, 2002 12:01 PM > To: Emmanuel.Dotaro@alcatel.fr > Cc: IETF MPLS List > Subject: Re: GMPLS features applicable to MPLS > > Hmmm... have to bite now. Who is confused here? The carriers? Don't > think so. They know exactly which feature to have in their networks. The > developers? Don't think so either. They know what can and cannot be > implemented. So if we have enough solutions floating around in various > drafts and RFC's. Why write more document? > > - Ping From owner-mpls@UU.NET Mon Nov 25 12:53:23 2002 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 ESMTP id MAA13133 for ; Mon, 25 Nov 2002 12:53:22 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnn23832 for ; Mon, 25 Nov 2002 17:56:02 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnn22192; Mon, 25 Nov 2002 17:55:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnn17949 for mpls-outgoing; Mon, 25 Nov 2002 17:54:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqnn17936 for ; Mon, 25 Nov 2002 17:54:54 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 QQnqnn20414 for ; Mon, 25 Nov 2002 17:54:33 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnn21635 for ; Mon, 25 Nov 2002 17:54:32 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 QQnqnn21629 for ; Mon, 25 Nov 2002 17:54:32 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 MAA07247; Mon, 25 Nov 2002 12:54:30 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10794; Mon, 25 Nov 2002 12:54:31 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Nov 2002 12:54:31 -0500 Message-ID: <39469E08BD83D411A3D900204840EC55763459@VIE-MSGUSR-01> From: "Naidu, Venkata" To: "'Ping Pan'" Cc: IETF MPLS List Subject: RE: GMPLS features applicable to MPLS Date: Mon, 25 Nov 2002 12:54:29 -0500 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 -> Hmmm... have to bite now. Who is confused here? The carriers? Don't -> think so. They know exactly which feature to have in their -> networks. The -> developers? Don't think so either. They know what can and cannot be -> implemented. So if we have enough solutions floating around -> in various drafts and RFC's. Why write more document? More than a year back, I pointed the potential confusion of these "drafts" vs "features" applicability. The confusion still exists, so do something to rectify this confusion. See the last bullet in my old mail. http://cell-relay.indiana.edu/mhonarc/mpls/2001-Sep/msg00268.html -- Venkata. From owner-mpls@UU.NET Mon Nov 25 13:01:44 2002 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 ESMTP id NAA13708 for ; Mon, 25 Nov 2002 13:01:43 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqno13955 for ; Mon, 25 Nov 2002 18:04:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqno10578; Mon, 25 Nov 2002 18:02:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqno24338 for mpls-outgoing; Mon, 25 Nov 2002 18:01:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqno24176 for ; Mon, 25 Nov 2002 18:01:49 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 QQnqno25670 for ; Mon, 25 Nov 2002 18:01:37 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqno03354 for ; Mon, 25 Nov 2002 18:01:36 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqno03348 for ; Mon, 25 Nov 2002 18:01:36 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA22376 for ; Mon, 25 Nov 2002 13:01:36 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAPI1av19878 for mpls@uu.net; Mon, 25 Nov 2002 13:01:36 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqnn17390 for ; Mon, 25 Nov 2002 17:45:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqnn16317 for ; Mon, 25 Nov 2002 17:45:48 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnn07651 for ; Mon, 25 Nov 2002 17:45:48 GMT Received: from mgw-x4.nokia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mgw-x4.nokia.com [131.228.20.27]) id QQnqnn07639 for ; Mon, 25 Nov 2002 17:45:47 GMT Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAPHkh621036 for ; Mon, 25 Nov 2002 19:46:43 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 25 Nov 2002 19:45:46 +0200 Received: from samail01.nmp.nokia.com ([131.228.240.6]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Nov 2002 19:45:44 +0200 Received: from www.nmp.nokia.com (www.nmp.nokia.com [131.228.244.112]) by samail01.nmp.nokia.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id VAA25722 for ; Mon, 25 Nov 2002 21:46:20 +0200 (EET) Received: from bigfoot.com (hed036-146.research.nokia.com [172.21.36.146]) by www.nmp.nokia.com (8.9.3 (PHNE_18979)/8.8.4) with ESMTP id TAA22621 for ; Mon, 25 Nov 2002 19:36:30 +0200 (EET) Message-ID: <3DE26007.6060109@bigfoot.com> Date: Mon, 25 Nov 2002 19:38:15 +0200 From: Chopin He Reply-To: chopin.he@bigfoot.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: zh, en, en-us, zh-cn MIME-Version: 1.0 To: mpls@UU.NET Subject: "Path Computation Server" Definition and Functionality Description Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Nov 2002 17:45:44.0923 (UTC) FILETIME=[7B076AB0:01C294AA] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi! folks! I hope this is the right place to ask this stupid MPLS question. I read couple of I-Ds mentioning "Path Computation Server", But I am a bit unclear about its definition and functionality. So far, PCS is mentioned in many documents [1][2][3][4][5], one example of its definition is found as:[1] "PCS: Path Computation Server (may be any kind of LSR (ABR, ASBR, ...) or a centralized path computation server " This is quite a detailed explaination, but I understand the LSR or ABR or ASBR are control plane components; while the centralised path computaton server is a management plane component. In some case, (e.g. network management), their roles are lardgely different. Is that possible to define them seperately? Additionaly, it seems to me that PCS's functionality is to response the PCC's Path Computation Request, thus compute the path, and send the result back to PCC. This sounds perfect. While I am still a bit unclear. What kind of information the PCS need to know? How can the PCS get the relevant information? And so on. E.g. Brunner said in [3]: "Definitely the path computation server needs topology information in order to perform its task. But how to get that information is out of scope of this document. " I wonder if there are some specification which defines the PCS's functionality explicitly? If not, can somebody take the initiative? Thanks for your time to read this mail. Best wishes! -- Chopin [1] Vasseur JP, et al., “RSVP Path computation request and reply messages”, , IETF work in progress, Jun 2002. [2] JP Vasseur, "IS-IS Path Computation Server discovery TLV", , IETF work in progress, June, 2002 [3] M. Brunner, " COPS usage for Path Computation Servers (COPS-PCS)", , IETF work in progress, September, 2002 [4] JP Vasseur, Peter Psenak, "OSPF Path Computation Server discovery", , IETF work in progress, June, 2002 [5] JP Vasseur, Peter Psenak, "OSPF Traffic Engineering capability TLVs ", , IETF work in progress, October, 2002 From owner-mpls@UU.NET Mon Nov 25 13:02:11 2002 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 ESMTP id NAA13738 for ; Mon, 25 Nov 2002 13:02:11 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqno29028 for ; Mon, 25 Nov 2002 18:04:51 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqno27433; Mon, 25 Nov 2002 18:04:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqno00054 for mpls-outgoing; Mon, 25 Nov 2002 18:03:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqno28666 for ; Mon, 25 Nov 2002 18:03:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqno05804 for ; Mon, 25 Nov 2002 18:03:17 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqno04756 for ; Mon, 25 Nov 2002 18:03:17 GMT Received: from exchange.tropicnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50]) id QQnqno04752 for ; Mon, 25 Nov 2002 18:03:16 GMT Received: from tropicnetworks.com ([10.1.5.206]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 25 Nov 2002 13:03:16 -0500 Message-ID: <3DE265E4.248C9DBB@tropicnetworks.com> Date: Mon, 25 Nov 2002 13:03:16 -0500 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ping Pan CC: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <200211221921.OAA14676@bigbird.xebeo.com> <3DE25008.17FDDB82@alcatel.fr> <3DE25732.4040900@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2002 18:03:16.0473 (UTC) FILETIME=[EDCD3690:01C294AC] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ping, You make a good point. This discussion is about document organization. Nothing earth shattering. This would not be important except that in some ways the world has changed. No longer do we have only a handful of implementations of a particular protocol - all being done by folks who work in 2 or 3 companies. Protocols are being implemented by an increasing number of companies with development in many parts of the world other than North America. Having well organized content simply makes lives easier for future developers. In this particular case, it also has clear implications on $ and code creep - see my previous email. Ideally, the Hitless Restart content & Unnumbered Links content should have remained separate content applicable to MPLS. Otherwise the next best compromise is an applicability statement draft. Best, Nabil Ping Pan wrote: > > Hmmm... have to bite now. Who is confused here? The carriers? Don't > think so. They know exactly which feature to have in their networks. The > developers? Don't think so either. They know what can and cannot be > implemented. So if we have enough solutions floating around in various > drafts and RFC's. Why write more document? > > - Ping From owner-mpls@UU.NET Mon Nov 25 13:53:16 2002 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 ESMTP id NAA17212 for ; Mon, 25 Nov 2002 13:53:15 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnr29710 for ; Mon, 25 Nov 2002 18:55:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnr26855; Mon, 25 Nov 2002 18:54:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnr10253 for mpls-outgoing; Mon, 25 Nov 2002 18:54:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqnr10248 for ; Mon, 25 Nov 2002 18:54:01 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 QQnqnr22031 for ; Mon, 25 Nov 2002 18:53:56 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnr16390 for ; Mon, 25 Nov 2002 18:53:25 GMT Received: from mail.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQnqnr16370 for ; Mon, 25 Nov 2002 18:53:25 GMT Received: from bemail05.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAPIrOQ18921 for ; Mon, 25 Nov 2002 19:53:24 +0100 Received: from alcatel.be ([138.203.67.40]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002112519532167:4996 ; Mon, 25 Nov 2002 19:53:21 +0100 Message-ID: <3DE27285.C479A722@alcatel.be> Date: Mon, 25 Nov 2002 19:57:09 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ping Pan Cc: Emmanuel.Dotaro@alcatel.fr, IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <200211221921.OAA14676@bigbird.xebeo.com> <3DE25008.17FDDB82@alcatel.fr> <3DE25732.4040900@cs.columbia.edu> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 19:53:21, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 19:53:23, Serialize complete at 11/25/2002 19:53:23 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit well if there was no confusion, the question would have been why such e-mail exchanges, imho they translate the need for consolidating the various work performed in different wg after two years of sustained sup-ip area efforts,... in any case such i-d's won't hurt whose that knows but certainly help in moving forward (taking here a broader perspective) with these efforts - dimitri. Ping Pan wrote: > > Hmmm... have to bite now. Who is confused here? The carriers? Don't > think so. They know exactly which feature to have in their networks. The > developers? Don't think so either. They know what can and cannot be > implemented. So if we have enough solutions floating around in various > drafts and RFC's. Why write more document? > > - Ping -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 From owner-mpls@UU.NET Mon Nov 25 14:33:30 2002 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 ESMTP id OAA19791 for ; Mon, 25 Nov 2002 14:33:29 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnu07281 for ; Mon, 25 Nov 2002 19:36:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnu05289; Mon, 25 Nov 2002 19:35:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnu02140 for mpls-outgoing; Mon, 25 Nov 2002 19:35:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqnu02131 for ; Mon, 25 Nov 2002 19:34:58 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 QQnqnu18319 for ; Mon, 25 Nov 2002 19:34:40 GMT From: riza.cetin@alcatel.be Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnu04656 for ; Mon, 25 Nov 2002 19:34:39 GMT Received: from mail.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQnqnu04620 for ; Mon, 25 Nov 2002 19:34:35 GMT Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAPJYYm24830 for ; Mon, 25 Nov 2002 20:34:34 +0100 Received: from alcatel.be ([143.209.15.175]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002112520343245:6159 ; Mon, 25 Nov 2002 20:34:32 +0100 Message-ID: <3DE27B46.16220049@alcatel.be> Date: Mon, 25 Nov 2002 20:34:30 +0100 X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: jcucchiara@artel.com Subject: LDP-MIB extensions X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 20:34:32, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 20:34:34, Serialize complete at 11/25/2002 20:34:34 Content-Type: multipart/mixed; boundary="------------473D6CA7A39DB873ED77118A" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------473D6CA7A39DB873ED77118A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi everybody, Attached text file listing the comments on the LDP-MIB and proposal for the extensions. Note that most of the extension/changes have been discussed during Saturday's (the day before IETF) MPLS-MIB review meeting and found very useful. Please provide your feedback before Joan includes them in the LDP-MIB draft. Thanks, Riza. --------------473D6CA7A39DB873ED77118A Content-Type: text/plain; charset=us-ascii; name="ldp-mib-extensions.txt" Content-Disposition: inline; filename="ldp-mib-extensions.txt" Content-Transfer-Encoding: 7bit -- *********************************** -- LDP-MIB Comments -- *********************************** Scalar object: 1. Add EgressLabelType (explicitNull, implicitNull) object. Entity Table: 1. Configuration to "Accept Targetted Hellos" or "Send Targetted Hellos". RFC3036: "Targeted Session is asymmetric and unidirectional." 2. Add HelloInterval (read-create) object. 3. Add KeepAliveInterval (read-create) object. 4. Add TransportAddress object to allow configuration of own transort address. PeerTable: 1. Add Transport Address of Peer (read-only) object. 2. Add to Peer Type (read-only) object. HelloAdjTable: 1. Add Negotiated HelloAdjNegotiatedHoldTime (read-only) object. 2. Add Hello Adj Interval Timer (read-only) object. LdpSessionTable: 1. Add Negotiated Keep Alive Time (read-only) object. 2. Add Keep Alive Interval Time (read-only) object. 3. Add InitRole - active or passive (read-only) object. LdpLspTable: 1. InterfaceIndexOrZero. GenericLabelRangeTable: 1. IfIndex 0 should refer to the global label space. -- *********************************** -- LDP-MIB Extensions PROPOSAL -- *********************************** -- *********************************** -- Scalar objects -- *********************************** mplsLdpEgressLabelType OBJECT-TYPE SYNTAX INTEGER { explicitNull (1), implicitNull (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "LDP Egress Label Type. This object specifies the type of label to be advertised by the LSR for FECs for which it is configured as the Egress node. A value of explicitNull (1) for this object specifies that a value of 0 will be advertised as the label. A value of implicitNull (2) for this object specifies that a value of 3 will be advertised as the label. Any modification of this object will result in the withdrawal and re-advertisement of all FECs for which the node is egress." DEFVAL { implicitNull } ::= { mplsLdp xxx } -- *********************************** -- LDP Entity Table Extensions -- *********************************** mplsLdpEntityEntry ::= SEQUENCE { ....................... mplsLdpEntityHelloInterval Integer32, mplsLdpEntityKaInterval Integer32, mplsLdpEntityTransAddr INTEGER } mplsLdpEntityHelloInterval OBJECT-TYPE SYNTAX Integer32 (2..10) MAX-ACCESS read-create STATUS current DESCRIPTION "The interval after which a hello is transmitted as a fraction of the Hello Hold time negotiated. It is calculated as follows Hello Interval Time (Hello Tx Time) = Hello Hold Time negotiated / Hello Interval." DEFVAL { 3 } ::= { mplsLdpEntityEntry x } mplsLdpEntityKaInterval OBJECT-TYPE SYNTAX Integer32 (2..10) MAX-ACCESS read-create STATUS current DESCRIPTION "The interval after which a keepalive is transmitted as a fraction of the KeepAlive Hold Timer negotiated. It is calculated as follows KeepAlive Interval Time (KeepAlive Tx Time) = KeepAlive Hold Time negotiated / KeepAlive Interval." DEFVAL { 3 } ::= { mplsLdpEntityEntry x } mplsLdpEntityTransAddr OBJECT-TYPE SYNTAX INTEGER { interface(1), loopback(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This specifies whether loopback or interface address is to be used in the transport address TLV in the hello messages. If the value is set to interface(1), the IP address of the interface via which the hello message is sent will be used as the transport address in the hello message. If the value is set to loopback(2), the IP address of loopback interface shall be used as the transport address in the hello message. Note that any change in the status of the interface whose address is being used as transport address will result in re-establishment of all sessions using this as transport address." DEFVAL { loopback } ::= { mplsLdpEntityEntry x } -- ********************************* -- LDP Peer Table Extensions -- ********************************* mplsLdpPeerEntry ::= SEQUENCE { ....................... mplsLdpPeerTransAddrType AddressFamilyNumbers, mplsLdpPeerTransAddr MplsLdpGenAddr, mplsLdpPeerType INTEGER } mplsLdpPeerTransAddrType OBJECT-TYPE SYNTAX AddressFamilyNumbers MAX-ACCESS read-only STATUS current DESCRIPTION "This specifies the transport address type advertised by the peer in hello message." ::= { mplsLdpPeerEntry x } mplsLdpPeerTransAddr OBJECT-TYPE SYNTAX MplsLdpGenAddr MAX-ACCESS read-only STATUS current DESCRIPTION "This specifies the transport address advertised by the peer in the hello message." ::= { mplsLdpPeerEntry x } mplsLdpPeerType OBJECT-TYPE SYNTAX INTEGER { link (1), targeted (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This value describes the connectivity of the peer." ::= { mplsLdpPeerEntry x } -- ******************************************** -- LDP Hello Adjacency Table Extensions -- ******************************************** mplsLdpHelloAdjEntry ::= SEQUENCE { ....................... mplsLdpHelloAdjNegHoldTimer Integer32, mplsLdpHelloAdjIntervalTimer Integer32 } mplsLdpHelloAdjNegHoldTimer OBJECT-TYPE SYNTAX Integer32(1..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This specifies the hello hold timer which is negotiated with the peer for this hello adjacency. A value of 65535 denotes that hold timer is infinite and is not used." ::= { mplsLdpHelloAdjEntry x } mplsLdpHelloAdjIntervalTimer OBJECT-TYPE SYNTAX Integer32(1..65535) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This specifies the hello transmission interval for this adjacency. This is calculated from the negotiated Hello hold timer as follows. Hello Interval Time (Hello Tx Time) = Hello Hold Time negotiated / Hello Interval A value of 65535 denotes that hold interval timer is infinite and is not used." ::= { mplsLdpHelloAdjEntry x } -- ************************************* -- LDP Sessions Table Extensions -- ************************************* mplsLdpSessionEntry ::= SEQUENCE { ......................... mplsLdpSesNegKaTimer Integer32, mplsLdpSesKaIntervalTimer Integer32, mplsLdpSesInitRole INTEGER } mplsLdpSesNegKaTimer OBJECT-TYPE SYNTAX Integer32(1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This specifies the KeepAlive Timer obtained from session negotiations with the peer." ::= { mplsLdpSessionEntry x } mplsLdpSesKaIntervalTimer OBJECT-TYPE SYNTAX Integer32(1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This specifies the KeepAlive Transmission timer being used for this session. This is calculated from the negotiated KeepAlive Hold Timer as follows KeepAlive Interval Time (KeepAlive Tx Time) = KeepAlive Hold Time negotiated / KeepAlive Interval." ::= { mplsLdpSessionEntry x } mplsLdpSesInitRole OBJECT-TYPE SYNTAX INTEGER { active(1), passive(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This specifies the role played by the entity during the session initialisation. A value of active(1) means that the entity initiates the session. A value of passive(2) means that the entity waits for the session initialisation message from the peer." ::= { mplsLdpSessionEntry x } END --------------473D6CA7A39DB873ED77118A-- From owner-mpls@UU.NET Mon Nov 25 15:12:45 2002 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 ESMTP id PAA22363 for ; Mon, 25 Nov 2002 15:12:45 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnx14757 for ; Mon, 25 Nov 2002 20:15:25 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqnw11099; Mon, 25 Nov 2002 20:13:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqnw23626 for mpls-outgoing; Mon, 25 Nov 2002 20:13:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqnw23621 for ; Mon, 25 Nov 2002 20:13:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnqnw10849 for ; Mon, 25 Nov 2002 20:13:27 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqnw10715 for ; Mon, 25 Nov 2002 20:13:27 GMT Received: from gateway.ipinfusion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnqnw10709 for ; Mon, 25 Nov 2002 20:13:26 GMT Received: from YuanHong (dhcp129.ipinfusion.com [10.10.0.129] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with SMTP id gAPKBWa31830; Mon, 25 Nov 2002 12:11:32 -0800 From: "Yuan Gu" To: , Subject: RE: TE MIB - LSR MIB integration Date: Mon, 25 Nov 2002 12:11:46 -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) In-Reply-To: <3DE20719.203@alcatel.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Roberto: > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Roberto.Guglielmi@alcatel.it > Sent: Monday, November 25, 2002 3:19 AM > To: mpls@UU.NET > Subject: TE MIB - LSR MIB integration > > > Hello everybody, > I have a doubt about interactions between LSR MIB and TE MIB for what > concerning LSPs nested in TE tunnels. > Consider the following scenario: > > R1 -------- R2 -------- R3 > > and suppose, for example, I have three incoming flows. I want to insert > each flow in one LSP and tunnel the three LSPs in one TE tunnel. > My questions are: > > 1) How are the three LSPs mapped on the same TE tunnel? There will be 3 entries in mplsTunnelTable. Each entry has different mplsTuunnelInstance. The mplsTunnelInstance "Uniquely identifies an instance of a tunnel. It is useful to identify multiple instances of tunnels for the purposes of backup and parallel tunnels." You may want to put your LSPID into this field. > > 2) Is there only one entry in the mplsTunnelTable pointing to one entry > in the mplsXCTable? There will be 3 corresponding entries in mplsXCTable. Each entry has different mplsXCLspId (RSVP-TE or CR-LDP). From owner-mpls@UU.NET Mon Nov 25 16:12:06 2002 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 ESMTP id QAA25977 for ; Mon, 25 Nov 2002 16:12:06 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqoa06091 for ; Mon, 25 Nov 2002 21:14:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqoa04467; Mon, 25 Nov 2002 21:14:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqoa17056 for mpls-outgoing; Mon, 25 Nov 2002 21:13:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqoa17050 for ; Mon, 25 Nov 2002 21:13:36 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 QQnqoa21721 for ; Mon, 25 Nov 2002 21:12:41 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqoa03009 for ; Mon, 25 Nov 2002 21:12:40 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f157.sea2.hotmail.com [207.68.165.157]) id QQnqoa02997 for ; Mon, 25 Nov 2002 21:12:40 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Nov 2002 13:12:36 -0800 Received: from 63.104.212.252 by sea2fd.sea2.hotmail.msn.com with HTTP; Mon, 25 Nov 2002 21:12:35 GMT X-Originating-IP: [63.104.212.252] From: "Sandeep B" To: nseddigh@tropicnetworks.com, pingpan@cs.columbia.edu Cc: mpls@UU.NET Subject: Re: GMPLS features applicable to MPLS Date: Mon, 25 Nov 2002 21:12:35 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Nov 2002 21:12:36.0109 (UTC) FILETIME=[60AC1BD0:01C294C7] Sender: owner-mpls@UU.NET Precedence: bulk There are few other things - e.g. L3PID. GMPLS explicitly defines that for Lsps that carry a certain type of traffic it needs to signal that using GPID e.g IP lsp should set certain GPID and L2VPN-MPLS lsps a certain other GPID. But there is no such defination in classic RSVP-TE. Such a case what should be the criteria. Do we follow GMPLS RSVP-TE or classic?? Particular to this question - Do we have finally decided what should L2VPN lsps signal as their L3PID???? http://cell.onecall.net/mhonarc/mpls/2002-Apr/msg00163.html GMPLS def ==>> The G-PID parameter is normally only examined at the egress. If the indicated G-PID cannot be supported then the egress MUST generate a PathErr message, with a "Routing problem/Unsupported L3PID" indication. In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G- PID during the processing of the Resv message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. The generated ResvErr message MAY include an Acceptable Label Set, see Section 4.1. > >Ping, > >You make a good point. This discussion is about document organization. >Nothing earth shattering. This would not be important except that >in some ways the world has changed. > >No longer do we have only a handful of implementations >of a particular protocol - all being done by folks who work >in 2 or 3 companies. Protocols are being implemented by >an increasing number of companies with development in many parts >of the world other than North America. > >Having well organized content simply makes lives easier for >future developers. In this particular case, it also has clear >implications on $ and code creep - see my previous email. > >Ideally, the Hitless Restart content & Unnumbered Links content >should have remained separate content applicable to MPLS. >Otherwise the next best compromise is an applicability >statement draft. > >Best, >Nabil > >Ping Pan wrote: > > > > Hmmm... have to bite now. Who is confused here? The carriers? Don't > > think so. They know exactly which feature to have in their networks. The > > developers? Don't think so either. They know what can and cannot be > > implemented. So if we have enough solutions floating around in various > > drafts and RFC's. Why write more document? > > > > - Ping _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From owner-mpls@UU.NET Mon Nov 25 17:09:53 2002 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 ESMTP id RAA28411 for ; Mon, 25 Nov 2002 17:09:52 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqoe06288 for ; Mon, 25 Nov 2002 22:12:34 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqoe04698; Mon, 25 Nov 2002 22:11:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqoe09786 for mpls-outgoing; Mon, 25 Nov 2002 22:11:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqoe09767 for ; Mon, 25 Nov 2002 22:11: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 QQnqoe00360 for ; Mon, 25 Nov 2002 22:10:52 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqoe14842 for ; Mon, 25 Nov 2002 22:10:52 GMT Received: from ctc.cl by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [200.29.39.105]) id QQnqoe14820 for ; Mon, 25 Nov 2002 22:10:51 GMT Received: from SmtpHost-01.ctc.cl by ctc.cl (SMI-8.6/SMI-SVR4) id TAA20522; Mon, 25 Nov 2002 19:08:22 -0300 Subject: TDP to LDP on a MPLS Network To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Luis Abello Daza/GSIS-01/CTC" Date: Mon, 25 Nov 2002 17:52:38 -0400 X-MIMETrack: Serialize by Router on SmtpHost-01/SRV/CTC(Release 5.0.6a |January 17, 2001) at 11/25/2002 07:09:57 PM 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 RAA28411 Hi everyone, Does one of you have any experience performing a change from TDP to LDP on a MPLS network?. Please correct me if I´m wrong. TDP or LDP will work only on the interfaces (between them) were it is configured so the network could work with boths, TDP and LDP. grettings LAD From owner-mpls@UU.NET Mon Nov 25 17:15:37 2002 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 ESMTP id RAA28609 for ; Mon, 25 Nov 2002 17:15:37 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqof27817 for ; Mon, 25 Nov 2002 22:18:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqof25302; Mon, 25 Nov 2002 22:16:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqof10638 for mpls-outgoing; Mon, 25 Nov 2002 22:16:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqof10627 for ; Mon, 25 Nov 2002 22:16:35 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 QQnqof18773 for ; Mon, 25 Nov 2002 22:16:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqof13816 for ; Mon, 25 Nov 2002 22:16:11 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqof13782 for ; Mon, 25 Nov 2002 22:16:11 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA15125 for ; Mon, 25 Nov 2002 17:16:10 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAPMGAe07979 for mpls@uu.net; Mon, 25 Nov 2002 17:16:10 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqof10171 for ; Mon, 25 Nov 2002 22:15:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqoe22066 for ; Mon, 25 Nov 2002 22:14:50 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqoe16947 for ; Mon, 25 Nov 2002 22:14:50 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.150.1.230]) id QQnqoe16914 for ; Mon, 25 Nov 2002 22:14: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 RAA35520; Mon, 25 Nov 2002 17:15:50 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200211252215.RAA35520@workhorse.fictitious.org> To: "Sandeep B" cc: nseddigh@tropicnetworks.com, pingpan@cs.columbia.edu, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: GMPLS features applicable to MPLS In-reply-to: Your message of "Mon, 25 Nov 2002 21:12:35 GMT." Date: Mon, 25 Nov 2002 17:15:50 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , "Sandeep B" writes: > There are few other things - e.g. L3PID. GMPLS explicitly defines that for > Lsps that carry a certain type of traffic it needs to signal that using GPID > e.g IP lsp should set certain GPID and L2VPN-MPLS lsps a certain other GPID. > But there is no such defination in classic RSVP-TE. Such a case what should > be the criteria. Do we follow GMPLS RSVP-TE or classic?? > > Particular to this question - Do we have finally decided what should L2VPN > lsps signal as their L3PID???? > > http://cell.onecall.net/mhonarc/mpls/2002-Apr/msg00163.html > > > > GMPLS def ==>> > > The G-PID parameter is normally only examined at the egress. If the > indicated G-PID cannot be supported then the egress MUST generate a > PathErr message, with a "Routing problem/Unsupported L3PID" > indication. In the case of PSC and when penultimate hop popping > (PHP) is requested, the penultimate hop also examines the (stored) G- > PID during the processing of the Resv message. In this case if the > G-PID is not supported, then the penultimate hop MUST generate a > ResvErr message with a "Routing problem/Unacceptable label value" > indication. The generated ResvErr message MAY include an Acceptable > Label Set, see Section 4.1. Look at L3PID in rfc3209.txt L3PID an identifier of the layer 3 protocol using this path. Standard Ethertype values are used. Curtis From owner-mpls@UU.NET Mon Nov 25 17:27:24 2002 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 ESMTP id RAA28916 for ; Mon, 25 Nov 2002 17:27:24 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqog03500 for ; Mon, 25 Nov 2002 22:30:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqof01214; Mon, 25 Nov 2002 22:29:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqof11376 for mpls-outgoing; Mon, 25 Nov 2002 22:28:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqof11368 for ; Mon, 25 Nov 2002 22:28:18 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 QQnqof07711 for ; Mon, 25 Nov 2002 22:27:45 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqof09280 for ; Mon, 25 Nov 2002 22:27:44 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQnqof09276 for ; Mon, 25 Nov 2002 22:27:44 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gAPMRiS09875; Mon, 25 Nov 2002 14:27:44 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id gAPMRiP61551; Mon, 25 Nov 2002 14:27:44 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 25 Nov 2002 14:27:44 -0800 (PST) From: Kireeti Kompella To: Nabil Seddigh cc: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS In-Reply-To: <3DDD1235.6834F38D@tropicnetworks.com> Message-ID: <20021125141550.F61470-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Nabil, On Thu, 21 Nov 2002, Nabil Seddigh wrote: > This is an excellent point that must surely be a source of concern > to many! It is certainly an issue that has been raised before on > this mailing list. > > For various reasons, the authors did not wish to undertake > the effort required to change the current drafts. There is an infinitude of ways that people can misunderstand, misinterpret and misimplement specs. There isn't enough time to set everyone straight. Besides which, the drafts are fine; what *might* be needed is an applicability statement. > Unnumbered links & graceful restart are not specific to gmpls Can you explain to me "specific to Generalized MPLS"? If you do, I will write the applicability statement myself :-) > and I never understood the rational for rolling them into > the gmpls drafts. IMHO, it is better to remove the content in > 2 separate drafts. Unnumbered *is* a separate draft! (... as is LSP hierarchy, before someone says that hierarchy is specific to GMPLS.) > However, if this is too much work for the authors at this > point then approach of an "MPLS-applicable" section in the > GMPLS drafts may be a suitable compromise. Authors tend to get so into their work that they cannot always see that some topics are confusing. It is then up to *someone else* with a *new* point of view to write the app statement (not the authors), especially when the authors themselves think such statements are not needed. Kireeti. From owner-mpls@UU.NET Mon Nov 25 18:04:23 2002 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 ESMTP id RAA28412 for ; Mon, 25 Nov 2002 17:09:53 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqoe17405 for ; Mon, 25 Nov 2002 22:12:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqoe15438; Mon, 25 Nov 2002 22:11:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqoe09604 for mpls-outgoing; Mon, 25 Nov 2002 22:11:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqoe09557 for ; Mon, 25 Nov 2002 22:10:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqoe08400 for ; Mon, 25 Nov 2002 22:10:08 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqoe02259 for ; Mon, 25 Nov 2002 22:10:08 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqoe02211 for ; Mon, 25 Nov 2002 22:10:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA14602 for ; Mon, 25 Nov 2002 17:10:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAPMA5b07462 for mpls@uu.net; Mon, 25 Nov 2002 17:10:05 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqoe08795 for ; Mon, 25 Nov 2002 22:09:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnqoe27393 for ; Mon, 25 Nov 2002 22:08:20 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqoe11743 for ; Mon, 25 Nov 2002 22:08:19 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQnqoe11729 for ; Mon, 25 Nov 2002 22:08:18 GMT Received: from JVASSEUR-W2K.cisco.com (che-vpn-cluster-1-49.cisco.com [10.86.240.49]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA15227; Mon, 25 Nov 2002 23:08:16 +0100 (MET) Message-Id: <4.3.2.7.2.20021125145703.0601ffe0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Nov 2002 15:08:09 -0700 To: chopin.he@bigfoot.com From: Jean Philippe Vasseur Subject: Re: "Path Computation Server" Definition and Functionality Description Cc: mpls@UU.NET In-Reply-To: <3DE26007.6060109@bigfoot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, At 19:38 25/11/2002 +0200, Chopin He wrote: >Hi! folks! > >I hope this is the right place to ask this stupid MPLS question. > >I read couple of I-Ds mentioning "Path Computation Server", But I am a bit >unclear about its definition and functionality. > >So far, PCS is mentioned in many documents [1][2][3][4][5], one example of >its definition is found as:[1] > > "PCS: Path Computation Server (may be any kind of LSR (ABR, ASBR, ...) > or a centralized path computation server " > >This is quite a detailed explaination, but I understand the LSR or ABR or >ASBR are control plane components; while the centralised path computaton >server is a management plane component. In some case, (e.g. network >management), their roles are lardgely different. Is that possible to >define them seperately? > > >Additionaly, it seems to me that PCS's functionality is to response the >PCC's Path Computation Request, thus compute the path, and send the result >back to PCC. This sounds perfect. While I am still a bit unclear. What >kind of information the PCS need to know? How can the PCS get the relevant >information? And so on. > >E.g. Brunner said in [3]: > "Definitely the path computation server needs topology information in > order to perform its task. But how to get that information is out of > scope of this document. " > >I wonder if there are some specification which defines the PCS's >functionality explicitly? > >If not, can somebody take the initiative? > The PCS's role is to compute TE LSP path for which it is not the HE. Basically, the PCS needs: - to get information about the topology, the TE resources, .... This can be done in several ways: downloading those informations from a router using a Telnet session, having a routing adjacency with a router, ... - some algorithm(s) to perform TE LSP path computation, - to provide the computed TE LSP path to the PCC (routers) using Telnet, a signalling protocol (Ex: [1]) Example 1: PCS= a UNIX station being able to receive request from routers to compute TE LSP path for primary TE LSP placement, inter-area TE LSPs, non packet TE LSP paths, bypass tunnel path computation, ... Example 2: PCS= an ABR (scenario 2 or 4 of draft http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt)) for inter-area TE LSP path computation, Example 3: any router is a PCS to compute the bypass tunnel(s) path for each of its neighbors to their respective (N)NHOP(s) LSRs. See the distributed bypass tunnel path computation scenario of http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-01.txt JP. >Thanks for your time to read this mail. > > > >Best wishes! > > >-- >Chopin > > > >[1] Vasseur JP, et al., "RSVP Path computation request and reply >messages", , IETF work in >progress, Jun 2002. > >[2] JP Vasseur, "IS-IS Path Computation Server discovery TLV", >, IETF work in progress, >June, 2002 > >[3] M. Brunner, " COPS usage for Path Computation Servers (COPS-PCS)", >, IETF work in progress, September, 2002 > >[4] JP Vasseur, Peter Psenak, "OSPF Path Computation Server discovery", >, IETF work in progress, >June, 2002 > >[5] JP Vasseur, Peter Psenak, "OSPF Traffic Engineering capability TLVs ", >, IETF work in progress, October, 2002 > > > > > From owner-mpls@UU.NET Tue Nov 26 08:19:19 2002 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 ESMTP id IAA00013 for ; Tue, 26 Nov 2002 08:19:19 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqqn26684 for ; Tue, 26 Nov 2002 13:22:01 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqqn23629; Tue, 26 Nov 2002 13:20:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqqn22811 for mpls-outgoing; Tue, 26 Nov 2002 13:20:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqqn22804 for ; Tue, 26 Nov 2002 13:20:25 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 QQnqqn19812 for ; Tue, 26 Nov 2002 13:20:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqqn22727 for ; Tue, 26 Nov 2002 13:20:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqqn22719 for ; Tue, 26 Nov 2002 13:20:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA29148 for ; Tue, 26 Nov 2002 08:20:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAQDK6g20361 for mpls@uu.net; Tue, 26 Nov 2002 08:20:06 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqqn22735 for ; Tue, 26 Nov 2002 13:18:39 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 QQnqqn03891 for ; Tue, 26 Nov 2002 13:17:20 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqqn20230 for ; Tue, 26 Nov 2002 13:17:20 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 QQnqqn20219 for ; Tue, 26 Nov 2002 13:17: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 IAA29632; Tue, 26 Nov 2002 08:14:36 -0500 (EST) Message-Id: <200211261314.IAA29632@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-cetin-mpls-diffserv-te-mib-00.txt Date: Tue, 26 Nov 2002 08:14:36 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for DiffServ Author(s) : R. Cetin Filename : draft-cetin-mpls-diffserv-te-mib-00.txt Pages : 20 Date : 2002-11-25 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for diffServ based Multiprotocol Label Switching (MPLS) Traffic Engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cetin-mpls-diffserv-te-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cetin-mpls-diffserv-te-mib-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-cetin-mpls-diffserv-te-mib-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: <2002-11-25134602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cetin-mpls-diffserv-te-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-cetin-mpls-diffserv-te-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-25134602.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Nov 26 09:59:28 2002 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 ESMTP id JAA04215 for ; Tue, 26 Nov 2002 09:59:28 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqqu26614 for ; Tue, 26 Nov 2002 15:02:07 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqqu24468; Tue, 26 Nov 2002 15:00:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqqu24302 for mpls-outgoing; Tue, 26 Nov 2002 15:00:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqqu23027 for ; Tue, 26 Nov 2002 15:00:20 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 QQnqqu20092 for ; Tue, 26 Nov 2002 15:00:08 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqqu09895 for ; Tue, 26 Nov 2002 15:00:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqqu09881 for ; Tue, 26 Nov 2002 15:00:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA06002 for ; Tue, 26 Nov 2002 10:00:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAQF06J25455 for mpls@uu.net; Tue, 26 Nov 2002 10:00:06 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqpu00227 for ; Tue, 26 Nov 2002 08:43: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 QQnqpu16121 for ; Tue, 26 Nov 2002 08:43:35 GMT From: Roberto.Guglielmi@alcatel.it Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqpu23571 for ; Tue, 26 Nov 2002 08:43:35 GMT Received: from tlvsca.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.243.74.245]) id QQnqpu23567 for ; Tue, 26 Nov 2002 08:43:34 GMT Received: from itmail02.prod.alcatel.it (localhost [127.0.0.1]) by tlvsca.vim.tlt.alcatel.it (8.12.5/8.12.5) with ESMTP id gAQ8hErt024416; Tue, 26 Nov 2002 09:43:15 +0100 (MET) Received: from alcatel.it ([151.98.36.75]) by itmail02.prod.alcatel.it (Lotus Domino Release 5.0.8) with ESMTP id 2002112609452765:834 ; Tue, 26 Nov 2002 09:45:27 +0100 Message-ID: <3DE332A9.1090800@alcatel.it> Date: Tue, 26 Nov 2002 09:36:57 +0100 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yuan Gu CC: mpls@UU.NET Subject: Re: TE MIB - LSR MIB integration References: X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/26/2002 09:45:27, Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/26/2002 09:45:30, Serialize complete at 11/26/2002 09:45:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Yuan, Thanks for your help. See my question at the end please. Yuan Gu wrote: >Hello, Roberto: > > > >>-----Original Message----- >>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >>Roberto.Guglielmi@alcatel.it >>Sent: Monday, November 25, 2002 3:19 AM >>To: mpls@UU.NET >>Subject: TE MIB - LSR MIB integration >> >> >>Hello everybody, >>I have a doubt about interactions between LSR MIB and TE MIB for what >>concerning LSPs nested in TE tunnels. >>Consider the following scenario: >> >>R1 -------- R2 -------- R3 >> >>and suppose, for example, I have three incoming flows. I want to insert >>each flow in one LSP and tunnel the three LSPs in one TE tunnel. >>My questions are: >> >>1) How are the three LSPs mapped on the same TE tunnel? >> >> > >There will be 3 entries in mplsTunnelTable. Each entry has different >mplsTuunnelInstance. > >The mplsTunnelInstance "Uniquely identifies an instance of a tunnel. It is >useful to identify multiple instances of tunnels for the purposes of backup >and parallel tunnels." >You may want to put your LSPID into this field. > > > >>2) Is there only one entry in the mplsTunnelTable pointing to one entry >>in the mplsXCTable? >> >> > >There will be 3 corresponding entries in mplsXCTable. Each entry has >different mplsXCLspId (RSVP-TE or CR-LDP). > > > > > Suppose I have three incoming Ethernet TLS flows on R1. Following Martini's draft, I should encapsulate Ethernet frames with a stack of two labels: the bottom label being the VC label, while the top label being the tunnel label. In other words, R1 has to push two labels on every incoming frame where the one at the top is always the same. I suppose each entry in mplsXCTable should point to a not null mplsLabelStackTable containing the corresponding VC label. If the tunnel label is set up by means of RSVP-TE and the VC label by means of LDP, how does R1 decides that the VC label has to be put in the mplsLabelStackTable and not in a new separate entry in mplsXCTable? What information of the RSVP messages are used to accomplish this? Regards Roberto From owner-mpls@UU.NET Tue Nov 26 12:27:17 2002 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 ESMTP id MAA12155 for ; Tue, 26 Nov 2002 12:27:17 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqrd28457 for ; Tue, 26 Nov 2002 17:29:57 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqrd27308; Tue, 26 Nov 2002 17:29:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqrd28954 for mpls-outgoing; Tue, 26 Nov 2002 17:28:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqrd28947 for ; Tue, 26 Nov 2002 17:28:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnqrd22860 for ; Tue, 26 Nov 2002 17:28:21 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqrd21840 for ; Tue, 26 Nov 2002 17:28:20 GMT Received: from exchange.tropicnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ottgw.tropicnetworks.com [209.202.99.50]) id QQnqrd21828 for ; Tue, 26 Nov 2002 17:28:20 GMT Received: from tropicnetworks.com ([10.3.0.81]) by exchange.tropicnetworks.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 26 Nov 2002 12:28:19 -0500 Message-ID: <3DE3AF33.6640FF29@tropicnetworks.com> Date: Tue, 26 Nov 2002 12:28:19 -0500 From: Nabil Seddigh Organization: Tropic Networks X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: IETF MPLS List Subject: Re: GMPLS features applicable to MPLS References: <20021125141550.F61470-100000@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2002 17:28:19.0753 (UTC) FILETIME=[3678E190:01C29571] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kireeti, > > Can you explain to me "specific to Generalized MPLS"? If you do, > I will write the applicability statement myself :-) I replied to this in a previous post and I think others on this thread essentially said the samething. Box & stack vendors typically like to implement all of a draft. It is much easier and more interoperable than picking and choosing sections from a variety of drafts. As for an applicability draft, the thoughts are clear in my head even if it is not being expressed clearly via email. If there is interest, I could put something together. There's a lot of new spec (objects & behavious) in the gmpls drafts (functional & signaling) that many plain router vendors or router stack vendors would not implement - ie no desire to configure optics or tdm via signalling. Yet the unnumbered link & hitless restart features may be of interest to such vendors. It would be nice if they didn't have to wade through GMPLS docs too extract this info. > > > and I never understood the rational for rolling them into > > the gmpls drafts. IMHO, it is better to remove the content in > > 2 separate drafts. > > Unnumbered *is* a separate draft! (... as is LSP hierarchy, > before someone says that hierarchy is specific to GMPLS.) True enough. However, part of section 9.1 of http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-09.txt contains content that's not in the unnum draft and which would be incorporated by someone implementing the unnum draft. Best, Nabil From owner-mpls@UU.NET Tue Nov 26 14:51:30 2002 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 ESMTP id OAA17975 for ; Tue, 26 Nov 2002 14:51:30 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqrn13451 for ; Tue, 26 Nov 2002 19:54:10 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqrn11684; Tue, 26 Nov 2002 19:53:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqrn17180 for mpls-outgoing; Tue, 26 Nov 2002 19:53:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqrn17170 for ; Tue, 26 Nov 2002 19:52:58 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 QQnqrn07164 for ; Tue, 26 Nov 2002 19:52:56 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqrn11075 for ; Tue, 26 Nov 2002 19:52:56 GMT Received: from gateway.ipinfusion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnqrn11060 for ; Tue, 26 Nov 2002 19:52:55 GMT Received: from YuanHong (dhcp127.ipinfusion.com [10.10.0.127] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with SMTP id gAQJqAa31885; Tue, 26 Nov 2002 11:52:10 -0800 From: "Yuan Gu" To: Cc: Subject: RE: TE MIB - LSR MIB integration Date: Tue, 26 Nov 2002 11:52:21 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3DE332A9.1090800@alcatel.it> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Suppose I have three incoming Ethernet TLS flows on R1. Following > Martini's draft, I should encapsulate Ethernet frames with a > stack of two labels: the bottom label being the VC label, while > the top label being the tunnel label. In other words, R1 has to > push two labels on every incoming frame where the one at the top > is always the same. > I suppose each entry in mplsXCTable should point to a not null > mplsLabelStackTable containing the corresponding VC label. If the > tunnel label is set up by means of RSVP-TE and the VC label by > means of LDP, how does R1 decides that the VC label has to be put > in the mplsLabelStackTable and not in a new separate entry in > mplsXCTable? What information of the RSVP messages are used to > accomplish this? > > Regards Roberto > I don't think the LSR MIB take L2VPN into account at all. You may want to implement your propertory MIB for supporting L2VPN. From owner-mpls@UU.NET Tue Nov 26 15:38:09 2002 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 ESMTP id PAA19565 for ; Tue, 26 Nov 2002 15:38:09 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqrq02529 for ; Tue, 26 Nov 2002 20:40:47 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqrq29496; Tue, 26 Nov 2002 20:39:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqrq08362 for mpls-outgoing; Tue, 26 Nov 2002 20:38:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqrq08357 for ; Tue, 26 Nov 2002 20:38:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnqrq03423 for ; Tue, 26 Nov 2002 20:38:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqrq28272 for ; Tue, 26 Nov 2002 20:38:07 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqrq28262 for ; Tue, 26 Nov 2002 20:38:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA08278 for ; Tue, 26 Nov 2002 15:38:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAQKc6c14706 for mpls@uu.net; Tue, 26 Nov 2002 15:38:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqrq08296 for ; Tue, 26 Nov 2002 20:36: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 QQnqrq11858 for ; Tue, 26 Nov 2002 20:36:35 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqrq27445 for ; Tue, 26 Nov 2002 20:36:35 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnqrq27438 for ; Tue, 26 Nov 2002 20:36:34 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAQKaoI7010068; Tue, 26 Nov 2002 15:36:51 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-1-2.cisco.com [10.86.240.2]) by bucket.cisco.com (Mirapoint) with ESMTP id ACE46449; Tue, 26 Nov 2002 15:36:24 -0500 (EST) Message-Id: <5.2.0.9.2.20021126153414.02dc7578@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 26 Nov 2002 15:36:21 -0500 To: "Yuan Gu" From: "Thomas D. Nadeau" Subject: RE: TE MIB - LSR MIB integration Cc: , In-Reply-To: References: <3DE332A9.1090800@alcatel.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:52 AM 11/26/2002 -0800, Yuan Gu wrote: > > Suppose I have three incoming Ethernet TLS flows on R1. Following > > Martini's draft, I should encapsulate Ethernet frames with a > > stack of two labels: the bottom label being the VC label, while > > the top label being the tunnel label. In other words, R1 has to > > push two labels on every incoming frame where the one at the top > > is always the same. > > I suppose each entry in mplsXCTable should point to a not null > > mplsLabelStackTable containing the corresponding VC label. If the > > tunnel label is set up by means of RSVP-TE and the VC label by > > means of LDP, how does R1 decides that the VC label has to be put > > in the mplsLabelStackTable and not in a new separate entry in > > mplsXCTable? What information of the RSVP messages are used to > > accomplish this? > > > > Regards Roberto > > > >I don't think the LSR MIB take L2VPN into account at all. You may want to >implement your propertory MIB for supporting L2VPN. The LSR MIB shows the LFIB and MPLS-enabled interfaces of an LSR. If you can represent labels (or label stacks) in an LFIB, you can see it there. If you want to attach application- specific things to entries in the TFIB, you need application-specific MIBs such as the PWE-MPLS MIB that joins pwe3 vcs of any service type to MPLS LSPs (or TE tunnels). --Tom From owner-mpls@UU.NET Tue Nov 26 19:29:07 2002 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 ESMTP id TAA28271 for ; Tue, 26 Nov 2002 19:29:07 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqsg15099 for ; Wed, 27 Nov 2002 00:31:49 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqsg14170; Wed, 27 Nov 2002 00:31:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqsg10223 for mpls-outgoing; Wed, 27 Nov 2002 00:30:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqsg10218 for ; Wed, 27 Nov 2002 00:30:39 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 QQnqsg22091 for ; Wed, 27 Nov 2002 00:30:34 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqsg27049 for ; Wed, 27 Nov 2002 00:30:34 GMT Received: from excalibur.santera.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnqsg27044 for ; Wed, 27 Nov 2002 00:30:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: TE MIB - LSR MIB integration Date: Tue, 26 Nov 2002 18:30:30 -0600 Message-ID: Thread-Topic: TE MIB - LSR MIB integration Thread-Index: AcKUv4cSOI8UxOd9Romw9c8CHaxi4AA6ABaw From: "Zhu, Rupert" To: "Yuan Gu" , , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA28271 Roberto, Yuan: Interesting scenario. I agree on Yuan's approach, if you insist on mapping the 3 LSPs into one TE tunnel. However, why should we choose to map the 3 LSPs to the same tunnel? The application described is to have 3 flows carried in 3 LSPs, respectively. Since there is no logical relationships between the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more appropriate to model them as 3 independent entities. Alternative Solution #1: Map to 3 LSPs directly. -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). Have each mplsFTNActionType=redirectLSP. Have each mplsFTNActionPointer pointing to one of the 3 mplsXCEntry. Alternative Solution #2: Map to 3 tunnels (instead of one). -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). -- Populate 3 entries in mplsTunnelTable, each representing a distinct (logical) tunnel. (That is, they have different values in mplsTunnelIndex.) -- Have each mplsFTNActionType=redirectTunnel. Have each mplsFTNActionPointer pointing to one of the 3 mplsTunnelEntry. In other words, if there is no relationship between the 3 LSPs, then they do not belong to the same TE tunnel. My two cents. -- Rupert > -----Original Message----- > From: Yuan Gu [mailto:yuangu@ipinfusion.com] > Sent: Monday, November 25, 2002 2:12 PM > To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET > Subject: RE: TE MIB - LSR MIB integration > > > Hello, Roberto: > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > Roberto.Guglielmi@alcatel.it > > Sent: Monday, November 25, 2002 3:19 AM > > To: mpls@UU.NET > > Subject: TE MIB - LSR MIB integration > > > > > > Hello everybody, > > I have a doubt about interactions between LSR MIB and TE > MIB for what > > concerning LSPs nested in TE tunnels. > > Consider the following scenario: > > > > R1 -------- R2 -------- R3 > > > > and suppose, for example, I have three incoming flows. I > want to insert > > each flow in one LSP and tunnel the three LSPs in one TE tunnel. > > My questions are: > > > > 1) How are the three LSPs mapped on the same TE tunnel? > > There will be 3 entries in mplsTunnelTable. Each entry has different > mplsTuunnelInstance. > > The mplsTunnelInstance "Uniquely identifies an instance of a > tunnel. It is > useful to identify multiple instances of tunnels for the > purposes of backup > and parallel tunnels." > You may want to put your LSPID into this field. > > > > > 2) Is there only one entry in the mplsTunnelTable pointing > to one entry > > in the mplsXCTable? > > There will be 3 corresponding entries in mplsXCTable. Each entry has > different mplsXCLspId (RSVP-TE or CR-LDP). > > > From owner-mpls@UU.NET Tue Nov 26 21:28:58 2002 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 ESMTP id VAA02033 for ; Tue, 26 Nov 2002 21:28:58 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqso20692 for ; Wed, 27 Nov 2002 02:31:40 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqso19505; Wed, 27 Nov 2002 02:31:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqso26934 for mpls-outgoing; Wed, 27 Nov 2002 02:30:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqso26844 for ; Wed, 27 Nov 2002 02:30:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqsn04706 for ; Wed, 27 Nov 2002 02:28:49 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqsn08873 for ; Wed, 27 Nov 2002 02:28:49 GMT Received: from gateway.ipinfusion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.ipinfusion.com [65.223.109.2]) id QQnqsn08868 for ; Wed, 27 Nov 2002 02:28:49 GMT Received: from YuanHong (dhcp127.ipinfusion.com [10.10.0.127] (may be forged)) by gateway.ipinfusion.com (8.11.6/8.11.6) with SMTP id gAR2Rla12849; Tue, 26 Nov 2002 18:27:47 -0800 From: "Yuan Gu" To: , "Thomas D. Nadeau" , , , Cc: "mpls group" Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt Date: Tue, 26 Nov 2002 18:27:57 -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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3.0.1.32.20021021101808.007213b4@pop.mindspring.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Joan: Do you have any result of your discussion? Regards! Yuan > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Monday, October 21, 2002 7:18 AM > To: Yuan Gu; Thomas D. Nadeau; cheenu@paramanet.com; > arun@force10networks.com; hans@ipunplugged.com > Cc: mpls group > Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt > > > > Hi Yuan, > > I will take your suggestion and discuss it > with the co-authors of the LSR MIB. > > Thanks, Joan > > > At 12:22 PM 10/18/02 -0700, Yuan Gu wrote: > >Joan: > > > >Thanks for you reply. > > > >For LspID which is defined in XC table, it's still worth to have > it because > >some vendors might not support TE mib and want to show which LSP > makes the > >cross connection. The problem is that the current MplsLSPId > definition can't > >uniquely identify an LSP for RSVP-TE case. Then, we need to > extend MplsLSPId > >concept to make it not limited by lspid defined in SenderTemple > of RFC3209. > >For RSVP-TE case, I believe we can define MplsLSPId as > >ingressLSRID+egressLSRID+tunnelid+lspid (similar as CRLDP definition). By > >this way, LSR mib will have a unique identification of LSP which makes > >insegment, XC and outsegment entries. > > > >Please let me know your thought. > > > >Regards! > >Yuan > > > >-----Original Message----- > >From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > >Sent: Friday, October 18, 2002 11:59 AM > >To: Yuan Gu; Thomas D. Nadeau; cheenu@paramanet.com; > >arun@force10networks.com; hans@ipunplugged.com > >Cc: mpls group > >Subject: RE: FW: I-D ACTION:draft-ietf-mpls-tc-mib-04.txt > > > > > > > >Hi Yuan, > > > >At 01:56 PM 10/17/02 -0700, Yuan Gu wrote: > >> > >>>Although, it may be necessary to clarify this a tad, I don't > >>>believe there is a conflict. Perhaps, this description > >>>should simply state: > >>>For RSVP, the MplsLSPId is the "LSP ID" as defined in RFC3209. > >> > >>Then for RSVP-TE, what's the sense to define LSP ID in XC > table? This two > >>bytes LSPID can't identify an unique LSP. Don't need to mention transit > >>node, even within single ingress node it's not unique right? > >> > > > >Okay, I think I see your point. > >The object does allow an operator to configure the > >LSP-ID, (and show the LSPID in the transit situation). > >Also, this object is optional so doesn't need to be supported by > >the agent. > > > >Do you think this object is not worth having in this table at all, > >even optionally? > > > > Thanks, Joan > > > > > > > > > > > From owner-mpls@UU.NET Wed Nov 27 02:06:32 2002 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 ESMTP id CAA16632 for ; Wed, 27 Nov 2002 02:06:31 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqtg20381 for ; Wed, 27 Nov 2002 07:09:13 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqtg18818; Wed, 27 Nov 2002 07:08:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqtg19651 for mpls-outgoing; Wed, 27 Nov 2002 07:08:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqtg19631 for ; Wed, 27 Nov 2002 07:07: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 QQnqtg02557 for ; Wed, 27 Nov 2002 07:07:02 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqtg17994 for ; Wed, 27 Nov 2002 07:07:02 GMT Received: from ganesh.ctd.hctech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnqtg17959 for ; Wed, 27 Nov 2002 07:07:00 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 12:43:39 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06D65D71@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: "Zhu, Rupert" , Yuan Gu , Roberto.Guglielmi@alcatel.it, mpls@UU.NET Subject: RE: TE MIB - LSR MIB integration Date: Wed, 27 Nov 2002 12:39:13 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In this scenario there is only one TE tunnel , ie the outer tunnel across R1 to R3. Three vanilla LSPs use it to tunnel flows across R1 to R3. ( hope I understood the problem right). Hence , it would be appropriate to have 3 XC entries( pointed from their respective FTN entries) corresponding to each vanilla LSP with the tunnel label in their label stacks. Also, I think there should be only one tunnel entry corresponding to the TE tunnel. Thanks and Regards Vijay "Where protocols are a passion, MPLS is a religion " -----Original Message----- From: Zhu, Rupert [mailto:rupert.zhu@santera.com] Sent: Wednesday, November 27, 2002 6:01 AM To: Yuan Gu; Roberto.Guglielmi@alcatel.it; mpls@UU.NET Subject: RE: TE MIB - LSR MIB integration Roberto, Yuan: Interesting scenario. I agree on Yuan's approach, if you insist on mapping the 3 LSPs into one TE tunnel. However, why should we choose to map the 3 LSPs to the same tunnel? The application described is to have 3 flows carried in 3 LSPs, respectively. Since there is no logical relationships between the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more appropriate to model them as 3 independent entities. Alternative Solution #1: Map to 3 LSPs directly. -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). Have each mplsFTNActionType=redirectLSP. Have each mplsFTNActionPointer pointing to one of the 3 mplsXCEntry. Alternative Solution #2: Map to 3 tunnels (instead of one). -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). -- Populate 3 entries in mplsTunnelTable, each representing a distinct (logical) tunnel. (That is, they have different values in mplsTunnelIndex.) -- Have each mplsFTNActionType=redirectTunnel. Have each mplsFTNActionPointer pointing to one of the 3 mplsTunnelEntry. In other words, if there is no relationship between the 3 LSPs, then they do not belong to the same TE tunnel. My two cents. -- Rupert > -----Original Message----- > From: Yuan Gu [mailto:yuangu@ipinfusion.com] > Sent: Monday, November 25, 2002 2:12 PM > To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET > Subject: RE: TE MIB - LSR MIB integration > > > Hello, Roberto: > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > Roberto.Guglielmi@alcatel.it > > Sent: Monday, November 25, 2002 3:19 AM > > To: mpls@UU.NET > > Subject: TE MIB - LSR MIB integration > > > > > > Hello everybody, > > I have a doubt about interactions between LSR MIB and TE > MIB for what > > concerning LSPs nested in TE tunnels. > > Consider the following scenario: > > > > R1 -------- R2 -------- R3 > > > > and suppose, for example, I have three incoming flows. I > want to insert > > each flow in one LSP and tunnel the three LSPs in one TE tunnel. > > My questions are: > > > > 1) How are the three LSPs mapped on the same TE tunnel? > > There will be 3 entries in mplsTunnelTable. Each entry has different > mplsTuunnelInstance. > > The mplsTunnelInstance "Uniquely identifies an instance of a > tunnel. It is > useful to identify multiple instances of tunnels for the > purposes of backup > and parallel tunnels." > You may want to put your LSPID into this field. > > > > > 2) Is there only one entry in the mplsTunnelTable pointing > to one entry > > in the mplsXCTable? > > There will be 3 corresponding entries in mplsXCTable. Each entry has > different mplsXCLspId (RSVP-TE or CR-LDP). > > > From owner-mpls@UU.NET Wed Nov 27 04:53:23 2002 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 ESMTP id EAA04723 for ; Wed, 27 Nov 2002 04:53:23 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqtr00317 for ; Wed, 27 Nov 2002 09:56:04 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqtr28872; Wed, 27 Nov 2002 09:55:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqtr09622 for mpls-outgoing; Wed, 27 Nov 2002 09:55:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqtr09617 for ; Wed, 27 Nov 2002 09:55:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqtr21473 for ; Wed, 27 Nov 2002 09:54:43 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqtr26260 for ; Wed, 27 Nov 2002 09:54:43 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnqtr26236 for ; Wed, 27 Nov 2002 09:54:41 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Nov 2002 15:31:19 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06D6605C@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: Roberto.Guglielmi@alcatel.it Cc: mpls@UU.NET Subject: RE: TE MIB - LSR MIB integration Date: Wed, 27 Nov 2002 15:26:25 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The label stack and top label arrangements are as usual , as you said. Reg. the TE tunnel entry - I would imagine its going to have an associated XC entry ,which has associated outsegment, FTN etc. and would be able to carry traffic directly( not just as a tunnel for other LSPs). Multiple LSPs may be using this TE tunnel entry, since they would be holding the TE tunnel label as their top label in their outsegments. Thanks and Regards Vijay "Where protocols are a passion, MPLS is a religion " -----Original Message----- From: Roberto.Guglielmi@alcatel.it [mailto:Roberto.Guglielmi@alcatel.it] Sent: Wednesday, November 27, 2002 1:49 PM To: Vijayanand C - CTD, Chennai.; Zhu, Rupert; Yuan Gu Cc: mpls@UU.NET Subject: Re: TE MIB - LSR MIB integration Yuan,Rupert and Vijayanand thanks for your replies. Please see my comments inline. - Roberto Vijayanand C - CTD, Chennai. wrote: >In this scenario there is only one TE tunnel , ie the outer tunnel across R1 >to R3. Three vanilla LSPs use it to tunnel flows across R1 to R3. ( hope I >understood the problem right). > You understood right. > >Hence , it would be appropriate to have 3 XC entries( pointed from their >respective FTN entries) corresponding to each vanilla LSP with the tunnel >label in their label stacks. > So, the tunnel label in the mplsOutSegmentTable and the bottom label in the mplsLabelStackTable? > >Also, I think there should be only one tunnel entry corresponding to the TE >tunnel. > Which table points to this tunnel entry? Where does this tunnel entry point to? > >Thanks and Regards >Vijay > >"Where protocols are a passion, MPLS is a religion " > >-----Original Message----- >From: Zhu, Rupert [mailto:rupert.zhu@santera.com] >Sent: Wednesday, November 27, 2002 6:01 AM >To: Yuan Gu; Roberto.Guglielmi@alcatel.it; mpls@UU.NET >Subject: RE: TE MIB - LSR MIB integration > > >Roberto, Yuan: > >Interesting scenario. I agree on Yuan's approach, if you >insist on mapping the 3 LSPs into one TE tunnel. >However, why should we choose to map the 3 LSPs to >the same tunnel? > The incoming flows are Ethernet TLS flow traversing an intervening MPLS network. The typical scenario is to assign each of the flows entering and leaving the MPLS network from the same end points, with a VC label (following Martini's draft) and encapsulate all the obtained LSPs into one TE tunnel, in order to offer the different clients the same service. > >The application described is to have 3 flows carried in 3 LSPs, >respectively. Since there is no logical relationships between >the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more >appropriate to model them as 3 independent entities. > >Alternative Solution #1: Map to 3 LSPs directly. > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > Have each mplsFTNActionType=redirectLSP. > Have each mplsFTNActionPointer pointing to one > of the 3 mplsXCEntry. > The classification is achieved using the pwe MIBs. The VC label is kept in the MPLS world, not in the pwe world. > >Alternative Solution #2: Map to 3 tunnels (instead of one). > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > -- Populate 3 entries in mplsTunnelTable, each representing > a distinct (logical) tunnel. (That is, they have different > values in mplsTunnelIndex.) > -- Have each mplsFTNActionType=redirectTunnel. > Have each mplsFTNActionPointer pointing to one of > the 3 mplsTunnelEntry. > >In other words, if there is no relationship between the 3 LSPs, >then they do not belong to the same TE tunnel. > >My two cents. > >-- Rupert > > > > >>-----Original Message----- >>From: Yuan Gu [mailto:yuangu@ipinfusion.com] >>Sent: Monday, November 25, 2002 2:12 PM >>To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET >>Subject: RE: TE MIB - LSR MIB integration >> >> >>Hello, Roberto: >> >> >> >>>-----Original Message----- >>>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >>>Roberto.Guglielmi@alcatel.it >>>Sent: Monday, November 25, 2002 3:19 AM >>>To: mpls@UU.NET >>>Subject: TE MIB - LSR MIB integration >>> >>> >>>Hello everybody, >>>I have a doubt about interactions between LSR MIB and TE >>> >>> >>MIB for what >> >> >>>concerning LSPs nested in TE tunnels. >>>Consider the following scenario: >>> >>>R1 -------- R2 -------- R3 >>> >>>and suppose, for example, I have three incoming flows. I >>> >>> >>want to insert >> >> >>>each flow in one LSP and tunnel the three LSPs in one TE tunnel. >>>My questions are: >>> >>>1) How are the three LSPs mapped on the same TE tunnel? >>> >>> >>There will be 3 entries in mplsTunnelTable. Each entry has different >>mplsTuunnelInstance. >> >>The mplsTunnelInstance "Uniquely identifies an instance of a >>tunnel. It is >>useful to identify multiple instances of tunnels for the >>purposes of backup >>and parallel tunnels." >>You may want to put your LSPID into this field. >> >> >> >>>2) Is there only one entry in the mplsTunnelTable pointing >>> >>> >>to one entry >> >> >>>in the mplsXCTable? >>> >>> >>There will be 3 corresponding entries in mplsXCTable. Each entry has >>different mplsXCLspId (RSVP-TE or CR-LDP). >> >> >> I understand your point of view. In my opinion, the 3 entries in mplsXCTable should have the tunnel label in the mplsOutSegmentTable and the bottom label in the mplsLabelStackTable. Do you agree? If not, where the 2 labels are indicated for each flow? >> >> >> > > > From owner-mpls@UU.NET Wed Nov 27 05:19:38 2002 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 ESMTP id FAA05013 for ; Wed, 27 Nov 2002 05:19:37 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqtt22543 for ; Wed, 27 Nov 2002 10:22:16 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqtt19914; Wed, 27 Nov 2002 10:20:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqtt00045 for mpls-outgoing; Wed, 27 Nov 2002 10:20:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqtt00040 for ; Wed, 27 Nov 2002 10:20:25 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 QQnqtt15019 for ; Wed, 27 Nov 2002 10:20:06 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqtt25121 for ; Wed, 27 Nov 2002 10:20:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqtt25104 for ; Wed, 27 Nov 2002 10:20:05 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA24121 for ; Wed, 27 Nov 2002 05:20:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gARAK5C24862 for mpls@uu.net; Wed, 27 Nov 2002 05:20:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqtt29985 for ; Wed, 27 Nov 2002 10:19:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqtt26391 for ; Wed, 27 Nov 2002 10:18:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqtt17882 for ; Wed, 27 Nov 2002 10:18:30 GMT Received: from bru-cse-118.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: bru-cse-118.cisco.com [144.254.9.40]) id QQnqtt17868 for ; Wed, 27 Nov 2002 10:18:29 GMT Received: (from ldeghein@localhost) by bru-cse-118.cisco.com (8.11.6+Sun/CA/950118) id gARAGE027257; Wed, 27 Nov 2002 11:16:14 +0100 (CET) Date: Wed, 27 Nov 2002 11:16:14 +0100 (CET) From: Luc De Ghein Message-Id: <200211271016.gARAGE027257@bru-cse-118.cisco.com> To: labello@ctc.cl Subject: Re: TDP to LDP on a MPLS Network Cc: mpls@UU.NET X-Sun-Charset: ISO-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk LAD, > Hi everyone, > > > Does one of you have any experience performing a change from TDP to LDP on > a MPLS network?. Please correct me if I´m wrong. TDP or LDP will work only > on the interfaces (between them) were it is configured so the network could > work with boths, TDP and LDP. Yes, the network will work with both TDP and LDP. You move from TDP to LDP between a pair of routers, not per link. I.e., when having two links between a pair of routers, you cannot have one link with TDP and one link with LDP configured. Luc > grettings > LAD From owner-mpls@UU.NET Wed Nov 27 06:33:04 2002 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 ESMTP id GAA06156 for ; Wed, 27 Nov 2002 06:33:04 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqty09180 for ; Wed, 27 Nov 2002 11:35:38 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqty07288; Wed, 27 Nov 2002 11:34:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqty23851 for mpls-outgoing; Wed, 27 Nov 2002 11:34:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqty23846 for ; Wed, 27 Nov 2002 11:34: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 QQnqty29903 for ; Wed, 27 Nov 2002 11:33:20 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqty06339 for ; Wed, 27 Nov 2002 11:33:20 GMT Received: from tokyo.ccrle.nec.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQnqty06326 for ; Wed, 27 Nov 2002 11:33:19 GMT Received: from imap.heidelberg.ccrle.nec.de (imap [192.168.102.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id gARBWsY25287; Wed, 27 Nov 2002 12:32:54 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C65CF3CC9B; Wed, 27 Nov 2002 12:31:15 +0100 (CET) Date: Wed, 27 Nov 2002 12:31:16 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Jean Philippe Vasseur , chopin.he@bigfoot.com Cc: mpls@UU.NET Subject: Re: "Path Computation Server" Definition and Functionality Description Message-ID: <5787602.1038400276@[192.168.102.207]> In-Reply-To: <4.3.2.7.2.20021125145703.0601ffe0@paris.cisco.com> References: <4.3.2.7.2.20021125145703.0601ffe0@paris.cisco.com> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit As Jean Philippe has meantioned there are a number of ways how to get the required information to a central place, therefore is is pretty solution/implementation specific and therefore should not be standardized. The information you need heavily depends on the algorithm you want to run in the PCS. The algorithm on the other hand might depend on the type of service request (currently this naturally out-of-scope of the WG) Marcus --On Montag, 25. November 2002 15:08 -0700 Jean Philippe Vasseur wrote: > Hi, > > At 19:38 25/11/2002 +0200, Chopin He wrote: >> Hi! folks! >> >> I hope this is the right place to ask this stupid MPLS question. >> >> I read couple of I-Ds mentioning "Path Computation Server", But I am a >> bit unclear about its definition and functionality. >> >> So far, PCS is mentioned in many documents [1][2][3][4][5], one example >> of its definition is found as:[1] >> >> "PCS: Path Computation Server (may be any kind of LSR (ABR, ASBR, ...) >> or a centralized path computation server " >> >> This is quite a detailed explaination, but I understand the LSR or ABR >> or ASBR are control plane components; while the centralised path >> computaton server is a management plane component. In some case, (e.g. >> network management), their roles are lardgely different. Is that >> possible to define them seperately? >> >> >> Additionaly, it seems to me that PCS's functionality is to response the >> PCC's Path Computation Request, thus compute the path, and send the >> result back to PCC. This sounds perfect. While I am still a bit >> unclear. What kind of information the PCS need to know? How can the >> PCS get the relevant information? And so on. >> >> E.g. Brunner said in [3]: >> "Definitely the path computation server needs topology information in >> order to perform its task. But how to get that information is out of >> scope of this document. " >> >> I wonder if there are some specification which defines the PCS's >> functionality explicitly? >> >> If not, can somebody take the initiative? >> > > The PCS's role is to compute TE LSP path for which it is not the HE. > Basically, the PCS needs: > - to get information about the topology, the TE resources, .... This can > be done in several ways: downloading those informations from a router > using a Telnet session, having a routing adjacency with a router, ... - > some algorithm(s) to perform TE LSP path computation, > - to provide the computed TE LSP path to the PCC (routers) using Telnet, > a signalling protocol (Ex: [1]) Example 1: PCS= a UNIX station being able > to receive request from routers to compute TE LSP path for primary TE LSP > placement, inter-area TE LSPs, non packet TE LSP paths, bypass tunnel > path computation, ... Example 2: PCS= an ABR (scenario 2 or 4 of draft > http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.t > xt)) for inter-area TE LSP path computation, Example 3: any router is a > PCS to compute the bypass tunnel(s) path for each of its neighbors to > their respective (N)NHOP(s) LSRs. See the distributed bypass tunnel path > computation scenario of > http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation > -01.txt > > JP. > > >> Thanks for your time to read this mail. >> >> >> >> Best wishes! >> >> >> -- >> Chopin >> >> >> >> [1] Vasseur JP, et al., "RSVP Path computation request and reply >> messages", , IETF work in >> progress, Jun 2002. >> >> [2] JP Vasseur, "IS-IS Path Computation Server discovery TLV", >> , IETF work in progress, >> June, 2002 >> >> [3] M. Brunner, " COPS usage for Path Computation Servers (COPS-PCS)", >> , IETF work in progress, September, >> 2002 >> >> [4] JP Vasseur, Peter Psenak, "OSPF Path Computation Server discovery", >> , IETF work in progress, >> June, 2002 >> >> [5] JP Vasseur, Peter Psenak, "OSPF Traffic Engineering capability TLVs >> ", , IETF work in progress, >> October, 2002 >> >> >> >> >> > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus From owner-mpls@UU.NET Wed Nov 27 09:09:42 2002 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 ESMTP id JAA10215 for ; Wed, 27 Nov 2002 09:09:42 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqui05919 for ; Wed, 27 Nov 2002 14:12:21 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqui03986; Wed, 27 Nov 2002 14:11:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqui00958 for mpls-outgoing; Wed, 27 Nov 2002 14:10:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqui00797 for ; Wed, 27 Nov 2002 14:10:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnqui12178 for ; Wed, 27 Nov 2002 14:10:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqui02930 for ; Wed, 27 Nov 2002 14:10:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnqui02907 for ; Wed, 27 Nov 2002 14:10:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA04327 for ; Wed, 27 Nov 2002 09:10:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gAREA5h06929 for mpls@uu.net; Wed, 27 Nov 2002 09:10:05 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnqui00273 for ; Wed, 27 Nov 2002 14:09:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnqui28704 for ; Wed, 27 Nov 2002 14:09:06 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqui20531 for ; Wed, 27 Nov 2002 14:09:06 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQnqui20523 for ; Wed, 27 Nov 2002 14:09:05 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gARE9Hxu013082; Wed, 27 Nov 2002 09:09:18 -0500 (EST) Received: from tnadeau-w2k.cisco.com (che-vpn-cluster-2-58.cisco.com [10.86.242.58]) by bucket.cisco.com (Mirapoint) with ESMTP id ACE56409; Wed, 27 Nov 2002 09:08:50 -0500 (EST) Message-Id: <5.2.0.9.2.20021127090717.0300d1e8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 27 Nov 2002 09:08:47 -0500 To: "Zhu, Rupert" From: "Thomas D. Nadeau" Subject: RE: TE MIB - LSR MIB integration Cc: "Yuan Gu" , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 06:30 PM 11/26/2002 -0600, Zhu, Rupert wrote: >Roberto, Yuan: > >Interesting scenario. I agree on Yuan's approach, if you >insist on mapping the 3 LSPs into one TE tunnel. >However, why should we choose to map the 3 LSPs to >the same tunnel? > >The application described is to have 3 flows carried in 3 LSPs, >respectively. Since there is no logical relationships between >the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more >appropriate to model them as 3 independent entities. > >Alternative Solution #1: Map to 3 LSPs directly. > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > Have each mplsFTNActionType=redirectLSP. > Have each mplsFTNActionPointer pointing to one > of the 3 mplsXCEntry. This only works if the LSPs *originate* at the LSR in question. I understood that they were merely joining at the LSR in question and originated at different locations. >Alternative Solution #2: Map to 3 tunnels (instead of one). > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > -- Populate 3 entries in mplsTunnelTable, each representing > a distinct (logical) tunnel. (That is, they have different > values in mplsTunnelIndex.) > -- Have each mplsFTNActionType=redirectTunnel. > Have each mplsFTNActionPointer pointing to one of > the 3 mplsTunnelEntry. Again, I think that you are assuming that the LSPs originate at the local LSR, which I do not think they do, but feel free to correct me if I am wrong. --Tom >In other words, if there is no relationship between the 3 LSPs, >then they do not belong to the same TE tunnel. > >My two cents. > >-- Rupert > > > > -----Original Message----- > > From: Yuan Gu [mailto:yuangu@ipinfusion.com] > > Sent: Monday, November 25, 2002 2:12 PM > > To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET > > Subject: RE: TE MIB - LSR MIB integration > > > > > > Hello, Roberto: > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > > Roberto.Guglielmi@alcatel.it > > > Sent: Monday, November 25, 2002 3:19 AM > > > To: mpls@UU.NET > > > Subject: TE MIB - LSR MIB integration > > > > > > > > > Hello everybody, > > > I have a doubt about interactions between LSR MIB and TE > > MIB for what > > > concerning LSPs nested in TE tunnels. > > > Consider the following scenario: > > > > > > R1 -------- R2 -------- R3 > > > > > > and suppose, for example, I have three incoming flows. I > > want to insert > > > each flow in one LSP and tunnel the three LSPs in one TE tunnel. > > > My questions are: > > > > > > 1) How are the three LSPs mapped on the same TE tunnel? > > > > There will be 3 entries in mplsTunnelTable. Each entry has different > > mplsTuunnelInstance. > > > > The mplsTunnelInstance "Uniquely identifies an instance of a > > tunnel. It is > > useful to identify multiple instances of tunnels for the > > purposes of backup > > and parallel tunnels." > > You may want to put your LSPID into this field. > > > > > > > > 2) Is there only one entry in the mplsTunnelTable pointing > > to one entry > > > in the mplsXCTable? > > > > There will be 3 corresponding entries in mplsXCTable. Each entry has > > different mplsXCLspId (RSVP-TE or CR-LDP). > > > > > > From owner-mpls@UU.NET Wed Nov 27 11:48:34 2002 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 ESMTP id LAA18598 for ; Wed, 27 Nov 2002 11:48:33 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqut15580 for ; Wed, 27 Nov 2002 16:51:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqut14070; Wed, 27 Nov 2002 16:50:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqut22741 for mpls-outgoing; Wed, 27 Nov 2002 16:50:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnqut22731 for ; Wed, 27 Nov 2002 16:50:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnqut22473 for ; Wed, 27 Nov 2002 16:49:25 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqut13134 for ; Wed, 27 Nov 2002 16:49:25 GMT Received: from excalibur.santera.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: exchange.santera.com [4.22.157.11]) id QQnqut13124 for ; Wed, 27 Nov 2002 16:49:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: TE MIB - LSR MIB integration Date: Wed, 27 Nov 2002 10:49:24 -0600 Message-ID: Thread-Topic: TE MIB - LSR MIB integration Thread-Index: AcKV+2YZvbWf2eQvTa2Y19dmLRxVqgANX9gA From: "Zhu, Rupert" To: "Vijayanand C - CTD, Chennai." , Cc: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA18598 Vijay, Roberto: Thanks for the comments. Now I agree that wrapping the 3 individual LSPs into a 4th LSP (as a transport pipe) is more appropriate in this scenario. The essential element here is LSP nesting or LSP hierarchy based on usage of label stack. What is the role of TE tunnel in this play? QUESTION: Can we achieve the same effect without using mplsTunnelTable? If network operator does manual provisioning across R1, R2 and R3, then it seems that we can achieve the same effect based on FTN and LSR MIB, (leaving out TE MIB). If network operator wants to establish the outer LSP through signaling, then he has to use TE MIB. So the MPLS-TE-MIB is mainly used as a signaling interface in this case. Did I miss anything? -- Rupert > -----Original Message----- > From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] > Sent: Wednesday, November 27, 2002 3:56 AM > To: Roberto.Guglielmi@alcatel.it > Cc: mpls@UU.NET > Subject: RE: TE MIB - LSR MIB integration > > > The label stack and top label arrangements are as usual , as you said. > > Reg. the TE tunnel entry - I would imagine its going to have > an associated > XC entry ,which has associated outsegment, FTN etc. and would > be able to > carry traffic directly( not just as a tunnel for other LSPs). > Multiple LSPs may be using this TE tunnel entry, since they > would be holding > the TE tunnel label as their top label in their outsegments. > > Thanks and Regards > Vijay > > "Where protocols are a passion, MPLS is a religion " > > -----Original Message----- > From: Roberto.Guglielmi@alcatel.it > [mailto:Roberto.Guglielmi@alcatel.it] > Sent: Wednesday, November 27, 2002 1:49 PM > To: Vijayanand C - CTD, Chennai.; Zhu, Rupert; Yuan Gu > Cc: mpls@UU.NET > Subject: Re: TE MIB - LSR MIB integration > > > Yuan,Rupert and Vijayanand thanks for your replies. > Please see my comments inline. > > - Roberto > > > > Vijayanand C - CTD, Chennai. wrote: > > >In this scenario there is only one TE tunnel , ie the outer > tunnel across > R1 > >to R3. Three vanilla LSPs use it to tunnel flows across R1 > to R3. ( hope I > >understood the problem right). > > > You understood right. > > > > >Hence , it would be appropriate to have 3 XC entries( > pointed from their > >respective FTN entries) corresponding to each vanilla LSP > with the tunnel > >label in their label stacks. > > > So, the tunnel label in the mplsOutSegmentTable and the > bottom label in the > mplsLabelStackTable? > > > > >Also, I think there should be only one tunnel entry > corresponding to the TE > >tunnel. > > > Which table points to this tunnel entry? Where does this tunnel entry > point to? > > > > >Thanks and Regards > >Vijay > > > >"Where protocols are a passion, MPLS is a religion " > > > >-----Original Message----- > >From: Zhu, Rupert [mailto:rupert.zhu@santera.com] > >Sent: Wednesday, November 27, 2002 6:01 AM > >To: Yuan Gu; Roberto.Guglielmi@alcatel.it; mpls@UU.NET > >Subject: RE: TE MIB - LSR MIB integration > > > > > >Roberto, Yuan: > > > >Interesting scenario. I agree on Yuan's approach, if you > >insist on mapping the 3 LSPs into one TE tunnel. > >However, why should we choose to map the 3 LSPs to > >the same tunnel? > > > The incoming flows are Ethernet TLS flow traversing an > intervening MPLS > network. The typical scenario is to assign each of the flows entering > and leaving the MPLS network from the same end points, with a > VC label > (following Martini's draft) and encapsulate all the obtained > LSPs into > one TE tunnel, in order to offer the different clients the > same service. > > > > >The application described is to have 3 flows carried in 3 LSPs, > >respectively. Since there is no logical relationships between > >the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more > >appropriate to model them as 3 independent entities. > > > >Alternative Solution #1: Map to 3 LSPs directly. > > > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > > Have each mplsFTNActionType=redirectLSP. > > Have each mplsFTNActionPointer pointing to one > > of the 3 mplsXCEntry. > > > The classification is achieved using the pwe MIBs. The VC > label is kept > in the MPLS world, not in the pwe world. > > > > >Alternative Solution #2: Map to 3 tunnels (instead of one). > > > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > > -- Populate 3 entries in mplsTunnelTable, each representing > > a distinct (logical) tunnel. (That is, they have different > > values in mplsTunnelIndex.) > > -- Have each mplsFTNActionType=redirectTunnel. > > Have each mplsFTNActionPointer pointing to one of > > the 3 mplsTunnelEntry. > > > >In other words, if there is no relationship between the 3 LSPs, > >then they do not belong to the same TE tunnel. > > > >My two cents. > > > >-- Rupert > > > > > > > > > >>-----Original Message----- > >>From: Yuan Gu [mailto:yuangu@ipinfusion.com] > >>Sent: Monday, November 25, 2002 2:12 PM > >>To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET > >>Subject: RE: TE MIB - LSR MIB integration > >> > >> > >>Hello, Roberto: > >> > >> > >> > >>>-----Original Message----- > >>>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > >>>Roberto.Guglielmi@alcatel.it > >>>Sent: Monday, November 25, 2002 3:19 AM > >>>To: mpls@UU.NET > >>>Subject: TE MIB - LSR MIB integration > >>> > >>> > >>>Hello everybody, > >>>I have a doubt about interactions between LSR MIB and TE > >>> > >>> > >>MIB for what > >> > >> > >>>concerning LSPs nested in TE tunnels. > >>>Consider the following scenario: > >>> > >>>R1 -------- R2 -------- R3 > >>> > >>>and suppose, for example, I have three incoming flows. I > >>> > >>> > >>want to insert > >> > >> > >>>each flow in one LSP and tunnel the three LSPs in one TE tunnel. > >>>My questions are: > >>> > >>>1) How are the three LSPs mapped on the same TE tunnel? > >>> > >>> > >>There will be 3 entries in mplsTunnelTable. Each entry has different > >>mplsTuunnelInstance. > >> > >>The mplsTunnelInstance "Uniquely identifies an instance of a > >>tunnel. It is > >>useful to identify multiple instances of tunnels for the > >>purposes of backup > >>and parallel tunnels." > >>You may want to put your LSPID into this field. > >> > >> > >> > >>>2) Is there only one entry in the mplsTunnelTable pointing > >>> > >>> > >>to one entry > >> > >> > >>>in the mplsXCTable? > >>> > >>> > >>There will be 3 corresponding entries in mplsXCTable. Each entry has > >>different mplsXCLspId (RSVP-TE or CR-LDP). > >> > >> > >> > I understand your point of view. > In my opinion, the 3 entries in mplsXCTable should have the > tunnel label in > the mplsOutSegmentTable and the bottom label in the > mplsLabelStackTable. Do > you agree? If not, where the 2 labels are indicated for each flow? > > > >> > >> > >> > > > > > > > > From owner-mpls@UU.NET Thu Nov 28 00:17:31 2002 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 ESMTP id AAA09444 for ; Thu, 28 Nov 2002 00:17:31 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqwr25474 for ; Thu, 28 Nov 2002 05:20:11 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqwr23742; Thu, 28 Nov 2002 05:19:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqwr18975 for mpls-outgoing; Thu, 28 Nov 2002 05:19:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQnqwr18970 for ; Thu, 28 Nov 2002 05:19: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 QQnqwr18780 for ; Thu, 28 Nov 2002 05:18:53 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqwr23244 for ; Thu, 28 Nov 2002 05:18:53 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnqwr23228 for ; Thu, 28 Nov 2002 05:18:51 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Nov 2002 10:55:23 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06D666DF@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: "Zhu, Rupert" , Roberto.Guglielmi@alcatel.it Cc: mpls@UU.NET Subject: RE: TE MIB - LSR MIB integration Date: Thu, 28 Nov 2002 10:50:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Rupert, I think the issue is not whether the LSPs/tunnels are manually configured or signalled. Whenever we have a TE tunnel the tunnel entry and hence the TE MIB comes into play. The LSR and FTN MIBs are going to be there for vanilla LSPs and TE tunnels( a TE tunnel also has an associated XC entry ). Thanks and Regards Vijay "Where protocols are a passion, MPLS is a religion " -----Original Message----- From: Zhu, Rupert [mailto:rupert.zhu@santera.com] Sent: Wednesday, November 27, 2002 10:19 PM To: Vijayanand C - CTD, Chennai.; Roberto.Guglielmi@alcatel.it Cc: mpls@UU.NET Subject: RE: TE MIB - LSR MIB integration Vijay, Roberto: Thanks for the comments. Now I agree that wrapping the 3 individual LSPs into a 4th LSP (as a transport pipe) is more appropriate in this scenario. The essential element here is LSP nesting or LSP hierarchy based on usage of label stack. What is the role of TE tunnel in this play? QUESTION: Can we achieve the same effect without using mplsTunnelTable? If network operator does manual provisioning across R1, R2 and R3, then it seems that we can achieve the same effect based on FTN and LSR MIB, (leaving out TE MIB). If network operator wants to establish the outer LSP through signaling, then he has to use TE MIB. So the MPLS-TE-MIB is mainly used as a signaling interface in this case. Did I miss anything? -- Rupert > -----Original Message----- > From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] > Sent: Wednesday, November 27, 2002 3:56 AM > To: Roberto.Guglielmi@alcatel.it > Cc: mpls@UU.NET > Subject: RE: TE MIB - LSR MIB integration > > > The label stack and top label arrangements are as usual , as you said. > > Reg. the TE tunnel entry - I would imagine its going to have > an associated > XC entry ,which has associated outsegment, FTN etc. and would > be able to > carry traffic directly( not just as a tunnel for other LSPs). > Multiple LSPs may be using this TE tunnel entry, since they > would be holding > the TE tunnel label as their top label in their outsegments. > > Thanks and Regards > Vijay > > "Where protocols are a passion, MPLS is a religion " > > -----Original Message----- > From: Roberto.Guglielmi@alcatel.it > [mailto:Roberto.Guglielmi@alcatel.it] > Sent: Wednesday, November 27, 2002 1:49 PM > To: Vijayanand C - CTD, Chennai.; Zhu, Rupert; Yuan Gu > Cc: mpls@UU.NET > Subject: Re: TE MIB - LSR MIB integration > > > Yuan,Rupert and Vijayanand thanks for your replies. > Please see my comments inline. > > - Roberto > > > > Vijayanand C - CTD, Chennai. wrote: > > >In this scenario there is only one TE tunnel , ie the outer > tunnel across > R1 > >to R3. Three vanilla LSPs use it to tunnel flows across R1 > to R3. ( hope I > >understood the problem right). > > > You understood right. > > > > >Hence , it would be appropriate to have 3 XC entries( > pointed from their > >respective FTN entries) corresponding to each vanilla LSP > with the tunnel > >label in their label stacks. > > > So, the tunnel label in the mplsOutSegmentTable and the > bottom label in the > mplsLabelStackTable? > > > > >Also, I think there should be only one tunnel entry > corresponding to the TE > >tunnel. > > > Which table points to this tunnel entry? Where does this tunnel entry > point to? > > > > >Thanks and Regards > >Vijay > > > >"Where protocols are a passion, MPLS is a religion " > > > >-----Original Message----- > >From: Zhu, Rupert [mailto:rupert.zhu@santera.com] > >Sent: Wednesday, November 27, 2002 6:01 AM > >To: Yuan Gu; Roberto.Guglielmi@alcatel.it; mpls@UU.NET > >Subject: RE: TE MIB - LSR MIB integration > > > > > >Roberto, Yuan: > > > >Interesting scenario. I agree on Yuan's approach, if you > >insist on mapping the 3 LSPs into one TE tunnel. > >However, why should we choose to map the 3 LSPs to > >the same tunnel? > > > The incoming flows are Ethernet TLS flow traversing an > intervening MPLS > network. The typical scenario is to assign each of the flows entering > and leaving the MPLS network from the same end points, with a > VC label > (following Martini's draft) and encapsulate all the obtained > LSPs into > one TE tunnel, in order to offer the different clients the > same service. > > > > >The application described is to have 3 flows carried in 3 LSPs, > >respectively. Since there is no logical relationships between > >the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more > >appropriate to model them as 3 independent entities. > > > >Alternative Solution #1: Map to 3 LSPs directly. > > > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > > Have each mplsFTNActionType=redirectLSP. > > Have each mplsFTNActionPointer pointing to one > > of the 3 mplsXCEntry. > > > The classification is achieved using the pwe MIBs. The VC > label is kept > in the MPLS world, not in the pwe world. > > > > >Alternative Solution #2: Map to 3 tunnels (instead of one). > > > > -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). > > -- Populate 3 entries in mplsTunnelTable, each representing > > a distinct (logical) tunnel. (That is, they have different > > values in mplsTunnelIndex.) > > -- Have each mplsFTNActionType=redirectTunnel. > > Have each mplsFTNActionPointer pointing to one of > > the 3 mplsTunnelEntry. > > > >In other words, if there is no relationship between the 3 LSPs, > >then they do not belong to the same TE tunnel. > > > >My two cents. > > > >-- Rupert > > > > > > > > > >>-----Original Message----- > >>From: Yuan Gu [mailto:yuangu@ipinfusion.com] > >>Sent: Monday, November 25, 2002 2:12 PM > >>To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET > >>Subject: RE: TE MIB - LSR MIB integration > >> > >> > >>Hello, Roberto: > >> > >> > >> > >>>-----Original Message----- > >>>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > >>>Roberto.Guglielmi@alcatel.it > >>>Sent: Monday, November 25, 2002 3:19 AM > >>>To: mpls@UU.NET > >>>Subject: TE MIB - LSR MIB integration > >>> > >>> > >>>Hello everybody, > >>>I have a doubt about interactions between LSR MIB and TE > >>> > >>> > >>MIB for what > >> > >> > >>>concerning LSPs nested in TE tunnels. > >>>Consider the following scenario: > >>> > >>>R1 -------- R2 -------- R3 > >>> > >>>and suppose, for example, I have three incoming flows. I > >>> > >>> > >>want to insert > >> > >> > >>>each flow in one LSP and tunnel the three LSPs in one TE tunnel. > >>>My questions are: > >>> > >>>1) How are the three LSPs mapped on the same TE tunnel? > >>> > >>> > >>There will be 3 entries in mplsTunnelTable. Each entry has different > >>mplsTuunnelInstance. > >> > >>The mplsTunnelInstance "Uniquely identifies an instance of a > >>tunnel. It is > >>useful to identify multiple instances of tunnels for the > >>purposes of backup > >>and parallel tunnels." > >>You may want to put your LSPID into this field. > >> > >> > >> > >>>2) Is there only one entry in the mplsTunnelTable pointing > >>> > >>> > >>to one entry > >> > >> > >>>in the mplsXCTable? > >>> > >>> > >>There will be 3 corresponding entries in mplsXCTable. Each entry has > >>different mplsXCLspId (RSVP-TE or CR-LDP). > >> > >> > >> > I understand your point of view. > In my opinion, the 3 entries in mplsXCTable should have the > tunnel label in > the mplsOutSegmentTable and the bottom label in the > mplsLabelStackTable. Do > you agree? If not, where the 2 labels are indicated for each flow? > > > >> > >> > >> > > > > > > > > From owner-mpls@UU.NET Thu Nov 28 05:43:17 2002 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 ESMTP id FAA25033 for ; Thu, 28 Nov 2002 05:43:17 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqxn08550 for ; Thu, 28 Nov 2002 10:45:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnqxn07033; Thu, 28 Nov 2002 10:45:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQnqxm04547 for mpls-outgoing; Thu, 28 Nov 2002 10:44:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnqxm04536 for ; Thu, 28 Nov 2002 10:44: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 QQnqxm08889 for ; Thu, 28 Nov 2002 10:44:07 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnqxm09338 for ; Thu, 28 Nov 2002 10:44:07 GMT Received: from ganesh.ctd.hctech.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQnqxm09326 for ; Thu, 28 Nov 2002 10:44:05 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Nov 2002 16:20:39 +0530 Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06D867F8@haritha.hclt.com> From: "Vijayanand C - CTD, Chennai." To: Roberto.Guglielmi@alcatel.it Cc: mpls@UU.NET Subject: RE: TE MIB - LSR MIB integration Date: Thu, 28 Nov 2002 16:16:18 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The traffic parameters will be bound to the TE tunnel which is denoted by the tunnel label ( top label) retrieved from the XC outsegment of the vanilla LSP . I think, how to do traffic conditioning from here on, would be an implementation issue. But once u have identified the TE tunnel to put the traffic onto, it guess can be done. Thanks and Regards Vijay "Where protocols are a passion, MPLS is a religion " -----Original Message----- From: Roberto.Guglielmi@alcatel.it [mailto:Roberto.Guglielmi@alcatel.it] Sent: Thursday, November 28, 2002 1:40 PM To: Vijayanand C - CTD, Chennai. Cc: rupert.zhu@santera.com; mpls@UU.NET Subject: Re: TE MIB - LSR MIB integration Vijay, I have a doubt. If the TE tunnel is internally used by the LSP, how is it possible to use all the parameters configured in the TE MIB for the TE tunnel, given the fact the the classification process would point directly to the XC entry? You can only apply traffic parameters retrieved from the LSR MIB. - Roberto Vijayanand C - CTD, Chennai. wrote: >Yes, thats because its' the vanilla LSP which is the 'hit' in the >classification, and the TE tunnel is internally used by it. > >Its my pleasure to help. > >Thanks and Regards >Vijay > >"Where protocols are a passion, MPLS is a religion " > >-----Original Message----- >From: Roberto.Guglielmi@alcatel.it [mailto:Roberto.Guglielmi@alcatel.it] >Sent: Wednesday, November 27, 2002 4:14 PM >To: Vijayanand C - CTD, Chennai. >Subject: Re: TE MIB - LSR MIB integration > > >Hence, the FTNActionPointer would point directly to the XC entry and not >to the TE tunnel entry, is it right? This was the point getting me confused. >I really appreciate your help. > - Roberto > > >Vijayanand C - CTD, Chennai. wrote: > > > >>Yes, this is what I meant. >> >>But I dont understand what you are trying to get at. >> >>At the ingress the FTN map entries for the vanilla LSPs will clasify the >>packet and use the labels pointed to by the XC which will contain the TE >>tunnel label on top. This top label will be associated with the subsequent >>traffic shaping activities. >> >> >>Thanks and Regards >>Vijay >> >>"Where protocols are a passion, MPLS is a religion " >> >>-----Original Message----- >>From: Roberto.Guglielmi@alcatel.it [mailto:Roberto.Guglielmi@alcatel.it] >>Sent: Wednesday, November 27, 2002 3:44 PM >>To: Vijayanand C - CTD, Chennai. >>Cc: mpls@UU.NET >>Subject: Re: TE MIB - LSR MIB integration >> >> >>Vijayanand, >>please let me know if i understood what you just said. >> >>1) There are 4 XC entries: >> - 1 XC entry associated to the TE tunnel entry with only the >>tunnel label in the Out Segment >> - 3 XC entries each one associated to one flow and each one with >>the tunnel label in the Out Segment and the bottom label in the Stack >> >> >Table. > > >>Is this correct? >> >>2) In this case, how is it possible to get to one of the 3 XC entries >>containing the stack of labels, passing by the TE tunnel table, since >>the TE tunnel entry points to the XC entry with only the tunnel label? >>In other words, I don't understand how multiple LSPs can use the TE >>tunnel entry! >> >> - Roberto >> >> >>Vijayanand C - CTD, Chennai. wrote: >> >> >> >> >> >>>The label stack and top label arrangements are as usual , as you said. >>> >>>Reg. the TE tunnel entry - I would imagine its going to have an associated >>>XC entry ,which has associated outsegment, FTN etc. and would be able to >>>carry traffic directly( not just as a tunnel for other LSPs). >>>Multiple LSPs may be using this TE tunnel entry, since they would be >>> >>> >>> >>> >>holding >> >> >> >> >>>the TE tunnel label as their top label in their outsegments. >>> >>>Thanks and Regards >>>Vijay >>> >>>"Where protocols are a passion, MPLS is a religion " >>> >>>-----Original Message----- >>>From: Roberto.Guglielmi@alcatel.it [mailto:Roberto.Guglielmi@alcatel.it] >>>Sent: Wednesday, November 27, 2002 1:49 PM >>>To: Vijayanand C - CTD, Chennai.; Zhu, Rupert; Yuan Gu >>>Cc: mpls@UU.NET >>>Subject: Re: TE MIB - LSR MIB integration >>> >>> >>>Yuan,Rupert and Vijayanand thanks for your replies. >>>Please see my comments inline. >>> >>> - Roberto >>> >>> >>> >>>Vijayanand C - CTD, Chennai. wrote: >>> >>> >>> >>> >>> >>> >>> >>>>In this scenario there is only one TE tunnel , ie the outer tunnel across >>>> >>>> >>>> >>>> >>>> >>>> >>>R1 >>> >>> >>> >>> >>> >>> >>>>to R3. Three vanilla LSPs use it to tunnel flows across R1 to R3. ( hope >>>> >>>> >I > > >>>>understood the problem right). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>You understood right. >>> >>> >>> >>> >>> >>> >>> >>>>Hence , it would be appropriate to have 3 XC entries( pointed from their >>>>respective FTN entries) corresponding to each vanilla LSP with the tunnel >>>>label in their label stacks. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>So, the tunnel label in the mplsOutSegmentTable and the bottom label in >>> >>> >the > > >>>mplsLabelStackTable? >>> >>> >>> >>> >>> >>> >>> >>>>Also, I think there should be only one tunnel entry corresponding to the >>>> >>>> >>>> >>>> >>TE >> >> >> >> >>>>tunnel. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>Which table points to this tunnel entry? Where does this tunnel entry >>>point to? >>> >>> >>> >>> >>> >>> >>> >>>>Thanks and Regards >>>>Vijay >>>> >>>>"Where protocols are a passion, MPLS is a religion " >>>> >>>>-----Original Message----- >>>>From: Zhu, Rupert [mailto:rupert.zhu@santera.com] >>>>Sent: Wednesday, November 27, 2002 6:01 AM >>>>To: Yuan Gu; Roberto.Guglielmi@alcatel.it; mpls@UU.NET >>>>Subject: RE: TE MIB - LSR MIB integration >>>> >>>> >>>>Roberto, Yuan: >>>> >>>>Interesting scenario. I agree on Yuan's approach, if you >>>>insist on mapping the 3 LSPs into one TE tunnel. >>>>However, why should we choose to map the 3 LSPs to >>>>the same tunnel? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>The incoming flows are Ethernet TLS flow traversing an intervening MPLS >>>network. The typical scenario is to assign each of the flows entering >>>and leaving the MPLS network from the same end points, with a VC label >>>(following Martini's draft) and encapsulate all the obtained LSPs into >>>one TE tunnel, in order to offer the different clients the same service. >>> >>> >>> >>> >>> >>> >>> >>>>The application described is to have 3 flows carried in 3 LSPs, >>>>respectively. Since there is no logical relationships between >>>>the 3 LSPs, (e.g., load sharing, backup, etc.), it seems more >>>>appropriate to model them as 3 independent entities. >>>> >>>>Alternative Solution #1: Map to 3 LSPs directly. >>>> >>>> -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). >>>> Have each mplsFTNActionType=redirectLSP. >>>> Have each mplsFTNActionPointer pointing to one >>>> of the 3 mplsXCEntry. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>The classification is achieved using the pwe MIBs. The VC label is kept >>>in the MPLS world, not in the pwe world. >>> >>> >>> >>> >>> >>> >>> >>>>Alternative Solution #2: Map to 3 tunnels (instead of one). >>>> >>>> -- Populate 3 entries in mplsFTNTable (in MPLS-FTN-MIB). >>>> -- Populate 3 entries in mplsTunnelTable, each representing >>>> a distinct (logical) tunnel. (That is, they have different >>>> values in mplsTunnelIndex.) >>>> -- Have each mplsFTNActionType=redirectTunnel. >>>> Have each mplsFTNActionPointer pointing to one of >>>> the 3 mplsTunnelEntry. >>>> >>>>In other words, if there is no relationship between the 3 LSPs, >>>>then they do not belong to the same TE tunnel. >>>> >>>>My two cents. >>>> >>>>-- Rupert >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Yuan Gu [mailto:yuangu@ipinfusion.com] >>>>>Sent: Monday, November 25, 2002 2:12 PM >>>>>To: Roberto.Guglielmi@alcatel.it; mpls@UU.NET >>>>>Subject: RE: TE MIB - LSR MIB integration >>>>> >>>>> >>>>>Hello, Roberto: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >>>>>>Roberto.Guglielmi@alcatel.it >>>>>>Sent: Monday, November 25, 2002 3:19 AM >>>>>>To: mpls@UU.NET >>>>>>Subject: TE MIB - LSR MIB integration >>>>>> >>>>>> >>>>>>Hello everybody, >>>>>>I have a doubt about interactions between LSR MIB and TE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>MIB for what >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>concerning LSPs nested in TE tunnels. >>>>>>Consider the following scenario: >>>>>> >>>>>>R1 -------- R2 -------- R3 >>>>>> >>>>>>and suppose, for example, I have three incoming flows. I >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>want to insert >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>each flow in one LSP and tunnel the three LSPs in one TE tunnel. >>>>>>My questions are: >>>>>> >>>>>>1) How are the three LSPs mapped on the same TE tunnel? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>There will be 3 entries in mplsTunnelTable. Each entry has different >>>>>mplsTuunnelInstance. >>>>> >>>>>The mplsTunnelInstance "Uniquely identifies an instance of a >>>>>tunnel. It is >>>>>useful to identify multiple instances of tunnels for the >>>>>purposes of backup >>>>>and parallel tunnels." >>>>>You may want to put your LSPID into this field. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>2) Is there only one entry in the mplsTunnelTable pointing >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>to one entry >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>in the mplsXCTable? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>There will be 3 corresponding entries in mplsXCTable. Each entry has >>>>>different mplsXCLspId (RSVP-TE or CR-LDP). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>I understand your point of view. >>>In my opinion, the 3 entries in mplsXCTable should have the tunnel label >>> >>> >in > > >>>the mplsOutSegmentTable and the bottom label in the mplsLabelStackTable. >>> >>> >Do > > >>>you agree? If not, where the 2 labels are indicated for each flow? >>> >>> >>> >>> >>> >>> >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > From owner-mpls@UU.NET Fri Nov 29 10:11:26 2002 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 ESMTP id KAA01280 for ; Fri, 29 Nov 2002 10:11:26 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrbw24048 for ; Fri, 29 Nov 2002 15:14:05 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnrbw19625; Fri, 29 Nov 2002 15:11:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrbw23041 for mpls-outgoing; Fri, 29 Nov 2002 15:11:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnrbw22983 for ; Fri, 29 Nov 2002 15:11:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQnrbw04024 for ; Fri, 29 Nov 2002 15:10:22 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrbw28961 for ; Fri, 29 Nov 2002 15:10:21 GMT Received: from mo01.hanafos.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [211.202.13.143]) id QQnrbw28885 for ; Fri, 29 Nov 2002 15:10:15 GMT Received: from [211.211.117.230] by mo01.hanafos.com (Terrace Internet Messaging Server 3.280) with ESMTP id 2002113000:08:19:772228.29495.2315 for ; Sat, 30 Nov 2002 00:08:19 +0900 (KST) Message-ID: <002b01c297b9$4b54fc80$e675d3d3@lge.com> Reply-To: "Intae Jung" From: "Intae Jung" To: , Subject: Regarding LDP scalability Date: Sat, 30 Nov 2002 00:09:20 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C29804.BB0A49E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C29804.BB0A49E0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sDQpJJ2QgbGlrZSB0byBhc2sgYSBjb3VwbGUgb2YgcXVlc3Rpb25zIHJlZ2FyZGluZyBh IHNjYWxhYmlsaXR5IG9mIExEUCwgDQplc3BlY2lhbGx5IHdoZW4gaXQgaXMgZGVwbG95ZWQgaW4g YW4gQVRNLUxTUiwgYWRvcHRpbmcgRG93bnN0cmVhbSBvbg0KRGVtYW5kIGRpc3RyaWJ1dGlvbiB3 aXRoIGNvbnNlcnZhdGl2ZSBsYWJlbCByZXRlbnNpb24gYW5kIG9yZGVyZWQgY29udHJvbCwNCndo ZXJlIGxhYmVscyAoVlBJL1ZDSSkgYXJlIGEgcmVsYXRpdmVseSBzY2FyY2UgcmVzb3VyY2UgdGhh dCBtdXN0IGJlIGNvbnNlcnZlZA0KaW4gQVRNIHN3aXRjaC4gVGhlIFZQSS9WQ0kgaXMgYSBwYXJ0 aWN1bGFybHkgdmFsdWFibGUgYW5kIGxpbWl0ZWQgcmVzb3VyY2UgdGhhdCANCnNob3VsZCBiZSBz YXZlZCB3aGVuIGFuIEFUTSBMU1IgaXMgbm90IGFibGUgdG8gc3VwcG9ydCBWQy1tZXJnaW5nIGNh cGFiaWxpdHkuDQpVbmZvcnR1bmF0ZWx5IHRoZSBzeXN0ZW0gSSdtIG1hbmFnaW5nIGhhcyBubyBW Qy1tZXJnaW5nIGNhcGFiaWxpdHkuDQpBcyBkZWZpbmVkIGluIHRoZSBzdGFuZGFyZCwgTERQIGF0 dGVtcHRzIHRvIHNldHVwIG9yIHJlbGVhc2UgYSBob3AtYnktaG9wIExTUCANCndoZW5ldmVyIGEg bmV3IHJvdXRlIGlzIGFkZGVkIG9yIGRlbGV0ZWQgaW4gYW4gQVRNIExFUiB0aHJvdWdoIHJvdXRp bmcgcHJvdG9jb2xzLCANCm1haW5seSBJR1Agc3VjaCBhcyBPU1BGLCBJU0lTIG9yIFJJUC4NCkxl dCBtZSBhc3N1bWUgYSBzYW1wbGUgQVRNLU1QTFMgbmV0d29yayBhcyBmb2xsb3dzLg0KDQpOZXR3 b3JrMSAtIFIxIDwtPiBMRVIxIDwtPiBMU1IxIDwtPiBMU1IyIDwtPiBMRVIyIDwtPiBSMiAtIE5l dHdvcmsyDQoNCjwtLS1JUCBOZXR3b3JrLS0tPjwtLS0tLS0tLS0tLS1NUExTIE5ldHdvcmstLS0t LS0tLS0+PC0tLUlQIE5ldHdvcmstLS0+DQoNClIxLCBSMjogUm91dGVyIG9wZXJhdGluZyBJR1Ag KE9TUEYgb3IgUklQKQ0KTEVSMSwgTEVSMjogRWRnZSBBVE0gTFNSIG9wZXJhdGluZyBMRFAgYW5k IElHUCAoaUJHUCBpZiBuZWVkZWQpDQpMU1IxLCBMU1IyOiBBVE0gTFNSIG9wZXJhdGluZyBMRFAg YW5kIElHUCAoT1NQRiBvciBJUy1JUykNCg0KT1NQRiBvciBSSVAgaXMgdXNlZCBpbiB0aGUgSVAg TmV0d29yayBhbmQgT1NQRiBvciBJUy1JUyBpcyBkZXBsb3llZCANCmluIHRoZSBNUExTIE5ldHdv cmsuIEFuIGktQkdQIHNlc3Npb24gY291bGQgYmUgc2V0dXAgYmV0d2VlbiBMRVIxIGFuZCBMRVIy DQppZiBuZWVkZWQsIGJ1dCBub3QgbmVjZXNzYXJpbHkgc2luY2UgTEVSMSBhbmQgTEVSMiBhcmUg bm90IHN1cHBvc2VkIHRvIHByb3ZpZGUgDQpCR1AvTVBMUyBmdW5jdGlvbmFsaXR5LCBpbiBvdGhl ciB3b3JkcywgdGhleSBkb24ndCB3b3JrIGFzIGEgUEUoUHJvdmlkZXIgRWRnZSkgcm91dGVyLiAN CkxFUjEsIExFUjIsIExTUjEgYW5kIExTUjIgc3VwcG9ydCBvbmx5IExEUCBhcyBhbiBNUExTIHNp Z25hbGluZyBwcm90b2NvbC4NCg0KVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgbnVtYmVyIG9mIExT UCdzIGZyb20gTEVSMSB0byBMRVIyIGluY3JlYXNlcw0KYXMgdGhlIG51bWJlciBvZiBuZXR3b3Jr cyBpbmNyZWFzZXMgaW4gdGhlIE5ldHdvcmsyLCBtZWFuaW5nIHRoYXQgdGhlIG51bWJlciBvZg0K cm91dGluZyBlbnRyaWVzIGluIExFUjEgaW5jcmVhc2VzIGFjY29yZGluZ2x5LCB3aGVyZWFzZSB0 aGUgbnVtYmVyIG9mIExTUHMgc3VwcG9ydGVkDQpieSBMRVIxIGlzIGEgbG90IHNtYWxsZXIgdGhh biB0aGUgbnVtYmVyIG9mIGl0cyByb3V0ZSBlbnRyaWVzLg0KRXZlbnR1YWxseSwgYXMgdGhlIG51 bWJlciBvZiBMU1BzIHNldHVwIGV4Y2VlZHMgdGhlIG1heGltdW0gbnVtYmVyIG9mIExTUCdzLA0K d2UnbGwgbm90IGJlIGFibGUgdG8gc2V0dXAgYW4gTFNQIGFueSBtb3JlIGV2ZW4gdGhvdWdoIG5l dyByb3V0ZXMgYXJlIGFkZGVkLg0KQXMgSSBtZW50aW9uZWQgYWJvdmUsIExTUjEgYW5kIExTUjIg ZG9uJ3Qgc3VwcG9ydCBWQy1tZXJnaW5nIGNhcGFiaWxpdHksIA0KdGh1cyB0aGUgc2NhbGFiaWxp dHkgYmVjb21lcyBxdWl0ZSBzZXJ2ZXJlLg0KVGhlcmVmb3JlIHcncmUgdHJ5aW5nIHRvIGZpZ3Vy ZSBvdXQgaG93IHRvIHN1cHBvcnQgYSBsb3Qgb2Ygcm91dGluZyBlbnRyaWVzIHVzaW5nDQphIGxp bWl0ZWQgbnVtYmVyIG9mIExTUCdzLiBXZSBhcmUgdHJ5aW5nIHRvIGNvbWUgdXAgd2l0aCBhIG1l Y2hhbmlzbSB0aGF0IHNldHVwcyANCmp1c3Qgb25lIExTUCBiZXR3ZWVuIExFUjEgYW5kIExFUjIs IHdoaWNoIGNvdWxkIGJlIHNoYXJlZCBiZXR3ZWVuIGFsbCBiZXN0LWVmZm9ydA0KdHJhZmZpYyBi ZXR3ZWVuIE5ldHdvcmsxIGFuZCBOZXR3b3JrczIuDQoNClRoZSBwcm9ibGVtIHdlIGZhY2VkIGlz IGhvdyB0byBzZXR1cCBvbmx5IDEgTFNQcyBiZXR3ZWVuIExFUnMgYXV0b21hdGljYWxseSwgDQph bmQgdGhlbiBob3cgdG8gbWFwIGEgbG90IG9mIHJvdXRlIGVudHJpZXMgdG8gdGhlIHNoYXJlZCBM U1AuDQpBbHRob3VnaCB0d28gTEVSJ3MgYXJlIHNob3duIGluIHRoZSBleGFtcGxlLCB0aGUgbnVt YmVyIG9mIExTUCdzIGJldHdlZW4gTEVSJ3MNCmNhbiBiZSBxdWl0ZSBsYXJnZSBhcyB0aGUgbnVt YmVyIG9mIExFUidzIGluY3JlYXNlcy4NCldlJ3JlIGNvbnNpZGVyaW5nIHRvIHNldHVwIGEgZnVs bC1tZXNoIGlCR1Agc2Vzc2lvbnMgYmV0d2VlbiBhbGwgTEVSJ3MsIGFuZA0KdG8gdXNlIEJHUCBu ZXh0IGhvcCBnYXRld2F5IGluIG9yZGVyIHRvIGdldCBhbiBGRUMtdG8tTkhGTEUgbWFwcGluZy4N CkluIG90aGVyIHdvcmRzLCByb3V0ZXMgZnJvbSBOZXR3b3JrMiB3aWxsIGJlIHJlZGlzdHJpYnV0 ZWQgdG8gTEVSMSB2aWEgaUJHUCBzZXNzaW9uDQpiZXR3ZWVuIExFUjEgYW5kIExFUjIsIGFuZCB0 aGVuIExFUjEgd2lsbCBzZXR1cCBqdXN0IG9uZSBMU1AgZm9yIHRoZSBCR1AgbmV4dCBob3ANCmFk ZHJlc3MgYW5kIG1hcCBhbGwgcm91dGVzIGZyb20gTmV0d29yazEgdG8gdGhlIExTUC4NCkhvd2V2 ZXIgaXQgZW5mb3JjZXMgdXMgdG8gc2V0dXAgaUJHUCBzZXNzaW9ucyBiZXR3ZWVuIGFsbCBvZiBM RVIncyBldmVuIHRob3VnaA0Kd2UgZG9uJ3QgbmVlZCB0aGVtIHVubGVzcyB3ZSBkZXBsb3kgTVBM Uy4gV2UncmUgYWxzbyB3b25kZXJpbmcgd2hldGhlcg0Kd2UnbGwgYmUgYWJsZSB0byBzb2x2ZSB0 aGUgcHJvYmxlbSB1c2luZyBhbnkgSUdQIGNhcGFiaWxpdHksIGxpa2UgdGFnIGZpZWxkIG9mIEFT LWV4dGVybmFsIA0KTFNBIGluIE9TUEYuDQoNClBsZWFzZSBlbmxpZ2h0ZW4gdXMgb24gdGhpcyBp c3N1ZS4gDQpBbnkgZXhwZXJpZW5jZSBvciBpZGVhIHdpbGwgYmUgZ3JlYXRseSBhcHByZWNpYXRl ZC4NClRoYW5rcyBpbiBhZHZhbmNlLg0KDQpSZWdhcmRzLA0KDQpKdW5nLg== ------=_NextPart_000_0028_01C29804.BB0A49E0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTEyNiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj5IZWxsbyw8QlI+SSdkIGxpa2UgdG8gYXNrIGEgY291cGxlIG9mIA0KcXVlc3Rpb25z IHJlZ2FyZGluZyBhIHNjYWxhYmlsaXR5IG9mIExEUCwgPEJSPmVzcGVjaWFsbHkgd2hlbiBpdCBp cyBkZXBsb3llZCBpbiANCmFuIEFUTS1MU1IsIGFkb3B0aW5nIERvd25zdHJlYW0gb248QlI+RGVt YW5kIGRpc3RyaWJ1dGlvbiB3aXRoIGNvbnNlcnZhdGl2ZSANCmxhYmVsIHJldGVuc2lvbiBhbmQg b3JkZXJlZCBjb250cm9sLDxCUj53aGVyZSBsYWJlbHMgKFZQSS9WQ0kpIGFyZSBhIHJlbGF0aXZl bHkgDQpzY2FyY2UgcmVzb3VyY2UgdGhhdCBtdXN0IGJlIGNvbnNlcnZlZDxCUj5pbiBBVE0gc3dp dGNoLiBUaGUgVlBJL1ZDSSBpcyBhIA0KcGFydGljdWxhcmx5IHZhbHVhYmxlIGFuZCBsaW1pdGVk IHJlc291cmNlIHRoYXQgPEJSPnNob3VsZCBiZSBzYXZlZCB3aGVuIGFuIEFUTSANCkxTUiBpcyBu b3QgYWJsZSB0byBzdXBwb3J0IFZDLW1lcmdpbmcgY2FwYWJpbGl0eS48QlI+VW5mb3J0dW5hdGVs eSB0aGUgc3lzdGVtIA0KSSdtIG1hbmFnaW5nIGhhcyBubyBWQy1tZXJnaW5nIGNhcGFiaWxpdHku PEJSPkFzIGRlZmluZWQgaW4gdGhlIHN0YW5kYXJkLCBMRFAgDQphdHRlbXB0cyB0byBzZXR1cCBv ciByZWxlYXNlIGEgaG9wLWJ5LWhvcCBMU1AgPEJSPndoZW5ldmVyIGEgbmV3IHJvdXRlIGlzIGFk ZGVkIA0Kb3IgZGVsZXRlZCBpbiBhbiBBVE0gTEVSIHRocm91Z2ggcm91dGluZyBwcm90b2NvbHMs IDxCUj5tYWlubHkgSUdQIHN1Y2ggYXMgT1NQRiwgDQpJU0lTIG9yIFJJUC48QlI+TGV0IG1lIGFz c3VtZSBhIHNhbXBsZSBBVE0tTVBMUyBuZXR3b3JrIGFzIA0KZm9sbG93cy48QlI+PEJSPk5ldHdv cmsxIC0gUjEgJmx0Oy0mZ3Q7IExFUjEgJmx0Oy0mZ3Q7IExTUjEgJmx0Oy0mZ3Q7IExTUjIgDQom bHQ7LSZndDsgTEVSMiAmbHQ7LSZndDsgUjIgLSBOZXR3b3JrMjxCUj48QlI+Jmx0Oy0tLUlQIA0K TmV0d29yay0tLSZndDsmbHQ7LS0tLS0tLS0tLS0tTVBMUyBOZXR3b3JrLS0tLS0tLS0tJmd0OyZs dDstLS1JUCANCk5ldHdvcmstLS0mZ3Q7PEJSPjxCUj5SMSwgUjI6IFJvdXRlciBvcGVyYXRpbmcg SUdQIChPU1BGIG9yIFJJUCk8QlI+TEVSMSwgTEVSMjogDQpFZGdlIEFUTSBMU1Igb3BlcmF0aW5n IExEUCBhbmQgSUdQIChpQkdQIGlmIG5lZWRlZCk8QlI+TFNSMSwgTFNSMjogQVRNIExTUiANCm9w ZXJhdGluZyBMRFAgYW5kIElHUCAoT1NQRiBvciBJUy1JUyk8QlI+PEJSPk9TUEYgb3IgUklQIGlz IHVzZWQgaW4gdGhlIElQIA0KTmV0d29yayBhbmQgT1NQRiBvciBJUy1JUyBpcyBkZXBsb3llZCA8 QlI+aW4gdGhlIE1QTFMgTmV0d29yay4gQW4gaS1CR1Agc2Vzc2lvbiANCmNvdWxkIGJlIHNldHVw IGJldHdlZW4gTEVSMSBhbmQgTEVSMjxCUj5pZiBuZWVkZWQsIGJ1dCBub3QgbmVjZXNzYXJpbHkg c2luY2UgDQpMRVIxIGFuZCBMRVIyIGFyZSBub3Qgc3VwcG9zZWQgdG8gcHJvdmlkZSA8QlI+QkdQ L01QTFMgZnVuY3Rpb25hbGl0eSwgaW4gb3RoZXIgDQp3b3JkcywgdGhleSBkb24ndCB3b3JrIGFz IGEgUEUoUHJvdmlkZXIgRWRnZSkgcm91dGVyLiA8QlI+TEVSMSwgTEVSMiwgTFNSMSBhbmQgDQpM U1IyIHN1cHBvcnQgb25seSBMRFAgYXMgYW4gTVBMUyBzaWduYWxpbmcgcHJvdG9jb2wuPEJSPjxC Uj5UaGUgcHJvYmxlbSBpcyB0aGF0IA0KdGhlIG51bWJlciBvZiBMU1AncyBmcm9tIExFUjEgdG8g TEVSMiBpbmNyZWFzZXM8QlI+YXMgdGhlIG51bWJlciBvZiBuZXR3b3JrcyANCmluY3JlYXNlcyBp biB0aGUgTmV0d29yazIsIG1lYW5pbmcgdGhhdCB0aGUgbnVtYmVyIG9mPEJSPnJvdXRpbmcgZW50 cmllcyBpbiBMRVIxIA0KaW5jcmVhc2VzIGFjY29yZGluZ2x5LCB3aGVyZWFzZSB0aGUgbnVtYmVy IG9mIExTUHMgc3VwcG9ydGVkPEJSPmJ5IExFUjEgaXMgYSBsb3QgDQpzbWFsbGVyIHRoYW4gdGhl IG51bWJlciBvZiBpdHMgcm91dGUgZW50cmllcy48QlI+RXZlbnR1YWxseSwgYXMgdGhlIG51bWJl ciBvZiANCkxTUHMgc2V0dXAgZXhjZWVkcyB0aGUgbWF4aW11bSBudW1iZXIgb2YgTFNQJ3MsPEJS PndlJ2xsIG5vdCBiZSBhYmxlIHRvIHNldHVwIGFuIA0KTFNQIGFueSBtb3JlIGV2ZW4gdGhvdWdo IG5ldyByb3V0ZXMgYXJlIGFkZGVkLjxCUj5BcyBJIG1lbnRpb25lZCBhYm92ZSwgTFNSMSBhbmQg DQpMU1IyIGRvbid0IHN1cHBvcnQgVkMtbWVyZ2luZyBjYXBhYmlsaXR5LCA8QlI+dGh1cyB0aGUg c2NhbGFiaWxpdHkgYmVjb21lcyBxdWl0ZSANCnNlcnZlcmUuPEJSPlRoZXJlZm9yZSB3J3JlIHRy eWluZyB0byBmaWd1cmUgb3V0IGhvdyB0byBzdXBwb3J0IGEgbG90IG9mIHJvdXRpbmcgDQplbnRy aWVzIHVzaW5nPEJSPmEgbGltaXRlZCBudW1iZXIgb2YgTFNQJ3MuIFdlIGFyZSB0cnlpbmcgdG8g Y29tZSB1cCB3aXRoIGEgDQptZWNoYW5pc20gdGhhdCBzZXR1cHMgPEJSPmp1c3Qgb25lIExTUCBi ZXR3ZWVuIExFUjEgYW5kIExFUjIsIHdoaWNoIGNvdWxkIGJlIA0Kc2hhcmVkIGJldHdlZW4gYWxs IGJlc3QtZWZmb3J0PEJSPnRyYWZmaWMgYmV0d2VlbiBOZXR3b3JrMSBhbmQgDQpOZXR3b3JrczIu PEJSPjxCUj5UaGUgcHJvYmxlbSB3ZSBmYWNlZCBpcyBob3cgdG8gc2V0dXAgb25seSAxIExTUHMg YmV0d2VlbiBMRVJzIA0KYXV0b21hdGljYWxseSwgPEJSPmFuZCB0aGVuIGhvdyB0byBtYXAgYSBs b3Qgb2Ygcm91dGUgZW50cmllcyB0byB0aGUgc2hhcmVkIA0KTFNQLjxCUj5BbHRob3VnaCB0d28g TEVSJ3MgYXJlIHNob3duIGluIHRoZSBleGFtcGxlLCB0aGUgbnVtYmVyIG9mIExTUCdzIGJldHdl ZW4gDQpMRVInczxCUj5jYW4gYmUgcXVpdGUgbGFyZ2UgYXMgdGhlIG51bWJlciBvZiBMRVIncyBp bmNyZWFzZXMuPEJSPldlJ3JlIA0KY29uc2lkZXJpbmcgdG8gc2V0dXAgYSBmdWxsLW1lc2ggaUJH UCBzZXNzaW9ucyBiZXR3ZWVuIGFsbCBMRVIncywgYW5kPEJSPnRvIHVzZSANCkJHUCBuZXh0IGhv cCBnYXRld2F5IGluIG9yZGVyIHRvIGdldCBhbiBGRUMtdG8tTkhGTEUgbWFwcGluZy48QlI+SW4g b3RoZXIgd29yZHMsIA0Kcm91dGVzIGZyb20gTmV0d29yazIgd2lsbCBiZSByZWRpc3RyaWJ1dGVk IHRvIExFUjEgdmlhIGlCR1Agc2Vzc2lvbjxCUj5iZXR3ZWVuIA0KTEVSMSBhbmQgTEVSMiwgYW5k IHRoZW4gTEVSMSB3aWxsIHNldHVwIGp1c3Qgb25lIExTUCBmb3IgdGhlIEJHUCBuZXh0IA0KaG9w PEJSPmFkZHJlc3MgYW5kIG1hcCBhbGwgcm91dGVzIGZyb20gTmV0d29yazEgdG8gdGhlIExTUC48 QlI+SG93ZXZlciBpdCANCmVuZm9yY2VzIHVzIHRvIHNldHVwIGlCR1Agc2Vzc2lvbnMgYmV0d2Vl biBhbGwgb2YgTEVSJ3MgZXZlbiB0aG91Z2g8QlI+d2UgZG9uJ3QgDQpuZWVkIHRoZW0gdW5sZXNz IHdlIGRlcGxveSBNUExTLiBXZSdyZSBhbHNvIHdvbmRlcmluZyB3aGV0aGVyPEJSPndlJ2xsIGJl IGFibGUgDQp0byBzb2x2ZSB0aGUgcHJvYmxlbSB1c2luZyBhbnkgSUdQIGNhcGFiaWxpdHksIGxp a2UgdGFnIGZpZWxkIG9mIEFTLWV4dGVybmFsIA0KPEJSPkxTQSBpbiBPU1BGLjxCUj48QlI+UGxl YXNlIGVubGlnaHRlbiB1cyBvbiB0aGlzIGlzc3VlLiA8QlI+QW55IGV4cGVyaWVuY2Ugb3IgDQpp ZGVhIHdpbGwgYmUgZ3JlYXRseSBhcHByZWNpYXRlZC48QlI+VGhhbmtzIGluIA0KYWR2YW5jZS48 QlI+PEJSPlJlZ2FyZHMsPEJSPjxCUj5KdW5nLjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0028_01C29804.BB0A49E0-- From owner-mpls@UU.NET Fri Nov 29 10:28:50 2002 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 ESMTP id KAA01478 for ; Fri, 29 Nov 2002 10:28:50 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrby16900 for ; Fri, 29 Nov 2002 15:31:33 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnrby15787; Fri, 29 Nov 2002 15:31:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrby25052 for mpls-outgoing; Fri, 29 Nov 2002 15:30:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnrby25047 for ; Fri, 29 Nov 2002 15:30:40 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 QQnrby00523 for ; Fri, 29 Nov 2002 15:30:00 GMT Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrby09804 for ; Fri, 29 Nov 2002 15:30:00 GMT Received: from hoemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnrby09776 for ; Fri, 29 Nov 2002 15:30:00 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gATFTwP09863 for ; Fri, 29 Nov 2002 10:29:58 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 16:29:57 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: review of mpls-mgmt-overview revision 02 Date: Fri, 29 Nov 2002 16:29:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Here are my comments/nits that you can/should consider for the next revision. A lot of it is indeed nits/spelling/grammar stuff... do I have to repat that for all docs, or can I assume that the authors/editors will seriously check those things themselves? Here we go. - there is only ONE MIB. You keep talking about MIBs or "Management Information Bases". Please make sure to use consistent terminology... the correct termonology is: - Management Information Base (MIB) - MIB Module(s), when talking about one or more MIB modules as specified in a I-D or an RFC. This comment probably applies to other MPLS MIB documents as well - In the abstract you talk about "the management architecture for MPLS" Is it indeed that wide? If so, then it should include all mechanisms that people can use for managing/configuring MPLS. I think the document is what the title says, namely an overview. Maybe instead of "management overview" it is even better to say "MIB overview". Anyway... I don;t think it is an architecture - In this document you often say "this draft". Better to use terms like "this document" or "this memo" or such, so that it still is correct when published as RFC. - I see you use mib module names with an underscore, for example MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB Better get that in sync. True for most mib module names I believe - 2nd para on page 6 (still sect 4.3 s/map to one more/map to one or more/ ?? Can you add some text how that mapping is done? Liek via shared index, or via augments, or via mapping table ? - 2nd para sect 4.5 sentence ends as: "... in question or." Seems incorrect s/objects needed for TE tunnels/objects needed for managing TE tunnels/ ?? - Sect 4.9 "Interfaces Group of MIB II" ?? This is just the IF-MIB as per RFC2863. No need to reference or talk about MIB II I think. "Thus, the MPLS interface" --> maybe better: "Thus, a MPLS interface" - Make descriptors consistent. Like - mplsLdpEntityFrameRelayXxxxx - mplsLdpEntityConfFrXxxx so either make all freme-relay stuff xxxFrameRelayYyy or xxxFrYyy but do not mix all that. I also wonder why in some case Fr comes before the Xxxx and in other cases after it. - mplsLdpEntityFrameRelayXxxxx - mplsLdpEntityConfFrXxxx why not mplsLdpEntityFrameRelayConfXxxx A lot of that has to do with making it easier for users to see which objects are in which tables and to which set of objects they belong. - Sect 6.1, last sentence 4th bullet Add "and FrameRelays respectively" ?? - Sect 6.3 Pls add some text if such notifications are generated per session or per entity or whatever it is. - sect 6.4 Would be good to show which tables augment which other tables And explain how the others relate to each other (index sharing, rowpointers, extension...)? - Sect 7.1 are mplsTunnelResourceTable and mplsTunnelCRDLPResTable both "resource" tables? If so, then why not use "Resource" in both cases, or just "Res" in both cases? Consistency please!!!!! Question: Is there also a mplsTunnelRSVPResTable? If yes, then I am missing it here, if no, then why is that not needed? So Tunnel Computed Hop Table is: mplsTunnelCHopTable and Tunnel Actual Hop Table is: mplsTunnelARHopTable is the R for Route? If so then add Route in there - sect 7.2 ".. mplsTunnelMaxHops defines the size of route that may be configured on the LSR." I have difficulty understanding what that means. What is the "size of route"? - Your references to PWE3 and PPVPN WG docs are listed as normative. I doubt that they really are. In any event, if they are normative, then they will have to be ready for RFC at the same time that this doc goes to RFC. - Your split of references for the SNMP boilerplate text is not correct. The correct split is: > > > > Normative Informative > > ---------- ------------ > > 1905 1155 > > 1906 1157 > > 1212 > > 1215 > > 2571 1901 > > 2572 2570 > > 2573 > > 2574 > > 2575 > > 2578 > > 2579 > > 2580 > > - We're working on the new MIB boilerplate. Much shorter. Not 100% stable yet. If you prefer to use it (I assume the new boiler plate will be stable by the time you go to RFC-Editor queue), then I can send you what the curretn text looks like. Thanks, Bert From owner-mpls@UU.NET Fri Nov 29 11:22:22 2002 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 ESMTP id LAA02617 for ; Fri, 29 Nov 2002 11:22:21 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrcb23260 for ; Fri, 29 Nov 2002 16:25:03 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnrcb21173; Fri, 29 Nov 2002 16:24:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrcb17770 for mpls-outgoing; Fri, 29 Nov 2002 16:23:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnrcb17765 for ; Fri, 29 Nov 2002 16:23:26 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 QQnrcb10326 for ; Fri, 29 Nov 2002 16:21:54 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrcb19957 for ; Fri, 29 Nov 2002 16:21:53 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnrcb19953 for ; Fri, 29 Nov 2002 16:21:53 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gATGLpP24275 for ; Fri, 29 Nov 2002 11:21:52 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 17:21:50 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: review of draft-ietf-mpls-tc-mib-05.txt Date: Fri, 29 Nov 2002 17:21:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Here is my review - compiles clean. Thanks!! - introduction s/a MIB/a MIB module/ - the reference for RFC2119, that is [21] does not show up in the references. TO be consistent, you may want to make it [RFC2119] - need to add an IPR section as per RFC2026 Section 10 Such is needed for all stds track documents) - Although you do explain in comments that IANA needs to assign a number, it probably will make things go easier, if you repeat that in an IANA Considerations Section, in which you list that IANA needs to assign a number under the transmission subtree. - references need to be split in nromative and informative - Just a note that MIB Boilerplate will prbably change in the next week or so. It is much shorter, so that is good (I think) - mplsBitRate is still pretty strange, as discussed at the meeting on Saturday 16th, I think you know how to change it to be clearer In any event, it is probably better to use an Unsigned32, cause a negative value seems to make no sense at all. - MplsOwner. As I explained at the meeting, I may still not be clear on what the text says. I think the "In all other respects" sentence seems to say that an operator may delete rows (entries) that have been created by other methods. Operator may do so via SN MP or OTHER methods. But operator is not supposed to make changes to rows created by other methods. Did I get that? If so, can it be made clearer? If not... then certainly it needs to be made clearer - MplsLsrIndex Mmm... in which MIB module is this used? - MplsTunnelIndex Probably better to make the base type Unsigned32 (1..65535) that is also more consistent with the MplsTunnelIndexOrZero Thanks, Bert From owner-mpls@UU.NET Fri Nov 29 11:38:10 2002 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 ESMTP id LAA02906 for ; Fri, 29 Nov 2002 11:38:09 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrcc10747 for ; Fri, 29 Nov 2002 16:40:52 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnrcc08688; Fri, 29 Nov 2002 16:39:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrcc18798 for mpls-outgoing; Fri, 29 Nov 2002 16:39:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnrcc18793 for ; Fri, 29 Nov 2002 16:39:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnrcc19974 for ; Fri, 29 Nov 2002 16:39:30 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrcc06316 for ; Fri, 29 Nov 2002 16:39:30 GMT Received: from hoemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnrcc06301 for ; Fri, 29 Nov 2002 16:39:29 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gATGdRP29159 for ; Fri, 29 Nov 2002 11:39:28 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 17:39:26 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: SYNTAX (compile) errors for draft-ietf-mpls-ftn-mib-05.txt Date: Fri, 29 Nov 2002 17:39:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Here is first a list with compiler (syntax) errors SMICng tells me: E: f(mplsftn.mi2), (1,1) SMI item "Counter32" used in MPLS-FTN-MIB, but not defined or imported E: f(mplsftn.mi2), (197,34) Item "mplsFTNProtocol" in sequence "MplsFTNEntry" has conflicting syntax specified E: f(mplsftn.mi2), (590,38) Item "mplsFTNMatchedPackets" in sequence "MplsFTNPerfEntry" has conflicting syntax specified E: f(mplsftn.mi2), (591,38) Item "mplsFTNMatchedOctets" in sequence "MplsFTNPerfEntry" has conflicting syntax specified W: f(mplsftn.mi2), (586,30) Row "mplsFTNPerfEntry" does not have a consistent indexing scheme - index items must be in same order as used in INDEX clause for "base row" mplsFTNMapEntry SMIlint (smilint@ibr.cs.tu-bs.de) tells me as shown below Thanks, Bert -----Original Message----- From: smilint@ibr.cs.tu-bs.de [mailto:smilint@ibr.cs.tu-bs.de] Sent: zaterdag 16 november 2002 16:45 To: Wijnen, Bert (Bert) Subject: Re: mpls ftn 5 output of smilint -l 9 follows, empty output means everything is fine. --start-- 1096: SMIv2 base type `Counter32' must be imported from SNMPv2-SMI 1105: type of `mplsFTNMatchedPackets' in sequence and object type definition do not match 1109: SMIv2 base type `Counter32' must be imported from SNMPv2-SMI 1119: type of `mplsFTNMatchedOctets' in sequence and object type definition do not match --end-- From owner-mpls@UU.NET Fri Nov 29 12:19:16 2002 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 ESMTP id MAA03613 for ; Fri, 29 Nov 2002 12:19:16 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrcf27334 for ; Fri, 29 Nov 2002 17:21:59 GMT Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnrcf24890; Fri, 29 Nov 2002 17:20:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrcf10916 for mpls-outgoing; Fri, 29 Nov 2002 17:20:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnrcf10906 for ; Fri, 29 Nov 2002 17:20:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnrcf19756 for ; Fri, 29 Nov 2002 17:19:18 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrcf10056 for ; Fri, 29 Nov 2002 17:19:18 GMT Received: from hoemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQnrcf10049 for ; Fri, 29 Nov 2002 17:19:18 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gATHJGD08884 for ; Fri, 29 Nov 2002 12:19:16 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 18:19:15 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Mpls (E-mail)" Subject: Compile/Syntax errors in draft-ietf-mpls-lsr-mib-09.txt Date: Fri, 29 Nov 2002 18:07:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk First compile errors/warning: SMICng tells me: E: f(mplslsr.mi2), (657,38) Item "mplsOutSegmentIfIndex" in sequence "MplsOutSegmentEntry" has conflicting syntax specified W: f(mplslsr.mi2), (1737,1) OBJECT-GROUP "mplsXCOptionalGroup" is not used in a MODULE-COMPLIANCE in current module W: f(mplslsr.mi2), (1818,1) OBJECT-GROUP "mplsLabelStackGroup" is not used in a MODULE-COMPLIANCE in current module W: f(mplslsr.mi2), (1844,1) NOTIFICATION-GROUP "mplsLsrNotificationGroup" is not used in a MODULE-COMPLIANCE in current module Thanks, Bert From owner-mpls@UU.NET Fri Nov 29 13:17:12 2002 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 ESMTP id NAA04844 for ; Fri, 29 Nov 2002 13:17:12 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrcj27986 for ; Fri, 29 Nov 2002 18:19:54 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnrcj26101; Fri, 29 Nov 2002 18:18:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrcj03735 for mpls-outgoing; Fri, 29 Nov 2002 18:18:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnrcj03730 for ; Fri, 29 Nov 2002 18:18:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnrcj15253 for ; Fri, 29 Nov 2002 18:18:12 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrcj25367 for ; Fri, 29 Nov 2002 18:18:11 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQnrcj25229 for ; Fri, 29 Nov 2002 18:18:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA09588 for ; Fri, 29 Nov 2002 13:18:05 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.11.2/CISCO.WS.1.2) id gATII5O29557 for mpls@uu.net; Fri, 29 Nov 2002 13:18:05 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQnrcj03680 for ; Fri, 29 Nov 2002 18:17:34 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 QQnrcj04564 for ; Fri, 29 Nov 2002 18:17:21 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrcj24604 for ; Fri, 29 Nov 2002 18:17:21 GMT Received: from fargo.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fargo.cisco.com [171.70.170.202]) id QQnrcj24594 for ; Fri, 29 Nov 2002 18:17:20 GMT Received: from abdb (rtp-vpn1-818.cisco.com [10.82.227.50]) by fargo.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id KAA20825; Fri, 29 Nov 2002 10:17:18 -0800 (PST) From: "Dmitry Bokotey" To: "'Intae Jung'" , , Cc: "Cpignata" Subject: RE: Regarding LDP scalability Date: Fri, 29 Nov 2002 12:17:35 -0600 Message-ID: <002e01c297d3$98952500$0801a8c0@abdb> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C297A1.4DFAB500" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <002b01c297b9$4b54fc80$e675d3d3@lge.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C297A1.4DFAB500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit cc to Carlos -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Intae Jung Sent: Friday, November 29, 2002 9:09 AM To: mpls-ops@mplsrc.com; mpls@UU.NET Subject: Regarding LDP scalability Hello, I'd like to ask a couple of questions regarding a scalability of LDP, especially when it is deployed in an ATM-LSR, adopting Downstream on Demand distribution with conservative label retension and ordered control, where labels (VPI/VCI) are a relatively scarce resource that must be conserved in ATM switch. The VPI/VCI is a particularly valuable and limited resource that should be saved when an ATM LSR is not able to support VC-merging capability. Unfortunately the system I'm managing has no VC-merging capability. As defined in the standard, LDP attempts to setup or release a hop-by-hop LSP whenever a new route is added or deleted in an ATM LER through routing protocols, mainly IGP such as OSPF, ISIS or RIP. Let me assume a sample ATM-MPLS network as follows. Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 - Network2 <---IP Network---><------------MPLS Network---------><---IP Network---> R1, R2: Router operating IGP (OSPF or RIP) LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP if needed) LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or IS-IS) OSPF or RIP is used in the IP Network and OSPF or IS-IS is deployed in the MPLS Network. An i-BGP session could be setup between LER1 and LER2 if needed, but not necessarily since LER1 and LER2 are not supposed to provide BGP/MPLS functionality, in other words, they don't work as a PE(Provider Edge) router. LER1, LER2, LSR1 and LSR2 support only LDP as an MPLS signaling protocol. The problem is that the number of LSP's from LER1 to LER2 increases as the number of networks increases in the Network2, meaning that the number of routing entries in LER1 increases accordingly, wherease the number of LSPs supported by LER1 is a lot smaller than the number of its route entries. Eventually, as the number of LSPs setup exceeds the maximum number of LSP's, we'll not be able to setup an LSP any more even though new routes are added. As I mentioned above, LSR1 and LSR2 don't support VC-merging capability, thus the scalability becomes quite servere. Therefore w're trying to figure out how to support a lot of routing entries using a limited number of LSP's. We are trying to come up with a mechanism that setups just one LSP between LER1 and LER2, which could be shared between all best-effort traffic between Network1 and Networks2. The problem we faced is how to setup only 1 LSPs between LERs automatically, and then how to map a lot of route entries to the shared LSP. Although two LER's are shown in the example, the number of LSP's between LER's can be quite large as the number of LER's increases. We're considering to setup a full-mesh iBGP sessions between all LER's, and to use BGP next hop gateway in order to get an FEC-to-NHFLE mapping. In other words, routes from Network2 will be redistributed to LER1 via iBGP session between LER1 and LER2, and then LER1 will setup just one LSP for the BGP next hop address and map all routes from Network1 to the LSP. However it enforces us to setup iBGP sessions between all of LER's even though we don't need them unless we deploy MPLS. We're also wondering whether we'll be able to solve the problem using any IGP capability, like tag field of AS-external LSA in OSPF. Please enlighten us on this issue. Any experience or idea will be greatly appreciated. Thanks in advance. Regards, Jung. ------=_NextPart_000_002F_01C297A1.4DFAB500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
cc to=20 Carlos
-----Original Message-----
From:=20 owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Intae = Jung
Sent: Friday, November 29, 2002 9:09 AM
To:=20 mpls-ops@mplsrc.com; mpls@UU.NET
Subject: Regarding LDP=20 scalability

Hello,
I'd like to ask a couple = of=20 questions regarding a scalability of LDP,
especially when it is = deployed=20 in an ATM-LSR, adopting Downstream on
Demand distribution with = conservative=20 label retension and ordered control,
where labels (VPI/VCI) are a=20 relatively scarce resource that must be conserved
in ATM switch. = The=20 VPI/VCI is a particularly valuable and limited resource that =
should be=20 saved when an ATM LSR is not able to support VC-merging=20 capability.
Unfortunately the system I'm managing has no VC-merging = capability.
As defined in the standard, LDP attempts to setup or = release a=20 hop-by-hop LSP
whenever a new route is added or deleted in an ATM = LER=20 through routing protocols,
mainly IGP such as OSPF, ISIS or = RIP.
Let me=20 assume a sample ATM-MPLS network as follows.

Network1 - R1 = <->=20 LER1 <-> LSR1 <-> LSR2 <-> LER2 <-> R2 -=20 Network2

<---IP Network---><------------MPLS=20 Network---------><---IP Network--->

R1, R2: Router = operating=20 IGP (OSPF or RIP)
LER1, LER2: Edge ATM LSR operating LDP and IGP = (iBGP if=20 needed)
LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or=20 IS-IS)

OSPF or RIP is used in the IP Network and OSPF or IS-IS = is=20 deployed
in the MPLS Network. An i-BGP session could be setup = between LER1=20 and LER2
if needed, but not necessarily since LER1 and LER2 are not = supposed to provide
BGP/MPLS functionality, in other words, they = don't=20 work as a PE(Provider Edge) router.
LER1, LER2, LSR1 and LSR2 = support only=20 LDP as an MPLS signaling protocol.

The problem is that the = number of=20 LSP's from LER1 to LER2 increases
as the number of networks = increases in=20 the Network2, meaning that the number of
routing entries in LER1 = increases=20 accordingly, wherease the number of LSPs supported
by LER1 is a lot = smaller=20 than the number of its route entries.
Eventually, as the number of = LSPs=20 setup exceeds the maximum number of LSP's,
we'll not be able to = setup an=20 LSP any more even though new routes are added.
As I mentioned = above, LSR1=20 and LSR2 don't support VC-merging capability,
thus the scalability = becomes=20 quite servere.
Therefore w're trying to figure out how to support a = lot of=20 routing entries using
a limited number of LSP's. We are trying to = come up=20 with a mechanism that setups
just one LSP between LER1 and LER2, = which=20 could be shared between all best-effort
traffic between Network1 = and=20 Networks2.

The problem we faced is how to setup only 1 LSPs = between=20 LERs automatically,
and then how to map a lot of route entries to = the=20 shared LSP.
Although two LER's are shown in the example, the number = of=20 LSP's between LER's
can be quite large as the number of LER's=20 increases.
We're considering to setup a full-mesh iBGP sessions = between all=20 LER's, and
to use BGP next hop gateway in order to get an = FEC-to-NHFLE=20 mapping.
In other words, routes from Network2 will be redistributed = to LER1=20 via iBGP session
between LER1 and LER2, and then LER1 will setup = just one=20 LSP for the BGP next hop
address and map all routes from Network1 = to the=20 LSP.
However it enforces us to setup iBGP sessions between all of = LER's=20 even though
we don't need them unless we deploy MPLS. We're also = wondering=20 whether
we'll be able to solve the problem using any IGP = capability, like=20 tag field of AS-external
LSA in OSPF.

Please enlighten us = on this=20 issue.
Any experience or idea will be greatly = appreciated.
Thanks in=20 = advance.

Regards,

Jung.
------=_NextPart_000_002F_01C297A1.4DFAB500-- From owner-mpls@UU.NET Fri Nov 29 22:13:58 2002 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 ESMTP id WAA14624 for ; Fri, 29 Nov 2002 22:13:58 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrdt03550 for ; Sat, 30 Nov 2002 03:16:42 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnrdt01999; Sat, 30 Nov 2002 03:15:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrdt01603 for mpls-outgoing; Sat, 30 Nov 2002 03:15:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnrdt01596 for ; Sat, 30 Nov 2002 03:15:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnrds22783 for ; Sat, 30 Nov 2002 03:14:44 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrds18438 for ; Sat, 30 Nov 2002 03:14:43 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQnrds18433 for ; Sat, 30 Nov 2002 03:14:43 GMT Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 29 Nov 2002 22:14:41 -0500 Message-ID: <000d01c2981e$a4855ec0$ef13588a@movaz.com> From: "Adrian Farrel" To: "Wijnen, Bert \(Bert\)" , "Mpls \(E-mail\)" References: Subject: Re: review of mpls-mgmt-overview revision 02 Date: Fri, 29 Nov 2002 22:14:47 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 30 Nov 2002 03:14:43.0144 (UTC) FILETIME=[A0A58C80:01C2981E] Sender: owner-mpls@UU.NET Precedence: bulk Bert, Thanks. All nits are most welcome. I, for one, welcome your efforts to get RFCs in clear and correct English. A couple of follow-up questions/comments in the snipped text below... Cheers, Adrian ----- Original Message ----- From: "Wijnen, Bert (Bert)" > A lot of it is indeed nits/spelling/grammar > stuff... do I have to repat that for all docs, or can I assume > that the authors/editors will seriously check those things > themselves? Hmmm. I know what you SHOULD be able to asume... > - I see you use mib module names with an underscore, for example > MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB > Better get that in sync. True for most mib module names I believe Ah! I made this global change after I thought I heard Tom suggest that you said that the use of underscore was a requirement. At least one of us is out of synch here - I will change back to hyphen. > - Make descriptors consistent. Like > - mplsLdpEntityFrameRelayXxxxx > - mplsLdpEntityConfFrXxxx > so either make all freme-relay stuff xxxFrameRelayYyy or xxxFrYyy > but do not mix all that. I also wonder why in some case > Fr comes before the Xxxx and in other cases after it. > - mplsLdpEntityFrameRelayXxxxx > - mplsLdpEntityConfFrXxxx > why not mplsLdpEntityFrameRelayConfXxxx > Are mplsTunnelResourceTable and mplsTunnelCRDLPResTable both "resource" > tables? If so, then why not use "Resource" in both cases, or just "Res" > in both cases? Consistency please!!!!! > So Tunnel Computed Hop Table is: mplsTunnelCHopTable > and Tunnel Actual Hop Table is: mplsTunnelARHopTable > is the R for Route? If so then add Route in there Agreed. This draft, however, can only report what is in the MIB modules themselves. Tom and Joan - relying on you to pick up these things and then I'll change the overview to match. > Question: Is there also a mplsTunnelRSVPResTable? If yes, then I am > missing it here, if no, then why is that not needed? Good question. No there is no RSVP resource table. CR-LDP resource specification is a superset of RSVP resource specification. I will add a note explaining. > - sect 7.2 > ".. mplsTunnelMaxHops defines the size of route that may be configured > on the LSR." > I have difficulty understanding what that means. > What is the "size of route"? Syntax is "size of route that", but I agree that this could be clearer. > - Your references to PWE3 and PPVPN WG docs are listed as normative. > I doubt that they really are. In any event, if they are normative, > then they will have to be ready for RFC at the same time that this > doc goes to RFC. You're right. Old reference from when we thought we were going to include them in detail. > - Your split of references for the SNMP boilerplate text is not > correct. The correct split is: [SNIP] > - We're working on the new MIB boilerplate. Much shorter. Not 100% stable > yet. If you prefer to use it (I assume the new boiler plate will be > stable by the time you go to RFC-Editor queue), then I can send you what > the curretn text looks like. I will wait as late as I can and then include the most up-to-date version. But... Do you consider that the boilerplate is appropriate for inclusion in this overview or should I aim to hack it down? Actually, if the new material is shorter, perhaps it will be fine. From owner-mpls@UU.NET Fri Nov 29 22:31:39 2002 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 ESMTP id WAA15057 for ; Fri, 29 Nov 2002 22:31:39 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrdu04556 for ; Sat, 30 Nov 2002 03:34:17 GMT Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnrdu02235; Sat, 30 Nov 2002 03:33:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrdu02807 for mpls-outgoing; Sat, 30 Nov 2002 03:33:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQnrdu02794 for ; Sat, 30 Nov 2002 03:32:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQnrdu27297 for ; Sat, 30 Nov 2002 03:31:26 GMT Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrdu15784 for ; Sat, 30 Nov 2002 03:31:26 GMT Received: from atlntex01.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQnrdu15773 for ; Sat, 30 Nov 2002 03:31:26 GMT Received: from BLIULAPTOP ([172.16.8.184]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 29 Nov 2002 22:31:24 -0500 Message-ID: <002b01c29820$fa957730$ef13588a@movaz.com> From: "Adrian Farrel" To: "'mpls@uu.net'" Subject: LDP Restart Applicablity Statement - Comments please Date: Fri, 29 Nov 2002 22:31:31 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 30 Nov 2002 03:31:25.0560 (UTC) FILETIME=[F6221780:01C29820] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I gave a brief overview of draft-farrel0mpls-ldp-restart-applic-01.txt in Atlanta and asked that it move forward as WG document not least because it was requested by the chairs and because its existence will help the progress of draft-ietf-mpls-ldp-ft and draft-ietf-mpls-ldp-restart as they try to become RFCs. It seemed to be the case in Atlanta that very few people had read the draft and as Bert has commented elsewhere we should at least get 10 or 20 people to read drafts before they become WG documents. So... I believe implementers of LDP need to give serious consideration to at least one of draft-ietf-mpls-ldp-ft and draft-ietf-mpls-ldp-restart. This applicability statement should help them decide whether and which to implement. It would be a great help if all those concerned with LDP could cast an eye over the draft and send comments to the mailing list. At the moment, comments such as "read it, looks good" or "read it, don't like it" would be as useful as detailed feedback since they will give us some feeling about the value of the draft. Thanks, Adrian From owner-mpls@UU.NET Sat Nov 30 10:40:49 2002 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 ESMTP id KAA06928 for ; Sat, 30 Nov 2002 10:40:49 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrfq24452 for ; Sat, 30 Nov 2002 15:43:32 GMT Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQnrfq16591; Sat, 30 Nov 2002 15:39:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQnrfq07468 for mpls-outgoing; Sat, 30 Nov 2002 15:39:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQnrfq07453 for ; Sat, 30 Nov 2002 15:39:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQnrfq28271 for ; Sat, 30 Nov 2002 15:39:14 GMT Received: from cmr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: localhost [127.0.0.1]) id QQnrfq18374 for ; Sat, 30 Nov 2002 15:39:13 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 QQnrfq18369 for ; Sat, 30 Nov 2002 15:39:13 GMT Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gAUFdBr14162 for ; Sat, 30 Nov 2002 10:39:11 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 30 Nov 2002 16:39:10 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: Adrian Farrel , "Mpls (E-mail)" Subject: RE: review of mpls-mgmt-overview revision 02 Date: Sat, 30 Nov 2002 16:39:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Inline > -----Original Message----- > From: Adrian Farrel [mailto:afarrel@movaz.com] > Sent: zaterdag 30 november 2002 4:15 > To: Wijnen, Bert (Bert); Mpls (E-mail) > Subject: Re: review of mpls-mgmt-overview revision 02 > > > Bert, > Thanks. All nits are most welcome. I, for one, welcome your > efforts to get RFCs in clear and correct English. > > A couple of follow-up questions/comments in the snipped text below... > > Cheers, > Adrian > ----- Original Message ----- > From: "Wijnen, Bert (Bert)" > .. > > Question: Is there also a mplsTunnelRSVPResTable? If yes, then I am > > missing it here, if no, then why is that not needed? > > Good question. > No there is no RSVP resource table. CR-LDP resource > specification is a superset of RSVP resource specification. > I will add a note explaining. > Maybe the name should not suggest that it is CR-LDP specific then? > > - Your split of references for the SNMP boilerplate text is not > > correct. The correct split is: > [SNIP] > > - We're working on the new MIB boilerplate. Much shorter. Not 100% stable > > yet. If you prefer to use it (I assume the new boiler plate will be > > stable by the time you go to RFC-Editor queue), then I can send you what > > the curretn text looks like. > > I will wait as late as I can and then include the most up-to-date version. > But... > Do you consider that the boilerplate is appropriate for inclusion in this > overview or should I aim to hack it down? Actually, if the new material is > shorter, perhaps it will be fine. > As far as I am concerned, I do not even need the boiler-plate here. If the new (shorter) boiler plate is ready, then it would not hurt, but I do not think it is mandatory to have it in the overview doc. Up to you Bert