From owner-mpls@UU.NET Fri Jun 1 00:20:08 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16197 for ; Fri, 1 Jun 2001 00:20:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrmf00083; Fri, 1 Jun 2001 04:19:26 GMT Received: by mail-control.mail.uu.net id QQkrmf23862 for mpls-outgoing; Fri, 1 Jun 2001 04:18:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkrmf23855 for ; Fri, 1 Jun 2001 04:18:49 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 QQkrmf23752 for ; Fri, 1 Jun 2001 04:17:56 GMT Received: from tomts7-srv.bellnexxia.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomts7.bellnexxia.net [209.226.175.40]) id QQkrmf28528 for ; Fri, 1 Jun 2001 04:17:55 GMT Received: from blasterspad ([64.229.132.18]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010601041753.CQZX16174.tomts7-srv.bellnexxia.net@blasterspad>; Fri, 1 Jun 2001 00:17:53 -0400 From: "AMK Networking Technologies Inc." To: "'Chris Kuszmaul'" , Subject: RE: LDP requires break-before-make Date: Fri, 1 Jun 2001 00:24:59 -0400 Message-ID: <000201c0ea52$d222fca0$093efea9@blasterspad> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B142656.C7E831A0@pluris.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Chris, I don't see the requirement for this functionality as LDP offers the following: 1) Two distribution methods ( DoD and DU) 2) Two control methods (ordered and Independent) 3) Two retention methods (liberal and conservative) These can be combined to achieve varying results *some not so desirable*, like break-and-make and make-and-no-break. If the scenario you describe is like this....a label mapping is received by a LSR for a FEC which has bound a label, I am assuming that this mapping is received by that LSR on a different interface. That would also mean that the network is configured for DU at the very least. The LSR would not necessarily inform the upstream LSR but rather use the new label and release the existing label...in that case it is not a break-make situation. If the scenario you describe is like this....The MPLS domain is configured for Liberal Label Retention and a new next hop is discovered by a particular LSR for a particular FEC (the next hop is a different interface...logical or physical) then the existing label is released and the label stored in the LIB for that next hop interface is used...again this is not a Break-Make. If a connection or downstream router fails then that is again a different set of procedures depending on the configuration of the LSRs in the MPLS domain. In that case DoD with conservative retention mode does cause a break-make...life is full of trade offs. Please feel free to comment...If I misunderstood you, I apologize, please restate your question. regards, Micheal -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Chris Kuszmaul Sent: Tuesday, May 29, 2001 6:45 PM To: David Charlap; mpls@UU.NET Subject: LDP requires break-before-make Before a label can be mapped to an FEC that has already been mapped, the LSR must release the old label (prompted perhaps by a withdrawal message). Thus, LDP calls for a break-before-make on LSP updates. It would seem a straightforward matter for the protocol to include a withdraw-and-map message that performs this sequence atomically, and so preserves a make-before-break condition. Is there some reason for not providing for this kind of functionality? Thanks for any comments. CLK PS: The careful reader will realize that I have mentioned this issue before in the thread [Re: Receive Label Receive !!], but have not seen any reply. This is an attempt to focus the question and broaden the pool of possible respondents. From owner-mpls@UU.NET Fri Jun 1 09:09:25 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07469 for ; Fri, 1 Jun 2001 09:09:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrno12795; Fri, 1 Jun 2001 13:07:14 GMT Received: by mail-control.mail.uu.net id QQkrno13826 for mpls-outgoing; Fri, 1 Jun 2001 13:06:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrno13739 for ; Fri, 1 Jun 2001 13:06: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 QQkrno06014 for ; Fri, 1 Jun 2001 13:06:25 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f14.law14.hotmail.com [64.4.21.14]) id QQkrno19833 for ; Fri, 1 Jun 2001 13:06:24 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 1 Jun 2001 06:06:23 -0700 Received: from 212.153.183.58 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 01 Jun 2001 13:06:23 GMT X-Originating-IP: [212.153.183.58] From: "MP LS" To: mpls-ops@mplsrc.com, MPLS@UU.NET Subject: Cell interleave and ATM-LSR Date: Fri, 01 Jun 2001 15:06:23 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Jun 2001 13:06:23.0712 (UTC) FILETIME=[A8AD1600:01C0EA9B] Sender: owner-mpls@UU.NET Precedence: bulk Hello all, I have some questions i am courious about, Because i read the MPLS RFC 3031 i also read the part of cell interleaving. I just aks myself how most vendors have solved this problem. Another question is how ATM-LSRs use there MPLS signalling. I know they use VC 32 to send their LDP and IGP information It is sent in TCP/IP messages. Do they put those TCP/IP messages just in AAL 5 ?? and do all routers then unpack the TCP/IP packets from the AAL5 frame?? It is a bit confusing to me !! I'll hope anyone can answer my questions. Greetings Niels Sitters. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Fri Jun 1 10:22:24 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08768 for ; Fri, 1 Jun 2001 10:22:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrnt09091; Fri, 1 Jun 2001 14:20:22 GMT Received: by mail-control.mail.uu.net id QQkrnt18281 for mpls-outgoing; Fri, 1 Jun 2001 14:19:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrnt18249 for ; Fri, 1 Jun 2001 14:19: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 QQkrnt13996 for ; Fri, 1 Jun 2001 14:18:03 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 QQkrnt06645 for ; Fri, 1 Jun 2001 14:18:02 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 KAA09662; Fri, 1 Jun 2001 10:17:59 -0400 (EDT) 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 KAA18253; Fri, 1 Jun 2001 10:17:56 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 10:17:55 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0211EB57@whq-msgusr-02.pit.comms.marconi.com> From: "Krishnan, Vijay G." To: "'MP LS'" Cc: mpls-ops@mplsrc.com, MPLS@UU.NET Subject: RE: Cell interleave and ATM-LSR Date: Fri, 1 Jun 2001 10:17:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk -----Original Message----- From: MP LS [mailto:stagempls@hotmail.com] Sent: Friday, June 01, 2001 9:06 AM To: mpls-ops@mplsrc.com; MPLS@UU.NET Subject: Cell interleave and ATM-LSR Niels, Cell interleaving is an issue only in case of merging of labels on pure ATM switches (LSRs). When you merge LSPs in a non-merge capable ATM LSR, the cells from the two different LSPs get interleaved. VC 32 is for control packets (unlabelled traffic) and hence will have to be reassembled to IP packet on each LSR. Therefore no cell interleaving for VC 32. thanks Vijay Hello all, I have some questions i am courious about, Because i read the MPLS RFC 3031 i also read the part of cell interleaving. I just aks myself how most vendors have solved this problem. Another question is how ATM-LSRs use there MPLS signalling. I know they use VC 32 to send their LDP and IGP information It is sent in TCP/IP messages. Do they put those TCP/IP messages just in AAL 5 ?? and do all routers then unpack the TCP/IP packets from the AAL5 frame?? It is a bit confusing to me !! I'll hope anyone can answer my questions. Greetings Niels Sitters. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Fri Jun 1 10:30:47 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08881 for ; Fri, 1 Jun 2001 10:30:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrnt21515; Fri, 1 Jun 2001 14:28:47 GMT Received: by mail-control.mail.uu.net id QQkrnt19366 for mpls-outgoing; Fri, 1 Jun 2001 14:28:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrnt19346 for ; Fri, 1 Jun 2001 14:28:04 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 QQkrnt10434 for ; Fri, 1 Jun 2001 14:26:10 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkrnt16093 for ; Fri, 1 Jun 2001 14:26:09 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 651E294006; Fri, 1 Jun 2001 10:26:09 -0400 (EDT) Message-ID: <3B17A601.EF168134@sandburst.com> Date: Fri, 01 Jun 2001 10:26:09 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Kuszmaul Cc: MPLS Mailing List Subject: Re: LDP requires break-before-make References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> <3AF06AB7.81EE10AB@marconi.com> <3AF08792.4A56B50F@pluris.com> <3B142656.C7E831A0@pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Chris, I understand your concern. A few years ago (early '98) I had proposed a semantic interpretation for LDP that directly related to this. The response was to explicitly prohibit the behavior which would have had this semantic. I had suggested that (in DU mode) an LSR that advertised a new label for exactly the same FEC as it had previously advertised a different label meant for the upstream LSR to replace the previous label with the new one. Over time, I came to undestand why this may have been a little too simplistic. Also, it may be needed when DoD label advertisement is being used as well. I think your basic idea of using a new message type will work. I had thought of that and talked with a couple of people on the LDP design team about it - and they were not too receptive to the idea as part of the base LDP specification (adds complexity not really required for basic functionality). Also - at the time - I thought it possible to achieve a very similar result by simply including both the label withdraw and the new label mapping in the same PDU (an LDP PDU can contain multiple LDP messages). Of course, this latter approach depends on a few things: o that you are not correct in your assertion that a downstream LSR is required to wait for a label release message prior to sending a new label mapping (*), o that an upstream LSR actually looks for a 'replacement' label mapping message in a PDU that contains a label withdraw message, o that this upstream LSR processes multiple messages in a single PDU in the order in which they appear in the PDU and o that the dowbstream LSR put them in the PDU in the order in which it expected them to be processed (+). * I think that the requirement is that the downstream LSR MUST not re-use the same label until it receives a label release for a label it has withdrawn. I do not think there is any statement in the specification that prohibits sending a new label mapping prior to receiving a label release for the previous mapping for the same FEC. Please let me know if there is text in the spec to the contrary. + Given that I am right in my interpretation of the current spec wrt issuing a new label mapping after a label withdraw, the last two bullets naturally fall out since the current restriction on sending a new label mapping (with a different label) prior to withdrawing a prior label mapping imposes an ordering resptriction on adding messages to a PDU and processing them on receipt. This ordering is not hard to achieve. Essentially, a downstream LSR can try this approach and hope that the upstream LSR was built to be robust and resilient (either using the approach above, or some other approach). -- Eric Gray You wrote: > Before a label can be mapped to an FEC that has already been mapped, the LSR > must release the old label (prompted perhaps by a withdrawal message). Thus, LDP > calls for a break-before-make on LSP updates. It would seem a straightforward > matter for the protocol to include a withdraw-and-map message that performs this > sequence atomically, and so preserves a make-before-break condition. > > Is there some reason for not providing for this kind of functionality? > > Thanks for any comments. > > CLK > > PS: The careful reader will realize that I have mentioned this issue before in > the thread [Re: Receive Label Receive !!], but have not seen any reply. This is > an attempt to focus the question and broaden the pool of possible respondents. From owner-mpls@UU.NET Fri Jun 1 10:43:50 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09033 for ; Fri, 1 Jun 2001 10:43:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrnu04259; Fri, 1 Jun 2001 14:42:35 GMT Received: by mail-control.mail.uu.net id QQkrnu21212 for mpls-outgoing; Fri, 1 Jun 2001 14:42:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrnu21191 for ; Fri, 1 Jun 2001 14:41:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkrnu18245 for ; Fri, 1 Jun 2001 14:39:32 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkrnu00760 for ; Fri, 1 Jun 2001 14:39:31 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 5905194006; Fri, 1 Jun 2001 10:39:30 -0400 (EDT) Message-ID: <3B17A922.49A58CA4@sandburst.com> Date: Fri, 01 Jun 2001 10:39:30 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: nagendras@netbrahma.com Cc: Chris Kuszmaul , David Charlap , mpls@UU.NET Subject: Re: LDP requires break-before-make References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tomar, An LSR may assign any semantics it wishes to the labels it distributes to peers. If it assigns the 'wrong' semantics (using some definition of 'wrong'), however, it may be required to change (withdraw and map again) this label to conform to a new semantic if the nature of the LSP changes. This can have extremely bad effects on both the packet forwarding for the LSP associated with this label and the status of the LSP with respect to all upstream LSRs (potentially including the entire MPLS domain). There are several ways to deal with this, including having a way to make-before-break on a specific label mapping. It would be a good idea to have a well understood approach. At present, the only (even partially) understood approach is to avoid assigning semantics to specific labels that can lead to this situation. As to how to do this, don't ask. :-) -- Eric Gray You wrote: > Hi! > I cannot understand why an LSR (downstream) will need to withdraw a > label mapping for a particular FEC from its upstream peer and send a new > mapping for the same FEC this time with a different label > (withdraw-and-map message). It can as well use the old (incoming) label > for whatever purpose it's planning to use the new label. > The only reason can be setting up of multiple equal-cost paths, which the > RFC says is not supported now. > I would like to know if there are any other implications. > > -- tomar > > On Tue, 29 May 2001, Chris Kuszmaul wrote: > > > > > Before a label can be mapped to an FEC that has already been mapped, the LSR > > must release the old label (prompted perhaps by a withdrawal message). Thus, LDP > > calls for a break-before-make on LSP updates. It would seem a straightforward > > matter for the protocol to include a withdraw-and-map message that performs this > > sequence atomically, and so preserves a make-before-break condition. > > > > Is there some reason for not providing for this kind of functionality? > > > > Thanks for any comments. > > > > CLK > > > > PS: The careful reader will realize that I have mentioned this issue before in > > the thread [Re: Receive Label Receive !!], but have not seen any reply. This is > > an attempt to focus the question and broaden the pool of possible respondents. > > From owner-mpls@UU.NET Fri Jun 1 11:01:02 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09387 for ; Fri, 1 Jun 2001 11:01:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrnv21556; Fri, 1 Jun 2001 14:57:41 GMT Received: by mail-control.mail.uu.net id QQkrnv23509 for mpls-outgoing; Fri, 1 Jun 2001 14:57:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkrnv23482 for ; Fri, 1 Jun 2001 14:56:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkrnv16818 for ; Fri, 1 Jun 2001 14:56:27 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQkrnv09296 for ; Fri, 1 Jun 2001 14:56:26 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f51Erdh01483; Fri, 1 Jun 2001 10:53:39 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 10:57:33 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D0220404019F6904@mail1.tellium.com> From: Dimitrios Pendarakis To: "'Jonathan Lang'" , "'Fong Liaw'" , "'suresh Katukam'" Cc: "'Jennifer Yates'" , mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: Last call - RSVP problems Date: Fri, 1 Jun 2001 10:57:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jonathan, The problem with being in meetings is it took me a long time to respond -:) So, I 'll try to provide a summary of the messages exchanged as well as my understanding of our off-line discussion on the applicability of RSVP and LMP Hello mechanisms. An attempt on terminology clarification first: Control channel: This is a logical channel over which IP control packets are transported between two network elements (for example a UNI-C and UNI-N in the case of the OIF UNI). A control channel can be realized in multiple ways, for example, in-fiber using SONET/SDH overhead bytes, out-of-band over an Ethernet, etc. A pair of network elements may be connected by multiple control channels, used either concurrently or in a primary-backup configuration. Control channel failures can be detected using link management procedures, such as the LMP Hello mechanism. Signaling channel: This is a logical channel over which signaling messages are exchanged between two peers. The signaling channel is realized using (potentially multiple) control channels and it operation relies on processing of signaling messages by the respective peer signaling entities. A signaling channel failure is the result of failure of all control channels, or failure of a signaling entity. Signaling channel failures can be detected using the RSVP hello mechanism (assuming of course RSVP is the signaling protocol used!). Hope this helps, Dimitrios > -----Original Message----- > From: Jonathan Lang [mailto:jplang@calient.net] > Sent: Wednesday, May 30, 2001 2:08 PM > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong Liaw'; > 'suresh Katukam' > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > Subject: RE: Last call - RSVP problems > > > Dimitrios, > The luxury of being in meetings all morning is that I had > the chance to > read your email as well as the responses from David, Lyndon, > and Eric before > I respond. Since I agree with their response, I will try to be brief. > Using RSVP Hellos to detect RSVP module failures is in my > mind the correct > usage for them. Control channel failures should be detected > by mechanisms > designed to detect them (e.g., LMP Hellos). One scenario > that carriers are > interested in supporting is the notion of having parallel > redundant control > channels for signaling purposes. We will need to support > other mechanisms > for detecting control channel failures in this case. > > Thanks, > Jonathan > > > -----Original Message----- > > From: Dimitrios Pendarakis [mailto:DPendarakis@tellium.com] > > Sent: Wednesday, May 30, 2001 7:24 AM > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam' > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > Subject: RE: Last call - RSVP problems > > > > > > Jonathan, > > > > Could you please clarify why you think RSVP Hello doesn't work for > > parallel (redundant) control channels? Control channel redundancy > > is obviously important; however I don't think it relates to the > > usefulness of the RSVP hello mechanism, at least in the context of > > this discussion. > > > > The whole issue is one of layering: LMP hello allows you to detect > > individual link (or control channel) failures; RSVP Hello allows > > you to detect that you 've lost contact with your signaling peer > > for whatever reason (failure of all redundant control channels, > > failure of the RSVP daemon, etc.). Since they operate at different > > levels they are to some extend complementary; once RSVP Hello tells > > you that your peer is not reachable, you could use LMP Hello's to > > try to pinpoint where the problem occurred. > > > > For clarification, the "control channel failure" mentioned in > > Fong's mail that started this discussion refers to a failure of the > > signaling channel, i.e., inability to communicate with your > signaling > > peer, not failure of specific (individual) control > channels. As such, > > I still believe RSVP Hello is a more accurate detection mechanism. > > > > Please see some additional comments inline. > > > > Thanks, > > Dimitris > > > > > > > If you're using the RSVP Hello to detect the failure of the > > > RSVP module > > > only, then this is fine. If you're using the RSVP Hello to > > detect (or > > > rather, infer) control channel failures, I have a problem. > > > For starters, I > > > don't think it works for parallel (redundant) control > > > channels; if control > > > channel redundancy is *not* important for SPs, then it's not > > > as much of an > > > issue, however, I think you're overloading the semantics of > > > the RSVP Hello. > > > > > > See additional comments inline. > > > > > > Thanks, > > > Jonathan > > > > > > > > > > > Hi Jonathan, > > > > > > > > What needs to be detected here is the inability to send and > > > > receive signaling messages to and from your RSVP peer. In this > > > > respect, using RSVP Hello is a more accurate mechanism for > > > > detecting failures since it is part of the RSVP protocol and > > > > independent of the link layer used to realize the control > > > > channel. As you point out, if you prefer redundant control > > > > channels for resiliency, and want to rely on LMP only, you have > > > > to correlate all LMP detected failures in order to declare a > > > > control channel failure. > > > This is not correct. LMP allows you to detect individual > > > control channel > > > failures, even when there are multiple (redundant) control > > > channels. The > > > RSVP Hello cannot do this. > > > > > > > Sure, as I pointed above, RSVP Hello is not intended to detect > > individual link failures. At the risk of sounding repetitive, the > > point here is that these are different mechanisms that serve > > different purpose. For example, if you have 3 (redundant) > IP control > > channels and rely on LMP Hello only, in order to infer > failure of the > > signaling channel with your peer, you would have to correlate LMP > > failures in all three channels. > > > > > > With RSVP Hello you would rely on a > > > > single set of event(s) to detect the failure. > > > To be clear, the failure of the RSVP module. > > > > Or simultaneous failure of all IP control channels... > > > > > > > > > To go even further, what if all your control channels > are working > > > > fine, but your RSVP daemon has crashed, for whatever reason. > > > > LMP hellos will keep going across but RSVP messages will not... > > > This is where the RSVP Hello has its place. > > > > > > > > > > > All this points to the (certainly non-trivial) problem > of failure > > > > detection and correlation at different layers. I am not > trying to > > > > say that RSVP Hello is the perfect or only mechanism we > > should rely > > > > on, but it certainly has a place in addressing the problem. > > > agreed. see above comment. > > > > > > > > > > > Thanks, > > > > Dimitris > > > > > > > > PS. Hopefully we are not too far apart so we might not have > > > > to keep the discussion going for too long :-) > > > > In any case I believe it has some relevance here as well. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > Sent: Friday, May 25, 2001 6:56 PM > > > > > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong > Liaw'; 'suresh > > > > > Katukam'; v.sharma@ieee.org > > > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > > > Subject: RE: Last call - RSVP problems > > > > > > > > > > > > > > > Dimitris, > > > > > The RSVP Hello Extension is intended to detect node > > > > failures and not > > > > > necessarily link (control channel) failures. In particular, > > > > > the tunnel > > > > > draft says, "It should be noted that node failure detection > > > > > is not the same > > > > > as a link failure detection mechanism, particularly in the > > > > > case of multiple > > > > > parallel unnumbered links." What happens if you want > > > > > redundant control > > > > > channels for control-channel resiliency? I believe you would > > > > > still want a > > > > > mechanism to detect control channel (link-layer) failures. > > > > > > > > > > In LMP, you can have multiple active control channels > > > > > between a pair of > > > > > nodes. You can configure control channels over shared > > > > > Ethernet and over > > > > > SONET/SDH overhead, etc. You send keep-alive Hellos over > > > > each control > > > > > channel. If you so desire, you can send all signaling > > > > > messages over the > > > > > Ethernet control channels. You can also choose to send all > > > > > remaining LMP > > > > > messages over the SONET/SDH-based control channels. Keeping > > > > > RSVP Hellos as > > > > > "optional" would be fine. Making them mandatory doesn't seem > > > > > like the right > > > > > solution. > > > > > > > > > > Thanks, > > > > > Jonathan > > > > > > > > > > P.S. Should we move this discussion on the OIF list?? > > > > > > > > > > > -----Original Message----- > > > > > > From: Dimitrios Pendarakis [mailto:DPendarakis@tellium.com] > > > > > > Sent: Friday, May 25, 2001 3:16 PM > > > > > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; > > > > > v.sharma@ieee.org > > > > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > > > > Subject: RE: Last call - RSVP problems > > > > > > > > > > > > > > > > > > Hi Jonathan, > > > > > > > > > > > > One point to consider is that the signaling control > > > > > > channel might be realized over a different link layer > > > > > > than LMP. For example, LMP might be running in-fiber > > > > > > over SONET/SDH overhead bytes, while RSVP is running > > > > > > over an out-of-band network such a shared Ethernet. > > > > > > RSVP Hello allows independent detection of signaling > > > > > > channel failure, so it's a useful option to keep. > > > > > > > > > > > > Thanks, > > > > > > Dimitris > > > > > > > > > > > > Dimitris Pendarakis > > > > > > Tellium, Inc. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > > > Sent: Friday, May 25, 2001 5:30 PM > > > > > > > To: 'Fong Liaw'; 'suresh Katukam'; v.sharma@ieee.org > > > > > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > > > > > Subject: RE: Last call - RSVP problems > > > > > > > > > > > > > > > > > > > > > Fong, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Same as (2), any proposals that remove the refresh > > > mechanism > > > > > > > > is going to be difficult to prove that all cases > > > are covered. > > > > > > > > > > > > > > > > Instead, we (will) recommend the following in OIF UNI > > > > document: > > > > > > > > > > > > > > > > Use RSVP Hello to detect control channel failure. > > > > > > > Why wouldn't you use the LMP Hello to detect > > control channel > > > > > > > failure? This > > > > > > > is exactly what it is designed for. From > > > > > > > draft-ietf-mpls-lsp-tunnel-08.txt, > > > > > > > > > > > > > > "This (RSVP Hello) mechanism is intended to be > used when > > > > > > > notification of > > > > > > > link layer > > > > > > > failures is not available and unnumbered links are not > > > > > > > used, or when > > > > > > > the failure detection mechanisms provided by the link > > > > > > layer are not > > > > > > > sufficient for timely node failure detection." > > > > > > > > > > > > > > > If a control channel failure is detected, > LSPs states > > > > > > > > are maintained as if a node continues to receive > > > > > > > > RSVP refresh message from the failed control channel. > > > > > > > > The recommended Hello timer will be in second range, > > > > > > > > instead of ms range specified in RSVP-TE draft. > > > > > > > > > > > > > > > > If a control channel failed permanently, manual > > > > intervention > > > > > > > > may be required. This is to be studied. > > > > > > > > > > > > > > > > p.s The text is currently being drafted as we type. > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Jun 1 11:39:21 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10124 for ; Fri, 1 Jun 2001 11:39:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrny02828; Fri, 1 Jun 2001 15:37:31 GMT Received: by mail-control.mail.uu.net id QQkrny17393 for mpls-outgoing; Fri, 1 Jun 2001 15:36:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkrny17319 for ; Fri, 1 Jun 2001 15:36:42 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 QQkrny16427 for ; Fri, 1 Jun 2001 15:35:08 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe18.law10.hotmail.com [64.4.14.122]) id QQkrny11422 for ; Fri, 1 Jun 2001 15:35:07 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 1 Jun 2001 08:35:06 -0700 X-Originating-IP: [12.34.209.74] From: "Frank Hujber" To: "Dimitrios Pendarakis" , "'Jonathan Lang'" , "'Fong Liaw'" , "'suresh Katukam'" Cc: "'Jennifer Yates'" , , References: <0CD7D73C734BD411AEE100B0D0220404019F6904@mail1.tellium.com> Subject: Re: Last call - RSVP problems Date: Fri, 1 Jun 2001 11:32:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: X-OriginalArrivalTime: 01 Jun 2001 15:35:06.0660 (UTC) FILETIME=[6F2AE640:01C0EAB0] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dimitrios, Given your reply below, then might I ask... Is it true, then, that a signaling channel might be an LSP between the initiator and terminator nodes of a network-wide connection, which resides in or on a control channel? (Which I guess would make a signaling channel a specialized case of the control channel) ? Frank Hujber Alphion Corportaion fhujber@hotmail.com ----- Original Message ----- From: Dimitrios Pendarakis To: 'Jonathan Lang' ; 'Fong Liaw' ; 'suresh Katukam' Cc: 'Jennifer Yates' ; ; Sent: Friday, June 01, 2001 10:57 AM Subject: RE: Last call - RSVP problems > Jonathan, > > The problem with being in meetings is it took me a long > time to respond -:) > > So, I 'll try to provide a summary of the messages exchanged > as well as my understanding of our off-line discussion > on the applicability of RSVP and LMP Hello mechanisms. > > An attempt on terminology clarification first: > Control channel: This is a logical channel over which IP > control packets are transported between two network elements > (for example a UNI-C and UNI-N in the case of the OIF UNI). > A control channel can be realized in multiple ways, for example, > in-fiber using SONET/SDH overhead bytes, out-of-band over an > Ethernet, etc. > A pair of network elements may be connected by multiple control > channels, used either concurrently or in a primary-backup > configuration. Control channel failures can be detected using > link management procedures, such as the LMP Hello mechanism. > > Signaling channel: This is a logical channel over which signaling > messages are exchanged between two peers. The signaling channel > is realized using (potentially multiple) control channels and > it operation relies on processing of signaling messages by the > respective peer signaling entities. > A signaling channel failure is the result of failure of all control > channels, or failure of a signaling entity. Signaling channel > failures can be detected using the RSVP hello mechanism (assuming > of course RSVP is the signaling protocol used!). > > Hope this helps, > Dimitrios > > > -----Original Message----- > > From: Jonathan Lang [mailto:jplang@calient.net] > > Sent: Wednesday, May 30, 2001 2:08 PM > > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong Liaw'; > > 'suresh Katukam' > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > Subject: RE: Last call - RSVP problems > > > > > > Dimitrios, > > The luxury of being in meetings all morning is that I had > > the chance to > > read your email as well as the responses from David, Lyndon, > > and Eric before > > I respond. Since I agree with their response, I will try to be brief. > > Using RSVP Hellos to detect RSVP module failures is in my > > mind the correct > > usage for them. Control channel failures should be detected > > by mechanisms > > designed to detect them (e.g., LMP Hellos). One scenario > > that carriers are > > interested in supporting is the notion of having parallel > > redundant control > > channels for signaling purposes. We will need to support > > other mechanisms > > for detecting control channel failures in this case. > > > > Thanks, > > Jonathan > > > > > -----Original Message----- > > > From: Dimitrios Pendarakis [mailto:DPendarakis@tellium.com] > > > Sent: Wednesday, May 30, 2001 7:24 AM > > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam' > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > Subject: RE: Last call - RSVP problems > > > > > > > > > Jonathan, > > > > > > Could you please clarify why you think RSVP Hello doesn't work for > > > parallel (redundant) control channels? Control channel redundancy > > > is obviously important; however I don't think it relates to the > > > usefulness of the RSVP hello mechanism, at least in the context of > > > this discussion. > > > > > > The whole issue is one of layering: LMP hello allows you to detect > > > individual link (or control channel) failures; RSVP Hello allows > > > you to detect that you 've lost contact with your signaling peer > > > for whatever reason (failure of all redundant control channels, > > > failure of the RSVP daemon, etc.). Since they operate at different > > > levels they are to some extend complementary; once RSVP Hello tells > > > you that your peer is not reachable, you could use LMP Hello's to > > > try to pinpoint where the problem occurred. > > > > > > For clarification, the "control channel failure" mentioned in > > > Fong's mail that started this discussion refers to a failure of the > > > signaling channel, i.e., inability to communicate with your > > signaling > > > peer, not failure of specific (individual) control > > channels. As such, > > > I still believe RSVP Hello is a more accurate detection mechanism. > > > > > > Please see some additional comments inline. > > > > > > Thanks, > > > Dimitris > > > > > > > > > > If you're using the RSVP Hello to detect the failure of the > > > > RSVP module > > > > only, then this is fine. If you're using the RSVP Hello to > > > detect (or > > > > rather, infer) control channel failures, I have a problem. > > > > For starters, I > > > > don't think it works for parallel (redundant) control > > > > channels; if control > > > > channel redundancy is *not* important for SPs, then it's not > > > > as much of an > > > > issue, however, I think you're overloading the semantics of > > > > the RSVP Hello. > > > > > > > > See additional comments inline. > > > > > > > > Thanks, > > > > Jonathan > > > > > > > > > > > > > > Hi Jonathan, > > > > > > > > > > What needs to be detected here is the inability to send and > > > > > receive signaling messages to and from your RSVP peer. In this > > > > > respect, using RSVP Hello is a more accurate mechanism for > > > > > detecting failures since it is part of the RSVP protocol and > > > > > independent of the link layer used to realize the control > > > > > channel. As you point out, if you prefer redundant control > > > > > channels for resiliency, and want to rely on LMP only, you have > > > > > to correlate all LMP detected failures in order to declare a > > > > > control channel failure. > > > > This is not correct. LMP allows you to detect individual > > > > control channel > > > > failures, even when there are multiple (redundant) control > > > > channels. The > > > > RSVP Hello cannot do this. > > > > > > > > > > Sure, as I pointed above, RSVP Hello is not intended to detect > > > individual link failures. At the risk of sounding repetitive, the > > > point here is that these are different mechanisms that serve > > > different purpose. For example, if you have 3 (redundant) > > IP control > > > channels and rely on LMP Hello only, in order to infer > > failure of the > > > signaling channel with your peer, you would have to correlate LMP > > > failures in all three channels. > > > > > > > > With RSVP Hello you would rely on a > > > > > single set of event(s) to detect the failure. > > > > To be clear, the failure of the RSVP module. > > > > > > Or simultaneous failure of all IP control channels... > > > > > > > > > > > > To go even further, what if all your control channels > > are working > > > > > fine, but your RSVP daemon has crashed, for whatever reason. > > > > > LMP hellos will keep going across but RSVP messages will not... > > > > This is where the RSVP Hello has its place. > > > > > > > > > > > > > > All this points to the (certainly non-trivial) problem > > of failure > > > > > detection and correlation at different layers. I am not > > trying to > > > > > say that RSVP Hello is the perfect or only mechanism we > > > should rely > > > > > on, but it certainly has a place in addressing the problem. > > > > agreed. see above comment. > > > > > > > > > > > > > > Thanks, > > > > > Dimitris > > > > > > > > > > PS. Hopefully we are not too far apart so we might not have > > > > > to keep the discussion going for too long :-) > > > > > In any case I believe it has some relevance here as well. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > > Sent: Friday, May 25, 2001 6:56 PM > > > > > > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong > > Liaw'; 'suresh > > > > > > Katukam'; v.sharma@ieee.org > > > > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > > > > Subject: RE: Last call - RSVP problems > > > > > > > > > > > > > > > > > > Dimitris, > > > > > > The RSVP Hello Extension is intended to detect node > > > > > failures and not > > > > > > necessarily link (control channel) failures. In particular, > > > > > > the tunnel > > > > > > draft says, "It should be noted that node failure detection > > > > > > is not the same > > > > > > as a link failure detection mechanism, particularly in the > > > > > > case of multiple > > > > > > parallel unnumbered links." What happens if you want > > > > > > redundant control > > > > > > channels for control-channel resiliency? I believe you would > > > > > > still want a > > > > > > mechanism to detect control channel (link-layer) failures. > > > > > > > > > > > > In LMP, you can have multiple active control channels > > > > > > between a pair of > > > > > > nodes. You can configure control channels over shared > > > > > > Ethernet and over > > > > > > SONET/SDH overhead, etc. You send keep-alive Hellos over > > > > > each control > > > > > > channel. If you so desire, you can send all signaling > > > > > > messages over the > > > > > > Ethernet control channels. You can also choose to send all > > > > > > remaining LMP > > > > > > messages over the SONET/SDH-based control channels. Keeping > > > > > > RSVP Hellos as > > > > > > "optional" would be fine. Making them mandatory doesn't seem > > > > > > like the right > > > > > > solution. > > > > > > > > > > > > Thanks, > > > > > > Jonathan > > > > > > > > > > > > P.S. Should we move this discussion on the OIF list?? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dimitrios Pendarakis [mailto:DPendarakis@tellium.com] > > > > > > > Sent: Friday, May 25, 2001 3:16 PM > > > > > > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; > > > > > > v.sharma@ieee.org > > > > > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > > > > > Subject: RE: Last call - RSVP problems > > > > > > > > > > > > > > > > > > > > > Hi Jonathan, > > > > > > > > > > > > > > One point to consider is that the signaling control > > > > > > > channel might be realized over a different link layer > > > > > > > than LMP. For example, LMP might be running in-fiber > > > > > > > over SONET/SDH overhead bytes, while RSVP is running > > > > > > > over an out-of-band network such a shared Ethernet. > > > > > > > RSVP Hello allows independent detection of signaling > > > > > > > channel failure, so it's a useful option to keep. > > > > > > > > > > > > > > Thanks, > > > > > > > Dimitris > > > > > > > > > > > > > > Dimitris Pendarakis > > > > > > > Tellium, Inc. > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > > > > > Sent: Friday, May 25, 2001 5:30 PM > > > > > > > > To: 'Fong Liaw'; 'suresh Katukam'; v.sharma@ieee.org > > > > > > > > Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org > > > > > > > > Subject: RE: Last call - RSVP problems > > > > > > > > > > > > > > > > > > > > > > > > Fong, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Same as (2), any proposals that remove the refresh > > > > mechanism > > > > > > > > > is going to be difficult to prove that all cases > > > > are covered. > > > > > > > > > > > > > > > > > > Instead, we (will) recommend the following in OIF UNI > > > > > document: > > > > > > > > > > > > > > > > > > Use RSVP Hello to detect control channel failure. > > > > > > > > Why wouldn't you use the LMP Hello to detect > > > control channel > > > > > > > > failure? This > > > > > > > > is exactly what it is designed for. From > > > > > > > > draft-ietf-mpls-lsp-tunnel-08.txt, > > > > > > > > > > > > > > > > "This (RSVP Hello) mechanism is intended to be > > used when > > > > > > > > notification of > > > > > > > > link layer > > > > > > > > failures is not available and unnumbered links are not > > > > > > > > used, or when > > > > > > > > the failure detection mechanisms provided by the link > > > > > > > layer are not > > > > > > > > sufficient for timely node failure detection." > > > > > > > > > > > > > > > > > If a control channel failure is detected, > > LSPs states > > > > > > > > > are maintained as if a node continues to receive > > > > > > > > > RSVP refresh message from the failed control channel. > > > > > > > > > The recommended Hello timer will be in second range, > > > > > > > > > instead of ms range specified in RSVP-TE draft. > > > > > > > > > > > > > > > > > > If a control channel failed permanently, manual > > > > > intervention > > > > > > > > > may be required. This is to be studied. > > > > > > > > > > > > > > > > > > p.s The text is currently being drafted as we type. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Fri Jun 1 12:31:11 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11452 for ; Fri, 1 Jun 2001 12:31:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrob04345; Fri, 1 Jun 2001 16:29:21 GMT Received: by mail-control.mail.uu.net id QQkrob12511 for mpls-outgoing; Fri, 1 Jun 2001 16:28:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkrob12506 for ; Fri, 1 Jun 2001 16:28: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 QQkrob07200 for ; Fri, 1 Jun 2001 16:27:54 GMT From: ananth.nagarajan@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQkrob01872 for ; Fri, 1 Jun 2001 16:27:54 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f51GdhF13316; Fri, 1 Jun 2001 11:39:43 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f51GRps21969; Fri, 1 Jun 2001 11:27:51 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id LAA12809; Fri, 1 Jun 2001 11:27:50 -0500 (CDT) X-OpenMail-Hops: 1 Date: Fri, 1 Jun 2001 11:27:49 -0500 Message-Id: Subject: RE: GMPLS Last Calls MIME-Version: 1.0 TO: ccamp@ops.ietf.org, mpls@UU.NET CC: wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-405eee36-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-405eee36-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Fri, 1 Jun 2001 11:27:49 -0500" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkrob04345 Content-Transfer-Encoding: quoted-printable All, Sprint has remained fairly quiet on the issues regarding the control=20 plane as we have been working to formulate our internal views. We are=20 very concerned about the many issues that have been raised regarding=20 the proposed draft GMPLS standard over the past few weeks. These are=20 the collective opinions of me and my colleagues who are=20 involved/interested in optical control plane issues. Issues raised by others and some added here are of particular concern. =20 In order to move forward, it is recommended that the scope of this=20 version of the standard be re-evaluated and all issues related to that=20 scope of work resolved before standardization. We tried to include here=20 as many items that we could although it is not all inclusive as there=20 were so many issues raised. We believe it is not in the best interest=20 of any of the parties involved to standardize as things stand with so=20 many known issues outstanding. Depending on determined scope (i.e. this=20 list could change depending on scope of GMPLS determined by the group),=20 here are some items that we currently believe must be addressed before=20 final approval: 1) GMPLS is being specified without clear requirements identified=20 first. As such, there is no way to ensure all needed features have=20 been provided by the specification. For example, control plane=20 management requirements have not adequately been identified and there=20 is concern that the addition of management requirements may cause=20 modifications to GMPLS functions/protocol. 2) GMPLS is being defined based on assumptions about proprietary=20 transmission planes without those assumptions being specified. How can=20 we be sure that the control plane support is correct? How can we be=20 sure that it can be combined with other features? Assumptions=20 regarding the transmission plane that can affect the control plane must=20 be clearly documented. This creates the additional related problem that=20 there is not a clear inter-working defined for interaction between=20 standard/proprietary control planes/transmission planes. 3) Assuring separation of the control plane from the data plane=20 continues to arise.. When the control plane fails it should not affect=20 existing connections. Also if connections in progress are affected=20 then they should not leave partially setup connections =96 they should=20 fail gracefully informing the initiator. The GMPLS architecture=20 document mentions this separation, but it's not clear how the GMPLS=20 signaling specifications reflect the implications of this decoupling. =20 4) Support for NSAP addresses and in general support such that control=20 plane addressing is independent of clients and vice versa. Also=20 scalable naming/addressing scheme such as proposed in OIF. 5) Since the control plane may be supported via multiple protocols,=20 clear statement of what is - and isn't - covered in the GMPLS Signaling=20 Description, RSVP Extensions, LDP Extensions drafts is needed. 6) Terminology is an issue (e.g.waveband switching, link) 7) Transaction support for connection set-up and release is needed for=20 connection oriented networks (e.g. crankback capability). 8) Reliable message transfer=20 9) Security concerns have not been fully addressed, particularly at the=20 architectural level. The use of separate control network may=20 necessitate the need for 24 hour staff to protect against 'Denial of=20 Service' attacks as currently happens for IP router networks. In=20 general, admission control issues need to be addressed. 10) The definition of transparency may be overly simplified. See=20 comments by Ben Mack-Crane: I think the debate on transparency indicates that the issue is not as=20 clear as we might think. The OIF document you cite defines forms of=20 transparency that are very straightforward (flags 1,2) not the more complex forms in=20 the current GMPLS drafts (flags 3..10). Also, these are easily=20 provided in O-E-O or O-O-O networks operating at the lambda level, but there is no standard for providing these over TDM multiplexed SONET/SDH links. If two vendors implement the same signaling but different TDM=20 multiplexing, that=20 doesn't achieve interoperability. Is there any way in the drafts to=20 determine the scope of application of the various signaling elements (that is, whether they=20 apply to UNI or NNI, whether they apply to specific network=20 layers/technologies)? 11) One summary of additional items with issues includes: - SDH/SONET transparency. - SDH/SONET arbitrary concatenation, flexible concatenation. - AUG-X, TUG, STS Groups signal types and LSP capabilities. - All kinds of end-to-end protection/restoration for any layer, except=20 the IP layer. - The concept of LSC and FSC layers, i.e. concept of lambda and fiber=20 switching. - The label set object (only used for lambda issues). - LSP encoding type, bandwidth encoding and GPID have to be simplified=20 accordingly. - MPLS extensions to control G.709 (since multiplexing, etc is not yet=20 defined). 12) Support for paths across SONET/SDH gateways 13) Compatibility is required/desired with legacy SDH/SONET equipment=20 [and also legacy DWDM] 14) Just so that we don't stop at 13 :-) Thanks, Ananth --openmail-part-405eee36-00000001-- From owner-mpls@UU.NET Fri Jun 1 12:39:20 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11750 for ; Fri, 1 Jun 2001 12:39:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkroc18490; Fri, 1 Jun 2001 16:37:30 GMT Received: by mail-control.mail.uu.net id QQkroc13750 for mpls-outgoing; Fri, 1 Jun 2001 16:37:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkroc13734 for ; Fri, 1 Jun 2001 16:36:53 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 QQkroc22452 for ; Fri, 1 Jun 2001 16:35:24 GMT Received: from charon.s3group.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.s3group.com [193.120.90.3]) id QQkroc14607 for ; Fri, 1 Jun 2001 16:35:23 GMT Received: from headyin.s3group.com ([193.120.89.200]) by charon.s3group.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25139 for ; Fri, 1 Jun 2001 17:35:26 +0100 (BST) Received: from s3group.com ([193.120.89.113]) by headyin.s3group.com (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GE900FHZFEYYE@headyin.s3group.com> for mpls@UU.NET; Fri, 1 Jun 2001 17:35:22 +0100 (BST) Date: Fri, 01 Jun 2001 17:39:05 +0100 From: Paul Mannion Subject: MPLS Mode test Setup To: "mpls@UU.NET" Message-id: <3B17C529.93D8E0BA@s3group.com> Organization: Comms Infrastructure MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (WinNT; U) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_+tcCZppKfZqXy5TMOPVLtg)" X-Accept-Language: en,en-GB Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_+tcCZppKfZqXy5TMOPVLtg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anybody know where I can get information on how to setup a test harness to test MPLS LER (ingress and egress) and LSR capability ? Anybody know of some free (maybe Linux) MPLS traffic generating / analyzing tools? tnx Paul --Boundary_(ID_+tcCZppKfZqXy5TMOPVLtg) Content-type: text/x-vcard; name=paulm.vcf; charset=us-ascii Content-description: Card for Paul Mannion Content-disposition: attachment; filename=paulm.vcf Content-Transfer-Encoding: 7bit begin:vcard n:Mannion;Paul tel;work:353-1-2078766 x-mozilla-html:FALSE org:Silicon and Software Systems;Communications Infrastructure version:2.1 email;internet:Paul.Mannion@s3group.com title:Software Engineer adr;quoted-printable:;;Sandyford Ind Estate,=0D=0ALeopardstown;Dublin;;;Ireland fn:Paul Mannion end:vcard --Boundary_(ID_+tcCZppKfZqXy5TMOPVLtg)-- From owner-mpls@UU.NET Fri Jun 1 12:53:26 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12302 for ; Fri, 1 Jun 2001 12:53:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrod21102; Fri, 1 Jun 2001 16:51:26 GMT Received: by mail-control.mail.uu.net id QQkrod15411 for mpls-outgoing; Fri, 1 Jun 2001 16:50:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkrod15393 for ; Fri, 1 Jun 2001 16:50: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 QQkrod23791 for ; Fri, 1 Jun 2001 16:50:00 GMT Received: from charon.s3group.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.s3group.com [193.120.90.3]) id QQkrod19022 for ; Fri, 1 Jun 2001 16:49:59 GMT Received: from headyin.s3group.com ([193.120.89.200]) by charon.s3group.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25283 for ; Fri, 1 Jun 2001 17:50:02 +0100 (BST) Received: from s3group.com ([193.120.89.113]) by headyin.s3group.com (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GE900FNSG3BYE@headyin.s3group.com> for mpls@UU.NET; Fri, 1 Jun 2001 17:49:59 +0100 (BST) Date: Fri, 01 Jun 2001 17:53:41 +0100 From: Paul Mannion Subject: FEC to HHLFE association To: "mpls@UU.NET" Message-id: <3B17C895.803B4EB3@s3group.com> Organization: Comms Infrastructure MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (WinNT; U) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_b5CXGlGnlCxtu9eg6Ee3/Q)" X-Accept-Language: en,en-GB Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_b5CXGlGnlCxtu9eg6Ee3/Q) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry if these q's have been addressed already: 1] Is it true to say that RSVP will not setup the FEC to NHFLE mapping for a LSP? 2] What is the most likely route distribution protocol used to distribute these mappings? Pointers/ RFC's to these piggy-back methods would be appreciated. tnx Paul --Boundary_(ID_b5CXGlGnlCxtu9eg6Ee3/Q) Content-type: text/x-vcard; name=paulm.vcf; charset=us-ascii Content-description: Card for Paul Mannion Content-disposition: attachment; filename=paulm.vcf Content-Transfer-Encoding: 7bit begin:vcard n:Mannion;Paul tel;work:353-1-2078766 x-mozilla-html:FALSE org:Silicon and Software Systems;Communications Infrastructure version:2.1 email;internet:Paul.Mannion@s3group.com title:Software Engineer adr;quoted-printable:;;Sandyford Ind Estate,=0D=0ALeopardstown;Dublin;;;Ireland fn:Paul Mannion end:vcard --Boundary_(ID_b5CXGlGnlCxtu9eg6Ee3/Q)-- From owner-mpls@UU.NET Fri Jun 1 13:08:47 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12894 for ; Fri, 1 Jun 2001 13:08:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkroe13268; Fri, 1 Jun 2001 17:06:55 GMT Received: by mail-control.mail.uu.net id QQkroe27852 for mpls-outgoing; Fri, 1 Jun 2001 17:06:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkroe27837 for ; Fri, 1 Jun 2001 17:06:01 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 QQkroe27124 for ; Fri, 1 Jun 2001 17:05:48 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkroe11583 for ; Fri, 1 Jun 2001 17:05:47 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f51H5k926723 for ; Fri, 1 Jun 2001 10:05:46 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA13063 for mpls@uu.net; Fri, 1 Jun 2001 13:05:43 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrod15665 for ; Fri, 1 Jun 2001 16:52:37 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 QQkrod01473 for ; Fri, 1 Jun 2001 16:52:15 GMT Received: from roam.psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [131.107.37.68]) id QQkrod22435 for ; Fri, 1 Jun 2001 16:52:14 GMT Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155s8Q-0001s2-00; Fri, 01 Jun 2001 09:50:50 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ananth.nagarajan@mail.sprint.com Cc: ccamp@ops.ietf.org, mpls@UU.NET, wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Subject: RE: GMPLS Last Calls References: Message-Id: Date: Fri, 01 Jun 2001 09:50:50 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > These are the collective opinions of me and my colleagues as the ietf is composed of individuals, i have not read your irrelevant message. should you have personal expertise you wish to share, i would be very inteested in hearing it. randy From owner-mpls@UU.NET Fri Jun 1 13:10:40 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12969 for ; Fri, 1 Jun 2001 13:10:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkroe10113; Fri, 1 Jun 2001 17:09:27 GMT Received: by mail-control.mail.uu.net id QQkroe28473 for mpls-outgoing; Fri, 1 Jun 2001 17:07:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkroe27964 for ; Fri, 1 Jun 2001 17:06: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 QQkroe15162 for ; Fri, 1 Jun 2001 17:06:14 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkroe12198 for ; Fri, 1 Jun 2001 17:06:13 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f51H6C927177 for ; Fri, 1 Jun 2001 10:06:12 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA13068 for mpls@uu.net; Fri, 1 Jun 2001 13:06:11 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkroe23190 for ; Fri, 1 Jun 2001 17:04:10 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 QQkroe07609 for ; Fri, 1 Jun 2001 17:03:47 GMT Received: from seralph10.essex.ac.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: seralph10.essex.ac.uk [155.245.240.160]) id QQkroe07295 for ; Fri, 1 Jun 2001 17:03:47 GMT Received: from sernt12.essex.ac.uk ([155.245.240.181]) by seralph10.essex.ac.uk with esmtp (Exim 3.13 #1) id 155sKg-0004Gj-00; Fri, 01 Jun 2001 18:03:30 +0100 Received: by sernt12.essex.ac.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 18:03:28 +0100 Received: from mjrpc.essex.ac.uk ([155.245.210.9]) by sernt14.essex.ac.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2D4NR6R; Fri, 1 Jun 2001 17:58:31 +0100 From: "Reed, Martin J" To: Paul Mannion Cc: mpls@UU.NET Date: Fri, 1 Jun 2001 16:43:36 +0100 (BST) Subject: Re: MPLS Mode test Setup In-Reply-To: <3B17C529.93D8E0BA@s3group.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Paul, I have been using Nistswitch that runs on FreeBSD quite succesfully. You can find more information on this and other such tools at the following http://www.mplsrc.com/vendor.shtml down the bottom of the page under Software:shareware If you use something other than nistswitch let me know how you get on. Martin Reed On Fri, 1 Jun 2001, Paul Mannion wrote: > Anybody know where I can get information on how to setup a > test harness to test MPLS LER (ingress and > egress) and LSR capability ? > > Anybody know of some free (maybe Linux) MPLS traffic generating > / analyzing tools? > > tnx > Paul > > -- / Dr. M.J. Reed Room: 4SB.6.15 \ | Dept. Electronic Systems Engineering Tel:+44 (0)1206 872479 | | University of Essex, Colchester CO4 3SQ, UK FAX:+44 (0)1206 872900 | \ mailto:mjreed@essex.ac.uk Web: http://esewww.essex.ac.uk/~mjreed / From owner-mpls@UU.NET Fri Jun 1 13:10:43 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12981 for ; Fri, 1 Jun 2001 13:10:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkroe12096; Fri, 1 Jun 2001 17:08:10 GMT Received: by mail-control.mail.uu.net id QQkroe27943 for mpls-outgoing; Fri, 1 Jun 2001 17:06:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkroe27894 for ; Fri, 1 Jun 2001 17:06: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 QQkroe25455 for ; Fri, 1 Jun 2001 17:05:46 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.227.9.200]) id QQkroe05143 for ; Fri, 1 Jun 2001 17:05:45 GMT Received: from pluris.com (do101085.pluris.com [172.16.55.241]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id JAA27360; Fri, 1 Jun 2001 09:59:24 -0700 (PDT) Message-ID: <3B17C9EC.1833E239@pluris.com> Date: Fri, 01 Jun 2001 09:59:24 -0700 From: Chris Kuszmaul Organization: Pluris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Eric Gray CC: MPLS Mailing List Subject: Re: LDP requires break-before-make References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> <3AF06AB7.81EE10AB@marconi.com> <3AF08792.4A56B50F@pluris.com> <3B142656.C7E831A0@pluris.com> <3B17A601.EF168134@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Eric I think you are right. Consider LSRs A and B. A sends to B the label mapping: There is nothing I am aware of in the spec that prevents A from sending another mapping, such as: , prior to receiving a label release (of label1) from B. What I was saying was that B had to release label1 (transmit a label release to A) before B could accept the mapping of label2. Your solution, of combining a label withdrawal (of label1) with the label mapping of label2, in a PDU, seems to basically make sense. The semantics of ordering is necessary, but not sufficient to prevent a break before make. I think there needs to be a sense of atomicity as well: Both the label withdrawal and the label mapping need to be done, or neither should be done. In particular, the label release message transmitted by B MUST be contemporaneous with the completion of the label mapping. The LDP spec does not *preclude* just such a behavior, and so a PDU containing a label withdrawal and a label mapping can be treated as a label-mapping-overwrite, without violating the spec, and thus preventing a break before make. CLK Eric Gray wrote: > Chris, > > I understand your concern. A few years ago (early '98) I had > proposed a semantic interpretation for LDP that directly related > to this. The response was to explicitly prohibit the behavior > which would have had this semantic. > > I had suggested that (in DU mode) an LSR that advertised a > new label for exactly the same FEC as it had previously advertised > a different label meant for the upstream LSR to replace the previous > label with the new one. Over time, I came to undestand why this > may have been a little too simplistic. Also, it may be needed when > DoD label advertisement is being used as well. > > I think your basic idea of using a new message type will work. > I had thought of that and talked with a couple of people on the LDP > design team about it - and they were not too receptive to the idea > as part of the base LDP specification (adds complexity not really > required for basic functionality). Also - at the time - I thought it > possible to achieve a very similar result by simply including both > the label withdraw and the new label mapping in the same PDU (an > LDP PDU can contain multiple LDP messages). > > Of course, this latter approach depends on a few things: > > o that you are not correct in your assertion that a downstream > LSR is required to wait for a label release message prior > to sending a new label mapping (*), > > o that an upstream LSR actually looks for a 'replacement' > label mapping message in a PDU that contains a label > withdraw message, > > o that this upstream LSR processes multiple messages in a > single PDU in the order in which they appear in the PDU > > and > > o that the dowbstream LSR put them in the PDU in the order > in which it expected them to be processed (+). > > * I think that the requirement is that the downstream LSR MUST > not re-use the same label until it receives a label release for a > label it has withdrawn. I do not think there is any statement in > the specification that prohibits sending a new label mapping > prior to receiving a label release for the previous mapping for > the same FEC. Please let me know if there is text in the spec > to the contrary. > > + Given that I am right in my interpretation of the current spec wrt > issuing a new label mapping after a label withdraw, the last two > bullets naturally fall out since the current restriction on sending > a new label mapping (with a different label) prior to withdrawing > a prior label mapping imposes an ordering resptriction on adding > messages to a PDU and processing them on receipt. This ordering > is not hard to achieve. > > Essentially, a downstream LSR can try this approach and hope that > the upstream LSR was built to be robust and resilient (either using the > approach above, or some other approach). > > -- > Eric Gray > > You wrote: > > > Before a label can be mapped to an FEC that has already been mapped, the LSR > > must release the old label (prompted perhaps by a withdrawal message). Thus, LDP > > calls for a break-before-make on LSP updates. It would seem a straightforward > > matter for the protocol to include a withdraw-and-map message that performs this > > sequence atomically, and so preserves a make-before-break condition. > > > > Is there some reason for not providing for this kind of functionality? > > > > Thanks for any comments. > > > > CLK > > > > PS: The careful reader will realize that I have mentioned this issue before in > > the thread [Re: Receive Label Receive !!], but have not seen any reply. This is > > an attempt to focus the question and broaden the pool of possible respondents. From owner-mpls@UU.NET Fri Jun 1 13:13:51 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13065 for ; Fri, 1 Jun 2001 13:13:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkroe21084; Fri, 1 Jun 2001 17:11:57 GMT Received: by mail-control.mail.uu.net id QQkroe06617 for mpls-outgoing; Fri, 1 Jun 2001 17:11:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkroe06447 for ; Fri, 1 Jun 2001 17:10:56 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 QQkroe07639; Fri, 1 Jun 2001 17:10:39 GMT From: PDiamond@semtech.com Received: from mail.semtech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [209.241.157.179]) id QQkroe15188; Fri, 1 Jun 2001 17:10:38 GMT Subject: RE: GMPLS Last Calls To: Randy Bush Cc: ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, lynn.neir@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, owner-mpls@UU.NET, Tammy.Ferris@mail.sprint.com, wesam.alanqar@mail.sprint.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Fri, 1 Jun 2001 10:07:54 -0700 X-MIMETrack: Serialize by Router on Mail/SMTC(Release 5.0.6a |January 17, 2001) at 06/01/2001 10:09:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk nasty.... the mesage is very relevant From owner-mpls@UU.NET Fri Jun 1 13:27:10 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13749 for ; Fri, 1 Jun 2001 13:27:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrof01125; Fri, 1 Jun 2001 17:25:10 GMT Received: by mail-control.mail.uu.net id QQkrof09305 for mpls-outgoing; Fri, 1 Jun 2001 17:24:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrof09236 for ; Fri, 1 Jun 2001 17:24:16 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 QQkrof04479 for ; Fri, 1 Jun 2001 17:23:00 GMT From: ananth.nagarajan@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQkrof07121 for ; Fri, 1 Jun 2001 17:23:00 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f51HYnF16096; Fri, 1 Jun 2001 12:34:49 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f51HMus13298; Fri, 1 Jun 2001 12:22:56 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id MAA06234; Fri, 1 Jun 2001 12:22:56 -0500 (CDT) X-OpenMail-Hops: 1 Date: Fri, 1 Jun 2001 12:22:55 -0500 Message-Id: Subject: RE: GMPLS Last Calls MIME-Version: 1.0 TO: randy@psg.com CC: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-4060ffff-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-4060ffff-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Fri, 1 Jun 2001 12:22:54 -0500" Content-Transfer-Encoding: 7bit >as the ietf is composed of individuals, i have not read your irrelevant >message. should you have personal expertise you wish to share, i would >be very inteested in hearing it. In the interest of saving bandwidth, individual expertise has been bundled/aggregated/grouped to have one email instead of several. can't help it if this doesn't appeal to you --openmail-part-4060ffff-00000001-- From owner-mpls@UU.NET Fri Jun 1 13:28:20 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13791 for ; Fri, 1 Jun 2001 13:28:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrof08686; Fri, 1 Jun 2001 17:27:04 GMT Received: by mail-control.mail.uu.net id QQkrof09599 for mpls-outgoing; Fri, 1 Jun 2001 17:26:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkrof09579 for ; Fri, 1 Jun 2001 17:26: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 QQkrof13542 for ; Fri, 1 Jun 2001 17:25:25 GMT Received: from smtp2.cluster.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQkrof10435 for ; Fri, 1 Jun 2001 17:25:25 GMT Received: from oleane (dyn-1-1-186.Vin.dialup.oleane.fr [195.25.4.186]) by smtp2.cluster.oleane.net with SMTP id f51HPMe09683; Fri, 1 Jun 2001 19:25:22 +0200 (CEST) Message-ID: <007401c0eac0$e80c1420$8401a8c0@oleane.com> Reply-To: "Michel Gosse" From: "Michel Gosse" To: Cc: Subject: Re: Real use of VPN Date: Fri, 1 Jun 2001 19:32:58 +0200 Organization: Upper Side Conferences MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01C0EAD1.A9C81360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0071_01C0EAD1.A9C81360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard,=20 =20 May we inform you that an MPLS news website has been launched this week: http://www.mplsworld.com You will find there all news, IETF drafts, White Papers, usefull links = and a complete buyer's guide related to MPLS current progress.=20 Michel ------=_NextPart_000_0071_01C0EAD1.A9C81360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Richard,=20
 
May we inform you that an MPLS news = website has=20 been launched this week:
 
You will find there all news, IETF = drafts, White=20 Papers, usefull links and a complete buyer's guide related to MPLS = current=20 progress.
 
Michel
------=_NextPart_000_0071_01C0EAD1.A9C81360-- From owner-mpls@UU.NET Fri Jun 1 14:00:50 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14869 for ; Fri, 1 Jun 2001 14:00:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkroh09594; Fri, 1 Jun 2001 17:58:45 GMT Received: by mail-control.mail.uu.net id QQkroh13774 for mpls-outgoing; Fri, 1 Jun 2001 17:58:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkroh13750 for ; Fri, 1 Jun 2001 17:57: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 QQkroh21607 for ; Fri, 1 Jun 2001 17:57:30 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkroh29770 for ; Fri, 1 Jun 2001 17:57:29 GMT Received: from cclmsent02.lon.bt.com by gollum (local) with ESMTP; Fri, 1 Jun 2001 18:56:14 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Fri, 1 Jun 2001 18:56:11 +0100 Message-ID: To: steven.wright@snt.BellSouth.com, mpls@UU.NET, te-wg@ops.ietf.org, Shahram_Davari@pmc-sierra.com, Ben.Mack-Crane@tellabs.com Subject: RE: draft-harrison-mpls-oam-req-00.txt Date: Fri, 1 Jun 2001 18:56:00 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="windows-1252" Sender: owner-mpls@UU.NET Precedence: bulk Hi Steven....many thanks for your comments.....I have tried to answer as best I can below. regards, Neil steven wright observed 31 May 2001 19:05 > > A couple of Points.... > 1) Reqt#10 > I think there is a class of errors associated with us the use of LSP > hierarchies that may not be covered here ? > Consider that a provider may have several TE LSPs ( e.g. with > different QoS) > across a core network into which lower level LSPs are label > stacked. Even > though they may get to the right destination, they may get > there through the > "wrong" label stacked path. > unless you think this is covered under one of the other > topics, I's suggest > adding something like ... > "(e) Incorrect use of Label hierarchy" NH=> Now that is a novel one...I think we need to think about that. If this ever happened it would be undetectable at present (in any technology I can think of, not just MPLS)...and specifically here, since the trail termination source identifier (TTSI) is only checked at the *peer* trail termination sink point in CV packets, then everything would seem OK. It would be possible to detect this if at every LSP trail termination point the immediate client layer CV flows were all checked against some database of what is supposed to be going through that egress point. In other words, at the LSP layer N we check: - CV flow for layer N LSP - CV flow for all layer N-1 LSPs supported by the server LSP at layer N (no need to go higher...proving this mechanism recurses) This solution may, on reflection, be OK. Shahram/Ben...have you any views on this (noting that some record of clients is needed anyway to forward FDI correctly)? You could also possibly discover such a defect via some form of route-trace....but this would have some other complications and, by definition, would not detect the effect anyway.....so some other method of knowing when/where to look would be needed anyway to trigger such a search. > > 2) A missing Requirement on the "scope" of OAM mechanisms? > The other OAM requirements result in a need to insert some > packets into the > LSP in order to measure continuity, performance etc. > We need to ensure that such packets are : > (i) restricted to the service provider's network i.e do. not > pass beyond the > egress of the LSP into a customer network > ( I'll let braver souls debate what that means with respect > to penultimate > hop popping ! 8^} ) > (ii) not spoofed by customer traffic in the LSP data plane. > > I'm not sure how you would meet the security requirements > stated ins section > 5 without this. > I believe the mechanisms proposed in > draft-harrison-mpls-oam-00.txt did > attempt to do this.. > NH=> Yes you are correct, I have thought about this and some suggestions were given in the 'solutions' ID that you mention. > > 3) This is editorial ... > I'd be tempted to refer to "mechanisms" rather than "tools" in a > requirements document. "Tools" sound like products. > "mechanisms" may have a > variety of implementations including protocol extensions as well as > specific tools. NH=> OK. > > Motivations #7 and #10 seem to be saying the same thing to me > (and one I'd > agree with!). I'd suggest either merging them or rephrasing > to explain why > they are different... NH=> I agree....I have already pointed this out to the team (as well as a load of other changes I feel are needed) > > > regards > Steven Wright > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Shahram > > Davari > > Sent: Friday, May 18, 2001 6:32 PM > > To: 'internet-drafts@ietf.org' > > Cc: 'mpls@uu.net'; 'te-wg@ops.ietf.org' > > Subject: draft-harrison-mpls-oam-req-00.txt > > > > > > Hi, > > > > Please post the attached draft. > > > > Summary: > > > > This draft provides motivation and requirements for user-plane OAM > > (Operation and Maintenance) functionality in MPLS networks. > > > > Motivation for this recommendation rose from Network operators' need > > or tools that ensure reliability and performance of MPLS LSPs > > (Label Switched Paths). User-plane OAM tools are required to verify > > that LSPs have been setup and are available to deliver customer data > > to target destinations according to QoS (Quality of Service) > > guarantees given in SLAs (Service Level Agreements). > > > > Requirements presented in this draft include but are not limited to: > > > > . Tools to efficiently detect and localize defects in MPLS layer > > . Mechanisms for fast defect notification > > . Availability and performance criteria > > . Trigger for corrective actions (e.g. protection switching) when > > failures occur. > > > > > > Regards, > > -Shahram Davari > > > > <> > > > > From owner-mpls@UU.NET Fri Jun 1 14:17:14 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15294 for ; Fri, 1 Jun 2001 14:17:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkroi19423; Fri, 1 Jun 2001 18:14:59 GMT Received: by mail-control.mail.uu.net id QQkroi04785 for mpls-outgoing; Fri, 1 Jun 2001 18:14:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkroi04757 for ; Fri, 1 Jun 2001 18:14:06 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 QQkroi08631 for ; Fri, 1 Jun 2001 18:13:42 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkroi17650 for ; Fri, 1 Jun 2001 18:13:41 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f51IDgU07789 for ; Fri, 1 Jun 2001 11:13:42 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA13312 for mpls@uu.net; Fri, 1 Jun 2001 14:13:39 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkroh12841 for ; Fri, 1 Jun 2001 17:54: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 QQkroh11666 for ; Fri, 1 Jun 2001 17:53:38 GMT From: Tammy.Ferris@mail.sprint.com Received: from kcmgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker1.sprint.com [208.18.122.165]) id QQkroh04135 for ; Fri, 1 Jun 2001 17:53:38 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f51Hra414613; Fri, 1 Jun 2001 12:53:36 -0500 (CDT) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f51HrZs11369; Fri, 1 Jun 2001 12:53:36 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id MAA07545; Fri, 1 Jun 2001 12:53:35 -0500 (CDT) X-OpenMail-Hops: 1 Date: Fri, 1 Jun 2001 12:53:34 -0500 Message-Id: Subject: RE: GMPLS Last Calls MIME-Version: 1.0 TO: ananth.nagarajan@mail.sprint.com, randy@psg.com CC: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-24374f1d-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-24374f1d-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Fri, 1 Jun 2001 12:53:31 -0500" Content-Transfer-Encoding: 7bit Ananth and all, I will be gone for all of next week in Turin, Italy. I will try to read my mail but don't know how much luck I will have in getting access. I am leaving tomorrow. I am hoping that for these detailed messages that are GMPLS specific, you and Wesam can take the brunt of it. I want to focus more on the functional level and management specific issues as much as possible and leave detailed GMPLS items to the two of you. I see that this individual from Alcatel is pushing hard for GMPLS. I will let you all know what happens in Turin. I think maybe just thank those that sent the e-mails and say you will look over what they sent if you don't have any further opion on what they sent. Tammy -----Original Message----- From: Nagarajan, Ananth Sent: Friday, June 01, 2001 12:23 To: randy Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir, Lynn Subject: RE: GMPLS Last Calls >as the ietf is composed of individuals, i have not read your irrelevant >message. should you have personal expertise you wish to share, i would >be very inteested in hearing it. In the interest of saving bandwidth, individual expertise has been bundled/aggregated/grouped to have one email instead of several. can't help it if this doesn't appeal to you --openmail-part-24374f1d-00000001-- From owner-mpls@UU.NET Fri Jun 1 14:39:19 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15966 for ; Fri, 1 Jun 2001 14:39:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrok21565; Fri, 1 Jun 2001 18:37:23 GMT Received: by mail-control.mail.uu.net id QQkrok07545 for mpls-outgoing; Fri, 1 Jun 2001 18:36:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrok07539 for ; Fri, 1 Jun 2001 18:36: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 QQkrok13037 for ; Fri, 1 Jun 2001 18:36:06 GMT Received: from prue.eim.surrey.ac.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQkrok20859 for ; Fri, 1 Jun 2001 18:36:05 GMT Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 155tly-0004V6-00; Fri, 01 Jun 2001 19:35:46 +0100 Date: Fri, 1 Jun 2001 19:35:43 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Randy Bush cc: ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, mpls@UU.NET, wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Subject: RE: GMPLS Last Calls In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *155tly-0004V6-00*0kqOkupy80g* http://duncanthrax.net/exiscan/ Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 1 Jun 2001, Randy Bush wrote: > > These are the collective opinions of me and my colleagues > > as the ietf is composed of individuals, i have not read your irrelevant > message. Interesting, Randy. Do you read internet-drafts and RFCs that have multiple authors, where consensus between the authors is implicit in the author list? If they'd thrown their comments and criticisms together in draft form, would you have read it? L. oh, and Tammy? The 'individual from Alcatel' is just an individual. PGP From owner-mpls@UU.NET Fri Jun 1 15:26:27 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16744 for ; Fri, 1 Jun 2001 15:26:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkron02285; Fri, 1 Jun 2001 19:24:52 GMT Received: by mail-control.mail.uu.net id QQkron02537 for mpls-outgoing; Fri, 1 Jun 2001 19:24:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkron02523 for ; Fri, 1 Jun 2001 19:24: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 QQkron08030 for ; Fri, 1 Jun 2001 19:23:36 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkron12064 for ; Fri, 1 Jun 2001 19:23:35 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 85CAA94006; Fri, 1 Jun 2001 15:23:35 -0400 (EDT) Message-ID: <3B17EBB7.4E5970B6@sandburst.com> Date: Fri, 01 Jun 2001 15:23:35 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush Cc: ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, mpls@UU.NET, wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Subject: Re: GMPLS Last Calls References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Randy, Is this one of your usual insightful comments? Let's see what our studio audience has to say - Bzztzzt! Apparently that was a wrong answer. :-) Repeatedly we ask for input from carriers. We get some and we hear that we're only interested in hearing from individuals? As Lloyd said, interesting... -- Eric Gray You wrote: > > These are the collective opinions of me and my colleagues > > as the ietf is composed of individuals, i have not read your irrelevant > message. should you have personal expertise you wish to share, i would > be very inteested in hearing it. > > randy From owner-mpls@UU.NET Fri Jun 1 15:28:54 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16814 for ; Fri, 1 Jun 2001 15:28:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkron07337; Fri, 1 Jun 2001 19:27:52 GMT Received: by mail-control.mail.uu.net id QQkron03022 for mpls-outgoing; Fri, 1 Jun 2001 19:27:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkron03004 for ; Fri, 1 Jun 2001 19:27: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 QQkron23926 for ; Fri, 1 Jun 2001 19:27:11 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkron15739 for ; Fri, 1 Jun 2001 19:27:11 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA22179; Fri, 1 Jun 2001 12:26:43 -0700 (PDT) Message-Id: <200106011926.MAA22179@red.juniper.net> To: Dimitrios Pendarakis cc: "'Jonathan Lang'" , "'Fong Liaw'" , "'suresh Katukam'" , "'Jennifer Yates'" , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: Last call - RSVP problems In-Reply-To: Your message of "Fri, 01 Jun 2001 10:57:32 EDT." <0CD7D73C734BD411AEE100B0D0220404019F6904@mail1.tellium.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27332.991423602.1@juniper.net> Date: Fri, 01 Jun 2001 12:26:42 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Dimitrios, > The problem with being in meetings is it took me a long > time to respond -:) > > So, I 'll try to provide a summary of the messages exchanged > as well as my understanding of our off-line discussion > on the applicability of RSVP and LMP Hello mechanisms. > > An attempt on terminology clarification first: > Control channel: This is a logical channel over which IP > control packets are transported between two network elements > (for example a UNI-C and UNI-N in the case of the OIF UNI). > A control channel can be realized in multiple ways, for example, > in-fiber using SONET/SDH overhead bytes, out-of-band over an > Ethernet, etc. > A pair of network elements may be connected by multiple control > channels, used either concurrently or in a primary-backup > configuration. Control channel failures can be detected using > link management procedures, such as the LMP Hello mechanism. > > Signaling channel: This is a logical channel over which signaling > messages are exchanged between two peers. The signaling channel > is realized using (potentially multiple) control channels and > it operation relies on processing of signaling messages by the > respective peer signaling entities. > A signaling channel failure is the result of failure of all control > channels, or failure of a signaling entity. Signaling channel > failures can be detected using the RSVP hello mechanism (assuming > of course RSVP is the signaling protocol used!). And then to extend it further we can also talk about routing channel, which is a logical channel over which routing messages (Hellos, Link State Updates) are exchanged between two peers. The routing channel is realized using (potentially multiple) control channels and its operation relies on processing of routing messages by the respective peer routing entities. A routing channel failure is the result of failure of all control channels, or failure of a routing entity. Routing channel failures can be detected using the ISIS/OSPF hello mechanism (assuming ISIS/OSPF is the routing protocol used). Yakov. From owner-mpls@UU.NET Fri Jun 1 15:30:39 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16866 for ; Fri, 1 Jun 2001 15:30:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkroo23948; Fri, 1 Jun 2001 19:30:02 GMT Received: by mail-control.mail.uu.net id QQkron03231 for mpls-outgoing; Fri, 1 Jun 2001 19:29:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkron03209 for ; Fri, 1 Jun 2001 19:29:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkron28573 for ; Fri, 1 Jun 2001 19:28:43 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 QQkron17301 for ; Fri, 1 Jun 2001 19:28:43 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 PAA04567 for ; Fri, 1 Jun 2001 15:28:38 -0400 (EDT) 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 PAA29536 for ; Fri, 1 Jun 2001 15:28:39 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 15:28:38 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF042F7E88@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: mpls@UU.NET Subject: Few questions related to LDP Date: Fri, 1 Jun 2001 15:28:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi! I have some basic questions on LDP LSPs. I will appreciate, if some one can help me with these. Q1. What are the conditions that make a LSR an ingress for a FEC ? (RFC3036, A.1.2 LMp14) Q2. If a LSR is an ingress for a FEC, then it is also an "LSP Ingress" (RFC3031, 3.15 , 1) for the LSP associated with the above mentioned FEC. Is my interpretation correct ? Q3. If an LSR is _not_ an ingress for a FEC, can unlabelled IP traffic (matching the FEC) be mapped into the LDP LSP corresponding to the above mentioned FEC ? For example: R1-----(FEC1 = L1) ------R2-------(FEC1 = L2)------R3 | | R4 R1: ingress for FEC1, R3: egress for FEC1 Can/Should unlabelled IP traffic arriving at R2 (from R4 and matching prefix) be "inserted" into the LSP _transiting_ through it ? Q4. If the answer to the previous question is 'yes', then doesn't that make R2 ingress for that FEC ? Thanks, sanjay From owner-mpls@UU.NET Fri Jun 1 16:11:42 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17578 for ; Fri, 1 Jun 2001 16:11:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkroq03530; Fri, 1 Jun 2001 20:11:22 GMT Received: by mail-control.mail.uu.net id QQkroq19307 for mpls-outgoing; Fri, 1 Jun 2001 20:10:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkroq19243 for ; Fri, 1 Jun 2001 20:10:40 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 QQkroq21094 for ; Fri, 1 Jun 2001 20:10:19 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 QQkroq02218 for ; Fri, 1 Jun 2001 20:10:18 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f51KAI926778 for ; Fri, 1 Jun 2001 13:10:18 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA14029 for mpls@uu.net; Fri, 1 Jun 2001 16:10:15 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkroq12721 for ; Fri, 1 Jun 2001 20:03:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkroq13992 for ; Fri, 1 Jun 2001 20:03:19 GMT Received: from roam.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [131.107.37.68]) id QQkroq01903 for ; Fri, 1 Jun 2001 20:03:18 GMT Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155v6D-000206-00; Fri, 01 Jun 2001 13:00:45 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Gray Cc: ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, mpls@UU.NET, wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Subject: Re: GMPLS Last Calls References: <3B17EBB7.4E5970B6@sandburst.com> Message-Id: Date: Fri, 01 Jun 2001 13:00:45 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Is this one of your usual insightful comments? nope. a statement of ietf culture and policy. randy From owner-mpls@UU.NET Fri Jun 1 16:21:01 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17670 for ; Fri, 1 Jun 2001 16:21:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkror13896; Fri, 1 Jun 2001 20:20:47 GMT Received: by mail-control.mail.uu.net id QQkror28701 for mpls-outgoing; Fri, 1 Jun 2001 20:19:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkror28648 for ; Fri, 1 Jun 2001 20:19: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 QQkror02031 for ; Fri, 1 Jun 2001 20:19:01 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkror11887 for ; Fri, 1 Jun 2001 20:19:01 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 3C94494006; Fri, 1 Jun 2001 16:18:57 -0400 (EDT) Message-ID: <3B17F8B1.6760CF49@sandburst.com> Date: Fri, 01 Jun 2001 16:18:57 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush Cc: ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, mpls@UU.NET, wesam.alanqar@mail.sprint.com, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, lynn.neir@mail.sprint.com Subject: Re: GMPLS Last Calls References: <3B17EBB7.4E5970B6@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Randy, Thanks. As an individual, I am interested in hearing from other individuals who can help me to understand what is useful work and what is not. I am so interested in hearing this, that I will go to some lengths to discourage others from censuring them. I believe it is even possible that I am not alone among the many individuals participating in, or listening to, this discussion in feeling this way. But I could be wrong, and you're certainly entitled to express your own opinion. -- Eric Gray You wrote: > > Is this one of your usual insightful comments? > > nope. a statement of ietf culture and policy. > > randy From owner-mpls@UU.NET Fri Jun 1 16:34:31 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17832 for ; Fri, 1 Jun 2001 16:34:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkros12903; Fri, 1 Jun 2001 20:34:11 GMT Received: by mail-control.mail.uu.net id QQkros00323 for mpls-outgoing; Fri, 1 Jun 2001 20:33:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkros00300 for ; Fri, 1 Jun 2001 20:33: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 QQkros03590 for ; Fri, 1 Jun 2001 20:30:41 GMT From: ananth.nagarajan@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQkros26461 for ; Fri, 1 Jun 2001 20:30:40 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f51KgSF20921; Fri, 1 Jun 2001 15:42:28 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f51KUZs29687; Fri, 1 Jun 2001 15:30:36 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id PAA02219; Fri, 1 Jun 2001 15:30:35 -0500 (CDT) X-OpenMail-Hops: 1 Date: Fri, 1 Jun 2001 15:30:34 -0500 Message-Id: Subject: RE: Re: GMPLS Last Calls MIME-Version: 1.0 TO: eric.gray@sandburst.com, randy@psg.com CC: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-406a2320-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-406a2320-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Fri, 1 Jun 2001 15:30:34 -0500" Content-Transfer-Encoding: 7bit Eric, Lloyd and other "individuals", Thanks for being so understanding :-) I am sorry this thread is going on in a direction it was not intended to. I apologize for offending "IETF culture". As a group of individuals interested in getting technical responses to our technical concerns, can we re-focus on the technical issues raised collectively by individuals that I work with (I hope this description is acceptable)? Let us get a technical discussion going, please! Ananth -----Original Message----- From: eric.gray [mailto:eric.gray@sandburst.com] Sent: Friday, June 01, 2001 3:19 PM To: randy Cc: eric.gray; Nagarajan, Ananth; ccamp; mpls; Alanqar, Wesam; Ferris, Tammy; Jones, Mark L.; Neir, Lynn Subject: Re: GMPLS Last Calls Randy, Thanks. As an individual, I am interested in hearing from other individuals who can help me to understand what is useful work and what is not. I am so interested in hearing this, that I will go to some lengths to discourage others from censuring them. I believe it is even possible that I am not alone among the many individuals participating in, or listening to, this discussion in feeling this way. But I could be wrong, and you're certainly entitled to express your own opinion. -- Eric Gray You wrote: > > Is this one of your usual insightful comments? > > nope. a statement of ietf culture and policy. > > randy --openmail-part-406a2320-00000001-- From owner-mpls@UU.NET Fri Jun 1 17:27:17 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18312 for ; Fri, 1 Jun 2001 17:27:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrov06101; Fri, 1 Jun 2001 21:26:47 GMT Received: by mail-control.mail.uu.net id QQkrov25637 for mpls-outgoing; Fri, 1 Jun 2001 21:26:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkrov25614 for ; Fri, 1 Jun 2001 21:26: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 QQkrov13251 for ; Fri, 1 Jun 2001 21:24:10 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQkrov03163 for ; Fri, 1 Jun 2001 21:24:05 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f51LLdt14000; Fri, 1 Jun 2001 17:21:39 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 17:25:33 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D02204040198229D@mail1.tellium.com> From: Bala Rajagopalan To: "'ananth.nagarajan@mail.sprint.com'" Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Subject: RE: Re: GMPLS Last Calls Date: Fri, 1 Jun 2001 17:25:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Ananth: I see that some of the issues you bring up are not show stoppers. Others need some clarification from you (please see below). Also, if you have any suggestions on how to resolve (what you consider are) the issues, please post them/write some drafts. This is the most constructive way going forward. With regard to NSAP, Dan Speers posted a note in the OIF mailing list soliciting response to the following: > > 1) Type of legacy equipment needing NSAP addresses > > (also, is > > this optical network element or client equipment?) > > 2) Rough estimate of number of UNI ports needing NSAP address > > (2002, 2005, and 2010) > > 3) Description of application in which this legacy equipment > > will use UNI > > signaling I don't recall seeing any response. furthermore, the NSAP requirement was not unanimously endorsed by all carriers (at the OIF). It would also be nice if you can give some insight on the timeline in which you need various features, and whether the current GMPLS developments are inadequate within that timeline. (We can always have a progression of features). Please see below. On the whole, I believe that there is no need for alarm or panic now (or even to be "very" concerned :-)). Regards, Bala Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- 1) GMPLS is being specified without clear requirements identified first. As such, there is no way to ensure all needed features have been provided by the specification. For example, control plane management requirements have not adequately been identified and there is concern that the addition of management requirements may cause modifications to GMPLS functions/protocol. BR: Please be more specific about what you need now that's missing, and how we can address this? 2) GMPLS is being defined based on assumptions about proprietary transmission planes without those assumptions being specified. How can we be sure that the control plane support is correct? How can we be sure that it can be combined with other features? Assumptions regarding the transmission plane that can affect the control plane must be clearly documented. This creates the additional related problem that there is not a clear inter-working defined for interaction between standard/proprietary control planes/transmission planes. BR: I get the feeling you're referring to the concatenation/transperency issues discussed recently. While the debate has been hot, there's no show stopper here. Several suggestions are being considered for clarifying standard/non-standard features supported. 3) Assuring separation of the control plane from the data plane continues to arise.. When the control plane fails it should not affect existing connections. Also if connections in progress are affected then they should not leave partially setup connections - they should fail gracefully informing the initiator. The GMPLS architecture document mentions this separation, but it's not clear how the GMPLS signaling specifications reflect the implications of this decoupling. BR: This issue has been discussed for the OIF UNI signaling (GMPLS based, as you know), and solutions in the RSVP/LDP space have been proposed (some drafts may be written). This is also not a show stopper by any means. 4) Support for NSAP addresses and in general support such that control plane addressing is independent of clients and vice versa. Also scalable naming/addressing scheme such as proposed in OIF. BR: NSAP, see my initial comments. The OIF is not dealing with names/resolution, etc. This has been decided to be out of the scope of UNI signaling, and considered as a separate function. 5) Since the control plane may be supported via multiple protocols, clear statement of what is - and isn't - covered in the GMPLS Signaling Description, RSVP Extensions, LDP Extensions drafts is needed. BR: Don't understand this, but doesn't look like a major issue from your phrasing. 6) Terminology is an issue (e.g.waveband switching, link) BR: Any inconsistencies can be taken care of easily. 7) Transaction support for connection set-up and release is needed for connection oriented networks (e.g. crankback capability). BR: Internet drafts have already been written on crankback. I suggest that you please consider writing some drafts if there is something missing. 8) Reliable message transfer BR: Very much a part of signaling. the OIF work has considered this aspect also. 9) Security concerns have not been fully addressed, particularly at the architectural level. The use of separate control network may necessitate the need for 24 hour staff to protect against 'Denial of Service' attacks as currently happens for IP router networks. In general, admission control issues need to be addressed. BR: Please elaborate on these, specifically, what's new in the context of GMPLS. 10) The definition of transparency may be overly simplified. See comments by Ben Mack-Crane: I think the debate on transparency indicates that the issue is not as clear as we might think. The OIF document you cite defines forms of transparency that are very straightforward (flags 1,2) not the more complex forms in the current GMPLS drafts (flags 3..10). Also, these are easily provided in O-E-O or O-O-O networks operating at the lambda level, but there is no standard for providing these over TDM multiplexed SONET/SDH links. BR: This is an ongoing topic of discussion. Doesn't break down the rest of the proposal. If two vendors implement the same signaling but different TDM multiplexing, that doesn't achieve interoperability. Is there any way in the drafts to determine the scope of application of the various signaling elements (that is, whether they apply to UNI or NNI, whether they apply to specific network layers/technologies)? 11) One summary of additional items with issues includes: - SDH/SONET transparency. - SDH/SONET arbitrary concatenation, flexible concatenation. - AUG-X, TUG, STS Groups signal types and LSP capabilities. - All kinds of end-to-end protection/restoration for any layer, except the IP layer. BR: Restoration is not actually covered in the current set of drafts. An earlier thread discussed this, and my suggestion is that this feature be dealt with separately. - The concept of LSC and FSC layers, i.e. concept of lambda and fiber switching. BR: What are the issues here? - The label set object (only used for lambda issues). - LSP encoding type, bandwidth encoding and GPID have to be simplified accordingly. - MPLS extensions to control G.709 (since multiplexing, etc is not yet defined). BR: A draft is forthcoming on this. 12) Support for paths across SONET/SDH gateways BR: Please clarify the issues/write drafts. 13) Compatibility is required/desired with legacy SDH/SONET equipment [and also legacy DWDM] BR: Same as above. 14) Just so that we don't stop at 13 :-) Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Fri Jun 1 19:22:13 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19243 for ; Fri, 1 Jun 2001 19:22:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrpd02453; Fri, 1 Jun 2001 23:22:13 GMT Received: by mail-control.mail.uu.net id QQkrpd16857 for mpls-outgoing; Fri, 1 Jun 2001 23:21:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrpd16836 for ; Fri, 1 Jun 2001 23:21: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 QQkrpd21653 for ; Fri, 1 Jun 2001 23:21:18 GMT Received: from dnsmx1rrc.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQkrpd01384 for ; Fri, 1 Jun 2001 23:21:18 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id TAA00047 for ; Fri, 1 Jun 2001 19:20:02 -0400 (EDT) Subject: rsvp -te To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Fri, 1 Jun 2001 19:20:04 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 06/01/2001 07:20:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Is it possible for RSVP message with proprietary objects that are not defined in the spec like Opaque object? I do not think so. Can anyone tell me whether I am right. Thanks in advance. Julia From owner-mpls@UU.NET Sat Jun 2 18:52:50 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14083 for ; Sat, 2 Jun 2001 18:52:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrst27103; Sat, 2 Jun 2001 22:52:55 GMT Received: by mail-control.mail.uu.net id QQkrst05872 for mpls-outgoing; Sat, 2 Jun 2001 22:52:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrst05861 for ; Sat, 2 Jun 2001 22:52: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 QQkrst09242 for ; Sat, 2 Jun 2001 22:50:48 GMT Received: from usa04.ambernetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.121.148.133]) id QQkrst20696 for ; Sat, 2 Jun 2001 22:50:48 GMT Received: by usa04.ambernetworks.com with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Jun 2001 15:49:13 -0700 Message-ID: <9F4704BE89F7D4118A0F0002B328C36C0620C7@usa04.ambernetworks.com> From: Peng Li To: "'mpls@UU.NET'" Subject: relationship of RD/VRF/VPN Date: Sat, 2 Jun 2001 15:49:12 -0700 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 Hi, In the RFC2547, it seemed to define that each VPN will have its unique router distinguisher value. In CISCO PRESS book, "MPLS and VPN Architecture", 2nd printing, page 172 also expressed the same idea. However, in cisco routers, each VRF with associated with one or multiple interface can participate in multiple VPNs, (e.g. the case where one CE routers participate in multiple VPNs). And each VRF will have a RD associated with it. Thus, a RD is not one-to-one mapping relationship with VPN anymore. Anyone else confused by this? Can someone please explain to me what is the correct relationship of RD/VRF and VPN? many thanks, peng From owner-mpls@UU.NET Sat Jun 2 20:12:41 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14383 for ; Sat, 2 Jun 2001 20:12:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrsy04433; Sun, 3 Jun 2001 00:12:25 GMT Received: by mail-control.mail.uu.net id QQkrsy22846 for mpls-outgoing; Sun, 3 Jun 2001 00:11:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrsy22652 for ; Sun, 3 Jun 2001 00:11: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 QQkrsy23201 for ; Sun, 3 Jun 2001 00:10:55 GMT Received: from momotaro.labs.nec.co.jp by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: momotaro.labs.nec.co.jp [202.247.6.209]) id QQkrsy01482 for ; Sun, 3 Jun 2001 00:10:54 GMT Received: from iwata-pc2.nwk.cl.nec.co.jp by momotaro.labs.nec.co.jp (8.11.3/MOMO-010516) with ESMTP id f530Ac545225; Sun, 3 Jun 2001 09:10:38 +0900 (JST) Message-Id: <4.3.2-J.20010602092204.03e3bf00@tea.nwk.cl.nec.co.jp> X-Sender: iwata@momotaro.labs.nec.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Sat, 02 Jun 2001 09:28:33 +0900 To: From: Atsushi Iwata Subject: RE: Re: GMPLS Last Calls Cc: Bala Rajagopalan , wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, Gerald (Jerry) Ash , Adrian Farrel , Norihito Fujita In-Reply-To: <0CD7D73C734BD411AEE100B0D02204040198229D@mail1.tellium.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Ananth, As Bala suggested, I wrote the following I-D proposing the crankback routing capability for CR-LDP and RSVP-TE signaling. http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-00.txt Please look at it and if you find any missing pieces for GMPLS signaling, please let me know. I would appreciate any constructive comments. Thank you. At 17:25 01/06/01 -0400, Bala Rajagopalan wrote: >7) Transaction support for connection set-up and release is needed for >connection oriented networks (e.g. crankback capability). > >BR: Internet drafts have already been written on crankback. I suggest >that you please consider writing some drafts if there is something >missing. ---------------------------------------------------------------- Atsushi Iwata, Ph.D. Assistant Manager Network Architecture TG, Networking Research Labs, NEC Corporation 4-1-1 Miyazaki Miyamae-ku, Kawasaki, 216-8555, Japan TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct) NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299 Internet E-mail: a-iwata@ah.jp.nec.com NEC-internal E-mail: iwata@ccm.CL.nec.co.jp *** Organization has been a bit changed since Apr.2001 *** From owner-mpls@UU.NET Sun Jun 3 16:17:23 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11105 for ; Sun, 3 Jun 2001 16:17:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrwb14526; Sun, 3 Jun 2001 20:17:21 GMT Received: by mail-control.mail.uu.net id QQkrwb22651 for mpls-outgoing; Sun, 3 Jun 2001 20:16:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrwb22607 for ; Sun, 3 Jun 2001 20:15:57 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 QQkrwb06135 for ; Sun, 3 Jun 2001 20:15:49 GMT Received: from mail3.svr.pol.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail3.svr.pol.co.uk [195.92.193.19]) id QQkrwb12274 for ; Sun, 3 Jun 2001 20:15:49 GMT Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by mail3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 156eHs-0000cX-00; Sun, 03 Jun 2001 21:15:48 +0100 Received: from modem-297.hoary-redpoll.dialup.pol.co.uk ([62.137.197.41] helo=BLIULAPTOP) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 156eHs-0001Po-00; Sun, 03 Jun 2001 21:15:48 +0100 Message-ID: <001701c0ec69$74bdc950$29c5893e@movaz.com> From: "Adrian Farrel" To: , "Hong Liao" References: Subject: Re: rsvp -te Date: Sun, 3 Jun 2001 16:12:01 -0400 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 Sender: owner-mpls@UU.NET Precedence: bulk Hi Julia, Perfectly possible. See RFC2205 section 3.10 Regards, Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ----- Original Message ----- From: "Hong Liao" To: Sent: Friday, June 01, 2001 7:20 PM Subject: rsvp -te > > Hi, > > Is it possible for RSVP message with proprietary objects that are not > defined in the spec like Opaque object? > I do not think so. Can anyone tell me whether I am right. > > > Thanks in advance. > > Julia > > From owner-mpls@UU.NET Sun Jun 3 21:13:00 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12236 for ; Sun, 3 Jun 2001 21:13:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrwu24471; Mon, 4 Jun 2001 01:12:22 GMT Received: by mail-control.mail.uu.net id QQkrwu29468 for mpls-outgoing; Mon, 4 Jun 2001 01:11:45 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkrwu29382 for ; Mon, 4 Jun 2001 01:11:27 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 QQkrwu17389 for ; Mon, 4 Jun 2001 01:11:23 GMT Received: from caip.rutgers.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: caip.rutgers.edu [128.6.236.10]) id QQkrwu10066 for ; Mon, 4 Jun 2001 01:11:23 GMT Received: (from senthil@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id VAA26396; Sun, 3 Jun 2001 21:11:14 -0400 (EDT) Date: Sun, 3 Jun 2001 21:11:14 -0400 (EDT) From: Senthilkumar Rajasekharan To: Peng Li cc: "'mpls@UU.NET'" Subject: Re: relationship of RD/VRF/VPN In-Reply-To: <9F4704BE89F7D4118A0F0002B328C36C0620C7@usa04.ambernetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, > associated with it. Thus, a RD is not one-to-one mapping relationship with > VPN anymore. True. RD and a VPN do not have a one-to-one association in all cases although its possible to have a VPN that has a one-to-one mapping with an RD value. >Anyone else confused by this? Can someone please explain to me >what is the correct relationship of RD/VRF and VPN? RD values map to a VRF and a VPN can be a grouping of multiple VRFs. And so the RD values have a one-to-one mapping with a VRF and the VRF has a many-to-one mapping with a VPN in the Intranets case and many-to-many relationship in the Extranets case ( by virtue of extending RT values of a VRF). Hope this Helps, -Senthil P:S > I have refrained from going into vendor specific issues and I can answer vendor specific questions either offline or you can post a query to mpls-ops@mplsrc.com > > many thanks, > peng > From owner-mpls@UU.NET Mon Jun 4 01:26:05 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17282 for ; Mon, 4 Jun 2001 01:26:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrxl07839; Mon, 4 Jun 2001 05:26:13 GMT Received: by mail-control.mail.uu.net id QQkrxl13254 for mpls-outgoing; Mon, 4 Jun 2001 05:25:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrxl13241 for ; Mon, 4 Jun 2001 05:25:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkrxl07782 for ; Mon, 4 Jun 2001 05:25:08 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQkrxl06622 for ; Mon, 4 Jun 2001 05:25:06 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MH6RWBDR; Mon, 4 Jun 2001 11:07:41 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2DGY5; Mon, 4 Jun 2001 10:53:00 +0530 From: "Vijayanand C" To: Subject: mplsInSegmentNPop Date: Mon, 4 Jun 2001 10:59:33 +0530 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.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, I have a question regarding LSR MIB. In MplsInSegmentEntry there is an object mplsInSegmentNPop which seems to indicate the number of labels to pop, which is usually 1. Can anyone tell me a situation where we need to pop more than 1 label before deciding what to do or before looking at the cross-connect for the top label? There is a cross-connect and out segment entry associated with each insegment enbtry, using which we can determine whether the label has to be popped/swapped etc. Also, if we always pop say 2 labels for a particular top label, then what is the significance of the second label. Please correct me of I am wrong. Regards, Vijay From owner-mpls@UU.NET Mon Jun 4 05:37:01 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02100 for ; Mon, 4 Jun 2001 05:37:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkryc14377; Mon, 4 Jun 2001 09:37:04 GMT Received: by mail-control.mail.uu.net id QQkryc26074 for mpls-outgoing; Mon, 4 Jun 2001 09:36:33 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkryc25986 for ; Mon, 4 Jun 2001 09:36: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 QQkryc28940 for ; Mon, 4 Jun 2001 09:35:26 GMT From: shehzad.mirza@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkryc12804 for ; Mon, 4 Jun 2001 09:35:25 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by gollum (local) with ESMTP; Mon, 4 Jun 2001 10:34:50 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2652.35) id ; Mon, 4 Jun 2001 10:34:41 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A94092DDE59@mbtlipnt01.btlabs.bt.co.uk> To: BRaja@tellium.com, ananth.nagarajan@mail.sprint.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Subject: RE: Re: GMPLS Last Calls Date: Mon, 4 Jun 2001 10:33:10 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Bala, I am uncomfortable about talking about emails that were made in a different forum, but I think some clarification to the OIF comments is required. 1. The email that Dan Spears sent to the OIF mailing list made it clear that if there were no responses then the Paris Agreement that ONA Address shall be capable of accommodating either of the IP or NSAP families would still stand. It is wrong to assume that no responses meant that there was no need to support NSAP. 2. It is unreasonable to expect unanimity between carriers given that they have to support a diverse range of services and customers and legacy equipment. Though I'm sure that smart vendors will find ways of accommodating the majority of their carrier customers requirements. I do agree that the work has to continue to ensure that all issues are addressed. regards Shehzad Mirza > -----Original Message----- > From: Bala Rajagopalan [SMTP:BRaja@tellium.com] > Sent: 01 June 2001 22:26 > To: 'ananth.nagarajan@mail.sprint.com' > Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; > Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; > lynn.neir@mail.sprint.com > Subject: RE: Re: GMPLS Last Calls > > Ananth: > > I see that some of the issues you bring up are > not show stoppers. Others need some clarification > from you (please see below). Also, if you > have any suggestions on how to resolve (what you > consider are) the issues, please post them/write > some drafts. This is the most constructive way > going forward. > > With regard to NSAP, Dan Speers posted a note > in the OIF mailing list soliciting response to the following: > > > > 1) Type of legacy equipment needing NSAP addresses > > > (also, is > > > this optical network element or client equipment?) > > > 2) Rough estimate of number of UNI ports needing NSAP address > > > (2002, 2005, and 2010) > > > 3) Description of application in which this legacy equipment > > > will use UNI > > > signaling > > I don't recall seeing any response. furthermore, the NSAP > requirement was not unanimously endorsed by all carriers (at > the OIF). > > It would also be nice if you can give some insight on > the timeline in which you need various features, and whether > the current GMPLS developments are inadequate within > that timeline. (We can always have a progression of features). > > Please see below. On the whole, I believe that there is no > need for alarm or panic now (or even to be "very" concerned :-)). > > > Regards, > > Bala > > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > -----Original Message----- > 1) GMPLS is being specified without clear requirements identified > first. As such, there is no way to ensure all needed features have > been provided by the specification. For example, control plane > management requirements have not adequately been identified and there > is concern that the addition of management requirements may cause > modifications to GMPLS functions/protocol. > > BR: Please be more specific about what you need now that's missing, and > how we can address this? > > 2) GMPLS is being defined based on assumptions about proprietary > transmission planes without those assumptions being specified. How can > we be sure that the control plane support is correct? How can we be > sure that it can be combined with other features? Assumptions > regarding the transmission plane that can affect the control plane must > be clearly documented. This creates the additional related problem that > there is not a clear inter-working defined for interaction between > standard/proprietary control planes/transmission planes. > > BR: I get the feeling you're referring to the concatenation/transperency > issues discussed recently. While the debate has been hot, there's > no show stopper here. Several suggestions are being considered for > clarifying standard/non-standard features supported. > > > 3) Assuring separation of the control plane from the data plane > continues to arise.. When the control plane fails it should not affect > existing connections. Also if connections in progress are affected > then they should not leave partially setup connections - they should > fail gracefully informing the initiator. The GMPLS architecture > document mentions this separation, but it's not clear how the GMPLS > signaling specifications reflect the implications of this decoupling. > > BR: This issue has been discussed for the OIF UNI signaling (GMPLS > based, as you know), and solutions in the RSVP/LDP space have been > proposed (some drafts may be written). > This is also not a show stopper by any means. > > > 4) Support for NSAP addresses and in general support such that control > plane addressing is independent of clients and vice versa. Also > scalable naming/addressing scheme such as proposed in OIF. > > BR: NSAP, see my initial comments. The OIF is not dealing with > names/resolution, etc. This has been decided to be out of the > scope of UNI signaling, and considered as a separate function. > > > 5) Since the control plane may be supported via multiple protocols, > clear statement of what is - and isn't - covered in the GMPLS Signaling > Description, RSVP Extensions, LDP Extensions drafts is needed. > > BR: Don't understand this, but doesn't look like a major issue from > your phrasing. > > 6) Terminology is an issue (e.g.waveband switching, link) > > BR: Any inconsistencies can be taken care of easily. > > 7) Transaction support for connection set-up and release is needed for > connection oriented networks (e.g. crankback capability). > > BR: Internet drafts have already been written on crankback. I suggest > that you please consider writing some drafts if there is something > missing. > > 8) Reliable message transfer > > BR: Very much a part of signaling. the OIF work has considered this > aspect also. > > 9) Security concerns have not been fully addressed, particularly at the > architectural level. The use of separate control network may > necessitate the need for 24 hour staff to protect against 'Denial of > Service' attacks as currently happens for IP router networks. In > general, admission control issues need to be addressed. > > BR: Please elaborate on these, specifically, what's new in the > context of GMPLS. > > 10) The definition of transparency may be overly simplified. See > comments by Ben Mack-Crane: > I think the debate on transparency indicates that the issue is not as > clear > as we might think. The OIF document you cite defines forms of > transparency > that are very straightforward (flags 1,2) not the more complex forms in > the current GMPLS drafts (flags 3..10). Also, these are easily > provided in > O-E-O or O-O-O networks operating at the lambda level, but there is no > standard for providing these over TDM multiplexed SONET/SDH links. > > BR: This is an ongoing topic of discussion. Doesn't break down > the rest of the proposal. > > If two vendors implement the same signaling but different TDM > multiplexing, that > doesn't achieve interoperability. Is there any way in the drafts to > determine the scope > of application of the various signaling elements (that is, whether they > apply to UNI or NNI, whether they apply to specific network > layers/technologies)? > 11) One summary of additional items with issues includes: > - SDH/SONET transparency. > - SDH/SONET arbitrary concatenation, flexible concatenation. > - AUG-X, TUG, STS Groups signal types and LSP capabilities. > - All kinds of end-to-end protection/restoration for any layer, except > the IP layer. > > BR: Restoration is not actually covered in the current set of drafts. > An earlier thread discussed this, and my suggestion is that this > feature be dealt with separately. > > - The concept of LSC and FSC layers, i.e. concept of lambda and fiber > switching. > > BR: What are the issues here? > > - The label set object (only used for lambda issues). > - LSP encoding type, bandwidth encoding and GPID have to be simplified > accordingly. > - MPLS extensions to control G.709 (since multiplexing, etc is not yet > defined). > > BR: A draft is forthcoming on this. > > 12) Support for paths across SONET/SDH gateways > > BR: Please clarify the issues/write drafts. > > 13) Compatibility is required/desired with legacy SDH/SONET equipment > [and also legacy DWDM] > > BR: Same as above. > > 14) Just so that we don't stop at 13 :-) > > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > From owner-mpls@UU.NET Mon Jun 4 10:05:44 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07971 for ; Mon, 4 Jun 2001 10:05:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkryu21990; Mon, 4 Jun 2001 14:04:53 GMT Received: by mail-control.mail.uu.net id QQkryu23212 for mpls-outgoing; Mon, 4 Jun 2001 14:04:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkryu23177 for ; Mon, 4 Jun 2001 14:04:04 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 QQkryu22574 for ; Mon, 4 Jun 2001 14:03:17 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 QQkryu27938 for ; Mon, 4 Jun 2001 14:03:17 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f54E3G926108 for ; Mon, 4 Jun 2001 07:03:16 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA15401 for mpls@uu.net; Mon, 4 Jun 2001 10:03:15 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkrqa18964 for ; Sat, 2 Jun 2001 05:08:23 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 QQkrqa13540 for ; Sat, 2 Jun 2001 05:06:36 GMT Received: from web10006.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web10006.mail.yahoo.com [216.136.130.42]) id QQkrqa02774 for ; Sat, 2 Jun 2001 05:06:35 GMT Message-ID: <20010602050635.6444.qmail@web10006.mail.yahoo.com> Received: from [63.116.202.66] by web10006.mail.yahoo.com; Fri, 01 Jun 2001 22:06:35 PDT Date: Fri, 1 Jun 2001 22:06:35 -0700 (PDT) From: Vishal Mishra Subject: IP Fragmentation before entering LSP To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Folks, How are fragmented IP Packets identified by the Ingress LER if the basis of classification involves part of the IP Payload, such as the Transport Layer address (say UDP Port) ? Does this mean only the first fragment of all such IP Packets travel through the Traffic Engineered LSP, and the rest of the IP fragments (being unclassified) follow the best effort (Non-TEed) Path ? This would lead to a whole lot of problems (including out of order packets). Thanks for any help !! Vishal. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Mon Jun 4 10:08:19 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08037 for ; Mon, 4 Jun 2001 10:08:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkryu02622; Mon, 4 Jun 2001 14:06:27 GMT Received: by mail-control.mail.uu.net id QQkryu23353 for mpls-outgoing; Mon, 4 Jun 2001 14:04:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkryu23275 for ; Mon, 4 Jun 2001 14:04: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 QQkryu04863 for ; Mon, 4 Jun 2001 14:03:23 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkryu26542 for ; Mon, 4 Jun 2001 14:03:22 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f54E3QU00835 for ; Mon, 4 Jun 2001 07:03:26 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA15405 for mpls@uu.net; Mon, 4 Jun 2001 10:03:20 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrxj21095 for ; Mon, 4 Jun 2001 04:59:57 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 QQkrxj09387 for ; Mon, 4 Jun 2001 04:59:53 GMT Received: from dharti.aplion.stpn.soft.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.190.129.102]) id QQkrxj22856 for ; Mon, 4 Jun 2001 04:59:48 GMT Received: from neeru (abisht [192.9.202.111]) by dharti.aplion.stpn.soft.net (8.8.7/8.8.4) with SMTP id KAA17272 for ; Mon, 4 Jun 2001 10:14:17 +0530 Message-ID: <002401c0ecb3$45b2a2d0$6fca09c0@neeru> From: "Neeru Kamra" To: Subject: Query Date: Mon, 4 Jun 2001 10:30:24 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C0ECE1.5DAFC150" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C0ECE1.5DAFC150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How will we use FEC table. How it is different from FTN table. ------=_NextPart_000_0021_01C0ECE1.5DAFC150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How will we use FEC table. How it is = different from=20 FTN table.
 
------=_NextPart_000_0021_01C0ECE1.5DAFC150-- From owner-mpls@UU.NET Mon Jun 4 10:10:09 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08076 for ; Mon, 4 Jun 2001 10:10:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkryu03460; Mon, 4 Jun 2001 14:08:10 GMT Received: by mail-control.mail.uu.net id QQkryu23971 for mpls-outgoing; Mon, 4 Jun 2001 14:06:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkryu23399 for ; Mon, 4 Jun 2001 14:05: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 QQkryu06699 for ; Mon, 4 Jun 2001 14:03:15 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkryu26283 for ; Mon, 4 Jun 2001 14:03:11 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f54E3EU00700 for ; Mon, 4 Jun 2001 07:03:14 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA15397 for mpls@uu.net; Mon, 4 Jun 2001 10:03:08 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkrpi14376 for ; Sat, 2 Jun 2001 00:41:12 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 QQkrpi27047 for ; Sat, 2 Jun 2001 00:41:08 GMT Received: from smtp01.mrf.mail.rcn.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp01.mrf.mail.rcn.net [207.172.4.60]) id QQkrpi19245 for ; Sat, 2 Jun 2001 00:41:08 GMT Received: from 66-44-0-141.s141.apx1.lnh.md.dialup.rcn.com ([66.44.0.141] helo=OSAMA) by smtp01.mrf.mail.rcn.net with smtp (Exim 3.16 #6) id 155zTX-0005z0-00 ; Fri, 01 Jun 2001 20:41:08 -0400 Reply-To: From: "Osama Farrag" To: "Choudhury, Sanjaya" , Subject: RE: Few questions related to LDP Date: Fri, 1 Jun 2001 20:40:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4FBEA8857476D311A03300204840E1CF042F7E88@whq-msgusr-02.pit.comms.marconi.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Unlabelled IP Traffic Matching FEC in your example, will not be mapped into the LDP LSP by R2, It should not be inserted by R2. R1 is Ingress of A FEC, assuming that it is the node that established the MPLS LSP "tunnel" using LDP. Regards, Osama Farrag -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Choudhury, Sanjaya Sent: Friday, June 01, 2001 3:29 PM To: mpls@UU.NET Subject: Few questions related to LDP Hi! I have some basic questions on LDP LSPs. I will appreciate, if some one can help me with these. Q1. What are the conditions that make a LSR an ingress for a FEC ? (RFC3036, A.1.2 LMp14) Q2. If a LSR is an ingress for a FEC, then it is also an "LSP Ingress" (RFC3031, 3.15 , 1) for the LSP associated with the above mentioned FEC. Is my interpretation correct ? Q3. If an LSR is _not_ an ingress for a FEC, can unlabelled IP traffic (matching the FEC) be mapped into the LDP LSP corresponding to the above mentioned FEC ? For example: R1-----(FEC1 = L1) ------R2-------(FEC1 = L2)------R3 | | R4 R1: ingress for FEC1, R3: egress for FEC1 Can/Should unlabelled IP traffic arriving at R2 (from R4 and matching prefix) be "inserted" into the LSP _transiting_ through it ? Q4. If the answer to the previous question is 'yes', then doesn't that make R2 ingress for that FEC ? Thanks, sanjay From owner-mpls@UU.NET Mon Jun 4 10:11:29 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08143 for ; Mon, 4 Jun 2001 10:11:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkryu28244; Mon, 4 Jun 2001 14:09:41 GMT Received: by mail-control.mail.uu.net id QQkryu27798 for mpls-outgoing; Mon, 4 Jun 2001 14:07:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkryu26488 for ; Mon, 4 Jun 2001 14:06: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 QQkryu09225 for ; Mon, 4 Jun 2001 14:06:03 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkryu00210 for ; Mon, 4 Jun 2001 14:06:02 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 86C7094006; Mon, 4 Jun 2001 10:05:57 -0400 (EDT) Message-ID: <3B1B95C5.C88EC9A8@sandburst.com> Date: Mon, 04 Jun 2001 10:05:57 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: MPLS Mailing List , Common Control and Measurement Protocols Subject: Re: GMPLS Last Calls References: <3B17EBB7.4E5970B6@sandburst.com> <3B18FFD5.B8989917@erols.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Anonymous, Look, I know that these IETF mailing lists are prone to flame wars and that many people prefer to be silent 'lurkers' as a result. But, unless people are willing to come forward with their comments directly, it is not very likely that they will be heard. Also, in spite of Randy's comments, people DO want to hear from members of companies. It is easy to express high sounding, but meaningless, opinions when posting as 'an individual' - especially when posting from an anonymous free E-mail account (as so many people do these days). Understand that - if you come forward with an opinion or idea that you and your colleagues have come up with together - your opinion/idea will have only the weight of an individual opinion. In theory, your opinions and ideas should be considered by IETF participants solely on their merit and not as a result of who you work for (or what your position is in the IETF). Also, in theory, it is understood that your individual opinions and ideas do not reflect the opinions and ideas of your employer. And most of us (wink, wink) believe this too. Personally, I think there is entirely too much censure (read 'flames') going on. If you and your colleagues each individually express the same opinion, you will hear comments like 'well, one company heard from'. On the other hand, if one of you expresses a common opinion, he/she will be censured for not expressing an individual opinion. It may seem like you can't win, but you have to try. And - until some IETF 'king' decides to stoop to literal censure - your opinions will be heard in spite of the flames... :-) -- Eric Gray 'Anonymous' wrote: > Eric, > > I agree with you whole heartedly. We must have the inputs from the carriers > and not from the vendors alone. Some vendors are pushing MPLS, GMPLS now, > like this are the best ideas since sliced bread. But others (Global > Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the > problems with MPLS. > > Issues that we have found relate to - > > 1. MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's > book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To > many people, QoS is the driving factor behind MPLS. This is actually > something of a misconception......QoS is not a very strong reason to deploy > MPLS..." > > 2. To do VPN with MPLS with extensions is a bad idea also since BGP is a > routing protocol that changes state quite often and to use it for VPN with > MPLS tags is not really a very smart solution as a recent comm related > magazine article points out (I don't have it here but I can provide it if you > are interested), > > 2. If not for QoS, then is it for TE? As others have said on this MPLS > thread, you can easily do TE with a host of network management tools > available out there - if not real-time, for sure, near-real-time. > > 3. Other issues pertaining to MPLS are - scalability: explicit path, RSVP, > CSFP, all found not scalable from the dawn of these technologies (see Nortel > site slides on MPLS for one confirmation), and finally > > 4. No one addresses the fact that tagging and variable packet sizing enroute > for a packet is extremely high memory and processing hog (hardly acceptable > for the hundreds and thousands of older routers out there) not to mention the > issues of label explosion, TTL, and risk of MTU violation and subsequent > fragmentation and retagging of packets. > > My colleagues and I wonder why no one speaks up. > > (Please feel free to use these items in the thread if you don't use my name. > Thanks.) > > (Anonymous) > > Eric Gray wrote: > > > Randy, > > > > Is this one of your usual insightful comments? Let's see what our > > studio audience has to say - Bzztzzt! Apparently that was a wrong > > answer. :-) > > > > Repeatedly we ask for input from carriers. We get some and we > > hear that we're only interested in hearing from individuals? As Lloyd > > said, interesting... > > > > -- > > Eric Gray > > > > You wrote: > > > > > > These are the collective opinions of me and my colleagues > > > > > > as the ietf is composed of individuals, i have not read your irrelevant > > > message. should you have personal expertise you wish to share, i would > > > be very inteested in hearing it. > > > > > > randy From owner-mpls@UU.NET Mon Jun 4 10:48:22 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09036 for ; Mon, 4 Jun 2001 10:48:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkryx29742; Mon, 4 Jun 2001 14:46:46 GMT Received: by mail-control.mail.uu.net id QQkryx07548 for mpls-outgoing; Mon, 4 Jun 2001 14:46:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkryx07461 for ; Mon, 4 Jun 2001 14:45:58 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 QQkryx17762 for ; Mon, 4 Jun 2001 14:45:21 GMT From: ananth.nagarajan@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQkryx10977 for ; Mon, 4 Jun 2001 14:45:21 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f54EvGF29069; Mon, 4 Jun 2001 09:57:16 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f54EjHs24256; Mon, 4 Jun 2001 09:45:18 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id JAA20480; Mon, 4 Jun 2001 09:45:12 -0500 (CDT) X-OpenMail-Hops: 1 Date: Mon, 4 Jun 2001 09:45:11 -0500 Message-Id: Subject: RE: Re: GMPLS Last Calls MIME-Version: 1.0 TO: ccamp@ops.ietf.org, eric.gray@sandburst.com, mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-407f3a21-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-407f3a21-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Mon, 4 Jun 2001 09:45:10 -0500" Content-Transfer-Encoding: 7bit This is to the same individual who sent me a private e-mail with similar content as was sent to Eric Gray: Please don't misinterpret my GMPLS concerns as concerns about MPLS as a whole. Please note that I am very supportive of MPLS, and in fact, I like the very aspects of MPLS that you point out as bad things (MPLS for TE, BGP-MPLS and Virtual Router-based VPNs etc.) I also have no problem with GMPLS as the protocol of choice for the optical control plane (In fact i think it is a very logical idea). My e-mail was to point out, what carriers may think as deficiencies with GMPLS for the optical control plane. I welcome comments, like Bala's and others' clarifying the different features that address our concerns. After all, voicing concerns and getting clarifications on a protocol is supposed to be an educational process as well. (Doesn't mean that all the concerns that had been expressed in my e-mail have been resolved, but those will be addressed via a separate e-mail). Cheers, Ananth -----Original Message----- From: eric.gray [mailto:eric.gray@sandburst.com] Sent: Monday, June 04, 2001 9:06 AM To: mpls; ccamp Subject: Re: GMPLS Last Calls Anonymous, Look, I know that these IETF mailing lists are prone to flame wars and that many people prefer to be silent 'lurkers' as a result. But, unless people are willing to come forward with their comments directly, it is not very likely that they will be heard. Also, in spite of Randy's comments, people DO want to hear from members of companies. It is easy to express high sounding, but meaningless, opinions when posting as 'an individual' - especially when posting from an anonymous free E-mail account (as so many people do these days). Understand that - if you come forward with an opinion or idea that you and your colleagues have come up with together - your opinion/idea will have only the weight of an individual opinion. In theory, your opinions and ideas should be considered by IETF participants solely on their merit and not as a result of who you work for (or what your position is in the IETF). Also, in theory, it is understood that your individual opinions and ideas do not reflect the opinions and ideas of your employer. And most of us (wink, wink) believe this too. Personally, I think there is entirely too much censure (read 'flames') going on. If you and your colleagues each individually express the same opinion, you will hear comments like 'well, one company heard from'. On the other hand, if one of you expresses a common opinion, he/she will be censured for not expressing an individual opinion. It may seem like you can't win, but you have to try. And - until some IETF 'king' decides to stoop to literal censure - your opinions will be heard in spite of the flames... :-) -- Eric Gray 'Anonymous' wrote: > Eric, > > I agree with you whole heartedly. We must have the inputs from the carriers > and not from the vendors alone. Some vendors are pushing MPLS, GMPLS now, > like this are the best ideas since sliced bread. But others (Global > Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the > problems with MPLS. > > Issues that we have found relate to - > > 1. MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's > book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To > many people, QoS is the driving factor behind MPLS. This is actually > something of a misconception......QoS is not a very strong reason to deploy > MPLS..." > > 2. To do VPN with MPLS with extensions is a bad idea also since BGP is a > routing protocol that changes state quite often and to use it for VPN with > MPLS tags is not really a very smart solution as a recent comm related > magazine article points out (I don't have it here but I can provide it if you > are interested), > > 2. If not for QoS, then is it for TE? As others have said on this MPLS > thread, you can easily do TE with a host of network management tools > available out there - if not real-time, for sure, near-real-time. > > 3. Other issues pertaining to MPLS are - scalability: explicit path, RSVP, > CSFP, all found not scalable from the dawn of these technologies (see Nortel > site slides on MPLS for one confirmation), and finally > > 4. No one addresses the fact that tagging and variable packet sizing enroute > for a packet is extremely high memory and processing hog (hardly acceptable > for the hundreds and thousands of older routers out there) not to mention the > issues of label explosion, TTL, and risk of MTU violation and subsequent > fragmentation and retagging of packets. > > My colleagues and I wonder why no one speaks up. > > (Please feel free to use these items in the thread if you don't use my name. > Thanks.) > > (Anonymous) > > Eric Gray wrote: > > > Randy, > > > > Is this one of your usual insightful comments? Let's see what our > > studio audience has to say - Bzztzzt! Apparently that was a wrong > > answer. :-) > > > > Repeatedly we ask for input from carriers. We get some and we > > hear that we're only interested in hearing from individuals? As Lloyd > > said, interesting... > > > > -- > > Eric Gray > > > > You wrote: > > > > > > These are the collective opinions of me and my colleagues > > > > > > as the ietf is composed of individuals, i have not read your irrelevant > > > message. should you have personal expertise you wish to share, i would > > > be very inteested in hearing it. > > > > > > randy --openmail-part-407f3a21-00000001-- From owner-mpls@UU.NET Mon Jun 4 10:50:05 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09068 for ; Mon, 4 Jun 2001 10:50:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkryx03758; Mon, 4 Jun 2001 14:49:15 GMT Received: by mail-control.mail.uu.net id QQkryx07932 for mpls-outgoing; Mon, 4 Jun 2001 14:48:46 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkryx07849 for ; Mon, 4 Jun 2001 14:48:17 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 QQkryx21857 for ; Mon, 4 Jun 2001 14:47:40 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkryx13610 for ; Mon, 4 Jun 2001 14:47:40 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id HAA00384; Mon, 4 Jun 2001 07:47:39 -0700 (PDT) Message-Id: <200106041447.HAA00384@red.juniper.net> To: MPLS Mailing List , Common Control and Measurement Protocols cc: Eric Gray Subject: Re: GMPLS Last Calls In-Reply-To: Your message of "Mon, 04 Jun 2001 10:05:57 EDT." <3B1B95C5.C88EC9A8@sandburst.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77114.991666059.1@juniper.net> Date: Mon, 04 Jun 2001 07:47:39 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Anonymous, > I agree with you whole heartedly. We must have the inputs from the carriers > and not from the vendors alone. Some vendors are pushing MPLS, GMPLS now, > like this are the best ideas since sliced bread. But others (Global > Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the > problems with MPLS. > > Issues that we have found relate to - > > 1. MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's > book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To > many people, QoS is the driving factor behind MPLS. This is actually > something of a misconception......QoS is not a very strong reason to deploy > MPLS..." The above seems like quoting out of context. To put it in the proper context here is the full sentence: Compared to other factors, such as traffic engineering and Virtual Private Network support, QoS is not a very strong reason to deploy MPLS. So, what you seem to be missing is that it is *relative* to other applications, such as TE and VPN, that "QoS is not a very strong reason to deploy MPLS". And while on the subject of QoS and MPLS, further in the first section of Chapter 6 (page 148): ..there are some novel QoS capabilities that can be supported across a provider network using MPLS that, while not being truly end-to-end, nevertheless may prove very useful. One of these, guaranteed bandwidth LSPs, is discussed in Section 7.5.2. > 2. To do VPN with MPLS with extensions is a bad idea also since BGP is a > routing protocol that changes state quite often and to use it for VPN with > MPLS tags is not really a very smart solution as a recent comm related > magazine article points out (I don't have it here but I can provide it if > you are interested), At best whether "to do VPN with MPLS with extensions" is "a bad idea" is a matter of opinion. However, since at the beginning of you message you suggested to get inputs from the carriers, you may look at the list of authors of draft-rosen-rfc2547bis-03.txt, as this list may give you a hint of what carriers think about this technology. > 2. If not for QoS, then is it for TE? As others have said on this MPLS > thread, you can easily do TE with a host of network management tools > available out there - if not real-time, for sure, near-real-time. First of all, there is a difference between "said" and "done". So, while other "have said.. you can easily do TE with a host of network management tools", one could ask whether they actually done this. And if yes, then the next question would be to compare results with TE based on MPLS Constraint-based routing. > 3. Other issues pertaining to MPLS are - scalability: explicit path, RSVP, > CSFP, all found not scalable from the dawn of these technologies (see Nortel > site slides on MPLS for one confirmation), and finally Since you quoted from "MPLS: Technology and Application" before, I'd like to suggest to look at Section 7.6.2 of this book for the discussion of alledged scalability problem with RSVP, when used in conjunction with MPLS Constraint-based routing. Yakov. From owner-mpls@UU.NET Mon Jun 4 11:16:57 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09573 for ; Mon, 4 Jun 2001 11:16:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkryz09716; Mon, 4 Jun 2001 15:15:24 GMT Received: by mail-control.mail.uu.net id QQkryy29199 for mpls-outgoing; Mon, 4 Jun 2001 15:14:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkryy29166 for ; Mon, 4 Jun 2001 15:14:47 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 QQkryy00320 for ; Mon, 4 Jun 2001 15:13:32 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkryy07063 for ; Mon, 4 Jun 2001 15:13:31 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA00953; Mon, 4 Jun 2001 08:13:31 -0700 (PDT) Message-Id: <200106041513.IAA00953@red.juniper.net> To: MPLS Mailing List , Common Control and Measurement Protocols , Eric Gray Subject: Re: GMPLS Last Calls In-Reply-To: Your message of "Mon, 04 Jun 2001 07:47:39 PDT." <200106041447.HAA00384@red.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <81223.991667611.1@juniper.net> Date: Mon, 04 Jun 2001 08:13:31 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk [minor typo...] > Since you quoted from "MPLS: Technology and Application" before, > I'd like to suggest to look at Section 7.6.2 of this book for the ^^^^^ 7.2.6 > discussion of alledged scalability problem with RSVP, when used in > conjunction with MPLS Constraint-based routing. Yakov. From owner-mpls@UU.NET Mon Jun 4 12:01:01 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11130 for ; Mon, 4 Jun 2001 12:01:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzb12732; Mon, 4 Jun 2001 15:59:27 GMT Received: by mail-control.mail.uu.net id QQkrzb05224 for mpls-outgoing; Mon, 4 Jun 2001 15:58:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkrzb05213 for ; Mon, 4 Jun 2001 15:58: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 QQkrzb04881 for ; Mon, 4 Jun 2001 15:57:50 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQkrzb10707 for ; Mon, 4 Jun 2001 15:57:49 GMT Received: from cirwm3nt01.nor.bt.com by gandalf (local) with ESMTP; Mon, 4 Jun 2001 16:56:54 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Mon, 4 Jun 2001 16:57:03 +0100 Message-ID: To: yakov@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Cc: eric.gray@sandburst.com Subject: RE: GMPLS Last Calls Date: Mon, 4 Jun 2001 16:56:49 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yakov Rekhter wrote 04 June 2001 15:48 > > > > Issues that we have found relate to - > > > > 1. MPLS is not for QoS (See first paragraph of Chapter 6 > of Yakov Rekhter's > > book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), > Yakov says, " To > > many people, QoS is the driving factor behind MPLS. This > is actually > > something of a misconception......QoS is not a very strong > reason to deploy > > MPLS..." > > The above seems like quoting out of context. To put it in the proper > context here is the full sentence: > > Compared to other factors, such as traffic engineering and Virtual > Private Network support, QoS is not a very strong reason to deploy > MPLS. > > So, what you seem to be missing is that it is *relative* to other > applications, such as TE and VPN, that "QoS is not a very > strong reason > to deploy MPLS". > > And while on the subject of QoS and MPLS, further in the > first section > of Chapter 6 (page 148): > > ..there are some novel QoS capabilities that can be supported across > a provider network using MPLS that, while not being truly > end-to-end, > nevertheless may prove very useful. One of these, > guaranteed bandwidth > LSPs, is discussed in Section 7.5.2. NH=> MPLS has the potential to become very important and have a key role on QoS issues (and it should not be confused with GMPLS see 'note' at end).....but to get there we need to recognise these points: - LDP is to me an IP routing adjunct.....its main role as I see it is to provde address partitioning (or a 'hierachy of routing' as I think you described it in your book Yakov....which, if anyone has not read it, I can strongly recommend); - LDP induced LSPs do not really create a layer network.....since they allow merging, and this in itself causes some hard QoS problems....like how does one define availability in a mpt-pt tree? [Its the old issue of 'no free lunch'...if you push down a problem in 1 dimension (eg scalability), it creates a problem somewhere else (eg measuing availability in VPNs say)]; - Explicitly routed LSPs on the other hand do form true layer networks....since they need to be signalled they exist as true trail objects in their own right. And it was these apsects that our OAM paper tried to address for MPLS....that is, to attack the QoS problem (wrt operational processes and measurements) one needs to first define the defects (and MPLS does have the potential to introduce new ones) and the consequent actions...and from this we can define availability of the LSPs which in turn is a pre-requisite to measuring QoS (since QoS is only relevant to the up-state of the LSP). However.....we have had a 'hard time' from a few on this (maybe there is a silent majority that support this work?)....and this relates to Eric Gray's prior mail on why people don't speak up.....besides the fear of ridicule or abuse, one can only try so many tmes before giving up and going elsewhere. So maybe there is a deep-seated culture problem that needs addressing? Note - MPLS introduces a new user-plane technology....the shim header. By definition, and as noted above, operators need to manage this in an OAM/performance sense. MPLS has the ability to be extended to end systems....I know this is not currently on the agenda of many, but it has that *potential* (ie so that applications could choose a priori the transfer mode, co or cnls). The arguments for a single control-plane across MPLS and IP (or to be more precise the 'addressing facet' of the control-plane) is important if ever MPLS was extended to end systems.....this was the real problem with ATM and IP unification, ie disjoint addressing. GMPLS on the other hand does not introduce a new user-plane. It is about re-using control-plane facets for different layer networks. In principle this is a laudable aim, but its actual embodiment has many technical and commercial implications that are too deep to go into here and we (ie I and colleagues in BT) are addressing these elsewhere. So all I wanted to say here is that one should not compare MPLS and GMPLS like they are same thing. > From owner-mpls@UU.NET Mon Jun 4 12:17:18 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11621 for ; Mon, 4 Jun 2001 12:17:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzd05329; Mon, 4 Jun 2001 16:15:22 GMT Received: by mail-control.mail.uu.net id QQkrzc26412 for mpls-outgoing; Mon, 4 Jun 2001 16:14:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkrzc26356 for ; Mon, 4 Jun 2001 16:14:16 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 QQkrzc10172; Mon, 4 Jun 2001 16:14:11 GMT From: PDiamond@semtech.com Received: from mail.semtech.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [209.241.157.179]) id QQkrzc03667; Mon, 4 Jun 2001 16:14:11 GMT Subject: Re: GMPLS Last Calls To: Eric Gray Cc: Common Control and Measurement Protocols , MPLS Mailing List , owner-mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Mon, 4 Jun 2001 09:11:05 -0700 X-MIMETrack: Serialize by Router on Mail/SMTC(Release 5.0.6a |January 17, 2001) at 06/04/2001 09:13:13 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Eric, You are right on the nose.. these communications forums depend on interactive dialogue and freedom to have and courage to express an opinion. When people cloak their identity to avoid direct confrontation or worst yet to falsly influence....well that is one of the downsides to freedom of speach. All with valid reaons need to speak up...the listener has to alboe to filter the wheat from the chaff. Pat From owner-mpls@UU.NET Mon Jun 4 12:25:57 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11876 for ; Mon, 4 Jun 2001 12:25:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzd08208; Mon, 4 Jun 2001 16:24:14 GMT Received: by mail-control.mail.uu.net id QQkrzd27730 for mpls-outgoing; Mon, 4 Jun 2001 16:23:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkrzd27642 for ; Mon, 4 Jun 2001 16:22:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkrzd26652 for ; Mon, 4 Jun 2001 16:20:16 GMT Received: from philotas.hosting.pacbell.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: philotas.hosting.pacbell.net [216.100.99.24]) id QQkrzd12786 for ; Mon, 4 Jun 2001 16:20:15 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by philotas.hosting.pacbell.net id MAA03711; Mon, 4 Jun 2001 12:20:14 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: , "Vishal Mishra" Subject: RE: IP Fragmentation before entering LSP Date: Mon, 4 Jun 2001 09:19:26 -0700 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.2911.0) Importance: Normal In-Reply-To: <20010602050635.6444.qmail@web10006.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I think all the fragments should be applied with the same classification policy. The identification field in the IP header would allow you to associate a fragment to a datagram at the LER. In case a fragment arrives out of order before the first one comes, I think you may buffer it until the first one arrives or a timer expires. - jay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vishal Mishra Sent: Friday, June 01, 2001 10:07 PM To: mpls@UU.NET Subject: IP Fragmentation before entering LSP Hi Folks, How are fragmented IP Packets identified by the Ingress LER if the basis of classification involves part of the IP Payload, such as the Transport Layer address (say UDP Port) ? Does this mean only the first fragment of all such IP Packets travel through the Traffic Engineered LSP, and the rest of the IP fragments (being unclassified) follow the best effort (Non-TEed) Path ? This would lead to a whole lot of problems (including out of order packets). Thanks for any help !! Vishal. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Mon Jun 4 12:46:10 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12341 for ; Mon, 4 Jun 2001 12:46:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrze00086; Mon, 4 Jun 2001 16:44:36 GMT Received: by mail-control.mail.uu.net id QQkrze29822 for mpls-outgoing; Mon, 4 Jun 2001 16:44:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrze29814 for ; Mon, 4 Jun 2001 16:43:59 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 QQkrze21875 for ; Mon, 4 Jun 2001 16:42:54 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 QQkrze14205 for ; Mon, 4 Jun 2001 16:42:49 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 MAA26463 for ; Mon, 4 Jun 2001 12:42:47 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01709 for ; Mon, 4 Jun 2001 12:42:46 -0400 (EDT) Message-ID: <3B1BBAB3.CFBE3DDE@marconi.com> Date: Mon, 04 Jun 2001 12:43:31 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: IP Fragmentation before entering LSP References: <20010602050635.6444.qmail@web10006.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vishal Mishra wrote: > > How are fragmented IP Packets identified by the Ingress LER > if the basis of classification involves part of the IP Payload, > such as the Transport Layer address (say UDP Port) ? > > Does this mean only the first fragment of all such IP Packets > travel through the Traffic Engineered LSP, and the rest of the IP > fragments (being unclassified) follow the best effort (Non-TEed) > Path ? > > This would lead to a whole lot of problems (including out of > order packets). If the ingress LER is going to classify on L4+ information, then that information must obviously be present. There are only three possible choices I can see here: 1: Have the ingress LER reassemble the fragments before injecting into the LSP (possibly re-fragmenting them after reassembly). The upside is that it eliminates this problem altogether. The downside is that it may be impossible to do this at line-rate, and the router will have to deal the the possibility that some of the fragments may never arrive (perhaps they got routed through some other router, or perhaps they were lost.) 2: Have the ingress LER forward the first fragment (the one with the L4 header) according to its policy, and ignore the L4 information for other packets. The upside is that you don't have to worry about late/missing fragments. The downside is that the first fragment may take a different route through the network from the other fragments, leading to out of order delivery. 3: Have the ingress LER use stateful packet inspection. When the first fragment arrives, it should record enough information to be able to recognize the remaining fragments and send them into the same LSP. The upside is that it solves the problem and you don't need to buffer the entire packet. The downside is that the first fragment may not arrive first, and that you need to deal with the possibility that one or more fragments may never arrive. The only way to avoid the problem altogether is to restrict your packet classification to what is available in the IP header. But this may not be acceptible to all customers. -- David From owner-mpls@UU.NET Mon Jun 4 13:04:59 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12969 for ; Mon, 4 Jun 2001 13:04:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzg14718; Mon, 4 Jun 2001 17:03:16 GMT Received: by mail-control.mail.uu.net id QQkrzg06065 for mpls-outgoing; Mon, 4 Jun 2001 17:02:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrzg05830 for ; Mon, 4 Jun 2001 17:02:27 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 QQkrzg02334 for ; Mon, 4 Jun 2001 17:00:48 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkrzg11104 for ; Mon, 4 Jun 2001 17:00:48 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id E57B79400B; Mon, 4 Jun 2001 13:00:47 -0400 (EDT) Message-ID: <3B1BBEBF.77A0D0C6@sandburst.com> Date: Mon, 04 Jun 2001 13:00:47 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: IP Fragmentation before entering LSP References: <20010602050635.6444.qmail@web10006.mail.yahoo.com> <3B1BBAB3.CFBE3DDE@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, There's a fourth option implied in the downside of each of your 3 listed options. Since it is possible for the packets to arrive out of order at the ingress to the LSP, then it is also likely that it is acceptable to just do as Vishal suggested (even though this seems not to be a preferred option). If it was possible for packets to arrive out of order at the ingress, then it was certain that they would have arrived out of order at the destination. Why should we expect the ingress LSR to fix this? -- Eric Gray You wrote: > Vishal Mishra wrote: > > > > How are fragmented IP Packets identified by the Ingress LER > > if the basis of classification involves part of the IP Payload, > > such as the Transport Layer address (say UDP Port) ? > > > > Does this mean only the first fragment of all such IP Packets > > travel through the Traffic Engineered LSP, and the rest of the IP > > fragments (being unclassified) follow the best effort (Non-TEed) > > Path ? > > > > This would lead to a whole lot of problems (including out of > > order packets). > > If the ingress LER is going to classify on L4+ information, then that > information must obviously be present. There are only three possible > choices I can see here: > > 1: Have the ingress LER reassemble the fragments before injecting > into the LSP (possibly re-fragmenting them after reassembly). > The upside is that it eliminates this problem altogether. The > downside is that it may be impossible to do this at line-rate, > and the router will have to deal the the possibility that some of > the fragments may never arrive (perhaps they got routed through > some other router, or perhaps they were lost.) > > 2: Have the ingress LER forward the first fragment (the one with the > L4 header) according to its policy, and ignore the L4 information > for other packets. The upside is that you don't have to worry > about late/missing fragments. The downside is that the first > fragment may take a different route through the network from the > other fragments, leading to out of order delivery. > > 3: Have the ingress LER use stateful packet inspection. When the > first fragment arrives, it should record enough information to be > able to recognize the remaining fragments and send them into the > same LSP. The upside is that it solves the problem and you don't > need to buffer the entire packet. The downside is that the first > fragment may not arrive first, and that you need to deal with the > possibility that one or more fragments may never arrive. > > The only way to avoid the problem altogether is to restrict your packet > classification to what is available in the IP header. But this may not > be acceptible to all customers. > > -- David From owner-mpls@UU.NET Mon Jun 4 13:52:10 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14430 for ; Mon, 4 Jun 2001 13:52:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzj25447; Mon, 4 Jun 2001 17:50:31 GMT Received: by mail-control.mail.uu.net id QQkrzj26901 for mpls-outgoing; Mon, 4 Jun 2001 17:49:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrzj26888 for ; Mon, 4 Jun 2001 17:49:37 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 QQkrzj09877 for ; Mon, 4 Jun 2001 17:49:19 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkrzj23549 for ; Mon, 4 Jun 2001 17:49:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f54HnLU15861 for ; Mon, 4 Jun 2001 10:49:22 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA16541 for mpls@uu.net; Mon, 4 Jun 2001 13:49:16 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkrzi25357 for ; Mon, 4 Jun 2001 17:37: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 QQkrzi16698; Mon, 4 Jun 2001 17:37:18 GMT Received: from lowblow.svc.tds.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lowblow.svc.tds.net [204.246.1.39]) id QQkrzi26899; Mon, 4 Jun 2001 17:37:17 GMT Received: from tds.net ([64.244.22.241]) by lowblow.svc.tds.net with ESMTP id <20010604173717.LONC29822.lowblow@tds.net>; Mon, 4 Jun 2001 12:37:17 -0500 Message-ID: <3B1BC7B4.7B1546DC@tds.net> Date: Mon, 04 Jun 2001 13:39:00 -0400 From: "Patricia A. Holden" X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: PDiamond@semtech.com CC: Randy Bush , ananth.nagarajan@mail.sprint.com, ccamp@ops.ietf.org, lynn.neir@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, owner-mpls@UU.NET, Tammy.Ferris@mail.sprint.com, wesam.alanqar@mail.sprint.com Subject: Re: GMPLS Last Calls References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit i agree. PDiamond@semtech.com wrote: > nasty.... > > the mesage is very relevant From owner-mpls@UU.NET Mon Jun 4 14:07:58 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14840 for ; Mon, 4 Jun 2001 14:07:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzk13500; Mon, 4 Jun 2001 18:06:46 GMT Received: by mail-control.mail.uu.net id QQkrzk11559 for mpls-outgoing; Mon, 4 Jun 2001 18:06:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkrzk11501 for ; Mon, 4 Jun 2001 18:06:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkrzk26411 for ; Mon, 4 Jun 2001 18:04:45 GMT Received: from NOD.RESTON.MCI.NET by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nod.reston.mci.net [166.60.6.38]) id QQkrzk17304 for ; Mon, 4 Jun 2001 18:04:45 GMT Received: from rbonica ([166.60.27.25]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with SMTP id <01K4DDWZTK7GA0UGWB@shoe.reston.mci.net> for mpls@UU.NET; Mon, 04 Jun 2001 14:04:44 -0400 (EDT) Date: Mon, 04 Jun 2001 13:49:10 -0400 From: Ron Bonica Subject: RE: IP Fragmentation before entering LSP In-reply-to: <3B1BBAB3.CFBE3DDE@marconi.com> To: David Charlap , mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Dave, As you have observed, options 1 and 3 may not be compatible with line rate forwarding in the network core. Option 2 may cause fragment re-ordering. A fourth option is to prevent all fragments from traveling on an LSP. If possible, forward all fragments using standard IP forwarding mechanisms. If this is not possible, discard the datagram. Ron > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David > Charlap > Sent: Monday, June 04, 2001 12:44 PM > To: mpls@UU.NET > Subject: Re: IP Fragmentation before entering LSP > > > Vishal Mishra wrote: > > > > How are fragmented IP Packets identified by the Ingress LER > > if the basis of classification involves part of the IP Payload, > > such as the Transport Layer address (say UDP Port) ? > > > > Does this mean only the first fragment of all such IP Packets > > travel through the Traffic Engineered LSP, and the rest of the IP > > fragments (being unclassified) follow the best effort (Non-TEed) > > Path ? > > > > This would lead to a whole lot of problems (including out of > > order packets). > > If the ingress LER is going to classify on L4+ information, then that > information must obviously be present. There are only three possible > choices I can see here: > > 1: Have the ingress LER reassemble the fragments before injecting > into the LSP (possibly re-fragmenting them after reassembly). > The upside is that it eliminates this problem altogether. The > downside is that it may be impossible to do this at line-rate, > and the router will have to deal the the possibility that some of > the fragments may never arrive (perhaps they got routed through > some other router, or perhaps they were lost.) > > 2: Have the ingress LER forward the first fragment (the one with the > L4 header) according to its policy, and ignore the L4 information > for other packets. The upside is that you don't have to worry > about late/missing fragments. The downside is that the first > fragment may take a different route through the network from the > other fragments, leading to out of order delivery. > > 3: Have the ingress LER use stateful packet inspection. When the > first fragment arrives, it should record enough information to be > able to recognize the remaining fragments and send them into the > same LSP. The upside is that it solves the problem and you don't > need to buffer the entire packet. The downside is that the first > fragment may not arrive first, and that you need to deal with the > possibility that one or more fragments may never arrive. > > The only way to avoid the problem altogether is to restrict your packet > classification to what is available in the IP header. But this may not > be acceptible to all customers. > > -- David From owner-mpls@UU.NET Mon Jun 4 14:10:12 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14931 for ; Mon, 4 Jun 2001 14:10:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzk01960; Mon, 4 Jun 2001 18:08:20 GMT Received: by mail-control.mail.uu.net id QQkrzk14164 for mpls-outgoing; Mon, 4 Jun 2001 18:07:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrzk12180 for ; Mon, 4 Jun 2001 18:06:43 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 QQkrzk24013 for ; Mon, 4 Jun 2001 18:06:27 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.227.9.200]) id QQkrzk12821 for ; Mon, 4 Jun 2001 18:06:23 GMT Received: from pluris.com (do101085.pluris.com [172.16.55.241]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA21972; Mon, 4 Jun 2001 11:05:18 -0700 (PDT) Message-ID: <3B1BCDDE.FAB2985E@pluris.com> Date: Mon, 04 Jun 2001 11:05:18 -0700 From: Chris Kuszmaul Organization: Pluris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Patricia A. Holden" CC: Eric Gray , MPLS Mailing List Subject: Re: LDP requires break-before-make References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> <3AF06AB7.81EE10AB@marconi.com> <3AF08792.4A56B50F@pluris.com> <3B142656.C7E831A0@pluris.com> <3B17A601.EF168134@sandburst.com> <3B17C9EC.1833E239@pluris.com> <3B1BCBE5.59AFA7CE@tds.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Looks right to me. CLK "Patricia A. Holden" wrote: > So what you are saying is that A sends a label-withdraw(of label1) followed by a > label-mapping(of label2) message to B and B sends back a label-release(of label1) to A > after completing the label-mapping message(of label2). Is my understanding correct? > > Thanks, > Pat > > Chris Kuszmaul wrote: > > > Hi Eric > > > > I think you are right. Consider LSRs A and B. > > > > A sends to B the label mapping: > > > > There is nothing I am aware of in the spec that prevents A from sending another > > mapping, such as: > > , prior to receiving a label release (of label1) from B. > > > > What I was saying was that B had to release label1 (transmit a label release to A) > > before B could accept the mapping of label2. Your solution, of combining a label > > withdrawal (of label1) with the label mapping of label2, in a PDU, seems to basically > > make sense. > > > > The semantics of ordering is necessary, but not sufficient to prevent a break before > > make. I think there needs to be a sense of atomicity as well: Both the label > > withdrawal and the label mapping need to be done, or neither should be done. In > > particular, the label release message transmitted by B MUST be contemporaneous with > > the completion of the label mapping. The LDP spec does not *preclude* just such a > > behavior, and so a PDU containing a label withdrawal and a label mapping can be > > treated as a label-mapping-overwrite, without violating the spec, and thus preventing > > a break before make. > > > > CLK > > > > Eric Gray wrote: > > > > > Chris, > > > > > > I understand your concern. A few years ago (early '98) I had > > > proposed a semantic interpretation for LDP that directly related > > > to this. The response was to explicitly prohibit the behavior > > > which would have had this semantic. > > > > > > I had suggested that (in DU mode) an LSR that advertised a > > > new label for exactly the same FEC as it had previously advertised > > > a different label meant for the upstream LSR to replace the previous > > > label with the new one. Over time, I came to undestand why this > > > may have been a little too simplistic. Also, it may be needed when > > > DoD label advertisement is being used as well. > > > > > > I think your basic idea of using a new message type will work. > > > I had thought of that and talked with a couple of people on the LDP > > > design team about it - and they were not too receptive to the idea > > > as part of the base LDP specification (adds complexity not really > > > required for basic functionality). Also - at the time - I thought it > > > possible to achieve a very similar result by simply including both > > > the label withdraw and the new label mapping in the same PDU (an > > > LDP PDU can contain multiple LDP messages). > > > > > > Of course, this latter approach depends on a few things: > > > > > > o that you are not correct in your assertion that a downstream > > > LSR is required to wait for a label release message prior > > > to sending a new label mapping (*), > > > > > > o that an upstream LSR actually looks for a 'replacement' > > > label mapping message in a PDU that contains a label > > > withdraw message, > > > > > > o that this upstream LSR processes multiple messages in a > > > single PDU in the order in which they appear in the PDU > > > > > > and > > > > > > o that the dowbstream LSR put them in the PDU in the order > > > in which it expected them to be processed (+). > > > > > > * I think that the requirement is that the downstream LSR MUST > > > not re-use the same label until it receives a label release for a > > > label it has withdrawn. I do not think there is any statement in > > > the specification that prohibits sending a new label mapping > > > prior to receiving a label release for the previous mapping for > > > the same FEC. Please let me know if there is text in the spec > > > to the contrary. > > > > > > + Given that I am right in my interpretation of the current spec wrt > > > issuing a new label mapping after a label withdraw, the last two > > > bullets naturally fall out since the current restriction on sending > > > a new label mapping (with a different label) prior to withdrawing > > > a prior label mapping imposes an ordering resptriction on adding > > > messages to a PDU and processing them on receipt. This ordering > > > is not hard to achieve. > > > > > > Essentially, a downstream LSR can try this approach and hope that > > > the upstream LSR was built to be robust and resilient (either using the > > > approach above, or some other approach). > > > > > > -- > > > Eric Gray > > > > > > You wrote: > > > > > > > Before a label can be mapped to an FEC that has already been mapped, the LSR > > > > must release the old label (prompted perhaps by a withdrawal message). Thus, LDP > > > > calls for a break-before-make on LSP updates. It would seem a straightforward > > > > matter for the protocol to include a withdraw-and-map message that performs this > > > > sequence atomically, and so preserves a make-before-break condition. > > > > > > > > Is there some reason for not providing for this kind of functionality? > > > > > > > > Thanks for any comments. > > > > > > > > CLK > > > > > > > > PS: The careful reader will realize that I have mentioned this issue before in > > > > the thread [Re: Receive Label Receive !!], but have not seen any reply. This is > > > > an attempt to focus the question and broaden the pool of possible respondents. From owner-mpls@UU.NET Mon Jun 4 14:24:41 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15177 for ; Mon, 4 Jun 2001 14:24:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzl04037; Mon, 4 Jun 2001 18:20:25 GMT Received: by mail-control.mail.uu.net id QQkrzl20485 for mpls-outgoing; Mon, 4 Jun 2001 18:19:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrzl20452 for ; Mon, 4 Jun 2001 18:19:37 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 QQkrzl11854 for ; Mon, 4 Jun 2001 18:16:34 GMT Received: from philotas.hosting.pacbell.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: philotas.hosting.pacbell.net [216.100.99.24]) id QQkrzl28115 for ; Mon, 4 Jun 2001 18:16:33 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by philotas.hosting.pacbell.net id OAA08015; Mon, 4 Jun 2001 14:16:26 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "David Charlap" , Subject: RE: IP Fragmentation before entering LSP Date: Mon, 4 Jun 2001 11:15:38 -0700 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.2911.0) Importance: Normal In-Reply-To: <3B1BBAB3.CFBE3DDE@marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I agree with most but I think applying one policy to the first fragment and another to the rest is problematic, particularly from the QoS's perspective, if not for others. So although all possible, I think options 1 and 3 are more realistic. But between 1 and 3, I think if you can do 1, you have done 3 already. You need to deal with out-of-order arrivals or fragments that never come for both options 1 and 3, but 3 is almost like a subset of 1, operation wise. One problem with option one is that the packets arrive in fragments most likely is because of the MTU restriction in the first place. If you physically reassemble the fragments, the lower layer has to break them up again on the way out, most likely. Yet another thing is, if you physically reassemble them, your switch/router has to deal with jumbo frames, not necessarily hardware friendly thing to have. I think 3 is probably better. Once the first fragment arrives, you know what to do for the rest and you don't have to hold on to them. Implementation wise, as also indicated in my previous message, I think it should be fairly straightforward and not too expensive either. - jay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Charlap Sent: Monday, June 04, 2001 9:44 AM To: mpls@UU.NET Subject: Re: IP Fragmentation before entering LSP Vishal Mishra wrote: > > How are fragmented IP Packets identified by the Ingress LER > if the basis of classification involves part of the IP Payload, > such as the Transport Layer address (say UDP Port) ? > > Does this mean only the first fragment of all such IP Packets > travel through the Traffic Engineered LSP, and the rest of the IP > fragments (being unclassified) follow the best effort (Non-TEed) > Path ? > > This would lead to a whole lot of problems (including out of > order packets). If the ingress LER is going to classify on L4+ information, then that information must obviously be present. There are only three possible choices I can see here: 1: Have the ingress LER reassemble the fragments before injecting into the LSP (possibly re-fragmenting them after reassembly). The upside is that it eliminates this problem altogether. The downside is that it may be impossible to do this at line-rate, and the router will have to deal the the possibility that some of the fragments may never arrive (perhaps they got routed through some other router, or perhaps they were lost.) 2: Have the ingress LER forward the first fragment (the one with the L4 header) according to its policy, and ignore the L4 information for other packets. The upside is that you don't have to worry about late/missing fragments. The downside is that the first fragment may take a different route through the network from the other fragments, leading to out of order delivery. 3: Have the ingress LER use stateful packet inspection. When the first fragment arrives, it should record enough information to be able to recognize the remaining fragments and send them into the same LSP. The upside is that it solves the problem and you don't need to buffer the entire packet. The downside is that the first fragment may not arrive first, and that you need to deal with the possibility that one or more fragments may never arrive. The only way to avoid the problem altogether is to restrict your packet classification to what is available in the IP header. But this may not be acceptible to all customers. -- David From owner-mpls@UU.NET Mon Jun 4 14:53:39 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15687 for ; Mon, 4 Jun 2001 14:53:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzn18926; Mon, 4 Jun 2001 18:52:03 GMT Received: by mail-control.mail.uu.net id QQkrzn24555 for mpls-outgoing; Mon, 4 Jun 2001 18:51:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrzn24471 for ; Mon, 4 Jun 2001 18:51:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkrzn16175 for ; Mon, 4 Jun 2001 18:50:19 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkrzn19150 for ; Mon, 4 Jun 2001 18:50:18 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f54IoLU19637 for ; Mon, 4 Jun 2001 11:50:21 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA16765 for mpls@uu.net; Mon, 4 Jun 2001 14:50:16 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkrzj27540 for ; Mon, 4 Jun 2001 17:55: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 QQkrzj02421 for ; Mon, 4 Jun 2001 17:55:10 GMT Received: from lowblow.svc.tds.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lowblow.svc.tds.net [204.246.1.39]) id QQkrzj02835 for ; Mon, 4 Jun 2001 17:55:09 GMT Received: from tds.net ([64.244.22.241]) by lowblow.svc.tds.net with ESMTP id <20010604175509.LUBF29822.lowblow@tds.net>; Mon, 4 Jun 2001 12:55:09 -0500 Message-ID: <3B1BCBE5.59AFA7CE@tds.net> Date: Mon, 04 Jun 2001 13:56:53 -0400 From: "Patricia A. Holden" X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Kuszmaul CC: Eric Gray , MPLS Mailing List Subject: Re: LDP requires break-before-make References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> <3AF06AB7.81EE10AB@marconi.com> <3AF08792.4A56B50F@pluris.com> <3B142656.C7E831A0@pluris.com> <3B17A601.EF168134@sandburst.com> <3B17C9EC.1833E239@pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit So what you are saying is that A sends a label-withdraw(of label1) followed by a label-mapping(of label2) message to B and B sends back a label-release(of label1) to A after completing the label-mapping message(of label2). Is my understanding correct? Thanks, Pat Chris Kuszmaul wrote: > Hi Eric > > I think you are right. Consider LSRs A and B. > > A sends to B the label mapping: > > There is nothing I am aware of in the spec that prevents A from sending another > mapping, such as: > , prior to receiving a label release (of label1) from B. > > What I was saying was that B had to release label1 (transmit a label release to A) > before B could accept the mapping of label2. Your solution, of combining a label > withdrawal (of label1) with the label mapping of label2, in a PDU, seems to basically > make sense. > > The semantics of ordering is necessary, but not sufficient to prevent a break before > make. I think there needs to be a sense of atomicity as well: Both the label > withdrawal and the label mapping need to be done, or neither should be done. In > particular, the label release message transmitted by B MUST be contemporaneous with > the completion of the label mapping. The LDP spec does not *preclude* just such a > behavior, and so a PDU containing a label withdrawal and a label mapping can be > treated as a label-mapping-overwrite, without violating the spec, and thus preventing > a break before make. > > CLK > > Eric Gray wrote: > > > Chris, > > > > I understand your concern. A few years ago (early '98) I had > > proposed a semantic interpretation for LDP that directly related > > to this. The response was to explicitly prohibit the behavior > > which would have had this semantic. > > > > I had suggested that (in DU mode) an LSR that advertised a > > new label for exactly the same FEC as it had previously advertised > > a different label meant for the upstream LSR to replace the previous > > label with the new one. Over time, I came to undestand why this > > may have been a little too simplistic. Also, it may be needed when > > DoD label advertisement is being used as well. > > > > I think your basic idea of using a new message type will work. > > I had thought of that and talked with a couple of people on the LDP > > design team about it - and they were not too receptive to the idea > > as part of the base LDP specification (adds complexity not really > > required for basic functionality). Also - at the time - I thought it > > possible to achieve a very similar result by simply including both > > the label withdraw and the new label mapping in the same PDU (an > > LDP PDU can contain multiple LDP messages). > > > > Of course, this latter approach depends on a few things: > > > > o that you are not correct in your assertion that a downstream > > LSR is required to wait for a label release message prior > > to sending a new label mapping (*), > > > > o that an upstream LSR actually looks for a 'replacement' > > label mapping message in a PDU that contains a label > > withdraw message, > > > > o that this upstream LSR processes multiple messages in a > > single PDU in the order in which they appear in the PDU > > > > and > > > > o that the dowbstream LSR put them in the PDU in the order > > in which it expected them to be processed (+). > > > > * I think that the requirement is that the downstream LSR MUST > > not re-use the same label until it receives a label release for a > > label it has withdrawn. I do not think there is any statement in > > the specification that prohibits sending a new label mapping > > prior to receiving a label release for the previous mapping for > > the same FEC. Please let me know if there is text in the spec > > to the contrary. > > > > + Given that I am right in my interpretation of the current spec wrt > > issuing a new label mapping after a label withdraw, the last two > > bullets naturally fall out since the current restriction on sending > > a new label mapping (with a different label) prior to withdrawing > > a prior label mapping imposes an ordering resptriction on adding > > messages to a PDU and processing them on receipt. This ordering > > is not hard to achieve. > > > > Essentially, a downstream LSR can try this approach and hope that > > the upstream LSR was built to be robust and resilient (either using the > > approach above, or some other approach). > > > > -- > > Eric Gray > > > > You wrote: > > > > > Before a label can be mapped to an FEC that has already been mapped, the LSR > > > must release the old label (prompted perhaps by a withdrawal message). Thus, LDP > > > calls for a break-before-make on LSP updates. It would seem a straightforward > > > matter for the protocol to include a withdraw-and-map message that performs this > > > sequence atomically, and so preserves a make-before-break condition. > > > > > > Is there some reason for not providing for this kind of functionality? > > > > > > Thanks for any comments. > > > > > > CLK > > > > > > PS: The careful reader will realize that I have mentioned this issue before in > > > the thread [Re: Receive Label Receive !!], but have not seen any reply. This is > > > an attempt to focus the question and broaden the pool of possible respondents. From owner-mpls@UU.NET Tue Jun 5 05:21:12 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13635 for ; Tue, 5 Jun 2001 05:21:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksbt03405; Tue, 5 Jun 2001 09:21:16 GMT Received: by mail-control.mail.uu.net id QQksbt25839 for mpls-outgoing; Tue, 5 Jun 2001 09:20:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksbt25824 for ; Tue, 5 Jun 2001 09:20:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQksbt14644 for ; Tue, 5 Jun 2001 09:20:15 GMT Received: from localhost.localdomain by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksbt01870 for ; Tue, 5 Jun 2001 09:20:11 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f559Nwq07077; Tue, 5 Jun 2001 14:54:01 +0530 Date: Tue, 5 Jun 2001 14:53:58 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@localhost.localdomain Reply-To: nagendras@netbrahma.com To: Ron Bonica cc: David Charlap , mpls@UU.NET Subject: RE: IP Fragmentation before entering LSP In-Reply-To: Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi! Can anyone tell me what is this concern about fragment re-ordering ?? IP fragmentation/reassembly is immune to fragment re-ordering, then why is this concern in the last few mails in this thread. I can understand the other concerns shown in this thread. regards tomar On Mon, 4 Jun 2001, Ron Bonica wrote: > Dave, > > As you have observed, options 1 and 3 may not be compatible with line rate > forwarding in the network core. Option 2 may cause fragment re-ordering. > > A fourth option is to prevent all fragments from traveling on an LSP. If > possible, forward all fragments using standard IP forwarding mechanisms. If > this is not possible, discard the datagram. > > Ron > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David > > Charlap > > Sent: Monday, June 04, 2001 12:44 PM > > To: mpls@UU.NET > > Subject: Re: IP Fragmentation before entering LSP > > > > > > Vishal Mishra wrote: > > > > > > How are fragmented IP Packets identified by the Ingress LER > > > if the basis of classification involves part of the IP Payload, > > > such as the Transport Layer address (say UDP Port) ? > > > > > > Does this mean only the first fragment of all such IP Packets > > > travel through the Traffic Engineered LSP, and the rest of the IP > > > fragments (being unclassified) follow the best effort (Non-TEed) > > > Path ? > > > > > > This would lead to a whole lot of problems (including out of > > > order packets). > > > > If the ingress LER is going to classify on L4+ information, then that > > information must obviously be present. There are only three possible > > choices I can see here: > > > > 1: Have the ingress LER reassemble the fragments before injecting > > into the LSP (possibly re-fragmenting them after reassembly). > > The upside is that it eliminates this problem altogether. The > > downside is that it may be impossible to do this at line-rate, > > and the router will have to deal the the possibility that some of > > the fragments may never arrive (perhaps they got routed through > > some other router, or perhaps they were lost.) > > > > 2: Have the ingress LER forward the first fragment (the one with the > > L4 header) according to its policy, and ignore the L4 information > > for other packets. The upside is that you don't have to worry > > about late/missing fragments. The downside is that the first > > fragment may take a different route through the network from the > > other fragments, leading to out of order delivery. > > > > 3: Have the ingress LER use stateful packet inspection. When the > > first fragment arrives, it should record enough information to be > > able to recognize the remaining fragments and send them into the > > same LSP. The upside is that it solves the problem and you don't > > need to buffer the entire packet. The downside is that the first > > fragment may not arrive first, and that you need to deal with the > > possibility that one or more fragments may never arrive. > > > > The only way to avoid the problem altogether is to restrict your packet > > classification to what is available in the IP header. But this may not > > be acceptible to all customers. > > > > -- David > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Tue Jun 5 05:32:11 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13724 for ; Tue, 5 Jun 2001 05:32:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksbu18370; Tue, 5 Jun 2001 09:31:58 GMT Received: by mail-control.mail.uu.net id QQksbu26964 for mpls-outgoing; Tue, 5 Jun 2001 09:31:23 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksbu26893 for ; Tue, 5 Jun 2001 09:31:04 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 QQksbu16558 for ; Tue, 5 Jun 2001 09:30:22 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksbu15692 for ; Tue, 5 Jun 2001 09:30:20 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f559V7d16659; Tue, 5 Jun 2001 15:01:07 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A62.0032CA8A ; Tue, 5 Jun 2001 14:44:46 +0530 X-Lotus-FromDomain: HSS To: nagendras@netbrahma.com cc: Ron Bonica , David Charlap , mpls@UU.NET Message-ID: <65256A62.0032C934.00@sandesh.hss.hns.com> Date: Tue, 5 Jun 2001 14:44:42 +0530 Subject: RE: IP Fragmentation before entering LSP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi nagendra! The concern regarding the fragmentation is raised in case the the QoS classification of a packet is based on the L4+ information i.e. like what type of application does the packet belong to (SAP, HTTP etc. for example). In this case the fragmented packets will not have enough information to be classified and hence the discussion above. regards sumit Nagendra Singh Tomar on 06/05/2001 02:53:58 PM Please respond to nagendras@netbrahma.com To: Ron Bonica cc: David Charlap , mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: RE: IP Fragmentation before entering LSP Hi! Can anyone tell me what is this concern about fragment re-ordering ?? IP fragmentation/reassembly is immune to fragment re-ordering, then why is this concern in the last few mails in this thread. I can understand the other concerns shown in this thread. regards tomar On Mon, 4 Jun 2001, Ron Bonica wrote: > Dave, > > As you have observed, options 1 and 3 may not be compatible with line rate > forwarding in the network core. Option 2 may cause fragment re-ordering. > > A fourth option is to prevent all fragments from traveling on an LSP. If > possible, forward all fragments using standard IP forwarding mechanisms. If > this is not possible, discard the datagram. > > Ron > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David > > Charlap > > Sent: Monday, June 04, 2001 12:44 PM > > To: mpls@UU.NET > > Subject: Re: IP Fragmentation before entering LSP > > > > > > Vishal Mishra wrote: > > > > > > How are fragmented IP Packets identified by the Ingress LER > > > if the basis of classification involves part of the IP Payload, > > > such as the Transport Layer address (say UDP Port) ? > > > > > > Does this mean only the first fragment of all such IP Packets > > > travel through the Traffic Engineered LSP, and the rest of the IP > > > fragments (being unclassified) follow the best effort (Non-TEed) > > > Path ? > > > > > > This would lead to a whole lot of problems (including out of > > > order packets). > > > > If the ingress LER is going to classify on L4+ information, then that > > information must obviously be present. There are only three possible > > choices I can see here: > > > > 1: Have the ingress LER reassemble the fragments before injecting > > into the LSP (possibly re-fragmenting them after reassembly). > > The upside is that it eliminates this problem altogether. The > > downside is that it may be impossible to do this at line-rate, > > and the router will have to deal the the possibility that some of > > the fragments may never arrive (perhaps they got routed through > > some other router, or perhaps they were lost.) > > > > 2: Have the ingress LER forward the first fragment (the one with the > > L4 header) according to its policy, and ignore the L4 information > > for other packets. The upside is that you don't have to worry > > about late/missing fragments. The downside is that the first > > fragment may take a different route through the network from the > > other fragments, leading to out of order delivery. > > > > 3: Have the ingress LER use stateful packet inspection. When the > > first fragment arrives, it should record enough information to be > > able to recognize the remaining fragments and send them into the > > same LSP. The upside is that it solves the problem and you don't > > need to buffer the entire packet. The downside is that the first > > fragment may not arrive first, and that you need to deal with the > > possibility that one or more fragments may never arrive. > > > > The only way to avoid the problem altogether is to restrict your packet > > classification to what is available in the IP header. But this may not > > be acceptible to all customers. > > > > -- David > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Tue Jun 5 07:08:08 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14875 for ; Tue, 5 Jun 2001 07:08:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksca28061; Tue, 5 Jun 2001 11:07:35 GMT Received: by mail-control.mail.uu.net id QQksca11226 for mpls-outgoing; Tue, 5 Jun 2001 11:07:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksca10547 for ; Tue, 5 Jun 2001 11:06:47 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 QQksca21765 for ; Tue, 5 Jun 2001 11:05:38 GMT Received: from localhost.localdomain by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksca24410 for ; Tue, 5 Jun 2001 11:05:35 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1]) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f55B9Dq07146; Tue, 5 Jun 2001 16:39:14 +0530 Date: Tue, 5 Jun 2001 16:39:13 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@localhost.localdomain Reply-To: nagendras@netbrahma.com To: suchauhan@hss.hns.com cc: nagendras@netbrahma.com, Ron Bonica , David Charlap , mpls@UU.NET Subject: RE: IP Fragmentation before entering LSP In-Reply-To: <65256A62.0032C934.00@sandesh.hss.hns.com> Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Sumit! Thanx for the reply, but my question was not "Why is fragmentation a concern " but Why is fragment re-ordering a concern" .. cheers tomar On Tue, 5 Jun 2001 suchauhan@hss.hns.com wrote: > > > hi nagendra! > The concern regarding the fragmentation is raised in case the the QoS > classification of a packet is based on the L4+ information i.e. like what type > of application does the packet belong to (SAP, HTTP etc. for example). In this > case the fragmented packets will not have enough information to be classified > and hence the discussion above. > > regards > sumit > > > > > Nagendra Singh Tomar on 06/05/2001 02:53:58 PM > > Please respond to nagendras@netbrahma.com > > To: Ron Bonica > cc: David Charlap , mpls@UU.NET (bcc: Sumit > Chauhan/HSS) > > Subject: RE: IP Fragmentation before entering LSP > > > > > Hi! > Can anyone tell me what is this concern about fragment > re-ordering ?? IP fragmentation/reassembly is immune to fragment > re-ordering, then why is this concern in the last few mails in this > thread. I can understand the other concerns shown in this thread. > > regards > tomar > > On Mon, 4 Jun 2001, Ron Bonica wrote: > > > Dave, > > > > As you have observed, options 1 and 3 may not be compatible with line rate > > forwarding in the network core. Option 2 may cause fragment re-ordering. > > > > A fourth option is to prevent all fragments from traveling on an LSP. If > > possible, forward all fragments using standard IP forwarding mechanisms. If > > this is not possible, discard the datagram. > > > > Ron > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David > > > Charlap > > > Sent: Monday, June 04, 2001 12:44 PM > > > To: mpls@UU.NET > > > Subject: Re: IP Fragmentation before entering LSP > > > > > > > > > Vishal Mishra wrote: > > > > > > > > How are fragmented IP Packets identified by the Ingress LER > > > > if the basis of classification involves part of the IP Payload, > > > > such as the Transport Layer address (say UDP Port) ? > > > > > > > > Does this mean only the first fragment of all such IP Packets > > > > travel through the Traffic Engineered LSP, and the rest of the IP > > > > fragments (being unclassified) follow the best effort (Non-TEed) > > > > Path ? > > > > > > > > This would lead to a whole lot of problems (including out of > > > > order packets). > > > > > > If the ingress LER is going to classify on L4+ information, then that > > > information must obviously be present. There are only three possible > > > choices I can see here: > > > > > > 1: Have the ingress LER reassemble the fragments before injecting > > > into the LSP (possibly re-fragmenting them after reassembly). > > > The upside is that it eliminates this problem altogether. The > > > downside is that it may be impossible to do this at line-rate, > > > and the router will have to deal the the possibility that some of > > > the fragments may never arrive (perhaps they got routed through > > > some other router, or perhaps they were lost.) > > > > > > 2: Have the ingress LER forward the first fragment (the one with the > > > L4 header) according to its policy, and ignore the L4 information > > > for other packets. The upside is that you don't have to worry > > > about late/missing fragments. The downside is that the first > > > fragment may take a different route through the network from the > > > other fragments, leading to out of order delivery. > > > > > > 3: Have the ingress LER use stateful packet inspection. When the > > > first fragment arrives, it should record enough information to be > > > able to recognize the remaining fragments and send them into the > > > same LSP. The upside is that it solves the problem and you don't > > > need to buffer the entire packet. The downside is that the first > > > fragment may not arrive first, and that you need to deal with the > > > possibility that one or more fragments may never arrive. > > > > > > The only way to avoid the problem altogether is to restrict your packet > > > classification to what is available in the IP header. But this may not > > > be acceptible to all customers. > > > > > > -- David > > > > -- > > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ > > > > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Tue Jun 5 08:24:19 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17312 for ; Tue, 5 Jun 2001 08:24:19 -0400 (EDT) From: owner-mpls@UU.NET Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkscf16360; Tue, 5 Jun 2001 12:23:55 GMT Received: by mail-control.mail.uu.net id QQkscf13794 for mpls-outgoing; Tue, 5 Jun 2001 12:23:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkscf13782 for ; Tue, 5 Jun 2001 12:23: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 QQkscf04094 for ; Tue, 5 Jun 2001 12:22:29 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkscf14366 for ; Tue, 5 Jun 2001 12:22:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f55CMVU20590 for ; Tue, 5 Jun 2001 05:22:31 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA17497 for mpls@uu.net; Tue, 5 Jun 2001 08:22:27 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrzu19047 for ; Mon, 4 Jun 2001 20:42:11 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 QQkrzu00096 for ; Mon, 4 Jun 2001 20:41:57 GMT Received: from e1.ny.us.ibm.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [32.97.182.101]) id QQkrzu08758 for ; Mon, 4 Jun 2001 20:41:56 GMT Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA446026 for ; Mon, 4 Jun 2001 16:40:14 -0400 Received: from d01ml065.pok.ibm.com (d01ml065.pok.ibm.com [9.117.250.65]) by northrelay02.pok.ibm.com (8.11.1/NCO v4.96) with ESMTP id f54KaJ4190386 for ; Mon, 4 Jun 2001 16:36:20 -0400 Received: from westrelay03.boulder.ibm.com ([9.99.140.24]) by d01hub03.pok.ibm.com (Lotus Domino Release 5.07a) with ESMTP id 2001060416095991:229895 ; Mon, 4 Jun 2001 16:09:59 -0400 Received: from e33.esmtp.ibm.com (e33.esmtp.ibm.com [9.14.4.131]) by westrelay03.boulder.ibm.com (8.11.1/NCO v4.96.1.0) with ESMTP id f54KA1m44032 for ; Mon, 4 Jun 2001 14:10:01 -0600 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by e33.esmtp.ibm.com (8.9.3/8.9.3) with ESMTP id PAA07802 for ; Mon, 4 Jun 2001 15:04:28 -0500 Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkrzs14500; Mon, 4 Jun 2001 20:09:55 GMT Received: by mail-control.mail.uu.net id QQkrzs08577 for mpls-outgoing; Mon, 4 Jun 2001 20:08:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkrzs08106 for ; Mon, 4 Jun 2001 20:08: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 QQkrzs15439 for ; Mon, 4 Jun 2001 20:05:21 GMT Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkrzs19244 for ; Mon, 4 Jun 2001 20:05:21 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA27785 for ; Mon, 4 Jun 2001 15:59:49 -0400 (EDT) Subject: rsvp-te opaque object X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: MIME-Version: 1.0 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 06/04/2001 03:59:49 PM, Itemize by SMTP Server on D01HUB03/01/H/IBM(Release 5.07a |May 14, 2001) at 06/04/2001 04:10:00 PM, MIME-CD by Router on D01HUB03/01/H/IBM(Release 5.07a |May 14, 2001) at 06/04/2001 04:10:00 PM, MIME-CD complete at 06/04/2001 04:10:00 PM, Serialize by Router on D01ML065/01/M/IBM(Release 5.0.7 SPR #MIAS4UTJ8H &S/390 SPR #JHEG4V8UT5|April 5, 2001) at 06/04/2001 04:41:54 PM To: mpls@UU.NET Date: Mon, 4 Jun 2001 16:41:50 -0400 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Andria, Thanks for your reply. I understand that there may have an object with new c-type or class which may be defined for the future. Does it mean an extra field in any rsvp-te defined messages in spec? For example, Path message has ::= [ ] [ ] [ ] [ ... ] ??? ******* add extra Opaque object *******???? ::= [ ] [ ] Thanks in advance. Julia >Hi, >Is it possible for RSVP message with proprietary objects that are not defined in the spec like Opaque object? >L do not think so. Can anyone tell me whether I am right. >Thanks in advance. >Julia From owner-mpls@UU.NET Tue Jun 5 08:26:14 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17395 for ; Tue, 5 Jun 2001 08:26:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkscf27476; Tue, 5 Jun 2001 12:25:49 GMT Received: by mail-control.mail.uu.net id QQkscf13887 for mpls-outgoing; Tue, 5 Jun 2001 12:25:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkscf13870 for ; Tue, 5 Jun 2001 12:24:58 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 QQkscf17083 for ; Tue, 5 Jun 2001 12:22:44 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkscf14690 for ; Tue, 5 Jun 2001 12:22:44 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f55CMkU20675 for ; Tue, 5 Jun 2001 05:22:46 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA17501 for mpls@uu.net; Tue, 5 Jun 2001 08:22:42 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkrzy14407 for ; Mon, 4 Jun 2001 21:34: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 QQkrzy18965 for ; Mon, 4 Jun 2001 21:34:34 GMT From: ewliu@263.net Received: from mta1.263.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.44.43]) id QQkrzy01590 for ; Mon, 4 Jun 2001 21:34:32 GMT Received: by mta1.263.net (Postfix, from userid 60001) id 13C313B8E1; Tue, 5 Jun 2001 05:26:17 +0800 (CST) MIME-Version: 1.0 Message-Id: <3B1BFCF9.06417@mta1> Date: Tue, 5 Jun 2001 05:26:17 +0800 (CST) To: mpls-ops@mplsrc.com Cc: mpls@UU.NET Subject: Any disadvantage about MPLS? X-Priority: 1 X-Originating-IP: [211.69.198.47] Sender: owner-mpls@UU.NET Precedence: bulk Content-Type: text/plain; charset=unknown-8bit X-MIME-Autoconverted: from 8bit to base64 by cmr0.ash.ops.us.uu.net id QQkscf27476 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA17395 It seems that MPLS is good for almost everything,from QoS to traffic engineering and VPN. I want to get some information about its disadvantages,any information will be appreciated. _____________________________________________ ÏÄÈÕÊÝÉí¡¢°çö¦±¦µä http://shopping.263.net/hotsale/summer/ [×ã²»³ö»§ ÇáËÉÉÏÍø] ÉÏÍøרÓúţº95963£¬Óû§Ãû/ÃÜÂ룺263 From owner-mpls@UU.NET Tue Jun 5 08:36:19 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17704 for ; Tue, 5 Jun 2001 08:36:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkscg09372; Tue, 5 Jun 2001 12:35:58 GMT Received: by mail-control.mail.uu.net id QQkscg15223 for mpls-outgoing; Tue, 5 Jun 2001 12:35:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkscg15218 for ; Tue, 5 Jun 2001 12:35:22 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 QQkscg19455 for ; Tue, 5 Jun 2001 12:35:04 GMT From: mgoel@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkscg18765 for ; Tue, 5 Jun 2001 12:34:57 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f55CZsX24820; Tue, 5 Jun 2001 18:05:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A62.0043B523 ; Tue, 5 Jun 2001 17:49:32 +0530 X-Lotus-FromDomain: HSS To: ewliu@263.net cc: mpls-ops@mplsrc.com, mpls@UU.NET Message-ID: <65256A62.0043AD00.00@sandesh.hss.hns.com> Date: Tue, 5 Jun 2001 18:03:26 +0530 Subject: Re: Any disadvantage about MPLS? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi ewliu! one disadvantage of mpls is that a four byte shim header is inserted to every network layer packet before being forwarded to data link layer, which effectively increases the payload for data link layer. Regards Mohit ewliu@263.net on 06/05/2001 02:56:17 AM To: mpls-ops@mplsrc.com cc: mpls@UU.NET (bcc: Mohit Goel/HSS) Subject: Any disadvantage about MPLS? It seems that MPLS is good for almost everything,from QoS to traffic engineering and VPN. I want to get some information about its disadvantages,any information will be appreciated. _____________________________________________ ?????????????????? http://shopping.263.net/hotsale/summer/ [???????? ????????] ????????????95963????????/??????263 From owner-mpls@UU.NET Tue Jun 5 10:20:59 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21971 for ; Tue, 5 Jun 2001 10:20:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkscn25161; Tue, 5 Jun 2001 14:19:28 GMT Received: by mail-control.mail.uu.net id QQkscn04498 for mpls-outgoing; Tue, 5 Jun 2001 14:18:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkscn04484 for ; Tue, 5 Jun 2001 14:18:50 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 QQkscn01259 for ; Tue, 5 Jun 2001 14:18:26 GMT Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQkscn18518 for ; Tue, 5 Jun 2001 14:18:22 GMT Received: from akshat (rahul [165.133.13.21]) by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id TAA10789; Tue, 5 Jun 2001 19:39:01 -0600 (GMT) Message-ID: <005a01c0edca$4a0b38c0$150d85a5@dti.daewoo.co.kr> From: "Akshat Kapoor" To: , Cc: , References: <65256A62.0043AD00.00@sandesh.hss.hns.com> Subject: Re: Any disadvantage about MPLS? Date: Tue, 5 Jun 2001 19:47:39 +0530 Organization: Mercury Corp. (Formerly Daewoo Telecom Ltd) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mohit, That case would only hold true - if the native Layer 2 header doesn't have a field for label (like ATM has VPI-VCI fields, FR has DLCI), or - the label stack (if present) can't be adjusted in the layer 2 header. Akshat ----- Original Message ----- From: To: Cc: ; Sent: Tuesday, June 05, 2001 6:03 PM Subject: Re: Any disadvantage about MPLS? > > > Hi ewliu! > > one disadvantage of mpls is that a four byte shim header is inserted to every > network layer packet before being forwarded to data link layer, which > effectively increases the payload for data link layer. > > Regards > Mohit > > > > > ewliu@263.net on 06/05/2001 02:56:17 AM > > To: mpls-ops@mplsrc.com > cc: mpls@UU.NET (bcc: Mohit Goel/HSS) > > Subject: Any disadvantage about MPLS? > > > > > It seems that MPLS is good for almost everything,from QoS to traffic engineering > and VPN. > > I want to get some information about its disadvantages,any information will be > appreciated. > > _____________________________________________ > ?????????????????? http://shopping.263.net/hotsale/summer/ > [???????? ????????] ????????????95963????????/??????263 > > > > > > From owner-mpls@UU.NET Tue Jun 5 10:45:18 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22589 for ; Tue, 5 Jun 2001 10:45:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksco23408; Tue, 5 Jun 2001 14:43:45 GMT Received: by mail-control.mail.uu.net id QQksco06381 for mpls-outgoing; Tue, 5 Jun 2001 14:43:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksco06373 for ; Tue, 5 Jun 2001 14:43: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 QQksco14646 for ; Tue, 5 Jun 2001 14:42:23 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQksco04049 for ; Tue, 5 Jun 2001 14:42:23 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 6DDD394009; Tue, 5 Jun 2001 10:42:17 -0400 (EDT) Message-ID: <3B1CEFC9.2339BEA6@sandburst.com> Date: Tue, 05 Jun 2001 10:42:17 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: nagendras@netbrahma.com Cc: suchauhan@hss.hns.com, Ron Bonica , David Charlap , mpls@UU.NET Subject: Re: IP Fragmentation before entering LSP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nagendra, Vishal's original question had to do with a general concern that already fragmented UDP packets might arrive at a point where a TE LSP originates. If the basis for ingress to the TE LSP is a specific L4 attribute, it is possible that the first IP fragment will qualify for ingress and the rest will not. While out of order delivery is a concern in this situation, perhaps a more important concern is that the 'service' associated with the TE LSP was meant to apply to the entire UDP packet. Since all but the first fragment do not receive this 'service' (whatever it is), the entire packet is at least as bad off as if no part of it received the 'service'. The issue with re-ordering IP fragments is that many stack implementations do this somewhat sub-optimally. Thus, if fragments are re-ordered, this could lead to further degradation of the 'service' intended for this packet. An example of a 'service' degradation might be the case where a certain class of UDP packets are intended to be filtered (possibly to prevent certain types of denial of service attack). In this case, filtering the first fragment could result in a greater 'denial of service' impact that if the filtering service did not exist. I think Dave Charlap and Ron Bonica were going in the right direction with their suggestions. It seems to me that the LSR at the ingress needs to be more aware of its limitations. If it is not able to ensure that all subsequent IP fragments will go on the same LSP, it should not admit the first one. Either it uses Dave's options 1 or 3, it forwards using IP or it drops the packet (as Ron suggested). Note that this is also consistent with Jay's initial suggestion to employ the same policy to all IP fragments. -- Eric Gray You wrote: > Hi Sumit! > Thanx for the reply, but my question was not "Why is fragmentation > a concern " but Why is fragment re-ordering a concern" .. > > cheers > tomar > > On Tue, 5 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > hi nagendra! > > The concern regarding the fragmentation is raised in case the the QoS > > classification of a packet is based on the L4+ information i.e. like what type > > of application does the packet belong to (SAP, HTTP etc. for example). In this > > case the fragmented packets will not have enough information to be classified > > and hence the discussion above. > > > > regards > > sumit > > > > > > > > > > Nagendra Singh Tomar on 06/05/2001 02:53:58 PM > > > > Please respond to nagendras@netbrahma.com > > > > To: Ron Bonica > > cc: David Charlap , mpls@UU.NET (bcc: Sumit > > Chauhan/HSS) > > > > Subject: RE: IP Fragmentation before entering LSP > > > > > > > > > > Hi! > > Can anyone tell me what is this concern about fragment > > re-ordering ?? IP fragmentation/reassembly is immune to fragment > > re-ordering, then why is this concern in the last few mails in this > > thread. I can understand the other concerns shown in this thread. > > > > regards > > tomar > > > > On Mon, 4 Jun 2001, Ron Bonica wrote: > > > > > Dave, > > > > > > As you have observed, options 1 and 3 may not be compatible with line rate > > > forwarding in the network core. Option 2 may cause fragment re-ordering. > > > > > > A fourth option is to prevent all fragments from traveling on an LSP. If > > > possible, forward all fragments using standard IP forwarding mechanisms. If > > > this is not possible, discard the datagram. > > > > > > Ron > > > > > > > -----Original Message----- > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David > > > > Charlap > > > > Sent: Monday, June 04, 2001 12:44 PM > > > > To: mpls@UU.NET > > > > Subject: Re: IP Fragmentation before entering LSP > > > > > > > > > > > > Vishal Mishra wrote: > > > > > > > > > > How are fragmented IP Packets identified by the Ingress LER > > > > > if the basis of classification involves part of the IP Payload, > > > > > such as the Transport Layer address (say UDP Port) ? > > > > > > > > > > Does this mean only the first fragment of all such IP Packets > > > > > travel through the Traffic Engineered LSP, and the rest of the IP > > > > > fragments (being unclassified) follow the best effort (Non-TEed) > > > > > Path ? > > > > > > > > > > This would lead to a whole lot of problems (including out of > > > > > order packets). > > > > > > > > If the ingress LER is going to classify on L4+ information, then that > > > > information must obviously be present. There are only three possible > > > > choices I can see here: > > > > > > > > 1: Have the ingress LER reassemble the fragments before injecting > > > > into the LSP (possibly re-fragmenting them after reassembly). > > > > The upside is that it eliminates this problem altogether. The > > > > downside is that it may be impossible to do this at line-rate, > > > > and the router will have to deal the the possibility that some of > > > > the fragments may never arrive (perhaps they got routed through > > > > some other router, or perhaps they were lost.) > > > > > > > > 2: Have the ingress LER forward the first fragment (the one with the > > > > L4 header) according to its policy, and ignore the L4 information > > > > for other packets. The upside is that you don't have to worry > > > > about late/missing fragments. The downside is that the first > > > > fragment may take a different route through the network from the > > > > other fragments, leading to out of order delivery. > > > > > > > > 3: Have the ingress LER use stateful packet inspection. When the > > > > first fragment arrives, it should record enough information to be > > > > able to recognize the remaining fragments and send them into the > > > > same LSP. The upside is that it solves the problem and you don't > > > > need to buffer the entire packet. The downside is that the first > > > > fragment may not arrive first, and that you need to deal with the > > > > possibility that one or more fragments may never arrive. > > > > > > > > The only way to avoid the problem altogether is to restrict your packet > > > > classification to what is available in the IP header. But this may not > > > > be acceptible to all customers. > > > > > > > > -- David > > > > > > > -- > > > > > > ------------------------------------------------------------------------------ > > Nagendra Singh Tomar > > > > Residence: > > 369 KHB Colony > > 5th Block Koramangala > > Bangalore 95 > > INDIA > > Phone : 5524839 > > email : nagendras@netbrahma.com > > > > > > "Sometimes quantity becomes quality" > > --Gary Kasparov, > > When he played against Deep Blue. He said this after looking at a > > computer which found a forced mate in 249 in an endgame, after calculating > > all the possible moves with only 5 pieces left on the board. > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > -- > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ From owner-mpls@UU.NET Tue Jun 5 11:11:45 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23093 for ; Tue, 5 Jun 2001 11:11:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkscq26688; Tue, 5 Jun 2001 15:10:12 GMT Received: by mail-control.mail.uu.net id QQkscq28005 for mpls-outgoing; Tue, 5 Jun 2001 15:09:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkscq27985 for ; Tue, 5 Jun 2001 15:09:24 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 QQkscq20667 for ; Tue, 5 Jun 2001 15:06:54 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkscq21997 for ; Tue, 5 Jun 2001 15:06:54 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 2415E94006; Tue, 5 Jun 2001 11:06:54 -0400 (EDT) Message-ID: <3B1CF58E.DACC9C0F@sandburst.com> Date: Tue, 05 Jun 2001 11:06:54 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Akshat Kapoor Cc: mgoel@hss.hns.com, mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Any disadvantage about MPLS? References: <65256A62.0043AD00.00@sandesh.hss.hns.com> <005a01c0edca$4a0b38c0$150d85a5@dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Akshat, Even in the case where there is a representation of the label in the L2 header, there will most often be a corresponding label stack entry in the MPLS shim header. If you read the specifications for ATM and Frame Relay, you will find that inclusion of the MPLS shim header is at least the normal case. For this reason, it is likely that nobody will use the abnormal case - i.e. - omitting the MPLS shim header when it is known that ALL packets will use exactly one MPLS label when carried on an ATM (or FR*) VC. However, the 'extra' space consumed using MPLS labels is a minor cost in using the protocol particularly in TE or VPN application (where an alternative choice might be to IP-in-IP encapsulation, for instance). Most of the costs associated with MPLS could be grouped under the general headings of additonal protocol complexity and interworking with an existing networking installed base. * While RFC 3034 implies that there is a non-default case where a label stack may be omitted, it does not describe when and how. RFC 3035 explicitly states the conditions under which it is possible to use a VC corresponding to (a portion of) an LSP, omitting the label stack. See section 9, RFC 3035 for ATM encaps and section 4 of RFC 3034 for Frame Relay... -- Eric Gray You wrote: > Hi Mohit, > That case would only hold true > - if the native Layer 2 header doesn't have a field for label (like ATM has > VPI-VCI fields, FR has DLCI), or > - the label stack (if present) can't be adjusted in the layer 2 header. > > Akshat > ----- Original Message ----- > From: > To: > Cc: ; > Sent: Tuesday, June 05, 2001 6:03 PM > Subject: Re: Any disadvantage about MPLS? > > > > > > > Hi ewliu! > > > > one disadvantage of mpls is that a four byte shim header is inserted to > every > > network layer packet before being forwarded to data link layer, which > > effectively increases the payload for data link layer. > > > > Regards > > Mohit > > > > > > > > > > ewliu@263.net on 06/05/2001 02:56:17 AM > > > > To: mpls-ops@mplsrc.com > > cc: mpls@UU.NET (bcc: Mohit Goel/HSS) > > > > Subject: Any disadvantage about MPLS? > > > > > > > > > > It seems that MPLS is good for almost everything,from QoS to traffic > engineering > > and VPN. > > > > I want to get some information about its disadvantages,any information > will be > > appreciated. > > > > _____________________________________________ > > ?????????????????? http://shopping.263.net/hotsale/summer/ > > [???????? ????????] ????????????95963????????/??????263 > > > > > > > > > > > > From owner-mpls@UU.NET Tue Jun 5 11:18:47 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23237 for ; Tue, 5 Jun 2001 11:18:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkscr29966; Tue, 5 Jun 2001 15:17:06 GMT Received: by mail-control.mail.uu.net id QQkscr29283 for mpls-outgoing; Tue, 5 Jun 2001 15:16:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkscr29226 for ; Tue, 5 Jun 2001 15:16:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkscq01438 for ; Tue, 5 Jun 2001 15:12:11 GMT Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQkscq05316 for ; Tue, 5 Jun 2001 15:12:10 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA10531; Tue, 5 Jun 2001 11:04:49 -0400 (EDT) Subject: Re: rsvp-te opaque object To: "Adrian Farrel" Cc: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Tue, 5 Jun 2001 11:04:48 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 06/05/2001 11:04:48 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Adrian, So you mean there is no need to add extra field into the PDU message for the Opaque object. But as I know, there is one switches which is implemented by this way with extra opaque(unrecognized) field inside the Path pdu message. Do you think they implement the switch with this way correctly or not? Thanks, Julia "Adrian Farrel" To: "Hong Liao" Subject: Re: rsvp-te opaque object 06/04/01 05:06 PM Julia, My point is that all undefined objects are opaque and there is no need to define a specific value to encode an opaque object. You might ask that there are some values that are reserved for implementation usage so that future objects don't clash. This would be a matter for IANA (and for all I know, it has been resolved there already). You might want to define a specific use of opaque objects (that they be delivered to a specific non-RSVP component). This is similar to what happens with Policy objects. The need for this function would drive the allocation of the value. Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ----- Original Message ----- From: "Hong Liao" To: Sent: Monday, June 04, 2001 3:59 PM Subject: rsvp-te opaque object > Andria, > > Thanks for your reply. I understand that there may have an object with new > c-type or class which may be defined for the future. Does it mean an extra > field in any rsvp-te defined messages in spec? For example, Path message > has > > ::= [ ] > > > [ ] > > [ ] > [ ... ] > > > ??? ******* add extra Opaque object *******???? > > ::= > [ ] > [ ] > > Thanks in advance. > > Julia > > > > > >Hi, > > >Is it possible for RSVP message with proprietary objects that are not > defined in the spec like Opaque object? > >L do not think so. Can anyone tell me whether I am right. > > > >Thanks in advance. > > >Julia > > From owner-mpls@UU.NET Tue Jun 5 11:55:36 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24155 for ; Tue, 5 Jun 2001 11:55:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksct27232; Tue, 5 Jun 2001 15:53:46 GMT Received: by mail-control.mail.uu.net id QQksct02618 for mpls-outgoing; Tue, 5 Jun 2001 15:53:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksct02601 for ; Tue, 5 Jun 2001 15:52: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 QQksct15635 for ; Tue, 5 Jun 2001 15:51:18 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQksct24198 for ; Tue, 5 Jun 2001 15:51:18 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f55FpKU14761 for ; Tue, 5 Jun 2001 08:51:20 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA18803 for mpls@uu.net; Tue, 5 Jun 2001 11:51:16 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkscs00918 for ; Tue, 5 Jun 2001 15:37: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 QQkscs02330 for ; Tue, 5 Jun 2001 15:36:47 GMT From: PyjuPy@netscape.net Received: from imo-d08.mx.aol.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imo-d08.mx.aol.com [205.188.157.40]) id QQkscs06268 for ; Tue, 5 Jun 2001 15:36:47 GMT Received: from PyjuPy@netscape.net by imo-d08.mx.aol.com (mail_out_v30.22.) id 1.b5.4ecbaf (16213) for ; Tue, 5 Jun 2001 11:36:40 -0400 (EDT) Received: from netscape.com (aimmail10.aim.aol.com [205.188.144.202]) by air-in01.mx.aol.com (v77_r1.37) with ESMTP; Tue, 05 Jun 2001 11:36:40 -0400 Date: Tue, 05 Jun 2001 11:36:40 -0400 To: mpls@UU.NET Subject: Restoration Mime-Version: 1.0 Message-ID: <0FAA8C62.39DD3BA4.00053931@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi all, Does any vender's routers/switchs support fast restoration if a link is down? Thanks in advance! P.J. __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From owner-mpls@UU.NET Tue Jun 5 14:03:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27495 for ; Tue, 5 Jun 2001 14:03:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksda13874; Tue, 5 Jun 2001 17:31:01 GMT Received: by mail-control.mail.uu.net id QQksda23340 for mpls-outgoing; Tue, 5 Jun 2001 17:30:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksda23332 for ; Tue, 5 Jun 2001 17:30:21 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 QQkscz23102 for ; Tue, 5 Jun 2001 17:29:05 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkscz09814 for ; Tue, 5 Jun 2001 17:29:05 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 390E594006; Tue, 5 Jun 2001 13:29:05 -0400 (EDT) Message-ID: <3B1D16E1.3A9B1724@sandburst.com> Date: Tue, 05 Jun 2001 13:29:05 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Gibson, Mark" Cc: MPLS Mailing List Subject: Re: RSVP-TE typo References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Mark, As I currently understand it, George has promised to re-insert this section with a pointer to the RFC that describes the equivalent object. When this is done, these pointers then become indirect references to this same RFC. Thus we demonstrate that pointer indirection works. :-) -- Eric Gray You wrote: > When re-reading the RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt I notice > that there are two systematic typos. Sections 2.3 and 2.6 refer to Section > 4.8 for details of handing Class-of-Service service. No such section exists, > indeed I am confused what you mean by Class-of-Service. (zero matches on the > RFC search tool http://www.rfc-editor.org/cgi-bin/rfcsearch.pl > , zero matches on the > internet-draft search tool > http://search.ietf.org/search/cgi-bin/BrokerQuery.pl.cgi > ). The only > oblique reference I can find is on pp49 of RFC 2205 where RSVP packets are > described as receiving a preferred class of service to prevent routers > dropping them. > > Could you please clarify/amend before this gets published. > > Regards > > Mark Gibson > > -- > This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited. If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents. Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated. From owner-mpls@UU.NET Tue Jun 5 15:40:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29142 for ; Tue, 5 Jun 2001 15:40:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkscy29832; Tue, 5 Jun 2001 17:10:18 GMT Received: by mail-control.mail.uu.net id QQkscy08170 for mpls-outgoing; Tue, 5 Jun 2001 17:09:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkscy07916 for ; Tue, 5 Jun 2001 17:09:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkscy15859 for ; Tue, 5 Jun 2001 17:08:22 GMT Received: from mail2.orchestream.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.orchestream.com [195.153.64.126]) id QQkscy10499 for ; Tue, 5 Jun 2001 17:08:22 GMT Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 5 Jun 2001 18:09:46 +0100 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id NAA27407 for ; Tue, 5 Jun 2001 13:09:43 +0100 Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 18:04:22 +0100 Message-ID: From: "Gibson, Mark" To: "'mpls@uu.net'" Subject: RSVP-TE typo Date: Tue, 5 Jun 2001 18:04:21 +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 When re-reading the RSVP-TE draft-ietf-mpls-rsvp-lsp-tunnel-08.txt I notice that there are two systematic typos. Sections 2.3 and 2.6 refer to Section 4.8 for details of handing Class-of-Service service. No such section exists, indeed I am confused what you mean by Class-of-Service. (zero matches on the RFC search tool http://www.rfc-editor.org/cgi-bin/rfcsearch.pl , zero matches on the internet-draft search tool http://search.ietf.org/search/cgi-bin/BrokerQuery.pl.cgi ). The only oblique reference I can find is on pp49 of RFC 2205 where RSVP packets are described as receiving a preferred class of service to prevent routers dropping them. Could you please clarify/amend before this gets published. Regards Mark Gibson -- This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited. If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents. Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated. From owner-mpls@UU.NET Tue Jun 5 16:11:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29415 for ; Tue, 5 Jun 2001 16:11:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksdk12809; Tue, 5 Jun 2001 20:09:38 GMT Received: by mail-control.mail.uu.net id QQksdk15524 for mpls-outgoing; Tue, 5 Jun 2001 20:08:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksdk15443 for ; Tue, 5 Jun 2001 20:08: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 QQksdk27904 for ; Tue, 5 Jun 2001 20:04:29 GMT Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQksdk09037 for ; Tue, 5 Jun 2001 20:04:29 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA00520; Tue, 5 Jun 2001 15:52:21 -0400 (EDT) Subject: Re: rsvp-te opaque object To: "Adrian Farrel" Cc: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Tue, 5 Jun 2001 15:52:20 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 06/05/2001 03:52:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Adrian, So you mean there is no need to add extra field into the PDU message for the Opaque object. But as I know, there is one switches which is implemented by this way with extra opaque(unrecognized) field inside the Path pdu message. Do you think they implement the switch with this way correctly or not? Thanks, Julia "Adrian Farrel" To: "Hong Liao" Subject: Re: rsvp-te opaque object 06/04/01 05:06 PM Julia, My point is that all undefined objects are opaque and there is no need to define a specific value to encode an opaque object. You might ask that there are some values that are reserved for implementation usage so that future objects don't clash. This would be a matter for IANA (and for all I know, it has been resolved there already). You might want to define a specific use of opaque objects (that they be delivered to a specific non-RSVP component). This is similar to what happens with Policy objects. The need for this function would drive the allocation of the value. Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ----- Original Message ----- From: "Hong Liao" To: Sent: Monday, June 04, 2001 3:59 PM Subject: rsvp-te opaque object > Andria, > > Thanks for your reply. I understand that there may have an object with new > c-type or class which may be defined for the future. Does it mean an extra > field in any rsvp-te defined messages in spec? For example, Path message > has > > ::= [ ] > > > [ ] > > [ ] > [ ... ] > > > ??? ******* add extra Opaque object *******???? > > ::= > [ ] > [ ] > > Thanks in advance. > > Julia > > > > > >Hi, > > >Is it possible for RSVP message with proprietary objects that are not > defined in the spec like Opaque object? > >L do not think so. Can anyone tell me whether I am right. > > > >Thanks in advance. > > >Julia > > From owner-mpls@UU.NET Tue Jun 5 18:16:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00679 for ; Tue, 5 Jun 2001 18:16:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksds22512; Tue, 5 Jun 2001 22:14:24 GMT Received: by mail-control.mail.uu.net id QQksds07968 for mpls-outgoing; Tue, 5 Jun 2001 22:13:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksds07956 for ; Tue, 5 Jun 2001 22:13:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQksds10586 for ; Tue, 5 Jun 2001 22:12:56 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 QQksds21109 for ; Tue, 5 Jun 2001 22:12:56 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 SAA02952; Tue, 5 Jun 2001 18:12:53 -0400 (EDT) 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 SAA02648; Tue, 5 Jun 2001 18:12:54 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Jun 2001 18:12:54 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5530964C@VIE-MSGUSR-01> From: "Naidu, Venkata" To: "'mgoel@hss.hns.com'" , ewliu@263.net Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: Any disadvantage about MPLS? Date: Tue, 5 Jun 2001 18:12:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Another minor but worth mentioning disadvantage(s) are: (1) There is no protection for shim header: Both L2 and L3 have their own checksum/CRC for respective headers/PDUs. But won't cover shim header specifically. For example some L2s like ATM has checksum only for header (first label) not for their payload. (shim header + IP header + data are in ATM payloads) It is difficult to rely on L1/L2 CRCs, even a single bit corruption in shim header may lead the LSP to different destinations not destined to!?! (2) When many "bits" are available in hand (IPv4 IPv6 headers) to control the flow we can provide many features (ranging from diff-serv, TOS, encryption, precedence, fragmentation, control & many more options etc.) but expecting the same functionality with small number of bits in hand (shim header) is always difficult and disadvantages follow. (3) Remember there are always some pros-and-cons for hope-by-hope forwarding and switching (in theory) (mean to say connection-less vs connection-oriented also) We have to weigh them both for our needs, in what expense? I am not going against MPLS, just to mention a few. If we start mentioning advantages, we can write a book challenging Yakov ;-) --Venkata Naidu -> Hi ewliu! -> -> one disadvantage of mpls is that a four byte shim header is -> inserted to every -> network layer packet before being forwarded to data link layer, which -> effectively increases the payload for data link layer. -> -> Regards -> Mohit -> -> -> -> -> ewliu@263.net on 06/05/2001 02:56:17 AM -> -> To: mpls-ops@mplsrc.com -> cc: mpls@UU.NET (bcc: Mohit Goel/HSS) -> -> Subject: Any disadvantage about MPLS? -> -> -> -> -> It seems that MPLS is good for almost everything,from QoS to -> traffic engineering -> and VPN. -> -> I want to get some information about its disadvantages,any -> information will be -> appreciated. -> -> _____________________________________________ -> ?????????????????? http://shopping.263.net/hotsale/summer/ -> [???????? ????????] ????????????95963????????/??????263 -> -> -> -> -> From owner-mpls@UU.NET Tue Jun 5 18:32:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00896 for ; Tue, 5 Jun 2001 18:32:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksdu08907; Tue, 5 Jun 2001 22:30:17 GMT Received: by mail-control.mail.uu.net id QQksdt09510 for mpls-outgoing; Tue, 5 Jun 2001 22:29:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksdt09487 for ; Tue, 5 Jun 2001 22:29:28 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 QQksdt28986 for ; Tue, 5 Jun 2001 22:27:53 GMT Received: from morpheus.lanterncom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: morpheus.lanterncom.com [64.161.157.68]) id QQksdt15277 for ; Tue, 5 Jun 2001 22:27:53 GMT Received: by morpheus.lanterncom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 15:21:58 -0700 Message-ID: <87DB6812511ED511AFD0000347251A2D1D6CC0@morpheus.lanterncom.com> From: Sunil Ramachandran To: "'Akshat Kapoor'" , mgoel@hss.hns.com, ewliu@263.net Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: Any disadvantage about MPLS? Date: Tue, 5 Jun 2001 15:21:58 -0700 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 Let us say, an MPLS shim is required for Ethernet [Layer2]. What would be the ideal mechanism to negotiate MTU entirely within Layer2? - Sunil. -----Original Message----- From: Akshat Kapoor [mailto:akshat@mercurykr.com] Sent: Tuesday, June 05, 2001 7:18 AM To: mgoel@hss.hns.com; ewliu@263.net Cc: mpls-ops@mplsrc.com; mpls@UU.NET Subject: Re: Any disadvantage about MPLS? Hi Mohit, That case would only hold true - if the native Layer 2 header doesn't have a field for label (like ATM has VPI-VCI fields, FR has DLCI), or - the label stack (if present) can't be adjusted in the layer 2 header. Akshat ----- Original Message ----- From: To: Cc: ; Sent: Tuesday, June 05, 2001 6:03 PM Subject: Re: Any disadvantage about MPLS? > > > Hi ewliu! > > one disadvantage of mpls is that a four byte shim header is inserted to every > network layer packet before being forwarded to data link layer, which > effectively increases the payload for data link layer. > > Regards > Mohit > > > > > ewliu@263.net on 06/05/2001 02:56:17 AM > > To: mpls-ops@mplsrc.com > cc: mpls@UU.NET (bcc: Mohit Goel/HSS) > > Subject: Any disadvantage about MPLS? > > > > > It seems that MPLS is good for almost everything,from QoS to traffic engineering > and VPN. > > I want to get some information about its disadvantages,any information will be > appreciated. > > _____________________________________________ > ?????????????????? http://shopping.263.net/hotsale/summer/ > [???????? ????????] ????????????95963????????/??????263 > > > > > > From owner-mpls@UU.NET Tue Jun 5 19:03:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01200 for ; Tue, 5 Jun 2001 19:03:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksdw16540; Tue, 5 Jun 2001 23:01:48 GMT Received: by mail-control.mail.uu.net id QQksdw16397 for mpls-outgoing; Tue, 5 Jun 2001 23:01:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksdw16015 for ; Tue, 5 Jun 2001 23:01:04 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 QQksdv16833 for ; Tue, 5 Jun 2001 22:58:26 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQksdv10597 for ; Tue, 5 Jun 2001 22:58:26 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id BD0A794006; Tue, 5 Jun 2001 18:58:25 -0400 (EDT) Message-ID: <3B1D6411.5435E607@sandburst.com> Date: Tue, 05 Jun 2001 18:58:25 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Naidu, Venkata" Cc: "'mgoel@hss.hns.com'" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Any disadvantage about MPLS? References: <39469E08BD83D411A3D900204840EC5530964C@VIE-MSGUSR-01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Venkata, Sigh. Why do we let ourselves be dragged down this path? You wrote: > Another minor but worth mentioning disadvantage(s) are: > > (1) There is no protection for shim header: > Both L2 and L3 have their own checksum/CRC > for respective headers/PDUs. But won't cover shim > header specifically. For example some L2s like ATM > has checksum only for header (first label) not for > their payload. > (shim header + IP header + data are in ATM payloads) > > It is difficult to rely on L1/L2 CRCs, > even a single bit corruption in shim header > may lead the LSP to different destinations > not destined to!?! Most people tend to feel that L1/L2 error detection is sufficient. > > > (2) When many "bits" are available in hand (IPv4 IPv6 headers) > to control the flow we can provide many features > (ranging from diff-serv, TOS, encryption, precedence, > fragmentation, control & many more options etc.) > but expecting the same functionality with small number > of bits in hand (shim header) is always difficult > and disadvantages follow. We cannot do much with 5 or more words worth of binary options that we cannot also do with the one-word label stack entry. Do we truly need to differentiate more than 8 million (or so) flows in every network box, and at every network interface? > > > (3) Remember there are always some pros-and-cons for > hope-by-hope forwarding and switching (in theory) > (mean to say connection-less vs connection-oriented also) > We have to weigh them both for our needs, in what expense? I like your (Freudian?) description of routing as hope-by-hope forwarding and switching. Cute. :-) > > > I am not going against MPLS, just to mention a few. > If we start mentioning advantages, we can write a book > challenging Yakov ;-) That might be a good idea. > > > --Venkata Naidu > > -> Hi ewliu! > -> > -> one disadvantage of mpls is that a four byte shim header is > -> inserted to every > -> network layer packet before being forwarded to data link layer, which > -> effectively increases the payload for data link layer. > -> > -> Regards > -> Mohit > -> > -> > -> > -> > -> ewliu@263.net on 06/05/2001 02:56:17 AM > -> > -> To: mpls-ops@mplsrc.com > -> cc: mpls@UU.NET (bcc: Mohit Goel/HSS) > -> > -> Subject: Any disadvantage about MPLS? > -> > -> > -> > -> > -> It seems that MPLS is good for almost everything,from QoS to > -> traffic engineering > -> and VPN. > -> > -> I want to get some information about its disadvantages,any > -> information will be > -> appreciated. > -> > -> _____________________________________________ > -> ?????????????????? http://shopping.263.net/hotsale/summer/ > -> [???????? ????????] ????????????95963????????/??????263 > -> > -> > -> > -> > -> From owner-mpls@UU.NET Tue Jun 5 19:30:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01503 for ; Tue, 5 Jun 2001 19:30:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksdx22395; Tue, 5 Jun 2001 23:28:22 GMT Received: by mail-control.mail.uu.net id QQksdx05644 for mpls-outgoing; Tue, 5 Jun 2001 23:27:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksdx05630 for ; Tue, 5 Jun 2001 23:27:33 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 QQksdx29828 for ; Tue, 5 Jun 2001 23:27:20 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f177.law11.hotmail.com [64.4.17.177]) id QQksdx21084 for ; Tue, 5 Jun 2001 23:27:19 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Jun 2001 16:27:19 -0700 Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 05 Jun 2001 23:27:19 GMT X-Originating-IP: [65.112.106.16] From: "Irfan Lateef" To: eric.gray@sandburst.com, Venkata.Naidu@Marconi.com Cc: mgoel@hss.hns.com, mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Any disadvantage about MPLS? Date: Tue, 05 Jun 2001 19:27:19 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jun 2001 23:27:19.0500 (UTC) FILETIME=[108230C0:01C0EE17] Sender: owner-mpls@UU.NET Precedence: bulk Eric, > >We cannot do much with 5 or more words worth of binary options >that we cannot also do with the one-word label stack entry. Do >we truly need to differentiate more than 8 million (or so) flows in >every network box, and at every network interface? > With the current experience with MPLS, and the need to design high speed MPLS routers, I would like take your suggestion to the extreme of saying that we should have only 16-bit labels. This would allow faster label lookups. Hence it brings me to saying that 32-bit MPLS label itself is actually a disadvantage in taking the designs to the next levels. Irfan Lateef >From: Eric Gray >To: "Naidu, Venkata" >CC: "'mgoel@hss.hns.com'" , mpls-ops@mplsrc.com, >mpls@UU.NET >Subject: Re: Any disadvantage about MPLS? >Date: Tue, 05 Jun 2001 18:58:25 -0400 > >Venkata, > > Sigh. Why do we let ourselves be dragged down this path? > >You wrote: > > > Another minor but worth mentioning disadvantage(s) are: > > > > (1) There is no protection for shim header: > > Both L2 and L3 have their own checksum/CRC > > for respective headers/PDUs. But won't cover shim > > header specifically. For example some L2s like ATM > > has checksum only for header (first label) not for > > their payload. > > (shim header + IP header + data are in ATM payloads) > > > > It is difficult to rely on L1/L2 CRCs, > > even a single bit corruption in shim header > > may lead the LSP to different destinations > > not destined to!?! > >Most people tend to feel that L1/L2 error detection is sufficient. > > > > > > > (2) When many "bits" are available in hand (IPv4 IPv6 headers) > > to control the flow we can provide many features > > (ranging from diff-serv, TOS, encryption, precedence, > > fragmentation, control & many more options etc.) > > but expecting the same functionality with small number > > of bits in hand (shim header) is always difficult > > and disadvantages follow. > >We cannot do much with 5 or more words worth of binary options >that we cannot also do with the one-word label stack entry. Do >we truly need to differentiate more than 8 million (or so) flows in >every network box, and at every network interface? > > > > > > > (3) Remember there are always some pros-and-cons for > > hope-by-hope forwarding and switching (in theory) > > (mean to say connection-less vs connection-oriented also) > > We have to weigh them both for our needs, in what expense? > >I like your (Freudian?) description of routing as hope-by-hope >forwarding and switching. Cute. :-) > > > > > > > I am not going against MPLS, just to mention a few. > > If we start mentioning advantages, we can write a book > > challenging Yakov ;-) > >That might be a good idea. > > > > > > > --Venkata Naidu > > > > -> Hi ewliu! > > -> > > -> one disadvantage of mpls is that a four byte shim header is > > -> inserted to every > > -> network layer packet before being forwarded to data link layer, which > > -> effectively increases the payload for data link layer. > > -> > > -> Regards > > -> Mohit > > -> > > -> > > -> > > -> > > -> ewliu@263.net on 06/05/2001 02:56:17 AM > > -> > > -> To: mpls-ops@mplsrc.com > > -> cc: mpls@UU.NET (bcc: Mohit Goel/HSS) > > -> > > -> Subject: Any disadvantage about MPLS? > > -> > > -> > > -> > > -> > > -> It seems that MPLS is good for almost everything,from QoS to > > -> traffic engineering > > -> and VPN. > > -> > > -> I want to get some information about its disadvantages,any > > -> information will be > > -> appreciated. > > -> > > -> _____________________________________________ > > -> ?????????????????? http://shopping.263.net/hotsale/summer/ > > -> [???????? ????????] ????????????95963????????/??????263 > > -> > > -> > > -> > > -> > > -> > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Jun 5 20:18:05 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01978 for ; Tue, 5 Jun 2001 20:18:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkseb16423; Wed, 6 Jun 2001 00:16:56 GMT Received: by mail-control.mail.uu.net id QQkseb00395 for mpls-outgoing; Wed, 6 Jun 2001 00:16:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkseb00338 for ; Wed, 6 Jun 2001 00:15:51 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 QQksea29074 for ; Wed, 6 Jun 2001 00:12:33 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQksea13379 for ; Wed, 6 Jun 2001 00:12:33 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 8136B94006; Tue, 5 Jun 2001 20:12:29 -0400 (EDT) Message-ID: <3B1D756D.8D6147AC@sandburst.com> Date: Tue, 05 Jun 2001 20:12:29 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Naidu, Venkata" , "'mgoel@hss.hns.com'" , mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Any disadvantage about MPLS? References: <39469E08BD83D411A3D900204840EC5530964C@VIE-MSGUSR-01> <3B1D6411.5435E607@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Earlier, I wrote (snipped), in response to Venkata: > > ... > > > > (2) When many "bits" are available in hand (IPv4 IPv6 headers) > > to control the flow we can provide many features > > (ranging from diff-serv, TOS, encryption, precedence, > > fragmentation, control & many more options etc.) > > but expecting the same functionality with small number > > of bits in hand (shim header) is always difficult > > and disadvantages follow. > > We cannot do much with 5 or more words worth of binary options > that we cannot also do with the one-word label stack entry. Do > we truly need to differentiate more than 8 million (or so) flows in > every network box, and at every network interface? Just to be clear, comparing apples to apples, you have to include the 8 bit TTL and the 3 bit EXP field, along with the MPLS label when comparing it to IPv4/v6 headers for informational content. The one bit bottom of stack bit has nothing to do with forwarding but there are similarly non-contributing bits in IPv4/v6 headers. Part of the point is that the MPLS label stack gives a more efficient means to aggregate flows (using MPLS tunnels) than - for instance - IP-in-IP tunnels. With improved efficency in aggregating flows, 20 bit labels, possibly with 3 bit EXP values, should be enough info for network boxes/interfaces to process per-packet. Of course, if a network entity wants to support fewer labels, they are free to do so. > > > > ... From owner-mpls@UU.NET Tue Jun 5 20:35:23 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02129 for ; Tue, 5 Jun 2001 20:35:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksec17410; Wed, 6 Jun 2001 00:34:00 GMT Received: by mail-control.mail.uu.net id QQksec01989 for mpls-outgoing; Wed, 6 Jun 2001 00:33:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksec01970 for ; Wed, 6 Jun 2001 00:33: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 QQksec02756 for ; Wed, 6 Jun 2001 00:32:38 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 QQksec15201 for ; Wed, 6 Jun 2001 00:32:38 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 UAA08514 for ; Tue, 5 Jun 2001 20:32:35 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA17531 for ; Tue, 5 Jun 2001 20:32:36 -0400 (EDT) Message-ID: <3B1D7A19.39106874@marconi.com> Date: Tue, 05 Jun 2001 20:32:25 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Any disadvantage about MPLS? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Irfan Lateef wrote: > > With the current experience with MPLS, and the need to design > high speed MPLS routers, I would like take your suggestion to > the extreme of saying that we should have only 16-bit labels. > This would allow faster label lookups. Hence it brings me to saying > that 32-bit MPLS label itself is actually a disadvantage in taking > the designs to the next levels. MPLS labels are not 32-bit values. They are stored in 32-bit integers for the convenience of signaling protocols. An MPLS label on an interface that uses shim headers (like POS) is 20 bits wide. An MPLS label on an ATM interface may be 8, 12, 24 or 28 bits, depending on the encoding scheme (SVC or SVP) and whether the cell structure is UNI or NNI. In general, I think most implementations use 24-bit labels (SVC encoding with UNI-format cell structures.) An MPLS label on a Frame Relay interface may be 10 or 23 bits, depending on the DLCI width that the interface uses. See also RFCs 3031, 3032 and 3034 -- David From owner-mpls@UU.NET Wed Jun 6 00:10:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07033 for ; Wed, 6 Jun 2001 00:10:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkseq19916; Wed, 6 Jun 2001 04:08:53 GMT Received: by mail-control.mail.uu.net id QQkseq12352 for mpls-outgoing; Wed, 6 Jun 2001 04:08:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkseq12062 for ; Wed, 6 Jun 2001 04:08: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 QQkseq04519 for ; Wed, 6 Jun 2001 04:05:27 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQkseq16490 for ; Wed, 6 Jun 2001 04:05:26 GMT Received: (qmail 12488 invoked from network); 6 Jun 2001 03:57:57 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 6 Jun 2001 03:57:57 -0000 Received: from gayatri.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id JAA06760; Wed, 6 Jun 2001 09:36:20 +0530 (IST) Received: from localhost (gabhijit@localhost) by gayatri.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id JAA30103; Wed, 6 Jun 2001 09:40:16 +0530 X-Authentication-Warning: gayatri.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Wed, 6 Jun 2001 09:40:16 +0530 (IST) From: Abhijit Gadgil To: Osama Farrag cc: "Choudhury, Sanjaya" , Subject: RE: Few questions related to LDP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk sorry for a lateish reply.. please follow inline.. > >Unlabelled IP Traffic Matching FEC in your example, will not be mapped into >the LDP LSP by R2, It should not be inserted by R2. Why is it so? As per my understanding, R2 can insert traffic on to the LSP, if it has an entry in the FTN points to the NHLFE that corrosponds to ILM for labelled packets that arrive from R1. (Assuming R2 merge capable). If it is not, it may request a label for traffic arriving on the interface to R4. Is it not a question of whether an implementation can do it, than whether standards support it? regards, -abhijit > > Q3. If an LSR is _not_ an ingress for a FEC, can unlabelled IP > traffic (matching the FEC) be mapped into the LDP LSP corresponding > to the above mentioned FEC ? > For example: > R1-----(FEC1 = L1) ------R2-------(FEC1 = L2)------R3 > | > | > R4 > > R1: ingress for FEC1, R3: egress for FEC1 > > Can/Should unlabelled IP traffic arriving at R2 (from R4 and >matching > prefix) be "inserted" into the LSP _transiting_ through it ? From owner-mpls@UU.NET Wed Jun 6 02:57:10 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21964 for ; Wed, 6 Jun 2001 02:57:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksda10438; Tue, 5 Jun 2001 17:36:43 GMT Received: by mail-control.mail.uu.net id QQksda24165 for mpls-outgoing; Tue, 5 Jun 2001 17:36:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksda24149 for ; Tue, 5 Jun 2001 17:36: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 QQksda26281 for ; Tue, 5 Jun 2001 17:31:50 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQksda05435 for ; Tue, 5 Jun 2001 17:31:49 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f55HVqU07690 for ; Tue, 5 Jun 2001 10:31:52 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA19495 for mpls@uu.net; Tue, 5 Jun 2001 13:31:47 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkscz21850 for ; Tue, 5 Jun 2001 17:19: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 QQkscz09240 for ; Tue, 5 Jun 2001 17:17:51 GMT Received: from ahmler4.mail.eds.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ahmler4.mail.eds.com [192.85.154.77]) id QQkscz08283 for ; Tue, 5 Jun 2001 17:17:50 GMT Received: from ahmlir1.mail.eds.com (ahmlir1-2.mail.eds.com [192.85.154.25]) by ahmler4.mail.eds.com (8.11.1/8.11.1) with ESMTP id f55HHWC18178; Tue, 5 Jun 2001 13:17:32 -0400 Received: from ahmlir1.mail.eds.com (localhost [127.0.0.1]) by ahmlir1.mail.eds.com (8.11.3/8.11.3) with ESMTP id f55HHVI26354; Tue, 5 Jun 2001 13:17:32 -0400 (EDT) Received: from usahm001.examhub.exch.eds.com (usahm001.examhub.exch.eds.com [207.37.138.140]) by ahmlir1.mail.eds.com (8.11.3/8.11.0) with ESMTP id f55HHVY26331; Tue, 5 Jun 2001 13:17:31 -0400 (EDT) Received: by usahm001.examhub.exch.eds.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 13:17:27 -0400 Message-ID: <80C532CF88BDD4118DB700508BE3263603846A55@CAMKM202> From: "Islam, Aziz (Thinkpath)" To: ewliu@263.net, mpls-ops@mplsrc.com Cc: mpls@UU.NET Subject: RE: Any disadvantage about MPLS? Date: Tue, 5 Jun 2001 13:17:28 -0400 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 Hi All, To debate the advantages and disadvantages of MPLS, one needs to clearly understand where it fits in into the realm of data communications. MPLS complements routing and takes it to the next level. The obvious disadvantage is that being the "bleeding-edge" technology, some hiccups might be expected in its implementation. Also, the learning curve may be steep for some organizations and individuals. Interoperability and inter-provider issues, as always, take some time to get resolved, for which work is going on in full swing in many IETF working groups. So I would sum up by saying that the advantages of MPLS may far outweigh its disadvantages. Aziz S. Islam Senior Infrastructure Specialist Cisco CCIE R/S Network Engineering EDS Canada Inc. 33 Yonge Street, Suite 400 Toronto, Ontario M5E 1G4 Ph: (416)814-1696 http://www.eds.com -----Original Message----- From: ewliu@263.net [mailto:ewliu@263.net] Sent: June 4, 2001 5:26 PM To: mpls-ops@mplsrc.com Cc: mpls@UU.NET Subject: Any disadvantage about MPLS? Importance: High This message uses a character set that is not supported by the Internet Service. To view the original message content, open the attached message. If the text doesn't display correctly, save the attachment to disk, and then open it using a viewer that can display the original character set. From owner-mpls@UU.NET Wed Jun 6 05:03:01 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23996 for ; Wed, 6 Jun 2001 05:03:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksfk09345; Wed, 6 Jun 2001 09:01:49 GMT Received: by mail-control.mail.uu.net id QQksfk07821 for mpls-outgoing; Wed, 6 Jun 2001 09:01:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksfk07274 for ; Wed, 6 Jun 2001 09:01:05 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 QQksfj19413 for ; Wed, 6 Jun 2001 08:57:09 GMT Received: from piorun.ds.pg.gda.pl by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: piorun.ds.pg.gda.pl [213.192.76.1]) id QQksfj03947 for ; Wed, 6 Jun 2001 08:54:20 GMT Received: from localhost (maks@localhost) by piorun.ds.pg.gda.pl (8.11.4/8.11.4) with ESMTP id f568xPe23354 for ; Wed, 6 Jun 2001 10:59:40 +0200 Date: Wed, 6 Jun 2001 10:59:24 +0200 (CEST) From: Maks Milkowski To: Subject: ATM QoS classes in MPLS (?) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I'm doing some research about IP/ATM integration by implementing MPLS in ATM networks. I have some doubts regarding QoS issues: ATM routing protocols supporting ATM QoS classes (CBR, VBR, etc.) are replaced with IP routing protocols - does it mean that ATM-LSRs (not working in 'ships in the night' mode) support only int-serv and diff-serv models ? Do they use CAC function to deliver those QoS guarantees? How ATM cells carrying IP packet are treated in ATM-LSRs from QoS point of view? Thanks in advance for any help, Maks From owner-mpls@UU.NET Wed Jun 6 08:33:09 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27926 for ; Wed, 6 Jun 2001 08:33:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksfy12651; Wed, 6 Jun 2001 12:30:30 GMT Received: by mail-control.mail.uu.net id QQksfy15535 for mpls-outgoing; Wed, 6 Jun 2001 12:30:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksfx15477 for ; Wed, 6 Jun 2001 12:29:33 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 QQksfx26295 for ; Wed, 6 Jun 2001 12:27:14 GMT Received: from localhost.localdomain by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksfx08947 for ; Wed, 6 Jun 2001 12:27:10 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f56CU0q14148; Wed, 6 Jun 2001 18:00:09 +0530 Date: Wed, 6 Jun 2001 17:59:59 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: Abhijit Gadgil cc: Osama Farrag , "Choudhury, Sanjaya" , mpls@UU.NET Subject: RE: Few questions related to LDP In-Reply-To: Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Abhijit, If there is an FTN entry in R2 that matches FEC1 then R2 _will_ insert labelled traffic, BUT in that case the statement that R2 is _not_ ingress for FEC1 is _not_ correct. Only if R2 is an ingress LSR for FEC1 will it install such an FTN entry. To understand how it is known whether an LSR is ingress for an FEC refer section 3.5.7.1 RFC 3036. In short an LSR is ingress for an FEC iff there is a routing tabel entry that exactly matches that FEC. cheers tomar On Wed, 6 Jun 2001, Abhijit Gadgil wrote: > > sorry for a lateish reply.. > > please follow inline.. > > > > >Unlabelled IP Traffic Matching FEC in your example, will not be mapped into > >the LDP LSP by R2, It should not be inserted by R2. > > Why is it so? As per my understanding, R2 can insert traffic on to the > LSP, if it has an entry in the FTN points to the NHLFE that corrosponds > to ILM for labelled packets that arrive from R1. (Assuming R2 merge > capable). If it is not, it may request a label for traffic arriving on > the interface to R4. > > Is it not a question of whether an implementation can do it, than whether > standards support it? > > regards, > > -abhijit > > > > > Q3. If an LSR is _not_ an ingress for a FEC, can unlabelled IP > > traffic (matching the FEC) be mapped into the LDP LSP corresponding > > to the above mentioned FEC ? > > For example: > > R1-----(FEC1 = L1) ------R2-------(FEC1 = L2)------R3 > > | > > | > > R4 > > > > R1: ingress for FEC1, R3: egress for FEC1 > > > > Can/Should unlabelled IP traffic arriving at R2 (from R4 and > >matching > > prefix) be "inserted" into the LSP _transiting_ through it ? > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Wed Jun 6 09:11:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29462 for ; Wed, 6 Jun 2001 09:11:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksga28395; Wed, 6 Jun 2001 13:08:09 GMT Received: by mail-control.mail.uu.net id QQksga00883 for mpls-outgoing; Wed, 6 Jun 2001 13:07:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksga00838 for ; Wed, 6 Jun 2001 13:07:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQksga21595 for ; Wed, 6 Jun 2001 13:06:01 GMT Received: from anchor-post-30.mail.demon.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: anchor-post-30.mail.demon.net [194.217.242.88]) id QQksga26225 for ; Wed, 6 Jun 2001 13:06:01 GMT Received: from layer8.demon.co.uk ([158.152.28.34] helo=layer8.co.uk) by anchor-post-30.mail.demon.net with smtp (Exim 2.12 #1) id 157d39-000C2k-0U for mpls@UU.NET; Wed, 6 Jun 2001 14:08:40 +0100 Received: from Bart [192.168.0.2] by layer8.co.uk [127.0.0.1] with SMTP (MDaemon.v2.7.SP0.R) for ; Wed, 06 Jun 101 14:00:21 +0100 From: "Andrew Bartholomew" To: "Chris Kuszmaul" , "Eric Gray" Cc: "MPLS Mailing List" Subject: RE: LDP requires break-before-make Date: Wed, 6 Jun 2001 14:04:53 +0100 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 V5.50.4133.2400 In-Reply-To: <3B17C9EC.1833E239@pluris.com> Importance: Normal X-MDaemon-Deliver-To: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Chris, If you consider the case that B is non-label-merge capable then A will sometimes need to bind new labels to the FEC without withdrawing the previous one. Such cases could make the update process much more complicated (consider updating one of the labels bound to a FEC but not the others). It seems to me as though there is a requirement for a transaction concept similar to MEGACO H.248, where a single transaction contains a number of separate actions, each comprising a set of commands that are executed sequentially. Actions may be performed in any order but if a command within an action fails, the action is aborted and the next action begun. regards, Andrew -- Andrew Bartholomew Layer 8 Consultancy Observa et sapiens cresces Services Limited Tel: +44 1202 558409 Fax: +44 1202 556748 Email: Andrewb@layer8.co.uk > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Chris > Kuszmaul > Sent: 01 June 2001 17:59 > To: Eric Gray > Cc: MPLS Mailing List > Subject: Re: LDP requires break-before-make > > > Hi Eric > > I think you are right. Consider LSRs A and B. > > A sends to B the label mapping: > > There is nothing I am aware of in the spec that prevents A from > sending another > mapping, such as: > , prior to receiving a label release (of label1) from B. > > What I was saying was that B had to release label1 (transmit a > label release to A) > before B could accept the mapping of label2. Your solution, of > combining a label > withdrawal (of label1) with the label mapping of label2, in a > PDU, seems to basically > make sense. > > The semantics of ordering is necessary, but not sufficient to > prevent a break before > make. I think there needs to be a sense of atomicity as well: > Both the label > withdrawal and the label mapping need to be done, or neither > should be done. In > particular, the label release message transmitted by B MUST be > contemporaneous with > the completion of the label mapping. The LDP spec does not > *preclude* just such a > behavior, and so a PDU containing a label withdrawal and a label > mapping can be > treated as a label-mapping-overwrite, without violating the spec, > and thus preventing > a break before make. > > CLK > > > Eric Gray wrote: > > > Chris, > > > > I understand your concern. A few years ago (early '98) I had > > proposed a semantic interpretation for LDP that directly related > > to this. The response was to explicitly prohibit the behavior > > which would have had this semantic. > > > > I had suggested that (in DU mode) an LSR that advertised a > > new label for exactly the same FEC as it had previously advertised > > a different label meant for the upstream LSR to replace the previous > > label with the new one. Over time, I came to undestand why this > > may have been a little too simplistic. Also, it may be needed when > > DoD label advertisement is being used as well. > > > > I think your basic idea of using a new message type will work. > > I had thought of that and talked with a couple of people on the LDP > > design team about it - and they were not too receptive to the idea > > as part of the base LDP specification (adds complexity not really > > required for basic functionality). Also - at the time - I thought it > > possible to achieve a very similar result by simply including both > > the label withdraw and the new label mapping in the same PDU (an > > LDP PDU can contain multiple LDP messages). > > > > Of course, this latter approach depends on a few things: > > > > o that you are not correct in your assertion that a > downstream > > LSR is required to wait for a label release > message prior > > to sending a new label mapping (*), > > > > o that an upstream LSR actually looks for a 'replacement' > > label mapping message in a PDU that contains a label > > withdraw message, > > > > o that this upstream LSR processes multiple messages in a > > single PDU in the order in which they appear in the PDU > > > > and > > > > o that the dowbstream LSR put them in the PDU in the order > > in which it expected them to be processed (+). > > > > * I think that the requirement is that the downstream LSR MUST > > not re-use the same label until it receives a label > release for a > > label it has withdrawn. I do not think there is any > statement in > > the specification that prohibits sending a new label mapping > > prior to receiving a label release for the previous mapping for > > the same FEC. Please let me know if there is text in the spec > > to the contrary. > > > > + Given that I am right in my interpretation of the current spec wrt > > issuing a new label mapping after a label withdraw, the last two > > bullets naturally fall out since the current > restriction on sending > > a new label mapping (with a different label) prior to > withdrawing > > a prior label mapping imposes an ordering resptriction on adding > > messages to a PDU and processing them on receipt. This ordering > > is not hard to achieve. > > > > Essentially, a downstream LSR can try this approach and hope that > > the upstream LSR was built to be robust and resilient (either using the > > approach above, or some other approach). > > > > -- > > Eric Gray > > > > You wrote: > > > > > Before a label can be mapped to an FEC that has already been > mapped, the LSR > > > must release the old label (prompted perhaps by a withdrawal > message). Thus, LDP > > > calls for a break-before-make on LSP updates. It would seem > a straightforward > > > matter for the protocol to include a withdraw-and-map message > that performs this > > > sequence atomically, and so preserves a make-before-break condition. > > > > > > Is there some reason for not providing for this kind of > functionality? > > > > > > Thanks for any comments. > > > > > > CLK > > > > > > PS: The careful reader will realize that I have mentioned > this issue before in > > > the thread [Re: Receive Label Receive !!], but have not seen > any reply. This is > > > an attempt to focus the question and broaden the pool of > possible respondents. > > > From owner-mpls@UU.NET Wed Jun 6 10:01:44 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01158 for ; Wed, 6 Jun 2001 10:01:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksgd11687; Wed, 6 Jun 2001 13:58:49 GMT Received: by mail-control.mail.uu.net id QQksgd14844 for mpls-outgoing; Wed, 6 Jun 2001 13:58:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksgd14822 for ; Wed, 6 Jun 2001 13:57:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQksgd18212 for ; Wed, 6 Jun 2001 13:57:40 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQksgd10137 for ; Wed, 6 Jun 2001 13:57:39 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f56Dvc907650 for ; Wed, 6 Jun 2001 06:57:38 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA20783 for mpls@uu.net; Wed, 6 Jun 2001 09:57:37 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkseq12341 for ; Wed, 6 Jun 2001 04:08:16 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 QQkseq07078 for ; Wed, 6 Jun 2001 04:07:54 GMT Received: from web10008.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web10008.mail.yahoo.com [216.136.130.44]) id QQkseq18791 for ; Wed, 6 Jun 2001 04:07:53 GMT Message-ID: <20010606040752.82311.qmail@web10008.mail.yahoo.com> Received: from [63.116.202.66] by web10008.mail.yahoo.com; Tue, 05 Jun 2001 21:07:52 PDT Date: Tue, 5 Jun 2001 21:07:52 -0700 (PDT) From: Vishal Mishra Subject: RE: IP Fragmentation before entering LSP To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk IP fragmentation would not be a problem for stream based protocols. Looking at the fact that the bulk of Internet Traffic, esp. the connection oriented traffic is TCP based, which does Path MTU Discovery, most of the LSPs would carry complete IP packets, since IP packets holding TCP data would never need to be fragmented. For protocols that use UDP or other/raw IP packets, some can be classified under the category - (1) They can break a large protocol PDU into multiple small PDUs, and (2) Those that require complete Protocol PDU to go in a single IP packet. (Not quite the best Example: Assuming that RSVP and OSPF packets want to ride through LSP tunnels for some reason - RSVP can choose to break a large RSVP packet holding a Bundle Message, into multiple small single/bundle messages, but OSPF cannot break a packet holding a large number of Router LSAs into multiple packets, even if it 'knew' the Path MTU) By-Passing the Problem - The category-1 protocol implementations can simply introduce the Path MTU Discovery mechanism to by-pass the fragmentation problem (MPLS aware version of daemon !!). The category-2 protocols would not be able to get the benefit of the LSP (only for L4+ based LSP), whenever the are forced to send large IP Packets. Vishal. --- Eric Gray wrote: > Nagendra, > > Vishal's original question had to do with a general concern that > already > fragmented UDP packets might arrive at a point where a TE LSP > originates. > If the basis for ingress to the TE LSP is a specific L4 attribute, it > is possible > that the first IP fragment will qualify for ingress and the rest will > not. While > out of order delivery is a concern in this situation, perhaps a more > important > concern is that the 'service' associated with the TE LSP was meant to > apply > to the entire UDP packet. Since all but the first fragment do not > receive this > 'service' (whatever it is), the entire packet is at least as bad off > as if no part > of it received the 'service'. > > The issue with re-ordering IP fragments is that many stack > implementations > do this somewhat sub-optimally. Thus, if fragments are re-ordered, > this could > lead to further degradation of the 'service' intended for this > packet. > > An example of a 'service' degradation might be the case where a > certain class > of UDP packets are intended to be filtered (possibly to prevent > certain types of > denial of service attack). In this case, filtering the first > fragment could result > in > a greater 'denial of service' impact that if the filtering service > did not exist. > > I think Dave Charlap and Ron Bonica were going in the right > direction with > their > suggestions. It seems to me that the LSR at the ingress needs to be > more aware of > its limitations. If it is not able to ensure that all subsequent IP > fragments will > go > on the same LSP, it should not admit the first one. Either it uses > Dave's options > 1 or 3, it forwards using IP or it drops the packet (as Ron > suggested). Note that > this is also consistent with Jay's initial suggestion to employ the > same policy to > all IP fragments. > > -- > Eric Gray >> Hi Folks, >> >> How are fragmented IP Packets identified by the Ingress LER >> if the basis of classification involves part of the IP Payload, >> such as the Transport Layer address (say UDP Port) ? >> >> Does this mean only the first fragment of all such IP Packets >> travel through the Traffic Engineered LSP, and the rest of the IP >> fragments (being unclassified) follow the best effort (Non-TEed) >> Path ? >> >> This would lead to a whole lot of problems (including out of >> order packets). >> >> Thanks for any help !! >> >> Vishal. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jun 6 10:23:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01759 for ; Wed, 6 Jun 2001 10:22:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksgf19390; Wed, 6 Jun 2001 14:19:30 GMT Received: by mail-control.mail.uu.net id QQksgf06899 for mpls-outgoing; Wed, 6 Jun 2001 14:18:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksgf06600 for ; Wed, 6 Jun 2001 14:16: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 QQksge19068 for ; Wed, 6 Jun 2001 14:13:36 GMT Received: from bridge.axiowave.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.axiowave.com [209.6.34.2]) id QQksge02606 for ; Wed, 6 Jun 2001 14:13:35 GMT Message-ID: From: Jeff Parker To: "'Maks Milkowski'" , mpls@UU.NET Subject: RE: ATM QoS classes in MPLS (?) Date: Wed, 6 Jun 2001 10:02:23 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EE91.4F44A020" 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_01C0EE91.4F44A020 Content-Type: text/plain; charset="iso-8859-1" > Hi all, > I'm doing some research about IP/ATM integration by > implementing MPLS in > ATM networks. I have some doubts regarding QoS issues: > ATM routing protocols supporting ATM QoS classes (CBR, VBR, etc.) are > replaced with IP routing protocols - does it mean that ATM-LSRs (not > working in 'ships in the night' mode) support only int-serv > and diff-serv > models ? Do they use CAC function to deliver those QoS > guarantees? How ATM > cells carrying IP packet are treated in ATM-LSRs from QoS > point of view? > > Thanks in advance for any help, > > Maks We need another metaphor - "Ships in the night" suggests: Suppose you book first class passage on an ocean liner, with a suite. What happens to your reservation if you find that your transport has been changed to air rather than sea? The problem of mapping between different models of service is not an easy one. - jeff parker ------_=_NextPart_001_01C0EE91.4F44A020 Content-Type: text/html; charset="iso-8859-1" RE: ATM QoS classes in MPLS (?)

> Hi all,
> I'm doing some research about IP/ATM integration by
> implementing MPLS in
> ATM networks. I have some doubts regarding QoS issues:
> ATM routing protocols supporting ATM QoS classes (CBR, VBR, etc.) are
> replaced with IP routing protocols - does it mean that  ATM-LSRs (not
> working in 'ships in the night' mode) support only int-serv
> and diff-serv
> models ? Do they use CAC function to deliver those QoS
> guarantees? How ATM
> cells carrying IP packet are treated in ATM-LSRs from QoS
> point of view?
>
> Thanks in advance for any help,
>
> Maks

We need another metaphor - "Ships in the night" suggests:

        Suppose you book first class passage on
an ocean liner, with a suite.  What happens to your
reservation if you find that your transport has been
changed to air rather than sea? 

The problem of mapping between different models of service
is not an easy one. 

- jeff parker

------_=_NextPart_001_01C0EE91.4F44A020-- From owner-mpls@UU.NET Wed Jun 6 10:27:38 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01855 for ; Wed, 6 Jun 2001 10:27:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksgf25977; Wed, 6 Jun 2001 14:24:36 GMT Received: by mail-control.mail.uu.net id QQksgf07544 for mpls-outgoing; Wed, 6 Jun 2001 14:24:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksgf07529 for ; Wed, 6 Jun 2001 14:23:56 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 QQksgf17278 for ; Wed, 6 Jun 2001 14:22:06 GMT Received: from samar.sasken.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQksgf22755 for ; Wed, 6 Jun 2001 14:22:02 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f56ELtE10527 for ; Wed, 6 Jun 2001 19:51:55 +0530 (IST) Received: from sasken.com (IDENT:rpjain@pcd-1-150.sasi.com [10.0.19.150]) by sund2.sasi.com (8.9.3/8.9.3) with ESMTP id NAA28909 for ; Tue, 5 Jun 2001 13:08:44 +0530 (IST) Message-ID: <3B1C8C83.1FF4D9CB@sasken.com> Date: Tue, 05 Jun 2001 13:08:43 +0530 From: Rajesh P Jain Organization: Sasken X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: MPLS Mailing List Subject: RSVP Path Message - Sender Descriptor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Hi", With reference to RFC 2205, PATH Message contains "Sender Descriptor" parameter as an "Optional Object". Why is the "Sender Descriptor" ( []), Optional???? If it is optional, How are Path States created without SENDER_TEMPLATE???? (Since the section 3.1.3 of RFC 2205 says that "Each RSVP-capable node along the path(s) captures a path message and processes it to create path state for the sender defined by the SENDER_TEMPLATE and SESSION objects). Please throw light on the above statement of the RFC??? TIA, Rajesh P Jain From owner-mpls@UU.NET Wed Jun 6 11:00:41 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02621 for ; Wed, 6 Jun 2001 11:00:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksgh10073; Wed, 6 Jun 2001 14:59:11 GMT Received: by mail-control.mail.uu.net id QQksgh12211 for mpls-outgoing; Wed, 6 Jun 2001 14:58:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksgh12196 for ; Wed, 6 Jun 2001 14:58: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 QQksgh10222 for ; Wed, 6 Jun 2001 14:57:44 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 QQksgh23071 for ; Wed, 6 Jun 2001 14:57:44 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 KAA15955 for ; Wed, 6 Jun 2001 10:57:39 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22780 for ; Wed, 6 Jun 2001 10:57:37 -0400 (EDT) Message-ID: <3B1E44D9.42429BC9@marconi.com> Date: Wed, 06 Jun 2001 10:57:29 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: MPLS Mailing List Subject: Re: RSVP Path Message - Sender Descriptor References: <3B1C8C83.1FF4D9CB@sasken.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Rajesh P Jain wrote: > > With reference to RFC 2205, PATH Message contains "Sender > Descriptor" parameter as an "Optional Object". > > Why is the "Sender Descriptor" > ( []), Optional???? > > If it is optional, How are Path States created without > SENDER_TEMPLATE???? (Since the section 3.1.3 of RFC 2205 says that > "Each RSVP-capable node along the path(s) captures a path message > and processes it to create path state for the sender defined by > the SENDER_TEMPLATE and SESSION objects). The RSVP-TE draft (draft-ietf-mpls-rsvp-lsp-tunnel-08) does not have sender descriptor as an optional object, so the question is moot for MPLS. With respect to why RFC-2205 declares sender optional, the only thing I can think of is that is may not be necessary if WF-style reservations are used. You may find the RSVP working group more helpful here. Here are it's home pages: http://www.ietf.org/html.charters/rsvp-charter.html http://www.isi.edu/div7/rsvp/rsvp.html -- David From owner-mpls@UU.NET Wed Jun 6 11:02:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02665 for ; Wed, 6 Jun 2001 11:02:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksgi08755; Wed, 6 Jun 2001 15:00:51 GMT Received: by mail-control.mail.uu.net id QQksgi12430 for mpls-outgoing; Wed, 6 Jun 2001 15:00:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksgh12270 for ; Wed, 6 Jun 2001 14:59:32 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQksgh00754 for ; Wed, 6 Jun 2001 14:55:06 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQksgh03422 for ; Wed, 6 Jun 2001 14:55:04 GMT Received: (qmail 12238 invoked from network); 6 Jun 2001 14:47:36 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 6 Jun 2001 14:47:36 -0000 Received: from bharati.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id UAA17072; Wed, 6 Jun 2001 20:25:54 +0530 (IST) Received: from localhost (gabhijit@localhost) by bharati.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id UAA20321; Wed, 6 Jun 2001 20:26:01 +0530 Date: Wed, 6 Jun 2001 20:26:01 +0530 (IST) From: Abhijit Gadgil To: Nagendra Singh Tomar cc: Osama Farrag , "Choudhury, Sanjaya" , Subject: RE: Few questions related to LDP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk >Abhijit, > If there is an FTN entry in R2 that matches FEC1 then R2 _will_ >insert labelled traffic, BUT in that case the statement that R2 is _not_ >ingress for FEC1 is _not_ correct. If R2 does not recognize the FEC1, then when it receives label request for that FEC1, it will respond with "No Route" notification. So there is every reason to assume R2 has the FEC1 entry in its routing table. So it can potentially become _ingress_ for the FEC1. So it does not stop R2 from putting packets on the LSP. The fact that whether it can do so or not is more of implementation choice. Any LSR which can receive unlabeled packet and can forward it can become _ingress_. -abhijit > Only if R2 is an ingress LSR for FEC1 will it install such an FTN >entry. To understand how it is known whether an LSR is ingress for an FEC >refer section 3.5.7.1 RFC 3036. In short an LSR is ingress for an FEC iff >there is a routing tabel entry that exactly matches that FEC. > >cheers >tomar > > >On Wed, 6 Jun 2001, Abhijit Gadgil wrote: > >> >> sorry for a lateish reply.. >> >> please follow inline.. >> >> > >> >Unlabelled IP Traffic Matching FEC in your example, will not be mapped into >> >the LDP LSP by R2, It should not be inserted by R2. >> >> Why is it so? As per my understanding, R2 can insert traffic on to the >> LSP, if it has an entry in the FTN points to the NHLFE that corrosponds >> to ILM for labelled packets that arrive from R1. (Assuming R2 merge >> capable). If it is not, it may request a label for traffic arriving on >> the interface to R4. >> >> Is it not a question of whether an implementation can do it, than whether >> standards support it? >> >> regards, >> >> -abhijit >> >> > >> > Q3. If an LSR is _not_ an ingress for a FEC, can unlabelled IP >> > traffic (matching the FEC) be mapped into the LDP LSP corresponding >> > to the above mentioned FEC ? >> > For example: >> > R1-----(FEC1 = L1) ------R2-------(FEC1 = L2)------R3 >> > | >> > | >> > R4 >> > >> > R1: ingress for FEC1, R3: egress for FEC1 >> > >> > Can/Should unlabelled IP traffic arriving at R2 (from R4 and >> >matching >> > prefix) be "inserted" into the LSP _transiting_ through it ? >> > > From owner-mpls@UU.NET Wed Jun 6 11:57:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03913 for ; Wed, 6 Jun 2001 11:57:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksgl11738; Wed, 6 Jun 2001 15:56:06 GMT Received: by mail-control.mail.uu.net id QQksgl08747 for mpls-outgoing; Wed, 6 Jun 2001 15:55:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksgl08717 for ; Wed, 6 Jun 2001 15:54: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 QQksgl25402 for ; Wed, 6 Jun 2001 15:49:16 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f232.law11.hotmail.com [64.4.17.232]) id QQksgl02457 for ; Wed, 6 Jun 2001 15:49:16 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 6 Jun 2001 08:49:15 -0700 Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 06 Jun 2001 15:49:15 GMT X-Originating-IP: [65.112.106.16] From: "Irfan Lateef" To: david.charlap@marconi.com, mpls@UU.NET Subject: Re: Any disadvantage about MPLS? Date: Wed, 06 Jun 2001 11:49:15 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jun 2001 15:49:15.0734 (UTC) FILETIME=[3D520F60:01C0EEA0] Sender: owner-mpls@UU.NET Precedence: bulk David, I mis-wrote 20-bit as 32-bit, thanks for correcting me. But the point I was trying to make is the sanctity of 20-bits versus 16-bits. I have been through all RFCs and even Yakov's book does not talk about it. I was only refering to the case where shim headers are used as you mentioned in POS. Can you enlighten us with the rationale for the 20-bits for label versus why not 16-bits. Thanks, Irfan >From: David Charlap >To: mpls@UU.NET >Subject: Re: Any disadvantage about MPLS? >Date: Tue, 05 Jun 2001 20:32:25 -0400 > >Irfan Lateef wrote: > > > > With the current experience with MPLS, and the need to design > > high speed MPLS routers, I would like take your suggestion to > > the extreme of saying that we should have only 16-bit labels. > > This would allow faster label lookups. Hence it brings me to saying > > that 32-bit MPLS label itself is actually a disadvantage in taking > > the designs to the next levels. > >MPLS labels are not 32-bit values. They are stored in 32-bit integers >for the convenience of signaling protocols. > >An MPLS label on an interface that uses shim headers (like POS) is 20 >bits wide. > >An MPLS label on an ATM interface may be 8, 12, 24 or 28 bits, depending >on the encoding scheme (SVC or SVP) and whether the cell structure is >UNI or NNI. In general, I think most implementations use 24-bit labels >(SVC encoding with UNI-format cell structures.) > >An MPLS label on a Frame Relay interface may be 10 or 23 bits, depending >on the DLCI width that the interface uses. > >See also RFCs 3031, 3032 and 3034 > >-- David _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Jun 6 13:45:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06649 for ; Wed, 6 Jun 2001 13:45:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksgs01216; Wed, 6 Jun 2001 17:44:08 GMT Received: by mail-control.mail.uu.net id QQksgs00186 for mpls-outgoing; Wed, 6 Jun 2001 17:43:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksgs00166 for ; Wed, 6 Jun 2001 17:43: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 QQksgs13780 for ; Wed, 6 Jun 2001 17:42:43 GMT Received: from charon.s3group.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns.s3group.com [193.120.90.3]) id QQksgs29122 for ; Wed, 6 Jun 2001 17:42:42 GMT Received: from headyin.s3group.com ([193.120.89.200]) by charon.s3group.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16713; Wed, 6 Jun 2001 18:42:03 +0100 (BST) Received: from s3group.com ([193.120.89.113]) by headyin.s3group.com (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GEI00GLURTX9N@headyin.s3group.com>; Wed, 6 Jun 2001 18:41:58 +0100 (BST) Date: Wed, 06 Jun 2001 18:45:57 +0100 From: Paul Mannion Subject: FTN MIB Question To: mpls@UU.NET, mpls-ops@mplsrc.com Message-id: <3B1E6C55.E5EDFC4E@s3group.com> Organization: Comms Infrastructure MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (WinNT; U) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_1RoQKOy7XO5Feil1Wvzkaw)" X-Accept-Language: en,en-GB Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_1RoQKOy7XO5Feil1Wvzkaw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, sorry if this has been answered already. If i'm missing something fundamental please point me in the right direction. The FTNMap table in the FEC-To-NHFLE MIB is indexed using the mplsFTNMapIfIndex. The entry is described as follows: "Interface index that this FTN entry is being applied to. " If we're running MPLS over ethernet on this ingress LER, is the mplsFTNMapIfIndex the local ifIndex of the incoming ethernet interface ? Or am I missing something? paul --Boundary_(ID_1RoQKOy7XO5Feil1Wvzkaw) Content-type: text/x-vcard; name=paulm.vcf; charset=us-ascii Content-description: Card for Paul Mannion Content-disposition: attachment; filename=paulm.vcf Content-Transfer-Encoding: 7bit begin:vcard n:Mannion;Paul tel;work:353-1-2078766 x-mozilla-html:FALSE org:Silicon and Software Systems;Communications Infrastructure version:2.1 email;internet:Paul.Mannion@s3group.com title:Software Engineer adr;quoted-printable:;;Sandyford Ind Estate,=0D=0ALeopardstown;Dublin;;;Ireland fn:Paul Mannion end:vcard --Boundary_(ID_1RoQKOy7XO5Feil1Wvzkaw)-- From owner-mpls@UU.NET Wed Jun 6 13:54:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06898 for ; Wed, 6 Jun 2001 13:54:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksgt10231; Wed, 6 Jun 2001 17:53:12 GMT Received: by mail-control.mail.uu.net id QQksgt01482 for mpls-outgoing; Wed, 6 Jun 2001 17:52:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksgt01458 for ; Wed, 6 Jun 2001 17:52:08 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 QQksgt00457 for ; Wed, 6 Jun 2001 17:50:45 GMT Received: from smtp486-bms.mail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp486-bms.mail.com [165.251.44.40]) id QQksgt07304 for ; Wed, 6 Jun 2001 17:50:45 GMT Received: from csrinivasan (unknown [12.34.209.72]) by smtp486-bms.mail.com (SMTP server) with SMTP id 3E7F2498A4; Wed, 6 Jun 2001 13:50:45 -0400 (EDT) From: "Cheenu Srinivasan" To: "'Paul Mannion'" , , Subject: RE: FTN MIB Question Date: Wed, 6 Jun 2001 13:56:51 -0400 Message-ID: <176689DD1922D511ABE10001022E4DF20AB057@OPTONT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <3B1E6C55.E5EDFC4E@s3group.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > The FTNMap table in the FEC-To-NHFLE MIB is indexed using the > mplsFTNMapIfIndex. The entry is described as follows: > > "Interface index that this FTN entry is being applied > to. " > > If we're running MPLS over ethernet on this ingress LER, is the > mplsFTNMapIfIndex the local ifIndex of the incoming ethernet > interface ? This is correct. Cheenu From owner-mpls@UU.NET Wed Jun 6 16:09:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08627 for ; Wed, 6 Jun 2001 16:09:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkshc19936; Wed, 6 Jun 2001 20:08:10 GMT Received: by mail-control.mail.uu.net id QQkshc08985 for mpls-outgoing; Wed, 6 Jun 2001 20:07:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkshc07741 for ; Wed, 6 Jun 2001 20:07:01 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 QQkshc29576 for ; Wed, 6 Jun 2001 20:07:01 GMT Received: from dnsmx1rrc.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQkshc17795 for ; Wed, 6 Jun 2001 20:07:01 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA21849 for ; Wed, 6 Jun 2001 16:01:11 -0400 (EDT) Subject: resv tear--label To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Wed, 6 Jun 2001 16:01:08 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 06/06/2001 04:01:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can anyone help me to confirm whether there is a label object inside the Resv-tear message? For my understanding, there is , and it is got from the Resv message. So I think there is a label object inside the resv tear message. Thanks, Julia From owner-mpls@UU.NET Wed Jun 6 16:26:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08806 for ; Wed, 6 Jun 2001 16:26:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkshd16013; Wed, 6 Jun 2001 20:24:37 GMT Received: by mail-control.mail.uu.net id QQkshd16247 for mpls-outgoing; Wed, 6 Jun 2001 20:23:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkshd16156 for ; Wed, 6 Jun 2001 20:22: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 QQkshd24902 for ; Wed, 6 Jun 2001 20:19:17 GMT Received: from web14101.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14101.mail.yahoo.com [216.136.172.131]) id QQkshd27996 for ; Wed, 6 Jun 2001 20:19:16 GMT Message-ID: <20010606201915.28160.qmail@web14101.mail.yahoo.com> Received: from [199.166.16.38] by web14101.mail.yahoo.com; Wed, 06 Jun 2001 13:19:15 PDT Date: Wed, 6 Jun 2001 13:19:15 -0700 (PDT) From: LDP Hello Subject: Re: rsvp -te To: Adrian Farrel , mpls@UU.NET, Hong Liao In-Reply-To: <001701c0ec69$74bdc950$29c5893e@movaz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I agree with Adrian. http://www.iana.org/assignments/rsvp-parameters explains all the unassigned Classes for RSVP. Any Object with unassigned or unknown Class number must be considered Opaque Object and must be treated according to RFC2205's section 3.10. ie must be rejected if the class is 0bbbbbbb, ignore silently if class is 10bbbbbb and ignore but forward if 11bbbbbb. regards; --- Adrian Farrel wrote: > Hi Julia, > > Perfectly possible. > > See RFC2205 section 3.10 > > Regards, > Adrian > -- > Adrian Farrel > Movaz Networks Inc. > afarrel@movaz.com > ----- Original Message ----- > From: "Hong Liao" > To: > Sent: Friday, June 01, 2001 7:20 PM > Subject: rsvp -te > > > > > > Hi, > > > > Is it possible for RSVP message with proprietary > objects that are not > > defined in the spec like Opaque object? > > I do not think so. Can anyone tell me whether I > am right. > > > > > > Thanks in advance. > > > > Julia > > > > > > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jun 6 17:24:45 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09374 for ; Wed, 6 Jun 2001 17:24:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkshh06812; Wed, 6 Jun 2001 21:23:07 GMT Received: by mail-control.mail.uu.net id QQkshh12395 for mpls-outgoing; Wed, 6 Jun 2001 21:22:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkshh12346 for ; Wed, 6 Jun 2001 21:21:52 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 QQkshh24188 for ; Wed, 6 Jun 2001 21:20:03 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 QQkshh03764 for ; Wed, 6 Jun 2001 21:20:02 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 RAA18278 for ; Wed, 6 Jun 2001 17:19:59 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02356 for ; Wed, 6 Jun 2001 17:20:00 -0400 (EDT) Message-ID: <3B1E9E79.4D346675@marconi.com> Date: Wed, 06 Jun 2001 17:19:53 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: rsvp -te References: <20010606201915.28160.qmail@web14101.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit LDP Hello wrote: > > I agree with Adrian. > > http://www.iana.org/assignments/rsvp-parameters > explains all the unassigned Classes for RSVP. > > Any Object with unassigned or unknown Class number > must be considered Opaque Object and must be treated > according to RFC2205's section 3.10. ie must be > rejected if the class is 0bbbbbbb, ignore silently if > class is 10bbbbbb and ignore but forward if 11bbbbbb. This rule should be followed for all unsupported object classes, even if there is an IANA assignment for that class number -- David From owner-mpls@UU.NET Wed Jun 6 17:26:12 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09400 for ; Wed, 6 Jun 2001 17:26:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkshh25505; Wed, 6 Jun 2001 21:24:32 GMT Received: by mail-control.mail.uu.net id QQkshh12417 for mpls-outgoing; Wed, 6 Jun 2001 21:22:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkshh12378 for ; Wed, 6 Jun 2001 21:22: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 QQkshh08181 for ; Wed, 6 Jun 2001 21:22:08 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 QQkshh22803 for ; Wed, 6 Jun 2001 21:22:08 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA18412 for ; Wed, 6 Jun 2001 17:22:05 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02653 for ; Wed, 6 Jun 2001 17:22:06 -0400 (EDT) Message-ID: <3B1E9EF7.D3B75C6E@marconi.com> Date: Wed, 06 Jun 2001 17:21:59 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: resv tear--label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > Can anyone help me to confirm whether there is a label object > inside the Resv-tear message? > > For my understanding, there is , and it is > got from the Resv message. So I think there is a label object > inside the resv tear message. First rule of internet protocols: Be conservative in what you send. Be liberal in what you accept. Your code should include the label in ResvTear messages it generates. But if you receive a packet that is missing the object, you should not reject the message unless your implementation is unable to process the tear without it. -- David From owner-mpls@UU.NET Wed Jun 6 18:32:04 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10034 for ; Wed, 6 Jun 2001 18:32:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkshm03152; Wed, 6 Jun 2001 22:30:10 GMT Received: by mail-control.mail.uu.net id QQkshl09220 for mpls-outgoing; Wed, 6 Jun 2001 22:29:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkshl09208 for ; Wed, 6 Jun 2001 22:29:27 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 QQkshl02054 for ; Wed, 6 Jun 2001 22:28:30 GMT Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkshl01369 for ; Wed, 6 Jun 2001 22:28:30 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA12690 for ; Wed, 6 Jun 2001 18:25:16 -0400 (EDT) Subject: opaque object ---an extra object field To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Wed, 6 Jun 2001 18:25:15 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 06/06/2001 06:25:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk >This rule should be followed for all unsupported object classes, even if >there is an IANA assignment for that class number >-- David I agree with it. I have question: The opaque object can be either the existing object of RSVP message with unknown class/c-type, or an extra object in any RSVP message content as an unrecognized object(rfc 2205, section 3.10). Am I right? If it is right, I suggest to put this opaque object inside the Path/Resv message field in the rsvp-te draft. Thanks, Julia LDP Hello wrote: > > I agree with Adrian. > > http://www.iana.org/assignments/rsvp-parameters > explains all the unassigned Classes for RSVP. > > Any Object with unassigned or unknown Class number > must be considered Opaque Object and must be treated > according to RFC2205's section 3.10. ie must be > rejected if the class is 0bbbbbbb, ignore silently if > class is 10bbbbbb and ignore but forward if 11bbbbbb. From owner-mpls@UU.NET Wed Jun 6 18:57:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10236 for ; Wed, 6 Jun 2001 18:57:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkshn08596; Wed, 6 Jun 2001 22:56:17 GMT Received: by mail-control.mail.uu.net id QQkshn11774 for mpls-outgoing; Wed, 6 Jun 2001 22:55:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkshn11765 for ; Wed, 6 Jun 2001 22:55: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 QQkshn29484 for ; Wed, 6 Jun 2001 22:55:25 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 QQkshn07629 for ; Wed, 6 Jun 2001 22:55:25 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 SAA24268 for ; Wed, 6 Jun 2001 18:55:22 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA21336 for ; Wed, 6 Jun 2001 18:55:24 -0400 (EDT) Message-ID: <3B1EB4D4.944E0264@marconi.com> Date: Wed, 06 Jun 2001 18:55:16 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: opaque object ---an extra object field References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > I have question: The opaque object can be either the existing > object of RSVP message with unknown class/c-type, or an extra > object in any RSVP message content as an unrecognized object(rfc > 2205, section 3.10). Am I right? If it is right, I suggest to put > this opaque object inside the Path/Resv message field in the > rsvp-te draft. If it an unknown C-Type of a known class, you have no choice but to reject the entire message with a PathErr/ResvErr. If it is an unknown class, then you follow section 3.10. There is no difference between "unknown class" and "extra object". If you're asking about where in the sequence of objects you should put unknown objects, I don't think it should matter. There are very few rules regarding object ordering. The only hard ones that I can think of are: - INTEGRITY, if used, must come immediately after the common header, and before everything else. - Each flow descriptor that has FLOWSPEC must begin with that FLOWSPEC. - Each flow descriptor that does not have a FLOWSPEC must begin with the FILTERSPEC. - The list of flow descriptors must follow the STYLE object. Within these rules, I think you're pretty must free to put unknown objects wherever you like. Personally, I think the best place to put unknown objects when forwarding them is: - In Path messages, immediately before the sender descriptor - In Resv messages, immediately before the STYLE object But I don't think there is any rule, as long as the resulting message doesn't violate any existing object-ordering rules. -- David From owner-mpls@UU.NET Wed Jun 6 23:25:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14500 for ; Wed, 6 Jun 2001 23:25:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksif26068; Thu, 7 Jun 2001 03:25:19 GMT Received: by mail-control.mail.uu.net id QQksif17199 for mpls-outgoing; Thu, 7 Jun 2001 03:24:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksif17180 for ; Thu, 7 Jun 2001 03: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 QQksif05121 for ; Thu, 7 Jun 2001 03:23:34 GMT Received: from localhost.localdomain by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksif17747 for ; Thu, 7 Jun 2001 03:23:31 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f573QNq07822; Thu, 7 Jun 2001 08:56:24 +0530 Date: Thu, 7 Jun 2001 08:56:23 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: Abhijit Gadgil cc: Nagendra Singh Tomar , Osama Farrag , "Choudhury, Sanjaya" , mpls@UU.NET Subject: RE: Few questions related to LDP In-Reply-To: Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 6 Jun 2001, Abhijit Gadgil wrote: > >Abhijit, > > If there is an FTN entry in R2 that matches FEC1 then R2 _will_ > >insert labelled traffic, BUT in that case the statement that R2 is _not_ > >ingress for FEC1 is _not_ correct. > > If R2 does not recognize the FEC1, then when it receives label request > for that FEC1, it will respond with "No Route" notification. So there is > every reason to assume R2 has the FEC1 entry in its routing table. I think you missed the keyword "exactly" in the definition of an ingress node. Assume that the FEC in question is 144.16.72.0/24 . Suppose R1 requests a label mapping for this FEC from R2, and suppose that the entry in R2 routing table is 144.16.0.0./16 for which the nexthop is R3. Note that here R2's routing table has an entry that suggests reachability to FEC 144.16.72.0/24 (hence it won't send a NO ROUTE notification) but since the routing table entry does not _exactly_ match the FEC, R2 will _not_ install an FTN entry for FEC 144.16.72.0/24 (after it gets a mapping from R3) and hence it will not be an ingress for that FEC. -- tomar > So it > can potentially become _ingress_ for the FEC1. So it does not stop R2 > from putting packets on the LSP. The fact that whether it can do so or > not is more of implementation choice. > > Any LSR which can receive unlabeled packet and can forward it can become > _ingress_. > > -abhijit > > > > Only if R2 is an ingress LSR for FEC1 will it install such an FTN > >entry. To understand how it is known whether an LSR is ingress for an FEC > >refer section 3.5.7.1 RFC 3036. In short an LSR is ingress for an FEC iff > >there is a routing tabel entry that exactly matches that FEC. > > > >cheers > >tomar > > > > > >On Wed, 6 Jun 2001, Abhijit Gadgil wrote: > > > >> > >> sorry for a lateish reply.. > >> > >> please follow inline.. > >> > >> > > >> >Unlabelled IP Traffic Matching FEC in your example, will not be mapped into > >> >the LDP LSP by R2, It should not be inserted by R2. > >> > >> Why is it so? As per my understanding, R2 can insert traffic on to the > >> LSP, if it has an entry in the FTN points to the NHLFE that corrosponds > >> to ILM for labelled packets that arrive from R1. (Assuming R2 merge > >> capable). If it is not, it may request a label for traffic arriving on > >> the interface to R4. > >> > >> Is it not a question of whether an implementation can do it, than whether > >> standards support it? > >> > >> regards, > >> > >> -abhijit > >> > >> > > >> > Q3. If an LSR is _not_ an ingress for a FEC, can unlabelled IP > >> > traffic (matching the FEC) be mapped into the LDP LSP corresponding > >> > to the above mentioned FEC ? > >> > For example: > >> > R1-----(FEC1 = L1) ------R2-------(FEC1 = L2)------R3 > >> > | > >> > | > >> > R4 > >> > > >> > R1: ingress for FEC1, R3: egress for FEC1 > >> > > >> > Can/Should unlabelled IP traffic arriving at R2 (from R4 and > >> >matching > >> > prefix) be "inserted" into the LSP _transiting_ through it ? > >> > > > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Thu Jun 7 00:18:52 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15320 for ; Thu, 7 Jun 2001 00:18:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksij24275; Thu, 7 Jun 2001 04:18:32 GMT Received: by mail-control.mail.uu.net id QQksij12365 for mpls-outgoing; Thu, 7 Jun 2001 04:18:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksij12350 for ; Thu, 7 Jun 2001 04:17:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQksij29070 for ; Thu, 7 Jun 2001 04:17:29 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQksij17290 for ; Thu, 7 Jun 2001 04:17:29 GMT Received: (qmail 2167 invoked from network); 7 Jun 2001 04:10:01 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 7 Jun 2001 04:10:01 -0000 Received: from gayatri.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id JAA02939; Thu, 7 Jun 2001 09:47:25 +0530 (IST) Received: from localhost (gabhijit@localhost) by gayatri.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id EAA06952; Thu, 7 Jun 2001 04:58:57 +0530 X-Authentication-Warning: gayatri.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Thu, 7 Jun 2001 04:58:57 +0530 (IST) From: Abhijit Gadgil To: Nagendra Singh Tomar cc: Subject: RE: Few questions related to LDP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > >> >Abhijit, >> > If there is an FTN entry in R2 that matches FEC1 then R2 _will_ >> >insert labelled traffic, BUT in that case the statement that R2 is _not_ >> >ingress for FEC1 is _not_ correct. >> >> If R2 does not recognize the FEC1, then when it receives label request >> for that FEC1, it will respond with "No Route" notification. So there is >> every reason to assume R2 has the FEC1 entry in its routing table. > >I think you missed the keyword "exactly" in the definition of an ingress >node. Assume that the FEC in question is 144.16.72.0/24 . Suppose R1 >requests a label mapping for this FEC from R2, and suppose that the entry >in R2 routing table is 144.16.0.0./16 for which the nexthop is R3. Note >that here R2's routing table has an entry that suggests reachability to >FEC 144.16.72.0/24 (hence it won't send a NO ROUTE notification) but since >the routing table entry does not _exactly_ >match the FEC, R2 will _not_ install an FTN entry for FEC 144.16.72.0/24 >(after it gets a mapping from R3) and hence it will not be an ingress for >that FEC. > >-- tomar In this case R2 is acting _over-smart_ and shd be prepared for the consequences of doing so... When R2 receives a request for 144.16.72.0/24 and it has no entry in the routing table exactly matching 144.16.72.0/24 it MUST respond with a No Route Notification... (refer section 3.5.8 Label Request Procedures) So R2 can indeed send a mapping for 144.16.0.0/16 to R1 unsolicitedly. If R1 prefers to use it for 144.16.72.0/24 he's doing so at his own risk... So its implementation dependent. And there is nothing hard and fast that can prevent R2 from being ingress... In general there can be multiple ingress routers for a given FEC. This is how multi-point to point LSPs can be created. The case being discussed here is precisely a case of multipoint to point LSP. -abhijit From owner-mpls@UU.NET Thu Jun 7 04:29:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01942 for ; Thu, 7 Jun 2001 04:29:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksja02951; Thu, 7 Jun 2001 08:30:07 GMT Received: by mail-control.mail.uu.net id QQksiz25738 for mpls-outgoing; Thu, 7 Jun 2001 08:29:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksiz25727 for ; Thu, 7 Jun 2001 08:29:27 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 QQksiz15307 for ; Thu, 7 Jun 2001 08:29:12 GMT Received: from aeon.barak.net.il by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.150.150.30]) id QQksiz01900 for ; Thu, 7 Jun 2001 08:29:10 GMT Received: from mail.barak.net.il (mail6.barak.net.il [212.150.150.141]) by aeon.barak.net.il (8.11.1/8.11.1) with ESMTP id f578SHd26090 for ; Thu, 7 Jun 2001 11:28:17 +0300 (IDT) Received: from messenger.radlan.co.il ([209.88.194.205]) by mail.barak.net.il (8.11.2/8.9.1) with ESMTP id f578Sxf08951 for ; Thu, 7 Jun 2001 11:29:01 +0300 (IDT) Received: by MESSENGER with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 11:27:40 +0200 Message-ID: <42AB6BE23C29D511831E0002B320248827A169@MESSENGER> From: Ilan Yerushalmi To: "'mpls@UU.NET'" Subject: Label space for Ethernet Date: Thu, 7 Jun 2001 11:26:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: owner-mpls@UU.NET Precedence: bulk Hi all, Is it possible for an upstream LSR to advertise its Ethernet supported label range? Thank you, Ilan From owner-mpls@UU.NET Thu Jun 7 10:04:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07587 for ; Thu, 7 Jun 2001 10:04:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksjw20253; Thu, 7 Jun 2001 14:02:38 GMT Received: by mail-control.mail.uu.net id QQksjw08159 for mpls-outgoing; Thu, 7 Jun 2001 14:01:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksjw07758 for ; Thu, 7 Jun 2001 14:01:28 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 QQksjv01947 for ; Thu, 7 Jun 2001 13:53:12 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQksjv12411 for ; Thu, 7 Jun 2001 13:53:11 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f57DrA901672 for ; Thu, 7 Jun 2001 06:53:10 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA23336 for mpls@uu.net; Thu, 7 Jun 2001 09:53:09 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkshx25463 for ; Thu, 7 Jun 2001 01:20: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 QQkshx00313 for ; Thu, 7 Jun 2001 01:20:14 GMT Received: from longmail2.lboard.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.109.116.89]) id QQkshx05287 for ; Thu, 7 Jun 2001 01:20:13 GMT Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 21:20:17 -0400 Message-ID: From: Ed Ellesson To: "'mpls@uu.net'" Cc: "'Wijnen, Bert (Bert)'" , "'Joel M. Halpern'" Subject: MPLS WG Notice: Policy Terminology Last Call is now complete Date: Wed, 6 Jun 2001 21:20:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, MPLS WG: We apologize to those of you who receive more than one copy of this notice. The extended working group last call is now completed, for the draft titled "Terminology" (draft-ietf-policy-terminology-03.txt), which is being re-titled as "Terminology for Policy-Based Management". This extended last call provided an opportunity for the following working groups to comment on the draft, and discuss proposed changes on the Policy Framework WG mailing list. Working groups participating in the extended working group last call for this draft: Policy DiffServ RAP IPSP SNMPCONF AAA AAAArch (IRTF) RSVP MPLS Comments resulting from this extended multiple working group last call were discussed and accepted on the policy framework working group mailing list. The document will be revised in accordance with the results of that discussion. The Policy Framework working group will then submit it to the IESG to request their review and approval for publication as an Informational RFC. Thanks to all of you who participated in this successful extended working group last call, and a special thanks to Andrea Westerinen, who edited the draft, engaged in the discussion of the comments, and who will update it per the discussion results. Ed Ellesson, with Joel Halpern, Co-chairs, Policy Framework WG From owner-mpls@UU.NET Thu Jun 7 10:05:21 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07606 for ; Thu, 7 Jun 2001 10:05:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksjw10142; Thu, 7 Jun 2001 14:03:57 GMT Received: by mail-control.mail.uu.net id QQksjw08351 for mpls-outgoing; Thu, 7 Jun 2001 14:02:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksjw08323 for ; Thu, 7 Jun 2001 14:01:57 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 QQksjv13532 for ; Thu, 7 Jun 2001 13:53:29 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 QQksjv10655 for ; Thu, 7 Jun 2001 13:53:28 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f57DrR901825 for ; Thu, 7 Jun 2001 06:53:27 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA23340 for mpls@uu.net; Thu, 7 Jun 2001 09:53:26 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksjh16287 for ; Thu, 7 Jun 2001 10:25: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 QQksjh14685 for ; Thu, 7 Jun 2001 10:24:21 GMT Received: from exchange.exbit.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: test.exbit.com [213.129.28.92]) id QQksjh15599 for ; Thu, 7 Jun 2001 10:24:20 GMT content-class: urn:content-classes:message Subject: Multicast MPLS and DMAC address Date: Thu, 7 Jun 2001 12:24:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <83086B3515097D41B082FFB5909214371BA686@exchange.exbit.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: Multicast MPLS and DMAC address Thread-Index: AcDvO/gEOvSAB7X4SRqBfQvDT4rW5g== From: "Morten J. Christensen" To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA07606 Hi all, In IP multicast there is a mapping between IP multicast addresses and multicast MAC addresses. I have not seen any documents dealing with mapping MPLS multicast labels to ethernet DMAC addresses. I suppose that this means that both for unicast and multicast the DMAC address of the ethernet frame is the next-hop MPLS router. Can anyone confirm this? Im sure this has been discussed earlier but I was unable to find a thread covering the subject. Any respone will be appreciated. Morten Jagd Christensen From owner-mpls@UU.NET Thu Jun 7 10:07:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07671 for ; Thu, 7 Jun 2001 10:07:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksjw11754; Thu, 7 Jun 2001 14:05:20 GMT Received: by mail-control.mail.uu.net id QQksjw08445 for mpls-outgoing; Thu, 7 Jun 2001 14:02:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksjw08324 for ; Thu, 7 Jun 2001 14:01: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 QQksjv13718 for ; Thu, 7 Jun 2001 13:53:53 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQksjv13103 for ; Thu, 7 Jun 2001 13:53:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f57Drs902034 for ; Thu, 7 Jun 2001 06:53:54 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA23344 for mpls@uu.net; Thu, 7 Jun 2001 09:53:49 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksjr08280 for ; Thu, 7 Jun 2001 12:52: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 QQksjr09695 for ; Thu, 7 Jun 2001 12:45:55 GMT Received: from piorun.ds.pg.gda.pl by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: piorun.ds.pg.gda.pl [213.192.76.1]) id QQksjr03322 for ; Thu, 7 Jun 2001 12:45:40 GMT Received: from localhost (maks@localhost) by piorun.ds.pg.gda.pl (8.11.4/8.11.4) with ESMTP id f57CkSu05819; Thu, 7 Jun 2001 14:46:29 +0200 Date: Thu, 7 Jun 2001 14:46:27 +0200 (CEST) From: Maks Milkowski To: Jeff Parker cc: Subject: RE: ATM QoS classes in MPLS (?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 6 Jun 2001, Jeff Parker wrote: > Suppose you book first class passage on > an ocean liner, with a suite. What happens to your > reservation if you find that your transport has been > changed to air rather than sea? Correct me if I'm wrong, bu tin 'pure' ATM networks and MPLS implemented on ATM networks transport is the same - ATM cells > The problem of mapping between different models of service > is not an easy one. That's obvious; but I'd like to know how it is solved in MPLS Maks Milkowski From owner-mpls@UU.NET Thu Jun 7 10:31:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08051 for ; Thu, 7 Jun 2001 10:31:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksjy20927; Thu, 7 Jun 2001 14:30:19 GMT Received: by mail-control.mail.uu.net id QQksjx27346 for mpls-outgoing; Thu, 7 Jun 2001 14:29:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksjx27309 for ; Thu, 7 Jun 2001 14:29: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 QQksjx29517 for ; Thu, 7 Jun 2001 14:26:08 GMT Received: from p-mail1.cnet.fr by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail1.rd.francetelecom.fr [193.49.124.31]) id QQksjx03233 for ; Thu, 7 Jun 2001 14:26:07 GMT Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 16:25:47 +0200 Message-ID: <98388C05D464D111B61800805F150416029AB368@p-ibis.rd.francetelecom.fr> From: zze-PELLE Thierry StagiaireFTRD/DAC/ISS To: "'mpls@uu.net'" Subject: LDP Specification question : Receive Label Mapping Message Date: Thu, 7 Jun 2001 16:25:47 +0200 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 Hi, I can't manage to understand steps LMp.28 & LMp.29 (RFC 3036 Annex A, p 103-104) : 1)If there is a pending request, the LMp.29 is executed, but in case of "DU", there is a test "If no pending request..." 2)Does it means that even in case of "DU Independant", labels may not be distributed to peers... (because of LMp.28)?????? Thanks for help, Thierry From owner-mpls@UU.NET Thu Jun 7 12:03:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09334 for ; Thu, 7 Jun 2001 12:03:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkske09498; Thu, 7 Jun 2001 16:02:14 GMT Received: by mail-control.mail.uu.net id QQkske01884 for mpls-outgoing; Thu, 7 Jun 2001 16:01:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkske01725 for ; Thu, 7 Jun 2001 16:01:31 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 QQkskc06898 for ; Thu, 7 Jun 2001 15:37:21 GMT Received: from zcars0m9.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQkskc08573 for ; Thu, 7 Jun 2001 15:37:20 GMT Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f57FbAE12743 for ; Thu, 7 Jun 2001 11:37:10 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 7 Jun 2001 11:37:00 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 11:37:09 -0400 Message-ID: <6DDA62170439D31185750000F80826AC064E683F@zmerd004.ca.nortel.com> From: "David Allan" To: neil.2.harrison@bt.com, yakov@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Cc: eric.gray@sandburst.com Subject: RE: GMPLS Last Calls Date: Thu, 7 Jun 2001 11:36:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EF67.A7998520" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EF67.A7998520 Content-Type: text/plain; charset="ISO-8859-1" Neil, you wrote - LDP induced LSPs do not really create a layer network.....since they allow merging, and this in itself causes some hard QoS problems....like how does one define availability in a mpt-pt tree? [Its the old issue of 'no free lunch'...if you push down a problem in 1 dimension (eg scalability), it creates a problem somewhere else (eg measuing availability in VPNs say)]; - Explicitly routed LSPs on the other hand do form true layer networks....since they need to be signalled they exist as true trail objects in their own right. I'm not sure the existence of merging or QoS is necessarily a criteria for excluding LDP "induced" LSPs as a layer. Intuitively it strikes me that for the purposes of MPLS a layer can exist independently of which subset of topological constructs in the architecture toolkit it subscribes to. ER-LSPs overlaid on an LDP infrastructre using integrated routing to me would constitute a useful definition of a "layer". It is only when I ruthlessly exclude absolutely everything but the elemental p2p undirectional trail from the discussion that such a hard definition applies, unfortunatley much of the value statements around MPLS disappear at roughly the same time. cheers Dave ------_=_NextPart_001_01C0EF67.A7998520 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: GMPLS Last Calls

Neil, you wrote

-       LDP induced = LSPs do not really create a layer network.....since they
allow merging, and this in itself causes some hard = QoS problems....like how
does one define availability in a mpt-pt tree?  = [Its the old issue of 'no
free lunch'...if you push down a problem in 1 = dimension (eg scalability), it
creates a problem somewhere else (eg measuing = availability in VPNs say)];
-       Explicitly = routed LSPs on the other hand do form true layer
networks....since they need to be signalled they = exist as true trail objects
in their own right.

I'm not sure the existence of merging or QoS is = necessarily a criteria for excluding LDP "induced" LSPs as a = layer. Intuitively it strikes me that for the purposes of MPLS a layer = can exist independently of which subset of topological constructs in = the architecture toolkit it subscribes to. ER-LSPs overlaid on an LDP = infrastructre using integrated routing to me would constitute a useful = definition of a "layer". It is only when I ruthlessly exclude = absolutely everything but the elemental  p2p undirectional trail = from the discussion that such a hard definition applies, unfortunatley = much of the value statements around MPLS disappear at roughly the same = time.

cheers
Dave

------_=_NextPart_001_01C0EF67.A7998520-- From owner-mpls@UU.NET Thu Jun 7 12:39:10 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10039 for ; Thu, 7 Jun 2001 12:39:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkskg17421; Thu, 7 Jun 2001 16:37:38 GMT Received: by mail-control.mail.uu.net id QQkskg20877 for mpls-outgoing; Thu, 7 Jun 2001 16:37:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkskg20870 for ; Thu, 7 Jun 2001 16:37:01 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 QQkskg26842 for ; Thu, 7 Jun 2001 16:35:43 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkskg15275 for ; Thu, 7 Jun 2001 16:35:42 GMT Received: from chqlubnt02.lon.bt.com by gollum (local) with ESMTP; Thu, 7 Jun 2001 17:34:56 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 7 Jun 2001 17:34:43 +0100 Message-ID: To: dallan@nortelnetworks.com, yakov@juniper.net, mpls@UU.NET, ccamp@ops.ietf.org Cc: eric.gray@sandburst.com Subject: RE: GMPLS Last Calls Date: Thu, 7 Jun 2001 17:34:44 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Dave.....I know exactly what you are saying and its something Andy Reid and I have chewed over once or twice when considering a functional architecture description of MPLS. I was certainly not exhaustive nor precise in my description and definitions....I was more interested in trying to emphasise the 'no free lunch' point that making one aspect simpler usually makes some aspect more complex (normal engineering trade-off). I see 2 basic forms of MPLS LSPs: 1 One that is a close adjunct function of the IGP.....this is LDP LSPs, and LDP is required since one cannot easily distribute labels piggy-backed on a link-state routing protocol like OSPF (though you can with BGP). 2 One that is not a close adjunct function of the IGP, and requires to be signalled....this is RSVP-TE and CR-LDP LSPs. The 'no free lunch' bit here means the former gives an operator more headaches when considering fault-management and the definition of SLAs for VPN services for example, whilst potentially getting some gains in scalability......so that's the trade off I was inferring. Its a bit like the polarised CO vs CNLS transfer mode view of the world.....in reality technologies fall some-way between the 2 pure extremes, and its knowing where the compromises should occur for a given (service) case.....since neither alone can yield an optimum solution for all cases. Indeed, one could say this is exactly why we have/need MPLS to augment IP. Neil -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: 07 June 2001 16:37 To: neil.2.harrison@bt.com; yakov@juniper.net; mpls@UU.NET; ccamp@ops.ietf.org Cc: eric.gray@sandburst.com Subject: RE: GMPLS Last Calls Neil, you wrote - LDP induced LSPs do not really create a layer network.....since they allow merging, and this in itself causes some hard QoS problems....like how does one define availability in a mpt-pt tree? [Its the old issue of 'no free lunch'...if you push down a problem in 1 dimension (eg scalability), it creates a problem somewhere else (eg measuing availability in VPNs say)]; - Explicitly routed LSPs on the other hand do form true layer networks....since they need to be signalled they exist as true trail objects in their own right. I'm not sure the existence of merging or QoS is necessarily a criteria for excluding LDP "induced" LSPs as a layer. Intuitively it strikes me that for the purposes of MPLS a layer can exist independently of which subset of topological constructs in the architecture toolkit it subscribes to. ER-LSPs overlaid on an LDP infrastructre using integrated routing to me would constitute a useful definition of a "layer". It is only when I ruthlessly exclude absolutely everything but the elemental p2p undirectional trail from the discussion that such a hard definition applies, unfortunatley much of the value statements around MPLS disappear at roughly the same time. cheers Dave From owner-mpls@UU.NET Thu Jun 7 13:37:56 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11233 for ; Thu, 7 Jun 2001 13:37:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkskk18884; Thu, 7 Jun 2001 17:36:34 GMT Received: by mail-control.mail.uu.net id QQkskk16838 for mpls-outgoing; Thu, 7 Jun 2001 17:35:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkskk16827 for ; Thu, 7 Jun 2001 17:35:52 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 QQkskk10672 for ; Thu, 7 Jun 2001 17:34:47 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.227.9.200]) id QQkskk05550 for ; Thu, 7 Jun 2001 17:34:43 GMT Received: from pluris.com (do101085.pluris.com [172.16.55.241]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA24355; Thu, 7 Jun 2001 10:27:59 -0700 (PDT) Message-ID: <3B1FB99F.C8D6C9FC@pluris.com> Date: Thu, 07 Jun 2001 10:27:59 -0700 From: Chris Kuszmaul Organization: Pluris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Bartholomew CC: Eric Gray , MPLS Mailing List Subject: Re: LDP requires break-before-make References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Andrew: Please elaborate on the scenario you are thinking of --- is it like the following? B | A-C | D C and D each advertise mappings to A as and . Since A is non-label-merge-capable, it advertises and to B, and sets up label switching as labelC -> labelA1(forward to B) labelD-> labelA2 (forward to B) Well, this is how it might be if the spec did not say that the second mapping received would be ignored and released. CLK Andrew Bartholomew wrote: > Chris, > > If you consider the case that B is non-label-merge capable then A will > sometimes need to bind new labels to the FEC without withdrawing the > previous one. Such cases could make the update process much more > complicated (consider updating one of the labels bound to a FEC but not the > others). > > It seems to me as though there is a requirement for a transaction concept > similar to MEGACO H.248, where a single transaction contains a number of > separate actions, each comprising a set of commands that are executed > sequentially. Actions may be performed in any order but if a command within > an action fails, the action is aborted and the next action begun. > > regards, > Andrew > > -- > Andrew Bartholomew > > Layer 8 Consultancy Observa et sapiens cresces > Services Limited > > Tel: +44 1202 558409 > Fax: +44 1202 556748 > Email: Andrewb@layer8.co.uk > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Chris > > Kuszmaul > > Sent: 01 June 2001 17:59 > > To: Eric Gray > > Cc: MPLS Mailing List > > Subject: Re: LDP requires break-before-make > > > > > > Hi Eric > > > > I think you are right. Consider LSRs A and B. > > > > A sends to B the label mapping: > > > > There is nothing I am aware of in the spec that prevents A from > > sending another > > mapping, such as: > > , prior to receiving a label release (of label1) from B. > > > > What I was saying was that B had to release label1 (transmit a > > label release to A) > > before B could accept the mapping of label2. Your solution, of > > combining a label > > withdrawal (of label1) with the label mapping of label2, in a > > PDU, seems to basically > > make sense. > > > > The semantics of ordering is necessary, but not sufficient to > > prevent a break before > > make. I think there needs to be a sense of atomicity as well: > > Both the label > > withdrawal and the label mapping need to be done, or neither > > should be done. In > > particular, the label release message transmitted by B MUST be > > contemporaneous with > > the completion of the label mapping. The LDP spec does not > > *preclude* just such a > > behavior, and so a PDU containing a label withdrawal and a label > > mapping can be > > treated as a label-mapping-overwrite, without violating the spec, > > and thus preventing > > a break before make. > > > > CLK > > > > > > Eric Gray wrote: > > > > > Chris, > > > > > > I understand your concern. A few years ago (early '98) I had > > > proposed a semantic interpretation for LDP that directly related > > > to this. The response was to explicitly prohibit the behavior > > > which would have had this semantic. > > > > > > I had suggested that (in DU mode) an LSR that advertised a > > > new label for exactly the same FEC as it had previously advertised > > > a different label meant for the upstream LSR to replace the previous > > > label with the new one. Over time, I came to undestand why this > > > may have been a little too simplistic. Also, it may be needed when > > > DoD label advertisement is being used as well. > > > > > > I think your basic idea of using a new message type will work. > > > I had thought of that and talked with a couple of people on the LDP > > > design team about it - and they were not too receptive to the idea > > > as part of the base LDP specification (adds complexity not really > > > required for basic functionality). Also - at the time - I thought it > > > possible to achieve a very similar result by simply including both > > > the label withdraw and the new label mapping in the same PDU (an > > > LDP PDU can contain multiple LDP messages). > > > > > > Of course, this latter approach depends on a few things: > > > > > > o that you are not correct in your assertion that a > > downstream > > > LSR is required to wait for a label release > > message prior > > > to sending a new label mapping (*), > > > > > > o that an upstream LSR actually looks for a 'replacement' > > > label mapping message in a PDU that contains a label > > > withdraw message, > > > > > > o that this upstream LSR processes multiple messages in a > > > single PDU in the order in which they appear in the PDU > > > > > > and > > > > > > o that the dowbstream LSR put them in the PDU in the order > > > in which it expected them to be processed (+). > > > > > > * I think that the requirement is that the downstream LSR MUST > > > not re-use the same label until it receives a label > > release for a > > > label it has withdrawn. I do not think there is any > > statement in > > > the specification that prohibits sending a new label mapping > > > prior to receiving a label release for the previous mapping for > > > the same FEC. Please let me know if there is text in the spec > > > to the contrary. > > > > > > + Given that I am right in my interpretation of the current spec wrt > > > issuing a new label mapping after a label withdraw, the last two > > > bullets naturally fall out since the current > > restriction on sending > > > a new label mapping (with a different label) prior to > > withdrawing > > > a prior label mapping imposes an ordering resptriction on adding > > > messages to a PDU and processing them on receipt. This ordering > > > is not hard to achieve. > > > > > > Essentially, a downstream LSR can try this approach and hope that > > > the upstream LSR was built to be robust and resilient (either using the > > > approach above, or some other approach). > > > > > > -- > > > Eric Gray > > > > > > You wrote: > > > > > > > Before a label can be mapped to an FEC that has already been > > mapped, the LSR > > > > must release the old label (prompted perhaps by a withdrawal > > message). Thus, LDP > > > > calls for a break-before-make on LSP updates. It would seem > > a straightforward > > > > matter for the protocol to include a withdraw-and-map message > > that performs this > > > > sequence atomically, and so preserves a make-before-break condition. > > > > > > > > Is there some reason for not providing for this kind of > > functionality? > > > > > > > > Thanks for any comments. > > > > > > > > CLK > > > > > > > > PS: The careful reader will realize that I have mentioned > > this issue before in > > > > the thread [Re: Receive Label Receive !!], but have not seen > > any reply. This is > > > > an attempt to focus the question and broaden the pool of > > possible respondents. > > > > > > From owner-mpls@UU.NET Thu Jun 7 14:03:18 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11672 for ; Thu, 7 Jun 2001 14:03:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkskm02031; Thu, 7 Jun 2001 18:01:13 GMT Received: by mail-control.mail.uu.net id QQkskm22434 for mpls-outgoing; Thu, 7 Jun 2001 18:00:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkskm21844 for ; Thu, 7 Jun 2001 18:00:21 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 QQkskm14927 for ; Thu, 7 Jun 2001 18:00:04 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkskm18852 for ; Thu, 7 Jun 2001 18:00:01 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id B221A94006; Thu, 7 Jun 2001 13:59:55 -0400 (EDT) Message-ID: <3B1FC11B.B34857C1@sandburst.com> Date: Thu, 07 Jun 2001 13:59:55 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Abhijit Gadgil Cc: Nagendra Singh Tomar , mpls@UU.NET Subject: Re: Few questions related to LDP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Abhijit/Nagendra, Assume the simple topology - --- R1 --- R2 --- R3 --- R1 shows R2 as the nexthop for FEC p.q.r.0/24. R2 shows R3 as nexthop for FEC p.q.0.0/16. This is a de-personalized version of the scenario you are both working with. It is a little strange, because it would seem that R2 is not the next hop (from R1's perspective) for (p.q.0.0/16 - p.q.r.0/24) but this could be the case if the rest of the topology were shown. If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the IPv4 explicit NULL label (indicating that it will egress packets destined for addresses matching this FEC. In any case, R1's requesting a label R2 was not intended to cause R2 to ingress packets for this FEC (so an FTN would not be created for this FEC, but for different reasons than are indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and - possibly - assign those packets to an LSP corresponding to the FEC p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. -- Eric Gray Abhijit Gadgil wrote: > > > >> >Abhijit, > >> > If there is an FTN entry in R2 that matches FEC1 then R2 _will_ > >> >insert labelled traffic, BUT in that case the statement that R2 is _not_ > >> >ingress for FEC1 is _not_ correct. > >> > >> If R2 does not recognize the FEC1, then when it receives label request > >> for that FEC1, it will respond with "No Route" notification. So there is > >> every reason to assume R2 has the FEC1 entry in its routing table. > > > >I think you missed the keyword "exactly" in the definition of an ingress > >node. Assume that the FEC in question is 144.16.72.0/24 . Suppose R1 > >requests a label mapping for this FEC from R2, and suppose that the entry > >in R2 routing table is 144.16.0.0./16 for which the nexthop is R3. Note > >that here R2's routing table has an entry that suggests reachability to > >FEC 144.16.72.0/24 (hence it won't send a NO ROUTE notification) but since > >the routing table entry does not _exactly_ > >match the FEC, R2 will _not_ install an FTN entry for FEC 144.16.72.0/24 > >(after it gets a mapping from R3) and hence it will not be an ingress for > >that FEC. > > > >-- tomar > > In this case R2 is acting _over-smart_ and shd be prepared for the > consequences of doing so... > > When R2 receives a request for 144.16.72.0/24 and it has no entry in the > routing table exactly matching 144.16.72.0/24 it MUST respond with a No > Route Notification... (refer section 3.5.8 Label Request Procedures) > So R2 can indeed send a mapping for 144.16.0.0/16 to R1 unsolicitedly. If > R1 prefers to use it for 144.16.72.0/24 he's doing so at his own > risk... So its implementation dependent. And there is nothing hard and > fast that can prevent R2 from being ingress... > > In general there can be multiple ingress routers for a given FEC. This is > how multi-point to point LSPs can be created. The case being discussed > here is precisely a case of multipoint to point LSP. > > -abhijit From owner-mpls@UU.NET Thu Jun 7 14:05:35 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11739 for ; Thu, 7 Jun 2001 14:05:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkskm21668; Thu, 7 Jun 2001 18:04:00 GMT Received: by mail-control.mail.uu.net id QQkskm26996 for mpls-outgoing; Thu, 7 Jun 2001 18:03:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkskm26619 for ; Thu, 7 Jun 2001 18:03:14 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 QQkskm28198 for ; Thu, 7 Jun 2001 18:03:06 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkskm22291 for ; Thu, 7 Jun 2001 18:03:06 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 340E394006; Thu, 7 Jun 2001 14:03:06 -0400 (EDT) Message-ID: <3B1FC1DA.65265FE9@sandburst.com> Date: Thu, 07 Jun 2001 14:03:06 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Ilan Yerushalmi Cc: "'mpls@UU.NET'" Subject: Re: Label space for Ethernet References: <42AB6BE23C29D511831E0002B320248827A169@MESSENGER> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ilan, There is no notion of 'supported label ranges' for Ethernet and PPP. The downstream LSR distributes labels it can support and the upstream LSR must be able to attach any of these to packets asscoiated with the corresponding LSP. -- Eric Gray You wrote: > Hi all, > > Is it possible for an upstream LSR to advertise its Ethernet supported label range? > > Thank you, > Ilan From owner-mpls@UU.NET Thu Jun 7 15:55:18 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13382 for ; Thu, 7 Jun 2001 15:55:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkskt22591; Thu, 7 Jun 2001 19:51:29 GMT Received: by mail-control.mail.uu.net id QQkskt11645 for mpls-outgoing; Thu, 7 Jun 2001 19:50:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkskt11602 for ; Thu, 7 Jun 2001 19:50:33 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 QQkskt04838 for ; Thu, 7 Jun 2001 19:50:01 GMT Received: from exchange01.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.205.166.180]) id QQkskt20669 for ; Thu, 7 Jun 2001 19:50:00 GMT Received: from BLIULAPTOP ([64.47.72.62]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 7 Jun 2001 15:46:03 -0400 Message-ID: <002801c0ef8a$d4bf8360$a503893e@movaz.com> From: "Adrian Farrel" To: "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-ldp-ft-02.txt Date: Thu, 7 Jun 2001 15:48:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C0EF69.4ADFA830" 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: 07 Jun 2001 19:46:05.0771 (UTC) FILETIME=[7D9361B0:01C0EF8A] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C0EF69.4ADFA830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-send owing to flaky mail system. Apologies for double delivery. Adrian ----- Original Message -----=20 From: Adrian Farrel=20 To: mpl@uu.net=20 Cc: swallow@cisco.com=20 Sent: Tuesday, June 05, 2001 12:12 PM Subject: draft-ietf-mpls-ldp-ft-02.txt All,=20 The latest version of this draft can now be found at =20 http://search.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ft-02.txt This version contains a few minor updates and clarifications as a = result of the last call. The changes are summarized in section 0. of = the document. George, can we spin last call to cover the changes? Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ------=_NextPart_000_0025_01C0EF69.4ADFA830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-send owing to flaky mail system. Apologies for double delivery. Adrian
----- Original Message -----
From:=20 Adrian = Farrel=20
Sent: Tuesday, June 05, 2001 = 12:12=20 PM
Subject:=20 draft-ietf-mpls-ldp-ft-02.txt

All,
 
The latest version of this draft = can now be=20 found at
 
http://search.ietf.org/internet-drafts/draft-ietf-mpls-ldp-ft-02.txt=
 
This version contains a few minor = updates and=20 clarifications as a result of the last call.  The changes are = summarized=20 in section 0. of the document.
 
George, can we spin last call to = cover the=20 changes?
 
Adrian
--
Adrian Farrel
Movaz = Networks=20 Inc.
afarrel@movaz.com
------=_NextPart_000_0025_01C0EF69.4ADFA830-- From owner-mpls@UU.NET Fri Jun 8 00:29:22 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21210 for ; Fri, 8 Jun 2001 00:29:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmb25365; Fri, 8 Jun 2001 04:29:32 GMT Received: by mail-control.mail.uu.net id QQksmb05844 for mpls-outgoing; Fri, 8 Jun 2001 04:28:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmb05725 for ; Fri, 8 Jun 2001 04:28: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 QQksmb02829 for ; Fri, 8 Jun 2001 04:26:22 GMT From: Ashwinp@in.huawei.com Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQksmb21950 for ; Fri, 8 Jun 2001 04:26:21 GMT Received: by tor-cm1.cisco.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 09:59:20 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C568736E109@tor-cm1.cisco.com> To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RegardingTraffic parameters Date: Fri, 8 Jun 2001 09:59:19 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EFD7.C67EF4F0" 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_01C0EFD7.C67EF4F0 Content-Type: text/plain; charset="iso-8859-1" Hello all, Can any one tell me how the resource management traffic parameters are mapped to the actual link attributes? The link attributes only contains the baud rate. And the request for the resources contains five parameters like PDR, PBS, CDR, CBS, EBS. CDR commited data rate can be directly mapped to the available bandwidth on the link. But how to say that i can support you this much amount of PDR ? And even if i say that, as the number of reservations on the link increases the the PDR may change...... Please tell me how it works and also if any URL's/materials on it is welcomed. Thanks in advance Ashwin ------_=_NextPart_001_01C0EFD7.C67EF4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RegardingTraffic parameters

Hello all,

         &nb= sp;   Can any one tell me how the resource management traffic = parameters
         &nb= sp;   are mapped to the actual link attributes?
         &nb= sp;   The link attributes only contains the baud rate. And = the request for the
         &nb= sp;   resources contains five parameters like PDR, PBS, CDR, = CBS, EBS.
         &nb= sp;   CDR commited data rate can be directly mapped to the = available bandwidth
         &nb= sp;   on the link. But how to say that i can support you this = much amount of PDR ?
         &nb= sp;   And even if i say that, as the number of reservations = on the link increases the
         &nb= sp;   the PDR may change......
         &nb= sp;   Please tell me how it works and also if any = URL's/materials on it is welcomed.


Thanks in advance
Ashwin

------_=_NextPart_001_01C0EFD7.C67EF4F0-- From owner-mpls@UU.NET Fri Jun 8 00:46:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21401 for ; Fri, 8 Jun 2001 00:46:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmd13207; Fri, 8 Jun 2001 04:46:41 GMT Received: by mail-control.mail.uu.net id QQksmd11970 for mpls-outgoing; Fri, 8 Jun 2001 04:46:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmd11841 for ; Fri, 8 Jun 2001 04:46:00 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 QQksmd00802 for ; Fri, 8 Jun 2001 04:45:41 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQksmd12143 for ; Fri, 8 Jun 2001 04:45:40 GMT Received: (qmail 11848 invoked from network); 8 Jun 2001 04:38:14 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 8 Jun 2001 04:38:14 -0000 Received: from gayatri.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id KAA18026; Fri, 8 Jun 2001 10:16:31 +0530 (IST) Received: from localhost (gabhijit@localhost) by gayatri.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id FAA27718; Fri, 8 Jun 2001 05:28:08 +0530 X-Authentication-Warning: gayatri.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Fri, 8 Jun 2001 05:28:08 +0530 (IST) From: Abhijit Gadgil To: Eric Gray cc: Nagendra Singh Tomar , Subject: Re: Few questions related to LDP In-Reply-To: <3B1FC11B.B34857C1@sandburst.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Eric, If R2 is distributing bindings unsolicitedly, it will always distribute bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not have entry for that FEC in its routing table. And R2 can send Mapping for label request p.q.r.0/24 when it receives explicitely such request and in that case it MUST send a No Route Notification.(according to rfc3036 section 3.5.8).. I accept it is bit harsh on R2's part in doing so, but this is what the RFC says.... The original question was Whether R2 can put packets from some other guy R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out that no it can't do so. IMO R2 can do so.. whether it does or not is implementation choice and standards don't prevent that. > --- R1 --- R2 --- R3 --- | R4 > btw there is a syntax error in ur mail in follwing para. "No matching brackets". :-) regards, -abhijit >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the >IPv4 explicit NULL label (indicating that it will egress packets destined >for addresses matching this FEC. In any case, R1's requesting a label >R2 was not intended to cause R2 to ingress packets for this FEC (so an >FTN would not be created for this FEC, but for different reasons than are >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and >- possibly - assign those packets to an LSP corresponding to the FEC >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > >-- >Eric Gray From owner-mpls@UU.NET Fri Jun 8 01:09:07 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21777 for ; Fri, 8 Jun 2001 01:09:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksme10670; Fri, 8 Jun 2001 05:08:52 GMT Received: by mail-control.mail.uu.net id QQksme05181 for mpls-outgoing; Fri, 8 Jun 2001 05:08:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksme05139 for ; Fri, 8 Jun 2001 05:08:16 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 QQksme16375 for ; Fri, 8 Jun 2001 05:07:51 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksme06775 for ; Fri, 8 Jun 2001 05:07:49 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f58586Q02656; Fri, 8 Jun 2001 10:38:06 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A65.001AB585 ; Fri, 8 Jun 2001 10:21:44 +0530 X-Lotus-FromDomain: HSS To: Abhijit Gadgil cc: Eric Gray , Nagendra Singh Tomar , mpls@UU.NET Message-ID: <65256A65.001AB478.00@sandesh.hss.hns.com> Date: Fri, 8 Jun 2001 10:21:40 +0530 Subject: Re: Few questions related to LDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi abhijit! You are correct in your analysis of the problem (the one with R4 involved) but there is still a question that needs to be answered. for R2 to be able ro also accept unlabeled packets from R4 and put them on the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is the routing update received from R3 which is the next hop for p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to do traffic merging for two seperate FEC. This can be done but I guess then the intelligence will have to be explicit in terms of - to what level we want to do it (consider another p.0.0.0/8 entry in r2 routing table from a next hop R5 !). You are absolutely right that this is a local issue and does not need to be LSP wide as Eric pointed out that someone having a route to p.q.0.0/16 will surely have a route to p.q.r.0/24 (even if it might not be the best one ;o) regards sumit Abhijit Gadgil on 06/08/2001 05:28:08 AM To: Eric Gray cc: Nagendra Singh Tomar , mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: Re: Few questions related to LDP Eric, If R2 is distributing bindings unsolicitedly, it will always distribute bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not have entry for that FEC in its routing table. And R2 can send Mapping for label request p.q.r.0/24 when it receives explicitely such request and in that case it MUST send a No Route Notification.(according to rfc3036 section 3.5.8).. I accept it is bit harsh on R2's part in doing so, but this is what the RFC says.... The original question was Whether R2 can put packets from some other guy R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out that no it can't do so. IMO R2 can do so.. whether it does or not is implementation choice and standards don't prevent that. > --- R1 --- R2 --- R3 --- | R4 > btw there is a syntax error in ur mail in follwing para. "No matching brackets". :-) regards, -abhijit >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the >IPv4 explicit NULL label (indicating that it will egress packets destined >for addresses matching this FEC. In any case, R1's requesting a label >R2 was not intended to cause R2 to ingress packets for this FEC (so an >FTN would not be created for this FEC, but for different reasons than are >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and >- possibly - assign those packets to an LSP corresponding to the FEC >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > >-- >Eric Gray From owner-mpls@UU.NET Fri Jun 8 01:54:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24501 for ; Fri, 8 Jun 2001 01:54:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmh16950; Fri, 8 Jun 2001 05:54:31 GMT Received: by mail-control.mail.uu.net id QQksmh23427 for mpls-outgoing; Fri, 8 Jun 2001 05:53:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksmh23416 for ; Fri, 8 Jun 2001 05:53:50 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 QQksmh22626 for ; Fri, 8 Jun 2001 05:53:24 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksmh20991 for ; Fri, 8 Jun 2001 05:53:18 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f585s1I05135; Fri, 8 Jun 2001 11:24:01 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A65.001EE892 ; Fri, 8 Jun 2001 11:07:36 +0530 X-Lotus-FromDomain: HSS To: Ashwinp@in.huawei.com cc: mpls-ops@mplsrc.com, mpls@UU.NET Message-ID: <65256A65.001EE62F.00@sandesh.hss.hns.com> Date: Fri, 8 Jun 2001 11:07:27 +0530 Subject: Re: RegardingTraffic parameters Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=1Zzndhqpt8C3meOHpAB1wHpkHiMtoSdEvO6YuaRyZKJN05Pm4iqLuNLn" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=1Zzndhqpt8C3meOHpAB1wHpkHiMtoSdEvO6YuaRyZKJN05Pm4iqLuNLn Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi ashwini! As far as I know PDR is something you are not commiting . its something you say you might be able to give and hence it cannot be mapped to any QoS parameter for MPLS. If you exceed ur CDR then you are always eligible to be dropped. regards sumit Ashwinp@in.huawei.com on 06/08/2001 10:29:19 AM To: mpls-ops@mplsrc.com, mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: RegardingTraffic parameters Hello all, Can any one tell me how the resource management traffic parameters are mapped to the actual link attributes? The link attributes only contains the baud rate. And the request for the resources contains five parameters like PDR, PBS, CDR, CBS, EBS. CDR commited data rate can be directly mapped to the available bandwidth on the link. But how to say that i can support you this much amount of PDR ? And even if i say that, as the number of reservations on the link increases the the PDR may change...... Please tell me how it works and also if any URL's/materials on it is welcomed. Thanks in advance Ashwin --0__=1Zzndhqpt8C3meOHpAB1wHpkHiMtoSdEvO6YuaRyZKJN05Pm4iqLuNLn Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+UmVnYXJk aW5nVHJhZmZpYyBwYXJhbWV0ZXJzPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPEJSPg0KPEJS Pg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkhlbGxvIGFsbCw8L0ZPTlQ+DQo8L1A+ DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENhbiBhbnkg b25lIHRlbGwgbWUgaG93IHRoZSByZXNvdXJjZSBtYW5hZ2VtZW50IHRyYWZmaWMgcGFyYW1ldGVy cyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YXJlIG1hcHBlZCB0byB0aGUgYWN0dWFsIGxpbmsgYXR0cmlidXRlcz88L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGxpbmsgYXR0cmlidXRl cyBvbmx5IGNvbnRhaW5zIHRoZSBiYXVkIHJhdGUuIEFuZCB0aGUgcmVxdWVzdCBmb3IgdGhlIDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNv dXJjZXMgY29udGFpbnMgZml2ZSBwYXJhbWV0ZXJzIGxpa2UgUERSLCBQQlMsIENEUiwgQ0JTLCBF QlMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENEUiBjb21taXRlZCBkYXRhIHJhdGUgY2FuIGJlIGRpcmVjdGx5IG1hcHBlZCB0byB0aGUgYXZh aWxhYmxlIGJhbmR3aWR0aCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgb24gdGhlIGxpbmsuIEJ1dCBob3cgdG8gc2F5IHRoYXQgaSBjYW4gc3Vw cG9ydCB5b3UgdGhpcyBtdWNoIGFtb3VudCBvZiBQRFIgPzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbmQgZXZlbiBpZiBpIHNheSB0aGF0LCBh cyB0aGUgbnVtYmVyIG9mIHJlc2VydmF0aW9ucyBvbiB0aGUgbGluayBpbmNyZWFzZXMgdGhlIDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUg UERSIG1heSBjaGFuZ2UuLi4uLi48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUGxlYXNlIHRlbGwgbWUgaG93IGl0IHdvcmtzIGFuZCBhbHNvIGlm IGFueSBVUkwncy9tYXRlcmlhbHMgb24gaXQgaXMgd2VsY29tZWQuPC9GT05UPg0KPC9QPg0KPEJS Pg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRoYW5rcyBpbiBhZHZhbmNlPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QXNod2luPC9GT05UPg0KPC9QPg0KDQo8 L0JPRFk+DQo8L0hUTUw+DQo= --0__=1Zzndhqpt8C3meOHpAB1wHpkHiMtoSdEvO6YuaRyZKJN05Pm4iqLuNLn-- From owner-mpls@UU.NET Fri Jun 8 02:06:19 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAB02532 for ; Fri, 8 Jun 2001 02:06:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmi07222; Fri, 8 Jun 2001 06:06:01 GMT Received: by mail-control.mail.uu.net id QQksmi05182 for mpls-outgoing; Fri, 8 Jun 2001 06:05:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksmi05132 for ; Fri, 8 Jun 2001 06:05:08 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 QQksmi23748 for ; Fri, 8 Jun 2001 06:01:10 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQksmi24301 for ; Fri, 8 Jun 2001 06:01:08 GMT Received: (qmail 20093 invoked from network); 8 Jun 2001 05:53:42 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 8 Jun 2001 05:53:42 -0000 Received: from gayatri.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id LAA23858; Fri, 8 Jun 2001 11:31:54 +0530 (IST) Received: from localhost (gabhijit@localhost) by gayatri.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id GAA00738; Fri, 8 Jun 2001 06:43:36 +0530 X-Authentication-Warning: gayatri.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Fri, 8 Jun 2001 06:43:35 +0530 (IST) From: Abhijit Gadgil To: cc: Eric Gray , Nagendra Singh Tomar , Subject: Re: Few questions related to LDP In-Reply-To: <65256A65.001AB478.00@sandesh.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk sumit, If R2 has no entry for p.q.r.o/24, but for p.q.0.0/16 then I think following shd happen, almost like what Eric has pointed out. R1-R2 R2-R3 ( R2 is being a bit smart here) ======= ======= LSP1 LSP2 (p.q.r.0/24) (p.q.0.0/16) and not R1-R2-R3 =========== LSP (p.q.r.0/24) If indeed an LSP as in scenario 2 exist, R2 does have an entry for p.q.r.0/24 in its routing table and thus in every likelyhood the FTN entry . And then it _can_ put packets for p.q.r.0/24 on the part of the LSP beyond it. i.e. R2-R3, which come from R4. Am i missing something? -abhijit On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > You are correct in your analysis of the problem (the one with R4 >involved) but there is still a question that needs to be answered. for >R2 to be able ro also accept unlabeled packets from R4 and put them on >the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say >p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for >creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is >the routing update received from R3 which is the next hop for >p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to >do traffic merging for two seperate FEC. This can be done but I guess >then the intelligence will have to be explicit in terms of - to what >level we want to do it (consider another p.0.0.0/8 entry in r2 routing >table from a next hop R5 !). You are absolutely right that this is a >local issue and does not need to be LSP wide as Eric pointed out that >someone having a route to p.q.0.0/16 will surely have a route to >p.q.r.0/24 (even if it might not be the best one ;o) > >regards >sumit From owner-mpls@UU.NET Fri Jun 8 02:07:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02613 for ; Fri, 8 Jun 2001 02:07:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmi03747; Fri, 8 Jun 2001 06:07:35 GMT Received: by mail-control.mail.uu.net id QQksmi08919 for mpls-outgoing; Fri, 8 Jun 2001 06:07:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmi08771 for ; Fri, 8 Jun 2001 06:06:56 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 QQksmi27129 for ; Fri, 8 Jun 2001 06:06:47 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksmi02869 for ; Fri, 8 Jun 2001 06:06:40 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5866tc05519; Fri, 8 Jun 2001 11:36:55 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A65.00201657 ; Fri, 8 Jun 2001 11:20:28 +0530 X-Lotus-FromDomain: HSS To: Abhijit Gadgil cc: Eric Gray , Nagendra Singh Tomar , mpls@UU.NET Message-ID: <65256A65.0020148C.00@sandesh.hss.hns.com> Date: Fri, 8 Jun 2001 11:20:21 +0530 Subject: Re: Few questions related to LDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi abhijit! that is eaxctly what I was pointing at and the key thing here is that you are making R2 "smarter" and the real question would be what level of smartness should it have in order to be able to induce such a setup. another key thing would be that this may not scale to all QoS requirements of a network when we intend to use MPLS for that rather than just hope-by-hope forwarding. ciao sumit Abhijit Gadgil on 06/08/2001 06:43:35 AM To: Sumit Chauhan/HSS@HSS cc: Eric Gray , Nagendra Singh Tomar , mpls@UU.NET Subject: Re: Few questions related to LDP sumit, If R2 has no entry for p.q.r.o/24, but for p.q.0.0/16 then I think following shd happen, almost like what Eric has pointed out. R1-R2 R2-R3 ( R2 is being a bit smart here) ======= ======= LSP1 LSP2 (p.q.r.0/24) (p.q.0.0/16) and not R1-R2-R3 =========== LSP (p.q.r.0/24) If indeed an LSP as in scenario 2 exist, R2 does have an entry for p.q.r.0/24 in its routing table and thus in every likelyhood the FTN entry . And then it _can_ put packets for p.q.r.0/24 on the part of the LSP beyond it. i.e. R2-R3, which come from R4. Am i missing something? -abhijit On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > You are correct in your analysis of the problem (the one with R4 >involved) but there is still a question that needs to be answered. for >R2 to be able ro also accept unlabeled packets from R4 and put them on >the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say >p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for >creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is >the routing update received from R3 which is the next hop for >p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to >do traffic merging for two seperate FEC. This can be done but I guess >then the intelligence will have to be explicit in terms of - to what >level we want to do it (consider another p.0.0.0/8 entry in r2 routing >table from a next hop R5 !). You are absolutely right that this is a >local issue and does not need to be LSP wide as Eric pointed out that >someone having a route to p.q.0.0/16 will surely have a route to >p.q.r.0/24 (even if it might not be the best one ;o) > >regards >sumit From owner-mpls@UU.NET Fri Jun 8 03:22:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07047 for ; Fri, 8 Jun 2001 03:22:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmn11829; Fri, 8 Jun 2001 07:22:24 GMT Received: by mail-control.mail.uu.net id QQksmn11919 for mpls-outgoing; Fri, 8 Jun 2001 07:21:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmn11898 for ; Fri, 8 Jun 2001 07:21:30 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 QQksmn12231 for ; Fri, 8 Jun 2001 07:20:49 GMT Received: from localhost.localdomain by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksmn10274 for ; Fri, 8 Jun 2001 07:20:46 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f587NRq13936; Fri, 8 Jun 2001 12:53:30 +0530 Date: Fri, 8 Jun 2001 12:53:26 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: Abhijit Gadgil cc: suchauhan@hss.hns.com, Eric Gray , Nagendra Singh Tomar , mpls@UU.NET Subject: Re: Few questions related to LDP In-Reply-To: Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Fri Jun 8 03:59:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07358 for ; Fri, 8 Jun 2001 03:59:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmp19012; Fri, 8 Jun 2001 07:59:15 GMT Received: by mail-control.mail.uu.net id QQksmp15822 for mpls-outgoing; Fri, 8 Jun 2001 07:58:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmp15803 for ; Fri, 8 Jun 2001 07:58:27 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 QQksmp05926 for ; Fri, 8 Jun 2001 07:56:51 GMT Received: from localhost.localdomain by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksmp14136 for ; Fri, 8 Jun 2001 07:56:47 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f587x3q14047; Fri, 8 Jun 2001 13:29:03 +0530 Date: Fri, 8 Jun 2001 13:29:02 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: Abhijit Gadgil cc: suchauhan@hss.hns.com, Eric Gray , Nagendra Singh Tomar , mpls@UU.NET Subject: Re: Few questions related to LDP In-Reply-To: Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Abhijit! Ur proposition leads to a couple of new questions. Assume that R2 has no entry for p.q.r.o/24, but for p.q.0.0/16, then according to ur proposition R2 will terminate the LSP (LSP1) i.e it will act as an egress for LSP1, and from R2 to R3 it will initiate a new LSP (LSP2) which will be for FEC p.q.0.0/16 unlike LSP1 which is for p.q.r.0/24. The question is why will R2 act as an egress for FEC p.q.r.0/24 (Refer 4.1.4 RFC 3032 for exact definition of an egress node), LRq.9 point #1 for DU/DoD Ordered control checks for egress, if the node is not egress for FEC it sends a label request for the same FEC (p.q.r.0/24) to the nexthop for that FEC (I assume that this nexthop is found by doing a longest prefix match in the routing table). A router is egress for an FEC if it is acting as a "deaggregation" point that is its routing table has more precise entries NOT when it is acting as an "aggregation" point i.e its routing table has less precise entries ( as is the case we are discussing) regards tomar On Fri, 8 Jun 2001, Abhijit Gadgil wrote: > sumit, > > If R2 has no entry for p.q.r.o/24, but for p.q.0.0/16 then I think > following shd happen, almost like what Eric has pointed out. > > R1-R2 R2-R3 ( R2 is being a bit smart here) > ======= ======= > LSP1 LSP2 > (p.q.r.0/24) (p.q.0.0/16) > > and not > > R1-R2-R3 > =========== > LSP > (p.q.r.0/24) > > If indeed an LSP as in scenario 2 exist, R2 does have an entry for > p.q.r.0/24 in its routing table and thus in every likelyhood the FTN entry > . And then it _can_ put packets for p.q.r.0/24 on the part of the LSP > beyond it. i.e. R2-R3, which come from R4. > > Am i missing something? > > -abhijit > > On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > > > You are correct in your analysis of the problem (the one with R4 > >involved) but there is still a question that needs to be answered. for > >R2 to be able ro also accept unlabeled packets from R4 and put them on > >the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say > >p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for > >creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is > >the routing update received from R3 which is the next hop for > >p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to > >do traffic merging for two seperate FEC. This can be done but I guess > >then the intelligence will have to be explicit in terms of - to what > >level we want to do it (consider another p.0.0.0/8 entry in r2 routing > >table from a next hop R5 !). You are absolutely right that this is a > >local issue and does not need to be LSP wide as Eric pointed out that > >someone having a route to p.q.0.0/16 will surely have a route to > >p.q.r.0/24 (even if it might not be the best one ;o) > > > >regards > >sumit > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Fri Jun 8 04:11:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07506 for ; Fri, 8 Jun 2001 04:11:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmq03010; Fri, 8 Jun 2001 08:12:01 GMT Received: by mail-control.mail.uu.net id QQksmq06464 for mpls-outgoing; Fri, 8 Jun 2001 08:11:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmq06425 for ; Fri, 8 Jun 2001 08:11:11 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 QQksmq25073 for ; Fri, 8 Jun 2001 08:10:08 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksmq07089 for ; Fri, 8 Jun 2001 08:10:02 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5889uI12408; Fri, 8 Jun 2001 13:39:56 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A65.002B5AFA ; Fri, 8 Jun 2001 13:23:33 +0530 X-Lotus-FromDomain: HSS To: nagendras@netbrahma.com cc: Abhijit Gadgil , Eric Gray , Nagendra Singh Tomar , mpls@UU.NET Message-ID: <65256A65.002B5A07.00@sandesh.hss.hns.com> Date: Fri, 8 Jun 2001 13:23:29 +0530 Subject: Re: Few questions related to LDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk nagendra! pls find comments inline. regards sumit Nagendra Singh Tomar on 06/08/2001 01:29:02 PM Please respond to nagendras@netbrahma.com To: Abhijit Gadgil cc: Sumit Chauhan/HSS@HSS, Eric Gray , Nagendra Singh Tomar , mpls@UU.NET Subject: Re: Few questions related to LDP Abhijit! Ur proposition leads to a couple of new questions. Assume that R2 has no entry for p.q.r.o/24, but for p.q.0.0/16, then according to ur proposition R2 will terminate the LSP (LSP1) i.e it will act as an egress for LSP1, and from R2 to R3 it will initiate a new LSP (LSP2) which will be for FEC p.q.0.0/16 unlike LSP1 which is for p.q.r.0/24. The question is why will R2 act as an egress for FEC p.q.r.0/24 (Refer 4.1.4 RFC 3032 for exact definition of an egress node), ***sumit*** Its RFC 3031 ;o)) Anyhow nothing in the spec prevents R2 from being the egress as it satisfys the point 1 of the two conditions for being an Egress LSR as follows " 1. R has an address Y, such that X is the address prefix in R's routing table which is the longest match for Y, or" think of it also as a case where LSR R2 might have been at the edge of an MPLS domain. It is not neccessary that R2 is the absolute last router to the FEC address prefix for it to act as an LSR. *********** LRq.9 point #1 for DU/DoD Ordered control checks for egress, if the node is not egress for FEC it sends a label request for the same FEC (p.q.r.0/24) to the nexthop for that FEC (I assume that this nexthop is found by doing a longest prefix match in the routing table). ****sumit**** again the R2 shall be marked here as the egress for p.q.r.0/24 as part of the "smart" R2 action items. ************* A router is egress for an FEC if it is acting as a "deaggregation" point that is its routing table has more precise entries NOT when it is acting as an "aggregation" point i.e its routing table has less precise entries ( as is the case we are discussing) regards tomar On Fri, 8 Jun 2001, Abhijit Gadgil wrote: > sumit, > > If R2 has no entry for p.q.r.o/24, but for p.q.0.0/16 then I think > following shd happen, almost like what Eric has pointed out. > > R1-R2 R2-R3 ( R2 is being a bit smart here) > ======= ======= > LSP1 LSP2 > (p.q.r.0/24) (p.q.0.0/16) > > and not > > R1-R2-R3 > =========== > LSP > (p.q.r.0/24) > > If indeed an LSP as in scenario 2 exist, R2 does have an entry for > p.q.r.0/24 in its routing table and thus in every likelyhood the FTN entry > . And then it _can_ put packets for p.q.r.0/24 on the part of the LSP > beyond it. i.e. R2-R3, which come from R4. > > Am i missing something? > > -abhijit > > On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > > > You are correct in your analysis of the problem (the one with R4 > >involved) but there is still a question that needs to be answered. for > >R2 to be able ro also accept unlabeled packets from R4 and put them on > >the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say > >p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for > >creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is > >the routing update received from R3 which is the next hop for > >p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to > >do traffic merging for two seperate FEC. This can be done but I guess > >then the intelligence will have to be explicit in terms of - to what > >level we want to do it (consider another p.0.0.0/8 entry in r2 routing > >table from a next hop R5 !). You are absolutely right that this is a > >local issue and does not need to be LSP wide as Eric pointed out that > >someone having a route to p.q.0.0/16 will surely have a route to > >p.q.r.0/24 (even if it might not be the best one ;o) > > > >regards > >sumit > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Fri Jun 8 04:35:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07610 for ; Fri, 8 Jun 2001 04:35:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksms19587; Fri, 8 Jun 2001 08:35:31 GMT Received: by mail-control.mail.uu.net id QQksms09221 for mpls-outgoing; Fri, 8 Jun 2001 08:34:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksms09213 for ; Fri, 8 Jun 2001 08:34:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQksms11698 for ; Fri, 8 Jun 2001 08:34:54 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksms02249 for ; Fri, 8 Jun 2001 08:34:52 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f588ZG914035; Fri, 8 Jun 2001 14:05:16 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A65.002DAB46 ; Fri, 8 Jun 2001 13:48:49 +0530 X-Lotus-FromDomain: HSS To: Abhijit Gadgil , Eric Gray , mpls@UU.NET Message-ID: <65256A65.002DAA5C.00@sandesh.hss.hns.com> Date: Fri, 8 Jun 2001 13:48:46 +0530 Subject: Re: Few questions related to LDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Nagendra Singh Tomar on 06/08/2001 02:00:54 PM Please respond to nagendras@netbrahma.com To: Sumit Chauhan/HSS@HSS cc: Nagendra Singh Tomar , Abhijit Gadgil , Eric Gray , mpls@UU.NET Subject: Re: Few questions related to LDP Hi sumit! Condition 1 in 4.1.4 of RFC 3031 covers the case when the FEC refers to some directly connected subnet for a node. I can't understand how u can say that R2 satisfys condition 1. Please explain ?? --tomar On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > > > nagendra! > pls find comments inline. > > regards > sumit > > > > > Nagendra Singh Tomar on 06/08/2001 01:29:02 PM > > Please respond to nagendras@netbrahma.com > > To: Abhijit Gadgil > cc: Sumit Chauhan/HSS@HSS, Eric Gray , Nagendra Singh > Tomar , mpls@UU.NET > > Subject: Re: Few questions related to LDP > > A> > > Abhijit! > Ur proposition leads to a couple of new questions. > Assume that R2 has no entry for p.q.r.o/24, but for p.q.0.0/16, then > according to ur proposition R2 will terminate the LSP (LSP1) i.e it will > act as an egress for LSP1, and from R2 to R3 it will initiate a new LSP > (LSP2) which will be for FEC p.q.0.0/16 unlike LSP1 which is for > p.q.r.0/24. > The question is why will R2 act as an egress for FEC p.q.r.0/24 > (Refer 4.1.4 RFC 3032 for exact definition of an egress node), > ***sumit*** > Its RFC 3031 ;o)) > Anyhow nothing in the spec prevents R2 from being the egress as it satisfys the > point 1 of the two conditions for being an Egress LSR as follows > " 1. R has an address Y, such that X is the address prefix in R's > routing table which is the longest match for Y, or" > > think of it also as a case where LSR R2 might have been at the edge of an MPLS > domain. It is not neccessary that R2 is the absolute last router to the FEC > address prefix for it to act as an LSR. > *********** > > LRq.9 point #1 for DU/DoD Ordered control checks for egress, if the node > is not egress for FEC it sends a label request for the same FEC > (p.q.r.0/24) to the nexthop for that FEC (I assume that this nexthop is > found by doing a longest prefix match in the routing table). > ****sumit**** > again the R2 shall be marked here as the egress for p.q.r.0/24 as part of the > "smart" R2 action items. > ************* > A router is egress for an FEC if it is acting as a "deaggregation" point > that is its routing table has more precise entries NOT when it is acting > as an "aggregation" point i.e its routing table has less precise entries ( > as is the case we are discussing) > > > regards > tomar > > > > > > On Fri, 8 Jun 2001, Abhijit Gadgil wrote: > > > sumit, > > > > If R2 has no entry for p.q.r.o/24, but for p.q.0.0/16 then I think > > following shd happen, almost like what Eric has pointed out. > > > > R1-R2 R2-R3 ( R2 is being a bit smart here) > > ======= ======= > > LSP1 LSP2 > > (p.q.r.0/24) (p.q.0.0/16) > > > > and not > > > > R1-R2-R3 > > =========== > > LSP > > (p.q.r.0/24) > > > > If indeed an LSP as in scenario 2 exist, R2 does have an entry for > > p.q.r.0/24 in its routing table and thus in every likelyhood the FTN entry > > . And then it _can_ put packets for p.q.r.0/24 on the part of the LSP > > beyond it. i.e. R2-R3, which come from R4. > > > > Am i missing something? > > > > -abhijit > > > > On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > You are correct in your analysis of the problem (the one with R4 > > >involved) but there is still a question that needs to be answered. for > > >R2 to be able ro also accept unlabeled packets from R4 and put them on > > >the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say > > >p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for > > >creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is > > >the routing update received from R3 which is the next hop for > > >p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to > > >do traffic merging for two seperate FEC. This can be done but I guess > > >then the intelligence will have to be explicit in terms of - to what > > >level we want to do it (consider another p.0.0.0/8 entry in r2 routing > > >table from a next hop R5 !). You are absolutely right that this is a > > >local issue and does not need to be LSP wide as Eric pointed out that > > >someone having a route to p.q.0.0/16 will surely have a route to > > >p.q.r.0/24 (even if it might not be the best one ;o) > > > > > >regards > > >sumit > > > > > > -- > > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ > > > > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Fri Jun 8 04:37:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07623 for ; Fri, 8 Jun 2001 04:37:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksms21774; Fri, 8 Jun 2001 08:37:22 GMT Received: by mail-control.mail.uu.net id QQksms09511 for mpls-outgoing; Fri, 8 Jun 2001 08:36:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksms09476 for ; Fri, 8 Jun 2001 08:36:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQksms12175 for ; Fri, 8 Jun 2001 08:35:07 GMT Received: from localhost.localdomain by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksms02439 for ; Fri, 8 Jun 2001 08:35:04 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f588Utq15051; Fri, 8 Jun 2001 14:00:55 +0530 Date: Fri, 8 Jun 2001 14:00:54 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: suchauhan@hss.hns.com cc: Nagendra Singh Tomar , Abhijit Gadgil , Eric Gray , mpls@UU.NET Subject: Re: Few questions related to LDP In-Reply-To: <65256A65.002B5A07.00@sandesh.hss.hns.com> Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi sumit! Condition 1 in 4.1.4 of RFC 3031 covers the case when the FEC refers to some directly connected subnet for a node. I can't understand how u can say that R2 satisfys condition 1. Please explain ?? --tomar On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > > > nagendra! > pls find comments inline. > > regards > sumit > > > > > Nagendra Singh Tomar on 06/08/2001 01:29:02 PM > > Please respond to nagendras@netbrahma.com > > To: Abhijit Gadgil > cc: Sumit Chauhan/HSS@HSS, Eric Gray , Nagendra Singh > Tomar , mpls@UU.NET > > Subject: Re: Few questions related to LDP > > A> > > Abhijit! > Ur proposition leads to a couple of new questions. > Assume that R2 has no entry for p.q.r.o/24, but for p.q.0.0/16, then > according to ur proposition R2 will terminate the LSP (LSP1) i.e it will > act as an egress for LSP1, and from R2 to R3 it will initiate a new LSP > (LSP2) which will be for FEC p.q.0.0/16 unlike LSP1 which is for > p.q.r.0/24. > The question is why will R2 act as an egress for FEC p.q.r.0/24 > (Refer 4.1.4 RFC 3032 for exact definition of an egress node), > ***sumit*** > Its RFC 3031 ;o)) > Anyhow nothing in the spec prevents R2 from being the egress as it satisfys the > point 1 of the two conditions for being an Egress LSR as follows > " 1. R has an address Y, such that X is the address prefix in R's > routing table which is the longest match for Y, or" > > think of it also as a case where LSR R2 might have been at the edge of an MPLS > domain. It is not neccessary that R2 is the absolute last router to the FEC > address prefix for it to act as an LSR. > *********** > > LRq.9 point #1 for DU/DoD Ordered control checks for egress, if the node > is not egress for FEC it sends a label request for the same FEC > (p.q.r.0/24) to the nexthop for that FEC (I assume that this nexthop is > found by doing a longest prefix match in the routing table). > ****sumit**** > again the R2 shall be marked here as the egress for p.q.r.0/24 as part of the > "smart" R2 action items. > ************* > A router is egress for an FEC if it is acting as a "deaggregation" point > that is its routing table has more precise entries NOT when it is acting > as an "aggregation" point i.e its routing table has less precise entries ( > as is the case we are discussing) > > > regards > tomar > > > > > > On Fri, 8 Jun 2001, Abhijit Gadgil wrote: > > > sumit, > > > > If R2 has no entry for p.q.r.o/24, but for p.q.0.0/16 then I think > > following shd happen, almost like what Eric has pointed out. > > > > R1-R2 R2-R3 ( R2 is being a bit smart here) > > ======= ======= > > LSP1 LSP2 > > (p.q.r.0/24) (p.q.0.0/16) > > > > and not > > > > R1-R2-R3 > > =========== > > LSP > > (p.q.r.0/24) > > > > If indeed an LSP as in scenario 2 exist, R2 does have an entry for > > p.q.r.0/24 in its routing table and thus in every likelyhood the FTN entry > > . And then it _can_ put packets for p.q.r.0/24 on the part of the LSP > > beyond it. i.e. R2-R3, which come from R4. > > > > Am i missing something? > > > > -abhijit > > > > On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > You are correct in your analysis of the problem (the one with R4 > > >involved) but there is still a question that needs to be answered. for > > >R2 to be able ro also accept unlabeled packets from R4 and put them on > > >the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say > > >p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for > > >creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is > > >the routing update received from R3 which is the next hop for > > >p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to > > >do traffic merging for two seperate FEC. This can be done but I guess > > >then the intelligence will have to be explicit in terms of - to what > > >level we want to do it (consider another p.0.0.0/8 entry in r2 routing > > >table from a next hop R5 !). You are absolutely right that this is a > > >local issue and does not need to be LSP wide as Eric pointed out that > > >someone having a route to p.q.0.0/16 will surely have a route to > > >p.q.r.0/24 (even if it might not be the best one ;o) > > > > > >regards > > >sumit > > > > > > -- > > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ > > > > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Fri Jun 8 04:40:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07641 for ; Fri, 8 Jun 2001 04:40:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksms01944; Fri, 8 Jun 2001 08:39:50 GMT Received: by mail-control.mail.uu.net id QQksms09755 for mpls-outgoing; Fri, 8 Jun 2001 08:39:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksms09725 for ; Fri, 8 Jun 2001 08:39:00 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 QQksms28292 for ; Fri, 8 Jun 2001 08:38:37 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksms06008 for ; Fri, 8 Jun 2001 08:38:35 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f588a0q14065; Fri, 8 Jun 2001 14:06:00 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A65.002DBBE4 ; Fri, 8 Jun 2001 13:49:32 +0530 X-Lotus-FromDomain: HSS To: Abhijit Gadgil , Eric Gray , mpls@UU.NET Message-ID: <65256A65.002DBA79.00@sandesh.hss.hns.com> Date: Fri, 8 Jun 2001 13:49:26 +0530 Subject: Re: Few questions related to LDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi nagendra! yup I am sorry for mis-interpretting "has an address Y" as "having an address Y in its routing table". You are right that strictly speaking it cannot be an Egress LSR. But IMHO I still think, as part of the "smart" LSR theory we might still safely act as an Egress LSR for the situation discussed. actually closer to being a Proxy Egress LER (again not strictly by the specs.) regards sumit Nagendra Singh Tomar on 06/08/2001 02:00:54 PM Please respond to nagendras@netbrahma.com To: Sumit Chauhan/HSS@HSS cc: Nagendra Singh Tomar , Abhijit Gadgil , Eric Gray , mpls@UU.NET Subject: Re: Few questions related to LDP Hi sumit! Condition 1 in 4.1.4 of RFC 3031 covers the case when the FEC refers to some directly connected subnet for a node. I can't understand how u can say that R2 satisfys condition 1. Please explain ?? --tomar On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > > > nagendra! > pls find comments inline. > > regards > sumit > > > > > Nagendra Singh Tomar on 06/08/2001 01:29:02 PM > > Please respond to nagendras@netbrahma.com > > To: Abhijit Gadgil > cc: Sumit Chauhan/HSS@HSS, Eric Gray , Nagendra Singh > Tomar , mpls@UU.NET > > Subject: Re: Few questions related to LDP > > A> > > Abhijit! > Ur proposition leads to a couple of new questions. > Assume that R2 has no entry for p.q.r.o/24, but for p.q.0.0/16, then > according to ur proposition R2 will terminate the LSP (LSP1) i.e it will > act as an egress for LSP1, and from R2 to R3 it will initiate a new LSP > (LSP2) which will be for FEC p.q.0.0/16 unlike LSP1 which is for > p.q.r.0/24. > The question is why will R2 act as an egress for FEC p.q.r.0/24 > (Refer 4.1.4 RFC 3032 for exact definition of an egress node), > ***sumit*** > Its RFC 3031 ;o)) > Anyhow nothing in the spec prevents R2 from being the egress as it satisfys the > point 1 of the two conditions for being an Egress LSR as follows > " 1. R has an address Y, such that X is the address prefix in R's > routing table which is the longest match for Y, or" > > think of it also as a case where LSR R2 might have been at the edge of an MPLS > domain. It is not neccessary that R2 is the absolute last router to the FEC > address prefix for it to act as an LSR. > *********** > > LRq.9 point #1 for DU/DoD Ordered control checks for egress, if the node > is not egress for FEC it sends a label request for the same FEC > (p.q.r.0/24) to the nexthop for that FEC (I assume that this nexthop is > found by doing a longest prefix match in the routing table). > ****sumit**** > again the R2 shall be marked here as the egress for p.q.r.0/24 as part of the > "smart" R2 action items. > ************* > A router is egress for an FEC if it is acting as a "deaggregation" point > that is its routing table has more precise entries NOT when it is acting > as an "aggregation" point i.e its routing table has less precise entries ( > as is the case we are discussing) > > > regards > tomar > > > > > > On Fri, 8 Jun 2001, Abhijit Gadgil wrote: > > > sumit, > > > > If R2 has no entry for p.q.r.o/24, but for p.q.0.0/16 then I think > > following shd happen, almost like what Eric has pointed out. > > > > R1-R2 R2-R3 ( R2 is being a bit smart here) > > ======= ======= > > LSP1 LSP2 > > (p.q.r.0/24) (p.q.0.0/16) > > > > and not > > > > R1-R2-R3 > > =========== > > LSP > > (p.q.r.0/24) > > > > If indeed an LSP as in scenario 2 exist, R2 does have an entry for > > p.q.r.0/24 in its routing table and thus in every likelyhood the FTN entry > > . And then it _can_ put packets for p.q.r.0/24 on the part of the LSP > > beyond it. i.e. R2-R3, which come from R4. > > > > Am i missing something? > > > > -abhijit > > > > On Fri, 8 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > You are correct in your analysis of the problem (the one with R4 > > >involved) but there is still a question that needs to be answered. for > > >R2 to be able ro also accept unlabeled packets from R4 and put them on > > >the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say > > >p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for > > >creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is > > >the routing update received from R3 which is the next hop for > > >p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to > > >do traffic merging for two seperate FEC. This can be done but I guess > > >then the intelligence will have to be explicit in terms of - to what > > >level we want to do it (consider another p.0.0.0/8 entry in r2 routing > > >table from a next hop R5 !). You are absolutely right that this is a > > >local issue and does not need to be LSP wide as Eric pointed out that > > >someone having a route to p.q.0.0/16 will surely have a route to > > >p.q.r.0/24 (even if it might not be the best one ;o) > > > > > >regards > > >sumit > > > > > > -- > > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ > > > > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Fri Jun 8 04:54:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07708 for ; Fri, 8 Jun 2001 04:54:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmt15046; Fri, 8 Jun 2001 08:53:26 GMT Received: by mail-control.mail.uu.net id QQksmt11480 for mpls-outgoing; Fri, 8 Jun 2001 08:52:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksmt11461 for ; Fri, 8 Jun 2001 08:52: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 QQksmt18790 for ; Fri, 8 Jun 2001 08:50:54 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQksmt05026 for ; Fri, 8 Jun 2001 08:50:53 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ2X9K1W; Fri, 8 Jun 2001 14:33:44 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2DT3M; Fri, 8 Jun 2001 14:18:48 +0530 From: "Vijayanand C" To: Cc: Subject: RE: Few questions related to LDP Date: Fri, 8 Jun 2001 14:25:43 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <65256A65.001AB478.00@sandesh.hss.hns.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I want to add something regarding this. The routes you are talking are nothing but the routes maintained by the routing protocol. Now, within a domain, should'nt the routers have their routes in sync. Route updates are meant precisely for that purpose. I don't understand how 2 neighbouring routers have 2 routes of the form p.q.r.0/24, p.q.0.0/16. This will happen only when the former is the gateway to the subnet p.q.r.0/24 and the subnet route is not leaked. In that case , it automatically becomes the ingress for p.q.r.0/24. Hence, as Eric says it can issue an explicit NULL and act as ingress for the FEC p.q.r.0/24. It goes one level down the heirarchy. p.0.0.0/8 is one level up the heirarchy, it is outside p.q.0.0/16 Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of suchauhan@hss.hns.com Sent: Friday, June 08, 2001 10:22 AM To: Abhijit Gadgil Cc: Eric Gray; Nagendra Singh Tomar; mpls@UU.NET Subject: Re: Few questions related to LDP hi abhijit! You are correct in your analysis of the problem (the one with R4 involved) but there is still a question that needs to be answered. for R2 to be able ro also accept unlabeled packets from R4 and put them on the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is the routing update received from R3 which is the next hop for p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to do traffic merging for two seperate FEC. This can be done but I guess then the intelligence will have to be explicit in terms of - to what level we want to do it (consider another p.0.0.0/8 entry in r2 routing table from a next hop R5 !). You are absolutely right that this is a local issue and does not need to be LSP wide as Eric pointed out that someone having a route to p.q.0.0/16 will surely have a route to p.q.r.0/24 (even if it might not be the best one ;o) regards sumit Abhijit Gadgil on 06/08/2001 05:28:08 AM To: Eric Gray cc: Nagendra Singh Tomar , mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: Re: Few questions related to LDP Eric, If R2 is distributing bindings unsolicitedly, it will always distribute bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not have entry for that FEC in its routing table. And R2 can send Mapping for label request p.q.r.0/24 when it receives explicitely such request and in that case it MUST send a No Route Notification.(according to rfc3036 section 3.5.8).. I accept it is bit harsh on R2's part in doing so, but this is what the RFC says.... The original question was Whether R2 can put packets from some other guy R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out that no it can't do so. IMO R2 can do so.. whether it does or not is implementation choice and standards don't prevent that. > --- R1 --- R2 --- R3 --- | R4 > btw there is a syntax error in ur mail in follwing para. "No matching brackets". :-) regards, -abhijit >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the >IPv4 explicit NULL label (indicating that it will egress packets destined >for addresses matching this FEC. In any case, R1's requesting a label >R2 was not intended to cause R2 to ingress packets for this FEC (so an >FTN would not be created for this FEC, but for different reasons than are >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and >- possibly - assign those packets to an LSP corresponding to the FEC >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > >-- >Eric Gray From owner-mpls@UU.NET Fri Jun 8 05:08:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07813 for ; Fri, 8 Jun 2001 05:08:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmu07149; Fri, 8 Jun 2001 09:08:13 GMT Received: by mail-control.mail.uu.net id QQksmu29049 for mpls-outgoing; Fri, 8 Jun 2001 09:07:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmu29001 for ; Fri, 8 Jun 2001 09:07:37 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 QQksmu17153 for ; Fri, 8 Jun 2001 09:07:05 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksmu05908 for ; Fri, 8 Jun 2001 09:07:04 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5894Cw16026; Fri, 8 Jun 2001 14:34:12 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A65.0030520A ; Fri, 8 Jun 2001 14:17:47 +0530 X-Lotus-FromDomain: HSS To: "Vijayanand C" cc: mpls@UU.NET Message-ID: <65256A65.00304D69.00@sandesh.hss.hns.com> Date: Fri, 8 Jun 2001 14:17:34 +0530 Subject: RE: Few questions related to LDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi! What you are saying is correct tat it is highly improbable but it is not impossible. The hint for such a topology lies in a scenario where adjoining routers have MPLS enabled over one of the interfaces connesting them but nowhere is it essential that they also have an IGP(say OSPF) also enabled on that interface. I think it is not mandated anywhere in the specs that an MPLS enabled interface should also have IGP enabled on the same interface. Am i wrong? regards sumit "Vijayanand C" on 06/08/2001 02:25:43 PM To: Sumit Chauhan/HSS@HSS cc: mpls@uu.net Subject: RE: Few questions related to LDP Hello, I want to add something regarding this. The routes you are talking are nothing but the routes maintained by the routing protocol. Now, within a domain, should'nt the routers have their routes in sync. Route updates are meant precisely for that purpose. I don't understand how 2 neighbouring routers have 2 routes of the form p.q.r.0/24, p.q.0.0/16. This will happen only when the former is the gateway to the subnet p.q.r.0/24 and the subnet route is not leaked. In that case , it automatically becomes the ingress for p.q.r.0/24. Hence, as Eric says it can issue an explicit NULL and act as ingress for the FEC p.q.r.0/24. It goes one level down the heirarchy. p.0.0.0/8 is one level up the heirarchy, it is outside p.q.0.0/16 Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of suchauhan@hss.hns.com Sent: Friday, June 08, 2001 10:22 AM To: Abhijit Gadgil Cc: Eric Gray; Nagendra Singh Tomar; mpls@UU.NET Subject: Re: Few questions related to LDP hi abhijit! You are correct in your analysis of the problem (the one with R4 involved) but there is still a question that needs to be answered. for R2 to be able ro also accept unlabeled packets from R4 and put them on the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is the routing update received from R3 which is the next hop for p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to do traffic merging for two seperate FEC. This can be done but I guess then the intelligence will have to be explicit in terms of - to what level we want to do it (consider another p.0.0.0/8 entry in r2 routing table from a next hop R5 !). You are absolutely right that this is a local issue and does not need to be LSP wide as Eric pointed out that someone having a route to p.q.0.0/16 will surely have a route to p.q.r.0/24 (even if it might not be the best one ;o) regards sumit Abhijit Gadgil on 06/08/2001 05:28:08 AM To: Eric Gray cc: Nagendra Singh Tomar , mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: Re: Few questions related to LDP Eric, If R2 is distributing bindings unsolicitedly, it will always distribute bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not have entry for that FEC in its routing table. And R2 can send Mapping for label request p.q.r.0/24 when it receives explicitely such request and in that case it MUST send a No Route Notification.(according to rfc3036 section 3.5.8).. I accept it is bit harsh on R2's part in doing so, but this is what the RFC says.... The original question was Whether R2 can put packets from some other guy R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out that no it can't do so. IMO R2 can do so.. whether it does or not is implementation choice and standards don't prevent that. > --- R1 --- R2 --- R3 --- | R4 > btw there is a syntax error in ur mail in follwing para. "No matching brackets". :-) regards, -abhijit >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the >IPv4 explicit NULL label (indicating that it will egress packets destined >for addresses matching this FEC. In any case, R1's requesting a label >R2 was not intended to cause R2 to ingress packets for this FEC (so an >FTN would not be created for this FEC, but for different reasons than are >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and >- possibly - assign those packets to an LSP corresponding to the FEC >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > >-- >Eric Gray From owner-mpls@UU.NET Fri Jun 8 05:21:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07942 for ; Fri, 8 Jun 2001 05:21:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmv13081; Fri, 8 Jun 2001 09:21:25 GMT Received: by mail-control.mail.uu.net id QQksmv04097 for mpls-outgoing; Fri, 8 Jun 2001 09:20:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksmv04059 for ; Fri, 8 Jun 2001 09:20:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQksmv18673 for ; Fri, 8 Jun 2001 09:20:25 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQksmv02084 for ; Fri, 8 Jun 2001 09:20:24 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ2X9KQ5; Fri, 8 Jun 2001 15:03:16 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2DTRR; Fri, 8 Jun 2001 14:48:19 +0530 From: "Vijayanand C" To: Subject: RE: Few questions related to LDP Date: Fri, 8 Jun 2001 14:55:14 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, That apart one more issue. |domain|----R1--- R2----R3--- If you are talking about the situation where R1 has only p.q.r.0/24 and R2 has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside the subnet. Actually in this case p.q.r.0/24 is the address of the subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, ie, the next hop for this FEC is inside the domain not outside !! So, R1 will never request a label for p.q.r.0/24 to R2, simply because it is not the next hop! One more thing in this case R1 should be having p.q.0.0/16 since it is a border router for p.q.r.0/24. YOu have to state clearly your topology/subnert/AS configuration Regards, Vijay -----Original Message----- From: Vijayanand C [mailto:vijayc@hclt.com] Sent: Friday, June 08, 2001 2:55 PM To: suchauhan@hss.hns.com Subject: RE: Few questions related to LDP Hello, That apart one more issue. |domain|----R1--- R2----R3--- If you are talking about the situation where R1 has only p.q.r.0/24 and R2 has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside the subnet. Actually in this case p.q.r.0/24 is the address of the subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, ie, the next hop for this FEC is inside the domain not outside !! So, R1 will never request a label for p.q.r.0/24 to R2, simply because it is not the next hop! One more thing in this case R1 should be having p.q.0.0/16 since it is a border router for p.q.r.0/24. YOu have to state clearly your topology/subnert/AS configuration Regards, Vijay -----Original Message----- From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] Sent: Friday, June 08, 2001 2:18 PM To: Vijayanand C Cc: mpls@uu.net Subject: RE: Few questions related to LDP hi! What you are saying is correct tat it is highly improbable but it is not impossible. The hint for such a topology lies in a scenario where adjoining routers have MPLS enabled over one of the interfaces connesting them but nowhere is it essential that they also have an IGP(say OSPF) also enabled on that interface. I think it is not mandated anywhere in the specs that an MPLS enabled interface should also have IGP enabled on the same interface. Am i wrong? regards sumit "Vijayanand C" on 06/08/2001 02:25:43 PM To: Sumit Chauhan/HSS@HSS cc: mpls@uu.net Subject: RE: Few questions related to LDP Hello, I want to add something regarding this. The routes you are talking are nothing but the routes maintained by the routing protocol. Now, within a domain, should'nt the routers have their routes in sync. Route updates are meant precisely for that purpose. I don't understand how 2 neighbouring routers have 2 routes of the form p.q.r.0/24, p.q.0.0/16. This will happen only when the former is the gateway to the subnet p.q.r.0/24 and the subnet route is not leaked. In that case , it automatically becomes the ingress for p.q.r.0/24. Hence, as Eric says it can issue an explicit NULL and act as ingress for the FEC p.q.r.0/24. It goes one level down the heirarchy. p.0.0.0/8 is one level up the heirarchy, it is outside p.q.0.0/16 Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of suchauhan@hss.hns.com Sent: Friday, June 08, 2001 10:22 AM To: Abhijit Gadgil Cc: Eric Gray; Nagendra Singh Tomar; mpls@UU.NET Subject: Re: Few questions related to LDP hi abhijit! You are correct in your analysis of the problem (the one with R4 involved) but there is still a question that needs to be answered. for R2 to be able ro also accept unlabeled packets from R4 and put them on the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is the routing update received from R3 which is the next hop for p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to do traffic merging for two seperate FEC. This can be done but I guess then the intelligence will have to be explicit in terms of - to what level we want to do it (consider another p.0.0.0/8 entry in r2 routing table from a next hop R5 !). You are absolutely right that this is a local issue and does not need to be LSP wide as Eric pointed out that someone having a route to p.q.0.0/16 will surely have a route to p.q.r.0/24 (even if it might not be the best one ;o) regards sumit Abhijit Gadgil on 06/08/2001 05:28:08 AM To: Eric Gray cc: Nagendra Singh Tomar , mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: Re: Few questions related to LDP Eric, If R2 is distributing bindings unsolicitedly, it will always distribute bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not have entry for that FEC in its routing table. And R2 can send Mapping for label request p.q.r.0/24 when it receives explicitely such request and in that case it MUST send a No Route Notification.(according to rfc3036 section 3.5.8).. I accept it is bit harsh on R2's part in doing so, but this is what the RFC says.... The original question was Whether R2 can put packets from some other guy R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out that no it can't do so. IMO R2 can do so.. whether it does or not is implementation choice and standards don't prevent that. > --- R1 --- R2 --- R3 --- | R4 > btw there is a syntax error in ur mail in follwing para. "No matching brackets". :-) regards, -abhijit >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the >IPv4 explicit NULL label (indicating that it will egress packets destined >for addresses matching this FEC. In any case, R1's requesting a label >R2 was not intended to cause R2 to ingress packets for this FEC (so an >FTN would not be created for this FEC, but for different reasons than are >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and >- possibly - assign those packets to an LSP corresponding to the FEC >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > >-- >Eric Gray From owner-mpls@UU.NET Fri Jun 8 05:34:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08152 for ; Fri, 8 Jun 2001 05:34:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmw15507; Fri, 8 Jun 2001 09:34:54 GMT Received: by mail-control.mail.uu.net id QQksmw05431 for mpls-outgoing; Fri, 8 Jun 2001 09:34:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmw05415 for ; Fri, 8 Jun 2001 09:34:15 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 QQksmw22488 for ; Fri, 8 Jun 2001 09:32:20 GMT Received: from localhost.localdomain by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksmw13072 for ; Fri, 8 Jun 2001 09:32:16 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f589Y6q15351; Fri, 8 Jun 2001 15:04:06 +0530 Date: Fri, 8 Jun 2001 15:04:06 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: Vijayanand C cc: mpls@UU.NET Subject: RE: Few questions related to LDP In-Reply-To: Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Vijaya! Following is a more appropriate diagram of the network we were discussing ----R1--- R2----R3---|domain| Don't ask me how R1 has got a more precise route p.q.r.0/24 than R2 p.q.0.0/16, when apparantly R2 is the nexthop for R1 for the FEC p.q.r.0/24. The case we are considering might be a transient case. regards tomar On Fri, 8 Jun 2001, Vijayanand C wrote: > Hello, > > That apart one more issue. > > > |domain|----R1--- R2----R3--- > > If you are talking about the situation where R1 has only p.q.r.0/24 and R2 > has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside > the subnet. Actually in this case p.q.r.0/24 is the address of the > subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is > encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. > > So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, > ie, the next hop for this FEC is inside the domain not outside !! > > So, R1 will never request a label for p.q.r.0/24 to R2, simply because it is > not the next hop! > > > One more thing in this case R1 should be having p.q.0.0/16 since it is a > border router for p.q.r.0/24. > > YOu have to state clearly your topology/subnert/AS configuration > > > Regards, > Vijay > > -----Original Message----- > From: Vijayanand C [mailto:vijayc@hclt.com] > Sent: Friday, June 08, 2001 2:55 PM > To: suchauhan@hss.hns.com > Subject: RE: Few questions related to LDP > > > Hello, > > That apart one more issue. > > > |domain|----R1--- R2----R3--- > > If you are talking about the situation where R1 has only p.q.r.0/24 and R2 > has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside > the subnet. Actually in this case p.q.r.0/24 is the address of the > subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is > encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. > > So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, > ie, the next hop for this FEC is inside the domain not outside !! > > So, R1 will never request a label for p.q.r.0/24 to R2, simply because it is > not the next hop! > > > One more thing in this case R1 should be having p.q.0.0/16 since it is a > border router for p.q.r.0/24. > > YOu have to state clearly your topology/subnert/AS configuration > > > Regards, > Vijay > > -----Original Message----- > From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] > Sent: Friday, June 08, 2001 2:18 PM > To: Vijayanand C > Cc: mpls@uu.net > Subject: RE: Few questions related to LDP > > > > > hi! > What you are saying is correct tat it is highly improbable but it is > not > impossible. The hint for such a topology lies in a scenario where adjoining > routers have MPLS enabled over one of the interfaces connesting them but > nowhere > is it essential that they also have an IGP(say OSPF) also enabled on that > interface. I think it is not mandated anywhere in the specs that an MPLS > enabled > interface should also have IGP enabled on the same interface. Am i wrong? > > regards > sumit > > > > > "Vijayanand C" on 06/08/2001 02:25:43 PM > > To: Sumit Chauhan/HSS@HSS > cc: mpls@uu.net > > Subject: RE: Few questions related to LDP > > > > > Hello, > I want to add something regarding this. > > The routes you are talking are nothing but the routes maintained by the > routing protocol. Now, within a domain, should'nt the routers have their > routes in sync. Route updates are meant precisely for that purpose. I don't > understand how 2 neighbouring routers have 2 routes of the form p.q.r.0/24, > p.q.0.0/16. This will happen only when the former is the gateway to the > subnet p.q.r.0/24 and the subnet route is not leaked. In that case , it > automatically becomes the ingress for p.q.r.0/24. Hence, as Eric says it can > issue an explicit NULL and act as ingress for the FEC p.q.r.0/24. It goes > one level down the heirarchy. p.0.0.0/8 is one level up the heirarchy, it is > outside p.q.0.0/16 > > > Regards, > Vijay > > > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > suchauhan@hss.hns.com > Sent: Friday, June 08, 2001 10:22 AM > To: Abhijit Gadgil > Cc: Eric Gray; Nagendra Singh Tomar; mpls@UU.NET > Subject: Re: Few questions related to LDP > > > > > hi abhijit! > You are correct in your analysis of the problem (the one with R4 > involved) > but there is still a question that needs to be answered. for R2 to be able > ro > also accept unlabeled packets from R4 and put them on the LSP R1-R2-R3 there > has > to be a FTN entry created at R2 for say p.q.r.0/24 (which is the LSP > R1-R2-R3) > where as the trigger for creation of an FTN (DoD or DU) would only be for > p.q.0.0/16 as that is the routing update received from R3 which is the next > hop > for p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to do > traffic merging for two seperate FEC. This can be done but I guess then the > intelligence will have to be explicit in terms of - to what level we want > to do > it (consider another p.0.0.0/8 entry in r2 routing table from a next hop R5 > !). > You are absolutely right that this is a local issue and does not need to be > LSP > wide as Eric pointed out that someone having a route to p.q.0.0/16 will > surely > have a route to p.q.r.0/24 (even if it might not be the best one ;o) > > regards > sumit > > > > > > Abhijit Gadgil on 06/08/2001 05:28:08 AM > > To: Eric Gray > cc: Nagendra Singh Tomar , mpls@UU.NET (bcc: > Sumit > Chauhan/HSS) > > Subject: Re: Few questions related to LDP > > > > > > Eric, > > If R2 is distributing bindings unsolicitedly, it will always distribute > bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not > have entry for that FEC in its routing table. > > And R2 can send Mapping for label request p.q.r.0/24 when it receives > explicitely such request and in that case it MUST send a No Route > Notification.(according to rfc3036 section 3.5.8).. I accept it is bit > harsh on R2's part in doing so, but this is what the RFC says.... > > The original question was Whether R2 can put packets from some other guy > R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out > that no it can't do so. IMO R2 can do so.. whether it does or not is > implementation choice and standards don't prevent that. > > > --- R1 --- R2 --- R3 --- > | > R4 > > > > btw there is a syntax error in ur mail in follwing para. "No matching > brackets". :-) > > regards, > > -abhijit > > >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the > >IPv4 explicit NULL label (indicating that it will egress packets destined > >for addresses matching this FEC. In any case, R1's requesting a label > >R2 was not intended to cause R2 to ingress packets for this FEC (so an > >FTN would not be created for this FEC, but for different reasons than are > >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for > >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and > >- possibly - assign those packets to an LSP corresponding to the FEC > >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > > > >-- > >Eric Gray > > > > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Fri Jun 8 05:42:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08224 for ; Fri, 8 Jun 2001 05:42:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmw21884; Fri, 8 Jun 2001 09:41:21 GMT Received: by mail-control.mail.uu.net id QQksmw06057 for mpls-outgoing; Fri, 8 Jun 2001 09:40:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksmw06044 for ; Fri, 8 Jun 2001 09:40: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 QQksmw25875 for ; Fri, 8 Jun 2001 09:38:20 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQksmw18938 for ; Fri, 8 Jun 2001 09:38:19 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ2X9KZV; Fri, 8 Jun 2001 15:21:10 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2DT4K; Fri, 8 Jun 2001 15:06:13 +0530 From: "Vijayanand C" To: Cc: Subject: RE: Few questions related to LDP Date: Fri, 8 Jun 2001 15:13:08 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Nagrendra, Please tell me the situation where R1 has p.q.r.0/24 and R2 has p.q.0.0/16. What is the domain that you have showed to the right of R3. Is it p.q.r.0/24 ? Then R3 and R2 will also have p.q.r.0/24 unless you have a more complex topology.We need to know what is that topology for R1 which is 2 hops away from domain p.q.r.0/24 has the more precise route while R2 which is closer has a less precise route. Regards, Vijay -----Original Message----- From: Nagendra Singh Tomar [mailto:nagendras@netbrahma.com] Sent: Friday, June 08, 2001 3:04 PM To: Vijayanand C Cc: mpls@UU.NET Subject: RE: Few questions related to LDP Hi Vijaya! Following is a more appropriate diagram of the network we were discussing ----R1--- R2----R3---|domain| Don't ask me how R1 has got a more precise route p.q.r.0/24 than R2 p.q.0.0/16, when apparantly R2 is the nexthop for R1 for the FEC p.q.r.0/24. The case we are considering might be a transient case. regards tomar On Fri, 8 Jun 2001, Vijayanand C wrote: > Hello, > > That apart one more issue. > > > |domain|----R1--- R2----R3--- > > If you are talking about the situation where R1 has only p.q.r.0/24 and R2 > has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside > the subnet. Actually in this case p.q.r.0/24 is the address of the > subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is > encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. > > So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, > ie, the next hop for this FEC is inside the domain not outside !! > > So, R1 will never request a label for p.q.r.0/24 to R2, simply because it is > not the next hop! > > > One more thing in this case R1 should be having p.q.0.0/16 since it is a > border router for p.q.r.0/24. > > YOu have to state clearly your topology/subnert/AS configuration > > > Regards, > Vijay > > -----Original Message----- > From: Vijayanand C [mailto:vijayc@hclt.com] > Sent: Friday, June 08, 2001 2:55 PM > To: suchauhan@hss.hns.com > Subject: RE: Few questions related to LDP > > > Hello, > > That apart one more issue. > > > |domain|----R1--- R2----R3--- > > If you are talking about the situation where R1 has only p.q.r.0/24 and R2 > has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside > the subnet. Actually in this case p.q.r.0/24 is the address of the > subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is > encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. > > So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, > ie, the next hop for this FEC is inside the domain not outside !! > > So, R1 will never request a label for p.q.r.0/24 to R2, simply because it is > not the next hop! > > > One more thing in this case R1 should be having p.q.0.0/16 since it is a > border router for p.q.r.0/24. > > YOu have to state clearly your topology/subnert/AS configuration > > > Regards, > Vijay > > -----Original Message----- > From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] > Sent: Friday, June 08, 2001 2:18 PM > To: Vijayanand C > Cc: mpls@uu.net > Subject: RE: Few questions related to LDP > > > > > hi! > What you are saying is correct tat it is highly improbable but it is > not > impossible. The hint for such a topology lies in a scenario where adjoining > routers have MPLS enabled over one of the interfaces connesting them but > nowhere > is it essential that they also have an IGP(say OSPF) also enabled on that > interface. I think it is not mandated anywhere in the specs that an MPLS > enabled > interface should also have IGP enabled on the same interface. Am i wrong? > > regards > sumit > > > > > "Vijayanand C" on 06/08/2001 02:25:43 PM > > To: Sumit Chauhan/HSS@HSS > cc: mpls@uu.net > > Subject: RE: Few questions related to LDP > > > > > Hello, > I want to add something regarding this. > > The routes you are talking are nothing but the routes maintained by the > routing protocol. Now, within a domain, should'nt the routers have their > routes in sync. Route updates are meant precisely for that purpose. I don't > understand how 2 neighbouring routers have 2 routes of the form p.q.r.0/24, > p.q.0.0/16. This will happen only when the former is the gateway to the > subnet p.q.r.0/24 and the subnet route is not leaked. In that case , it > automatically becomes the ingress for p.q.r.0/24. Hence, as Eric says it can > issue an explicit NULL and act as ingress for the FEC p.q.r.0/24. It goes > one level down the heirarchy. p.0.0.0/8 is one level up the heirarchy, it is > outside p.q.0.0/16 > > > Regards, > Vijay > > > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > suchauhan@hss.hns.com > Sent: Friday, June 08, 2001 10:22 AM > To: Abhijit Gadgil > Cc: Eric Gray; Nagendra Singh Tomar; mpls@UU.NET > Subject: Re: Few questions related to LDP > > > > > hi abhijit! > You are correct in your analysis of the problem (the one with R4 > involved) > but there is still a question that needs to be answered. for R2 to be able > ro > also accept unlabeled packets from R4 and put them on the LSP R1-R2-R3 there > has > to be a FTN entry created at R2 for say p.q.r.0/24 (which is the LSP > R1-R2-R3) > where as the trigger for creation of an FTN (DoD or DU) would only be for > p.q.0.0/16 as that is the routing update received from R3 which is the next > hop > for p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to do > traffic merging for two seperate FEC. This can be done but I guess then the > intelligence will have to be explicit in terms of - to what level we want > to do > it (consider another p.0.0.0/8 entry in r2 routing table from a next hop R5 > !). > You are absolutely right that this is a local issue and does not need to be > LSP > wide as Eric pointed out that someone having a route to p.q.0.0/16 will > surely > have a route to p.q.r.0/24 (even if it might not be the best one ;o) > > regards > sumit > > > > > > Abhijit Gadgil on 06/08/2001 05:28:08 AM > > To: Eric Gray > cc: Nagendra Singh Tomar , mpls@UU.NET (bcc: > Sumit > Chauhan/HSS) > > Subject: Re: Few questions related to LDP > > > > > > Eric, > > If R2 is distributing bindings unsolicitedly, it will always distribute > bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not > have entry for that FEC in its routing table. > > And R2 can send Mapping for label request p.q.r.0/24 when it receives > explicitely such request and in that case it MUST send a No Route > Notification.(according to rfc3036 section 3.5.8).. I accept it is bit > harsh on R2's part in doing so, but this is what the RFC says.... > > The original question was Whether R2 can put packets from some other guy > R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out > that no it can't do so. IMO R2 can do so.. whether it does or not is > implementation choice and standards don't prevent that. > > > --- R1 --- R2 --- R3 --- > | > R4 > > > > btw there is a syntax error in ur mail in follwing para. "No matching > brackets". :-) > > regards, > > -abhijit > > >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the > >IPv4 explicit NULL label (indicating that it will egress packets destined > >for addresses matching this FEC. In any case, R1's requesting a label > >R2 was not intended to cause R2 to ingress packets for this FEC (so an > >FTN would not be created for this FEC, but for different reasons than are > >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for > >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and > >- possibly - assign those packets to an LSP corresponding to the FEC > >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > > > >-- > >Eric Gray > > > > > > -- ---------------------------------------------------------------------------- -- Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ---------------------------------------------------------------------------- -- From owner-mpls@UU.NET Fri Jun 8 05:48:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08267 for ; Fri, 8 Jun 2001 05:47:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmx09868; Fri, 8 Jun 2001 09:47:56 GMT Received: by mail-control.mail.uu.net id QQksmx07185 for mpls-outgoing; Fri, 8 Jun 2001 09:47:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmx07168 for ; Fri, 8 Jun 2001 09:47: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 QQksmx12153 for ; Fri, 8 Jun 2001 09:46:13 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksmx26433 for ; Fri, 8 Jun 2001 09:46:12 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f589hUD18702; Fri, 8 Jun 2001 15:13:30 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A65.0033EC92 ; Fri, 8 Jun 2001 14:57:08 +0530 X-Lotus-FromDomain: HSS To: "Vijayanand C" cc: mpls@UU.NET Message-ID: <65256A65.0033E7C5.00@sandesh.hss.hns.com> Date: Fri, 8 Jun 2001 14:56:55 +0530 Subject: RE: Few questions related to LDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi vijay! what we were considering was teh traffic coming the other way. The topology you drew is fine for our interest. But consider te discussion for the flow in the opposite direction! ciao sumit "Vijayanand C" on 06/08/2001 02:55:14 PM To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: RE: Few questions related to LDP Hello, That apart one more issue. |domain|----R1--- R2----R3--- If you are talking about the situation where R1 has only p.q.r.0/24 and R2 has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside the subnet. Actually in this case p.q.r.0/24 is the address of the subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, ie, the next hop for this FEC is inside the domain not outside !! So, R1 will never request a label for p.q.r.0/24 to R2, simply because it is not the next hop! One more thing in this case R1 should be having p.q.0.0/16 since it is a border router for p.q.r.0/24. YOu have to state clearly your topology/subnert/AS configuration Regards, Vijay -----Original Message----- From: Vijayanand C [mailto:vijayc@hclt.com] Sent: Friday, June 08, 2001 2:55 PM To: suchauhan@hss.hns.com Subject: RE: Few questions related to LDP Hello, That apart one more issue. |domain|----R1--- R2----R3--- If you are talking about the situation where R1 has only p.q.r.0/24 and R2 has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside the subnet. Actually in this case p.q.r.0/24 is the address of the subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, ie, the next hop for this FEC is inside the domain not outside !! So, R1 will never request a label for p.q.r.0/24 to R2, simply because it is not the next hop! One more thing in this case R1 should be having p.q.0.0/16 since it is a border router for p.q.r.0/24. YOu have to state clearly your topology/subnert/AS configuration Regards, Vijay -----Original Message----- From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] Sent: Friday, June 08, 2001 2:18 PM To: Vijayanand C Cc: mpls@uu.net Subject: RE: Few questions related to LDP hi! What you are saying is correct tat it is highly improbable but it is not impossible. The hint for such a topology lies in a scenario where adjoining routers have MPLS enabled over one of the interfaces connesting them but nowhere is it essential that they also have an IGP(say OSPF) also enabled on that interface. I think it is not mandated anywhere in the specs that an MPLS enabled interface should also have IGP enabled on the same interface. Am i wrong? regards sumit "Vijayanand C" on 06/08/2001 02:25:43 PM To: Sumit Chauhan/HSS@HSS cc: mpls@uu.net Subject: RE: Few questions related to LDP Hello, I want to add something regarding this. The routes you are talking are nothing but the routes maintained by the routing protocol. Now, within a domain, should'nt the routers have their routes in sync. Route updates are meant precisely for that purpose. I don't understand how 2 neighbouring routers have 2 routes of the form p.q.r.0/24, p.q.0.0/16. This will happen only when the former is the gateway to the subnet p.q.r.0/24 and the subnet route is not leaked. In that case , it automatically becomes the ingress for p.q.r.0/24. Hence, as Eric says it can issue an explicit NULL and act as ingress for the FEC p.q.r.0/24. It goes one level down the heirarchy. p.0.0.0/8 is one level up the heirarchy, it is outside p.q.0.0/16 Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of suchauhan@hss.hns.com Sent: Friday, June 08, 2001 10:22 AM To: Abhijit Gadgil Cc: Eric Gray; Nagendra Singh Tomar; mpls@UU.NET Subject: Re: Few questions related to LDP hi abhijit! You are correct in your analysis of the problem (the one with R4 involved) but there is still a question that needs to be answered. for R2 to be able ro also accept unlabeled packets from R4 and put them on the LSP R1-R2-R3 there has to be a FTN entry created at R2 for say p.q.r.0/24 (which is the LSP R1-R2-R3) where as the trigger for creation of an FTN (DoD or DU) would only be for p.q.0.0/16 as that is the routing update received from R3 which is the next hop for p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to do traffic merging for two seperate FEC. This can be done but I guess then the intelligence will have to be explicit in terms of - to what level we want to do it (consider another p.0.0.0/8 entry in r2 routing table from a next hop R5 !). You are absolutely right that this is a local issue and does not need to be LSP wide as Eric pointed out that someone having a route to p.q.0.0/16 will surely have a route to p.q.r.0/24 (even if it might not be the best one ;o) regards sumit Abhijit Gadgil on 06/08/2001 05:28:08 AM To: Eric Gray cc: Nagendra Singh Tomar , mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: Re: Few questions related to LDP Eric, If R2 is distributing bindings unsolicitedly, it will always distribute bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not have entry for that FEC in its routing table. And R2 can send Mapping for label request p.q.r.0/24 when it receives explicitely such request and in that case it MUST send a No Route Notification.(according to rfc3036 section 3.5.8).. I accept it is bit harsh on R2's part in doing so, but this is what the RFC says.... The original question was Whether R2 can put packets from some other guy R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out that no it can't do so. IMO R2 can do so.. whether it does or not is implementation choice and standards don't prevent that. > --- R1 --- R2 --- R3 --- | R4 > btw there is a syntax error in ur mail in follwing para. "No matching brackets". :-) regards, -abhijit >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the >IPv4 explicit NULL label (indicating that it will egress packets destined >for addresses matching this FEC. In any case, R1's requesting a label >R2 was not intended to cause R2 to ingress packets for this FEC (so an >FTN would not be created for this FEC, but for different reasons than are >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and >- possibly - assign those packets to an LSP corresponding to the FEC >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > >-- >Eric Gray From owner-mpls@UU.NET Fri Jun 8 06:00:03 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08369 for ; Fri, 8 Jun 2001 06:00:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmx08899; Fri, 8 Jun 2001 09:59:54 GMT Received: by mail-control.mail.uu.net id QQksmx08450 for mpls-outgoing; Fri, 8 Jun 2001 09:59:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksmx08437 for ; Fri, 8 Jun 2001 09:59:14 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 QQksmx10684 for ; Fri, 8 Jun 2001 09:59:01 GMT Received: from localhost.localdomain by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksmx26865 for ; Fri, 8 Jun 2001 09:58:57 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f58A0qq15444; Fri, 8 Jun 2001 15:30:53 +0530 Date: Fri, 8 Jun 2001 15:30:52 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: Vijayanand C cc: nagendras@netbrahma.com, mpls@UU.NET Subject: RE: Few questions related to LDP In-Reply-To: Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Vijaya! One possible transient scenario might be as follows L1 R1-----R2-----R3-----|p.q.r.0/24| | |L2 | |p.q.s.0/24| Assuming the above network has reached a quiescent state, so routing table at R2 will have 2 entries each for p.q.r.0/24 and p.q.s.0/24, suppose it also has p.q.0.0/16, then if the link L1 goes down and R3 senses that it can no longer reach p.q.r.0/24 thru L1, it will send a route update to that effect. During the time this update leaves R3 and reaches R2, we will have the routing tables as discussed in the previous few mails. Am I clear ??? regards tomar On Fri, 8 Jun 2001, Vijayanand C wrote: > Hello Nagrendra, > > Please tell me the situation where R1 has p.q.r.0/24 and R2 has p.q.0.0/16. > > What is the domain that you have showed to the right of R3. Is it p.q.r.0/24 > ? Then R3 and R2 will also have p.q.r.0/24 unless you have a more complex > topology.We need to know what is that topology for R1 which is 2 hops away > from domain p.q.r.0/24 has the more precise route while R2 which is closer > has a less precise route. > > Regards, > Vijay > > > -----Original Message----- > From: Nagendra Singh Tomar [mailto:nagendras@netbrahma.com] > Sent: Friday, June 08, 2001 3:04 PM > To: Vijayanand C > Cc: mpls@UU.NET > Subject: RE: Few questions related to LDP > > > Hi Vijaya! > Following is a more appropriate diagram of the network we were > discussing > > ----R1--- R2----R3---|domain| > > Don't ask me how R1 has got a more precise route p.q.r.0/24 than R2 > p.q.0.0/16, when apparantly R2 is the nexthop for R1 for the FEC > p.q.r.0/24. The case we are considering might be a transient case. > > regards > tomar > > > On Fri, 8 Jun 2001, Vijayanand C wrote: > > > Hello, > > > > That apart one more issue. > > > > > > |domain|----R1--- R2----R3--- > > > > If you are talking about the situation where R1 has only p.q.r.0/24 and > R2 > > has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside > > the subnet. Actually in this case p.q.r.0/24 is the address of the > > subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is > > encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. > > > > So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, > > ie, the next hop for this FEC is inside the domain not outside !! > > > > So, R1 will never request a label for p.q.r.0/24 to R2, simply because it > is > > not the next hop! > > > > > > One more thing in this case R1 should be having p.q.0.0/16 since it is a > > border router for p.q.r.0/24. > > > > YOu have to state clearly your topology/subnert/AS configuration > > > > > > Regards, > > Vijay > > > > -----Original Message----- > > From: Vijayanand C [mailto:vijayc@hclt.com] > > Sent: Friday, June 08, 2001 2:55 PM > > To: suchauhan@hss.hns.com > > Subject: RE: Few questions related to LDP > > > > > > Hello, > > > > That apart one more issue. > > > > > > |domain|----R1--- R2----R3--- > > > > If you are talking about the situation where R1 has only p.q.r.0/24 and > R2 > > has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside > > the subnet. Actually in this case p.q.r.0/24 is the address of the > > subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is > > encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. > > > > So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, > > ie, the next hop for this FEC is inside the domain not outside !! > > > > So, R1 will never request a label for p.q.r.0/24 to R2, simply because it > is > > not the next hop! > > > > > > One more thing in this case R1 should be having p.q.0.0/16 since it is a > > border router for p.q.r.0/24. > > > > YOu have to state clearly your topology/subnert/AS configuration > > > > > > Regards, > > Vijay > > > > -----Original Message----- > > From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] > > Sent: Friday, June 08, 2001 2:18 PM > > To: Vijayanand C > > Cc: mpls@uu.net > > Subject: RE: Few questions related to LDP > > > > > > > > > > hi! > > What you are saying is correct tat it is highly improbable but it is > > not > > impossible. The hint for such a topology lies in a scenario where > adjoining > > routers have MPLS enabled over one of the interfaces connesting them but > > nowhere > > is it essential that they also have an IGP(say OSPF) also enabled on that > > interface. I think it is not mandated anywhere in the specs that an MPLS > > enabled > > interface should also have IGP enabled on the same interface. Am i wrong? > > > > regards > > sumit > > > > > > > > > > "Vijayanand C" on 06/08/2001 02:25:43 PM > > > > To: Sumit Chauhan/HSS@HSS > > cc: mpls@uu.net > > > > Subject: RE: Few questions related to LDP > > > > > > > > > > Hello, > > I want to add something regarding this. > > > > The routes you are talking are nothing but the routes maintained by the > > routing protocol. Now, within a domain, should'nt the routers have their > > routes in sync. Route updates are meant precisely for that purpose. I > don't > > understand how 2 neighbouring routers have 2 routes of the form > p.q.r.0/24, > > p.q.0.0/16. This will happen only when the former is the gateway to the > > subnet p.q.r.0/24 and the subnet route is not leaked. In that case , it > > automatically becomes the ingress for p.q.r.0/24. Hence, as Eric says it > can > > issue an explicit NULL and act as ingress for the FEC p.q.r.0/24. It goes > > one level down the heirarchy. p.0.0.0/8 is one level up the heirarchy, it > is > > outside p.q.0.0/16 > > > > > > Regards, > > Vijay > > > > > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > suchauhan@hss.hns.com > > Sent: Friday, June 08, 2001 10:22 AM > > To: Abhijit Gadgil > > Cc: Eric Gray; Nagendra Singh Tomar; mpls@UU.NET > > Subject: Re: Few questions related to LDP > > > > > > > > > > hi abhijit! > > You are correct in your analysis of the problem (the one with R4 > > involved) > > but there is still a question that needs to be answered. for R2 to be able > > ro > > also accept unlabeled packets from R4 and put them on the LSP R1-R2-R3 > there > > has > > to be a FTN entry created at R2 for say p.q.r.0/24 (which is the LSP > > R1-R2-R3) > > where as the trigger for creation of an FTN (DoD or DU) would only be for > > p.q.0.0/16 as that is the routing update received from R3 which is the > next > > hop > > for p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to > do > > traffic merging for two seperate FEC. This can be done but I guess then > the > > intelligence will have to be explicit in terms of - to what level we want > > to do > > it (consider another p.0.0.0/8 entry in r2 routing table from a next hop > R5 > > !). > > You are absolutely right that this is a local issue and does not need to > be > > LSP > > wide as Eric pointed out that someone having a route to p.q.0.0/16 will > > surely > > have a route to p.q.r.0/24 (even if it might not be the best one ;o) > > > > regards > > sumit > > > > > > > > > > > > Abhijit Gadgil on 06/08/2001 05:28:08 AM > > > > To: Eric Gray > > cc: Nagendra Singh Tomar , mpls@UU.NET (bcc: > > Sumit > > Chauhan/HSS) > > > > Subject: Re: Few questions related to LDP > > > > > > > > > > > > Eric, > > > > If R2 is distributing bindings unsolicitedly, it will always distribute > > bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not > > have entry for that FEC in its routing table. > > > > And R2 can send Mapping for label request p.q.r.0/24 when it receives > > explicitely such request and in that case it MUST send a No Route > > Notification.(according to rfc3036 section 3.5.8).. I accept it is bit > > harsh on R2's part in doing so, but this is what the RFC says.... > > > > The original question was Whether R2 can put packets from some other guy > > R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out > > that no it can't do so. IMO R2 can do so.. whether it does or not is > > implementation choice and standards don't prevent that. > > > > > --- R1 --- R2 --- R3 --- > > | > > R4 > > > > > > > btw there is a syntax error in ur mail in follwing para. "No matching > > brackets". :-) > > > > regards, > > > > -abhijit > > > > >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return > the > > >IPv4 explicit NULL label (indicating that it will egress packets > destined > > >for addresses matching this FEC. In any case, R1's requesting a label > > >R2 was not intended to cause R2 to ingress packets for this FEC (so an > > >FTN would not be created for this FEC, but for different reasons than > are > > >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label > for > > >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and > > >- possibly - assign those packets to an LSP corresponding to the FEC > > >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > > > > > >-- > > >Eric Gray > > > > > > > > > > > > > > -- > > > ---------------------------------------------------------------------------- > -- > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ---------------------------------------------------------------------------- > -- > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Fri Jun 8 06:11:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08464 for ; Fri, 8 Jun 2001 06:11:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmy03081; Fri, 8 Jun 2001 10:10:47 GMT Received: by mail-control.mail.uu.net id QQksmy28888 for mpls-outgoing; Fri, 8 Jun 2001 10:10:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksmy28827 for ; Fri, 8 Jun 2001 10:09: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 QQksmy04892 for ; Fri, 8 Jun 2001 10:08:42 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQksmy17251 for ; Fri, 8 Jun 2001 10:08:41 GMT Received: (qmail 1928 invoked from network); 8 Jun 2001 10:01:16 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 8 Jun 2001 10:01:16 -0000 Received: from vani.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id PAA28126; Fri, 8 Jun 2001 15:39:32 +0530 (IST) Received: from localhost (gabhijit@localhost) by vani.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id PAA16316; Fri, 8 Jun 2001 15:54:28 +0530 X-Authentication-Warning: vani.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Fri, 8 Jun 2001 15:54:28 +0530 (IST) From: Abhijit Gadgil To: Nagendra Singh Tomar cc: Subject: Re: Few questions related to LDP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 8 Jun 2001, Nagendra Singh Tomar wrote: >Abhijit! > Ur proposition leads to a couple of new questions. >Assume that R2 has no entry for p.q.r.o/24, but for p.q.0.0/16, then >according to ur proposition R2 will terminate the LSP (LSP1) i.e it will >act as an egress for LSP1, and from R2 to R3 it will initiate a new LSP >(LSP2) which will be for FEC p.q.0.0/16 unlike LSP1 which is for >p.q.r.0/24. > The question is why will R2 act as an egress for FEC p.q.r.0/24 >(Refer 4.1.4 RFC 3032 for exact definition of an egress node), Thats why I am saying R2 is acting _smart_ (rather generous) and then its likey that the two LSPs I shown get created, in a way Eric has pointed out. -abhijit From owner-mpls@UU.NET Fri Jun 8 06:21:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08534 for ; Fri, 8 Jun 2001 06:21:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmz28682; Fri, 8 Jun 2001 10:21:13 GMT Received: by mail-control.mail.uu.net id QQksmz00969 for mpls-outgoing; Fri, 8 Jun 2001 10:20:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksmz00959 for ; Fri, 8 Jun 2001 10:20:41 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 QQksmz19975 for ; Fri, 8 Jun 2001 10:19:41 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQksmz27117 for ; Fri, 8 Jun 2001 10:19:40 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ2X9LL4; Fri, 8 Jun 2001 16:02:31 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2DT6K; Fri, 8 Jun 2001 15:47:34 +0530 From: "Vijayanand C" To: Subject: RE: Few questions related to LDP Date: Fri, 8 Jun 2001 15:54:28 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nagendra, You are now talking about a purely transient condition which I think was not your earlier intention. Anyway, R1 will also come to know of the failure in the next update. You are talking about a situation where R1 places a request while the update is on its way to R1! I think in such a situation R2 can send a NO_ROUTE notification, but by the time the no route notification reached R1 the bad news of L1 failure would have got to R1 rending the Label request obslete!! Even if it took any other action like sending NULL labels it would anyway be meaningless in a transient situation. Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Nagendra Singh Tomar Sent: Friday, June 08, 2001 3:31 PM To: Vijayanand C Cc: nagendras@netbrahma.com; mpls@UU.NET Subject: RE: Few questions related to LDP Hi Vijaya! One possible transient scenario might be as follows L1 R1-----R2-----R3-----|p.q.r.0/24| | |L2 | |p.q.s.0/24| Assuming the above network has reached a quiescent state, so routing table at R2 will have 2 entries each for p.q.r.0/24 and p.q.s.0/24, suppose it also has p.q.0.0/16, then if the link L1 goes down and R3 senses that it can no longer reach p.q.r.0/24 thru L1, it will send a route update to that effect. During the time this update leaves R3 and reaches R2, we will have the routing tables as discussed in the previous few mails. Am I clear ??? regards tomar On Fri, 8 Jun 2001, Vijayanand C wrote: > Hello Nagrendra, > > Please tell me the situation where R1 has p.q.r.0/24 and R2 has p.q.0.0/16. > > What is the domain that you have showed to the right of R3. Is it p.q.r.0/24 > ? Then R3 and R2 will also have p.q.r.0/24 unless you have a more complex > topology.We need to know what is that topology for R1 which is 2 hops away > from domain p.q.r.0/24 has the more precise route while R2 which is closer > has a less precise route. > > Regards, > Vijay > > > -----Original Message----- > From: Nagendra Singh Tomar [mailto:nagendras@netbrahma.com] > Sent: Friday, June 08, 2001 3:04 PM > To: Vijayanand C > Cc: mpls@UU.NET > Subject: RE: Few questions related to LDP > > > Hi Vijaya! > Following is a more appropriate diagram of the network we were > discussing > > ----R1--- R2----R3---|domain| > > Don't ask me how R1 has got a more precise route p.q.r.0/24 than R2 > p.q.0.0/16, when apparantly R2 is the nexthop for R1 for the FEC > p.q.r.0/24. The case we are considering might be a transient case. > > regards > tomar > > > On Fri, 8 Jun 2001, Vijayanand C wrote: > > > Hello, > > > > That apart one more issue. > > > > > > |domain|----R1--- R2----R3--- > > > > If you are talking about the situation where R1 has only p.q.r.0/24 and > R2 > > has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside > > the subnet. Actually in this case p.q.r.0/24 is the address of the > > subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is > > encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. > > > > So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, > > ie, the next hop for this FEC is inside the domain not outside !! > > > > So, R1 will never request a label for p.q.r.0/24 to R2, simply because it > is > > not the next hop! > > > > > > One more thing in this case R1 should be having p.q.0.0/16 since it is a > > border router for p.q.r.0/24. > > > > YOu have to state clearly your topology/subnert/AS configuration > > > > > > Regards, > > Vijay > > > > -----Original Message----- > > From: Vijayanand C [mailto:vijayc@hclt.com] > > Sent: Friday, June 08, 2001 2:55 PM > > To: suchauhan@hss.hns.com > > Subject: RE: Few questions related to LDP > > > > > > Hello, > > > > That apart one more issue. > > > > > > |domain|----R1--- R2----R3--- > > > > If you are talking about the situation where R1 has only p.q.r.0/24 and > R2 > > has only p.q.0.0/16, then you are not leaking the route p.q.r.0/24 outside > > the subnet. Actually in this case p.q.r.0/24 is the address of the > > subnetwork which lies to the left of R1. p.q.0.0/16 is the subnet which is > > encompassing many such subnets say p.q.r.0/24, p.q.s.0/24 etc. > > > > So at R1 a packet arriving for p.q.r.0/24 ahould be forwarded to the left, > > ie, the next hop for this FEC is inside the domain not outside !! > > > > So, R1 will never request a label for p.q.r.0/24 to R2, simply because it > is > > not the next hop! > > > > > > One more thing in this case R1 should be having p.q.0.0/16 since it is a > > border router for p.q.r.0/24. > > > > YOu have to state clearly your topology/subnert/AS configuration > > > > > > Regards, > > Vijay > > > > -----Original Message----- > > From: suchauhan@hss.hns.com [mailto:suchauhan@hss.hns.com] > > Sent: Friday, June 08, 2001 2:18 PM > > To: Vijayanand C > > Cc: mpls@uu.net > > Subject: RE: Few questions related to LDP > > > > > > > > > > hi! > > What you are saying is correct tat it is highly improbable but it is > > not > > impossible. The hint for such a topology lies in a scenario where > adjoining > > routers have MPLS enabled over one of the interfaces connesting them but > > nowhere > > is it essential that they also have an IGP(say OSPF) also enabled on that > > interface. I think it is not mandated anywhere in the specs that an MPLS > > enabled > > interface should also have IGP enabled on the same interface. Am i wrong? > > > > regards > > sumit > > > > > > > > > > "Vijayanand C" on 06/08/2001 02:25:43 PM > > > > To: Sumit Chauhan/HSS@HSS > > cc: mpls@uu.net > > > > Subject: RE: Few questions related to LDP > > > > > > > > > > Hello, > > I want to add something regarding this. > > > > The routes you are talking are nothing but the routes maintained by the > > routing protocol. Now, within a domain, should'nt the routers have their > > routes in sync. Route updates are meant precisely for that purpose. I > don't > > understand how 2 neighbouring routers have 2 routes of the form > p.q.r.0/24, > > p.q.0.0/16. This will happen only when the former is the gateway to the > > subnet p.q.r.0/24 and the subnet route is not leaked. In that case , it > > automatically becomes the ingress for p.q.r.0/24. Hence, as Eric says it > can > > issue an explicit NULL and act as ingress for the FEC p.q.r.0/24. It goes > > one level down the heirarchy. p.0.0.0/8 is one level up the heirarchy, it > is > > outside p.q.0.0/16 > > > > > > Regards, > > Vijay > > > > > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > suchauhan@hss.hns.com > > Sent: Friday, June 08, 2001 10:22 AM > > To: Abhijit Gadgil > > Cc: Eric Gray; Nagendra Singh Tomar; mpls@UU.NET > > Subject: Re: Few questions related to LDP > > > > > > > > > > hi abhijit! > > You are correct in your analysis of the problem (the one with R4 > > involved) > > but there is still a question that needs to be answered. for R2 to be able > > ro > > also accept unlabeled packets from R4 and put them on the LSP R1-R2-R3 > there > > has > > to be a FTN entry created at R2 for say p.q.r.0/24 (which is the LSP > > R1-R2-R3) > > where as the trigger for creation of an FTN (DoD or DU) would only be for > > p.q.0.0/16 as that is the routing update received from R3 which is the > next > > hop > > for p.q.0.0/16.Thus we are talking of R2 to be able to be smart enough to > do > > traffic merging for two seperate FEC. This can be done but I guess then > the > > intelligence will have to be explicit in terms of - to what level we want > > to do > > it (consider another p.0.0.0/8 entry in r2 routing table from a next hop > R5 > > !). > > You are absolutely right that this is a local issue and does not need to > be > > LSP > > wide as Eric pointed out that someone having a route to p.q.0.0/16 will > > surely > > have a route to p.q.r.0/24 (even if it might not be the best one ;o) > > > > regards > > sumit > > > > > > > > > > > > Abhijit Gadgil on 06/08/2001 05:28:08 AM > > > > To: Eric Gray > > cc: Nagendra Singh Tomar , mpls@UU.NET (bcc: > > Sumit > > Chauhan/HSS) > > > > Subject: Re: Few questions related to LDP > > > > > > > > > > > > Eric, > > > > If R2 is distributing bindings unsolicitedly, it will always distribute > > bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not > > have entry for that FEC in its routing table. > > > > And R2 can send Mapping for label request p.q.r.0/24 when it receives > > explicitely such request and in that case it MUST send a No Route > > Notification.(according to rfc3036 section 3.5.8).. I accept it is bit > > harsh on R2's part in doing so, but this is what the RFC says.... > > > > The original question was Whether R2 can put packets from some other guy > > R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out > > that no it can't do so. IMO R2 can do so.. whether it does or not is > > implementation choice and standards don't prevent that. > > > > > --- R1 --- R2 --- R3 --- > > | > > R4 > > > > > > > btw there is a syntax error in ur mail in follwing para. "No matching > > brackets". :-) > > > > regards, > > > > -abhijit > > > > >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return > the > > >IPv4 explicit NULL label (indicating that it will egress packets > destined > > >for addresses matching this FEC. In any case, R1's requesting a label > > >R2 was not intended to cause R2 to ingress packets for this FEC (so an > > >FTN would not be created for this FEC, but for different reasons than > are > > >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label > for > > >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and > > >- possibly - assign those packets to an LSP corresponding to the FEC > > >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > > > > > >-- > > >Eric Gray > > > > > > > > > > > > > > -- > > > -------------------------------------------------------------------------- -- > -- > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > -------------------------------------------------------------------------- -- > -- > -- ---------------------------------------------------------------------------- -- Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ---------------------------------------------------------------------------- -- From owner-mpls@UU.NET Fri Jun 8 06:28:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08633 for ; Fri, 8 Jun 2001 06:28:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksmz18482; Fri, 8 Jun 2001 10:27:31 GMT Received: by mail-control.mail.uu.net id QQksmz01760 for mpls-outgoing; Fri, 8 Jun 2001 10:26:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksmz01748 for ; Fri, 8 Jun 2001 10:26:54 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 QQksmz07987 for ; Fri, 8 Jun 2001 10:25:15 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQksmz02396 for ; Fri, 8 Jun 2001 10:25:14 GMT Received: (qmail 2873 invoked from network); 8 Jun 2001 10:17:47 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 8 Jun 2001 10:17:47 -0000 Received: from vani.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id PAA28951; Fri, 8 Jun 2001 15:55:49 +0530 (IST) Received: from localhost (gabhijit@localhost) by vani.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id QAA17635; Fri, 8 Jun 2001 16:10:46 +0530 X-Authentication-Warning: vani.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Fri, 8 Jun 2001 16:10:46 +0530 (IST) From: Abhijit Gadgil To: Nagendra Singh Tomar cc: Vijayanand C , Subject: RE: Few questions related to LDP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > L1 > R1-----R2-----R3-----|p.q.r.0/24| > | > |L2 > | > |p.q.s.0/24| > > >Assuming the above network has reached a quiescent state, so routing >table at R2 will have 2 entries each for p.q.r.0/24 and p.q.s.0/24, >suppose it also has p.q.0.0/16, then if the link L1 goes down and R3 >senses that it can no longer reach p.q.r.0/24 thru L1, it will send a >route update to that effect. During the time this update leaves R3 and >reaches R2, we will have the routing tables as discussed in the previous >few mails. >Am I clear ??? Not really... atleast to me :-) The one reason why entries described so will be there is as follows as I can see. R2 does "aggregation" (or gets "aggregated" information) and sends p.q.0.0/16, to R1. But there is a smart administrator who's sitting at R1 and adds an explicit route to p.q.r.0/24 with R2 as a gateway (ofcourse for reasons known only to her). and then R1 requests for p.q.r.0/24. In that case one of the following can happen 1. R2 recognizes p.q.r.0/24 and so does R3.. Nice and LSP will be created. There _can_ also be an _FTN_ entry in R2. 2. R2 recognizes only p.q.0.0/16 but is somewhat _smart_ (read as generous) and decides on his own to anyway let R1 create an LSP through it. It will create so in a manner described in previous mail (ie the two LSPs) Is anything still missing? -abhijit From owner-mpls@UU.NET Fri Jun 8 08:12:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10460 for ; Fri, 8 Jun 2001 08:12:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksng08115; Fri, 8 Jun 2001 12:12:29 GMT Received: by mail-control.mail.uu.net id QQksng22328 for mpls-outgoing; Fri, 8 Jun 2001 12:11:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksng22211 for ; Fri, 8 Jun 2001 12:11:29 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 QQksng17801 for ; Fri, 8 Jun 2001 12:08:22 GMT Received: from smtp4.cluster.oleane.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62]) id QQksng06145 for ; Fri, 8 Jun 2001 12:08:21 GMT Received: from oleane (dyn-1-1-059.Vin.dialup.oleane.fr [195.25.4.59]) by smtp4.cluster.oleane.net with SMTP id f58C8Iq13361 for ; Fri, 8 Jun 2001 14:08:19 +0200 (CEST) Message-ID: <004401c0f013$aaa29340$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPoW ' 01 Date: Fri, 8 Jun 2001 14:07:58 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C0F024.6BC782A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0041_01C0F024.6BC782A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The second edition of IPoW ' 01 (IP over WDM), to take place in Paris, = France, from October 16 to 19, 2001, will gather leading-edge = researchers and industrials in the IP and fibre domains.=20 Please refer to: http://www.upperside.fr/ipow01/ipow2001intro.htm ------=_NextPart_000_0041_01C0F024.6BC782A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The = second edition of=20 IPoW ' 01 (IP over WDM), to take place in = Paris,=20 France, from October 16 to 19, 2001, = will=20 gather leading-edge researchers and industrials in the IP and fibre = domains.=20
Please refer to:
http://www.uppe= rside.fr/ipow01/ipow2001intro.htm
------=_NextPart_000_0041_01C0F024.6BC782A0-- From owner-mpls@UU.NET Fri Jun 8 09:53:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12612 for ; Fri, 8 Jun 2001 09:53:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksnn15482; Fri, 8 Jun 2001 13:50:10 GMT Received: by mail-control.mail.uu.net id QQksnn23436 for mpls-outgoing; Fri, 8 Jun 2001 13:49:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksnn23425 for ; Fri, 8 Jun 2001 13:49:22 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 QQksnn19609 for ; Fri, 8 Jun 2001 13:47:28 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQksnn13452 for ; Fri, 8 Jun 2001 13:47:27 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ52Q0BW; Fri, 8 Jun 2001 19:30:15 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2D4SH; Fri, 8 Jun 2001 19:15:18 +0530 From: "Vijayanand C" To: "Abhijit Gadgil" Cc: , "Vijayc@Indya. Com" Subject: RE: Few questions related to LDP Date: Fri, 8 Jun 2001 19:22:14 +0530 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.00.2314.1300 Importance: Normal In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Abhijit, What you are saying according to option 2 is - even if an LSR does'nt have an exact match for an FEC , if it has a matching address prefix, it should enable LSP set up. What will be the FEC element that R2/next hop of static route propagate to its next hop. The matching prefix FEC element or the original static route FEC element itself? This new semantic(if you use static route FEC element which is not present in any of the FEC tables of the LSRs) has to be understood by all the routers upto the LSP termination. If you use the matching address prefix, then the intention of creating a static route (which may be to introduce a new FEC for the static route) may be lost. If a lot of operators start introducing static routes like this you also run into scalability problems, as the purpose of address heirarchy may be lost and the number of entries in the FEC table (not route table as you don't want to advertise these routes) may grow. Correct me if I am wrong Regards, Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Abhijit Gadgil Sent: Friday, June 08, 2001 4:11 PM To: Nagendra Singh Tomar Cc: Vijayanand C; mpls@UU.NET Subject: RE: Few questions related to LDP > L1 > R1-----R2-----R3-----|p.q.r.0/24| > | > |L2 > | > |p.q.s.0/24| > > >Assuming the above network has reached a quiescent state, so routing >table at R2 will have 2 entries each for p.q.r.0/24 and p.q.s.0/24, >suppose it also has p.q.0.0/16, then if the link L1 goes down and R3 >senses that it can no longer reach p.q.r.0/24 thru L1, it will send a >route update to that effect. During the time this update leaves R3 and >reaches R2, we will have the routing tables as discussed in the previous >few mails. >Am I clear ??? Not really... atleast to me :-) The one reason why entries described so will be there is as follows as I can see. R2 does "aggregation" (or gets "aggregated" information) and sends p.q.0.0/16, to R1. But there is a smart administrator who's sitting at R1 and adds an explicit route to p.q.r.0/24 with R2 as a gateway (ofcourse for reasons known only to her). and then R1 requests for p.q.r.0/24. In that case one of the following can happen 1. R2 recognizes p.q.r.0/24 and so does R3.. Nice and LSP will be created. There _can_ also be an _FTN_ entry in R2. 2. R2 recognizes only p.q.0.0/16 but is somewhat _smart_ (read as generous) and decides on his own to anyway let R1 create an LSP through it. It will create so in a manner described in previous mail (ie the two LSPs) Is anything still missing? -abhijit From owner-mpls@UU.NET Fri Jun 8 10:02:28 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12760 for ; Fri, 8 Jun 2001 10:02:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksno27313; Fri, 8 Jun 2001 14:00:46 GMT Received: by mail-control.mail.uu.net id QQksno25475 for mpls-outgoing; Fri, 8 Jun 2001 14:00:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksno24829 for ; Fri, 8 Jun 2001 14:00: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 QQksnn23460 for ; Fri, 8 Jun 2001 13:59:29 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQksnn25906 for ; Fri, 8 Jun 2001 13:59:29 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id F0E989400F; Fri, 8 Jun 2001 09:59:23 -0400 (EDT) Message-ID: <3B20DA3B.D57543A8@sandburst.com> Date: Fri, 08 Jun 2001 09:59:23 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Abhijit Gadgil Cc: Nagendra Singh Tomar , mpls@UU.NET Subject: Re: Few questions related to LDP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Abhijit, Sorry, forgot to 'lint' my email message. I believe your premise may be incorrect below: R2 is likely not to distribute a label mapping for p.q.0.0/16 since it may know what the routing topology looks like from R1's perspective. Even if R2 does distribute this mapping, R1 is free to release the one it can't use and ask for a different one it can use (with p.q.r.0/24). The use of the word 'exact' in section 3.5.8 seems problematic. I believe the word 'unambiguous' would have been better. If you look at the procedures for handling a label request, the test (LRq.2, page 97) only checks if there is a next hop for the requested FEC, and there is. Okay, so you have to work a little harder to figure that out. So? Note that this would not be the case if R1 and R2 had these route entries in reverse (i.e. R1 shows R2 as the next hop for p.q.0.0/16 and R2 shows R3 as the next hop for p.q.r.0/24). In that case, R2 could not find an unambiguous next hop for the FEC p.q.0.0/16 requested by R1. -- Eric Gray You wrote: > Eric, > > If R2 is distributing bindings unsolicitedly, it will always distribute > bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not > have entry for that FEC in its routing table. > > And R2 can send Mapping for label request p.q.r.0/24 when it receives > explicitely such request and in that case it MUST send a No Route > Notification.(according to rfc3036 section 3.5.8).. I accept it is bit > harsh on R2's part in doing so, but this is what the RFC says.... > > The original question was Whether R2 can put packets from some other guy > R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out > that no it can't do so. IMO R2 can do so.. whether it does or not is > implementation choice and standards don't prevent that. > > > --- R1 --- R2 --- R3 --- > | > R4 > > > > btw there is a syntax error in ur mail in follwing para. "No matching > brackets". :-) > > regards, > > -abhijit > > >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the > >IPv4 explicit NULL label (indicating that it will egress packets destined > >for addresses matching this FEC. In any case, R1's requesting a label > >R2 was not intended to cause R2 to ingress packets for this FEC (so an > >FTN would not be created for this FEC, but for different reasons than are > >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for > >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and > >- possibly - assign those packets to an LSP corresponding to the FEC > >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > > > >-- > >Eric Gray From owner-mpls@UU.NET Fri Jun 8 10:36:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13237 for ; Fri, 8 Jun 2001 10:36:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksnq23894; Fri, 8 Jun 2001 14:36:12 GMT Received: by mail-control.mail.uu.net id QQksnq18160 for mpls-outgoing; Fri, 8 Jun 2001 14:35:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksnq18128 for ; Fri, 8 Jun 2001 14:35:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQksnq11567 for ; Fri, 8 Jun 2001 14:33:30 GMT Received: from p-mail2.cnet.fr by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQksnq03593 for ; Fri, 8 Jun 2001 14:33:30 GMT Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 16:33:28 +0200 Message-ID: <98388C05D464D111B61800805F150416029AB372@p-ibis.rd.francetelecom.fr> From: zze-PELLE Thierry StagiaireFTRD/DAC/ISS To: "'mpls@uu.net'" Subject: How LDP know the LSP? Date: Fri, 8 Jun 2001 16:33:27 +0200 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 Hello, In RFC 3036, p. 101, it is written "Does LSR have a previously received label mapping for FEC from MsgSource for the LSP in question?". I can't figure how the LSR is able to link the FEC to a LSP (in non-merging case of course). Hope you can help, Thierry From owner-mpls@UU.NET Fri Jun 8 10:52:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13617 for ; Fri, 8 Jun 2001 10:52:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksnr22096; Fri, 8 Jun 2001 14:50:25 GMT Received: by mail-control.mail.uu.net id QQksnr19710 for mpls-outgoing; Fri, 8 Jun 2001 14:49:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksnr19695 for ; Fri, 8 Jun 2001 14:49:33 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 QQksnr09688 for ; Fri, 8 Jun 2001 14:47:37 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQksnr18935 for ; Fri, 8 Jun 2001 14:47:35 GMT Received: (qmail 15347 invoked from network); 8 Jun 2001 14:40:11 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 8 Jun 2001 14:40:11 -0000 Received: from bharati.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id UAA15560; Fri, 8 Jun 2001 20:18:27 +0530 (IST) Received: from localhost (gabhijit@localhost) by bharati.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id UAA06543; Fri, 8 Jun 2001 20:18:35 +0530 X-Authentication-Warning: bharati.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Fri, 8 Jun 2001 20:18:35 +0530 (IST) From: Abhijit Gadgil To: Vijayanand C cc: , "Vijayc@Indya. Com" Subject: RE: Few questions related to LDP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Vijay, >Abhijit, > >What you are saying according to option 2 is - even if an LSR does'nt have >an exact match for an FEC , if it has a matching address prefix, it should >enable LSP set up. What will be the FEC element that R2/next hop of static >route propagate to its next hop. The matching prefix FEC element or the >original static route FEC element itself? This new semantic(if you use >static route FEC element which is not present in any of the FEC tables of >the LSRs) has to be understood by all the routers upto the LSP termination. >If you use the matching address prefix, then the intention of creating a >static route (which may be to introduce a new FEC for the static route) may >be lost. > I think R2 will terminate the LSP, and initiate a new LSP further down the line acting as ingress for p.q.0.0/16 here. (Note that this is not quite advisable). >If a lot of operators start introducing static routes like this you also >run into scalability problems, as the purpose of address heirarchy may be >lost and the number of entries in the FEC table (not route table as you >don't want to advertise these routes) may grow. > I am certainly not "for" adding static routes like that. Infact they can cause problems as has been discussed so far. I was just pointing to the case when entries like that will be present in R1 and R2s routing table, apart from the transients. I agree that was quite a contrived case. But in case if such scenario occurs, the best will be for R2 to give a NO_ROUTE and if required handle those packets in IP, than putting them on LSP. Is that fine so far? -abhijit >Correct me if I am wrong > >Regards, >Vijay > > >-----Original Message----- >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Abhijit >Gadgil >Sent: Friday, June 08, 2001 4:11 PM >To: Nagendra Singh Tomar >Cc: Vijayanand C; mpls@UU.NET >Subject: RE: Few questions related to LDP > > > > > L1 > > R1-----R2-----R3-----|p.q.r.0/24| > > | > > |L2 > > | > > |p.q.s.0/24| > > > > > >Assuming the above network has reached a quiescent state, so routing > >table at R2 will have 2 entries each for p.q.r.0/24 and p.q.s.0/24, > >suppose it also has p.q.0.0/16, then if the link L1 goes down and R3 > >senses that it can no longer reach p.q.r.0/24 thru L1, it will send a > >route update to that effect. During the time this update leaves R3 and > >reaches R2, we will have the routing tables as discussed in the previous > >few mails. > >Am I clear ??? > >Not really... atleast to me :-) > >The one reason why entries described so will be there is as follows as I >can see. R2 does "aggregation" (or gets "aggregated" information) and >sends p.q.0.0/16, to R1. But there is a smart administrator who's sitting >at R1 and adds an explicit route to p.q.r.0/24 with R2 as a gateway >(ofcourse for reasons known only to her). and then R1 requests for >p.q.r.0/24. > >In that case one of the following can happen > >1. R2 recognizes p.q.r.0/24 and so does R3.. Nice and LSP will be created. >There _can_ also be an _FTN_ entry in R2. > >2. R2 recognizes only p.q.0.0/16 but is somewhat _smart_ (read as >generous) and decides on his own to anyway let R1 create an LSP through >it. It will create so in a manner described in previous mail (ie the two >LSPs) > >Is anything still missing? > >-abhijit > From owner-mpls@UU.NET Fri Jun 8 11:00:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13769 for ; Fri, 8 Jun 2001 11:00:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksnr01531; Fri, 8 Jun 2001 14:58:46 GMT Received: by mail-control.mail.uu.net id QQksnr20467 for mpls-outgoing; Fri, 8 Jun 2001 14:58:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksnr20456 for ; Fri, 8 Jun 2001 14:57: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 QQksnr26508 for ; Fri, 8 Jun 2001 14:56:37 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mailhost.iitb.ac.in [203.197.74.142]) id QQksnr29100 for ; Fri, 8 Jun 2001 14:56:36 GMT Received: (qmail 15711 invoked from network); 8 Jun 2001 14:49:12 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 8 Jun 2001 14:49:12 -0000 Received: from bharati.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id UAA15847; Fri, 8 Jun 2001 20:27:28 +0530 (IST) Received: from localhost (gabhijit@localhost) by bharati.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id UAA07206; Fri, 8 Jun 2001 20:27:39 +0530 X-Authentication-Warning: bharati.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Fri, 8 Jun 2001 20:27:39 +0530 (IST) From: Abhijit Gadgil To: Eric Gray cc: Nagendra Singh Tomar , Subject: Re: Few questions related to LDP In-Reply-To: <3B20DA3B.D57543A8@sandburst.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Eric, If I understand what u have stated correctly, R2 would send mapping for p.q.r.0/24 only when R1 _requests_ so. Will it not be best on R2s part to send NO_ROUTE notification in that case? But I am still not quite clear why R2 won't send mapping for p.q.0.0/16 unsolicitedly as u have pointed out? regards, -abhijit On Fri, 8 Jun 2001, Eric Gray wrote: >Abhijit, > > Sorry, forgot to 'lint' my email message. > > I believe your premise may be incorrect below: R2 is likely not to >distribute a label mapping for p.q.0.0/16 since it may know what the >routing topology looks like from R1's perspective. Even if R2 does >distribute this mapping, R1 is free to release the one it can't use and >ask for a different one it can use (with p.q.r.0/24). > > The use of the word 'exact' in section 3.5.8 seems problematic. I >believe the word 'unambiguous' would have been better. If you look >at the procedures for handling a label request, the test (LRq.2, page >97) only checks if there is a next hop for the requested FEC, and there >is. Okay, so you have to work a little harder to figure that out. So? > > Note that this would not be the case if R1 and R2 had these route >entries in reverse (i.e. R1 shows R2 as the next hop for p.q.0.0/16 and >R2 shows R3 as the next hop for p.q.r.0/24). In that case, R2 could not >find an unambiguous next hop for the FEC p.q.0.0/16 requested by R1. > >-- >Eric Gray > >You wrote: > >> Eric, >> >> If R2 is distributing bindings unsolicitedly, it will always distribute >> bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not >> have entry for that FEC in its routing table. >> >> And R2 can send Mapping for label request p.q.r.0/24 when it receives >> explicitely such request and in that case it MUST send a No Route >> Notification.(according to rfc3036 section 3.5.8).. I accept it is bit >> harsh on R2's part in doing so, but this is what the RFC says.... From owner-mpls@UU.NET Fri Jun 8 11:12:51 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14003 for ; Fri, 8 Jun 2001 11:12:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksns09814; Fri, 8 Jun 2001 15:09:36 GMT Received: by mail-control.mail.uu.net id QQksns04390 for mpls-outgoing; Fri, 8 Jun 2001 15:09:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksns03748 for ; Fri, 8 Jun 2001 15:08:44 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 QQksns15954 for ; Fri, 8 Jun 2001 15:07:56 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQksns11638 for ; Fri, 8 Jun 2001 15:07:55 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ52Q0XM; Fri, 8 Jun 2001 20:50:48 +0530 Received: from MALLIKPC ([192.168.232.162]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2D4W0; Fri, 8 Jun 2001 20:35:51 +0530 From: "gopinathg" To: , Subject: Modification of Traffic Resources Date: Fri, 8 Jun 2001 20:45:47 +0530 Message-ID: <001201c0f02d$e5855910$a2e8a8c0@hclt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello all How to modify Traffic Resources for an Established LSP ? If it is with Request Message using ActFlag (0001- modify LSP) then, Do we need to use ERTLV again ? ( ie Initial setup is done using ERTLV) Thanks In Advice gopinathg From owner-mpls@UU.NET Fri Jun 8 14:21:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18563 for ; Fri, 8 Jun 2001 14:21:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksof25543; Fri, 8 Jun 2001 18:19:30 GMT Received: by mail-control.mail.uu.net id QQksof28719 for mpls-outgoing; Fri, 8 Jun 2001 18:18:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksof28661 for ; Fri, 8 Jun 2001 18:18:34 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 QQksof15416 for ; Fri, 8 Jun 2001 18:17:19 GMT Received: from mail.pantheranetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.timetra.com [63.104.212.2]) id QQksof15651 for ; Fri, 8 Jun 2001 18:17:19 GMT Received: from TIMETRANZVCSJA ([192.168.200.1]) by mail.pantheranetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-66622U100L100S0V35) with SMTP id com for ; Fri, 8 Jun 2001 11:13:31 -0700 From: vkompella@timetra.com (Vach Kompella) To: Subject: LDP's optional Transport Address TLV in the Hello Message Date: Fri, 8 Jun 2001 11:12:43 -0700 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Suppose I want this Transport Address TLV sent out in the Hello message. If the default behavior is to use the loopback address, then which MIB table holds this info that there is an override Transport address? It is not in the Entity table. How do I know, as I initiate Discovery that I should use this TLV? It's a per interface thing, so I guess there is no convenient place to hang it. One possibility would be a field in the Entity that says mplsHelloTransportAddressFlag or something that is either enabled or disabled, so that either the interface or loopback address is used when Hellos start flying. I apologize if this has already been hashed out, but I couldn't find anything on it in the archives. -Vach From owner-mpls@UU.NET Fri Jun 8 14:40:19 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18800 for ; Fri, 8 Jun 2001 14:40:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksog16956; Fri, 8 Jun 2001 18:39:09 GMT Received: by mail-control.mail.uu.net id QQksog01118 for mpls-outgoing; Fri, 8 Jun 2001 18:38:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksog01091 for ; Fri, 8 Jun 2001 18:38: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 QQksog17348 for ; Fri, 8 Jun 2001 18:38:03 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQksog17048 for ; Fri, 8 Jun 2001 18:38:02 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f58Ic4U23568 for ; Fri, 8 Jun 2001 11:38:05 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA01442 for mpls@uu.net; Fri, 8 Jun 2001 14:38:00 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksof28488 for ; Fri, 8 Jun 2001 18:16: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 QQksof14230 for ; Fri, 8 Jun 2001 18:16:14 GMT Received: from thumper.research.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQksof17032 for ; Fri, 8 Jun 2001 18:16:14 GMT Received: from shannon.research.telcordia.com (shannon [128.96.73.2]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f58IG9u15845; Fri, 8 Jun 2001 14:16:09 -0400 (EDT) Received: from kliu (kliu.research.telcordia.com [128.96.73.134]) by shannon.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA04886; Fri, 8 Jun 2001 14:16:09 -0400 (EDT) Date: Fri, 8 Jun 2001 14:16:08 -0400 (EDT) From: Kevin Liu X-X-Sender: To: cc: Subject: [IP-Optical] GMPLS Scalability (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can the authors of this document w3.ietf.org/internet-drafts/draft-many-gmpls-architecture-00.txt comment on the following question posted yesterday? In the implementation I have seen, people delibrately separate MPLS or the FA from the IP (such as OSPF or the RA). In other words, IP usually thinks MPLS is only a VALUE-ADDED SERVICE. So the question is how scalable the GMPLS FA is. Thanks very much, -- Kevin Liu p.s. I am not on the list of mpls@uu.net. ---------- Forwarded message ---------- Date: Thu, 7 Jun 2001 16:54:08 -0400 (EDT) From: Kevin Liu To: ip-optical@lists.bell-labs.com Subject: [IP-Optical] GMPLS Scalability The GMPLS architecture Internet draft mentioned a Forwarding Adjacencies (FA) in addition to the Routing Adjacencies (RA). The FA is formed by LSPs e.g. the non-PSC circuits. My question is on the scalability of the FA. If OSPF maintains both RA and FA, how do we address the following problems. * FA may need to support N^2 connectivity (i.e. the full mesh). * FA is more dynamic than physical topology and soft state LSP reservation tends to generate lots of control traffic. * can someone give an example of how the RA hierarchy can be formed. -- Kevin Liu _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Sat Jun 9 08:35:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13678 for ; Sat, 9 Jun 2001 08:35:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksra11756; Sat, 9 Jun 2001 12:35:50 GMT Received: by mail-control.mail.uu.net id QQksra15261 for mpls-outgoing; Sat, 9 Jun 2001 12:35:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksra15248 for ; Sat, 9 Jun 2001 12:35: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 QQksra17391 for ; Sat, 9 Jun 2001 12:34:33 GMT Received: from www0q.netaddress.usa.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: www0q.netaddress.usa.net [204.68.24.46]) id QQksra09711 for ; Sat, 9 Jun 2001 12:34:33 GMT Received: (qmail 15695 invoked by uid 60001); 9 Jun 2001 12:34:32 -0000 Message-ID: <20010609123432.15694.qmail@www0q.netaddress.usa.net> Received: from 204.68.24.46 by www0q for [61.11.13.158] via web-mailer(34FM.0700.17C.01) on Sat Jun 9 12:34:32 GMT 2001 Date: 9 Jun 2001 06:34:32 MDT From: Vijayendra Sharma To: mpls@UU.NET Subject: pinging problem............help required X-Mailer: USANET web-mailer (34FM.0700.17C.01) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13678 Hello sir, Can anyone help me with this problem, Will machines A and B able to ping eachother...???? A B 1)192.168.0.1/16-----Hub------192.168.0.2/24 2)192.168.0.1/16-----Switch------192.168.0.2/24 3)192.168.0.1/16-----Router------192.168.0.2/24 i will be helpful to you, if you can help me in anyway. regards, Vijayendra. ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-mpls@UU.NET Sat Jun 9 23:51:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24590 for ; Sat, 9 Jun 2001 23:51:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkstj07179; Sun, 10 Jun 2001 03:51:45 GMT Received: by mail-control.mail.uu.net id QQkstj12191 for mpls-outgoing; Sun, 10 Jun 2001 03:51:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkstj12145 for ; Sun, 10 Jun 2001 03:50:55 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 QQkstj18645 for ; Sun, 10 Jun 2001 03:50:41 GMT Received: from osf1.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQkstj05989 for ; Sun, 10 Jun 2001 03:50:41 GMT Received: from localhost (hsong@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id XAA28140; Sat, 9 Jun 2001 23:50:38 -0400 (EDT) Date: Sat, 9 Jun 2001 23:50:38 -0400 (EDT) From: Haoxin Song To: Vijayendra Sharma cc: mpls@UU.NET Subject: Re: pinging problem............help required In-Reply-To: <20010609123432.15694.qmail@www0q.netaddress.usa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Vijayendra I think A and B are still belong to different network, although the network address is same (192.168.0.0) the network mask is different. So when connected by Hub, A and B can not ping each other. Switch and Router are used to connect different network so A B should be able to ping each other when configured correctly. Larry On 9 Jun 2001, Vijayendra Sharma wrote: > Hello sir, > Can anyone help me with this problem, > Will machines A and B able to ping eachother...???? > > A B > 1)192.168.0.1/16-----Hub------192.168.0.2/24 > > 2)192.168.0.1/16-----Switch------192.168.0.2/24 > > 3)192.168.0.1/16-----Router------192.168.0.2/24 > > i will be helpful to you, if you can help me in anyway. > regards, > Vijayendra. > > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > From owner-mpls@UU.NET Sun Jun 10 14:49:21 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12801 for ; Sun, 10 Jun 2001 14:49:21 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksvr08905; Sun, 10 Jun 2001 18:49:15 GMT Received: by mail-control.mail.uu.net id QQksvr06394 for mpls-outgoing; Sun, 10 Jun 2001 18:48:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksvr06381 for ; Sun, 10 Jun 2001 18:48:37 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 QQksvr15286 for ; Sun, 10 Jun 2001 18:48:23 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f174.law11.hotmail.com [64.4.17.174]) id QQksvr07098 for ; Sun, 10 Jun 2001 18:48:23 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 10 Jun 2001 11:48:22 -0700 Received: from 64.174.37.94 by lw11fd.law11.hotmail.msn.com with HTTP; Sun, 10 Jun 2001 18:48:22 GMT X-Originating-IP: [64.174.37.94] From: "krishna mohan doddapaneni" To: mpls@UU.NET Subject: Per-interface/Per-platform Lable space Date: Sun, 10 Jun 2001 18:48:22 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 10 Jun 2001 18:48:22.0746 (UTC) FILETIME=[ECB0F3A0:01C0F1DD] Sender: owner-mpls@UU.NET Precedence: bulk
Hi,
Is it possible for the same LSR to maintain per-interface label spaces and per-platform label spaces? If it is so can the label spaces overlap?
Thanks in advance,
Krishna

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

From owner-mpls@UU.NET Mon Jun 11 00:07:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18480 for ; Mon, 11 Jun 2001 00:07:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksxc18356; Mon, 11 Jun 2001 04:07:06 GMT Received: by mail-control.mail.uu.net id QQksxc07628 for mpls-outgoing; Mon, 11 Jun 2001 04:06:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksxc07546 for ; Mon, 11 Jun 2001 04:06: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 QQksxc19829 for ; Mon, 11 Jun 2001 04:05:41 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksxc02137 for ; Mon, 11 Jun 2001 04:05:40 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5B46nG14866; Mon, 11 Jun 2001 09:36:49 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A68.001517BB ; Mon, 11 Jun 2001 09:20:23 +0530 X-Lotus-FromDomain: HSS To: "krishna mohan doddapaneni" cc: mpls@UU.NET Message-ID: <65256A68.00150FBA.00@sandesh.hss.hns.com> Date: Mon, 11 Jun 2001 09:20:01 +0530 Subject: Re: Per-interface/Per-platform Lable space Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi krishna! Well to answer your I would like to say that it is possible to have a combination such as - Suppose for a given LSR you have N interfaces and M label spaces (M <= N) Then it is possible to have a combination that any sub-set of interfaces (MPLS interfaces) share the same label space. whether you call them per-interface or per-platform is ur call(I would choose to call them none). The combination of the set of interfaces that share a label space is totally a local matter as it primarily depends on hardware and software constraints(ability to distinguish between labels received from different interfaces and ATM VCI/VPI which are generally per-interface spaces). hope it helps! regards sumit "krishna mohan doddapaneni" on 06/11/2001 12:18:22 AM To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: Per-interface/Per-platform Lable space Hi, Is it possible for the same LSR to maintain per-interface label spaces and per-platform label spaces? If it is so can the label spaces overlap? Thanks in advance, Krishna From owner-mpls@UU.NET Mon Jun 11 00:11:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18510 for ; Mon, 11 Jun 2001 00:11:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksxc25953; Mon, 11 Jun 2001 04:11:15 GMT Received: by mail-control.mail.uu.net id QQksxc08115 for mpls-outgoing; Mon, 11 Jun 2001 04:10:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksxc08096 for ; Mon, 11 Jun 2001 04:10:33 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 QQksxc16581 for ; Mon, 11 Jun 2001 04:10:11 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQksxc23498 for ; Mon, 11 Jun 2001 04:10:09 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 11 Jun 2001 09:46:43 +0530 Received: from saumyad (saumyad.future.futsoft.com [10.20.6.42]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f5B49pO06277 for ; Mon, 11 Jun 2001 09:39:51 +0530 Reply-To: From: "saumyad" To: Subject: Notify message Date: Mon, 11 Jun 2001 09:42:57 +1000 Message-Id: <000001c0f207$144f2d40$2a06140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Could anyone explain please whats the use of "notify message" (as specified in the GMPLS-RSVPTE draft), except that we can use it for "targetted notification". Regards, Saumya Dikshit. From owner-mpls@UU.NET Mon Jun 11 00:56:55 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18744 for ; Mon, 11 Jun 2001 00:56:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksxf26433; Mon, 11 Jun 2001 04:56:47 GMT Received: by mail-control.mail.uu.net id QQksxf11835 for mpls-outgoing; Mon, 11 Jun 2001 04:56:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksxf11774 for ; Mon, 11 Jun 2001 04:55: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 QQksxf23592 for ; Mon, 11 Jun 2001 04:55:18 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQksxf05419 for ; Mon, 11 Jun 2001 04:55:17 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ52RK72; Mon, 11 Jun 2001 10:38:18 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2DW4Q; Mon, 11 Jun 2001 10:23:12 +0530 From: "Vijayanand C" To: "Eric Gray" Cc: , Subject: RE: Few questions related to LDP Date: Mon, 11 Jun 2001 10:29:44 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3B20DA3B.D57543A8@sandburst.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, The idea of your unambiguos match as against the usual exact match(or even the prefix match) is a little confusing.How can p.q.r.0/24 be a match for p.q.0.0/16 ? It is neither a prefix nor an exact match. Please correct me if I am wrong. Vijay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Eric Gray Sent: Friday, June 08, 2001 7:29 PM To: Abhijit Gadgil Cc: Nagendra Singh Tomar; mpls@UU.NET Subject: Re: Few questions related to LDP Abhijit, Sorry, forgot to 'lint' my email message. I believe your premise may be incorrect below: R2 is likely not to distribute a label mapping for p.q.0.0/16 since it may know what the routing topology looks like from R1's perspective. Even if R2 does distribute this mapping, R1 is free to release the one it can't use and ask for a different one it can use (with p.q.r.0/24). The use of the word 'exact' in section 3.5.8 seems problematic. I believe the word 'unambiguous' would have been better. If you look at the procedures for handling a label request, the test (LRq.2, page 97) only checks if there is a next hop for the requested FEC, and there is. Okay, so you have to work a little harder to figure that out. So? Note that this would not be the case if R1 and R2 had these route entries in reverse (i.e. R1 shows R2 as the next hop for p.q.0.0/16 and R2 shows R3 as the next hop for p.q.r.0/24). In that case, R2 could not find an unambiguous next hop for the FEC p.q.0.0/16 requested by R1. -- Eric Gray You wrote: > Eric, > > If R2 is distributing bindings unsolicitedly, it will always distribute > bindings for p.q.0.0/16 and won't distribute for p.q.r.0/24 as it does not > have entry for that FEC in its routing table. > > And R2 can send Mapping for label request p.q.r.0/24 when it receives > explicitely such request and in that case it MUST send a No Route > Notification.(according to rfc3036 section 3.5.8).. I accept it is bit > harsh on R2's part in doing so, but this is what the RFC says.... > > The original question was Whether R2 can put packets from some other guy > R4(pls see below), onto the LSP R1-R2-R3. To which someone has pointed out > that no it can't do so. IMO R2 can do so.. whether it does or not is > implementation choice and standards don't prevent that. > > > --- R1 --- R2 --- R3 --- > | > R4 > > > > btw there is a syntax error in ur mail in follwing para. "No matching > brackets". :-) > > regards, > > -abhijit > > >If R1 requests a label from R2 for the FEC p.q.r.0/24, R2 could return the > >IPv4 explicit NULL label (indicating that it will egress packets destined > >for addresses matching this FEC. In any case, R1's requesting a label > >R2 was not intended to cause R2 to ingress packets for this FEC (so an > >FTN would not be created for this FEC, but for different reasons than are > >indicated in Abhijit's reply). R2's giving R1 an implicit NULL label for > >FEC p.q.r.0/24 allows R2 to examine unlabled packets for this FEC and > >- possibly - assign those packets to an LSP corresponding to the FEC > >p.q.0.0/16. For this LSP, R2 could have an FTN and ingress packets. > > > >-- > >Eric Gray From owner-mpls@UU.NET Mon Jun 11 03:18:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04187 for ; Mon, 11 Jun 2001 03:18:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksxp12315; Mon, 11 Jun 2001 07:17:56 GMT Received: by mail-control.mail.uu.net id QQksxp21845 for mpls-outgoing; Mon, 11 Jun 2001 07:17:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksxp21832 for ; Mon, 11 Jun 2001 07:17: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 QQksxp28238 for ; Mon, 11 Jun 2001 07:16:22 GMT Received: from smtp2.cluster.oleane.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQksxp28485 for ; Mon, 11 Jun 2001 07:16:21 GMT Received: from oleane (dyn-1-1-063.Vin.dialup.oleane.fr [195.25.4.63]) by smtp2.cluster.oleane.net with SMTP id f5B7GCI35922 for ; Mon, 11 Jun 2001 09:16:16 +0200 (CEST) Message-ID: <012301c0f246$5bd21120$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World 2002 Date: Mon, 11 Jun 2001 09:15:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0120_01C0F257.18CF76E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0120_01C0F257.18CF76E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The call for proposals for MPLS World 2002, to be held in Paris February = from 5 to 8, is on-line on the following URL: http://www.upperside.fr/congress02/mplsworld2002.htm The dead line for turning in abstracts is July 30. ------=_NextPart_000_0120_01C0F257.18CF76E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The call for proposals for MPLS World = 2002,=20 to be held in Paris February from 5 to 8, is on-line on the following=20 URL:
http://www.= upperside.fr/congress02/mplsworld2002.htm
The dead line for turning in abstracts is July=20 30.
 
 
------=_NextPart_000_0120_01C0F257.18CF76E0-- From owner-mpls@UU.NET Mon Jun 11 05:14:07 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05089 for ; Mon, 11 Jun 2001 05:14:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksxw28204; Mon, 11 Jun 2001 09:13:59 GMT Received: by mail-control.mail.uu.net id QQksxw09759 for mpls-outgoing; Mon, 11 Jun 2001 09:13:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksxw09716 for ; Mon, 11 Jun 2001 09:13:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQksxw08773 for ; Mon, 11 Jun 2001 09:12:57 GMT Received: from p-mail1.cnet.fr by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail1.rd.francetelecom.fr [193.49.124.31]) id QQksxw19106 for ; Mon, 11 Jun 2001 09:12:56 GMT Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 11:02:24 +0200 Message-ID: <98388C05D464D111B61800805F150416029AB375@p-ibis.rd.francetelecom.fr> From: zze-PELLE Thierry StagiaireFTRD/DAC/ISS To: "'jleu@mindspring.com'" , zze-PELLE Thierry StagiaireFTRD/DAC/ISS Cc: mpls@UU.NET Subject: RE: How LDP know the LSP? Date: Mon, 11 Jun 2001 11:02:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Somes remarks to know if I understand well. > When I receive a mapping it fits one of the following: > -this is the first mapping I have seen, either requested or > unsolicited In this case, as you say, there is no LSP for this FEC, the LSP is created and propaged upstream or downstream depending if the mapping is requested or unsolicited. > -this is NOT the first and I should have a pending requested for it, > but if if don't ... > -this is a duplicate unsolicited mapping So you mean that in Non Merging case, an LSP cannot be setup from downstream to upstream by unsolicited messaged. If an LSP exists, the next ones MUST be requested. > So the only case you run into problems is if you receive multiple > unsolicited mappings from your peer. In which case you fall > through to LMp.11. ????? LMp.11 ?????? > PS you can look at the ldp-portable package at > http://mpls-linux.sf.net/ > to see how I have implemented it. I will. Ta From owner-mpls@UU.NET Mon Jun 11 05:54:19 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05460 for ; Mon, 11 Jun 2001 05:54:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksxz14820; Mon, 11 Jun 2001 09:54:29 GMT Received: by mail-control.mail.uu.net id QQksxz13509 for mpls-outgoing; Mon, 11 Jun 2001 09:53:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksxz13501 for ; Mon, 11 Jun 2001 09:53:44 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 QQksxz25579 for ; Mon, 11 Jun 2001 09:52:55 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksxz03215 for ; Mon, 11 Jun 2001 09:52:54 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5B9sAW05410 for ; Mon, 11 Jun 2001 15:24:10 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A68.0034E4A8 ; Mon, 11 Jun 2001 15:07:44 +0530 X-Lotus-FromDomain: HSS To: mpls@UU.NET Message-ID: <65256A68.0034E1EF.00@sandesh.hss.hns.com> Date: Mon, 11 Jun 2001 15:07:36 +0530 Subject: Error in RFC 3036?? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi all! I think there is a slight error in RFC 3036. Pg 97 Algorithm LRq.1 If Loop Detected , got to LRq.13. IMHO, should it not be If Loop Detected , got to LRq.5 regards sumit PS - Sorry if anyone has already pointed this out. From owner-mpls@UU.NET Mon Jun 11 06:10:20 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05556 for ; Mon, 11 Jun 2001 06:10:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksya01754; Mon, 11 Jun 2001 10:10:07 GMT Received: by mail-control.mail.uu.net id QQksya04170 for mpls-outgoing; Mon, 11 Jun 2001 10:09:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksya04109 for ; Mon, 11 Jun 2001 10:09:01 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 QQksya29442 for ; Mon, 11 Jun 2001 10:08:41 GMT Received: from mailgw.local.ipunplugged.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.88.134.217]) id QQksya00146 for ; Mon, 11 Jun 2001 10:08:41 GMT Received: from HANSPC (a7.local.ipunplugged.com [192.168.4.177]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA15852; Mon, 11 Jun 2001 12:10:28 +0200 From: =?iso-8859-1?Q?Hans_Sj=F6strand?= To: "Vach Kompella" , Cc: Subject: RE: LDP's optional Transport Address TLV in the Hello Message Date: Mon, 11 Jun 2001 12:06:52 +0200 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.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nobody raised the requirement to configure this specifically for LDP, so LDP adheres to the general policies regarding wheither to use loopback or local addreses. For plattform label space I guess this is not an issue, and for interface label space default is normally to use the interface addess. I've seen the Transport Address TLV more as a mean to ensure that your default-address-selection setting doesn't screw up your peer Transport address bindings. Not as a configurable option. This I belive is also the opinion among the communiuty at large since the mib has been through some last calls. I'm reluctant to add new features to the mib at this late stage in the rfc publishing process. Regards /// Hasse > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vach > Kompella > Sent: den 8 juni 2001 20:13 > To: mpls@UU.NET > Subject: LDP's optional Transport Address TLV in the Hello Message > > > Suppose I want this Transport Address TLV sent out in the Hello > message. If > the default behavior is to use the loopback address, then which MIB table > holds this info that there is an override Transport address? > > It is not in the Entity table. How do I know, as I initiate > Discovery that > I should use this TLV? > > It's a per interface thing, so I guess there is no convenient > place to hang > it. One possibility would be a field in the Entity that says > mplsHelloTransportAddressFlag or something that is either enabled or > disabled, so that either the interface or loopback address is used when > Hellos start flying. > > I apologize if this has already been hashed out, but I couldn't find > anything on it in the archives. > > -Vach From owner-mpls@UU.NET Mon Jun 11 06:15:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05587 for ; Mon, 11 Jun 2001 06:15:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyb29486; Mon, 11 Jun 2001 10:15:40 GMT Received: by mail-control.mail.uu.net id QQksyb04966 for mpls-outgoing; Mon, 11 Jun 2001 10:15:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksya04905 for ; Mon, 11 Jun 2001 10:14:54 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 QQksya28489 for ; Mon, 11 Jun 2001 10:14:42 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksya28512 for ; Mon, 11 Jun 2001 10:14:40 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5BAFuS06429 for ; Mon, 11 Jun 2001 15:45:56 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A68.0036E3DD ; Mon, 11 Jun 2001 15:29:32 +0530 X-Lotus-FromDomain: HSS To: mpls@UU.NET Message-ID: <65256A68.0036E083.00@sandesh.hss.hns.com> Date: Mon, 11 Jun 2001 15:29:23 +0530 Subject: RE: Error in RFC 3036?? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk yup sorry! LRq.4 it is. typo ;o) "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on 06/11/2001 03:27:43 PM To: Sumit Chauhan/HSS@HSS, mpls@UU.NET cc: Subject: RE: Error in RFC 3036?? > IMHO, should it not be > If Loop Detected , got to LRq.5 LRq.4 and not LRq.5 I think.... From owner-mpls@UU.NET Mon Jun 11 06:42:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05841 for ; Mon, 11 Jun 2001 06:42:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyc20722; Mon, 11 Jun 2001 10:41:26 GMT Received: by mail-control.mail.uu.net id QQksyc06919 for mpls-outgoing; Mon, 11 Jun 2001 10:40:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksyc06911 for ; Mon, 11 Jun 2001 10:40:47 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 QQksyc05724 for ; Mon, 11 Jun 2001 10:40:24 GMT Received: from p-mail2.cnet.fr by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQksyc24356 for ; Mon, 11 Jun 2001 10:40:23 GMT Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 11:57:43 +0200 Message-ID: <98388C05D464D111B61800805F150416029AB376@p-ibis.rd.francetelecom.fr> From: zze-PELLE Thierry StagiaireFTRD/DAC/ISS To: "'suchauhan@hss.hns.com'" , mpls@UU.NET Subject: RE: Error in RFC 3036?? Date: Mon, 11 Jun 2001 11:57:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > IMHO, should it not be > If Loop Detected , got to LRq.5 LRq.4 and not LRq.5 I think.... From owner-mpls@UU.NET Mon Jun 11 06:50:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05920 for ; Mon, 11 Jun 2001 06:50:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyd13129; Mon, 11 Jun 2001 10:49:52 GMT Received: by mail-control.mail.uu.net id QQksyd07898 for mpls-outgoing; Mon, 11 Jun 2001 10:49:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksyd07889 for ; Mon, 11 Jun 2001 10:49:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQksyd26888 for ; Mon, 11 Jun 2001 10:47:40 GMT Received: from localhost.localdomain by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQksyd10690 for ; Mon, 11 Jun 2001 10:47:37 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f5BApDq32206; Mon, 11 Jun 2001 16:21:13 +0530 Date: Mon, 11 Jun 2001 16:21:13 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: suchauhan@hss.hns.com cc: mpls@UU.NET Subject: RE: Error in RFC 3036?? In-Reply-To: <65256A68.0036E083.00@sandesh.hss.hns.com> Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk If the node detects a loop in the label request message, the its wise not to send the loop detected notification, because that might in turn loop and make the network conditions worse. In the LRq.2 case the loop is not detected in the label request message so we are sure that the return path for the notification message has no loop, so it is safe to send a notification in that case. --tomar On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > yup sorry! LRq.4 it is. typo ;o) > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on > 06/11/2001 03:27:43 PM > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > cc: > > Subject: RE: Error in RFC 3036?? > > > > > > IMHO, should it not be > > If Loop Detected , got to LRq.5 > > LRq.4 and not LRq.5 I think.... > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Mon Jun 11 07:22:10 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06415 for ; Mon, 11 Jun 2001 07:22:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyf17568; Mon, 11 Jun 2001 11:22:16 GMT Received: by mail-control.mail.uu.net id QQksyf00105 for mpls-outgoing; Mon, 11 Jun 2001 11:21:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksyf00088 for ; Mon, 11 Jun 2001 11:21:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQksyf14900 for ; Mon, 11 Jun 2001 11:20:55 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQksyf16073 for ; Mon, 11 Jun 2001 11:20:54 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5BBLnG08869; Mon, 11 Jun 2001 16:51:49 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A68.003CE732 ; Mon, 11 Jun 2001 16:35:13 +0530 X-Lotus-FromDomain: HSS To: nagendras@netbrahma.com cc: mpls@UU.NET Message-ID: <65256A68.003CD8BB.00@sandesh.hss.hns.com> Date: Mon, 11 Jun 2001 16:34:35 +0530 Subject: RE: Error in RFC 3036?? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi nagendra! Thanx a lot for the reply! But I still think the problem (if any) will be there in both cases stated below and to me sending the error notification back should be the right approach as the loop can be handled at the source receiving the notification. regards sumit Nagendra Singh Tomar on 06/11/2001 04:21:13 PM Please respond to nagendras@netbrahma.com To: Sumit Chauhan/HSS@HSS cc: mpls@UU.NET Subject: RE: Error in RFC 3036?? If the node detects a loop in the label request message, the its wise not to send the loop detected notification, because that might in turn loop and make the network conditions worse. In the LRq.2 case the loop is not detected in the label request message so we are sure that the return path for the notification message has no loop, so it is safe to send a notification in that case. --tomar On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > yup sorry! LRq.4 it is. typo ;o) > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on > 06/11/2001 03:27:43 PM > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > cc: > > Subject: RE: Error in RFC 3036?? > > > > > > IMHO, should it not be > > If Loop Detected , got to LRq.5 > > LRq.4 and not LRq.5 I think.... > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Mon Jun 11 08:59:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09151 for ; Mon, 11 Jun 2001 08:59:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyl07003; Mon, 11 Jun 2001 12:59:06 GMT Received: by mail-control.mail.uu.net id QQksyl00966 for mpls-outgoing; Mon, 11 Jun 2001 12:58:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksyl00937 for ; Mon, 11 Jun 2001 12:58:12 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 QQksyl24475 for ; Mon, 11 Jun 2001 12:57:38 GMT Received: from osf1.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQksyl27899 for ; Mon, 11 Jun 2001 12:57:38 GMT Received: from localhost (hsong@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id IAA28531; Mon, 11 Jun 2001 08:57:36 -0400 (EDT) Date: Mon, 11 Jun 2001 08:57:36 -0400 (EDT) From: Haoxin Song To: Vijayendra Sharma cc: mpls@UU.NET Subject: Re: pinging problem............help required In-Reply-To: <20010609123432.15694.qmail@www0q.netaddress.usa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Sorry for previous reply. That's a mistake. On second thought, when connected by Hub or Switch, A and B should have the understanding that they are on the same subnet, so they can ping each other. When connected by router, router may have problem having overlapped ip address configured, so A and B can not ping. Thanks, Larry On 9 Jun 2001, Vijayendra Sharma wrote: > Hello sir, > Can anyone help me with this problem, > Will machines A and B able to ping eachother...???? > > A B > 1)192.168.0.1/16-----Hub------192.168.0.2/24 > > 2)192.168.0.1/16-----Switch------192.168.0.2/24 > > 3)192.168.0.1/16-----Router------192.168.0.2/24 > > i will be helpful to you, if you can help me in anyway. > regards, > Vijayendra. > > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > From owner-mpls@UU.NET Mon Jun 11 09:14:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09691 for ; Mon, 11 Jun 2001 09:14:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksym21270; Mon, 11 Jun 2001 13:14:13 GMT Received: by mail-control.mail.uu.net id QQksym21941 for mpls-outgoing; Mon, 11 Jun 2001 13:13:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksym21929 for ; Mon, 11 Jun 2001 13:13:25 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 QQksym16003 for ; Mon, 11 Jun 2001 13:12:07 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 QQksym19059 for ; Mon, 11 Jun 2001 13:12:06 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BDC6911388 for ; Mon, 11 Jun 2001 06:12:06 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02477 for mpls@uu.net; Mon, 11 Jun 2001 09:12:04 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksov13543 for ; Fri, 8 Jun 2001 22:17:03 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 QQksov28126 for ; Fri, 8 Jun 2001 22:16:51 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f254.law14.hotmail.com [64.4.20.129]) id QQksov08295 for ; Fri, 8 Jun 2001 22:16:51 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 8 Jun 2001 15:16:50 -0700 Received: from 38.204.3.195 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 08 Jun 2001 22:16:50 GMT X-Originating-IP: [38.204.3.195] From: "Raju Venkatraman" To: mpls@UU.NET, ccamp@ops.ietf.org Subject: Doubts on GMPLS Date: Fri, 08 Jun 2001 22:16:50 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Jun 2001 22:16:50.0468 (UTC) FILETIME=[B70C5E40:01C0F068] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I was just going through GMPLS drafts and I've some questions. Actually not able to understand few things. Any help would be greatly appreciated. * Should the signalling module (control plane) be aware of all the data channels/links under its control? In GMPLS, as it would be used in optical networks and a no. of interfaces would be present [not all carrying the signalling information] between GMPLS-enabled optical nodes, I don't feel it's required. The mapping of signalling link/channel(s) to data links/channels could be mainatained out. * Where one would like to maintain the diffserv related intelligence while setting up L-LSP and E-LSPs - would it would be assumed to be with routing module or signalling module? I know, these things vary from implementation to implmentation, but just wanted to hear your thoughts in this regard. Thanks in advance. Raju _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Mon Jun 11 09:19:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09888 for ; Mon, 11 Jun 2001 09:19:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyn08129; Mon, 11 Jun 2001 13:19:00 GMT Received: by mail-control.mail.uu.net id QQksyn22555 for mpls-outgoing; Mon, 11 Jun 2001 13:18:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksyn22493 for ; Mon, 11 Jun 2001 13:17:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQksym12758 for ; Mon, 11 Jun 2001 13:13:47 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQksym16068 for ; Mon, 11 Jun 2001 13:13:45 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BDDj912191 for ; Mon, 11 Jun 2001 06:13:45 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02517 for mpls@uu.net; Mon, 11 Jun 2001 09:13:44 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksvy25953 for ; Sun, 10 Jun 2001 20:40: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 QQksvy05918 for ; Sun, 10 Jun 2001 20:40:17 GMT Received: from web13103.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13103.mail.yahoo.com [216.136.174.148]) id QQksvy19536 for ; Sun, 10 Jun 2001 20:40:17 GMT Message-ID: <20010610204017.5093.qmail@web13103.mail.yahoo.com> Received: from [63.88.196.33] by web13103.mail.yahoo.com; Sun, 10 Jun 2001 13:40:17 PDT Date: Sun, 10 Jun 2001 13:40:17 -0700 (PDT) From: jet chang Subject: erro code 24 To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, there: Did anyone know what the error code 24 and error value 13 mean? I got this in a PathErr message. The RFC 2205 only list error code upto 23. Thanks Jet ===== Xinjie Chang CCDA,CCNA __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Mon Jun 11 09:20:04 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09917 for ; Mon, 11 Jun 2001 09:20:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyn10421; Mon, 11 Jun 2001 13:20:06 GMT Received: by mail-control.mail.uu.net id QQksyn22565 for mpls-outgoing; Mon, 11 Jun 2001 13:18:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksyn22470 for ; Mon, 11 Jun 2001 13:16:41 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 QQksym20258 for ; Mon, 11 Jun 2001 13:13:59 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQksym20955 for ; Mon, 11 Jun 2001 13:13:58 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5BDE3U02101 for ; Mon, 11 Jun 2001 06:14:03 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02521 for mpls@uu.net; Mon, 11 Jun 2001 09:13:57 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksxt17040 for ; Mon, 11 Jun 2001 08:29:15 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 QQksxt22710 for ; Mon, 11 Jun 2001 08:28:47 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f32.pav1.hotmail.com [64.4.31.32]) id QQksxt13078 for ; Mon, 11 Jun 2001 08:28:47 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 11 Jun 2001 01:28:47 -0700 Received: from 62.0.167.98 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 11 Jun 2001 08:28:47 GMT X-Originating-IP: [62.0.167.98] From: "Yaron Raz" To: mpls@UU.NET Subject: MPLS control plane frame format Date: Mon, 11 Jun 2001 11:28:47 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jun 2001 08:28:47.0037 (UTC) FILETIME=[88A7AED0:01C0F250] Sender: owner-mpls@UU.NET Precedence: bulk I could not find any specific information on the control frame format (OSPF, RSVP etc.) in the standards, but as far as I understand there are 2 ways of carrying the control plane data over Ethernet between LSRs which will not violate any standard: 1. dest MAC, source MAC, Ethertype = IP, IP data (No MPLS at all) 2. dest MAC, Source MAC, Ethertype = MPLS, MPLS label = 0 (IPv4), IP data Which one is the standrad way of doing it (or maybe there's a third)? _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From owner-mpls@UU.NET Mon Jun 11 09:20:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09944 for ; Mon, 11 Jun 2001 09:20:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyn28911; Mon, 11 Jun 2001 13:20:35 GMT Received: by mail-control.mail.uu.net id QQksyn22586 for mpls-outgoing; Mon, 11 Jun 2001 13:18:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksyn22002 for ; Mon, 11 Jun 2001 13:15: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 QQksym11429 for ; Mon, 11 Jun 2001 13:13:20 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQksym20240 for ; Mon, 11 Jun 2001 13:13:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5BDDOU01792 for ; Mon, 11 Jun 2001 06:13:24 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02513 for mpls@uu.net; Mon, 11 Jun 2001 09:13:17 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkssh12295 for ; Sat, 9 Jun 2001 20:48:58 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 QQkssh25090 for ; Sat, 9 Jun 2001 20:48:45 GMT Received: from web10008.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web10008.mail.yahoo.com [216.136.130.44]) id QQkssh07744 for ; Sat, 9 Jun 2001 20:48:44 GMT Message-ID: <20010609204844.97390.qmail@web10008.mail.yahoo.com> Received: from [63.116.202.66] by web10008.mail.yahoo.com; Sat, 09 Jun 2001 13:48:44 PDT Date: Sat, 9 Jun 2001 13:48:44 -0700 (PDT) From: Vishal Mishra Subject: Re: pinging problem............help required To: Vijayendra Sharma Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Vijay, In Machine A - 192.168.0.2 belongs to the network 192.168/16, so the ping packet would be transmitted out 192.168.0.1 interface without any expected problems. In Machine B - 192.168.0.1 belongs on the network 192.168.0/24, so the ping response would be transmitted out 192.168.0.2 interface without any expected problems. Since neither sending nor receiving ping packets seems to be a problem, so the Ping should succeed in ALL cases. Where is the catch :) ? Vishal. --- Vijayendra Sharma wrote: > Hello sir, > Can anyone help me with this problem, > Will machines A and B able to ping eachother...???? > > A B > 1)192.168.0.1/16-----Hub------192.168.0.2/24 > > 2)192.168.0.1/16-----Switch------192.168.0.2/24 > > 3)192.168.0.1/16-----Router------192.168.0.2/24 > > i will be helpful to you, if you can help me in anyway. > regards, > Vijayendra. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Mon Jun 11 09:21:55 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09996 for ; Mon, 11 Jun 2001 09:21:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyn12636; Mon, 11 Jun 2001 13:21:10 GMT Received: by mail-control.mail.uu.net id QQksyn22597 for mpls-outgoing; Mon, 11 Jun 2001 13:18:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQksym21995 for ; Mon, 11 Jun 2001 13:14:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQksym27781 for ; Mon, 11 Jun 2001 13:12:58 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQksym19897 for ; Mon, 11 Jun 2001 13:12:57 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5BDD2U01607 for ; Mon, 11 Jun 2001 06:13:02 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02507 for mpls@uu.net; Mon, 11 Jun 2001 09:12:55 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQksrc08053 for ; Sat, 9 Jun 2001 13:10:26 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 QQksrc25716 for ; Sat, 9 Jun 2001 13:09:30 GMT Received: from smtp014.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: smtp014.mail.yahoo.com [216.136.173.58]) id QQksrc11027 for ; Sat, 9 Jun 2001 13:09:30 GMT Received: from unknown (HELO sujeet) (203.200.4.2) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Jun 2001 13:09:29 -0000 X-Apparently-From: Message-ID: <001801c0f0e5$ce790ab0$2106010a@visecity> From: "Sujeet Mehta" To: Subject: hi Date: Sat, 9 Jun 2001 18:42:13 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C0F113.E5EB7560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C0F113.E5EB7560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi there i have installed mpls-2.3 version on my linux i m havinfg a problem with it when i try to run it giving the commands it says=20 111:connection refused=20 can u help me with this See ya later luv, Sujeet ulti_surd@yahoo.com sujeetmehta@excite.com smehta@velankani.com ph:- +91-80-8522507/9 extn.. 1633 fax :- +91-80-8522508 ------=_NextPart_000_0015_01C0F113.E5EB7560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi there
i have installed mpls-2.3 version on my = linux
i m havinfg a problem with = it
when i try to run it giving the=20 commands
it says
111:connection refused =
can u help me with this
See ya later
luv,
Sujeet
ulti_surd@yahoo.com
sujeetmehta@excite.com
smehta@velankani.com
ph:-=20 +91-80-8522507/9 extn.. 1633
fax :-=20 +91-80-8522508
------=_NextPart_000_0015_01C0F113.E5EB7560-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-mpls@UU.NET Mon Jun 11 09:25:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10108 for ; Mon, 11 Jun 2001 09:25:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyn20014; Mon, 11 Jun 2001 13:25:19 GMT Received: by mail-control.mail.uu.net id QQksyn23183 for mpls-outgoing; Mon, 11 Jun 2001 13:24:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksyn23171 for ; Mon, 11 Jun 2001 13:24: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 QQksyn16144 for ; Mon, 11 Jun 2001 13:24:08 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQksyn18052 for ; Mon, 11 Jun 2001 13:24:07 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 11 Jun 2001 19:00:46 +0530 Received: from srikn (srikn.future.futsoft.com [10.20.6.48]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f5BDNrO27623; Mon, 11 Jun 2001 18:53:53 +0530 Reply-To: From: "Srikanth" To: Cc: Subject: Doubt in mpls-generalized-cr-ldp-03.txt Date: Mon, 11 Jun 2001 18:55:24 +0530 Message-Id: <000f01c0f279$f99aa4c0$3006140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I have a doubt in Explicit Label Control In section 5.1 (Procedures), "........If the U-bit of the ER-Hop being examined is clear (0), then value of the label is copied into a new Label_Set TLV. This Label_Set TLV MUST be included on the corresponding outgoing MAPPING message..........." Topology : LSR X -------------- LSR Y Consider the scenario, LSR X is processing the Label ER-Hop ( LSR X is a part of the ER-Hop preceding the Label ER-Hop in the Hop List ). This label ER-Hop specifies the Label to be assigned by LSR Y ( not in the case of splicing ). To achieve this, LSR X has to construct the Label Set ( with just this label ) and send it to LSR Y. So the MAPPING in section 5.1 should be REQUEST. Please correct if i am wrong. Thanks in advance, Srikanth Narayanan. From owner-mpls@UU.NET Mon Jun 11 09:52:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10756 for ; Mon, 11 Jun 2001 09:52:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksyp01426; Mon, 11 Jun 2001 13:51:26 GMT Received: by mail-control.mail.uu.net id QQksyp26106 for mpls-outgoing; Mon, 11 Jun 2001 13:50:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksyp26094 for ; Mon, 11 Jun 2001 13:50:20 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 QQksyp10446 for ; Mon, 11 Jun 2001 13:50:02 GMT Received: from mason2.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQksyp03366 for ; Mon, 11 Jun 2001 13:50:02 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA20209; Mon, 11 Jun 2001 09:48:48 -0400 (EDT) Date: Mon, 11 Jun 2001 09:48:48 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: jet chang cc: mpls@UU.NET Subject: Re: erro code 24 In-Reply-To: <20010610204017.5093.qmail@web13103.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Jet, I think the value for the "Routing Problem" error code is 24. Error value of 13 means "Unknown object class" and this may appear in Path or Resv message. -Rajiv On Sun, 10 Jun 2001, jet chang wrote: > Hi, there: > > Did anyone know what the error code 24 and error value > 13 mean? I got this in a PathErr message. > > The RFC 2205 only list error code upto 23. > > Thanks > Jet > > ===== > Xinjie Chang > > CCDA,CCNA > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ > > From owner-mpls@UU.NET Mon Jun 11 12:33:18 2001 Received: from cmr1.ash.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 MAA14261 for ; Mon, 11 Jun 2001 12:33:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQksza13362; Mon, 11 Jun 2001 16:30:49 GMT Received: by mail-control.mail.uu.net id QQksza09908 for mpls-outgoing; Mon, 11 Jun 2001 16:30:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQksza09900 for ; Mon, 11 Jun 2001 16:30:06 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 QQksyz09667 for ; Mon, 11 Jun 2001 16:29:57 GMT Received: from mason2.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQksyz16546 for ; Mon, 11 Jun 2001 16:29:57 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id MAA13206; Mon, 11 Jun 2001 12:26:25 -0400 (EDT) Date: Mon, 11 Jun 2001 12:26:25 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: jet chang cc: mpls@UU.NET Subject: Re: erro code 24 In-Reply-To: <20010611145500.42184.qmail@web13106.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Jet, I beleive the error code 24 is for RRO and ERO both. There are some error values that are associated with the "Routing Problem" error code. The list of these errors values can be found in the Section 4.5. of the latest RSVP-TE draft (draft-ietf-mpls-rsvp-lsp-tunnel-08.txt). I think you will find an up-to-date list of these error codes, which might help debugging the problem. Thanks. -Rajiv On Mon, 11 Jun 2001, jet chang wrote: > Rajiv: > > Thanks for the quick response. > > Would you illustrate some more details on this error, > what is the cause of this error? I guess if a LSR that > not ERO may be one reason. But since it the PATH > message there is no ERO, so the error should be caused > by other things. > > BTW, where can I find the most up-to-date list of > those error codes and error values? > > Thanks > > --- Rajiv Papneja wrote: > > Hi Jet, > > > > I think the value for the "Routing Problem" error > > code is 24. Error > > value of 13 means "Unknown object class" and this > > may appear in Path or > > Resv message. > > > > -Rajiv > > > > On Sun, 10 Jun 2001, jet chang wrote: > > > > > Hi, there: > > > > > > Did anyone know what the error code 24 and error > > value > > > 13 mean? I got this in a PathErr message. > > > > > > The RFC 2205 only list error code upto 23. > > > > > > Thanks > > > Jet > > > > > > ===== > > > Xinjie Chang > > > > > > CCDA,CCNA > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Get personalized email addresses from Yahoo! Mail > > - only $35 > > > a year! http://personal.mail.yahoo.com/ > > > > > > > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ > From owner-mpls@UU.NET Mon Jun 11 13:30:08 2001 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 NAA15403 for ; Mon, 11 Jun 2001 13:30:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkszd03300; Mon, 11 Jun 2001 17:27:40 GMT Received: by mail-control.mail.uu.net id QQkszd04607 for mpls-outgoing; Mon, 11 Jun 2001 17:27:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkszd04598 for ; Mon, 11 Jun 2001 17:26:57 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 QQkszd05054 for ; Mon, 11 Jun 2001 17:25:18 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 QQkszd29537 for ; Mon, 11 Jun 2001 17:25:18 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 NAA08769 for ; Mon, 11 Jun 2001 13:25:16 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25667 for ; Mon, 11 Jun 2001 13:25:15 -0400 (EDT) Message-ID: <3B24FF07.359E1779@marconi.com> Date: Mon, 11 Jun 2001 13:25:27 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: erro code 24 References: <20010610204017.5093.qmail@web13103.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jet chang wrote: > > Did anyone know what the error code 24 and error value > 13 mean? I got this in a PathErr message. > > The RFC 2205 only list error code upto 23. In the MPLS world, you want to also see draft-ietf-mpls-rsvp-lsp-tunnel-08.txt. Error code 24 is routing problem. I don't know what error value 13 is in this context, however. The RSVP-TE draft only defines error values 1-10. It's probably something vendor-specific. -- david From owner-mpls@UU.NET Mon Jun 11 14:22:15 2001 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 OAA16315 for ; Mon, 11 Jun 2001 14:22:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkszh18397; Mon, 11 Jun 2001 18:20:30 GMT Received: by mail-control.mail.uu.net id QQkszh29236 for mpls-outgoing; Mon, 11 Jun 2001 18:19:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkszh29218 for ; Mon, 11 Jun 2001 18:19:42 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 QQkszh18808 for ; Mon, 11 Jun 2001 18:19:12 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQkszh16727 for ; Mon, 11 Jun 2001 18:19:12 GMT Received: (qmail 10448 invoked by uid 104); 11 Jun 2001 18:19:11 -0000 Received: from Sajith_Kizhikkepurayil@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.405568 secs); 11/06/2001 11:19:11 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 11 Jun 2001 18:19:10 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5BIJAG16502 for ; Mon, 11 Jun 2001 11:19:10 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 11:22:31 -0700 Message-ID: <219DA90B32B7D411B90E00306E0071FC1529D7@sje4exm01.pmc-sierra.bc.ca> From: Sajith Kizhikkepurayil To: mpls@UU.NET Subject: swap & push operation Date: Mon, 11 Jun 2001 11:22:29 -0700 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 hi from rfc 3031: ---- c) replace the label at the top of the label stack with a specified new label, and then push one or more specified new labels onto the label stack. ---- could somebody give me an application scenario ? i understand that this is useful in ingress of an LSP i would like to know how exactly it works with respect to deciding the next hop, and how is the label that swaped&pushed being is decided if this is already being discussed, please give me the pointers. thanks sajith From owner-mpls@UU.NET Mon Jun 11 14:52:40 2001 Received: from cmr0.ash.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 OAA16781 for ; Mon, 11 Jun 2001 14:52:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkszj03133; Mon, 11 Jun 2001 18:51:06 GMT Received: by mail-control.mail.uu.net id QQkszj02277 for mpls-outgoing; Mon, 11 Jun 2001 18:50:33 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkszj02254 for ; Mon, 11 Jun 2001 18:50: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 QQkszj19607 for ; Mon, 11 Jun 2001 18:49:02 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkszj29594 for ; Mon, 11 Jun 2001 18:49:02 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5BIn5U17806 for ; Mon, 11 Jun 2001 11:49:06 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA03141 for mpls@uu.net; Mon, 11 Jun 2001 14:48:59 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksyt21727 for ; Mon, 11 Jun 2001 14:55:14 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 QQksyt13431 for ; Mon, 11 Jun 2001 14:55:02 GMT Received: from web13106.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13106.mail.yahoo.com [216.136.174.151]) id QQksyt02234 for ; Mon, 11 Jun 2001 14:55:01 GMT Message-ID: <20010611145500.42184.qmail@web13106.mail.yahoo.com> Received: from [63.88.196.33] by web13106.mail.yahoo.com; Mon, 11 Jun 2001 07:55:00 PDT Date: Mon, 11 Jun 2001 07:55:00 -0700 (PDT) From: jet chang Subject: Re: erro code 24 To: Rajiv Papneja Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Rajiv: Thanks for the quick response. Would you illustrate some more details on this error, what is the cause of this error? I guess if a LSR that not ERO may be one reason. But since it the PATH message there is no ERO, so the error should be caused by other things. BTW, where can I find the most up-to-date list of those error codes and error values? Thanks --- Rajiv Papneja wrote: > Hi Jet, > > I think the value for the "Routing Problem" error > code is 24. Error > value of 13 means "Unknown object class" and this > may appear in Path or > Resv message. > > -Rajiv > > On Sun, 10 Jun 2001, jet chang wrote: > > > Hi, there: > > > > Did anyone know what the error code 24 and error > value > > 13 mean? I got this in a PathErr message. > > > > The RFC 2205 only list error code upto 23. > > > > Thanks > > Jet > > > > ===== > > Xinjie Chang > > > > CCDA,CCNA > > > > __________________________________________________ > > Do You Yahoo!? > > Get personalized email addresses from Yahoo! Mail > - only $35 > > a year! http://personal.mail.yahoo.com/ > > > > > > > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Mon Jun 11 15:25:07 2001 Received: from cmr0.ash.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 PAA17386 for ; Mon, 11 Jun 2001 15:25:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkszl14688; Mon, 11 Jun 2001 19:24:02 GMT Received: by mail-control.mail.uu.net id QQkszl27357 for mpls-outgoing; Mon, 11 Jun 2001 19:23:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkszl27324 for ; Mon, 11 Jun 2001 19:23:16 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 QQkszl25551 for ; Mon, 11 Jun 2001 19:23:15 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 QQkszl12746 for ; Mon, 11 Jun 2001 19:23:14 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 f5BJNAQ58823 for ; Mon, 11 Jun 2001 15:23:10 -0400 (EDT) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f5BJNAa03707 for ; Mon, 11 Jun 2001 15:23:10 -0400 (EDT) Received: from torrentnet.com (peroni.torrentnet.com [198.78.51.135]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id f5BJNAB07062 for ; Mon, 11 Jun 2001 15:23:10 -0400 (EDT) Message-ID: <3B251A9E.8263DC09@torrentnet.com> Date: Mon, 11 Jun 2001 15:23:10 -0400 From: Rajneesh Mahajan Organization: Ericsson IPI X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: a doubt in draft-ietf-mpls-ftn-mib-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi The draft-ietf-mpls-ftn-mib-01 on MPLS FTN MIB specifies a lower and an upper end of the destination address range for a FEC. So it seems to suggest that there could be only one address range for a FEC. But there could be a situation when multiple address ranges (e.g. multiple dest address ranges) are used to classify packets into the same FEC. I am not sure how we can handle such a situation with current MIB specification. I would appreciate any suggestions/clarification in this regard. -Rajneesh From owner-mpls@UU.NET Mon Jun 11 15:30:55 2001 Received: from cmr1.ash.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 PAA17436 for ; Mon, 11 Jun 2001 15:30:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkszl23961; Mon, 11 Jun 2001 19:29:54 GMT Received: by mail-control.mail.uu.net id QQkszl28590 for mpls-outgoing; Mon, 11 Jun 2001 19:29:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkszl28567 for ; Mon, 11 Jun 2001 19:29:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkszl02380 for ; Mon, 11 Jun 2001 19:28:13 GMT Received: from smtp486-bms.mail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp486-bms.mail.com [165.251.44.40]) id QQkszl20082 for ; Mon, 11 Jun 2001 19:28:13 GMT Received: from csrinivasan (unknown [12.34.209.74]) by smtp486-bms.mail.com (SMTP server) with SMTP id E811549874; Mon, 11 Jun 2001 15:28:12 -0400 (EDT) From: "Cheenu Srinivasan" To: "'Rajneesh Mahajan'" , Subject: RE: a doubt in draft-ietf-mpls-ftn-mib-01 Date: Mon, 11 Jun 2001 15:35:01 -0400 Message-ID: <176689DD1922D511ABE10001022E4DF20AB060@OPTONT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B251A9E.8263DC09@torrentnet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > The draft-ietf-mpls-ftn-mib-01 on MPLS FTN MIB specifies a > lower and an > upper end of the destination address range for a FEC. So it seems to > suggest that there could be only one address range for a FEC. > But there > could be a situation when multiple address ranges (e.g. multiple dest > address ranges) are used to classify packets into the same FEC. I am > not sure how we can handle such a situation with current MIB > specification. I would appreciate any > suggestions/clarification in this > regard. You would create multiple entries in the table, one per range that you want to match. From owner-mpls@UU.NET Mon Jun 11 16:15:22 2001 Received: from cmr0.ash.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 QAA18131 for ; Mon, 11 Jun 2001 16:15:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkszp12878; Mon, 11 Jun 2001 20:15:04 GMT Received: by mail-control.mail.uu.net id QQkszo22962 for mpls-outgoing; Mon, 11 Jun 2001 20:14:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkszo22910 for ; Mon, 11 Jun 2001 20:13: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 QQkszo05174 for ; Mon, 11 Jun 2001 20:13:45 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 QQkszo13852 for ; Mon, 11 Jun 2001 20:13:45 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 f5BKDil59613; Mon, 11 Jun 2001 16:13:44 -0400 (EDT) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f5BKDhr04455; Mon, 11 Jun 2001 16:13:43 -0400 (EDT) Received: from torrentnet.com (peroni.torrentnet.com [198.78.51.135]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id f5BKDhr13001; Mon, 11 Jun 2001 16:13:43 -0400 (EDT) Message-ID: <3B252677.E9467538@torrentnet.com> Date: Mon, 11 Jun 2001 16:13:43 -0400 From: Rajneesh Mahajan Organization: Ericsson IPI X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Cheenu Srinivasan CC: mpls@UU.NET Subject: Re: a doubt in draft-ietf-mpls-ftn-mib-01 References: <176689DD1922D511ABE10001022E4DF20AB060@OPTONT> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Cheenu Thanks for your prompt response. I see one possible problem with having different entries in this case. All the destination address ranges should map to same FEC, hence logically there should be only one FTN entry for them. For example, lets consider the situation when a router wants to give same treatment to the packets destined to a set of destination networks (which means different address ranges). So it would like to map them to a single FEC and hence single FTN. Having different FTN entries for all these address ranges would cause lot more FTN entries than required and could lead to several complications (e.g. memory wastage). Please note that I am using only the destination address for mapping packets to FECs. I am not using source address, port numbers and protocol. -Rajneesh Cheenu Srinivasan wrote: > > The draft-ietf-mpls-ftn-mib-01 on MPLS FTN MIB specifies a > > lower and an > > upper end of the destination address range for a FEC. So it seems to > > suggest that there could be only one address range for a FEC. > > But there > > could be a situation when multiple address ranges (e.g. multiple dest > > address ranges) are used to classify packets into the same FEC. I am > > not sure how we can handle such a situation with current MIB > > specification. I would appreciate any > > suggestions/clarification in this > > regard. > > You would create multiple entries in the table, one per range that > you want to match. From owner-mpls@UU.NET Mon Jun 11 17:25:05 2001 Received: from cmr1.ash.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 RAA19324 for ; Mon, 11 Jun 2001 17:25:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkszt05344; Mon, 11 Jun 2001 21:24:19 GMT Received: by mail-control.mail.uu.net id QQkszt19722 for mpls-outgoing; Mon, 11 Jun 2001 21:23:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkszt19714 for ; Mon, 11 Jun 2001 21:23:31 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 QQkszt22968 for ; Mon, 11 Jun 2001 21:21:05 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkszt15440 for ; Mon, 11 Jun 2001 21:21:05 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5BLL3K25484; Mon, 11 Jun 2001 17:21:03 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; MON, 11 Jun 2001 17:14:34 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 17:14:34 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E5659A1F4@newman.tenornet.com> From: "Arvind, K" To: "'mpls@uu.net'" Cc: "Arvind, K" , "'swallow@cisco.com'" , "'lberger@movaz.com'" Subject: Clarification on RSVP HELLO Optimization (draft-ietf-mpls-rsvp-ls p-tunnel-08) Date: Mon, 11 Jun 2001 17:14:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk The last paragraph of Section 5(.0) in draft-ietf-mpls-rsvp-lsp-tunnel-08 http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt states: "A poll request also includes the sender's instance value. This allows the receiver of a poll to optionally treat the poll as an implicit response. This optional handling is an optimization that can reduce the total number of polls and responses processed by a pair of neighbors. In all cases, when both sides support the optimization the result will be only one set of polls and responses per failure detection interval. Depending on selected intervals, the same benefit can occur even when only one neighbor supports the optimization." Could someone please clarify this optimization further? Does the optimization consist of responding to a request with another (regularly scheduled) request [Interpretation 1], or responding to a request with an ack and then suppressing the next regularly scheduled request (i.e., treat the request as an implicit precocious/unsolicited ack) [Interpretation 2], or something else? With Interpretation 1, the two ends of a link exchange Hello requests periodically and no explicit acks are involved. This sounds like a reasonable optimization, but is not consistent with Section 5.3 ("On receipt of a message containing a HELLO REQUEST object, the receiver MUST generate a Hello message containing a HELLO ACK object"). With Interpretation 2, one end of a link may end up generating periodic Hello requests only, while the other end may end up generating only Hello acks in response. This also results in optimizing Hello traffic. If this was indeed the intended interpretation, it would be helpful if the paragraph quoted above were rewritten to make this clear. Thanks. Regards, Arvind. From owner-mpls@UU.NET Mon Jun 11 18:04:55 2001 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 SAA19886 for ; Mon, 11 Jun 2001 18:04:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkszw13895; Mon, 11 Jun 2001 22:04:42 GMT Received: by mail-control.mail.uu.net id QQkszw03325 for mpls-outgoing; Mon, 11 Jun 2001 22:04:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkszw02987 for ; Mon, 11 Jun 2001 22:04: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 QQkszw21545 for ; Mon, 11 Jun 2001 22:03:28 GMT Received: from smtp279-bms.mail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp279-bms.mail.com [165.251.44.41]) id QQkszw12544 for ; Mon, 11 Jun 2001 22:03:27 GMT Received: from csrinivasan (unknown [12.34.209.74]) by smtp279-bms.mail.com (SMTP server) with SMTP id 7ECC4281CB; Mon, 11 Jun 2001 18:03:27 -0400 (EDT) From: "Cheenu Srinivasan" To: "'Rajneesh Mahajan'" , "Cheenu Srinivasan" Cc: Subject: RE: a doubt in draft-ietf-mpls-ftn-mib-01 Date: Mon, 11 Jun 2001 18:10:17 -0400 Message-ID: <176689DD1922D511ABE10001022E4DF20AB061@OPTONT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B252677.E9467538@torrentnet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Thanks for your prompt response. I see one possible problem > with having > different entries in this case. All the destination address > ranges should > map to same FEC, hence logically there should be only one FTN > entry for > them. > > For example, lets consider the situation when a router wants > to give same > treatment to the packets destined to a set of destination > networks (which > means different address ranges). So it would like to map them > to a single > FEC and hence single FTN. Having different FTN entries for all these > address ranges would cause lot more FTN entries than required > and could > lead to several complications (e.g. memory wastage). > > Please note that I am using only the destination address for mapping > packets to FECs. I am not using source address, port numbers > and protocol. You can specify the same action for multiple entries so all these packets get the same treatment. While the ability to specify arbitrarily complex patterns inside the packet header in a single entry might be considered desirable by some folks, practical reasons and WG feedback guided us into picking the fields you see in the current MIB. From owner-mpls@UU.NET Mon Jun 11 21:32:04 2001 Received: from cmr1.ash.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 VAA21814 for ; Mon, 11 Jun 2001 21:32:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktak19302; Tue, 12 Jun 2001 01:31:14 GMT Received: by mail-control.mail.uu.net id QQktak05284 for mpls-outgoing; Tue, 12 Jun 2001 01:30:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktak05264 for ; Tue, 12 Jun 2001 01:30:21 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 QQktak18169 for ; Tue, 12 Jun 2001 01:30:11 GMT Received: from gateway.ipinfusion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gt.ipinfusion.com [209.11.132.18] (may be forged)) id QQktak18218 for ; Tue, 12 Jun 2001 01:30:11 GMT Received: from ipinfusion.com (IDENT:root@[10.10.0.38]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id f5C1Saj23845 for ; Mon, 11 Jun 2001 18:28:36 -0700 Message-ID: <3B257197.242B5784@ipinfusion.com> Date: Mon, 11 Jun 2001 18:34:15 -0700 From: Manoj Dutta X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Label Mapping !! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I had some doubts in RFC 3036. In section A.1.2, LMp.17 and A.1.6 FEC.1, an LSR seems to send mappings for a given FEC to the next hop for the same FEC. If so, why ? Thanks in advance manoj From owner-mpls@UU.NET Mon Jun 11 23:24:25 2001 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 XAA24237 for ; Mon, 11 Jun 2001 23:24:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktar07674; Tue, 12 Jun 2001 03:23:36 GMT Received: by mail-control.mail.uu.net id QQktar27463 for mpls-outgoing; Tue, 12 Jun 2001 03:23:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktar27452 for ; Tue, 12 Jun 2001 03:22: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 QQktar17920 for ; Tue, 12 Jun 2001 03:22:47 GMT Received: from localhost.localdomain by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQktar13053 for ; Tue, 12 Jun 2001 03:22:44 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f5C3Piq01550; Tue, 12 Jun 2001 08:55:45 +0530 Date: Tue, 12 Jun 2001 08:55:44 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: Bob Thomas cc: nagendras@netbrahma.com, suchauhan@hss.hns.com, mpls@UU.NET Subject: Re: Error in RFC 3036?? In-Reply-To: <200106111122.HAA06906@rhthomas-sun2.cisco.com> Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Bob! I am sorry if I did'nt put it correctly, but by saying that the Loop Detected Notification might in turn Loop, I meant that since a loop was detected on the label request received, there is a very high possibility that the return path (from the receiver of the label request to the sender of the Label request) for the notification message might as well loop so its better to silently discard it. Is'nt it because of this Bob ? regards tomar On Mon, 11 Jun 2001, Bob Thomas wrote: > Tomar, > > > If the node detects a loop in the label request message, the its wise not > > to send the loop detected notification, because that might in turn loop > > Note that the Loop Detected Notification is not propagated by the > receiver, and therefore will not loop. > > Bob > > > > and make the network conditions worse. In the LRq.2 case the loop is not > > detected in the label request message so we are sure that the return path > > for the notification message has no loop, so it is safe to send a > > notification in that case. > > > > --tomar > > > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > > > > > yup sorry! LRq.4 it is. typo ;o) > > > > > > > > > > > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on > > > 06/11/2001 03:27:43 PM > > > > > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > cc: > > > > > > Subject: RE: Error in RFC 3036?? > > > > > > > > > > > > > > > > IMHO, should it not be > > > > If Loop Detected , got to LRq.5 > > > > > > LRq.4 and not LRq.5 I think.... > > > > > > > > > > > > > -- > > > > > > ------------------------------------------------------------------------------ > > Nagendra Singh Tomar > > > > Residence: > > 369 KHB Colony > > 5th Block Koramangala > > Bangalore 95 > > INDIA > > Phone : 5524839 > > email : nagendras@netbrahma.com > > > > > > "Sometimes quantity becomes quality" > > --Gary Kasparov, > > When he played against Deep Blue. He said this after looking at a > > computer which found a forced mate in 249 in an endgame, after calculating > > all the possible moves with only 5 pieces left on the board. > > ------------------------------------------------------------------------------ > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Tue Jun 12 01:14:37 2001 Received: from cmr1.ash.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 BAA25684 for ; Tue, 12 Jun 2001 01:14:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktay25705; Tue, 12 Jun 2001 05:14:14 GMT Received: by mail-control.mail.uu.net id QQktay18311 for mpls-outgoing; Tue, 12 Jun 2001 05:13:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktay18291 for ; Tue, 12 Jun 2001 05:13: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 QQktay13379 for ; Tue, 12 Jun 2001 05:11:51 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQktay22952 for ; Tue, 12 Jun 2001 05:11:49 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5C5Cg522444; Tue, 12 Jun 2001 10:42:42 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A69.001B2011 ; Tue, 12 Jun 2001 10:26:16 +0530 X-Lotus-FromDomain: HSS To: nagendras@netbrahma.com cc: Bob Thomas , nagendras@netbrahma.com, mpls@UU.NET Message-ID: <65256A69.001B1EC2.00@sandesh.hss.hns.com> Date: Tue, 12 Jun 2001 10:26:12 +0530 Subject: Re: Error in RFC 3036?? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi nagendra! In case we are using Loop Detection in a MPLS domain (or for that matter over an LSP) and then in the case considered above the Loop Detection when detected at a LSR shall be the first to detect it and hence it is before the loop has actually occurred further down the LSP. We have still not reached the receiver as this is an Intermediate LSP. Hence there should not be a loop if we send back a notification to the source. regards sumit Nagendra Singh Tomar on 06/12/2001 08:55:44 AM Please respond to nagendras@netbrahma.com To: Bob Thomas cc: nagendras@netbrahma.com, Sumit Chauhan/HSS@HSS, mpls@UU.NET Subject: Re: Error in RFC 3036?? Bob! I am sorry if I did'nt put it correctly, but by saying that the Loop Detected Notification might in turn Loop, I meant that since a loop was detected on the label request received, there is a very high possibility that the return path (from the receiver of the label request to the sender of the Label request) for the notification message might as well loop so its better to silently discard it. Is'nt it because of this Bob ? regards tomar On Mon, 11 Jun 2001, Bob Thomas wrote: > Tomar, > > > If the node detects a loop in the label request message, the its wise not > > to send the loop detected notification, because that might in turn loop > > Note that the Loop Detected Notification is not propagated by the > receiver, and therefore will not loop. > > Bob > > > > and make the network conditions worse. In the LRq.2 case the loop is not > > detected in the label request message so we are sure that the return path > > for the notification message has no loop, so it is safe to send a > > notification in that case. > > > > --tomar > > > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > > > > > yup sorry! LRq.4 it is. typo ;o) > > > > > > > > > > > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on > > > 06/11/2001 03:27:43 PM > > > > > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > cc: > > > > > > Subject: RE: Error in RFC 3036?? > > > > > > > > > > > > > > > > IMHO, should it not be > > > > If Loop Detected , got to LRq.5 > > > > > > LRq.4 and not LRq.5 I think.... > > > > > > > > > > > > > -- > > > > > > ------------------------------------------------------------------------------ > > Nagendra Singh Tomar > > > > Residence: > > 369 KHB Colony > > 5th Block Koramangala > > Bangalore 95 > > INDIA > > Phone : 5524839 > > email : nagendras@netbrahma.com > > > > > > "Sometimes quantity becomes quality" > > --Gary Kasparov, > > When he played against Deep Blue. He said this after looking at a > > computer which found a forced mate in 249 in an endgame, after calculating > > all the possible moves with only 5 pieces left on the board. > > ------------------------------------------------------------------------------ > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Tue Jun 12 01:50:50 2001 Received: from cmr1.ash.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 BAA27864 for ; Tue, 12 Jun 2001 01:50:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbb09078; Tue, 12 Jun 2001 05:50:29 GMT Received: by mail-control.mail.uu.net id QQktbb22833 for mpls-outgoing; Tue, 12 Jun 2001 05:49:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktbb22814 for ; Tue, 12 Jun 2001 05:49:29 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 QQktbb06764 for ; Tue, 12 Jun 2001 05:49:04 GMT Received: from localhost.localdomain by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQktbb27144 for ; Tue, 12 Jun 2001 05:49:01 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f5C5pwq02306; Tue, 12 Jun 2001 11:22:00 +0530 Date: Tue, 12 Jun 2001 11:21:58 +0530 (IST) From: Nagendra Singh Tomar X-Sender: tomar@cheetah Reply-To: nagendras@netbrahma.com To: suchauhan@hss.hns.com cc: nagendras@netbrahma.com, Bob Thomas , mpls@UU.NET Subject: Re: Error in RFC 3036?? In-Reply-To: <65256A69.001B1EC2.00@sandesh.hss.hns.com> Message-ID: Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Yeah, actually I missed that point! --tomar On Tue, 12 Jun 2001 suchauhan@hss.hns.com wrote: > > > hi nagendra! > In case we are using Loop Detection in a MPLS domain (or for that matter > over an LSP) and then in the case considered above the Loop Detection when > detected at a LSR shall be the first to detect it and hence it is before the > loop has actually occurred further down the LSP. We have still not reached the > receiver as this is an Intermediate LSP. Hence there should not be a loop if we > send back a notification to the source. > > regards > sumit > > > > > Nagendra Singh Tomar on 06/12/2001 08:55:44 AM > > Please respond to nagendras@netbrahma.com > > To: Bob Thomas > cc: nagendras@netbrahma.com, Sumit Chauhan/HSS@HSS, mpls@UU.NET > > Subject: Re: Error in RFC 3036?? > > > > > Bob! > I am sorry if I did'nt put it correctly, but by saying that the > Loop Detected Notification might in turn Loop, I meant that since a loop > was detected on the label request received, there is a very high > possibility that the return path (from the receiver of the label request > to the sender of the Label request) for the notification message might as > well loop so its better to silently discard it. > > Is'nt it because of this Bob ? > > regards > tomar > > > On Mon, 11 Jun 2001, Bob Thomas wrote: > > > Tomar, > > > > > If the node detects a loop in the label request message, the its wise not > > > to send the loop detected notification, because that might in turn loop > > > > Note that the Loop Detected Notification is not propagated by the > > receiver, and therefore will not loop. > > > > Bob > > > > > > > and make the network conditions worse. In the LRq.2 case the loop is not > > > detected in the label request message so we are sure that the return path > > > for the notification message has no loop, so it is safe to send a > > > notification in that case. > > > > > > --tomar > > > > > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > > > > > > > > > yup sorry! LRq.4 it is. typo ;o) > > > > > > > > > > > > > > > > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" > on > > > > 06/11/2001 03:27:43 PM > > > > > > > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > > cc: > > > > > > > > Subject: RE: Error in RFC 3036?? > > > > > > > > > > > > > > > > > > > > > IMHO, should it not be > > > > > If Loop Detected , got to LRq.5 > > > > > > > > LRq.4 and not LRq.5 I think.... > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > ------------------------------------------------------------------------------ > > > Nagendra Singh Tomar > > > > > > Residence: > > > 369 KHB Colony > > > 5th Block Koramangala > > > Bangalore 95 > > > INDIA > > > Phone : 5524839 > > > email : nagendras@netbrahma.com > > > > > > > > > "Sometimes quantity becomes quality" > > > --Gary Kasparov, > > > When he played against Deep Blue. He said this after looking at a > > > computer which found a forced mate in 249 in an endgame, after calculating > > > all the possible moves with only 5 pieces left on the board. > > > > ------------------------------------------------------------------------------ > > > > > > > -- > > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ > > > > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Tue Jun 12 01:52:30 2001 Received: from cmr0.ash.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 BAA27952 for ; Tue, 12 Jun 2001 01:52:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbb15394; Tue, 12 Jun 2001 05:52:09 GMT Received: by mail-control.mail.uu.net id QQktbb22861 for mpls-outgoing; Tue, 12 Jun 2001 05:50:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktbb22837 for ; Tue, 12 Jun 2001 05:49: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 QQktbb11190 for ; Tue, 12 Jun 2001 05:49:37 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQktbb07988 for ; Tue, 12 Jun 2001 05:49:36 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5C5ort23856 for ; Tue, 12 Jun 2001 11:20:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A69.001E9C32 ; Tue, 12 Jun 2001 11:04:20 +0530 X-Lotus-FromDomain: HSS To: mpls@UU.NET Message-ID: <65256A69.001E9B9B.00@sandesh.hss.hns.com> Date: Tue, 12 Jun 2001 11:04:18 +0530 Subject: Label Stack Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi all! I have a very basic question. Consider the LSP setup below R1-------------R2-----------------R3-------------------R4---------------------R5------------------R6 Eth Eth ATM ATM Eth <------------------------------------------------> LSP2 <-------------------------------------------------------------------------------------------------------> LSP1 LSP1 = R1 to R6 LSP2 = R3 to R6 Now packet reaches R3 and R3 knows that the packet has to be sent out on an ATM outgoing interface with an ATM label space which is a tunnel. According to my understanding firstly the packet received(Ethernet payload with shim header) would be segmented into ATM cells and then tagged with the outgoing ATM VCI/VPI . Now seemingly this is a label stack but if we go by a more strict definition it is not as the stack is not part of each cell that is being carried. This is beacause the packet (IP + shim) was segmented and carried as ATM cells and hence only a small fraction (if not just one!) shall carry the shim header. Do we still say that this is a label stack? regards sumit From owner-mpls@UU.NET Tue Jun 12 02:05:24 2001 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 CAA05778 for ; Tue, 12 Jun 2001 02:05:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbc17798; Tue, 12 Jun 2001 06:05:00 GMT Received: by mail-control.mail.uu.net id QQktbc02316 for mpls-outgoing; Tue, 12 Jun 2001 06:04:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktbc01800 for ; Tue, 12 Jun 2001 06:04:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktbc06950 for ; Tue, 12 Jun 2001 06:03:09 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQktbc25787 for ; Tue, 12 Jun 2001 06:03:07 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5C64N424305 for ; Tue, 12 Jun 2001 11:34:23 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A69.001FDAB4 ; Tue, 12 Jun 2001 11:17:56 +0530 X-Lotus-FromDomain: HSS To: mpls@UU.NET Message-ID: <65256A69.001FDA4D.00@sandesh.hss.hns.com> Date: Tue, 12 Jun 2001 11:17:54 +0530 Subject: Re: Label Stack Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk sorry my mail client messed up the figure. I willl try and make it clearer below suchauhan@hss.hns.com on 06/12/2001 11:04:18 AM To: mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: Label Stack hi all! I have a very basic question. Consider the LSP setup below R1-------------R2-----------------R3-------------------R4---------------------R5------------------R6 Eth Links = R1-R2, R2-R3, R5-R6 ATM Links = R3-R4, R4-R5 LSP1 = R1 to R6 LSP2 = R3 to R5 LSP Tunnel = R3-R4-R5 (i.e. LSP2) Now packet reaches R3 and R3 knows that the packet has to be sent out on an ATM outgoing interface with an ATM label space which is a tunnel. According to my understanding firstly the packet received(Ethernet payload with shim header) would be segmented into ATM cells and then tagged with the outgoing ATM VCI/VPI . Now seemingly this is a label stack but if we go by a more strict definition it is not as the stack is not part of each cell that is being carried. This is beacause the packet (IP + shim) was segmented and carried as ATM cells and hence only a small fraction (if not just one!) shall carry the shim header. Do we still say that this is a label stack? regards sumit From owner-mpls@UU.NET Tue Jun 12 02:16:12 2001 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 CAA06792 for ; Tue, 12 Jun 2001 02:16:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbd29321; Tue, 12 Jun 2001 06:15:42 GMT Received: by mail-control.mail.uu.net id QQktbd14962 for mpls-outgoing; Tue, 12 Jun 2001 06:15:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktbc14942 for ; Tue, 12 Jun 2001 06:14: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 QQktbc25106 for ; Tue, 12 Jun 2001 06:13:49 GMT From: vijayc@hclt.com Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQktbc10347 for ; Tue, 12 Jun 2001 06:13:48 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ52RY2T; Tue, 12 Jun 2001 11:56:53 +0530 Received: from hclt.com (192.168.232.145 [192.168.232.145]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2DZZZ; Tue, 12 Jun 2001 11:41:42 +0530 Message-ID: <3B25B438.179003A5@hclt.com> Date: Tue, 12 Jun 2001 11:48:32 +0530 Organization: HCL Technologies X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-12 i686) X-Accept-Language: en MIME-Version: 1.0 To: suchauhan@hss.hns.com, mpls@UU.NET Subject: Re: Error in RFC 3036?? References: <65256A69.001B1EC2.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I also think there is no problem in sending back a Loop detected notification.This notification is not going to go beyond the peer as the peer will record that notifciation received and may retry the request. Also, if we don't send the notification the sender has no way of knowing the fate of his Request message, as LDP does not have timeouts for requests.The sender may be in Response Awaited state indefinetly. Correct me if I am wrong Regards, Vijay suchauhan@hss.hns.com wrote: > hi nagendra! > In case we are using Loop Detection in a MPLS domain (or for that matter > over an LSP) and then in the case considered above the Loop Detection when > detected at a LSR shall be the first to detect it and hence it is before the > loop has actually occurred further down the LSP. We have still not reached the > receiver as this is an Intermediate LSP. Hence there should not be a loop if we > send back a notification to the source. > > regards > sumit > > Nagendra Singh Tomar on 06/12/2001 08:55:44 AM > > Please respond to nagendras@netbrahma.com > > To: Bob Thomas > cc: nagendras@netbrahma.com, Sumit Chauhan/HSS@HSS, mpls@UU.NET > > Subject: Re: Error in RFC 3036?? > > Bob! > I am sorry if I did'nt put it correctly, but by saying that the > Loop Detected Notification might in turn Loop, I meant that since a loop > was detected on the label request received, there is a very high > possibility that the return path (from the receiver of the label request > to the sender of the Label request) for the notification message might as > well loop so its better to silently discard it. > > Is'nt it because of this Bob ? > > regards > tomar > > On Mon, 11 Jun 2001, Bob Thomas wrote: > > > Tomar, > > > > > If the node detects a loop in the label request message, the its wise not > > > to send the loop detected notification, because that might in turn loop > > > > Note that the Loop Detected Notification is not propagated by the > > receiver, and therefore will not loop. > > > > Bob > > > > > > > and make the network conditions worse. In the LRq.2 case the loop is not > > > detected in the label request message so we are sure that the return path > > > for the notification message has no loop, so it is safe to send a > > > notification in that case. > > > > > > --tomar > > > > > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > > > > > > > > > yup sorry! LRq.4 it is. typo ;o) > > > > > > > > > > > > > > > > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" > on > > > > 06/11/2001 03:27:43 PM > > > > > > > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > > cc: > > > > > > > > Subject: RE: Error in RFC 3036?? > > > > > > > > > > > > > > > > > > > > > IMHO, should it not be > > > > > If Loop Detected , got to LRq.5 > > > > > > > > LRq.4 and not LRq.5 I think.... > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > ------------------------------------------------------------------------------ > > > Nagendra Singh Tomar > > > > > > Residence: > > > 369 KHB Colony > > > 5th Block Koramangala > > > Bangalore 95 > > > INDIA > > > Phone : 5524839 > > > email : nagendras@netbrahma.com > > > > > > > > > "Sometimes quantity becomes quality" > > > --Gary Kasparov, > > > When he played against Deep Blue. He said this after looking at a > > > computer which found a forced mate in 249 in an endgame, after calculating > > > all the possible moves with only 5 pieces left on the board. > > > > ------------------------------------------------------------------------------ > > > > > > > -- > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ From owner-mpls@UU.NET Tue Jun 12 02:35:30 2001 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 CAA08241 for ; Tue, 12 Jun 2001 02:35:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbe21070; Tue, 12 Jun 2001 06:35:04 GMT Received: by mail-control.mail.uu.net id QQktbe17512 for mpls-outgoing; Tue, 12 Jun 2001 06:34:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktbe17497 for ; Tue, 12 Jun 2001 06:34: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 QQktbe09507 for ; Tue, 12 Jun 2001 06:33:01 GMT Received: from p-mail1.cnet.fr by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail1.rd.francetelecom.fr [193.49.124.31]) id QQktbe18563 for ; Tue, 12 Jun 2001 06:33:00 GMT Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 08:32:39 +0200 Message-ID: <98388C05D464D111B61800805F150416029AB380@p-ibis.rd.francetelecom.fr> From: zze-PELLE Thierry StagiaireFTRD/DAC/ISS To: "'Manoj Dutta'" , mpls@UU.NET Subject: RE: Label Mapping !! Date: Tue, 12 Jun 2001 08:32:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, > I had some doubts in RFC 3036. In section A.1.2, LMp.17 and A.1.6 > FEC.1, an LSR seems to send mappings for a given FEC to the next hop > for the same FEC. If so, why ? As I understand it, this is due to the existance of liberal mode : in case of LDP reconstuction, the former Next Hop (downstrem located) may become a LSR upstream located. Rigth? Thierry From owner-mpls@UU.NET Tue Jun 12 03:09:25 2001 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 DAA10339 for ; Tue, 12 Jun 2001 03:09:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbg00230; Tue, 12 Jun 2001 07:08:49 GMT Received: by mail-control.mail.uu.net id QQktbg03806 for mpls-outgoing; Tue, 12 Jun 2001 07:08:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktbg03323 for ; Tue, 12 Jun 2001 07:08:05 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 QQktbg28602 for ; Tue, 12 Jun 2001 07:06:48 GMT Received: from p-mail2.cnet.fr by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQktbg28169 for ; Tue, 12 Jun 2001 07:06:48 GMT Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 09:06:23 +0200 Message-ID: <98388C05D464D111B61800805F150416029AB381@p-ibis.rd.francetelecom.fr> From: zze-PELLE Thierry StagiaireFTRD/DAC/ISS To: "'suchauhan@hss.hns.com'" Cc: mpls@UU.NET Subject: RE: Label Mapping !! Date: Tue, 12 Jun 2001 09:06:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk HI, > hi! > IMHO this is not correct as the LSR from which the label > mapping has beeen > learnt can never be the upstream LSR for the same mapping - liberal or > conservative mode notwithstanding. Even if the IGP completely change the route for the FEC? e.g. If the network is ------- / \ A----B----C----D | | \----E First, the Path from A to E may be A B C D E. In this case, ------- / \ A-->-B-->-C-->-D | \|/ \----E hence, C is upstream with respect to D : C uses the label distributed by D. If the path from A to E changed to A B D C E. In this case, --->--- / \ A-->-B----C--<-D \|/ | \----E here, D is upstream with respect to C : D uses the label distributed by C. Finally, in liberal mode, if C has distributed a label to D (in the first case, where D was the Next Hop for C), it can use it directly. This is a quite strange case but it seems to be ok. Thierry From owner-mpls@UU.NET Tue Jun 12 03:36:21 2001 Received: from cmr0.ash.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 DAA10544 for ; Tue, 12 Jun 2001 03:36:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbi13778; Tue, 12 Jun 2001 07:34:01 GMT Received: by mail-control.mail.uu.net id QQktbi13768 for mpls-outgoing; Tue, 12 Jun 2001 07:33:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktbi13754 for ; Tue, 12 Jun 2001 07:33: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 QQktbi05270 for ; Tue, 12 Jun 2001 07:31:50 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQktbi19127 for ; Tue, 12 Jun 2001 07:31:48 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5C6qrE25843; Tue, 12 Jun 2001 12:22:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A69.00244A9C ; Tue, 12 Jun 2001 12:06:23 +0530 X-Lotus-FromDomain: HSS To: "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" cc: "'Manoj Dutta'" , mpls@UU.NET Message-ID: <65256A69.002443F5.00@sandesh.hss.hns.com> Date: Tue, 12 Jun 2001 12:06:05 +0530 Subject: RE: Label Mapping !! Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi! IMHO this is not correct as the LSR from which the label mapping has beeen learnt can never be the upstream LSR for the same mapping - liberal or conservative mode notwithstanding. regards sumit "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on 06/12/2001 12:02:39 PM To: "'Manoj Dutta'" , mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: RE: Label Mapping !! Hi, > I had some doubts in RFC 3036. In section A.1.2, LMp.17 and A.1.6 > FEC.1, an LSR seems to send mappings for a given FEC to the next hop > for the same FEC. If so, why ? As I understand it, this is due to the existance of liberal mode : in case of LDP reconstuction, the former Next Hop (downstrem located) may become a LSR upstream located. Rigth? Thierry From owner-mpls@UU.NET Tue Jun 12 04:03:15 2001 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 EAA10724 for ; Tue, 12 Jun 2001 04:03:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbk02665; Tue, 12 Jun 2001 08:02:21 GMT Received: by mail-control.mail.uu.net id QQktbk20918 for mpls-outgoing; Tue, 12 Jun 2001 08:01:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktbk20213 for ; Tue, 12 Jun 2001 08:01:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQktbk23641 for ; Tue, 12 Jun 2001 08:00:59 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQktbk00718 for ; Tue, 12 Jun 2001 08:00:57 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5C82Cb28116 for ; Tue, 12 Jun 2001 13:32:12 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A69.002AA298 ; Tue, 12 Jun 2001 13:15:41 +0530 X-Lotus-FromDomain: HSS To: mpls@UU.NET Message-ID: <65256A69.002AA10F.00@sandesh.hss.hns.com> Date: Tue, 12 Jun 2001 13:15:37 +0530 Subject: Section A.1.2 RFC 3036 concerns! Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi! I have a few concerns regarding the algo defined in this section 1. LMp.10 - In this case should we not consider this as a dual purpose message for the release of the previous label and installing the new label generated by the same downstream LSR. I strongly think it gives a better logic to the situation here as we have confirmed already that this is from our current next-hop for that FEC. 2. LMp.14 - How do we actually define a Ingress LSR? In my opinion any LSR should be able to act as Ingress atleast till the point the network IGP comes into stable state as till that point packets to the same destination may be coming from different Ingress routers. I would probably use something like - For the LMp.14 case we should have a FTN entry created and then time it out using say LRU algorithm to keep the size of FTN in check. Am I correct? 3. LMp.17 - Why do we need to send this also to the Peer LSR fro which the mapping has been learnt? Someone has raised the question earlier as well but I am still not convinced about the right approach here. 4. LMp.21 - In the message sent should not "PrevAdvLabel" be just "Label". We are only sending the current mapping and not the previous one here. 5. Lmp.28 - Should this not be done before LMp.20 so that we may not have to resend to the same peer twice (once because we are in DU mode and again when we realise we also have an outstanding request for a label from the same peer). I know this will not cause a problem as the peer will reject the second mapping but seems an awful waste of processing and network bandwidth (same as in point 1 above). regards sumit From owner-mpls@UU.NET Tue Jun 12 09:40:03 2001 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 JAA14787 for ; Tue, 12 Jun 2001 09:40:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcg22441; Tue, 12 Jun 2001 13:38:28 GMT Received: by mail-control.mail.uu.net id QQktcg18670 for mpls-outgoing; Tue, 12 Jun 2001 13:37:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktcg18657 for ; Tue, 12 Jun 2001 13:37:47 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 QQktcg07492 for ; Tue, 12 Jun 2001 13:35:53 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQktcg22361 for ; Tue, 12 Jun 2001 13:35:53 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5CDZvU19026 for ; Tue, 12 Jun 2001 06:35:57 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA05790 for mpls@uu.net; Tue, 12 Jun 2001 09:35:51 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkszy17987 for ; Mon, 11 Jun 2001 22:41:57 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 QQkszy09515 for ; Mon, 11 Jun 2001 22:41:52 GMT Received: from web14508.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14508.mail.yahoo.com [216.136.224.71]) id QQkszy29299 for ; Mon, 11 Jun 2001 22:41:52 GMT Message-ID: <20010611224151.79246.qmail@web14508.mail.yahoo.com> Received: from [206.87.3.173] by web14508.mail.yahoo.com; Mon, 11 Jun 2001 18:41:51 EDT Date: Mon, 11 Jun 2001 18:41:51 -0400 (EDT) From: "S. Davari" Reply-To: davari@ieee.org Subject: LSR-MIB Question To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi All, A few questions regarding LSR-MIB: 1) If TTL expires in an MPLS packet is the packet counted in mplsInSegmentErrors" or not? 2) If we receive a labeled packet and swap the label and then push a new label do we keep 2 sets of statistics on the outgoing segment, one for the swapped label and one for the pushed label or only one? BTW, I also noticed that in LSR-MIB a swap consists of a pop on incoming segment followed by a push on outgoing segment, this is odd !! The odder thing is that the incoming segment has a parameter called InSegmentNpop in which "N" identifies the number of pops to be performed on the insegment. How does one know in advance how many pops to perform? If you know that, then it means that all those labels that you pop are not used at all. Thanks, -Shahram _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca From owner-mpls@UU.NET Tue Jun 12 09:42:27 2001 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 JAA14816 for ; Tue, 12 Jun 2001 09:42:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcg24144; Tue, 12 Jun 2001 13:39:37 GMT Received: by mail-control.mail.uu.net id QQktcg18674 for mpls-outgoing; Tue, 12 Jun 2001 13:38:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktcg18659 for ; Tue, 12 Jun 2001 13:37: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 QQktcg09140 for ; Tue, 12 Jun 2001 13:37:05 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQktcg23806 for ; Tue, 12 Jun 2001 13:37:05 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5CDb8U19702 for ; Tue, 12 Jun 2001 06:37:08 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA05807 for mpls@uu.net; Tue, 12 Jun 2001 09:37:03 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktbm09868 for ; Tue, 12 Jun 2001 08:30: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 QQktbl19198 for ; Tue, 12 Jun 2001 08:29:39 GMT Received: from p-mail1.cnet.fr by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail1.rd.francetelecom.fr [193.49.124.31]) id QQktbl07763 for ; Tue, 12 Jun 2001 08:29:38 GMT Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 10:29:25 +0200 Received: from rd.francetelecom.com (lat4074.rd.francetelecom.fr [161.104.15.15]) by l-mhs1.lannion.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GQ90QL2C; Tue, 12 Jun 2001 10:28:55 +0200 Message-ID: <3B25D29C.D3C3E881@rd.francetelecom.com> Date: Tue, 12 Jun 2001 10:28:12 +0200 From: Olivier Dugeon Organization: France Telecom R&D X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-21mdksmp i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: mpls@UU.NET, te-wg@ops.ietf.org Subject: MPLS and COPS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, In a context of QoS control in a multi-domain and multi-technology network, we would use COPS as the control protocol rather than SNMP. COPS need a "Policy rules Information Base" to work. A such PIB is available for DiffServ for example. I would to know if somebody work on a PIB for MPLS. - Is there some case study inside the WG or it is out the scope/out of date ? - Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ? Thank's a lot Olivier Dugeon -- FTR&D/DAC/CPN Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 F-22307 LANNION | Fax: +(33) 2 96 05 18 52 From owner-mpls@UU.NET Tue Jun 12 09:42:58 2001 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 JAA14832 for ; Tue, 12 Jun 2001 09:42:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcg25996; Tue, 12 Jun 2001 13:40:50 GMT Received: by mail-control.mail.uu.net id QQktcg18680 for mpls-outgoing; Tue, 12 Jun 2001 13:38:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktcg18660 for ; Tue, 12 Jun 2001 13:37:49 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 QQktcg07303 for ; Tue, 12 Jun 2001 13:35:45 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQktcg19463 for ; Tue, 12 Jun 2001 13:35:44 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5CDZm917623 for ; Tue, 12 Jun 2001 06:35:48 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA05786 for mpls@uu.net; Tue, 12 Jun 2001 09:35:43 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQksyt21727 for ; Mon, 11 Jun 2001 14:55:14 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 QQksyt13431 for ; Mon, 11 Jun 2001 14:55:02 GMT Received: from web13106.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13106.mail.yahoo.com [216.136.174.151]) id QQksyt02234 for ; Mon, 11 Jun 2001 14:55:01 GMT Message-ID: <20010611145500.42184.qmail@web13106.mail.yahoo.com> Received: from [63.88.196.33] by web13106.mail.yahoo.com; Mon, 11 Jun 2001 07:55:00 PDT Date: Mon, 11 Jun 2001 07:55:00 -0700 (PDT) From: jet chang Subject: Re: erro code 24 To: Rajiv Papneja Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Rajiv: Thanks for the quick response. Would you illustrate some more details on this error, what is the cause of this error? I guess if a LSR that not ERO may be one reason. But since it the PATH message there is no ERO, so the error should be caused by other things. BTW, where can I find the most up-to-date list of those error codes and error values? Thanks --- Rajiv Papneja wrote: > Hi Jet, > > I think the value for the "Routing Problem" error > code is 24. Error > value of 13 means "Unknown object class" and this > may appear in Path or > Resv message. > > -Rajiv > > On Sun, 10 Jun 2001, jet chang wrote: > > > Hi, there: > > > > Did anyone know what the error code 24 and error > value > > 13 mean? I got this in a PathErr message. > > > > The RFC 2205 only list error code upto 23. > > > > Thanks > > Jet > > > > ===== > > Xinjie Chang > > > > CCDA,CCNA > > > > __________________________________________________ > > Do You Yahoo!? > > Get personalized email addresses from Yahoo! Mail > - only $35 > > a year! http://personal.mail.yahoo.com/ > > > > > > > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Tue Jun 12 09:44:21 2001 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 JAA14888 for ; Tue, 12 Jun 2001 09:44:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcg27700; Tue, 12 Jun 2001 13:41:59 GMT Received: by mail-control.mail.uu.net id QQktcg18683 for mpls-outgoing; Tue, 12 Jun 2001 13:38:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktcg18662 for ; Tue, 12 Jun 2001 13:37:50 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 QQktcg07922 for ; Tue, 12 Jun 2001 13:36:09 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQktcg22635 for ; Tue, 12 Jun 2001 13:36:08 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5CDaCU19229 for ; Tue, 12 Jun 2001 06:36:12 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA05794 for mpls@uu.net; Tue, 12 Jun 2001 09:36:07 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktah11458 for ; Tue, 12 Jun 2001 00:50:47 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 QQktah12798 for ; Tue, 12 Jun 2001 00:50:31 GMT Received: from smtp.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.135.132]) id QQktah27683 for ; Tue, 12 Jun 2001 00:50:29 GMT Received: from l24354 ([10.110.10.220]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GESKR200.K06 for ; Tue, 12 Jun 2001 08:45:02 +0800 Message-ID: <001501c0f2d9$b1f62ee0$dc0a6e0a@huawei.com.cn> From: "liyixiang" To: Subject: seek for your help! Date: Tue, 12 Jun 2001 08:50:36 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01C0F31C.BFCEAA40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C0F31C.BFCEAA40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01C0F31C.BFCEAA40" ------=_NextPart_001_0012_01C0F31C.BFCEAA40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciBhbnkgcGllY2Ugb2YgYWR2aWNlIHlvdSBzZW50IHRvIG1lIQ0KDQo= ------=_NextPart_001_0012_01C0F31C.BFCEAA40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFuayB5b3UgZm9yIGFu eSBwaWVjZSBvZiBhZHZpY2UgeW91IHNlbnQgdG8gbWUhPC9GT05UPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_001_0012_01C0F31C.BFCEAA40-- ------=_NextPart_000_0011_01C0F31C.BFCEAA40 Content-Type: text/plain; name="ldp_question.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ldp_question.txt" Content-Transfer-Encoding: quoted-printable Dear All: Hello!=20 I have here some questions in need of your help: (1)If all routers use Downstream Unsolicited mode in LDP, how can = the downstream end node initiate a session without causing a label = broadcast storm in the upstream nodes?=20 (2)As to my knowledge, the ethernet interface in the 3640 routers of = Cisco supports Downstream Unsolicited mode , whereas the ATM interface = in the 7500 series routers supports Downstream on demand mode. If the upstream node works in Downstream Unsolicited mode with a = downstream node(on the same phasical layer) works in downstream on = demand mode,there will occur a deadlock when the downstream node waits = for the upstream node to initiate the label request which never comes in = the Downstream Unsolicited mode. I believe special care should be taken for the two situations, but = the details is beyond the RFC for the time being.If you can give us some = pieces of advice on that, it would be of great help. Best wishes! Li Yixiang 01/06/11 ------=_NextPart_000_0011_01C0F31C.BFCEAA40-- From owner-mpls@UU.NET Tue Jun 12 09:45:42 2001 Received: from cmr0.ash.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 JAA14914 for ; Tue, 12 Jun 2001 09:45:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcg01456; Tue, 12 Jun 2001 13:43:39 GMT Received: by mail-control.mail.uu.net id QQktcg19107 for mpls-outgoing; Tue, 12 Jun 2001 13:42:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktcg18740 for ; Tue, 12 Jun 2001 13:39: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 QQktcg17127 for ; Tue, 12 Jun 2001 13:39:04 GMT From: Ashwinp@in.huawei.com Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQktcg26124 for ; Tue, 12 Jun 2001 13:39:02 GMT Received: by tor-cm1.cisco.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 19:11:58 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C56873F3E86@tor-cm1.cisco.com> To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: What we do if the LSP is preempted Date: Tue, 12 Jun 2001 19:11:57 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F349.A3EBDDC0" 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_01C0F349.A3EBDDC0 Content-Type: text/plain; charset="iso-8859-1" Dear all Can you please tell me what if the LSP is preempted ? Do we try to reestablish the LSP with some other path or we will just preempt it ? If we just preempt the LSP then it will be unfare with that LSP. And when should we try to reestablish that LSP ? Do anybody has any ionformation regarding this ? Thanks in advance Ashwin ------_=_NextPart_001_01C0F349.A3EBDDC0 Content-Type: text/html; charset="iso-8859-1" What we do if the LSP is preempted

Dear all

 Can you please tell me what if the LSP is preempted ? Do we try to reestablish the LSP
 with some other path or we will just preempt it ?
 If we just preempt the LSP then it will be unfare with that LSP. And when should we try to
 reestablish that LSP ?

Do anybody has any ionformation regarding this ?

Thanks in advance
Ashwin

------_=_NextPart_001_01C0F349.A3EBDDC0-- From owner-mpls@UU.NET Tue Jun 12 10:02:24 2001 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 KAA15373 for ; Tue, 12 Jun 2001 10:02:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktci18823; Tue, 12 Jun 2001 14:00:16 GMT Received: by mail-control.mail.uu.net id QQktch21146 for mpls-outgoing; Tue, 12 Jun 2001 13:59:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktch21136 for ; Tue, 12 Jun 2001 13:59: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 QQktch29568 for ; Tue, 12 Jun 2001 13:57:32 GMT Received: from exchange.pfn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [130.105.14.76]) id QQktch17288 for ; Tue, 12 Jun 2001 13:57:32 GMT Received: by exchange.tcloud.net with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 09:54:20 -0400 Message-ID: <40E27CB80FF6D411915B0008C74CCE2C0B4E09@exchange.tcloud.net> From: Fran Reichmeyer To: "'Olivier Dugeon '" , "'mpls@UU.NET '" , "'te-wg@ops.ietf.org '" Subject: RE: MPLS and COPS Date: Tue, 12 Jun 2001 09:54:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk After several attempts at introducing this to the wg, it was decided that policy is out of scope for the MPLS wg at this time. -Fran -----Original Message----- From: Olivier Dugeon To: mpls@UU.NET; te-wg@ops.ietf.org Sent: 6/12/01 4:28 AM Subject: MPLS and COPS Hi all, In a context of QoS control in a multi-domain and multi-technology network, we would use COPS as the control protocol rather than SNMP. COPS need a "Policy rules Information Base" to work. A such PIB is available for DiffServ for example. I would to know if somebody work on a PIB for MPLS. - Is there some case study inside the WG or it is out the scope/out of date ? - Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ? Thank's a lot Olivier Dugeon -- FTR&D/DAC/CPN Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 F-22307 LANNION | Fax: +(33) 2 96 05 18 52 From owner-mpls@UU.NET Tue Jun 12 10:15:46 2001 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 KAA15844 for ; Tue, 12 Jun 2001 10:15:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktci04925; Tue, 12 Jun 2001 14:13:55 GMT Received: by mail-control.mail.uu.net id QQktci12110 for mpls-outgoing; Tue, 12 Jun 2001 14:13:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktci12102 for ; Tue, 12 Jun 2001 14:13:21 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 QQktci19481 for ; Tue, 12 Jun 2001 14:11:55 GMT From: Ashwinp@in.huawei.com Received: from huaweimail.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQktci28808 for ; Tue, 12 Jun 2001 14:11:53 GMT Received: by tor-cm1.cisco.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 19:44:53 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C56873F3ED3@tor-cm1.cisco.com> To: lei.yao@wcom.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: What we do if the LSP is preempted Date: Tue, 12 Jun 2001 19:44:52 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F34E.3D562BB0" 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_01C0F34E.3D562BB0 Content-Type: text/plain; charset="iso-8859-1" Hello lei D____________________F / \ A---------------B---------------------C \_____E______/ Suppose i have a LSP ABEC of priority 3 And a LSP ADF with priority 4 Now i want to setup ABC with priority 2. As the resources are not available on link AB i will preempt LSP ABEC But there is a LSP ADF with priority 4 less than that of ABEC so if i preempt ABEC then won't it be fair to establish the LSP through ADFC and preempt ADF if enough resources are not available ? Thanks Ashwin -----Original Message----- From: Lei Yao [mailto:lei.yao@wcom.com] Sent: Tuesday, June 12, 2001 6:38 PM To: Ashwinp@in.huawei.com Subject: RE: What we do if the LSP is preempted A LSP is preempted because of the lack of network resource. In other words, there is network congestion. Therefore, you should not try to re-build the preempted LSP. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Ashwinp@in.huawei.com Sent: Tuesday, June 12, 2001 10:12 AM To: mpls-ops@mplsrc.com; mpls@UU.NET Subject: What we do if the LSP is preempted Dear all Can you please tell me what if the LSP is preempted ? Do we try to reestablish the LSP with some other path or we will just preempt it ? If we just preempt the LSP then it will be unfare with that LSP. And when should we try to reestablish that LSP ? Do anybody has any ionformation regarding this ? Thanks in advance Ashwin ------_=_NextPart_001_01C0F34E.3D562BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What we do if the LSP is preempted
 
Hello=20 lei
 
 =20 D____________________F
 /      &n= bsp;           &n= bsp;           &n= bsp;       =20 \
A---------------B---------------------C
       &nb= sp;          =20 \_____E______/
 
Suppose i have a LSP ABEC of priority=20 3
And a=20 LSP ADF with priority 4
 
Now i=20 want to setup ABC with priority 2.
As the=20 resources are not available on link AB i will preempt LSP=20 ABEC
But=20 there is a LSP ADF with priority 4 less than that of ABEC so if i=20 preempt
ABEC=20 then won't it be fair to establish the LSP through ADFC and preempt ADF =
if=20 enough resources are not available ?
Thanks
Ashwin
 
-----Original Message-----
From: Lei Yao=20 [mailto:lei.yao@wcom.com]
Sent: Tuesday, June 12, 2001 6:38 = PM
To: Ashwinp@in.huawei.com
Subject: RE: What we = do if=20 the LSP is preempted

A LSP=20 is preempted because of the lack of network resource. In other words, = there is=20 network congestion. Therefore, you should not try to re-build the = preempted=20 LSP.

 

=

-----Original=20 Message-----
From: = owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of=20 Ashwinp@in.huawei.com
Sent: Tuesday, June 12, 2001 = 10:12=20 AM
To: = mpls-ops@mplsrc.com;=20 mpls@UU.NET
Subject: What we=20 do if the LSP is preempted

 

 

Dear=20 all=20

 Can = you please=20 tell me what if the LSP is preempted ? Do we try to reestablish the = LSP=20
 with some=20 other path or we will just preempt it ?
 If = we just=20 preempt the LSP then it will be unfare with that LSP. And when should = we try=20 to
 reestablish=20 that LSP ?=20

Do = anybody has any=20 ionformation regarding this ?

Thanks in = advance=20
Ashwin

------_=_NextPart_001_01C0F34E.3D562BB0-- From owner-mpls@UU.NET Tue Jun 12 10:26:55 2001 Received: from cmr0.ash.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 KAA16229 for ; Tue, 12 Jun 2001 10:26:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcj17229; Tue, 12 Jun 2001 14:25:18 GMT Received: by mail-control.mail.uu.net id QQktcj13121 for mpls-outgoing; Tue, 12 Jun 2001 14:24:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktcj13116 for ; Tue, 12 Jun 2001 14:24:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktcj09159 for ; Tue, 12 Jun 2001 14:22:56 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktcj11246 for ; Tue, 12 Jun 2001 14:22:56 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 1863C9400B; Tue, 12 Jun 2001 10:22:51 -0400 (EDT) Message-ID: <3B2625BB.1A547B6C@sandburst.com> Date: Tue, 12 Jun 2001 10:22:51 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: suchauhan@hss.hns.com Cc: mpls@UU.NET Subject: Re: Section A.1.2 RFC 3036 concerns! References: <65256A69.002AA10F.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit suchauhan@hss.hns.com wrote: > Hi! > I have a few concerns regarding the algo defined in this section > > 1. LMp.10 - In this case should we not consider this as a dual purpose message > for the release of the previous label and installing the new label generated by > the same downstream LSR. I strongly think it gives a better logic to the > situation here as we have confirmed already that this is from our current > next-hop for that FEC. No. See "http://cell.onecall.net/mhonarc/mpls/current/msg00004.html", second paragraph in particular. > > > 2. LMp.14 - How do we actually define a Ingress LSR? In my opinion any LSR > should be able to act as Ingress atleast till the point the network IGP comes > into stable state as till that point packets to the same destination may be > coming from different Ingress routers. I would probably use something like - For > the LMp.14 case we should have a FTN entry created and then time it out using > say LRU algorithm to keep the size of FTN in check. Am I correct? Out of scope for specification. This falls under the heading of 'figure it out or find another line of work'. :-) (Your opinion on who must be an Ingress is not technically correct. Apply the same reasoning to who must be an egress, and you may find some satisfaction) See any of about a thousand postings on Label Edge Router functionality, over the last 2 years. > > > 3. LMp.17 - Why do we need to send this also to the Peer LSR fro which the > mapping has been learnt? Someone has raised the question earlier as well but I > am still not convinced about the right approach here. See note 7 - as it already says. > > > 4. LMp.21 - In the message sent should not "PrevAdvLabel" be just "Label". We > are only sending the current mapping and not the previous one here. No. We are re-advertising the same label - in case there is a change in hop count or path vector. > > > 5. Lmp.28 - Should this not be done before LMp.20 so that we may not have to > resend to the same peer twice (once because we are in DU mode and again when we > realise we also have an outstanding request for a label from the same peer). I > know this will not cause a problem as the peer will reject the second mapping > but seems an awful waste of processing and network bandwidth (same as in point 1 > above). No. Assume we are operating in DU advertisement, ordered control, mode. If we have an outstanding request from an LSR peer that is upstream with respect to a particular FEC, then it MUST be because the upstream LSR is looking for at least two labels. The label advertisement mode is negotiated between peers and both must use the mode negotiated. Therefore, for an LSR that is operating in DU mode to send a label request, it must expect at least two label mappings. The current procedure arrives at the correct behavior. > > > regards > sumit From owner-mpls@UU.NET Tue Jun 12 10:44:52 2001 Received: from cmr1.ash.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 KAA16808 for ; Tue, 12 Jun 2001 10:44:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktck03784; Tue, 12 Jun 2001 14:43:16 GMT Received: by mail-control.mail.uu.net id QQktck14683 for mpls-outgoing; Tue, 12 Jun 2001 14:42:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktck14675 for ; Tue, 12 Jun 2001 14:42:37 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 QQktck12573 for ; Tue, 12 Jun 2001 14:40:49 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktck01041 for ; Tue, 12 Jun 2001 14:40:49 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id B71519400B; Tue, 12 Jun 2001 10:40:48 -0400 (EDT) Message-ID: <3B2629F0.8E5D1188@sandburst.com> Date: Tue, 12 Jun 2001 10:40:48 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: zze-PELLE Thierry StagiaireFTRD/DAC/ISS , Manoj Dutta Cc: Sumit , mpls@UU.NET Subject: Re: Label Mapping !! References: <98388C05D464D111B61800805F150416029AB381@p-ibis.rd.francetelecom.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thierry/Sumit/Manoj, Consider the following simple analysis: o assume that a router has N interfaces for routing in a given routing domain o assume (for simplicity) it is not multipathing on any of these interfaces o then - for any specific FEC - o it has exactly one output interface to a nexthop for that FEC o it has N-1 interfaces over which it might receive a packet destined for that nexthop and FEC o and, if there is a route change that changes the nexthop, then one of the N-1 previously upstream peers MUST be the new nexthop. Therefore, it does not take a strange case to produce a scenario in which a router that was forwarding packets to another becomes the next hop for those same packets. -- Eric Gray So far, it has been writ: > HI, > > hi! > > IMHO this is not correct as the LSR from which the label > > mapping has beeen > > learnt can never be the upstream LSR for the same mapping - liberal or > > conservative mode notwithstanding. > > Even if the IGP completely change the route for the FEC? > > e.g. > > If the network is ------- > / \ > A----B----C----D > | | > \----E > > > First, the Path from A to E may be A B C D E. In this case, > ------- > / \ > A-->-B-->-C-->-D > | \|/ > \----E > hence, C is upstream with respect to D : C uses the label distributed by D. > > If the path from A to E changed to A B D C E. In this case, > --->--- > / \ > A-->-B----C--<-D > \|/ | > \----E > here, D is upstream with respect to C : D uses the label distributed by C. > > Finally, in liberal mode, if C has distributed a label to D (in the first > case, where D was the Next Hop for C), it can use it directly. > > This is a quite strange case but it seems to be ok. > > Thierry > From owner-mpls@UU.NET Tue Jun 12 11:00:05 2001 Received: from cmr0.ash.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 LAA17174 for ; Tue, 12 Jun 2001 11:00:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcl23161; Tue, 12 Jun 2001 14:58:20 GMT Received: by mail-control.mail.uu.net id QQktcl16455 for mpls-outgoing; Tue, 12 Jun 2001 14:57:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktcl16446 for ; Tue, 12 Jun 2001 14:57:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktcl05766 for ; Tue, 12 Jun 2001 14:54:00 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQktcl16036 for ; Tue, 12 Jun 2001 14:53:59 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id f5CKVqZ11748 for ; Tue, 12 Jun 2001 20:31:53 GMT Received: from soflt.alc.wipinfo.soft.net ([192.168.220.205]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GET6T100.MQR; Tue, 12 Jun 2001 14:11:25 +0530 Date: Tue, 12 Jun 2001 14:11:30 +0530 (IST) From: "chetan kumar s" X-Sender: chetansk@soflt.alc.wipinfo.soft.net Reply-To: chetan.kumar@wipro.com To: suchauhan@hss.hns.com cc: zze-PELLE Thierry StagiaireFTRD/DAC/ISS , "'Manoj Dutta'" , mpls@UU.NET Subject: RE: Label Mapping !! In-Reply-To: <65256A69.002443F5.00@sandesh.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > > hi! > IMHO this is not correct as the LSR from which the label mapping Hi, If look at the Notes:7 given in A.1.2, things are quite clear. The reason for including the message source is to handle the unsolicited ordered control mode. If the label is not sent to the next hop(upstream) for the FEC, the next hop may not have the label to use. Later if the next hop becomes the downstream for the FEC in question and since we are in unsoliciated ordered, the new next hop would have no way to request for the label. Of course the received may wish to release the same based on his retention mode, under which condition the next hop would be in request-on-request so that it can request for label. Thanks Chetan S > has beeen learnt can never be the upstream LSR for the same mapping - > liberal or conservative mode notwithstanding. > > regards > sumit > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on > 06/12/2001 12:02:39 PM > > To: "'Manoj Dutta'" , mpls@UU.NET > cc: (bcc: Sumit Chauhan/HSS) > > Subject: RE: Label Mapping !! > > > > > Hi, > > I had some doubts in RFC 3036. In section A.1.2, LMp.17 and A.1.6 > > FEC.1, an LSR seems to send mappings for a given FEC to the next hop > > for the same FEC. If so, why ? > > As I understand it, this is due to the existance of liberal mode : in case > of LDP reconstuction, the former Next Hop (downstrem located) may become a > LSR upstream located. > > Rigth? > > Thierry > > > > From owner-mpls@UU.NET Tue Jun 12 11:02:21 2001 Received: from cmr1.ash.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 LAA17213 for ; Tue, 12 Jun 2001 11:02:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcm24020; Tue, 12 Jun 2001 15:00:38 GMT Received: by mail-control.mail.uu.net id QQktcm16632 for mpls-outgoing; Tue, 12 Jun 2001 15:00:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktcl16602 for ; Tue, 12 Jun 2001 14:59:45 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 QQktcl20738 for ; Tue, 12 Jun 2001 14:54:57 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktcl19298 for ; Tue, 12 Jun 2001 14:54:57 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 006B39400B; Tue, 12 Jun 2001 10:54:56 -0400 (EDT) Message-ID: <3B262D40.7CDF7989@sandburst.com> Date: Tue, 12 Jun 2001 10:54:56 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: nagendras@netbrahma.com, vijayc@hclt.com Cc: suchauhan@hss.hns.com, Bob Thomas , mpls@UU.NET Subject: Re: Error in RFC 3036?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nagendra/Sumit/Vijay, LDP did not include discussion of timeouts as this is out of scope for the specification. The Label Request Abort message does allow an implementation to use a timeout. Since LDP relies on routing, it is assumed that a routing loop is a transient condition. By not forwarding a Label Request in which a loop has been detected, looping of the LSP control messages is not continued. It is not necessary to remove a loop created by Label Request messages since such a loop cannot produce a loop in the data path. This is not true for Label Mappings - therefore, in the Label Mapping case, it is a good idea to release the mappings and clean up state. In the Label Request case, when the loop is resolved, recognize new nexthop will ensure that wrong state is cleared up and the rest of the Label Request process reaches completion. -- Eric Gray You wrote: > Yeah, actually I missed that point! > --tomar > > On Tue, 12 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > hi nagendra! > > In case we are using Loop Detection in a MPLS domain (or for that matter > > over an LSP) and then in the case considered above the Loop Detection when > > detected at a LSR shall be the first to detect it and hence it is before the > > loop has actually occurred further down the LSP. We have still not reached the > > receiver as this is an Intermediate LSP. Hence there should not be a loop if we > > send back a notification to the source. > > > > regards > > sumit > > > > > > > > > > Nagendra Singh Tomar on 06/12/2001 08:55:44 AM > > > > Please respond to nagendras@netbrahma.com > > > > To: Bob Thomas > > cc: nagendras@netbrahma.com, Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > > Subject: Re: Error in RFC 3036?? > > > > > > > > > > Bob! > > I am sorry if I did'nt put it correctly, but by saying that the > > Loop Detected Notification might in turn Loop, I meant that since a loop > > was detected on the label request received, there is a very high > > possibility that the return path (from the receiver of the label request > > to the sender of the Label request) for the notification message might as > > well loop so its better to silently discard it. > > > > Is'nt it because of this Bob ? > > > > regards > > tomar > > > > > > On Mon, 11 Jun 2001, Bob Thomas wrote: > > > > > Tomar, > > > > > > > If the node detects a loop in the label request message, the its wise not > > > > to send the loop detected notification, because that might in turn loop > > > > > > Note that the Loop Detected Notification is not propagated by the > > > receiver, and therefore will not loop. > > > > > > Bob > > > > > > > > > > and make the network conditions worse. In the LRq.2 case the loop is not > > > > detected in the label request message so we are sure that the return path > > > > for the notification message has no loop, so it is safe to send a > > > > notification in that case. > > > > > > > > --tomar > > > > > > > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > > > > > > > > > > > > > yup sorry! LRq.4 it is. typo ;o) > > > > > > > > > > > > > > > > > > > > > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" > > on > > > > > 06/11/2001 03:27:43 PM > > > > > > > > > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > > > cc: > > > > > > > > > > Subject: RE: Error in RFC 3036?? > > > > > > > > > > > > > > > > > > > > > > > > > > IMHO, should it not be > > > > > > If Loop Detected , got to LRq.5 > > > > > > > > > > LRq.4 and not LRq.5 I think.... > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Nagendra Singh Tomar > > > > > > > > Residence: > > > > 369 KHB Colony > > > > 5th Block Koramangala > > > > Bangalore 95 > > > > INDIA > > > > Phone : 5524839 > > > > email : nagendras@netbrahma.com > > > > > > > > > > > > "Sometimes quantity becomes quality" > > > > --Gary Kasparov, > > > > When he played against Deep Blue. He said this after looking at a > > > > computer which found a forced mate in 249 in an endgame, after calculating > > > > all the possible moves with only 5 pieces left on the board. > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > -- > > > > > > ------------------------------------------------------------------------------ > > Nagendra Singh Tomar > > > > Residence: > > 369 KHB Colony > > 5th Block Koramangala > > Bangalore 95 > > INDIA > > Phone : 5524839 > > email : nagendras@netbrahma.com > > > > > > "Sometimes quantity becomes quality" > > --Gary Kasparov, > > When he played against Deep Blue. He said this after looking at a > > computer which found a forced mate in 249 in an endgame, after calculating > > all the possible moves with only 5 pieces left on the board. > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > -- > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ From owner-mpls@UU.NET Tue Jun 12 11:38:14 2001 Received: from cmr1.ash.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 LAA17795 for ; Tue, 12 Jun 2001 11:38:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktco04064; Tue, 12 Jun 2001 15:36:35 GMT Received: by mail-control.mail.uu.net id QQktco10395 for mpls-outgoing; Tue, 12 Jun 2001 15:35:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktco10370 for ; Tue, 12 Jun 2001 15:35:44 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 QQktco27720 for ; Tue, 12 Jun 2001 15:31:57 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQktco07962 for ; Tue, 12 Jun 2001 15:31:57 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA17577; Tue, 12 Jun 2001 17:31:53 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA20426; Tue, 12 Jun 2001 17:31:54 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 17:31:52 +0200 Message-ID: From: Hummel Heinrich To: "'liyixiang'" , mpls@UU.NET Subject: AW: seek for your help! Date: Tue, 12 Jun 2001 17:31:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F354.CD1546E0" 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_01C0F354.CD1546E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable it is awfully bad, to leave it up to the configuration of an interface = whether to allow downstream-on-demand or unsolicited-downstream. This distinction needs to be signalled in any LSP establishment = message, be it Label_Request or be it Label_Mapping. =20 Heinrich Hummel Siemens AG -----Urspr=A8=B9ngliche Nachricht----- Von: liyixiang [mailto:liyixiang@huawei.com] Gesendet: Dienstag, 12. Juni 2001 02:51 An: mpls@UU.NET Betreff: seek for your help! Thank you for any piece of advice you sent to me! =20 ------_=_NextPart_001_01C0F354.CD1546E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
it is=20 awfully bad, to leave it up to the configuration of an interface = whether to=20 allow downstream-on-demand or = unsolicited-downstream.
This=20 distinction needs to be signalled in any LSP establishment message, be = it=20 Label_Request or be it Label_Mapping.
 
Heinrich Hummel
Siemens AG
-----Urspr=A8=B9ngliche Nachricht-----
Von: = liyixiang=20 [mailto:liyixiang@huawei.com]
Gesendet: Dienstag, 12. Juni = 2001=20 02:51
An: mpls@UU.NET
Betreff: seek for your=20 help!

Thank you for any piece of advice you sent to=20 me!
 
------_=_NextPart_001_01C0F354.CD1546E0-- From owner-mpls@UU.NET Tue Jun 12 11:39:41 2001 Received: from cmr0.ash.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 LAA17865 for ; Tue, 12 Jun 2001 11:39:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktco09633; Tue, 12 Jun 2001 15:38:03 GMT Received: by mail-control.mail.uu.net id QQktco10464 for mpls-outgoing; Tue, 12 Jun 2001 15:36:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktco10390 for ; Tue, 12 Jun 2001 15:35: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 QQktcn04264 for ; Tue, 12 Jun 2001 15:29:35 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQktcn04860 for ; Tue, 12 Jun 2001 15:29:34 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5CFTcU25527 for ; Tue, 12 Jun 2001 08:29:38 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA06525 for mpls@uu.net; Tue, 12 Jun 2001 11:29:32 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktcm18064 for ; Tue, 12 Jun 2001 15:01: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 QQktcl25425 for ; Tue, 12 Jun 2001 14:58:35 GMT Received: from p-mail2.cnet.fr by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQktcl21349 for ; Tue, 12 Jun 2001 14:58:35 GMT Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 16:58:10 +0200 Received: from rd.francetelecom.com (lat4074.rd.francetelecom.fr [161.104.15.15]) by l-mhs1.lannion.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GQ90QMCK; Tue, 12 Jun 2001 16:57:44 +0200 Message-ID: <3B262DC5.3EE72AC3@rd.francetelecom.com> Date: Tue, 12 Jun 2001 16:57:09 +0200 From: Olivier Dugeon Organization: France Telecom R&D X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-21mdksmp i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: Fran Reichmeyer CC: "'mpls@UU.NET '" , "'te-wg@ops.ietf.org '" Subject: Re: MPLS and COPS References: <40E27CB80FF6D411915B0008C74CCE2C0B4E09@exchange.tcloud.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Fran Reichmeyer wrote: > > After several attempts at introducing this to the wg, it > was decided that policy is out of scope for the MPLS wg at this > time. > -Fran Ok, But is there another place for this study ? Apprently the RAP WG delegate the PIB study in the appropriate WG like SNMP do with the MIB. If the PIB is not study under MPLS or TE-WG is that significate that there is not possiblity to use COPS with MPLS? Olivier -- FTR&D/DAC/CPN Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 F-22307 LANNION | Fax: +(33) 2 96 05 18 52 From owner-mpls@UU.NET Tue Jun 12 11:52:28 2001 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 LAA18096 for ; Tue, 12 Jun 2001 11:52:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcp07804; Tue, 12 Jun 2001 15:50:38 GMT Received: by mail-control.mail.uu.net id QQktcp12265 for mpls-outgoing; Tue, 12 Jun 2001 15:50:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktcp11925 for ; Tue, 12 Jun 2001 15:46:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktcp03428 for ; Tue, 12 Jun 2001 15:45:23 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 QQktcp18898 for ; Tue, 12 Jun 2001 15:45:21 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA20570 for ; Tue, 12 Jun 2001 17:45:19 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA26055 for ; Tue, 12 Jun 2001 17:45:19 +0200 (MET DST) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 17:45:18 +0200 Message-ID: From: Hummel Heinrich To: mpls@UU.NET Subject: How is penultimate label popping requested/discouraged by signall ing ? Date: Tue, 12 Jun 2001 17:45:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F356.AE1EE050" 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_01C0F356.AE1EE050 Content-Type: text/plain; charset="gb2312" Hello, How is penultimate label popping requested resp. discouraged by explicit signalling? IMHO: it would be very bad if the penultimate LSR would do the label popping implicitly, i.e. by checking whether his next hop router is also the egress of the LSP and without permission ! Heinrich Hummel, Siemens AG ------_=_NextPart_001_01C0F356.AE1EE050 Content-Type: text/html; charset="gb2312"
Hello,
How is penultimate label popping requested resp. discouraged by explicit signalling?
 
IMHO: it would be very bad if the penultimate LSR would do the label popping implicitly, i.e. by checking whether
his next hop router is also the egress of the LSP and without permission !
 
Heinrich Hummel,
Siemens AG
------_=_NextPart_001_01C0F356.AE1EE050-- From owner-mpls@UU.NET Tue Jun 12 12:30:10 2001 Received: from cmr0.ash.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 MAA18784 for ; Tue, 12 Jun 2001 12:30:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcr12463; Tue, 12 Jun 2001 16:28:29 GMT Received: by mail-control.mail.uu.net id QQktcr06833 for mpls-outgoing; Tue, 12 Jun 2001 16:27:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktcr06818 for ; Tue, 12 Jun 2001 16:27: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 QQktcr06831 for ; Tue, 12 Jun 2001 16:27:20 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 QQktcr08023 for ; Tue, 12 Jun 2001 16:27:19 GMT Received: (qmail 13441 invoked by uid 104); 12 Jun 2001 16:27:18 -0000 Received: from Sajith_Kizhikkepurayil@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.398627 secs); 12/06/2001 09:27:18 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 12 Jun 2001 16:27:17 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5CGRHG20598; Tue, 12 Jun 2001 09:27:17 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 09:30:42 -0700 Message-ID: <219DA90B32B7D411B90E00306E0071FC1529E2@sje4exm01.pmc-sierra.bc.ca> From: Sajith Kizhikkepurayil To: "'raszuk@cisco.com'" Cc: mpls@UU.NET Subject: RE: swap & push operation Date: Tue, 12 Jun 2001 09:30:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk hi robert thanks for the clarification, the slide had it clearly explained so if i want to establish an explicit path between 2 LSRs do I need to use swap&push always, or is it only in special case like this ? thanks sajith >One example can be the CSC (Carrier of Carriers) case. When the packet >from ISP CE router is received to the carrier network it is a labeled >packet. The label is ahead of time distributed from Carrier's PE to the >CE. > >At the PE based on the incomming label value the label is being swapped >+ new IGP label is being pushed on top of stack to get packets to the >other side PE of the carrier (the one which faces the other ISP). > >For more graphical picture of this take a look at page from the below >ppt url (sorry for this but I hate draw ascii pictures :). >ftp://ftp-eng.cisco.com/rraszuk/interas_csc/RR_CSC_InterAS.ppt > >R. > >> Sajith Kizhikkepurayil wrote: >> >> hi >> >> from rfc 3031: >> ---- >> c) replace the label at the top of the label stack with a >> specified new label, and then push one or more specified new >> labels onto the label stack. >> ---- >> >> could somebody give me an application scenario ? >> >> i understand that this is useful in ingress of an LSP >> i would like to know how exactly it works with respect >to deciding >> the next hop, and how is the label that swaped&pushed being >> is decided >> >> if this is already being discussed, please give me the >pointers. >> >> thanks >> sajith > From owner-mpls@UU.NET Tue Jun 12 12:58:57 2001 Received: from cmr0.ash.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 MAA19466 for ; Tue, 12 Jun 2001 12:58:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktct20766; Tue, 12 Jun 2001 16:57:26 GMT Received: by mail-control.mail.uu.net id QQktct14226 for mpls-outgoing; Tue, 12 Jun 2001 16:56:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktct14209 for ; Tue, 12 Jun 2001 16:56:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQktct16791 for ; Tue, 12 Jun 2001 16:55:11 GMT From: francis.arts@alcatel.be Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQktct02236 for ; Tue, 12 Jun 2001 16:55:10 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f5CGsKq13600; Tue, 12 Jun 2001 18:54:20 +0200 (MET DST) Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A69.005CDB36 ; Tue, 12 Jun 2001 18:54:14 +0200 X-Lotus-FromDomain: ALCATEL To: Hummel Heinrich cc: mpls@UU.NET Message-ID: Date: Tue, 12 Jun 2001 18:54:09 +0200 Subject: Re: How is penultimate label popping requested/discouraged by signalling? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Considering RSVP the following applies [PHP = Penultimate Hop Popping]: 1/ Logic in last (ultimate) hop. The last (ultimate) hop requests the penultimate hop to apply PHP by specifying the 'implicit null label' in the RESV message. 2/ Logic in penultimate hop. * RSVP has no mechanism that allows the penultimate hop to specify **up front** (in the PATH message) that it does not support PHP. * If the last (ultimate) hop requests the penultimate hop to do PHP, while the penultimate hop does not support this feature, the following procedure applies: The penultimate hop returns a RESV ERR message to the last hop with an error code of "routing problem" and an error value of "unacceptable label value". This behavior is described in section 4.1.1.2 of (also included for reference below). Francis. --------------------------------- 4.1.1.2. Upstream A node uses the label carried in the LABEL object as the outgoing label associated with the sender. The router allocates a new label and binds it to the incoming interface of this session/sender. This is the same interface that the router uses to forward Resv messages to the previous hops. Several circumstance can lead to an unacceptable label. 1. the node is a merge incapable ATM switch but the downstream node has assigned the same label to two senders. ***2. The implicit null label was assigned, but the node is not *** capable of doing a penultimate pop for the associated L3PID 3. The assigned label is outside the requested label range In any of these events the node send a ResvErr message with an error code of "routing problem" and an error value of "unacceptable label value". From owner-mpls@UU.NET Tue Jun 12 13:28:59 2001 Received: from cmr0.ash.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 NAA20238 for ; Tue, 12 Jun 2001 13:28:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcv25467; Tue, 12 Jun 2001 17:27:17 GMT Received: by mail-control.mail.uu.net id QQktcv07715 for mpls-outgoing; Tue, 12 Jun 2001 17:26:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktcv07674 for ; Tue, 12 Jun 2001 17:26:33 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 QQktcv14332 for ; Tue, 12 Jun 2001 17:25:17 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktcv10999 for ; Tue, 12 Jun 2001 17:25:17 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 6D99494009; Tue, 12 Jun 2001 13:25:12 -0400 (EDT) Message-ID: <3B265078.F9820CDE@sandburst.com> Date: Tue, 12 Jun 2001 13:25:12 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Hummel Heinrich Cc: mpls@UU.NET Subject: Re: How is penultimate label popping requested/discouraged by signalling ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Heinrich, It is requested using implicit NULL labels. It is discouraged by releasing the implicit NULL label (after requesting another for the same FEC). While it isn't the intention that an LSR can volunteer to do PHP, as long as the nexthop is able to forward IP packets and uses the platform wide label space, it is hard to prevent. I agree it would not be a good idea, in general, and a signaling approach is available. -- Eric Gray You wrote: > Hello,How is penultimate label popping requested resp. discouraged by explicit > signalling?IMHO: it would be very bad if the penultimate LSR would do the > label popping implicitly, i.e. by checking whetherhis next hop router is also > the egress of the LSP and without permission !Heinrich Hummel,Siemens AG From owner-mpls@UU.NET Tue Jun 12 14:02:23 2001 Received: from cmr0.ash.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 OAA21120 for ; Tue, 12 Jun 2001 14:02:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcy06437; Tue, 12 Jun 2001 18:00:49 GMT Received: by mail-control.mail.uu.net id QQktcy12136 for mpls-outgoing; Tue, 12 Jun 2001 18:00:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktcy11953 for ; Tue, 12 Jun 2001 18:00:05 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 QQktcx05362 for ; Tue, 12 Jun 2001 17:55:54 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQktcx16876 for ; Tue, 12 Jun 2001 17:55:48 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5CHtl916511 for ; Tue, 12 Jun 2001 10:55:47 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA06975 for mpls@uu.net; Tue, 12 Jun 2001 13:55:46 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktcw09423 for ; Tue, 12 Jun 2001 17:43:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQktcw00790 for ; Tue, 12 Jun 2001 17:42:22 GMT Received: from mail07b.vwh1.net by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail07b.vwh1.net [209.238.9.59]) id QQktcw00727 for ; Tue, 12 Jun 2001 17:42:21 GMT Received: from www.carrier9.com (209.238.173.203) by mail07b.vwh1.net (RS ver 1.0.60s) with SMTP id 022089414; Tue, 12 Jun 2001 13:42:07 -0400 (EDT) From: "Sukanta Ganguly" To: "Fran Reichmeyer" , "'Olivier Dugeon '" , , Subject: RE: MPLS and COPS Date: Tue, 12 Jun 2001 10:51:26 -0700 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <40E27CB80FF6D411915B0008C74CCE2C0B4E09@exchange.tcloud.net> X-Loop-Detect: 1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Maybe the TE group should be the place for this. Clearly policies should be an important traffic engineering operation. SG -----Original Message----- From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On Behalf Of Fran Reichmeyer Sent: Tuesday, June 12, 2001 6:54 AM To: 'Olivier Dugeon '; 'mpls@UU.NET '; 'te-wg@ops.ietf.org ' Subject: RE: MPLS and COPS After several attempts at introducing this to the wg, it was decided that policy is out of scope for the MPLS wg at this time. -Fran -----Original Message----- From: Olivier Dugeon To: mpls@UU.NET; te-wg@ops.ietf.org Sent: 6/12/01 4:28 AM Subject: MPLS and COPS Hi all, In a context of QoS control in a multi-domain and multi-technology network, we would use COPS as the control protocol rather than SNMP. COPS need a "Policy rules Information Base" to work. A such PIB is available for DiffServ for example. I would to know if somebody work on a PIB for MPLS. - Is there some case study inside the WG or it is out the scope/out of date ? - Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ? Thank's a lot Olivier Dugeon -- FTR&D/DAC/CPN Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.com 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 F-22307 LANNION | Fax: +(33) 2 96 05 18 52 From owner-mpls@UU.NET Tue Jun 12 14:22:06 2001 Received: from cmr1.ash.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 OAA21590 for ; Tue, 12 Jun 2001 14:22:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcz27782; Tue, 12 Jun 2001 18:20:31 GMT Received: by mail-control.mail.uu.net id QQktcz03462 for mpls-outgoing; Tue, 12 Jun 2001 18:19:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktcz03437 for ; Tue, 12 Jun 2001 18:19:30 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 QQktcz00252 for ; Tue, 12 Jun 2001 18:16:28 GMT Received: from thumper.research.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQktcz12631 for ; Tue, 12 Jun 2001 18:16:28 GMT Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f5CIFsu23803; Tue, 12 Jun 2001 14:15:54 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id OAA23945; Tue, 12 Jun 2001 14:15:54 -0400 (EDT) Message-Id: <200106121815.OAA23945@monday.research.telcordia.com> Date: Tue, 12 Jun 2001 14:15:54 -0400 (EDT) From: Ritu Chadha Reply-To: Ritu Chadha Subject: RE: MPLS and COPS To: franr@pfn.com, Olivier.Dugeon@rd.francetelecom.com, mpls@UU.NET, te-wg@ops.ietf.org, sganguly@carrier9.com Cc: chadha@mailee.research.telcordia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bCVJgg6Ww2oIQRKiA7YiMA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Been there, tried that :-). This was discussed at some length a few months ago on the tewg mailing list. The ADs did not see policy as an area that fitted within the TE WG charter at that time. Ritu >From: "Sukanta Ganguly" >To: "Fran Reichmeyer" , "'Olivier Dugeon '" , , >Subject: RE: MPLS and COPS >Date: Tue, 12 Jun 2001 10:51:26 -0700 >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >Importance: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 >X-Loop-Detect: 1 > >Maybe the TE group should be the place for this. Clearly policies should be >an important traffic engineering operation. > >SG > >-----Original Message----- >From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On >Behalf Of Fran Reichmeyer >Sent: Tuesday, June 12, 2001 6:54 AM >To: 'Olivier Dugeon '; 'mpls@UU.NET '; 'te-wg@ops.ietf.org ' >Subject: RE: MPLS and COPS > > >After several attempts at introducing this to the wg, it >was decided that policy is out of scope for the MPLS wg at this >time. >-Fran > > >-----Original Message----- >From: Olivier Dugeon >To: mpls@UU.NET; te-wg@ops.ietf.org >Sent: 6/12/01 4:28 AM >Subject: MPLS and COPS > >Hi all, > >In a context of QoS control in a multi-domain and multi-technology >network, we would use COPS as the control protocol rather than SNMP. >COPS need a "Policy rules Information Base" to work. A such PIB is >available for DiffServ for example. I would to know if somebody work on >a PIB for MPLS. > >- Is there some case study inside the WG or it is out the scope/out of >date ? >- Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ? > >Thank's a lot > >Olivier Dugeon >-- > FTR&D/DAC/CPN > Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.com > 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 > F-22307 LANNION | Fax: +(33) 2 96 05 18 52 > ============================================================================= Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1A-216R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From owner-mpls@UU.NET Tue Jun 12 14:33:46 2001 Received: from cmr0.ash.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 OAA21989 for ; Tue, 12 Jun 2001 14:33:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktda10940; Tue, 12 Jun 2001 18:32:01 GMT Received: by mail-control.mail.uu.net id QQktda05126 for mpls-outgoing; Tue, 12 Jun 2001 18:31:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktda05097 for ; Tue, 12 Jun 2001 18:31:08 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 QQktcz13830 for ; Tue, 12 Jun 2001 18:28:21 GMT Received: from abel.senecanetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQktcz27817 for ; Tue, 12 Jun 2001 18:28:21 GMT Received: (from root@localhost) by abel.senecanetworks.com (8.9.3/8.99.99) id JAA18356; Tue, 12 Jun 2001 09:33:11 -0500 Received: from vsharmapc ([10.0.1.238]) by abel.senecanetworks.com (8.9.3/8.9.3) with SMTP id JAA18300; Tue, 12 Jun 2001 09:33:11 -0500 From: "Vipul Sharma" To: Cc: Subject: RE: LSR-MIB Question Date: Tue, 12 Jun 2001 14:28:50 -0400 Message-ID: <002101c0f36d$875d08e0$ee01000a@vsharmapc> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C0F34C.004B68E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20010611224151.79246.qmail@web14508.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-scanner: echelon Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C0F34C.004B68E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Shahram, I had run into similar question a while ago...Attached is the info. which will help you for 1. My feeling is that since there is no error conditions maybe they need to be collected in mplsInSegmentDiscards. But that is just what I beleive maybe the gurus have a differing opinion. For 2, I believe that we are reqd. to keep 2 sets of stats one for the swapped label and one for the pushed label Thanx, Vip vsharma@ieee.org Attached message ================================================================= > In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see stats for errored > packets. >For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors which is "The >number of errored packets received on this segment." > My question is what type of errors make these packets errored packets >because most errored packets are dropped at the physical interface iteself >by the chips (my understanding). So does this stats put a req. to run the >phy. interface device in promiscous mode? Basically any case where a labeled packet is received and cannot be forwarded by the MPLS software. There are many cases: out of bandwidth in the switching fabric, illegal labels in the packet, etc... --Tom >Vip > -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of S. Davari Sent: Monday, June 11, 2001 6:42 PM To: mpls@UU.NET Subject: LSR-MIB Question Hi All, A few questions regarding LSR-MIB: 1) If TTL expires in an MPLS packet is the packet counted in mplsInSegmentErrors" or not? 2) If we receive a labeled packet and swap the label and then push a new label do we keep 2 sets of statistics on the outgoing segment, one for the swapped label and one for the pushed label or only one? BTW, I also noticed that in LSR-MIB a swap consists of a pop on incoming segment followed by a push on outgoing segment, this is odd !! The odder thing is that the incoming segment has a parameter called InSegmentNpop in which "N" identifies the number of pops to be performed on the insegment. How does one know in advance how many pops to perform? If you know that, then it means that all those labels that you pop are not used at all. Thanks, -Shahram _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca ------=_NextPart_000_0022_01C0F34C.004B68E0 Content-Type: message/rfc822 Content-Disposition: attachment From: "Vipul Sharma" Sender: To: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: LSR MIB question Date: Fri, 4 May 2001 11:36:58 -0400 Message-ID: <015c01c0d4b0$0ee16900$ee01000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-scanner: echelon Importance: Normal In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C18@BBY1EXM01> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit It is my understanding that both stats are to be collected to satisfy the LSR MIB. Each LSR is reqd. to collect stats for in-segments and out-segments on a per LSP basis. In case of a tunnel, it should collect stats on per LSP (which may be agg. in a tunnel) as well as the tunnel (which is a new LSP)from a LSR point of view. Atleast, this is my understanding.... Vip -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram Davari Sent: Friday, May 04, 2001 11:03 AM To: 'mpls@uu.net' Subject: LSR MIB question Hi All, If an LSR is the origin point of an MPLS tunnel, and it receives an MPLS packet, it first swaps the top label and pushes a new label on top of that. Which performance statistics are required to be collected by LSR-MIB: The swapped label or the pushed label or both? Yours, Shahram Davari ------=_NextPart_000_0022_01C0F34C.004B68E0-- From owner-mpls@UU.NET Tue Jun 12 15:58:49 2001 Received: from cmr0.ash.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 PAA23580 for ; Tue, 12 Jun 2001 15:58:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktdf17171; Tue, 12 Jun 2001 19:56:54 GMT Received: by mail-control.mail.uu.net id QQktdf04293 for mpls-outgoing; Tue, 12 Jun 2001 19:55:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktdf04279 for ; Tue, 12 Jun 2001 19:55: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 QQktdf19144 for ; Tue, 12 Jun 2001 19:50:38 GMT Received: from thumper.research.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQktdf01005 for ; Tue, 12 Jun 2001 19:50:38 GMT Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f5CJnUu00967; Tue, 12 Jun 2001 15:49:30 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id PAA23999; Tue, 12 Jun 2001 15:49:30 -0400 (EDT) Message-Id: <200106121949.PAA23999@monday.research.telcordia.com> Date: Tue, 12 Jun 2001 15:49:30 -0400 (EDT) From: Ritu Chadha Reply-To: Ritu Chadha Subject: RE: MPLS and COPS To: franr@pfn.com, Olivier.Dugeon@rd.francetelecom.com, mpls@UU.NET, te-wg@ops.ietf.org, sganguly@carrier9.com Cc: chadha@mailee.research.telcordia.com, policy@raleigh.ibm.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q3vOqZDJV2IY+PsD4bKRSA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Well, I can't comment on that except to say that I'm completely in agreement with you. You should direct your concerns to the ADs. Randy? Ritu >From: "Sukanta Ganguly" >To: "Ritu Chadha" , , , , >Subject: RE: MPLS and COPS >Date: Tue, 12 Jun 2001 11:50:35 -0700 >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >Importance: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 >X-Loop-Detect: 1 > >Ritu, > I see what you are saying and I did read some of them emails but it is >needed. I mean I don't get it (:-)). Why not have a way for TE to take in >some higher layer knowledge to perform smart engineering. There is a lot of >knowledge that can be conveyed to the lower layers from the applications >sitting on top. > > >Sukanta Ganguly >Senior Architect >Carrier9 Networks >Phone (408)-746-0400 x 119 >FAx (408)-730-9441 > >-----Original Message----- >From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com] >Sent: Tuesday, June 12, 2001 11:16 AM >To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET; >te-wg@ops.ietf.org; sganguly@carrier9.com >Cc: chadha@mailee.research.telcordia.com >Subject: RE: MPLS and COPS > > >Been there, tried that :-). > >This was discussed at some length a few months ago on the tewg mailing list. >The ADs did not see policy as an area that fitted within the TE WG charter >at that time. > >Ritu > >>From: "Sukanta Ganguly" >>To: "Fran Reichmeyer" , "'Olivier Dugeon '" >, , >>Subject: RE: MPLS and COPS >>Date: Tue, 12 Jun 2001 10:51:26 -0700 >>MIME-Version: 1.0 >>Content-Transfer-Encoding: 7bit >>X-Priority: 3 (Normal) >>X-MSMail-Priority: Normal >>Importance: Normal >>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 >>X-Loop-Detect: 1 >> >>Maybe the TE group should be the place for this. Clearly policies should be >>an important traffic engineering operation. >> >>SG >> >>-----Original Message----- >>From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On >>Behalf Of Fran Reichmeyer >>Sent: Tuesday, June 12, 2001 6:54 AM >>To: 'Olivier Dugeon '; 'mpls@UU.NET '; 'te-wg@ops.ietf.org ' >>Subject: RE: MPLS and COPS >> >> >>After several attempts at introducing this to the wg, it >>was decided that policy is out of scope for the MPLS wg at this >>time. >>-Fran >> >> >>-----Original Message----- >>From: Olivier Dugeon >>To: mpls@UU.NET; te-wg@ops.ietf.org >>Sent: 6/12/01 4:28 AM >>Subject: MPLS and COPS >> >>Hi all, >> >>In a context of QoS control in a multi-domain and multi-technology >>network, we would use COPS as the control protocol rather than SNMP. >>COPS need a "Policy rules Information Base" to work. A such PIB is >>available for DiffServ for example. I would to know if somebody work on >>a PIB for MPLS. >> >>- Is there some case study inside the WG or it is out the scope/out of >>date ? >>- Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ? >> >>Thank's a lot >> >>Olivier Dugeon >>-- >> FTR&D/DAC/CPN >> Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.com >> 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 >> F-22307 LANNION | Fax: +(33) 2 96 05 18 52 >> > ============================================================================= Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1A-216R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From owner-mpls@UU.NET Tue Jun 12 16:19:27 2001 Received: from cmr1.ash.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 QAA23892 for ; Tue, 12 Jun 2001 16:19:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktdh12899; Tue, 12 Jun 2001 20:17:53 GMT Received: by mail-control.mail.uu.net id QQktdh26251 for mpls-outgoing; Tue, 12 Jun 2001 20:17:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktdh26240 for ; Tue, 12 Jun 2001 20:16:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktdg29429 for ; Tue, 12 Jun 2001 20:14:41 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQktdg07059 for ; Tue, 12 Jun 2001 20:14:40 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5CKEhU00921 for ; Tue, 12 Jun 2001 13:14:43 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA07275 for mpls@uu.net; Tue, 12 Jun 2001 16:14:38 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktde02857 for ; Tue, 12 Jun 2001 19:43:37 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 QQktde11673 for ; Tue, 12 Jun 2001 19:39:24 GMT Received: from mail07a.vwh1.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail07a.vwh1.net [209.238.9.57]) id QQktde17863 for ; Tue, 12 Jun 2001 19:39:24 GMT Received: from www.carrier9.com (209.238.173.203) by mail07a.vwh1.net (RS ver 1.0.60s) with SMTP id 037026814; Tue, 12 Jun 2001 14:41:16 -0400 (EDT) From: "Sukanta Ganguly" To: "Ritu Chadha" , , , , Subject: RE: MPLS and COPS Date: Tue, 12 Jun 2001 11:50:35 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200106121815.OAA23945@monday.research.telcordia.com> X-Loop-Detect: 1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ritu, I see what you are saying and I did read some of them emails but it is needed. I mean I don't get it (:-)). Why not have a way for TE to take in some higher layer knowledge to perform smart engineering. There is a lot of knowledge that can be conveyed to the lower layers from the applications sitting on top. Sukanta Ganguly Senior Architect Carrier9 Networks Phone (408)-746-0400 x 119 FAx (408)-730-9441 -----Original Message----- From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com] Sent: Tuesday, June 12, 2001 11:16 AM To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET; te-wg@ops.ietf.org; sganguly@carrier9.com Cc: chadha@mailee.research.telcordia.com Subject: RE: MPLS and COPS Been there, tried that :-). This was discussed at some length a few months ago on the tewg mailing list. The ADs did not see policy as an area that fitted within the TE WG charter at that time. Ritu >From: "Sukanta Ganguly" >To: "Fran Reichmeyer" , "'Olivier Dugeon '" , , >Subject: RE: MPLS and COPS >Date: Tue, 12 Jun 2001 10:51:26 -0700 >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >Importance: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 >X-Loop-Detect: 1 > >Maybe the TE group should be the place for this. Clearly policies should be >an important traffic engineering operation. > >SG > >-----Original Message----- >From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On >Behalf Of Fran Reichmeyer >Sent: Tuesday, June 12, 2001 6:54 AM >To: 'Olivier Dugeon '; 'mpls@UU.NET '; 'te-wg@ops.ietf.org ' >Subject: RE: MPLS and COPS > > >After several attempts at introducing this to the wg, it >was decided that policy is out of scope for the MPLS wg at this >time. >-Fran > > >-----Original Message----- >From: Olivier Dugeon >To: mpls@UU.NET; te-wg@ops.ietf.org >Sent: 6/12/01 4:28 AM >Subject: MPLS and COPS > >Hi all, > >In a context of QoS control in a multi-domain and multi-technology >network, we would use COPS as the control protocol rather than SNMP. >COPS need a "Policy rules Information Base" to work. A such PIB is >available for DiffServ for example. I would to know if somebody work on >a PIB for MPLS. > >- Is there some case study inside the WG or it is out the scope/out of >date ? >- Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ? > >Thank's a lot > >Olivier Dugeon >-- > FTR&D/DAC/CPN > Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.com > 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 > F-22307 LANNION | Fax: +(33) 2 96 05 18 52 > ============================================================================ = Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1A-216R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================ = From owner-mpls@UU.NET Tue Jun 12 16:46:26 2001 Received: from cmr0.ash.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 QAA24382 for ; Tue, 12 Jun 2001 16:46:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktdi12211; Tue, 12 Jun 2001 20:44:17 GMT Received: by mail-control.mail.uu.net id QQktdi29201 for mpls-outgoing; Tue, 12 Jun 2001 20:43:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktdi29170 for ; Tue, 12 Jun 2001 20:43: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 QQktdi12545 for ; Tue, 12 Jun 2001 20:37:52 GMT From: ananth.nagarajan@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQktdi23529 for ; Tue, 12 Jun 2001 20:37:51 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f5CKdpF10420; Tue, 12 Jun 2001 15:39:52 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f5CKRas10494; Tue, 12 Jun 2001 15:27:37 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id PAA21357; Tue, 12 Jun 2001 15:27:36 -0500 (CDT) X-OpenMail-Hops: 1 Date: Tue, 12 Jun 2001 15:27:31 -0500 Message-Id: Subject: RE: GMPLS issues (was - GMPLS Last Calls) MIME-Version: 1.0 TO: BRaja@tellium.com CC: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-4167abb8-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-4167abb8-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Tue, 12 Jun 2001 15:27:31 -0500" Content-Transfer-Encoding: 7bit Bala, Thanks for your reply. Sorry it took so long to reply back. Please see in-line. Thanks, Ananth bala>> > 1) Type of legacy equipment needing NSAP addresses bala>> > (also, is bala>> > this optical network element or client equipment?) bala>> > 2) Rough estimate of number of UNI ports needing NSAP address bala>> > (2002, 2005, and 2010) bala>> > 3) Description of application in which this legacy equipment bala>> > will use UNI bala>> > signaling bala>I don't recall seeing any response. furthermore, the NSAP bala>requirement was not unanimously endorsed by all carriers (at bala>the OIF). From our OIF representatives, although it was not unanimously endorsed, there was a significant demand for NSAP support. Well, NSAP is the main non-IP type of addressing that is required. The general requirement is to be able to support non-IP addresses (probably have an address translation from non-IP addresses to routable addresses). bala>It would also be nice if you can give some insight on bala>the timeline in which you need various features, and whether bala>the current GMPLS developments are inadequate within bala>that timeline. (We can always have a progression of features). NSAP support will be needed always (e.g. support for legacy DCC that uses NSAP). So the timeframe requirement is now. Ananth>2) GMPLS is being defined based on assumptions about proprietary Ananth>transmission planes without those assumptions being specified. How can Ananth>we be sure that the control plane support is correct? How can we be Ananth>sure that it can be combined with other features? Assumptions Ananth>regarding the transmission plane that can affect the control plane must Ananth>be clearly documented. This creates the additional related problem that Ananth>there is not a clear inter-working defined for interaction between Ananth>standard/proprietary control planes/transmission planes. bala>BR: I get the feeling you're referring to the concatenation/transperency bala>issues discussed recently. While the debate has been hot, there's bala>no show stopper here. Several suggestions are being considered for bala>clarifying standard/non-standard features supported. The concatenation/transparency issues are a concern. In addition, management features such as manual protection switching, protection switching configuration, billing support (e.g. usage collection) etc need to be supported too. Ananth>3) Assuring separation of the control plane from the data plane Ananth>continues to arise.. When the control plane fails it should not affect Ananth> existing connections. Also if connections in progress are affected Ananth>then they should not leave partially setup connections - they should Ananth>fail gracefully informing the initiator. The GMPLS architecture Ananth>document mentions this separation, but it's not clear how the GMPLS Ananth>signaling specifications reflect the implications of this decoupling. bala>BR: This issue has been discussed for the OIF UNI signaling (GMPLS bala>based, as you know), and solutions in the RSVP/LDP space have been bala>proposed (some drafts may be written). bala>This is also not a show stopper by any means. Don't understand how the OIF UNI addresses this. Our concerns are more with respect to the NNI (internal separation of control and data). If this is not addressed, it is definitely a showstopper. According to our OIF representatives, the OIF is looking at the IETF to specify these protocols. To be specific, existing connections shouldn't be impacted when the control plane fails. Ananth>4) Support for NSAP addresses and in general support such that control Ananth>plane addressing is independent of clients and vice versa. Also Ananth>scalable naming/addressing scheme such as proposed in OIF. bala>BR: NSAP, see my initial comments. The OIF is not dealing with bala>names/resolution, etc. This has been decided to be out of the bala>scope of UNI signaling, and considered as a separate function. Address translation of some form (for e.g. NSAP address translation) should be supported. See comment at the beginning of the email. Ananth>5) Since the control plane may be supported via multiple protocols, Ananth>clear statement of what is - and isn't - covered in the GMPLS Signaling Ananth>Description, RSVP Extensions, LDP Extensions drafts is needed. bala>BR: Don't understand this, but doesn't look like a major issue from bala>your phrasing. Recommend the development of applicability statements to cover this (otherwise, it is difficult to understand how the different pieces join together to form a coherent picture). Ananth>6) Terminology is an issue (e.g., waveband switching, link) bala>BR: Any inconsistencies can be taken care of easily. Like your comment. Hope it is as easy as it sounds :-) Mapping of terminology between standards bodies and also between different drafts in the IETF can be painful. Agreed however, that this is not a show-stopper. Ananth>7) Transaction support for connection set-up and release is needed for Ananth>connection oriented networks (e.g. crankback capability). bala>BR: Internet drafts have already been written on crankback. I suggest bala>that you please consider writing some drafts if there is something bala>missing. Aware of the "iwata-draft". Are there others? Ananth>8) Reliable message transfer bala>BR: Very much a part of signaling. the OIF work has considered this bala>aspect also. 'soft-state' signaling protocols may not be acceptable for the optical control plane. Live channels must not be dropped as a result of signaling message delivery failures (e.g. timer refresh failures) Ananth>9) Security concerns have not been fully addressed, particularly at the Ananth> architectural level. The use of separate control network may Ananth>necessitate the need for 24 hour staff to protect against 'Denial of Ananth>Service' attacks as currently happens for IP router networks. In Ananth>general, admission control issues need to be addressed. bala>BR: Please elaborate on these, specifically, what's new in the bala>context of GMPLS. e.g. in the case of ATM UNI, if a user or users attempt too many call setups simultaneously the switch control processor can become overloaded. So, some form of call pacing/overload handling is needed. Is there something similar in the GMPLS context for optical devices? Ananth>10) The definition of transparency may be overly simplified. See Ananth>comments by Ben Mack-Crane: Ananth>I think the debate on transparency indicates that the issue is not as Ananth>clear Ananth>as we might think. The OIF document you cite defines forms of Ananth>transparency Ananth>that are very straightforward (flags 1,2) not the more complex forms in Ananth>the current GMPLS drafts (flags 3..10). Also, these are easily Ananth>provided in Ananth>O-E-O or O-O-O networks operating at the lambda level, but there is no Ananth>standard for providing these over TDM multiplexed SONET/SDH links. bala>BR: This is an ongoing topic of discussion. Doesn't break down bala>the rest of the proposal. Agreed. Ananth>If two vendors implement the same signaling but different TDM Ananth>multiplexing, that Ananth>doesn't achieve interoperability. Is there any way in the drafts to Ananth>determine the scope Ananth>of application of the various signaling elements (that is, whether they Ananth>apply to UNI or NNI, whether they apply to specific network Ananth>layers/technologies)? Ananth>11) One summary of additional items with issues includes: Ananth>- SDH/SONET transparency. Ananth>- SDH/SONET arbitrary concatenation, flexible concatenation. Ananth>- AUG-X, TUG, STS Groups signal types and LSP capabilities. Ananth>- All kinds of end-to-end protection/restoration for any layer, except Ananth>the IP layer. bala>BR: Restoration is not actually covered in the current set of drafts. bala>An earlier thread discussed this, and my suggestion is that this bala>feature be dealt with separately. Potential show-stopper for deployment if restoration is not covered. Would agree that it could be addressed separately, though. Ananth>- The label set object (only used for lambda issues). Ananth>- LSP encoding type, bandwidth encoding and GPID have to be simplified Ananth>accordingly. Ananth>- MPLS extensions to control G.709 (since multiplexing, etc is not yet Ananth>defined). bala>BR: A draft is forthcoming on this. Have been made aware of this. Thanks. Ananth>12) Support for paths across SONET/SDH gateways bala>BR: Please clarify the issues/write drafts. Quoting from Siegfried Giebl's email regarding "If I understand this document correctly, then you are completely separating SONET and SDH signal types from each other, thus making it difficult to deal with paths across SONET/SDH gateways. As an alternative, I suggest you work only with entities of level STS-1 (STM-0) and higher. On the other hand why don't you go the full way and also add 64 kb/s channels ?" Ananth> 13) Compatibility is required/desired with legacy SDH/SONET equipment Ananth>[and also legacy DWDM] bala>BR: Same as above. NSAP issue identified above. Elements within a link may not communicate using the signaling, i.e., legacy SDH/SONET equipment that does not participate in signaling (participate only in connectivity) Thanks, Ananth --openmail-part-4167abb8-00000001-- From owner-mpls@UU.NET Wed Jun 13 01:00:37 2001 Received: from cmr1.ash.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 BAA01862 for ; Wed, 13 Jun 2001 01:00:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkteq10484; Wed, 13 Jun 2001 05:00:40 GMT Received: by mail-control.mail.uu.net id QQkteq28701 for mpls-outgoing; Wed, 13 Jun 2001 05:00:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkteq28393 for ; Wed, 13 Jun 2001 05:00:01 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 QQktep26316 for ; Wed, 13 Jun 2001 04:59:43 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQktep20838 for ; Wed, 13 Jun 2001 04:59:42 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ52SD6Y; Wed, 13 Jun 2001 10:42:50 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2D7P5; Wed, 13 Jun 2001 10:27:37 +0530 From: "Vijayanand C" To: "Vipul Sharma" Cc: Subject: RE: LSR-MIB Question Date: Wed, 13 Jun 2001 10:34:25 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <002101c0f36d$875d08e0$ee01000a@vsharmapc> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Regarding the LSR MIB, the use of InSegmentNpop is not clear to me and I raised this issue earlier, but have not got a reply. If for a particular label 'N' pop operations are always done then what is the significance of the N-1 labels beneath it. Which scenario is this useful and how is the 'N' value set,especially when it is greater than 1. Regards, Vijay -----Original Message----- From: Vipul Sharma [mailto:vsharma@senecanetworks.com] Sent: Tuesday, June 12, 2001 11:59 PM To: davari@ieee.org Cc: mpls@UU.NET Subject: RE: LSR-MIB Question Shahram, I had run into similar question a while ago...Attached is the info. which will help you for 1. My feeling is that since there is no error conditions maybe they need to be collected in mplsInSegmentDiscards. But that is just what I beleive maybe the gurus have a differing opinion. For 2, I believe that we are reqd. to keep 2 sets of stats one for the swapped label and one for the pushed label Thanx, Vip vsharma@ieee.org Attached message ================================================================= > In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see stats for errored > packets. >For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors which is "The >number of errored packets received on this segment." > My question is what type of errors make these packets errored packets >because most errored packets are dropped at the physical interface iteself >by the chips (my understanding). So does this stats put a req. to run the >phy. interface device in promiscous mode? Basically any case where a labeled packet is received and cannot be forwarded by the MPLS software. There are many cases: out of bandwidth in the switching fabric, illegal labels in the packet, etc... --Tom >Vip > -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of S. Davari Sent: Monday, June 11, 2001 6:42 PM To: mpls@UU.NET Subject: LSR-MIB Question Hi All, A few questions regarding LSR-MIB: 1) If TTL expires in an MPLS packet is the packet counted in mplsInSegmentErrors" or not? 2) If we receive a labeled packet and swap the label and then push a new label do we keep 2 sets of statistics on the outgoing segment, one for the swapped label and one for the pushed label or only one? BTW, I also noticed that in LSR-MIB a swap consists of a pop on incoming segment followed by a push on outgoing segment, this is odd !! The odder thing is that the incoming segment has a parameter called InSegmentNpop in which "N" identifies the number of pops to be performed on the insegment. How does one know in advance how many pops to perform? If you know that, then it means that all those labels that you pop are not used at all. Thanks, -Shahram _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca From owner-mpls@UU.NET Wed Jun 13 01:15:47 2001 Received: from cmr1.ash.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 BAA02609 for ; Wed, 13 Jun 2001 01:15:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkter00357; Wed, 13 Jun 2001 05:15:43 GMT Received: by mail-control.mail.uu.net id QQkter19679 for mpls-outgoing; Wed, 13 Jun 2001 05:15:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkteq19582 for ; Wed, 13 Jun 2001 05:14:52 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 QQkteq06105 for ; Wed, 13 Jun 2001 05:14:40 GMT From: AsheeshJ@in.huawei.com Received: from huaweimail.in.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQkteq15357 for ; Wed, 13 Jun 2001 05:14:39 GMT Received: by tor-cm1.cisco.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 10:47:40 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C56873F4467@tor-cm1.cisco.com> To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Doubt regarding preemption Date: Wed, 13 Jun 2001 10:47:39 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F3CC.5B1896F0" 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_01C0F3CC.5B1896F0 Content-Type: text/plain; charset="iso-8859-1" Preemption is based upon the hold and setup priorities of the existing LSP and LSP to be craeted. My question is, how do we decide which LSP to preempt ? Is it that this decision is made only at the ingress or can it be made at any point in the LSP ? If it is at the Ingress, how do we chech that preemption of an LSP will make way for the creation of the other ? Thanks in advance, Asheesh ------_=_NextPart_001_01C0F3CC.5B1896F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Doubt regarding preemption

Preemption is based upon the hold and = setup priorities of the existing LSP and LSP to be craeted.
My question is, how do we decide = which LSP to preempt ? Is it that this decision is made only at the = ingress or  can it be made at any point in the LSP ?

If it is at the Ingress, how do we = chech that preemption of an LSP will make way for the creation of the = other ?

Thanks in advance,

Asheesh

------_=_NextPart_001_01C0F3CC.5B1896F0-- From owner-mpls@UU.NET Wed Jun 13 02:47:21 2001 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 CAA15489 for ; Wed, 13 Jun 2001 02:47:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktex11575; Wed, 13 Jun 2001 06:46:45 GMT Received: by mail-control.mail.uu.net id QQktex18837 for mpls-outgoing; Wed, 13 Jun 2001 06:46:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktex18800 for ; Wed, 13 Jun 2001 06:46:06 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 QQktex25129 for ; Wed, 13 Jun 2001 06:45:48 GMT From: bhupeshb@in.huawei.com Received: from huaweimail.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQktex27751 for ; Wed, 13 Jun 2001 06:45:46 GMT Received: by tor-cm1.cisco.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 12:18:43 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C56873F4721@tor-cm1.cisco.com> To: krishnan@research.bell-labs.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: Tag-switching -vs- MPLS !!! Date: Wed, 13 Jun 2001 12:18:43 +0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F3D9.13B05570" 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_01C0F3D9.13B05570 Content-Type: text/plain; charset="iso-8859-1" tag switching is the general term used to notify a methodology MPLS uses that methodology ...of tag switching. dont confuse the terms technology and methodology ... MPLs is a technology which uses a kind of methodology of tag - switching which might be in use by some other protocols or technologies too.... regards bhupesh -----Original Message----- From: Sivaramakrishna Iyer Krishnan [mailto:krishnan@research.bell-labs.com] Sent: Monday, June 11, 2001 11:44 PM To: mpls-ops@mplsrc.com Subject: Tag-switching -vs- MPLS !!! Hi All, I am not sure what is the difference between tag-switching and MPLS ????????.... Also, are all mpls commands backward compatible to tag-switching ???... Thanks, Krishnan. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------_=_NextPart_001_01C0F3D9.13B05570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Tag-switching -vs- MPLS !!!

tag switching is the general term used to notify a = methodology

MPLS uses that methodology ...of tag = switching.
dont confuse the terms technology and methodology = ...

MPLs is a technology which uses a kind of methodology = of tag - switching which might be in use by some other protocols or = technologies too....

regards
bhupesh


-----Original Message-----
From: Sivaramakrishna Iyer Krishnan
[mailto:krishnan@research= .bell-labs.com]
Sent: Monday, June 11, 2001 11:44 PM
To: mpls-ops@mplsrc.com
Subject: Tag-switching -vs- MPLS !!!



Hi All,

I am not sure what is the difference between = tag-switching and MPLS
????????....

Also, are all mpls commands backward compatible to = tag-switching ???...

Thanks,
Krishnan.

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

------_=_NextPart_001_01C0F3D9.13B05570-- From owner-mpls@UU.NET Wed Jun 13 03:52:09 2001 Received: from cmr1.ash.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 DAA17241 for ; Wed, 13 Jun 2001 03:52:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktfb19594; Wed, 13 Jun 2001 07:51:25 GMT Received: by mail-control.mail.uu.net id QQktfb15323 for mpls-outgoing; Wed, 13 Jun 2001 07:50:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktfb15236 for ; Wed, 13 Jun 2001 07:50:42 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 QQktfb00954 for ; Wed, 13 Jun 2001 07:50:37 GMT From: bhupeshb@in.huawei.com Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQktfb09892 for ; Wed, 13 Jun 2001 07:50:35 GMT Received: by tor-cm1.cisco.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 13:23:36 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C5687419FA4@tor-cm1.cisco.com> To: mpls@UU.NET Cc: mpls-ops@mplsrc.com Date: Wed, 13 Jun 2001 13:23:35 +0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F3E2.23FEBF30" 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_01C0F3E2.23FEBF30 Content-Type: text/plain; charset="iso-8859-1" apologies for my previous reply .... as it wasnt mentioned in the question that by "tag-switching" actually meant was,,,"cisco tag-switching" so in that context ...my reply doesnt hold valid apologies for that mistake bhupesh ________________________________________ Bhupesh Bajaj Huawei Technologies India Pvt. Ltd. Leela Galleria , 3rd Floor The Leela Palace, No. 23, Airport Road , Bangalore - 560008 Tel : 5200322/23/24/25 extn: 469 email : bhupeshb@in.huawei.com ------_=_NextPart_001_01C0F3E2.23FEBF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

apologies for my previous reply = ....

as it wasnt mentioned in the question = that by "tag-switching" actually meant was,,,"cisco = tag-switching"
so in that context ...my reply doesnt = hold valid

apologies for that mistake
bhupesh


________________________________________
  = Bhupesh Bajaj
  = Huawei Technologies India Pvt. Ltd.
   Leela Galleria , 3rd = Floor
   The Leela Palace, No. 23,
   Airport Road , Bangalore - 560008
   Tel : 5200322/23/24/25  extn: 469
   email : bhupeshb@in.huawei.com =


------_=_NextPart_001_01C0F3E2.23FEBF30-- From owner-mpls@UU.NET Wed Jun 13 06:00:28 2001 Received: from cmr0.ash.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 GAA17947 for ; Wed, 13 Jun 2001 06:00:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktfk29688; Wed, 13 Jun 2001 10:00:16 GMT Received: by mail-control.mail.uu.net id QQktfj10770 for mpls-outgoing; Wed, 13 Jun 2001 09:59:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktfj10750 for ; Wed, 13 Jun 2001 09:59:33 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 QQktfj23624 for ; Wed, 13 Jun 2001 09:59:26 GMT Received: from smtp.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.135.132]) id QQktfj27316 for ; Wed, 13 Jun 2001 09:58:53 GMT Received: from z97716 ([10.110.10.147]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GEV4AA01.R21; Wed, 13 Jun 2001 17:42:10 +0800 Message-ID: <002c01c0f3ed$f6251d00$930a6e0a@huawei.com> From: "Heqing Zhu" To: "Vijayanand C" Cc: References: Subject: Re: LSR-MIB Question Date: Wed, 13 Jun 2001 17:48:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id GAA17947 When using the label stack, if there are several layers, and egress router is the same router. So I think you need pop these labels. If I am wrong, please correct me. > Hello, > Regarding the LSR MIB, the use of InSegmentNpop is not clear to me and I > raised this issue earlier, but have not got a reply. If for a particular > label 'N' pop operations are always done then what is the significance of > the N-1 labels beneath it. Which scenario is this useful and how is the 'N' > value set,especially when it is greater than 1. > > Regards, > Vijay > From owner-mpls@UU.NET Wed Jun 13 09:14:47 2001 Received: from cmr1.ash.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 JAA22173 for ; Wed, 13 Jun 2001 09:14:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktfw03854; Wed, 13 Jun 2001 13:14:00 GMT Received: by mail-control.mail.uu.net id QQktfw21979 for mpls-outgoing; Wed, 13 Jun 2001 13:13:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktfw21970 for ; Wed, 13 Jun 2001 13:13: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 QQktfw27641 for ; Wed, 13 Jun 2001 13:09:29 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQktfw23105 for ; Wed, 13 Jun 2001 13:09:28 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Wed, 13 Jun 2001 14:08:57 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 13 Jun 2001 14:08:48 +0100 Message-ID: To: Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 14:08:47 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Where is the issue ? Why do we need NSAP addresses in GMPLS ? > > Kind regards, > > Eric > Eric, I understand your points on the 'management network'......that is, the addressing of it's user-plane is a separate network to the user-plane offered for cutsomer connections. So let me concentrate on the 'external' user-plane here in an attempt to answer your question. Seems we have some choices in GMPLS at the moment: Addressing - v4 or v6 Signalling - RSVP or CR-LDP Routing - OSPF or IS-IS (but exterior is BGP only) All these facets are, in principle, independent choices. And, in particular, since 'server layer trails = client layer links' then addressing cannot be from the same space at a server and client layer. The addressing might have exactly the same format, but it comes from a different space, ie address X at layer M is not = address X at layer M. Given that the layers have to be decoupled in the general case (for commercial as well as technical reasons - see the BT 'Freeland' requirements draft to 12/00 mtg) then there seems to be no reason why an operator could not use NSAPs for the access points of SDH or OTNs if he so wished. And, given this choice, that operator might also prefer to use PNNI as the signalling/routing solution too. So, the issue seems not one of 'necesssity' but simply choice......though there may be certain technical benefits of choosing 1 solution over another. I don't believe there is anything technically wrong with saying this and giving operators/vendors a choice here is there?.....if there is please point out the problems. regards, Neil From owner-mpls@UU.NET Wed Jun 13 11:10:33 2001 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 LAA24759 for ; Wed, 13 Jun 2001 11:10:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktge11776; Wed, 13 Jun 2001 15:07:43 GMT Received: by mail-control.mail.uu.net id QQktge00702 for mpls-outgoing; Wed, 13 Jun 2001 15:07:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktge00565 for ; Wed, 13 Jun 2001 15:06:57 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 QQktge21225 for ; Wed, 13 Jun 2001 15:04:43 GMT Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radiant.calient.net [63.102.55.206]) id QQktge01187 for ; Wed, 13 Jun 2001 15:04:42 GMT Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 07:59:17 -0700 Message-ID: From: John Drake To: "'Mannie, Eric'" , "'neil.2.harrison@bt.com'" , ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 07:59:15 -0700 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 Also, an ATM service using NSAP addresses for customer ports could be built on top of a GMPLS core using IP addresses internally. The ATM service delivery switches could use the GMPLS core to provison lighpaths between themselves and then run PNNI as an overlay network for purposes of exchanging NSAP reachability information. -----Original Message----- From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] Sent: Wednesday, June 13, 2001 7:33 AM To: 'neil.2.harrison@bt.com'; ananth.nagarajan@mail.sprint.com; BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Hello Neil, >Given that the layers have to be decoupled in the general case (for >commercial as well as technical reasons - see the BT 'Freeland' requirements >draft to 12/00 mtg) then there seems to be no reason why an operator could >not use NSAPs for the access points of SDH or OTNs if he so wished. And, >given this choice, that operator might also prefer to use PNNI as the >signalling/routing solution too. So, the issue seems not one of >'necesssity' but simply choice......though there may be certain technical >benefits of choosing 1 solution over another. I don't believe there is >anything technically wrong with saying this and giving operators/vendors a >choice here is there?.....if there is please point out the problems. If somebody wants to use PNNI, it is not our business. The choice between a GMPLS control plane and a PNNI control plane is not in our scope. We are here working on GMPLS at the IETF, not on PNNI at the ATM Forum and not on G.ASON at the ITU-T. GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with NSAP addresses. I don't think that somebody will choose a control plane only because it uses IP or NSAP addresses, this doesn't make sense to me. There are much more important distinctions between the two control planes than the format of the addresses. Technically I don't see arguments to adapt GMPLS to NSAP addresses, or to AppleTalk addresses or to any kind of addresses that some people could prefer, or that could come from another standardization body. If technically there is a clear benefit of using NSAP addresses instead of IP addresses in GMPLS that should be demonstrated by somebody. Up to now nobody made it (I think that when somebody wants to modify an existing work in a standardization body this has to be justified with technical reasons, not just by a personal preference). So I presume that there is today no technical argument to use NSAP addresses in GMPLS. Even if any benefit is demonstrated, that should be balanced with the disadvantages of supporting it and finaly the IETF should decide if they want to adapt their protocols to other addressing schemes. Personally, I don't think that this make sense. Moreover, GMPLS is IP centric and this is one of its driving forces. I don't see the interest of transforming an IP centric control plane in a less IP centric control plane. This is going in the opposite direction of what we are trying to do. Kind regards, Eric Eric Mannie EBONE (GTS) From owner-mpls@UU.NET Wed Jun 13 11:30:38 2001 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 LAA25163 for ; Wed, 13 Jun 2001 11:30:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktgf15835; Wed, 13 Jun 2001 15:28:36 GMT Received: by mail-control.mail.uu.net id QQktgf15079 for mpls-outgoing; Wed, 13 Jun 2001 15:28:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktgf15072 for ; Wed, 13 Jun 2001 15:27: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 QQktgf18542 for ; Wed, 13 Jun 2001 15:25:44 GMT Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radiant.calient.net [63.102.55.206]) id QQktgf23785 for ; Wed, 13 Jun 2001 15:25:44 GMT Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 08:20:18 -0700 Message-ID: From: John Drake To: "'neil.2.harrison@bt.com'" , Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 08:20:12 -0700 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 Niel, I think that the point that Eric was trying to make is that the IETF isn't the correct venue for a PNNI based solution, although a PNNI based solution might be a perfectly fine thing. From a technical perspective, unless things have changed in the past several years, the issues with using PNNI are its lack of support for pre-emption/priority and make before break, and that its bandwidth advertisements are tightly coupled to ATM service categories. Thanks, John -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Wednesday, June 13, 2001 6:09 AM To: Eric.Mannie@ebone.com; ananth.nagarajan@mail.sprint.com; BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) > Where is the issue ? Why do we need NSAP addresses in GMPLS ? > > Kind regards, > > Eric > Eric, I understand your points on the 'management network'......that is, the addressing of it's user-plane is a separate network to the user-plane offered for cutsomer connections. So let me concentrate on the 'external' user-plane here in an attempt to answer your question. Seems we have some choices in GMPLS at the moment: Addressing - v4 or v6 Signalling - RSVP or CR-LDP Routing - OSPF or IS-IS (but exterior is BGP only) All these facets are, in principle, independent choices. And, in particular, since 'server layer trails = client layer links' then addressing cannot be from the same space at a server and client layer. The addressing might have exactly the same format, but it comes from a different space, ie address X at layer M is not = address X at layer M. Given that the layers have to be decoupled in the general case (for commercial as well as technical reasons - see the BT 'Freeland' requirements draft to 12/00 mtg) then there seems to be no reason why an operator could not use NSAPs for the access points of SDH or OTNs if he so wished. And, given this choice, that operator might also prefer to use PNNI as the signalling/routing solution too. So, the issue seems not one of 'necesssity' but simply choice......though there may be certain technical benefits of choosing 1 solution over another. I don't believe there is anything technically wrong with saying this and giving operators/vendors a choice here is there?.....if there is please point out the problems. regards, Neil From owner-mpls@UU.NET Wed Jun 13 11:42:46 2001 Received: from cmr0.ash.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 LAA25474 for ; Wed, 13 Jun 2001 11:42:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktgg10581; Wed, 13 Jun 2001 15:40:58 GMT Received: by mail-control.mail.uu.net id QQktgg15915 for mpls-outgoing; Wed, 13 Jun 2001 15:40:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktgg15861 for ; Wed, 13 Jun 2001 15:40: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 QQktgg18699 for ; Wed, 13 Jun 2001 15:39:12 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQktgg08658 for ; Wed, 13 Jun 2001 15:39:11 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA00319; Wed, 13 Jun 2001 08:38:13 -0700 (PDT) Message-Id: <200106131538.IAA00319@red.juniper.net> To: neil.2.harrison@bt.com cc: Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com, wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: Re: GMPLS issues (was - GMPLS Last Calls) In-Reply-To: Your message of "Wed, 13 Jun 2001 14:08:47 BST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17180.992446693.1@juniper.net> Date: Wed, 13 Jun 2001 08:38:13 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Neil, > Eric, I understand your points on the 'management network'......that is, the > addressing of it's user-plane is a separate network to the user-plane > offered for cutsomer connections. So let me concentrate on the 'external' > user-plane here in an attempt to answer your question. > > Seems we have some choices in GMPLS at the moment: > Addressing - v4 or v6 > Signalling - RSVP or CR-LDP > Routing - OSPF or IS-IS (but exterior is BGP only) > > All these facets are, in principle, independent choices. And, in > particular, since 'server layer trails = client layer links' then addressing > cannot be from the same space at a server and client layer. The addressing > might have exactly the same format, but it comes from a different space, ie > address X at layer M is not = address X at layer M. > > Given that the layers have to be decoupled in the general case (for > commercial as well as technical reasons - see the BT 'Freeland' requirements > draft to 12/00 mtg) then there seems to be no reason why an operator could > not use NSAPs for the access points of SDH or OTNs if he so wished. Please note that there is a way to carry NSAPs in IPv6 addresses, although it does not support all types of NSAPs. (see rfc1888 for more details). Please also note that GMPLS supports IPv6 (as well as IPv4). Finally, please note that a "perfect" solution (the one that addresses all the requirements of everyone) is a *non* goal for GMPLS. > And, > given this choice, that operator might also prefer to use PNNI as the > signalling/routing solution too. So, the issue seems not one of > 'necesssity' but simply choice......though there may be certain technical > benefits of choosing 1 solution over another. I don't believe there is > anything technically wrong with saying this and giving operators/vendors a > choice here is there?.....if there is please point out the problems. Few points: 1. Providing multiple choices for performing essentially the same thing, especially if these choices have similar characteristics, doesn't help to develop multi-vendor interoperable solutions. 2. The fact that in the IETF there are not one, but two link-state IGPs (OSPF and ISIS) is a bug, and not a feature. 3. The same applies for MPLS signalling (CR-LDP vs RSVP). 4. Suggesting yet another routing/signalling protocol, in addition to GMPLS, is adding yet another bug (not a feature). 5. I understand that BT submitted a contribution to the ITU suggesting PNNI as (yet another) routing/signalling for optical cross connects. Yakov. From owner-mpls@UU.NET Wed Jun 13 12:55:19 2001 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 MAA27249 for ; Wed, 13 Jun 2001 12:55:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktgl02340; Wed, 13 Jun 2001 16:52:26 GMT Received: by mail-control.mail.uu.net id QQktgl12822 for mpls-outgoing; Wed, 13 Jun 2001 16:51:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktgl12786 for ; Wed, 13 Jun 2001 16:51:36 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 QQktgl11910 for ; Wed, 13 Jun 2001 16:51:04 GMT Received: from prue.eim.surrey.ac.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQktgl00809 for ; Wed, 13 Jun 2001 16:51:04 GMT Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15ADr9-0001Ar-00; Wed, 13 Jun 2001 17:50:59 +0100 Date: Wed, 13 Jun 2001 17:50:56 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Yakov Rekhter cc: mpls@UU.NET Subject: Re: GMPLS issues (was - GMPLS Last Calls) In-Reply-To: <200106131538.IAA00319@red.juniper.net> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15ADr9-0001Ar-00*FX0kU8NSOF6* http://duncanthrax.net/exiscan/ Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 13 Jun 2001, Yakov Rekhter wrote: > 1. Providing multiple choices for performing essentially the same > thing, especially if these choices have similar characteristics, > doesn't help to develop multi-vendor interoperable solutions. > > 2. The fact that in the IETF there are not one, but two link-state > IGPs (OSPF and ISIS) is a bug, and not a feature. > > 3. The same applies for MPLS signalling (CR-LDP vs RSVP). Beg to differ. (and you mean RSVP-TE) The IETF insists on at least two interoperable implementations of anything to consider it for a standard. This allows the standard to be proven, and to have a concept of the underlying standard that is separate to any single implementation, while allowing choice of competing implementations. Each implementation can be evaluated on its merits; this exerts pressure on the implementations, and allows debugging and improvement of the implementations with respect to the underlying standard. Similarly, going up a level of abstraction, having more than one standard fulfil an implementation of a set of ideas increases understanding of the underlying principles, independent of each standard and its implementations, while allowing choice of competing standards as expressed in their implementations. Each standard can be evaluated on its merits; this exerts pressure on the standards, and allows debugging and improvement of the standards with respect to the underlying principles and algorithms. If it wasn't for ISIS, OSPF would really suck. and vice versa. Competition is Good. L. and I see just having BGP as a problem. PGP From owner-mpls@UU.NET Wed Jun 13 13:34:26 2001 Received: from cmr1.ash.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 NAA28004 for ; Wed, 13 Jun 2001 13:34:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktgo03421; Wed, 13 Jun 2001 17:33:42 GMT Received: by mail-control.mail.uu.net id QQktgo06123 for mpls-outgoing; Wed, 13 Jun 2001 17:33:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktgo06115 for ; Wed, 13 Jun 2001 17:32:58 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 QQktgo20836 for ; Wed, 13 Jun 2001 17:31:41 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 QQktgo00824 for ; Wed, 13 Jun 2001 17:31:41 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 NAA08143 for ; Wed, 13 Jun 2001 13:31:38 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07191 for ; Wed, 13 Jun 2001 13:31:39 -0400 (EDT) Message-ID: <3B27A38E.34BFF3BB@marconi.com> Date: Wed, 13 Jun 2001 13:31:58 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Doubt regarding preemption References: <751B6DD7A243D511AB9F0002557C56873F4467@tor-cm1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit AsheeshJ@in.huawei.com wrote: > > Preemption is based upon the hold and setup priorities of the > existing LSP and LSP to be craeted. > My question is, how do we decide which LSP to preempt ? It is not specified. Every switch is free to make its own decisions. This is not a problem. If an operator wants some LSPs to have priority over others, then he should signal those LSPs with a different holding priority from them. If two LSPs are at the same priority, then it is assumed that the operator doesn't care which of the two should be preempted first. -- David From owner-mpls@UU.NET Wed Jun 13 13:58:09 2001 Received: from cmr0.ash.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 NAA28335 for ; Wed, 13 Jun 2001 13:58:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktgp04772; Wed, 13 Jun 2001 17:55:18 GMT Received: by mail-control.mail.uu.net id QQktgp08152 for mpls-outgoing; Wed, 13 Jun 2001 17:54:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktgp08144 for ; Wed, 13 Jun 2001 17:54:28 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 QQktgp26114 for ; Wed, 13 Jun 2001 17:53:29 GMT Received: from prue.eim.surrey.ac.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQktgp26160 for ; Wed, 13 Jun 2001 17:53:28 GMT Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15AEpS-0001vb-00; Wed, 13 Jun 2001 18:53:18 +0100 Date: Wed, 13 Jun 2001 18:53:15 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Robert Raszuk cc: Yakov Rekhter , mpls@UU.NET Subject: Re: GMPLS issues (was - GMPLS Last Calls) In-Reply-To: <3B27A0D1.43CE429D@cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15AEpS-0001vb-00*/SeOTQVYxQU* http://duncanthrax.net/exiscan/ Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 13 Jun 2001, Robert Raszuk wrote: > Lloyd, > > I am afraid you have missed the point. I rather think you missed mine. > Please notice that RFC2026 clearly explains the requirements for a > protocol to become a standard. It talks about the requirement for > multiple implementations of the same protocol and not about > multiple implementations of multiple protocols which could do the > same thing. I see my analogy between the sets of relationships of implementations <-> standards and standards <-> underlying algorithms/principles/ideas was lost on you... > I agree with Yakov that having numerous IGPs, or TE signalling protocols > is an IETF bug. You'd rather have IETF decree the choice of protocol by fiat? First come is the winner? That's not the IETF. (Or at least, it didn't use to be.) Redundancy and alternatives are good things. > > If it wasn't for ISIS, OSPF would really suck. and vice versa. > > Competition is Good. > > Competition is good in the implementations of the same protocol between > different vendors not betwen two groups of devlopers in the same > company. (The company should have a single group working on a protocol.) If you're talking about competing protocols with similar functionality in a company, each with its own design group, the company can always decide to only support the one it thinks is better, or that it can do better. It can make a market choice. Or split into two companies. We don't do protocol design for the convenience of a single company -- do we? > Having numerous protocols which do exactly the same thing just > waists everybodys time and resources. OSPF and IS-IS don't do _exactly_ the same thing. Think about societal benefits - you're advocating a single protocol in each area in the name of efficiency, which limits scope for advancement. That puts rather too much faith in the original design of that single protocol. Short-term efficiency loss and duplication of effort turns out to be long-term development gain. L. > > Lloyd Wood wrote: > > > > On Wed, 13 Jun 2001, Yakov Rekhter wrote: > > > > > 1. Providing multiple choices for performing essentially the same > > > thing, especially if these choices have similar characteristics, > > > doesn't help to develop multi-vendor interoperable solutions. > > > > > > 2. The fact that in the IETF there are not one, but two link-state > > > IGPs (OSPF and ISIS) is a bug, and not a feature. > > > > > > 3. The same applies for MPLS signalling (CR-LDP vs RSVP). > > > > Beg to differ. (and you mean RSVP-TE) > > > > The IETF insists on at least two interoperable implementations of > > anything to consider it for a standard. This allows the standard to be > > proven, and to have a concept of the underlying standard that is > > separate to any single implementation, while allowing choice of > > competing implementations. Each implementation can be evaluated on its > > merits; this exerts pressure on the implementations, and allows > > debugging and improvement of the implementations with respect to the > > underlying standard. > > > > Similarly, going up a level of abstraction, having more than one > > standard fulfil an implementation of a set of ideas increases > > understanding of the underlying principles, independent of each > > standard and its implementations, while allowing choice of competing > > standards as expressed in their implementations. Each standard can be > > evaluated on its merits; this exerts pressure on the standards, and > > allows debugging and improvement of the standards with respect to the > > underlying principles and algorithms. > > > > If it wasn't for ISIS, OSPF would really suck. and vice versa. > > Competition is Good. > > > > L. > > > > and I see just having BGP as a problem. PGP From owner-mpls@UU.NET Wed Jun 13 15:10:43 2001 Received: from cmr0.ash.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 PAA29630 for ; Wed, 13 Jun 2001 15:10:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktgu27341; Wed, 13 Jun 2001 19:08:50 GMT Received: by mail-control.mail.uu.net id QQktgu23912 for mpls-outgoing; Wed, 13 Jun 2001 19:08:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktgu23777 for ; Wed, 13 Jun 2001 19:08: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 QQktgu27250 for ; Wed, 13 Jun 2001 19:07:29 GMT From: ananth.nagarajan@mail.sprint.com Received: from kcmgwp01.corp.sprint.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker1.sprint.com [208.18.122.165]) id QQktgu19596 for ; Wed, 13 Jun 2001 19:07:29 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f5DJ7E427369; Wed, 13 Jun 2001 14:07:19 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f5DJ7Es09622; Wed, 13 Jun 2001 14:07:14 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id OAA11867; Wed, 13 Jun 2001 14:07:10 -0500 (CDT) X-OpenMail-Hops: 1 Date: Wed, 13 Jun 2001 14:07:09 -0500 Message-Id: Subject: RE: GMPLS issues (was - GMPLS Last Calls) MIME-Version: 1.0 TO: BRaja@tellium.com, Eric.Mannie@ebone.com CC: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com Content-Type: multipart/mixed; boundary="openmail-part-4186299a-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-4186299a-00000001 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Wed, 13 Jun 2001 14:07:09 -0500" Content-Transfer-Encoding: 7bit Eric and others, I think the NSAP support issue is being misunderstood. The requirement is to support non-IP addresses at the edge (this may include NSAP) and translate/encapsulate to a routable IP address in the core (a la in a VPN scenario, where non-unique, non-IP addresses may be supported). i.e, support just IP-based routing in the optical control plane. hope this helps clarify. Ananth -----Original Message----- From: Eric.Mannie [mailto:Eric.Mannie@ebone.com] Sent: Wednesday, June 13, 2001 5:32 AM To: Nagarajan, Ananth; BRaja Cc: Alanqar, Wesam; ccamp; Ferris, Tammy; Jones, Mark L.; mpls; Neir, Lynn Subject: RE: GMPLS issues (was - GMPLS Last Calls) Hello Ananth, >bala>> > 1) Type of legacy equipment needing NSAP addresses >bala>> > (also, is >bala>> > this optical network element or client equipment?) >bala>> > 2) Rough estimate of number of UNI ports needing NSAP address >bala>> > (2002, 2005, and 2010) >bala>> > 3) Description of application in which this legacy equipment >bala>> > will use UNI >bala>> > signaling >bala>I don't recall seeing any response. furthermore, the NSAP >bala>requirement was not unanimously endorsed by all carriers (at >bala>the OIF). > >From our OIF representatives, although it was not unanimously endorsed, >there was a significant demand for NSAP support. Well, NSAP is the main >non-IP type of addressing that is required. The general requirement is >to be able to support non-IP addresses (probably have an address >translation from non-IP addresses to routable addresses). >NSAP support will be needed always (e.g. support for legacy DCC that >uses NSAP). So the timeframe requirement is now. Could you clarify the relationship between GMPLS and NSAP addresses ? You can run several protocol stacks in parallel over the same control channel. For instance, if your control channel is Ethernet, you can have an IP stack and any other kind of stack using any other kind of addresses. The two runs in parallel. The different stacks run in parallel in a "ship in the night" mode. The fact that you have for instance a TMN stack using NSAP addresses is completely orthogonal with a GMPLS stack. Speaking about my DCN: we have one DCN for both our transmission network and our IP network. The ADM's are managed using TMN only, DWDM equipment's are managed using SNMP and TMN, IP routers are managed using SNMP only. Everything uses the same DCN. For the TMN only equipment's we route CLNS using IS-IS and we don't use IP at all, it is pure OSI. For simplicity, we put MAC addresses (of the ADM Ethernet interfaces) into the NSAP addresses. You could put an IP address inside the NSAP address if you have a dual stack running on the box, that will even be simpler. For the DWDM equipment's we use SNMP and TMN. Each box has an IP address and I have to check what we do for the TMN stack. I think that it is transported over IP, maybe using RFC1006. If I remember correctly we only configure an IP address on the DWDM box. In that case, I presume that TSAP's are build using this IP address. For the IP routers that we want to manage we use SNMP (full IP stack), and it doesn't care about TMN and NSAP addresses. We use IS-IS and OSPF for the routing in the DCN. The small Cisco routers in the DCN forward and route both CLNS and IP. Indeed we use IS-IS in the dual mode for CLNS and IP. These DCN routers and their operations are independent of the nodes that we want to manage/control - of course. It works fine! Anyway, in a real DCN you will have new and old equipment's and you will need to support both. This is completely independent of the GMPLS stack. I could do VoIP using SIP (IP telephony signaling) over the DCN, do I have to use NSAP addresses in my VoIP stack because there is some TMN application that runs there as well ? No, of course. For instance, you run OSPF-TE between two new core ION backbone switches over an IP tunnel out-of-band using the DCN. GMPLS OSPF-TE packets and GMPLS RSVP-TE messages are encapsulated over IP and these IP packets are transported over the IP DCN using any kind of tunnelling scheme (IP in IP, GRE, etc). The "external" IP packets are routed using IS-IS in the DCN. The GMPLS OSPF-TE ignores the DCN IS-IS and vice-versa. So the GMPLS control plane runs completely independently of all the other stacks that are already running. Where is the issue ? Why do we need NSAP addresses in GMPLS ? Kind regards, Eric --openmail-part-4186299a-00000001-- From owner-mpls@UU.NET Wed Jun 13 17:16:26 2001 Received: from cmr0.ash.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 RAA01770 for ; Wed, 13 Jun 2001 17:16:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthc10584; Wed, 13 Jun 2001 21:14:22 GMT Received: by mail-control.mail.uu.net id QQkthc14399 for mpls-outgoing; Wed, 13 Jun 2001 21:13:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkthc14391 for ; Wed, 13 Jun 2001 21:13: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 QQkthc05002 for ; Wed, 13 Jun 2001 21:13:20 GMT Received: from ext1.ics.forth.gr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2]) id QQkthc06883 for ; Wed, 13 Jun 2001 21:13:19 GMT Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51]) by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id AAA23312; Thu, 14 Jun 2001 00:13:12 +0300 (EET DST) Received: from sappho.ics.forth.gr (sappho-lane.ics.forth.gr [139.91.157.50]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id AAA16379; Thu, 14 Jun 2001 00:13:16 +0300 (EET DST) Posted-Date: Thu, 14 Jun 2001 00:13:16 +0300 (EET DST) Organization: Received: from localhost (tziou@localhost) by sappho.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.2C-INTNULL) with ESMTP id AAA28631; Thu, 14 Jun 2001 00:13:16 +0300 (EEST) X-Authentication-Warning: sappho.ics.forth.gr: tziou owned process doing -bs Date: Thu, 14 Jun 2001 00:13:15 +0300 (EEST) From: Chrysostomos Tziouvaras To: mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: Problem with LEDA package In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a network of 107 nodes and about edges.I use max_flow() with input of type bigfloat. I use MAX_FLOW_SCALE_CAPS() before calling max_flow() in order to get the scaled values of capacity. The problem is that I cannot bound the error of max_flow() with respect to the scaled capacities. Regards Chrysostomos Tziouvaras ICS-FORTH Researcher From owner-mpls@UU.NET Wed Jun 13 17:19:57 2001 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 RAA01882 for ; Wed, 13 Jun 2001 17:19:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthd11324; Wed, 13 Jun 2001 21:17:17 GMT Received: by mail-control.mail.uu.net id QQkthc14421 for mpls-outgoing; Wed, 13 Jun 2001 21:14:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkthc14402 for ; Wed, 13 Jun 2001 21:13: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 QQkthc04859 for ; Wed, 13 Jun 2001 21:13:14 GMT Received: from mercury.polarisnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnai-216-15-8-227.cust.dnai.com [216.15.8.227]) id QQkthc09287 for ; Wed, 13 Jun 2001 21:13:13 GMT Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 13 Jun 2001 14:13:47 -0700 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 14:08:07 -0700 Message-ID: From: "Haim, Robert" To: lei.yao@wcom.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: What we do if the LSP is preempted Date: Wed, 13 Jun 2001 14:08:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F44C.F110B14E" 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_01C0F44C.F110B14E Content-Type: text/plain; charset="iso-8859-1" Lei, If an LSP is pre-empted the assumption is that its priority was lower than the one which replaced it. Attempting to reestablish the LSP would make sense if the Service Level Agreement with the customer warrants it. If it does, the network operator would have to make sure and reserve enough resources to accommodate its SLAs. Otherwise, for "best effort" traffic, you wouldn't re-establish the LSP. --robert -----Original Message----- From: Ashwinp@in.huawei.com [mailto:Ashwinp@in.huawei.com] Sent: Tuesday, June 12, 2001 7:45 AM To: lei.yao@wcom.com Cc: mpls-ops@mplsrc.com; mpls@UU.NET Subject: RE: What we do if the LSP is preempted Hello lei D____________________F / \ A---------------B---------------------C \_____E______/ Suppose i have a LSP ABEC of priority 3 And a LSP ADF with priority 4 Now i want to setup ABC with priority 2. As the resources are not available on link AB i will preempt LSP ABEC But there is a LSP ADF with priority 4 less than that of ABEC so if i preempt ABEC then won't it be fair to establish the LSP through ADFC and preempt ADF if enough resources are not available ? Thanks Ashwin -----Original Message----- From: Lei Yao [mailto:lei.yao@wcom.com] Sent: Tuesday, June 12, 2001 6:38 PM To: Ashwinp@in.huawei.com Subject: RE: What we do if the LSP is preempted A LSP is preempted because of the lack of network resource. In other words, there is network congestion. Therefore, you should not try to re-build the preempted LSP. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Ashwinp@in.huawei.com Sent: Tuesday, June 12, 2001 10:12 AM To: mpls-ops@mplsrc.com; mpls@UU.NET Subject: What we do if the LSP is preempted Dear all Can you please tell me what if the LSP is preempted ? Do we try to reestablish the LSP with some other path or we will just preempt it ? If we just preempt the LSP then it will be unfare with that LSP. And when should we try to reestablish that LSP ? Do anybody has any ionformation regarding this ? Thanks in advance Ashwin ------_=_NextPart_001_01C0F44C.F110B14E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What we do if the LSP is preempted

Lei,

 

=

If an LSP is pre-empted the assumption is that its priority was = lower than the one which replaced it. Attempting to reestablish the LSP would = make sense if the Service Level Agreement with the customer warrants it. If = it does, the network operator would have to make sure and reserve enough = resources to accommodate its SLAs. Otherwise, for “best effort” traffic, you = wouldn’t re-establish the LSP.

--robert

-----Original Message-----
From: = Ashwinp@in.huawei.com [mailto:Ashwinp@in.huawei.com]
Sent: Tuesday, June 12, = 2001 7:45 AM
To: lei.yao@wcom.com
Cc: mpls-ops@mplsrc.com; mpls@UU.NET
Subject: RE: What we do = if the LSP is preempted

 

 =

Hello = lei=

 =

  D____________________F

 / &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp; \=

A---------------= B---------------------C=

  &nbs= p;           &nbs= p;    \_____E______/

 =

Suppose i have = a LSP ABEC of priority 3

And a LSP ADF = with priority 4

 =

Now i want to = setup ABC with priority 2.

As the = resources are not available on link AB i will preempt LSP ABEC=

But there is a = LSP ADF with priority 4 less than that of ABEC so if i = preempt=

ABEC then won't = it be fair to establish the LSP through ADFC and preempt ADF = =

if enough = resources are not available ?

Thanks
Ashwin

 

-----Original Message-----
From: Lei Yao [mailto:lei.yao@wcom.com]
Sent: Tuesday, June 12, = 2001 6:38 PM
To: = Ashwinp@in.huawei.com
Subject: RE: What we do = if the LSP is preempted

A LSP is preempted because of the lack of = network resource. In other words, there is network congestion. Therefore, you = should not try to re-build the preempted = LSP.

 

=

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf = Of Ashwinp@in.huawei.com
Sent: Tuesday, June 12, = 2001 10:12 AM
To: mpls-ops@mplsrc.com; mpls@UU.NET
Subject: What we do if = the LSP is preempted

 =

 =

Dear = all =

 Can you = please tell me what if the LSP is preempted ? Do we try to reestablish the LSP =
 with some other path or we will = just preempt it ?
 If we just preempt the LSP then it = will be unfare with that LSP. And when should we try to
 reestablish that LSP = ? =

Do anybody has = any ionformation regarding this ?

Thanks in = advance
Ashwin

------_=_NextPart_001_01C0F44C.F110B14E-- From owner-mpls@UU.NET Wed Jun 13 17:52:57 2001 Received: from cmr1.ash.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 RAA02308 for ; Wed, 13 Jun 2001 17:52:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthf10136; Wed, 13 Jun 2001 21:50:43 GMT Received: by mail-control.mail.uu.net id QQkthf18461 for mpls-outgoing; Wed, 13 Jun 2001 21:50:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkthf18425 for ; Wed, 13 Jun 2001 21:49:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkthf24825 for ; Wed, 13 Jun 2001 21:48:44 GMT Received: from mercury.polarisnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnai-216-15-8-227.cust.dnai.com [216.15.8.227]) id QQkthf18972 for ; Wed, 13 Jun 2001 21:48:43 GMT Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 13 Jun 2001 14:49:16 -0700 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 14:43:35 -0700 Message-ID: From: "Haim, Robert" To: "'Rajeev Manur'" Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: What we do if the LSP is preempted Date: Wed, 13 Jun 2001 14:43:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F451.E59C4148" 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_01C0F451.E59C4148 Content-Type: text/plain; charset="iso-8859-1" IMHO, the answer is Yes. If you need to preempt an LSP to accommodate another flow of higher priority, then you will have to cannibalize any part of the currently established LSP that is in the way:-) --robert -----Original Message----- From: Rajeev Manur [mailto:rmanur@force10networks.com] Sent: Wednesday, June 13, 2001 2:43 PM To: 'Haim, Robert'; lei.yao@wcom.com Cc: mpls-ops@mplsrc.com; mpls@UU.NET Subject: RE: What we do if the LSP is preempted A related question. Pre-emption can be attempted on either ingress-LER or any other LSR hop wrt the LSP being setup. Also any hop that is attempting to preempt an LSP can preempt an LSP regardless of whether it is the ingress/core wrt to the LSP being pre-empted right ? with regards, Rajeev -----Original Message----- From: Haim, Robert [mailto:RHaim@PolarisNetworks.com] Sent: Wednesday, June 13, 2001 2:08 PM To: lei.yao@wcom.com Cc: mpls-ops@mplsrc.com; mpls@UU.NET Subject: RE: What we do if the LSP is preempted Lei, If an LSP is pre-empted the assumption is that its priority was lower than the one which replaced it. Attempting to reestablish the LSP would make sense if the Service Level Agreement with the customer warrants it. If it does, the network operator would have to make sure and reserve enough resources to accommodate its SLAs. Otherwise, for "best effort" traffic, you wouldn't re-establish the LSP. --robert -----Original Message----- From: Ashwinp@in.huawei.com [mailto:Ashwinp@in.huawei.com] Sent: Tuesday, June 12, 2001 7:45 AM To: lei.yao@wcom.com Cc: mpls-ops@mplsrc.com; mpls@UU.NET Subject: RE: What we do if the LSP is preempted Hello lei D____________________F / \ A---------------B---------------------C \_____E______/ Suppose i have a LSP ABEC of priority 3 And a LSP ADF with priority 4 Now i want to setup ABC with priority 2. As the resources are not available on link AB i will preempt LSP ABEC But there is a LSP ADF with priority 4 less than that of ABEC so if i preempt ABEC then won't it be fair to establish the LSP through ADFC and preempt ADF if enough resources are not available ? Thanks Ashwin -----Original Message----- From: Lei Yao [mailto:lei.yao@wcom.com] Sent: Tuesday, June 12, 2001 6:38 PM To: Ashwinp@in.huawei.com Subject: RE: What we do if the LSP is preempted A LSP is preempted because of the lack of network resource. In other words, there is network congestion. Therefore, you should not try to re-build the preempted LSP. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Ashwinp@in.huawei.com Sent: Tuesday, June 12, 2001 10:12 AM To: mpls-ops@mplsrc.com; mpls@UU.NET Subject: What we do if the LSP is preempted Dear all Can you please tell me what if the LSP is preempted ? Do we try to reestablish the LSP with some other path or we will just preempt it ? If we just preempt the LSP then it will be unfare with that LSP. And when should we try to reestablish that LSP ? Do anybody has any ionformation regarding this ? Thanks in advance Ashwin ------_=_NextPart_001_01C0F451.E59C4148 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What we do if the LSP is preempted

IMHO, the answer is Yes. If you need to preempt an LSP to = accommodate another flow of higher priority, then you will have to cannibalize any part of = the currently established LSP that is in the = way:-)

--robert

-----Original Message-----
From: Rajeev Manur [mailto:rmanur@force10networks.com]
Sent: Wednesday, June = 13, 2001 2:43 PM
To: 'Haim, Robert'; lei.yao@wcom.com
Cc: mpls-ops@mplsrc.com; mpls@UU.NET
Subject: RE: What we do = if the LSP is preempted

 

A related = question. Pre-emption can be attempted on either ingress-LER or any other = LSR hop wrt the LSP being setup. Also any hop that is attempting to = preempt an LSP can preempt an LSP regardless of whether it is the ingress/core wrt to = the LSP being pre-empted right ?

 =

with = regards,=

Rajeev=

-----Original Message-----
From: Haim, Robert [mailto:RHaim@PolarisNetworks.com]
Sent: Wednesday, June = 13, 2001 2:08 PM
To: lei.yao@wcom.com
Cc: mpls-ops@mplsrc.com; mpls@UU.NET
Subject: RE: What we do = if the LSP is preempted

Lei,

 

=

If an LSP is pre-empted the assumption is = that its priority was lower than the one which replaced it. Attempting to = reestablish the LSP would make sense if the Service Level Agreement with the = customer warrants it. If it does, the network operator would have to make sure = and reserve enough resources to accommodate its SLAs. Otherwise, for = “best effort” traffic, you wouldn’t re-establish the = LSP.

--robert

-----Original Message-----
From: = Ashwinp@in.huawei.com [mailto:Ashwinp@in.huawei.com]
Sent: Tuesday, June 12, = 2001 7:45 AM
To: lei.yao@wcom.com
Cc: mpls-ops@mplsrc.com; mpls@UU.NET
Subject: RE: What we do = if the LSP is preempted

 =

 =

Hello lei=

 =

  D____________________F

 / &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp; \=

A---------------= B---------------------C=

  &nbs= p;           &nbs= p;    \_____E______/

 =

Suppose i have a LSP ABEC of priority 3=

And a LSP ADF with priority 4

 =

Now i want to setup ABC with priority 2.=

As the resources are not available on link AB i will preempt LSP = ABEC=

But there is a LSP ADF with priority 4 less than that of ABEC so if i = preempt=

ABEC then won't it be fair to establish the LSP through ADFC and preempt ADF = =

if enough resources are not available ?=

Thanks
Ashwin

 

-----Original Message-----
From: Lei Yao [mailto:lei.yao@wcom.com]
Sent: Tuesday, June 12, = 2001 6:38 PM
To: = Ashwinp@in.huawei.com
Subject: RE: What we do = if the LSP is preempted

A LSP is preempted because of the lack of = network resource. In other words, there is network congestion. Therefore, you = should not try to re-build the preempted = LSP.

 

=

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf = Of Ashwinp@in.huawei.com
Sent: Tuesday, June 12, = 2001 10:12 AM
To: mpls-ops@mplsrc.com; mpls@UU.NET
Subject: What we do if = the LSP is preempted

 =

 =

Dear = all =

 Can you = please tell me what if the LSP is preempted ? Do we try to reestablish the LSP =
 with some other path or we will = just preempt it ?
 If we just preempt the LSP then it = will be unfare with that LSP. And when should we try to
 reestablish that LSP = ? =

Do anybody has = any ionformation regarding this ?

Thanks in = advance
Ashwin

------_=_NextPart_001_01C0F451.E59C4148-- From owner-mpls@UU.NET Wed Jun 13 18:42:36 2001 Received: from cmr0.ash.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 SAA02861 for ; Wed, 13 Jun 2001 18:42:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthi22733; Wed, 13 Jun 2001 22:42:32 GMT Received: by mail-control.mail.uu.net id QQkthi12817 for mpls-outgoing; Wed, 13 Jun 2001 22:42:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkthi12798 for ; Wed, 13 Jun 2001 22:41:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkthi08439 for ; Wed, 13 Jun 2001 22:41:30 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQkthi01922 for ; Wed, 13 Jun 2001 22:41:30 GMT Received: from cirwm3nt01.nor.bt.com by gandalf (local) with ESMTP; Wed, 13 Jun 2001 23:40:57 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 13 Jun 2001 23:41:11 +0100 Message-ID: To: jdrake@calient.net, Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 23:40:50 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi John, You observed 13 June 2001 16:20 > > Niel, > > I think that the point that Eric was trying to make is that > the IETF isn't > the correct venue > for a PNNI based solution, although a PNNI based solution might be a > perfectly fine thing. NH=> Many thanks for acknowledging this.......and as both a signalling expert and co-author of the PNNI specification your view should carry some weight. > > From a technical perspective, unless things have changed in > the past several > years, the issues > with using PNNI are its lack of support for > pre-emption/priority and make > before break, and that > its bandwidth advertisements are tightly coupled to ATM > service categories. NH=> But PNNI seems as though it can more easily adapted to the required job. It has certain features that make it quite attractive like: - mature/tested, already deployed and understood - proven carrier-strength - multiple interfaces already specified, ie UNI, E-NNI, I-NNI, AINI - separate link and signalling protocols, eg SSCOP keepalives separate from signalling, allows more physical interfaces not just connections per interface - supports crankback.....something now slated to be addded to RSVP/CR-LDP I assume? - supports static routed interfaces (AINI)....seems essential for inter-operator case; - support for address translation - supports S-PVC-type service - Logical Group Node concept provides powerful features, eg hides interior behaviour, allows centralised signalling and/or path computation, border nodes not burdened with higher layers, supports any topology, each peer group can have a different internal behaviour, etc; - good for phased migration (this is an importnat issue for operators); - centralised route computation may be better for OTNs.....this would be allowed; - separate signalling and routing means just signalling part can be used - etc It would, however, need some minor additional work to adapt it for SDH/OTN as you note......like BW advertisements. BTW- we have significant experience of trying to run multiple pre-emption schemes and found it not so useful. So this is one aspect we would want, and if it was present we would want to be able to turn it off. Regards, Neil From owner-mpls@UU.NET Wed Jun 13 18:43:35 2001 Received: from cmr0.ash.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 SAA02897 for ; Wed, 13 Jun 2001 18:43:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthi24364; Wed, 13 Jun 2001 22:43:42 GMT Received: by mail-control.mail.uu.net id QQkthi12823 for mpls-outgoing; Wed, 13 Jun 2001 22:42:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkthi12800 for ; Wed, 13 Jun 2001 22:41:48 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 QQkthi08458 for ; Wed, 13 Jun 2001 22:41:31 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQkthi21491 for ; Wed, 13 Jun 2001 22:41:31 GMT Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP; Wed, 13 Jun 2001 23:41:08 +0100 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 13 Jun 2001 23:41:11 +0100 Message-ID: To: Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 23:40:46 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric.....many thanks for your comments....couple of observations: > > If somebody wants to use PNNI, it is not our business. The > choice between a > GMPLS control plane and a PNNI control plane is not in our > scope. We are > here working on GMPLS at the IETF, not on PNNI at the ATM > Forum and not on > G.ASON at the ITU-T. NH=>We have to consider that the control-plane is composed of 3 principlly independent facets (ie addressing, signalling and routing) and it unfair to group them under a generic banner or forum heading. We really should be striving for best current practice here. > > GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with > NSAP addresses. > I don't think that somebody will choose a control plane only > because it uses > IP or NSAP addresses, this doesn't make sense to me. There > are much more > important distinctions between the two control planes than > the format of the > addresses. NH=> The addressing is almost an irrelevance......the addressing used can be anything provided it meets the requirements specified in the Freeland draft. Clearly we would re-use an existing addressing scheme, and v6 and NSAPs look good. v4 does not look so good. > > Technically I don't see arguments to adapt GMPLS to NSAP > addresses, or to > AppleTalk addresses or to any kind of addresses that some people could > prefer, or that could come from another standardization body. NH=> I don't want to do this either. > > If technically there is a clear benefit of using NSAP > addresses instead of > IP addresses in GMPLS that should be demonstrated by > somebody. Up to now > nobody made it (I think that when somebody wants to modify an > existing work > in a standardization body this has to be justified with > technical reasons, > not just by a personal preference). So I presume that there > is today no > technical argument to use NSAP addresses in GMPLS. NH=> Focusing on addressing here is a distraction......the attributes of an address that are required are that (i) it should be large enough for any possible growth, (ii) able to be properly structured to follow topology (for sensible hierarchical and aggregation reasons....so some 'wasted' space is not a bad thing) and (ii) that addresses are decoupled wrt cross-layer allocation (server layer trails = client layer links.....it can't be put more direct/obvious than that I think). > > Even if any benefit is demonstrated, that should be balanced with the > disadvantages of supporting it and finaly the IETF should > decide if they > want to adapt their protocols to other addressing schemes. > Personally, I > don't think that this make sense. NH=> I really think the addressing aspect is a bit of a distraction.......the key issues are all about the choice of signalling protocol and how the routing aspects are used. I cannot believe that a signalling protocol like RSVP whose orgins are from a Rx-controlled, multicast, IP, soft-state, etc environment is better fit than PNNI. This is not an attack of RSVP per se, it is all about re-using best available protocols for a given job. As Jon Crowcroft said at the NSIS BOF at the last mtg: "Don't fix signaling protocols via new requirements, but give a new direction in signaling requirements. PNNI specifications are excellently written, 3G handoff is excellent, Q.2931 is excellent. Don't start fixing RSVP until you have read all these protocols. We should not reinvent the wheel and waste the time of the IETF. [See ref: http://www.ietf.org/proceedings/01mar/index.html NSIS BOF] It is my opinion that all you will end up doing is re-inventing PNNI, eg recent crankback drafts. Sure you can do this but why waste the time of the IETF on this? > > Moreover, GMPLS is IP centric and this is one of its driving > forces. I don't > see the interest of transforming an IP centric control plane > in a less IP > centric control plane. This is going in the opposite > direction of what we > are trying to do. NH=> I don't really want to get into this area, so I will be as brief as possible....there is no IP in the SDH or OTN user-plane and, for us at least, the client and SDH/OTN networks must be decoupled. Sure you can force an IP oriented solution but that is by choice....it is certainly not forced by any technical or commercial necessity. Please also note that a significant (around 50% in some cases) of our SDH traffic demands actually come from 'native' managed BW customers.....so these are not even client networks (ie neither IP nor something else) that are under our management domain. These observations lead us to the conclusion that if a control-plane is to be introduced (and please note this is not a sure-fire certainty for SDH in any case for us....and I would urge operators to look at their billing, OSS and current operational practices before reaching any conclusions here) it should be chosen on best current practice principles. Further, we cannot see any good business case for SVCs in either SDH or OTNs....S-PVCs maybe. Has anyone really talked to operators about this....offering SVCs at SDH/OTN trail levels I mean? I would be amazed if valid business cases could be constructed......so if any operators out there know how to do this, we would be very keen to understand the arguments. So....observing that we are dealing with CO/cct-sw networks it would seem to make sense to us to use a signalling protocol that was designed to control such a fabric...and all I am saying here is that PNNI appears to be a better fit than RSVP (provided it is coupled with the right OSS/service environment, eg S-PVC like services 1st). regards, Neil From owner-mpls@UU.NET Wed Jun 13 18:45:27 2001 Received: from cmr1.ash.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 SAA02917 for ; Wed, 13 Jun 2001 18:45:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthj05908; Wed, 13 Jun 2001 22:45:16 GMT Received: by mail-control.mail.uu.net id QQkthi13041 for mpls-outgoing; Wed, 13 Jun 2001 22:44:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkthi12845 for ; Wed, 13 Jun 2001 22:42:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkthi07318 for ; Wed, 13 Jun 2001 22:41:45 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkthi11270 for ; Wed, 13 Jun 2001 22:41:44 GMT Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP; Wed, 13 Jun 2001 23:41:03 +0100 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 13 Jun 2001 23:41:02 +0100 Message-ID: To: L.Wood@eim.surrey.ac.uk, yakov@juniper.net Cc: mpls@UU.NET Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 23:40:52 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Good points Lloyd.....I have never seen a technical comparison of potential solutions.....let alone a statement of requirements from carriers against which to make this comparison (except the drafts from MCI/WCom and BT to the 12/00 mtg, which seem to have been ignored by some). regards, Neil > -----Original Message----- > From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] > Sent: 13 June 2001 17:51 > To: Yakov Rekhter > Cc: mpls@UU.NET > Subject: Re: GMPLS issues (was - GMPLS Last Calls) > > > On Wed, 13 Jun 2001, Yakov Rekhter wrote: > > > 1. Providing multiple choices for performing essentially the same > > thing, especially if these choices have similar characteristics, > > doesn't help to develop multi-vendor interoperable solutions. > > > > 2. The fact that in the IETF there are not one, but two link-state > > IGPs (OSPF and ISIS) is a bug, and not a feature. > > > > 3. The same applies for MPLS signalling (CR-LDP vs RSVP). > > Beg to differ. (and you mean RSVP-TE) > > The IETF insists on at least two interoperable implementations of > anything to consider it for a standard. This allows the standard to be > proven, and to have a concept of the underlying standard that is > separate to any single implementation, while allowing choice of > competing implementations. Each implementation can be evaluated on its > merits; this exerts pressure on the implementations, and allows > debugging and improvement of the implementations with respect to the > underlying standard. > > Similarly, going up a level of abstraction, having more than one > standard fulfil an implementation of a set of ideas increases > understanding of the underlying principles, independent of each > standard and its implementations, while allowing choice of competing > standards as expressed in their implementations. Each standard can be > evaluated on its merits; this exerts pressure on the standards, and > allows debugging and improvement of the standards with respect to the > underlying principles and algorithms. > > If it wasn't for ISIS, OSPF would really suck. and vice versa. > Competition is Good. > > L. > > and I see just having BGP as a problem. > > PGP > > > > > > From owner-mpls@UU.NET Wed Jun 13 18:46:35 2001 Received: from cmr1.ash.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 SAA02931 for ; Wed, 13 Jun 2001 18:46:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthj07661; Wed, 13 Jun 2001 22:46:33 GMT Received: by mail-control.mail.uu.net id QQkthi13059 for mpls-outgoing; Wed, 13 Jun 2001 22:44:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkthi12839 for ; Wed, 13 Jun 2001 22:42:21 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 QQkthi05936 for ; Wed, 13 Jun 2001 22:41:07 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQkthi10729 for ; Wed, 13 Jun 2001 22:41:07 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Wed, 13 Jun 2001 23:40:48 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 13 Jun 2001 23:40:51 +0100 Message-ID: To: yakov@juniper.net Cc: Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com, wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 23:40:51 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello Yakov..... > > Please note that there is a way to carry NSAPs in IPv6 addresses, > although it does not support all types of NSAPs. (see rfc1888 for > more details). Please also note that GMPLS supports IPv6 (as well > as IPv4). Finally, please note that a "perfect" solution (the one > that addresses all the requirements of everyone) is a *non* goal > for GMPLS. NH=> That is a fair point. Indeed, it is looking at a best fit from our perspective that is driving us......and I feel sure our position would be reflected by many large/established carriers. But you need to talk to the right people in those carriers to get the true view.......I suspect these people will not be tracking any of this discussion nor have looked at the issues in depth yet. > > > And, > > given this choice, that operator might also prefer to use > PNNI as the > > signalling/routing solution too. So, the issue seems not one of > > 'necesssity' but simply choice......though there may be > certain technical > > benefits of choosing 1 solution over another. I don't > believe there is > > anything technically wrong with saying this and giving > operators/vendors a > > choice here is there?.....if there is please point out the problems. > > Few points: > > 1. Providing multiple choices for performing essentially the same > thing, especially if these choices have similar characteristics, > doesn't help to develop multi-vendor interoperable solutions. NH=> Agreed. But who calls the shots here? > > 2. The fact that in the IETF there are not one, but two link-state > IGPs (OSPF and ISIS) is a bug, and not a feature. > > 3. The same applies for MPLS signalling (CR-LDP vs RSVP). > > 4. Suggesting yet another routing/signalling protocol, in addition > to GMPLS, is adding yet another bug (not a feature). NH=> Some bugs are better than others I guess. > > 5. I understand that BT submitted a contribution to the ITU > suggesting PNNI as (yet another) routing/signalling for optical > cross connects. NH=> Better bug? regards, Neil From owner-mpls@UU.NET Wed Jun 13 18:48:06 2001 Received: from cmr1.ash.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 SAA02961 for ; Wed, 13 Jun 2001 18:48:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthj09322; Wed, 13 Jun 2001 22:47:41 GMT Received: by mail-control.mail.uu.net id QQkthi13071 for mpls-outgoing; Wed, 13 Jun 2001 22:44:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkthi12840 for ; Wed, 13 Jun 2001 22:42:22 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 QQkthi06099 for ; Wed, 13 Jun 2001 22:41:14 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQkthi21104 for ; Wed, 13 Jun 2001 22:41:13 GMT Received: from chqlubnt02.lon.bt.com by gollum (local) with ESMTP; Wed, 13 Jun 2001 23:41:00 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 13 Jun 2001 23:40:48 +0100 Message-ID: To: jdrake@calient.net, Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 23:40:48 +0100 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi John.....You could do this, but I don't believe this is pertinent to what I was discussing. See my response to Eric. Regards, Neil > -----Original Message----- > From: John Drake [mailto:jdrake@calient.net] > Sent: 13 June 2001 15:59 > To: 'Mannie, Eric'; 'neil.2.harrison@bt.com'; > ananth.nagarajan@mail.sprint.com; BRaja@tellium.com > Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; > Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; > lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com > Subject: RE: GMPLS issues (was - GMPLS Last Calls) > > > Also, an ATM service using NSAP addresses for customer ports > could be built > on top of a GMPLS core using IP addresses internally. The ATM service > delivery switches could use the GMPLS core to provison > lighpaths between > themselves and then run > PNNI as an overlay network for purposes of exchanging NSAP > reachability > information. > > -----Original Message----- > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com] > Sent: Wednesday, June 13, 2001 7:33 AM > To: 'neil.2.harrison@bt.com'; ananth.nagarajan@mail.sprint.com; > BRaja@tellium.com > Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; > Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; > lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com > Subject: RE: GMPLS issues (was - GMPLS Last Calls) > > > Hello Neil, > > >Given that the layers have to be decoupled in the general case (for > >commercial as well as technical reasons - see the BT 'Freeland' > requirements > >draft to 12/00 mtg) then there seems to be no reason why an > operator could > >not use NSAPs for the access points of SDH or OTNs if he so > wished. And, > >given this choice, that operator might also prefer to use PNNI as the > >signalling/routing solution too. So, the issue seems not one of > >'necesssity' but simply choice......though there may be > certain technical > >benefits of choosing 1 solution over another. I don't > believe there is > >anything technically wrong with saying this and giving > operators/vendors a > >choice here is there?.....if there is please point out the problems. > > If somebody wants to use PNNI, it is not our business. The > choice between a > GMPLS control plane and a PNNI control plane is not in our > scope. We are > here working on GMPLS at the IETF, not on PNNI at the ATM > Forum and not on > G.ASON at the ITU-T. > > GMPLS comes with IPv4 and IPv6 addresses and PNNI comes with > NSAP addresses. > I don't think that somebody will choose a control plane only > because it uses > IP or NSAP addresses, this doesn't make sense to me. There > are much more > important distinctions between the two control planes than > the format of the > addresses. > > Technically I don't see arguments to adapt GMPLS to NSAP > addresses, or to > AppleTalk addresses or to any kind of addresses that some people could > prefer, or that could come from another standardization body. > > If technically there is a clear benefit of using NSAP > addresses instead of > IP addresses in GMPLS that should be demonstrated by > somebody. Up to now > nobody made it (I think that when somebody wants to modify an > existing work > in a standardization body this has to be justified with > technical reasons, > not just by a personal preference). So I presume that there > is today no > technical argument to use NSAP addresses in GMPLS. > > Even if any benefit is demonstrated, that should be balanced with the > disadvantages of supporting it and finaly the IETF should > decide if they > want to adapt their protocols to other addressing schemes. > Personally, I > don't think that this make sense. > > Moreover, GMPLS is IP centric and this is one of its driving > forces. I don't > see the interest of transforming an IP centric control plane > in a less IP > centric control plane. This is going in the opposite > direction of what we > are trying to do. > > Kind regards, > > Eric > > Eric Mannie > EBONE (GTS) > From owner-mpls@UU.NET Wed Jun 13 19:22:59 2001 Received: from cmr1.ash.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 TAA03338 for ; Wed, 13 Jun 2001 19:22:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthl18386; Wed, 13 Jun 2001 23:23:00 GMT Received: by mail-control.mail.uu.net id QQkthl06525 for mpls-outgoing; Wed, 13 Jun 2001 23:22:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkthl06520 for ; Wed, 13 Jun 2001 23:22:25 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 QQkthl19266 for ; Wed, 13 Jun 2001 23:21:36 GMT Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQkthl19762 for ; Wed, 13 Jun 2001 23:21:36 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id TAA11550 for ; Wed, 13 Jun 2001 19:17:47 -0400 (EDT) Subject: MAX rsvp-te message size To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Wed, 13 Jun 2001 19:17:37 -0400 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 06/13/2001 07:17:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can anyone tell me the max size of RSVP-TE message sent out? I saw cr-ldp spec, the max size for cr-ldp is 4096 bytes. Thanks in an advance. Julia From owner-mpls@UU.NET Wed Jun 13 20:16:40 2001 Received: from cmr1.ash.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 UAA03780 for ; Wed, 13 Jun 2001 20:16:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthp09030; Thu, 14 Jun 2001 00:16:35 GMT Received: by mail-control.mail.uu.net id QQktho00380 for mpls-outgoing; Thu, 14 Jun 2001 00:14:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktho00372 for ; Thu, 14 Jun 2001 00:14:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktho05442 for ; Thu, 14 Jun 2001 00:13:08 GMT Received: from zcars0m9.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQktho05873 for ; Thu, 14 Jun 2001 00:13:07 GMT Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5E0CtE23432 for ; Wed, 13 Jun 2001 20:12:55 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 13 Jun 2001 20:13:02 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 20:13:04 -0400 Message-ID: From: "Don Fedyk" To: neil.2.harrison@bt.com, Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 20:13:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F466.C699BEA0" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F466.C699BEA0 Content-Type: text/plain; charset="iso-8859-1" Neil You have made some pretty far reaching arguments. We also evaluated these schemes when we started GMPLS. It is my opinion we chose the route because we thought the IP-MPLS synergy in routing was strong. We run OSPF or IS-IS + BGP and we kill the overhead of having two routing systems with all the ills that go with it. There was also as John Drake mentioned more flexibility in adoption of capabilities. We tried once to put these in ATM and were shut down. Only after several years crank back solutions were introduced with still with some inflexible resistance. Next we looked at the signaling protocols and we fought hard to get flexibility and a connection oriented behavior. It is my opinion that CR-LDP was the best suited for this and we still use this model but we have conceded at present to talking to most of the routers with RSVP-TE. The signaling protocol is really not most of the work it is the flexibility we were striving for and with the exception of refresh the two protocols stay closely in synch. As far as addressing everyone seem to agree that we can add external addresses that have nothing to do with the core addressing so this is not about addressing. It is my opinion the best place to do this work has been the IETF over the last few years and here we use IP protocols. It has been the most responsive to the work to date. I don't see this suddenly changing and while you are right about it will look a lot like ATM when we get through that is because it is a connection oriented problem. Don ------_=_NextPart_001_01C0F466.C699BEA0 Content-Type: text/html; charset="iso-8859-1" RE: GMPLS issues (was - GMPLS Last Calls)

Neil

You have made some pretty far reaching arguments. We also evaluated
these schemes when we started GMPLS. It is my opinion we chose the
route because we thought the IP-MPLS synergy in routing was strong.
We run OSPF or IS-IS + BGP and we kill the overhead of having two
routing systems with all the ills that go with it. There was also
as John Drake mentioned more flexibility in adoption of capabilities.
We tried once to put these in ATM and were shut down. Only after
several years crank back solutions were introduced with still with
some inflexible resistance.

Next we looked at the signaling protocols and we fought hard to get
flexibility and a connection oriented behavior. It is my opinion that
CR-LDP was the best suited for this and we still use this model
but we have conceded at present to talking to most of the routers
with RSVP-TE. The signaling protocol is really not most of the
work it is the flexibility we were striving for and with the
exception of refresh the two protocols stay closely in synch.

As far as addressing everyone seem to agree that we can add
external addresses that have nothing to do with the core addressing
so this is not about addressing.

It is my opinion the best place to do this work has been the IETF
over the last few years and here we use IP protocols. It has been
the most responsive to the work to date. I don't see this suddenly
changing and while you are right about it will look a lot like ATM
when we get through that is because it is a connection oriented problem.

Don

------_=_NextPart_001_01C0F466.C699BEA0-- From owner-mpls@UU.NET Wed Jun 13 20:22:24 2001 Received: from cmr1.ash.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 UAA03829 for ; Wed, 13 Jun 2001 20:22:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkthp14812; Thu, 14 Jun 2001 00:21:57 GMT Received: by mail-control.mail.uu.net id QQkthp01176 for mpls-outgoing; Thu, 14 Jun 2001 00:21:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkthp01072 for ; Thu, 14 Jun 2001 00:21: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 QQkthp11433 for ; Thu, 14 Jun 2001 00:18:17 GMT Received: from radiant.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: radiant.calient.net [63.102.55.206]) id QQkthp07508 for ; Thu, 14 Jun 2001 00:18:17 GMT Received: by radiant.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 17:12:51 -0700 Message-ID: From: John Drake To: "'neil.2.harrison@bt.com'" , John Drake , Eric.Mannie@ebone.com, ananth.nagarajan@mail.sprint.com, BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com, ccamp@ops.ietf.org, Tammy.Ferris@mail.sprint.com, mark.jones@mail.sprint.com, mpls@UU.NET, lynn.neir@mail.sprint.com, andy.bd.reid@bt.com, alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Wed, 13 Jun 2001 17:12:50 -0700 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 in line -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Wednesday, June 13, 2001 3:41 PM To: jdrake@calient.net; Eric.Mannie@ebone.com; ananth.nagarajan@mail.sprint.com; BRaja@tellium.com Cc: wesam.alanqar@mail.sprint.com; ccamp@ops.ietf.org; Tammy.Ferris@mail.sprint.com; mark.jones@mail.sprint.com; mpls@UU.NET; lynn.neir@mail.sprint.com; andy.bd.reid@bt.com; alan.mcguire@bt.com Subject: RE: GMPLS issues (was - GMPLS Last Calls) Hi John, You observed 13 June 2001 16:20 > > Niel, > > I think that the point that Eric was trying to make is that > the IETF isn't > the correct venue > for a PNNI based solution, although a PNNI based solution might be a > perfectly fine thing. NH=> Many thanks for acknowledging this.......and as both a signalling expert and co-author of the PNNI specification your view should carry some weight. JD: Um, I was just trying to be nice. I don't have any idea of it could actually work, and it is, shall we say, a stabilized protocol. > > From a technical perspective, unless things have changed in > the past several > years, the issues > with using PNNI are its lack of support for > pre-emption/priority and make > before break, and that > its bandwidth advertisements are tightly coupled to ATM > service categories. NH=> But PNNI seems as though it can more easily adapted to the required job. JD: This sounds suspiciously like an assertion. It has certain features that make it quite attractive like: - mature/tested, already deployed and understood - proven carrier-strength JD: I think the whole point of GMPLS is that the same could be said of the IP suite of protocols. - multiple interfaces already specified, ie UNI, E-NNI, I-NNI, AINI JD: What are E-NNI and I-NNI? Also, at least when I looked at AINI, it had lots of problems with looping behavior and I don't know if they were fixed. - separate link and signalling protocols, eg SSCOP keepalives separate from signalling, allows more physical interfaces not just connections per interface JD: The same is provided by LMP wrt routing and signalling protocols, and link bundling provides better scalability wrt more physical interfaces than PNNI which doesn't have a similar concept. - supports crankback.....something now slated to be addded to RSVP/CR-LDP I assume? - supports static routed interfaces (AINI)....seems essential for inter-operator case; JD: GMPLS has this. - support for address translation JD: Not clear what you're referring to. - supports S-PVC-type service JD: GMPLS has this. - Logical Group Node concept provides powerful features, eg hides interior behaviour, allows centralised signalling and/or path computation, border nodes not burdened with higher layers, supports any topology, each peer group can have a different internal behaviour, etc; JD: I think you're referring to peer groups. In practice they were pretty nasty to configure properly, and I don't think they have all of the attributes you've given them. - good for phased migration (this is an importnat issue for operators); JD: Given that ATM, like IP, is a service, I don't see why there would be any reason to prefer PNNI over GMPLS. - centralised route computation may be better for OTNs.....this would be allowed; JD: PNNI doesn't have this intrinsically and GMPLS would support it just as easily. - separate signalling and routing means just signalling part can be used JD: I think that PNNI signalling and routing are much more tightly coupled than their GMPLS counterparts. Further, Eric Mannie designed in specific support in GMPLS for signalling only deployments. - etc It would, however, need some minor additional work to adapt it for SDH/OTN as you note......like BW advertisements. JD: It's only minor until you actually start to work out the details. BTW- we have significant experience of trying to run multiple pre-emption schemes and found it not so useful. So this is one aspect we would want, and if it was present we would want to be able to turn it off. JD: GMPLS has only a single pre-emption scheme. Regards, Neil From owner-mpls@UU.NET Wed Jun 13 21:13:38 2001 Received: from cmr0.ash.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 VAA04204 for ; Wed, 13 Jun 2001 21:13:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkths11125; Thu, 14 Jun 2001 01:13:15 GMT Received: by mail-control.mail.uu.net id QQkths24542 for mpls-outgoing; Thu, 14 Jun 2001 01:12:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkths24521 for ; Thu, 14 Jun 2001 01:12:22 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 QQkths05324 for ; Thu, 14 Jun 2001 01:12:06 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 QQkths07038 for ; Thu, 14 Jun 2001 01:12:05 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 VAA04622 for ; Wed, 13 Jun 2001 21:11:57 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA22390 for ; Wed, 13 Jun 2001 21:11:55 -0400 (EDT) Message-ID: <3B280F70.ABE6E90A@marconi.com> Date: Wed, 13 Jun 2001 21:12:16 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: MAX rsvp-te message size References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > Hi, > > Can anyone tell me the max size of RSVP-TE message sent out? > > I saw cr-ldp spec, the max size for cr-ldp is 4096 bytes. > > Thanks in an advance. The maximum size for most RSVP messges is the interface's MTU size, since an RSVP message must fit entirely into a single non-fragmented IP datagram. The one exception is a bundle message (one of the RSVP extensions in RFC 2961). Bundle messages may be as large as an IP datagram, since they may be fragmented. This means a maximum size of 64K. -- David From owner-mpls@UU.NET Wed Jun 13 21:26:21 2001 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 VAA04264 for ; Wed, 13 Jun 2001 21:26:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktht04645; Thu, 14 Jun 2001 01:25:04 GMT Received: by mail-control.mail.uu.net id QQktht25545 for mpls-outgoing; Thu, 14 Jun 2001 01:24:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktht25539 for ; Thu, 14 Jun 2001 01:24:26 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 QQktht25471 for ; Thu, 14 Jun 2001 01:24:18 GMT Received: from mason2.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQktht03855 for ; Thu, 14 Jun 2001 01:24:18 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id VAA15480; Wed, 13 Jun 2001 21:24:03 -0400 (EDT) Date: Wed, 13 Jun 2001 21:24:03 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: Hong Liao cc: mpls@UU.NET Subject: Re: MAX rsvp-te message size In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Julia, I think a single RSVP message may not exceed the maximum IP datagram size, approx. 64k bytes. -Rajiv On Wed, 13 Jun 2001, Hong Liao wrote: > Hi, > > Can anyone tell me the max size of RSVP-TE message sent out? > > I saw cr-ldp spec, the max size for cr-ldp is 4096 bytes. > > Thanks in an advance. > > Julia > > > From owner-mpls@UU.NET Thu Jun 14 00:01:58 2001 Received: from cmr0.ash.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 AAA07490 for ; Thu, 14 Jun 2001 00:01:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktie29041; Thu, 14 Jun 2001 04:01:52 GMT Received: by mail-control.mail.uu.net id QQktie21897 for mpls-outgoing; Thu, 14 Jun 2001 04:01:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktie21836 for ; Thu, 14 Jun 2001 04:01: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 QQktie27846 for ; Thu, 14 Jun 2001 04:00:23 GMT Received: from gateway.ipinfusion.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gt.ipinfusion.com [209.11.132.18] (may be forged)) id QQktie21967 for ; Thu, 14 Jun 2001 04:00:23 GMT Received: from ipinfusion.com (IDENT:root@[10.10.0.38]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id f5E3wJj14101 for ; Wed, 13 Jun 2001 20:58:20 -0700 Message-ID: <3B2837C1.2563FC69@ipinfusion.com> Date: Wed, 13 Jun 2001 21:04:17 -0700 From: Manoj Dutta X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Label Abort request !! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In RFC 3036, section A.1.3, LAbR.5 and LAbR.6 , why do we need to generate release message in response to an abort request message. Also, what label id we should use for this event (in the case where we have multiple mappings from next hop) thanks in advance manoj From owner-mpls@UU.NET Thu Jun 14 09:55:28 2001 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 JAA29463 for ; Thu, 14 Jun 2001 09:55:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktjr06002; Thu, 14 Jun 2001 13:51:56 GMT Received: by mail-control.mail.uu.net id QQktjr07067 for mpls-outgoing; Thu, 14 Jun 2001 13:51:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktjr07044 for ; Thu, 14 Jun 2001 13:50: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 QQktjr11668 for ; Thu, 14 Jun 2001 13:49:31 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQktjr18330 for ; Thu, 14 Jun 2001 13:49:31 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5EDnZU02334 for ; Thu, 14 Jun 2001 06:49:35 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA13565 for mpls@uu.net; Thu, 14 Jun 2001 09:49:29 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktji14594 for ; Thu, 14 Jun 2001 11:31:21 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 QQktji22187 for ; Thu, 14 Jun 2001 11:30:03 GMT Received: from mail.unina.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.unina.it [192.132.34.20]) id QQktji14387 for ; Thu, 14 Jun 2001 11:30:01 GMT Received: from corfu (corfu.grid.unina.it [143.225.229.151]) by mail.unina.it (8.9.3/8.9.3) with SMTP id NAA28697 for ; Thu, 14 Jun 2001 13:28:42 +0200 (MET DST) Message-ID: <001b01c0f4c5$fa179cc0$97e5e18f@comics.unina.it> From: "Roberto Canonico" To: Subject: Use of RSVP in MPLS Date: Thu, 14 Jun 2001 13:34:30 +0200 Organization: =?iso-8859-1?Q?Unicersit=E0_di_Napoli_=22Federico_II=22_-_DIS?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C0F4D6.BD896250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Messaggio in formato MIME composto da piy parti. ------=_NextPart_000_0018_01C0F4D6.BD896250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. After reading several documents and IDs related to RSVP-TE and its use in MPLS to setup new LSPs, it is clear that the setup process is initiated by the ingress LSR which sends an RSVP PATH message downstream to the egress LSR. Now my question are: - who instructed the ingress LSR to send the RESV message ? - would be it possible for the setup process to be initiated by a end system wishing to establish a new LSP through the MPLS network (a la IntServ) ? Thanks in advance for your clarifications. Regards, Roberto Canonico =20 ------=_NextPart_000_0018_01C0F4D6.BD896250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all.
After reading several documents = and
IDs related to RSVP-TE and its use in=20 MPLS
to setup new LSPs, it is clear = that the=20 setup
process is initiated by the=20 ingress LSR
which sends an RSVP PATH message=20 downstream
to the egress LSR.
Now my question are:
- who instructed the ingress LSR = to send=20 the
  RESV message ?
- would be it possible for the setup = process=20 to
be initiated by a end system wishing to = establish
a new LSP through the MPLS network (a = la IntServ)=20 ?
Thanks in advance for your=20 clarifications.
Regards,
    Roberto = Canonico
 
 
------=_NextPart_000_0018_01C0F4D6.BD896250-- From owner-mpls@UU.NET Thu Jun 14 10:02:44 2001 Received: from cmr1.ash.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 KAA29743 for ; Thu, 14 Jun 2001 10:02:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktjs28988; Thu, 14 Jun 2001 14:00:16 GMT Received: by mail-control.mail.uu.net id QQktjr07722 for mpls-outgoing; Thu, 14 Jun 2001 13:59:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktjr07701 for ; Thu, 14 Jun 2001 13:59:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQktjr28847 for ; Thu, 14 Jun 2001 13:59:07 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 QQktjr13223 for ; Thu, 14 Jun 2001 13:59:06 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 f5EDx6T96387 for ; Thu, 14 Jun 2001 09:59:06 -0400 (EDT) Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f5EDx6l40527 for ; Thu, 14 Jun 2001 09:59:06 -0400 (EDT) Received: from torrentnet.com (peroni.torrentnet.com [198.78.51.135]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id f5EDx6317145 for ; Thu, 14 Jun 2001 09:59:06 -0400 (EDT) Message-ID: <3B28C32A.786677C9@torrentnet.com> Date: Thu, 14 Jun 2001 09:59:06 -0400 From: Rajneesh Mahajan Organization: Ericsson IPI X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: is there any ILM MIB specification? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi I would appreciate it if someone can point me to some ILM MIB specification? I am unable to find it in MPLS charter website. -Rajneesh From owner-mpls@UU.NET Thu Jun 14 10:04:28 2001 Received: from cmr1.ash.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 KAA29825 for ; Thu, 14 Jun 2001 10:04:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktjs00172; Thu, 14 Jun 2001 14:01:16 GMT Received: by mail-control.mail.uu.net id QQktjs10404 for mpls-outgoing; Thu, 14 Jun 2001 14:00:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktjs10360 for ; Thu, 14 Jun 2001 14:00: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 QQktjr27264 for ; Thu, 14 Jun 2001 13:58:18 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQktjr26867 for ; Thu, 14 Jun 2001 13:58:17 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5EDwG912957 for ; Thu, 14 Jun 2001 06:58:16 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA13622 for mpls@uu.net; Thu, 14 Jun 2001 09:58:15 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkthe17245 for ; Wed, 13 Jun 2001 21:43:41 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 QQkthe15657 for ; Wed, 13 Jun 2001 21:43:12 GMT Received: from force10networks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQkthe12628 for ; Wed, 13 Jun 2001 21:43:07 GMT Received: from pc2101 by force10networks.com (8.8.8+Sun/ncore-main9-99) id OAA16206; Wed, 13 Jun 2001 14:42:39 -0700 (PDT) From: "Rajeev Manur" To: "'Haim, Robert'" , Cc: , Subject: RE: What we do if the LSP is preempted Date: Wed, 13 Jun 2001 14:42:43 -0700 Message-ID: <33207abc9eb1444a849e791bb178c1ba3b27de72@force10networks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f06a95a00a3d099b18d3567efebe0779" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --=_f06a95a00a3d099b18d3567efebe0779 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit A related question. Pre-emption can be attempted on either ingress-LER or any other LSR hop wrt the LSP being setup. Also any hop that is attempting to preempt an LSP can preempt an LSP regardless of whether it is the ingress/core wrt to the LSP being pre-empted right ? with regards, Rajeev -----Original Message----- From: Haim, Robert [mailto:RHaim@PolarisNetworks.com] Sent: Wednesday, June 13, 2001 2:08 PM To: lei.yao@wcom.com Cc: mpls-ops@mplsrc.com; mpls@UU.NET Subject: RE: What we do if the LSP is preempted Lei, If an LSP is pre-empted the assumption is that its priority was lower than the one which replaced it. Attempting to reestablish the LSP would make sense if the Service Level Agreement with the customer warrants it. If it does, the network operator would have to make sure and reserve enough resources to accommodate its SLAs. Otherwise, for “best effort” traffic, you wouldn’t re-establish the LSP. --robert -----Original Message----- From: Ashwinp@in.huawei.com [mailto:Ashwinp@in.huawei.com] Sent: Tuesday, June 12, 2001 7:45 AM To: lei.yao@wcom.com Cc: mpls-ops@mplsrc.com; mpls@UU.NET Subject: RE: What we do if the LSP is preempted Hello lei D____________________F / \ A---------------B---------------------C \_____E______/ Suppose i have a LSP ABEC of priority 3 And a LSP ADF with priority 4 Now i want to setup ABC with priority 2. As the resources are not available on link AB i will preempt LSP ABEC But there is a LSP ADF with priority 4 less than that of ABEC so if i preempt ABEC then won't it be fair to establish the LSP through ADFC and preempt ADF if enough resources are not available ? Thanks Ashwin -----Original Message----- From: Lei Yao [mailto:lei.yao@wcom.com] Sent: Tuesday, June 12, 2001 6:38 PM To: Ashwinp@in.huawei.com Subject: RE: What we do if the LSP is preempted A LSP is preempted because of the lack of network resource. In other words, there is network congestion. Therefore, you should not try to re-build the preempted LSP. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Ashwinp@in.huawei.com Sent: Tuesday, June 12, 2001 10:12 AM To: mpls-ops@mplsrc.com; mpls@UU.NET Subject: What we do if the LSP is preempted Dear all Can you please tell me what if the LSP is preempted ? Do we try to reestablish the LSP with some other path or we will just preempt it ? If we just preempt the LSP then it will be unfare with that LSP. And when should we try to reestablish that LSP ? Do anybody has any ionformation regarding this ? Thanks in advance Ashwin --=_f06a95a00a3d099b18d3567efebe0779 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What we do if the LSP is preempted
A=20 related question. Pre-emption can be attempted on either = ingress-LER or any=20 other LSR hop wrt the LSP being setup. Also any hop that is = attempting to=20 preempt an LSP can preempt an LSP regardless of whether it is the = ingress/core=20 wrt to the LSP being pre-empted right ?
 
with=20 regards,
Rajeev
-----Original Message-----
From: Haim, Robert=20 [mailto:RHaim@PolarisNetworks.com]
Sent: Wednesday, June 13, = 2001=20 2:08 PM
To: lei.yao@wcom.com
Cc: = mpls-ops@mplsrc.com;=20 mpls@UU.NET
Subject: RE: What we do if the LSP is=20 preempted

Lei,

 

If an=20 LSP is pre-empted the assumption is that its priority was lower than = the one=20 which replaced it. Attempting to reestablish the LSP would make sense = if the=20 Service Level Agreement with the customer warrants it. If it does, the = network=20 operator would have to make sure and reserve enough resources to = accommodate=20 its SLAs. Otherwise, for “best effort” traffic, you = wouldn’t re-establish the=20 LSP.

--robert

-----Original=20 Message-----
From:=20 Ashwinp@in.huawei.com [mailto:Ashwinp@in.huawei.com]
Sent: Tuesday, June 12, 2001 = 7:45=20 AM
To:=20 lei.yao@wcom.com
Cc:=20 mpls-ops@mplsrc.com; mpls@UU.NET
Subject: RE: What we do if the = LSP is=20 preempted

 

 

Hello=20 lei

 

 =20 D____________________F

 /          =             &= nbsp;           &n= bsp;   =20 \

A---------------B---------------------C

           &= nbsp;      =20 \_____E______/

 

Suppose=20 i have a LSP ABEC of priority 3

And a=20 LSP ADF with priority 4

 

Now i=20 want to setup ABC with priority 2.

As the=20 resources are not available on link AB i will preempt LSP=20 ABEC

But=20 there is a LSP ADF with priority 4 less than that of ABEC so if i = preempt

ABEC=20 then won't it be fair to establish the LSP through ADFC and preempt = ADF=20

if=20 enough resources are not available ?

Thanks
Ashwin

 

-----Original=20 Message-----
From: = Lei Yao=20 [mailto:lei.yao@wcom.com]
Sent: Tuesday, June 12, 2001 = 6:38=20 PM
To:=20 Ashwinp@in.huawei.com
Subject: RE: What we do if the = LSP is=20 preempted

A LSP=20 is preempted because of the lack of network resource. In other words, = there is=20 network congestion. Therefore, you should not try to re-build the = preempted=20 LSP.

 

-----Original=20 Message-----
From:=20 owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of=20 Ashwinp@in.huawei.com
Sent: Tuesday, June 12, 2001 = 10:12=20 AM
To: = mpls-ops@mplsrc.com;=20 mpls@UU.NET
Subject: What we=20 do if the LSP is preempted

 

 

Dear=20 all=20

 Can = you please=20 tell me what if the LSP is preempted ? Do we try to reestablish the = LSP=20
 with = some=20 other path or we will just preempt it ?
 If = we just=20 preempt the LSP then it will be unfare with that LSP. And when should = we try=20 to
 reestablish=20 that LSP ?=20

Do anybody = has any=20 ionformation regarding this ?

Thanks in=20 advance =
Ashwin

--=_f06a95a00a3d099b18d3567efebe0779-- From owner-mpls@UU.NET Thu Jun 14 10:10:31 2001 Received: from cmr0.ash.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 KAA00019 for ; Thu, 14 Jun 2001 10:10:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktjs11610; Thu, 14 Jun 2001 14:07:39 GMT Received: by mail-control.mail.uu.net id QQktjs26722 for mpls-outgoing; Thu, 14 Jun 2001 14:07:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktjs26527 for ; Thu, 14 Jun 2001 14:06: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 QQktjs11890 for ; Thu, 14 Jun 2001 14:06:09 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [203.199.51.142]) id QQktjs09768 for ; Thu, 14 Jun 2001 14:06:07 GMT Received: (qmail 10785 invoked from network); 14 Jun 2001 13:58:52 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 14 Jun 2001 13:58:52 -0000 Received: from brahmi.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id TAA13375; Thu, 14 Jun 2001 19:36:54 +0530 (IST) Received: from localhost (gabhijit@localhost) by brahmi.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id TAA23334; Thu, 14 Jun 2001 19:38:53 +0530 X-Authentication-Warning: brahmi.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Thu, 14 Jun 2001 19:38:53 +0530 (IST) From: Abhijit Gadgil To: Manoj Dutta cc: Subject: Re: Label Abort request !! In-Reply-To: <3B2837C1.2563FC69@ipinfusion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Manoj, the LAbR.5 and LAbR 6. Does not generate a label release message. It states, Generate Event : Received Label Release Message. which may in turn lead to generate the Label Release message. Also the point LAbR 5. will be reached if, a label request was received from the MessageSource to which LSR under consideration has not replied. (perhaps explicitely - for the request). and it has no outstanding request. So the Mapping for the FEC was received and sent or is in the queue to be sent. (either On Demand or Unsolicitedly). In this case since upstream guy is not willing to use label binding from the LSR under consideration, its most appropriate to generate label release event. About the second question - As a part of receiving Mapping/Request, LSR implementation will use stored information in determining which label to release.. Hope that helps.. -abhijit On Wed, 13 Jun 2001, Manoj Dutta wrote: >Hi, > >In RFC 3036, section A.1.3, LAbR.5 and LAbR.6 , why do we need to >generate release message in response >to an abort request message. Also, what label id we should use for this >event (in the case where we have >multiple mappings from next hop) > >thanks in advance >manoj > From owner-mpls@UU.NET Thu Jun 14 11:10:45 2001 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 LAA01823 for ; Thu, 14 Jun 2001 11:10:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktjw22483; Thu, 14 Jun 2001 15:08:11 GMT Received: by mail-control.mail.uu.net id QQktjw15230 for mpls-outgoing; Thu, 14 Jun 2001 15:07:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktjw15199 for ; Thu, 14 Jun 2001 15:07: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 QQktjw22818 for ; Thu, 14 Jun 2001 15:06:35 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktjw20873 for ; Thu, 14 Jun 2001 15:06:35 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 02B7994009; Thu, 14 Jun 2001 11:06:34 -0400 (EDT) Message-ID: <3B28D2FA.468E7311@sandburst.com> Date: Thu, 14 Jun 2001 11:06:34 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Manoj Dutta Cc: Abhijit Gadgil , mpls@UU.NET Subject: Re: Label Abort request !! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Manoj, Just to amplify on what Abhijit said: LAbR.1 and LAbR.2 deal with cases where no Label Request state is present - either because no request was previously received, or because a response has already been sent. LAbR.3 acknowledges the Label Request Abort message. LAbR.4 looks at the possibility that a Label Request may have been propagated downstream (as a result of the Label Request being aborted) and remains outstanding. If one has, LAbR.7, LAbR.8 and LAbR.9 make sure that that any unneeded Label Request downstream are cleared up, and LAbR.10 sets up state relative to any required propagation of the Label Request Abort message. LAbR.5 checks to see if a label mapping exists (possibly as a result of a downstream Label Request for which it has already received a response). If one does, LAbR.6 and procedures for Received Label Release Message make sure that any unneeded Label Mappings are released. To see why this makes sense, read Note 2 (as suggested by the existing text). LAbR.11 then deletes state relative to the Label Request being aborted - if any such state remains. -- Eric Gray Abhijit Gadgil wrote: > Manoj, > > the LAbR.5 and LAbR 6. Does not generate a label release message. It > states, > > Generate Event : Received Label Release Message. > > which may in turn lead to generate the Label Release message. > > Also the point LAbR 5. will be reached if, a label request was received > from the MessageSource to which LSR under consideration has not replied. > (perhaps explicitely - for the request). and it has no outstanding > request. So the Mapping for the FEC was received and sent or is in the > queue to be sent. (either On Demand or Unsolicitedly). In this case since > upstream guy is not willing to use label binding from the LSR under > consideration, its most appropriate to generate label release event. > > About the second question - As a part of receiving Mapping/Request, LSR > implementation will use stored information in determining which label to > release.. > > Hope that helps.. > > -abhijit > > On Wed, 13 Jun 2001, Manoj Dutta wrote: > > >Hi, > > > >In RFC 3036, section A.1.3, LAbR.5 and LAbR.6 , why do we need to > >generate release message in response > >to an abort request message. Also, what label id we should use for this > >event (in the case where we have > >multiple mappings from next hop) > > > >thanks in advance > >manoj > > From owner-mpls@UU.NET Thu Jun 14 11:31:02 2001 Received: from cmr0.ash.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 LAA02136 for ; Thu, 14 Jun 2001 11:31:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktjx05594; Thu, 14 Jun 2001 15:27:43 GMT Received: by mail-control.mail.uu.net id QQktjx26422 for mpls-outgoing; Thu, 14 Jun 2001 15:27:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktjx26371 for ; Thu, 14 Jun 2001 15:26:57 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 QQktjx18213 for ; Thu, 14 Jun 2001 15:26:08 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQktjx24098 for ; Thu, 14 Jun 2001 15:26:08 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5EFQ5K02893; Thu, 14 Jun 2001 11:26:05 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; THU, 14 Jun 2001 11:19:39 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 11:19:39 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E5659A1F7@newman.tenornet.com> From: "Arvind, K" To: "'David Charlap'" Cc: "'mpls@uu.net'" Subject: RE: MAX rsvp-te message size Date: Thu, 14 Jun 2001 11:19:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk David: >The maximum size for most RSVP messges is the interface's MTU size, >since an RSVP message must fit entirely into a single non-fragmented IP >datagram. According to RFC2205, Section 3.3: "In this version of the spec, each RSVP message must occupy exactly one IP datagram. If it exceeds the MTU, such a datagram will be fragmented by IP and reassembled at the recipient node. This has several consequences: o A single RSVP message may not exceed the maximum IP datagram size, approximately 64K bytes. o A congested non-RSVP cloud could lose individual message fragments, and any lost fragment will lose the entire message. Future versions of the protocol will provide solutions for these problems if they prove burdensome. " The paragraph quoted above doesn't seem to mandate that "an RSVP message must fit entirely into a single non-fragmented IP datagram"(I interpret "non-fragmented ip datagram" to mean one which is less than MTU) , though it does point out the potential practical consequences of fragmentation. I don't remember seeing any explicit prohibition of fragmentation in the RSVP-TE spec. Did I miss something? >The one exception is a bundle message (one of the RSVP extensions in RFC >2961). Bundle messages may be as large as an IP datagram, since they >may be fragmented. This means a maximum size of 64K. RFC2961 states explicitly that both Srefresh and Bundle messages may be IP fragmented, Regards, Arvind. > -----Original Message----- > From: David Charlap [SMTP:david.charlap@marconi.com] > Sent: Wednesday, June 13, 2001 9:12 PM > To: mpls@UU.NET > Subject: Re: MAX rsvp-te message size > > Hong Liao wrote: > > > > Hi, > > > > Can anyone tell me the max size of RSVP-TE message sent out? > > > > I saw cr-ldp spec, the max size for cr-ldp is 4096 bytes. > > > > Thanks in an advance. > > The maximum size for most RSVP messges is the interface's MTU size, > since an RSVP message must fit entirely into a single non-fragmented IP > datagram. > > The one exception is a bundle message (one of the RSVP extensions in RFC > 2961). Bundle messages may be as large as an IP datagram, since they > may be fragmented. This means a maximum size of 64K. > > -- David From owner-mpls@UU.NET Thu Jun 14 11:44:21 2001 Received: from cmr0.ash.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 LAA02563 for ; Thu, 14 Jun 2001 11:44:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktjy21170; Thu, 14 Jun 2001 15:41:46 GMT Received: by mail-control.mail.uu.net id QQktjy28016 for mpls-outgoing; Thu, 14 Jun 2001 15:40:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktjy28001 for ; Thu, 14 Jun 2001 15:40: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 QQktjy26334 for ; Thu, 14 Jun 2001 15:38:57 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQktjy17978 for ; Thu, 14 Jun 2001 15:38:56 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ52SYWG; Thu, 14 Jun 2001 21:22:10 +0530 Received: from MALLIKPC ([192.168.232.162]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z21BLC; Thu, 14 Jun 2001 21:06:51 +0530 From: "gopinathg" To: , Subject: selection of next hop in cr-ldp Date: Thu, 14 Jun 2001 21:16:47 +0530 Message-ID: <001501c0f4e9$39565390$a2e8a8c0@hclt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi I have a question regarding selection of next hop in cr-ldp....... From section 4.8.1 of draft-ietf-mpls-cr-ldp-05.txt step 1. is as follows Step 1 .-------------------------------------------------------------. If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop. ------- Do we need to proceed to step 2&3 if the above condition is satisfied or do we need to exit from algoritham ? If it proceeds thru step 2 & 3 the LSP may not pass through all the ER-Hop's. steps 2 ,3 are as follows 2. If there is no second ER-Hop, this indicates the end of the explicit route. The explicit route TLV should be removed from the Label Request Message. This node may or may not be the end of the LSP. Processing continues with section 4.8.2, where a new explicit route TLV may be added to the Label Request Message. 3. If the node is also a part of the abstract node described by the second ER-Hop, then the node deletes the first ER-Hop and continues processing with step 2, above. Note that this makes the second ER-Hop into the first ER-Hop of the next iteration. Thanks In Advance Gopinath.G.S HCL Technologies CHENNAI 600 006 http://www.hcltechnologies.com Ph work: +91-44-8291735/36/37 ext-629 Ph Res : +91-44-8292491 From owner-mpls@UU.NET Thu Jun 14 11:45:19 2001 Received: from cmr0.ash.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 LAA02589 for ; Thu, 14 Jun 2001 11:45:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktjy22881; Thu, 14 Jun 2001 15:43:05 GMT Received: by mail-control.mail.uu.net id QQktjy28087 for mpls-outgoing; Thu, 14 Jun 2001 15:41:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktjy27994 for ; Thu, 14 Jun 2001 15:40:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQktjy24882 for ; Thu, 14 Jun 2001 15:40:13 GMT From: francis.arts@alcatel.be Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQktjy25112 for ; Thu, 14 Jun 2001 15:40:13 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f5EFdtq11045; Thu, 14 Jun 2001 17:39:55 +0200 (MET DST) Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A6B.00560A68 ; Thu, 14 Jun 2001 17:39:47 +0200 X-Lotus-FromDomain: ALCATEL To: "Roberto Canonico" cc: mpls@UU.NET Message-ID: Date: Thu, 14 Jun 2001 17:39:43 +0200 Subject: Re: Use of RSVP in MPLS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=CGgFduP4WID5EYJR1UnSxNzzZXluBme5DMQs1WqaDQQgZxN8Vgw5F5TC" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=CGgFduP4WID5EYJR1UnSxNzzZXluBme5DMQs1WqaDQQgZxN8Vgw5F5TC Content-type: text/plain; charset=us-ascii Content-Disposition: inline See below. Francis. >> Now my question are: >> - who instructed the ingress LSR to send the >> RESV message ? The RESV message is not sent by the ingress LSR. Rather the RESV message is sent (hop-by-hop) from the egress LSR towards the ingress LSR. >> - would be it possible for the setup process to >> be initiated by a end system wishing to establish >> a new LSP through the MPLS network (a la IntServ) ? The protocol allows the setup to be initiated from an end system. However, the question is whether or not the service provider policy accepts LSP establishment requests from a host end system. "Roberto Canonico" on 14/06/2001 13:34:30 To: mpls@UU.NET cc: (bcc: Francis ARTS/BE/ALCATEL) Subject: Use of RSVP in MPLS Hi all. After reading several documents and IDs related to RSVP-TE and its use in MPLS to setup new LSPs, it is clear that the setup process is initiated by the ingress LSR which sends an RSVP PATH message downstream to the egress LSR. Now my question are: - who instructed the ingress LSR to send the RESV message ? - would be it possible for the setup process to be initiated by a end system wishing to establish a new LSP through the MPLS network (a la IntServ) ? Thanks in advance for your clarifications. Regards, Roberto Canonico --0__=CGgFduP4WID5EYJR1UnSxNzzZXluBme5DMQs1WqaDQQgZxN8Vgw5F5TC Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuNTAuNDUyMi4xODAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5I aSBhbGwuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BZnRlciBy ZWFkaW5nIHNldmVyYWwgZG9jdW1lbnRzIGFuZDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+SURzIHJlbGF0ZWQgdG8gUlNWUC1URSBhbmQgaXRzIHVzZSBpbiANCk1Q TFM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPnRvIHNldHVwIG5l dyBMU1BzLCZuYnNwO2l0IGlzIGNsZWFyIHRoYXQgdGhlIA0Kc2V0dXA8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPnByb2Nlc3MgaXMgaW5pdGlhdGVkIGJ5IHRoZSAN CmluZ3Jlc3MmbmJzcDtMU1I8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPndoaWNoIHNlbmRzIGFuIFJTVlAgUEFUSCBtZXNzYWdlIA0KZG93bnN0cmVhbTwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+dG8gdGhlIGVncmVzcyBMU1IuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Ob3cgbXkgcXVlc3Rpb24g YXJlOjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+LSB3aG8gaW5z dHJ1Y3RlZCB0aGUmbmJzcDtpbmdyZXNzIExTUiB0byBzZW5kIA0KdGhlPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mbmJzcDsgUkVTViBtZXNzYWdlID88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPi0gd291bGQgYmUgaXQgcG9zc2li bGUgZm9yIHRoZSBzZXR1cCBwcm9jZXNzIA0KdG88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPmJlIGluaXRpYXRlZCBieSBhIGVuZCBzeXN0ZW0gd2lzaGluZyB0byAN CmVzdGFibGlzaDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+YSBu ZXcgTFNQIHRocm91Z2ggdGhlIE1QTFMgbmV0d29yayAoYSBsYSBJbnRTZXJ2KSANCj88L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRoYW5rcyBpbiBhZHZhbmNlIGZv ciB5b3VyIA0KY2xhcmlmaWNhdGlvbnMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj5SZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvYmVydG8gQ2Fub25pY288L0ZPTlQ+PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K --0__=CGgFduP4WID5EYJR1UnSxNzzZXluBme5DMQs1WqaDQQgZxN8Vgw5F5TC-- From owner-mpls@UU.NET Thu Jun 14 12:13:06 2001 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 MAA03216 for ; Thu, 14 Jun 2001 12:13:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktka23326; Thu, 14 Jun 2001 16:09:10 GMT Received: by mail-control.mail.uu.net id QQktka09580 for mpls-outgoing; Thu, 14 Jun 2001 16:08:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktka09030 for ; Thu, 14 Jun 2001 16:08:19 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 QQktka11108 for ; Thu, 14 Jun 2001 16:05:06 GMT Received: from mail.unina.it by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.unina.it [192.132.34.20]) id QQktka03233 for ; Thu, 14 Jun 2001 16:05:05 GMT Received: from corfu (corfu.grid.unina.it [143.225.229.151]) by mail.unina.it (8.9.3/8.9.3) with SMTP id SAA31740; Thu, 14 Jun 2001 18:03:34 +0200 (MET DST) Message-ID: <012401c0f4ec$60bc8280$97e5e18f@comics.unina.it> From: "Roberto Canonico" To: Cc: References: Subject: Use of RSVP in MPLS (2) Date: Thu, 14 Jun 2001 18:09:23 +0200 Organization: =?iso-8859-1?Q?Unicersit=E0_di_Napoli_=22Federico_II=22_-_DIS?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Francis, thanks for your reply. A few more questions for all ... > The protocol allows the setup to be initiated from an end system. > However, the question is whether or not the service provider policy accepts LSP establishment requests from a host end system. Q1 - Has such a scenario any chance to be implemented in "real" MPLS networks ? Q2 - I remember in RSVP for IntServ, the resource reservation process was originated by a request issued by an application through a special API. In the case of RSVP-TE, what is the event that triggers this signalling phase ? In different words, what entities are in charge of deciding if a new LSP is to be created in an MPLS network ? Thanks again for your attention. Regards, Roberto Canonico "Roberto Canonico" on 14/06/2001 13:34:30 To: mpls@UU.NET cc: (bcc: Francis ARTS/BE/ALCATEL) Subject: Use of RSVP in MPLS Hi all. After reading several documents and IDs related to RSVP-TE and its use in MPLS to setup new LSPs, it is clear that the setup process is initiated by the ingress LSR which sends an RSVP PATH message downstream to the egress LSR. Now my question are: - who instructed the ingress LSR to send the RESV message ? - would be it possible for the setup process to be initiated by a end system wishing to establish a new LSP through the MPLS network (a la IntServ) ? Thanks in advance for your clarifications. Regards, Roberto Canonico From owner-mpls@UU.NET Thu Jun 14 12:25:11 2001 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 MAA03460 for ; Thu, 14 Jun 2001 12:25:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktkb07665; Thu, 14 Jun 2001 16:23:05 GMT Received: by mail-control.mail.uu.net id QQktkb22951 for mpls-outgoing; Thu, 14 Jun 2001 16:22:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktkb22919 for ; Thu, 14 Jun 2001 16:22:14 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 QQktkb00345 for ; Thu, 14 Jun 2001 16:20:36 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQktkb03333 for ; Thu, 14 Jun 2001 16:20:35 GMT Received: by SANMIGUEL with Internet Mail Service (5.5.2448.0) id ; Thu, 14 Jun 2001 18:18:29 +0200 Message-ID: From: Javier Antich To: Roberto Canonico , francis.arts@alcatel.be Cc: mpls@UU.NET Subject: RE: Use of RSVP in MPLS (2) Date: Thu, 14 Jun 2001 18:18:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03460 Hi Traffic Engineered tunels are expected to be innitiated/terminated in routers as a result of a traffic engineered path calculation (either by the administrator, by a network simulation tool, or by constraint-based routing). As a result, currently is the administrator, by configuration, who triggers the establishment of TE-LSPs, not the end applications. TE tunnels are something that end application are not aware today, probably also because a TE tunnel does not give the application any resources reservation, unless you implement some other features like CAR, WRR, WFQ, .... TE currently is useful for network administrators to have a better utilization of the network resources, rather than for applications asking for QoS like in "traditional" RSVP. ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Roberto Canonico [SMTP:roberto.canonico@unina.it] > Enviado el: jueves 14 de junio de 2001 18:09 > Para: francis.arts@alcatel.be > CC: mpls@UU.NET > Asunto: Use of RSVP in MPLS (2) > > Francis, thanks for your reply. > A few more questions for all ... > > > The protocol allows the setup to be initiated from an end system. > > However, the question is whether or not the service provider policy > accepts LSP establishment requests from a host end system. > > Q1 - Has such a scenario any chance to be implemented in "real" MPLS > networks ? > > Q2 - I remember in RSVP for IntServ, the resource > reservation process was originated by a request > issued by an application through a special API. > In the case of RSVP-TE, what is the event that triggers > this signalling phase ? > In different words, what entities are in charge of > deciding if a new LSP is to be created in an MPLS network ? > > Thanks again for your attention. > Regards, > Roberto Canonico > > > > > > > > > > > > > > > > > > "Roberto Canonico" on 14/06/2001 13:34:30 > > > > To: mpls@UU.NET > > cc: (bcc: Francis ARTS/BE/ALCATEL) > > > > Subject: Use of RSVP in MPLS > > > > > > > Hi all. > After reading several documents and > IDs related to RSVP-TE and its use in MPLS > to setup new LSPs, it is clear that the setup > process is initiated by the ingress LSR > which sends an RSVP PATH message downstream > to the egress LSR. > Now my question are: > - who instructed the ingress LSR to send the > RESV message ? > - would be it possible for the setup process to > be initiated by a end system wishing to establish > a new LSP through the MPLS network (a la IntServ) ? > Thanks in advance for your clarifications. > Regards, > Roberto Canonico From owner-mpls@UU.NET Thu Jun 14 13:14:19 2001 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 NAA04435 for ; Thu, 14 Jun 2001 13:14:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktke27683; Thu, 14 Jun 2001 17:12:47 GMT Received: by mail-control.mail.uu.net id QQktke16996 for mpls-outgoing; Thu, 14 Jun 2001 17:12:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktke16986 for ; Thu, 14 Jun 2001 17:12:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQktke29316 for ; Thu, 14 Jun 2001 17:10:23 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktke25256 for ; Thu, 14 Jun 2001 17:10:23 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id C053E94009; Thu, 14 Jun 2001 13:10:22 -0400 (EDT) Message-ID: <3B28EFFE.FD2B69F2@sandburst.com> Date: Thu, 14 Jun 2001 13:10:22 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: gopinathg Cc: mpls@UU.NET Subject: Re: selection of next hop in cr-ldp References: <001501c0f4e9$39565390$a2e8a8c0@hclt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gopinath, These steps do not precisely constitute a 'procedure'. The intent of the steps is defined by the lead-in statement - "To determine the next hop for the path, a node performs the following steps" ... If - as stated - the steps are intended to produce a next hop for the path, then the process is complete when a next hop is determined. I do not believe - since this is not strictly a procedure - that there is a needs for an explicit 'exit' statement. Hopefully this helps... -- Eric Gray You wrote: > Hi > > I have a question regarding selection of next hop in cr-ldp....... > > From section 4.8.1 of draft-ietf-mpls-cr-ldp-05.txt step 1. is as > follows > > Step 1 > .-------------------------------------------------------------. If > the L bit is set > and the local node is not part of the abstract node described by > the first ER-Hop, the node selects a next hop that is along the > path to the abstract node described by the first ER-Hop. ------- > > Do we need to proceed to step 2&3 if the above condition is satisfied or > do we need to > exit from algoritham ? > > If it proceeds thru step 2 & 3 the LSP may not pass through all the > ER-Hop's. > > steps 2 ,3 are as follows > > 2. If there is no second ER-Hop, this indicates the end of the > explicit route. The explicit route TLV should be removed from the > Label Request Message. This node may or may not be the end of > the LSP. Processing continues with section 4.8.2, where a new > explicit route TLV may be added to the Label Request Message. > > 3. If the node is also a part of the abstract node described by > the second ER-Hop, then the node deletes the first ER-Hop and > continues processing with step 2, above. Note that this makes > the second ER-Hop into the first ER-Hop of the next iteration. > > Thanks In Advance > > Gopinath.G.S > HCL Technologies > CHENNAI 600 006 > > http://www.hcltechnologies.com > Ph work: +91-44-8291735/36/37 ext-629 > Ph Res : +91-44-8292491 From owner-mpls@UU.NET Thu Jun 14 22:35:40 2001 Received: from cmr0.ash.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 WAA14850 for ; Thu, 14 Jun 2001 22:35:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktlq13242; Fri, 15 Jun 2001 02:34:01 GMT Received: by mail-control.mail.uu.net id QQktlq12717 for mpls-outgoing; Fri, 15 Jun 2001 02:33:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktlq12703 for ; Fri, 15 Jun 2001 02:33:14 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 QQktlq17709 for ; Fri, 15 Jun 2001 02:31:30 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQktlq13021 for ; Fri, 15 Jun 2001 02:31:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5F2VXU11648 for ; Thu, 14 Jun 2001 19:31:33 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id WAA15646 for mpls@uu.net; Thu, 14 Jun 2001 22:31:28 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktkx04188 for ; Thu, 14 Jun 2001 21:46:10 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 QQktkx29727 for ; Thu, 14 Jun 2001 21:45:55 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQktkx03437 for ; Thu, 14 Jun 2001 21:45:54 GMT Received: from kishan (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11]) by acc.com (8.11.1/8.11.1) with SMTP id f5ELh8l21584 for ; Thu, 14 Jun 2001 14:43:08 -0700 (PDT) Reply-To: From: "Hari Kishan" To: Subject: Q on non-mpls connection?? Date: Thu, 14 Jun 2001 14:42:08 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3B280F70.ABE6E90A@marconi.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Why is it a MUST to use LLC/SNAP encapsulation for non-mpls connection between two LDP peers connected via an LC-ATM interface?? what kind of problems does the LDP peers may run into if the non-mpls connection uses NULL encapsulations?? thanks, Kishan --------------------------------- Hari Kishan Desineni, Ericsson Inc, Data Backbone & Optical Division, Santabarbara, California - 93117 Office:(805) 562 6419 Home:(805) 968 1894 From owner-mpls@UU.NET Thu Jun 14 22:36:43 2001 Received: from cmr0.ash.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 WAA14869 for ; Thu, 14 Jun 2001 22:36:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktlq14614; Fri, 15 Jun 2001 02:35:07 GMT Received: by mail-control.mail.uu.net id QQktlq12726 for mpls-outgoing; Fri, 15 Jun 2001 02:33:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktlq12701 for ; Fri, 15 Jun 2001 02:33:12 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 QQktlq27462 for ; Fri, 15 Jun 2001 02:31:17 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQktlq12815 for ; Fri, 15 Jun 2001 02:31:16 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5F2VF908674 for ; Thu, 14 Jun 2001 19:31:15 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id WAA15634 for mpls@uu.net; Thu, 14 Jun 2001 22:31:14 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktkr04448 for ; Thu, 14 Jun 2001 20:15:04 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 QQktkq00447 for ; Thu, 14 Jun 2001 20:13:43 GMT Received: from math.uwaterloo.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: math.uwaterloo.ca [129.97.140.144]) id QQktkq13936 for ; Thu, 14 Jun 2001 20:13:42 GMT Received: from fe01.math.uwaterloo.ca (wwszeto@fe01.math.uwaterloo.ca [129.97.166.111]) by math.uwaterloo.ca (8.8.8/8.8.8) with ESMTP id QAA20356 for ; Thu, 14 Jun 2001 16:13:34 -0400 (EDT) Received: from localhost (wwszeto@localhost) by fe01.math.uwaterloo.ca (8.9.3/8.9.3) with ESMTP id QAA20363 for ; Thu, 14 Jun 2001 16:13:34 -0400 (EDT) X-Authentication-Warning: fe01.math: wwszeto owned process doing -bs Date: Thu, 14 Jun 2001 16:13:34 -0400 (EDT) From: "Wayne W. Szeto" To: mpls@UU.NET Subject: constraint-based routing algorithms Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have been looking at constraint-based routing algorithms for a while and the ones that I encountered are all based on minimum interference routing algorithm (mira), including s-mira, l-mira, lbu (link based utilization qos routing algorithm), and profile-based routing. I would like to know the trend for routing algorithms in MPLS networks. Are MPLS networks deployed today or in the near future going to use the simplest routing algorithm (i.e. minimum-hop)? Is there any MPLS networks using mira? or is there some other more popular algorithms that I'm missing? Thanks for any help. From owner-mpls@UU.NET Fri Jun 15 05:59:15 2001 Received: from cmr0.ash.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 FAA02372 for ; Fri, 15 Jun 2001 05:59:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktmt02387; Fri, 15 Jun 2001 09:58:58 GMT Received: by mail-control.mail.uu.net id QQktmt17222 for mpls-outgoing; Fri, 15 Jun 2001 09:58:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktmt17208 for ; Fri, 15 Jun 2001 09:58:13 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 QQktmt05359 for ; Fri, 15 Jun 2001 09:56:21 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [203.199.51.142]) id QQktmt29827 for ; Fri, 15 Jun 2001 09:56:20 GMT Received: (qmail 19070 invoked from network); 15 Jun 2001 09:49:06 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 15 Jun 2001 09:49:06 -0000 Received: from vani.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id PAA05855 for ; Fri, 15 Jun 2001 15:27:06 +0530 (IST) Received: from localhost (gabhijit@localhost) by vani.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id PAA28349 for ; Fri, 15 Jun 2001 15:28:22 +0530 X-Authentication-Warning: vani.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Fri, 15 Jun 2001 15:28:22 +0530 (IST) From: Abhijit Gadgil To: Subject: LMp. 17 in rfc3036. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, perhaps it's pointed out before, but inclusion of MsgSource in the loop of LMp. 17 seems somewhat problematic. Consider Ru - Upstream guy (DU ordered, Loop Detection = Yes) Rd - Downstream guy (DU ordered, Loop Detection = Yes) F - FEC in question. Assume Rd is not egress for the FEC, then according to section 2.8.2, Rd will send Path Vector to Ru. If Rd sends mapping for fec F to Ru. and as a part of loop of LMp. 17 Now at Ru according to LMp. 18 - LMp.21 LMp. 18 - No LMp. 19 - Yes LMP. 20 - (PV = (LSRid Ru, LSRid Rd), Hop Count = 0) LMp. 21 - send message to Rd. Now when Rd receives this message, it will detect a loop according to Check_Received_Attributes, it will NAK the message, with Loop Detected. So the purpose of sending the message is lost (Even with Liberal Retention at Rd). not inclusion of Rd in LMp. 17 is perhaps, problematic if Rd is of the type RequestNever.(Which is likely in DU) and Then Rd may never get mapping from Ru if Ru becomes nexthop for the same FEC sometime. But then in that case. Upon receiving Mapping from new next hop Rd1 (below), Ru will propagate it to Rd (As a part of LMp. 17 loop again).which won't be NAKed then. Initially -----------> Ru ------------ Rd | | | Rd1 Later (perhaps) <---------- Ru ------------ Rd | | | | | v Rd1 This may not be problematic if Loop Detection is not enabled and Rd does not send Path Vector in Mapping to Ru. Of course this is not harmful as far as the normal operation goes. It's only unnecessary. Am I missing something? thanks and regards -abhijit From owner-mpls@UU.NET Fri Jun 15 07:14:43 2001 Received: from cmr0.ash.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 HAA03119 for ; Fri, 15 Jun 2001 07:14:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktmy11239; Fri, 15 Jun 2001 11:14:12 GMT Received: by mail-control.mail.uu.net id QQktmy04533 for mpls-outgoing; Fri, 15 Jun 2001 11:13:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktmy04484 for ; Fri, 15 Jun 2001 11:13:13 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 QQktmy01003 for ; Fri, 15 Jun 2001 11:12:12 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQktmy09413 for ; Fri, 15 Jun 2001 11:12:11 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 15 Jun 2001 16:48:56 +0530 Received: from sailendram (sailendram.future.futsoft.com [10.8.7.27]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f5FBAwO01802 for ; Fri, 15 Jun 2001 16:40:58 +0530 Reply-To: From: "sailendra mahanty" To: "mpls Mailing list (E-mail)" Subject: Label Value for Withdrawn routes in Update message Date: Fri, 15 Jun 2001 16:13:57 +0530 Message-Id: <008001c0f588$15085980$1b07080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, This is regarding Carrying Label Information in BGP. If this is not appropriate list for discussing RFC3107 please let me know the proper mailing list. Here are the questions i have. Section 3 of RFC3107 says, The label information carried (as part of NLRI) in the withdrawn Routes field should be set to 0x800000. A. What is the significance of this value, i don't think this value is used at the time of deletion. To me it looks like 8 in 0x80000 represents the Bottom Of Stack field ( in the older version of draft BOS stored in High order bit of 3 octets field, but it's changed in RFC) B. In case of multiple routes ( multiple labels) advertising, if one wants to remove all the labels, is it OK to use 0x800000 as the value of the label ? Regards, -sailendra. From owner-mpls@UU.NET Fri Jun 15 09:30:27 2001 Received: from cmr0.ash.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 JAA07485 for ; Fri, 15 Jun 2001 09:30:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktni21789; Fri, 15 Jun 2001 13:30:22 GMT Received: by mail-control.mail.uu.net id QQktnh27092 for mpls-outgoing; Fri, 15 Jun 2001 13:29:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktnh27081 for ; Fri, 15 Jun 2001 13:29:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktnh09152 for ; Fri, 15 Jun 2001 13:26:43 GMT Received: from web14708.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14708.mail.yahoo.com [216.136.224.125]) id QQktnh06462 for ; Fri, 15 Jun 2001 13:26:43 GMT Message-ID: <20010615132642.1251.qmail@web14708.mail.yahoo.com> Received: from [63.160.25.178] by web14708.mail.yahoo.com; Fri, 15 Jun 2001 06:26:42 PDT Date: Fri, 15 Jun 2001 06:26:42 -0700 (PDT) From: Pratik Shah Subject: MIBs for Static FEC Configuration To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi all, Is there a standard MIB Object for configuring an FEC for a static LSP. For e.g. if the administrator wants to 'statically' configure different LSPs corresponding to different FECs for the same outgoing interface ... how does that happen ?? thanks, Pratik __________________________________________________ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ From owner-mpls@UU.NET Fri Jun 15 09:32:13 2001 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 JAA07580 for ; Fri, 15 Jun 2001 09:32:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktni01044; Fri, 15 Jun 2001 13:31:29 GMT Received: by mail-control.mail.uu.net id QQktni27141 for mpls-outgoing; Fri, 15 Jun 2001 13:30:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktnh27096 for ; Fri, 15 Jun 2001 13:29:48 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 QQktnh18909 for ; Fri, 15 Jun 2001 13:28:24 GMT Received: from mel.alcatel.fr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mel.alcatel.fr [212.208.74.132]) id QQktnh27669 for ; Fri, 15 Jun 2001 13:28:24 GMT Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA18145; Fri, 15 Jun 2001 14:05:37 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA21514; Fri, 15 Jun 2001 15:27:37 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA13676; Fri, 15 Jun 2001 15:27:38 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.248.220]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA24003; Fri, 15 Jun 2001 15:27:43 +0200 (MET DST) Message-ID: <3B2A0D68.E5EFB093@ms.alcatel.fr> Date: Fri, 15 Jun 2001 15:28:09 +0200 From: Victorianus Kapuangan X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: gopinathg CC: mpls@UU.NET Subject: Re: Modification of Traffic Resources References: <001201c0f02d$e5855910$a2e8a8c0@hclt.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit hi, Please try draft-ietf-mpls-crlsp-modify-03.txt. It might help ... :-) regards, -victor- gopinathg a écrit : > Hello all > > How to modify Traffic Resources for an Established LSP ? > > If it is with Request Message using ActFlag (0001- modify LSP) > then, Do we need to use ERTLV again ? > > ( ie Initial setup is done using ERTLV) > > Thanks In Advice > > gopinathg From owner-mpls@UU.NET Fri Jun 15 10:17:09 2001 Received: from cmr0.ash.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 KAA09674 for ; Fri, 15 Jun 2001 10:17:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktnl10177; Fri, 15 Jun 2001 14:15:42 GMT Received: by mail-control.mail.uu.net id QQktnk21459 for mpls-outgoing; Fri, 15 Jun 2001 14:14:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktnk21404 for ; Fri, 15 Jun 2001 14:14:12 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 QQktnk11529 for ; Fri, 15 Jun 2001 14:11:32 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQktnk21063 for ; Fri, 15 Jun 2001 14:11:31 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5FEBY915944 for ; Fri, 15 Jun 2001 07:11:34 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA17448 for mpls@uu.net; Fri, 15 Jun 2001 10:11:29 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktna07117 for ; Fri, 15 Jun 2001 11:36: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 QQktna08574 for ; Fri, 15 Jun 2001 11:35:30 GMT Received: from lisa.intechnology.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mgate.intechnology.co.uk [213.146.130.27]) id QQktna01252 for ; Fri, 15 Jun 2001 11:35:29 GMT Received: from LAP0608 ([172.16.25.108]) by lisa.intechnology.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M56LQPM7; Fri, 15 Jun 2001 12:36:40 +0100 Reply-To: From: "Steven Godfrey" To: Subject: Management VPN implementation Date: Fri, 15 Jun 2001 12:36:26 +0100 Message-ID: <001801c0f58f$6a09ced0$6c1910ac@intechnology.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a question regarding the use of the management VPN. They way I have implemented our management VPN on Cisco routers is by importing all the other Route Descriptors in to the management VPN. All the other VPN's also import the management VPN as shown below: ip vrf CUST1 rd 13009:106 route-target export 13009:106 route-target import 13009:106 route-target import 13009:108 ! ip vrf CUST2 rd 13009:110 route-target export 13009:110 route-target import 13009:110 route-target import 13009:108 ! <<<<>>>>>>>>>>> ip vrf MGMNT rd 13009:108 route-target export 13009:108 route-target import 13009:108 route-target import 13009:10 route-target import 13009:102 route-target import 13009:106 route-target import 13009:112 route-target import 13009:110 route-target import 13009:104 route-target import 13009:114 This works fine at the moment, my question is when CUST3 is configured say he uses the same address space as CUST2, i.e. 10.10.10.0/24 when I import that route descriptor into the management VPN I will get conflicting address space. Has anyone resolved this issue in their implementation? Thanks in Advance, Steve. From owner-mpls@UU.NET Fri Jun 15 10:19:17 2001 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 KAA09759 for ; Fri, 15 Jun 2001 10:19:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktnl17410; Fri, 15 Jun 2001 14:17:00 GMT Received: by mail-control.mail.uu.net id QQktnk21508 for mpls-outgoing; Fri, 15 Jun 2001 14:14:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktnk21467 for ; Fri, 15 Jun 2001 14:14:33 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 QQktnk10167 for ; Fri, 15 Jun 2001 14:10:20 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQktnk19891 for ; Fri, 15 Jun 2001 14:10:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5FEAM915305 for ; Fri, 15 Jun 2001 07:10:22 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA17437 for mpls@uu.net; Fri, 15 Jun 2001 10:10:17 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktnj28984 for ; Fri, 15 Jun 2001 13:48: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 QQktnj20924 for ; Fri, 15 Jun 2001 13:45:03 GMT Received: from mail2.itu.int by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.itu.ch [156.106.192.18]) id QQktnj07025 for ; Fri, 15 Jun 2001 13:45:02 GMT Received: by mail2.itu.ch with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 15:45:00 +0200 Message-ID: <905DD86907DAD3119DE70000778D770F021CA33F@mailsrv1.itu.ch> From: "Bigi, Fabio" To: "'mpls@uu.net'" Subject: Liaison statement from ITU-T SG 13 to MPLS Date: Fri, 15 Jun 2001 15:44:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0F5A1.5F4903FC" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0F5A1.5F4903FC Content-Type: text/plain; charset="iso-8859-1" Please find attached a Liaison Statement from ITU-T SG 13 which met in Caracas, Venezuela from 14-25 May 2001 to the MPLS forum. Best regards, Fabio Bigi TSB Senior Counsellor <> ------_=_NextPart_000_01C0F5A1.5F4903FC Content-Type: application/msword; name="LS-19-13.doc" Content-Disposition: attachment; filename="LS-19-13.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAAAAAA EAAAKAAAAAEAAAD+////AAAAACUAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAEgkAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYALhgAADd8AAA3fAAAtwQAAAAAAABaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAFYCAAAAAAAAVgIAAFYC AAAAAAAAVgIAAAAAAABWAgAAAAAAAFYCAAAAAAAAVgIAABQAAAAAAAAAAAAAAIoCAAAAAAAADAUA AAAAAAAMBQAAAAAAAAwFAAA4AAAARAUAABQAAABYBQAAHAAAAIoCAAAAAAAAewgAABQBAACABQAA AAAAAIAFAAAoAAAAqAUAAAAAAACoBQAAAAAAAKgFAAAAAAAAqAUAAAAAAACoBQAAAAAAAKgFAAAA AAAA+gcAAAIAAAD8BwAAAAAAAPwHAAAAAAAA/AcAAAAAAAD8BwAAAAAAAPwHAAAAAAAA/AcAACQA AACPCQAAIAIAAK8LAABiAAAAIAgAABUAAAAAAAAAAAAAAAAAAAAAAAAAVgIAAAAAAACoBQAAAAAA AAAAAAAAAAAAAAAAAAAAAACoBQAAAAAAAKgFAAAAAAAAqAUAAAAAAACoBQAAAAAAACAIAAAAAAAA 7AYAAAAAAABWAgAAAAAAAFYCAAAAAAAAqAUAAAAAAAAAAAAAAAAAAKgFAAAAAAAANQgAABYAAADs BgAAAAAAAOwGAAAAAAAA7AYAAAAAAACoBQAAvgAAAFYCAAAAAAAAqAUAAAAAAABWAgAAAAAAAKgF AAAAAAAA+gcAAAAAAAAAAAAAAAAAAOwGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAqAUAAAAAAAD6BwAAAAAAAOwGAADiAAAA7AYAAAAAAAAAAAAA AAAAAM4HAAAAAAAAVgIAAAAAAABWAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzgcAAAAAAACoBQAAAAAAAHQFAAAMAAAAIAscWFDz wAGKAgAAggIAAAwFAAAAAAAAZgYAAEYAAADOBwAAAAAAAAAAAAAAAAAAzgcAACwAAABLCAAAMAAA AHsIAAAAAAAAzgcAAAAAAAARDAAAAAAAAKwGAABAAAAAEQwAAAAAAADOBwAAAAAAAOwGAAAAAAAA agIAABIAAAB8AgAADgAAAFYCAAAAAAAAVgIAAAAAAABWAgAAAAAAAFYCAAAAAAAAAgDZAAAATFMg MTkvMTMNUVVFU1RJT046CTExLzEzDVNPVVJDRToJSVRVLVQgU0cxMyBtZWV0aW5nIChDYXJhY2Fz LCAxNCBNYXkgliAyNSBNYXkgMjAwMSkNVElUTEU6CUluaXRpYXRpb24gb2YgbmV3IHdvcmsgaXRl bXMgb24gVm9pY2Ugb3ZlciBNUExTIChWb01QTFMpDV9fX19fX19fX19fX18NQ09NTVVOSUNBVElP Tg1UTzoJTVBMUyBGb3J1bQ1BUFBST1ZBTDoJQWdyZWVkIGF0IElUVS1UIFNHMTMgbWVldGluZw1G T1I6CUluZm9ybWF0aW9uDURFQURMSU5FOglOL0ENDUNPTlRBQ1Q6CVExMSBSYXBwb3J0ZXVyDQlN YXJjbyBDYXJ1Z2kJVGVsOgkrMzMyIDk2MDUgMzYxNw1GcmFuY2UgVGVsZWNvbQlGYXg6CSszMzIg OTYwNSAzMjk4DQlFbWFpbDptYXJjby5jYXJ1Z2lAZnJhbmNldGVsZWNvbS5jb20NRlQgUiZEDTIg YXZlbnVlIFBpZXJyZSBNYXJ6aW4NMjIzMDAgTGFubmlvbiBDZWRleA1GcmFuY2UNBwdJVFUtVCBT RyAxMyBleHByZXNzZXMgaXRzIGFwcHJlY2lhdGlvbiB0byB0aGUgTVBMUyBGb3J1bSBmb3IgaXRz IHJlY2VudCBjb21tdW5pY2F0aW9uIG9mIHRoZSBEcmFmdCBJbXBsZW1lbnRhdGlvbiBBZ3JlZW1l bnQgb24gVm9pY2Ugb3ZlciBNUExTIChWb01QTFMpLiBTRyAxMyBpcyBwbGVhc2VkIHRvIGluZm9y bSB5b3VyIG9yZ2FuaXphdGlvbiB0aGF0IHdlIGhhdmUgaW5pdGlhdGVkIHdvcmsgaXRlbXMgcmVs YXRlZCB0byBWb01QTFMgKHJlcXVpcmVtZW50cywgc2VydmljZSBkZWZpbml0aW9uLCBmcmFtZXdv cmsgYXJjaGl0ZWN0dXJlLCB1c2VyIHBsYW5lIHByb3RvY29sIGFuZCBpbnRlcndvcmtpbmcpLiAN QW4gaW50ZXJpbSBtZWV0aW5nIG9uIHRoZSBWb01QTFMgdG9waWNzIGlzIHBsYW5uZWQgaW4gb3Jk ZXIgdG8gcHJvZ3Jlc3MgdGhlIHdob2xlIFZvTVBMUyB3b3JrIGFuZCB3ZSB3aWxsIGNvbW11bmlj YXRlIHlvdSB0aGUgbWFpbiByZXN1bHRzIG9mIHRoaXMgbWVldGluZy4NT3VyIGludGVudGlvbiBp cyBhbHNvIHRvIHByb3ZpZGUgY29tbWVudHMgdG8geW91IG9uIHRoZSBhYm92ZS1tZW50aW9uZWQg ZG9jdW1lbnQuICANV2UgbG9vayBmb3J3YXJkIHRvIGEgY2xvc2UgY29vcGVyYXRpb24gd2l0aCBN UExTIEZvcnVtIGFzIHRoZSB3b3JrIHByb2dyZXNzZXMgYW5kIHdpbGwgbWFrZSBldmVyeSBlZmZv cnQgdG8ga2VlcCB5b3UgaW5mb3JtZWQgb2Ygb3VyIHByb2dyZXNzLiAgDV9fX19fX19fX19fX19f X19fX18NDRMgRklMRU5BTUUgXHAgXCogTUVSR0VGT1JNQVQgFEQ6XE1heTAxLUxTXExTLTE5LmRv YxUJCRMgc2F2ZWRhdGUgXEAgZGQuTU0ueXkgFDA4LjA2LjAxFQ0NDQ0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAACQQA ACEEAAAnBAAAKwQAACwEAAA1BAAAOgQAADsEAABFBAAARgQAAFIEAABTBAAAogQAAK8EAADTBAAA 2QQAAN0EAADeBAAA6wQAAPYEAAABBQAABAUAAAYFAAAlBQAAKwUAAEAFAABqBQAAiAUAAIkFAACm BQAApwUAALoFAAC7BQAAwQUAAMIFAADEBQAAoQYAAL0GAAAgBwAAIQcAABAIAAARCAAAtwgAALgI AADUCAAA1QgAAPz16fXh9enW6dbp1vXO9en14fXp9en1yb/J9bizqJj16fXp9QCWAJAAkPWFfoUA AAAAAAAAAAAAAAAAAAAAAAAMQ0oUAE9KAABRSgAAABUDagAAAABDShQAT0oAAFFKAABVCAELbkgR BG8oAXRIEQQDbygBH0NKGABPSgAAUUoAAG1IDARuSBEEbygBc0gMBHRIEQQUQ0oYAE9KAABRSgAA bUgMBHNIDAQACE9KAABRSgAAAAwwShMAT0oAAFFKAAAAE21ICgxuSBEEbygBc0gKDHRIEQQIbUgK DHNICgwADzUIgUNKGABPSgAAUUoAABRDShgAT0oAAFFKAABuSBEEdEgRBAAPOwiBQ0oYAE9KAABR SgAAF0NKGABPSgAAUUoAAG5IEQRvKAF0SBEEDENKGABPSgAAUUoAAAAGNQiBXAiBLgAEAAAJBAAA GQQAAFQEAACUBAAAogQAALAEAAC/BAAA5gQAAPcEAAAFBQAABgUAAB4FAABABQAAYwUAAIkFAACQ BQAApwUAAPUAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAA AADOAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAA AAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAALIAAAAAAAAA AAAAAACiAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAJQAAAAAAAAAAAAAAACUAAAAAAAAAAAAAAAA AAAADgAADcYFAAFgGEAPhBsGFiQBSWYBAAAAXoQbBgAPAAANxggAAvIVsxsAQA+EGwYWJAFJZgEA AABehBsGDhEADcYNAQcaAxsG8hWzGwAAABYkAUlmAQAAAA4RAA3GDQEHGgMbBmAYsxsAAAAWJAFJ ZgEAAAATAAADJAEPhAMAEYT9/xOkeAAWJAFJZgEAAABehAMAYIT9/2EkARQAAA3GBQABFwYAD4QX BhGE6fkTpHgAFiQBSWYBAAAAXoQXBmCE6fkKEQADJAINxgQBBxoAE6R4AGEkAgARAAQAALcIAAAR CQAA/v4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQKnBQAAuwUAAMIF AADDBQAAxAUAACEHAAC9BwAAEQgAAKIIAAC2CAAAtwgAAA8JAAAQCQAA8QAAAAAAAAAAAAAAAPEA AAAAAAAAAAAAAADhAAAAAAAAAAAAAAAArwAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAACgAAAAAAAA AAAAAAAAmQAAAAAAAAAAAAAAAIcAAAAAAAAAAAAAAAB4AAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAA AHIAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAARAAAAMAABOk eAAPDwADJAENxg4ABBoDpwQ0BsEHwMDAwBOkeABhJAEAERQADcYFAAEAAAAPhP7/EYQBABOkeABW RP//XoT+/2CEAQAABhIAAyQDE6R4AGEkAwAOEgADJAMPhAAAEYQAABOkeABehAAAYIQAAGEkAwAx AAAWJAEXJAFJZgEAAAAAVAEAApZsAAjWGgABlP9YJgAGxCYAAAAAAAAAAAAAAAAAAAAAFPYBAAAa 1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/NNYGAAEKA2wAYfYDAAAQAAANxgUAAWAYQA+EGwYT pHgAFiQBSWYBAAAAXoQbBg4AAA3GBQABYBhAD4QbBhYkAUlmAQAAAF6EGwYADNUIAADqCAAA6wgA AO0IAADuCAAABAkAAAUJAAANCQAADgkAABEJAAASCQAA8+jh6OHo8+gA2gAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQ0oYAE9KAABRSgAAAAxDShQAT0oAAFFKAAAAFQNq AAAAAENKFABPSgAAUUoAAFUIARdDShQAT0oAAFFKAABtSAAEbkgABHUIAQAKEAkAABEJAAASCQAA /QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAABOkeAAAAQAAAAIsAAdQDwAIUA8AJlAJ ADGQaAEfsH0uILDIQSGwbgQisG4EI5BuBCSQbgQlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAFQAKAAEAaQAPAAMA AAAAAAAAAABAAABA8f8CAEAADAAGAE4AbwByAG0AYQBsAAAAAgAAACAAQ0oWAE9KAgBRSgIAX0gB BGFKGABtSAkEc0gJBHRICQQAAAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQAZQBmAGEA dQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAQgAfQAEA8gBC AAwAEQBIAGUAYQBkAGUAcgAsAGUAbgBjAGEAYgBlAHoAYQBkAG8AAAANAA8ADcYIAAJfEr4kAQIA AAAsACBAAQACASwADAAGAEYAbwBvAHQAZQByAAAADQAQAA3GCAACXxK+JAECAAAAUAD+TwEAEgFQ AAwABABIAGUAYQBkAAAAGgARAA3GBQABBxrANSQANyQAOCQAOUQCAEgkABwAQ0oYAE9KAABQSgMA UUoAAGFKFABtSAkIc0gJCGYA/k8BACIBZgAMAAcASQBuAGYAbwBkAG8AYwAAACoAEgANxgUAAYoF wA+EigURhHb6NSQANyQAOCQAOUQCAEgkAF6EigVghHb6HABDShgAT0oAAFBKAwBRSgAAYUoUAG1I CQhzSAkIKABVQKIAMQEoAAwACQBIAHkAcABlAHIAbABpAG4AawAAAAYAPioBQioCTgBCQAEAQgFO AAwACQBCAG8AZAB5ACAAVABlAHgAdAAAABoAFAADJAMPhDgEEmTwAAAAFKTwAF6EOARhJAMQAECI +/9DShQAUEoDAGFKFAAAAAAAEgUAAAYAABgAAAAA/////wEAAAAEIP//AQAYK6MAAAAAAAAAAAAS BQAAAAAAAAAAAAAAAAkAAAAZAAAAVAAAAJQAAACiAAAAsAAAAL8AAADmAAAA9wAAAAUBAAAGAQAA HgEAAEABAABjAQAAiQEAAJABAACnAQAAuwEAAMIBAADDAQAAxAEAACEDAAC9AwAAEQQAAKIEAAC2 BAAAtwQAAA8FAAATBQAAmAAAABEwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqwAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqwAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAABEwAAAAAAAAAIAA AACAqQAAABEwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAmAAAABIw AAAAAAAAAIAAAACAmAAAABIwAAAAAAAAAIAAAACAmAAAABIwAAAAAAAAAIAAAACAmAAAABQAAAAA AAAAAIAAAACAmAAAAA8wAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAABAwAAAAAAAA AIAAAACAmgAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAFkAAABZAAAAWQAAAFwAAAAABAAA1QgAABIJAAAGAAAACgAAAAAEAACnBQAAEAkAABIJ AAAHAAAACQAAAAsAAAAABAAAEQkAAAgAAAAAAAAAHQAAADMAAAA2AAAATQAAAFYAAABcAAAAEx0U /5WAExYU/5WAAAAAAAgAAACMAAAAkgAAABMBAAAdAQAAJQEAACsBAAAsAQAALwEAAKABAACmAQAA rQEAALQBAAC1AQAAugEAAFQCAABaAgAAtwIAAL0CAAARAwAAHQMAADsDAABBAwAAcwMAAHkDAAC3 BAAA6wQAAO0EAAAOBQAAEAUAABMFAAAEAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcABwAEAAcABwAHAAAAAAAJAAAAaQEAAIgBAACSAQAAmAEAALcEAADr BAAA7QQAAA4FAAAQBQAAEwUAAAQABwA6AAcAGgAHAAcABAAHAAcABwAAAAAACAAAAOYAAAD3AAAA HwEAAEABAACiBAAAtgQAALcEAAAOBQAAEwUAAAQABwAFAAcABQAHAAUABwAEAAcA//8GAAAABwBv AHIAZQBpAGwAbAB5ACkATQA6AFwAUwBHAF8ARABPAEMAXABTAEcAMQAzAFwATQBhAHkAMAAxAFwA TwB1AHQAZwBvAGkAbgBnAEwAUwBcAEwAUwAtADEAOQAuAGQAbwBjAAcAbwByAGUAaQBsAGwAeQAV AEQAOgBcAE0AYQB5ADAAMQAtAEwAUwBcAEwAUwAtADEAOQAuAGQAbwBjAAcAbwByAGUAaQBsAGwA eQAVAEQAOgBcAE0AYQB5ADAAMQAtAEwAUwBcAEwAUwAtADEAOQAuAGQAbwBjAAAAAAAJAAAAwwEA AMQBAAC2BAAAEwUAAAAAAAAIAAAAAgEAAJYBAAABAAAA/0AAgAEAAAAAAAAAAACg6+QCAQABAAAA AAAAAAAAAAAAAAAAAAACEAAAAAAAAAASBQAAYAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A //8BAAgAAAAAAAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABAAAAEcWkAEA AAICBgMFBAUCAwSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIA bwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBi AG8AbAAAADMmkAEAAAILBgQCAgICAgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwA AABdEZABgAoAAAAAAAAAAAAAAQAAAAAABwgQAAAAAAAAAAAAAgAAAAAATQBTACAATQBpAG4AYwBo AG8AAABBAHIAaQBhAGwAIABVAG4AaQBjAG8AZABlACAATQBTAAAAIgAEADEIjBgA8NACAABoAQAA AADYOlaGO2RWRpkaO2YFAAQAAAAAAAAAAAAAAAEAAQAAAAQAAxABAAAAAAAAAAAAAAABAAEAAAAB AAAAAAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG4EbgS0ALQAgYEeMAAAEAAZ AGQAAAAZAAAAAAAAAAAAAAAAAAAAZcLivgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAnwEAAAAACDKDUQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP//EgAAAAAAAAAOAEkAVABVACAATgBvAHIAbQBhAGwALgBkAG8AdAAAAAAA AAAHAG8AcgBlAGkAbABsAHkABwBvAHIAZQBpAGwAbAB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAA AAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACEAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAAuAAA AAQAAADEAAAABQAAANQAAAAGAAAA4AAAAAcAAADsAAAACAAAAPwAAAAJAAAADAEAABIAAAAYAQAA CgAAADQBAAALAAAAQAEAAAwAAABMAQAADQAAAFgBAAAOAAAAZAEAAA8AAABsAQAAEAAAAHQBAAAT AAAAfAEAAAIAAADkBAAAHgAAAA8AAABJVFUgTm9ybWFsLmRvdAAAHgAAAAEAAAAAVFUgHgAAAAgA AABvcmVpbGx5AB4AAAABAAAAAHJlaR4AAAABAAAAAHJlaR4AAAAHAAAAbm9ybWFsAAAeAAAACAAA AG9yZWlsbHkAHgAAAAIAAAA1AGVpHgAAABMAAABNaWNyb3NvZnQgV29yZCA5LjAAAEAAAAAAGA2P AAAAAEAAAAAAFkPr1CW/AUAAAAAAuK6VM+/AAUAAAAAAEkg2UPPAAQMAAAABAAAAAwAAAAAAAAAD AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALV zdWcLhsQk5cIACss+a4wAAAA+AAAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAHwAAAAGAAAAhAAA ABEAAACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAAAKwAAAAWAAAAtAAAAA0AAAC8AAAA DAAAANcAAAACAAAA5AQAAB4AAAAEAAAASVRVAAMAAAABAAAAAwAAAAEAAAADAAAAAAAAAAMAAACg CgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAA8AAABJVFUgTm9ybWFs LmRvdAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoA AAALAAAADAAAAP7///8OAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAA/v///xYAAAAXAAAAGAAA ABkAAAAaAAAAGwAAABwAAAD+////HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAAP7////9//// JwAAAP7////+/////v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABG AAAAAAAAAAAAAAAAcD8fWFDzwAEpAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAAEAAAAAAAAFcAbwByAGQARABv AGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIB BQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4YAAAA AAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAVAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAB0AAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAQAAAAYAAAD/////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAATwBiAGoAZQBjAHQA UABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAHA/H1hQ88ABcD8fWFDzwAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQg V29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= ------_=_NextPart_000_01C0F5A1.5F4903FC-- From owner-mpls@UU.NET Fri Jun 15 11:37:07 2001 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 LAA12069 for ; Fri, 15 Jun 2001 11:37:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktnq05656; Fri, 15 Jun 2001 15:35:13 GMT Received: by mail-control.mail.uu.net id QQktnq18324 for mpls-outgoing; Fri, 15 Jun 2001 15:34:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktnq18316 for ; Fri, 15 Jun 2001 15:34:35 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 QQktnq25005 for ; Fri, 15 Jun 2001 15:34:03 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQktnq02663 for ; Fri, 15 Jun 2001 15:34:02 GMT Received: by SANMIGUEL with Internet Mail Service (5.5.2448.0) id ; Fri, 15 Jun 2001 17:31:55 +0200 Message-ID: From: Javier Antich Reply-To: steven.godfrey@intechnology.co.uk To: "'Steven Godfrey '" , "'mpls@UU.NET '" Subject: RE: Management VPN implementation Date: Fri, 15 Jun 2001 17:31:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk You should be sure that each CE router has a unique loopback address for management which is not the same than any other. It should not be a problem that the links between CE-PE in different VPNs overlap (only that the routing table in the Management VPN VRF may be funny). -----Original Message----- From: Steven Godfrey To: mpls@UU.NET Sent: 15/06/01 13:36 Subject: Management VPN implementation Hi, I have a question regarding the use of the management VPN. They way I have implemented our management VPN on Cisco routers is by importing all the other Route Descriptors in to the management VPN. All the other VPN's also import the management VPN as shown below: ip vrf CUST1 rd 13009:106 route-target export 13009:106 route-target import 13009:106 route-target import 13009:108 ! ip vrf CUST2 rd 13009:110 route-target export 13009:110 route-target import 13009:110 route-target import 13009:108 ! <<<<>>>>>>>>>>> ip vrf MGMNT rd 13009:108 route-target export 13009:108 route-target import 13009:108 route-target import 13009:10 route-target import 13009:102 route-target import 13009:106 route-target import 13009:112 route-target import 13009:110 route-target import 13009:104 route-target import 13009:114 This works fine at the moment, my question is when CUST3 is configured say he uses the same address space as CUST2, i.e. 10.10.10.0/24 when I import that route descriptor into the management VPN I will get conflicting address space. Has anyone resolved this issue in their implementation? Thanks in Advance, Steve. From owner-mpls@UU.NET Fri Jun 15 12:06:18 2001 Received: from cmr1.ash.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 MAA12929 for ; Fri, 15 Jun 2001 12:06:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktns13983; Fri, 15 Jun 2001 16:05:33 GMT Received: by mail-control.mail.uu.net id QQktns04224 for mpls-outgoing; Fri, 15 Jun 2001 16:05:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktns03026 for ; Fri, 15 Jun 2001 16:04: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 QQktns05717 for ; Fri, 15 Jun 2001 16:01:03 GMT Received: from mail.marhold.at by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.marhold.at [194.152.126.85]) id QQktns00933 for ; Fri, 15 Jun 2001 16:01:02 GMT Received: from AMARHOLD ([192.168.1.33]) by mail.marhold.at (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id at; Fri, 15 Jun 2001 18:11:45 +0200 From: "Alexander Marhold" To: , Subject: RE: Management VPN implementation Date: Fri, 15 Jun 2001 18:03:09 +0200 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <001801c0f58f$6a09ced0$6c1910ac@intechnology.co.uk> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Some points on that a) importing via customer-RTs into the management VPN does not scale and is cumbersome to implement as for each new customer you need to add those import RTs the better way is to export to a separate RT ( separate from any customer) on all customer sites and to import that one in the MGMT-vrf b) what connectivity does the MGMT really need ? as Javier Antich in his mail has already mentioned it is typically the loopback address only. so the best way to do those things is: 1) using loopbackaddresses of a specified range for all managed routers 2) SELECTIVE export of only the loopback to this specific RT (RT-x1) ( using the "export map xxx" statement) 3) importing that RT in the MGMT-vrf 4) exporting the MGMT address using the RT (RT-x2) 5) importing that RT on all customer sites having a mangaged router 6) on the managed router specify that SNMP and other protocols are using the loopback-address as source address for their messages That`s it then: -> you only need one route map and can apply this to all customer vrf's can be a template) -> whenever you enter a new customer site NO config changes on the MGMT site is needed -> it is a scalable solution with best regards Alexander __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ __/ __/ Dipl.Ing. Alexander Marhold MBA __/ CCIE #3324, CCNP, CCDP, CCSI #20642 __/ Core & IP Services __/ Mobile: ++43-(0)664-16 28 234 __/ PRO IN http://www.proin.com -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Steven Godfrey Sent: Friday, June 15, 2001 1:36 PM To: mpls@UU.NET Subject: Management VPN implementation Hi, I have a question regarding the use of the management VPN. They way I have implemented our management VPN on Cisco routers is by importing all the other Route Descriptors in to the management VPN. All the other VPN's also import the management VPN as shown below: ip vrf CUST1 rd 13009:106 route-target export 13009:106 route-target import 13009:106 route-target import 13009:108 ! ip vrf CUST2 rd 13009:110 route-target export 13009:110 route-target import 13009:110 route-target import 13009:108 ! <<<<>>>>>>>>>>> ip vrf MGMNT rd 13009:108 route-target export 13009:108 route-target import 13009:108 route-target import 13009:10 route-target import 13009:102 route-target import 13009:106 route-target import 13009:112 route-target import 13009:110 route-target import 13009:104 route-target import 13009:114 This works fine at the moment, my question is when CUST3 is configured say he uses the same address space as CUST2, i.e. 10.10.10.0/24 when I import that route descriptor into the management VPN I will get conflicting address space. Has anyone resolved this issue in their implementation? Thanks in Advance, Steve. From owner-mpls@UU.NET Fri Jun 15 13:46:13 2001 Received: from cmr0.ash.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 NAA19156 for ; Fri, 15 Jun 2001 13:46:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktny15584; Fri, 15 Jun 2001 17:44:36 GMT Received: by mail-control.mail.uu.net id QQktny10405 for mpls-outgoing; Fri, 15 Jun 2001 17:43:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktny10367 for ; Fri, 15 Jun 2001 17:43: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 QQktny26638 for ; Fri, 15 Jun 2001 17:40:29 GMT Received: from milan.turinnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 63-197-247-126.turinntwks.com [63.197.247.126] (may be forged)) id QQktny11634 for ; Fri, 15 Jun 2001 17:40:29 GMT Received: by MILAN with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 10:40:13 -0700 Message-ID: <36EF020032CFD411B7B400508B55E590A21B2F@MILAN> From: Bhaskara Peela To: mpls@UU.NET Subject: GMPLS LSR MIB Date: Fri, 15 Jun 2001 10:40:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Is any there any work going on for the GMPLS support of LSR mib. i.e., is there any MIB that enables the provisioning of static GMPLS LSPs. thanks regards bhaskara From owner-mpls@UU.NET Fri Jun 15 13:56:27 2001 Received: from cmr0.ash.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 NAA19721 for ; Fri, 15 Jun 2001 13:56:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktnz27476; Fri, 15 Jun 2001 17:56:10 GMT Received: by mail-control.mail.uu.net id QQktnz11935 for mpls-outgoing; Fri, 15 Jun 2001 17:55:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktnz11925 for ; Fri, 15 Jun 2001 17:55:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktnz02501 for ; Fri, 15 Jun 2001 17:52:51 GMT Received: from exchange01.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.205.166.180]) id QQktnz28551 for ; Fri, 15 Jun 2001 17:52:51 GMT Received: from BLIULAPTOP ([64.47.72.62]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 15 Jun 2001 13:48:39 -0400 Message-ID: <018a01c0f5c3$c3231ce0$70c8193e@movaz.com> From: "Adrian Farrel" To: "Bhaskara Peela" Cc: References: <36EF020032CFD411B7B400508B55E590A21B2F@MILAN> Subject: Re: GMPLS LSR MIB Date: Fri, 15 Jun 2001 13:50:11 -0400 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: 15 Jun 2001 17:48:40.0328 (UTC) FILETIME=[69781880:01C0F5C3] Sender: owner-mpls@UU.NET Precedence: bulk Yes, in deed. The authors of the GMPLS TE MIB are discussing this at the moment and I hope that we'll have something out soon(ish). Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ----- Original Message ----- From: "Bhaskara Peela" To: Sent: Friday, June 15, 2001 1:40 PM Subject: GMPLS LSR MIB > Hi, > > Is any there any work going on for the GMPLS support of LSR mib. > i.e., is there any MIB that enables the provisioning of static GMPLS LSPs. > > thanks > > regards > bhaskara > From owner-mpls@UU.NET Fri Jun 15 14:31:08 2001 Received: from cmr1.ash.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 OAA21726 for ; Fri, 15 Jun 2001 14:31:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktnk11685; Fri, 15 Jun 2001 14:02:19 GMT Received: by mail-control.mail.uu.net id QQktnk04849 for mpls-outgoing; Fri, 15 Jun 2001 14:01:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktnk04740 for ; Fri, 15 Jun 2001 14:01:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktnj08726 for ; Fri, 15 Jun 2001 13:59:14 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktnj08222 for ; Fri, 15 Jun 2001 13:59:13 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 92D759400B; Fri, 15 Jun 2001 09:59:08 -0400 (EDT) Message-ID: <3B2A14AC.C30DDD7F@sandburst.com> Date: Fri, 15 Jun 2001 09:59:08 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Abhijit Gadgil Cc: mpls@UU.NET Subject: Re: LMp. 17 in rfc3036. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Abhijit, Please see below. You wrote: > Hi, > > perhaps it's pointed out before, but inclusion of MsgSource in the loop of > LMp. 17 seems somewhat problematic. > > Consider > Ru - Upstream guy (DU ordered, Loop Detection = Yes) > Rd - Downstream guy (DU ordered, Loop Detection = Yes) > F - FEC in question. > > Assume Rd is not egress for the FEC, then according to section 2.8.2, Rd > will send Path Vector to Ru. > > > If Rd sends mapping for fec F to Ru. > and as a part of loop of LMp. 17 > Now at Ru according to LMp. 18 - LMp.21 > > LMp. 18 - No > LMp. 19 - Yes > LMP. 20 - (PV = (LSRid Ru, LSRid Rd), Hop Count = 0) > LMp. 21 - send message to Rd. > > Now when Rd receives this message, it will detect a loop according to > Check_Received_Attributes, it will NAK the message, with Loop Detected. > This is interesting behavior. Implied in the use of a Path Vector is the intent to use the corresponding LSP as reflected by the Path Vector. However, whether Ru provides a label mapping to Rd in response to the label mapping it received from Rd or not, it MUST NOT bind these two labels. There is a logical disconnect - therefore - in having Ru send a label mapping to Rd containing a path vector with Rd in it already. As you point out, Rd will detect a loop and release the Label Mapping it receives from Ru, and the problem goes away. > > > So the purpose of sending the message is lost (Even with Liberal > Retention at Rd). Not necessarily, see below. > > > not inclusion of Rd in LMp. 17 is perhaps, problematic if Rd is of the > type RequestNever.(Which is likely in DU) and Then Rd may never get > mapping from Ru if Ru becomes nexthop for the same FEC sometime. But then > in that case. Upon receiving Mapping from new next hop Rd1 (below), Ru > will propagate it to Rd (As a part of LMp. 17 loop again).which won't be > NAKed then. Correct. > > > Initially > -----------> > Ru ------------ Rd > | > | > | > Rd1 > > Later (perhaps) > <---------- > Ru ------------ Rd > | | > | | > | v > Rd1 > > This may not be problematic if Loop Detection is not enabled and Rd does > not send Path Vector in Mapping to Ru. Exactly. It is not definitely wrong for Ru to send a label mapping to Rd for the same FEC that Rd has just sent a label mapping to Ru - even though Ru knows that Rd is the next hop for this FEC. However, in doing so, it is effectively NOT using ordered control since there is no downstream label to which it can bind the label it is advertising to Rd. As said before, it is definitely wrong for Ru to bind the label it receives from Rd to the label it advertises to Rd. > > > Of course this is not harmful as far as the normal operation goes. It's > only unnecessary. Am I missing something? It can be useful, as you suggested, in the case where Rd is using DU, and liberal retention, modes. > > > thanks and regards > > -abhijit From owner-mpls@UU.NET Fri Jun 15 16:16:09 2001 Received: from cmr1.ash.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 QAA27715 for ; Fri, 15 Jun 2001 16:16:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktoj04664; Fri, 15 Jun 2001 20:16:03 GMT Received: by mail-control.mail.uu.net id QQktoi23000 for mpls-outgoing; Fri, 15 Jun 2001 20:14:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktoi22995 for ; Fri, 15 Jun 2001 20:14:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQktoi12083 for ; Fri, 15 Jun 2001 20:13:09 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQktoi15894 for ; Fri, 15 Jun 2001 20:12:37 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f5FK9WJ16895; Fri, 15 Jun 2001 16:09:32 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 16:13:16 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D0220404015450E0@mail1.tellium.com> From: Sudipta Sengupta To: "'Wayne W. Szeto'" , mpls@UU.NET Subject: RE: constraint-based routing algorithms Date: Fri, 15 Jun 2001 16:13:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk OSPF TE extensions have been proposed to disseminate link bandwidth information for facilitating distributed traffic engineered route computation. one important metric for evaluating the efficiency of constraint-based routing algorithms is reduced path blocking. most of the algorithms mentioned below (mira, etc.) try to minimize path blocking in an online routing model. vendors look upon the path computation module of their MPLS software as proprietary and would not want to reveal the precise algorithms used. the interest of customers (carriers/ISPs) in such sophisticated algorithms is also not clear. a case needs to be made for the direct or indirect translation of efficient routing into network deployment and operational cost savings. to the best of my knowledge, MPLS implementations continue to use a simple shortest-hop or shortest-cost (with user defined cost) based algorithms for path computation. --sudipta __________________________________ Sudipta Sengupta Tellium Optical Networking Systems 2 Crescent Place PO box 901 Oceanport, NJ 07757-0901. Email: sudipta@tellium.com Phone: +1-732-483-2837 -----Original Message----- From: Wayne W. Szeto [mailto:wwszeto@math.uwaterloo.ca] Sent: Thursday, June 14, 2001 4:14 PM To: mpls@UU.NET Subject: constraint-based routing algorithms I have been looking at constraint-based routing algorithms for a while and the ones that I encountered are all based on minimum interference routing algorithm (mira), including s-mira, l-mira, lbu (link based utilization qos routing algorithm), and profile-based routing. I would like to know the trend for routing algorithms in MPLS networks. Are MPLS networks deployed today or in the near future going to use the simplest routing algorithm (i.e. minimum-hop)? Is there any MPLS networks using mira? or is there some other more popular algorithms that I'm missing? Thanks for any help. From owner-mpls@UU.NET Fri Jun 15 16:51:31 2001 Received: from cmr1.ash.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 QAA29336 for ; Fri, 15 Jun 2001 16:51:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktol08234; Fri, 15 Jun 2001 20:51:10 GMT Received: by mail-control.mail.uu.net id QQktol26136 for mpls-outgoing; Fri, 15 Jun 2001 20:50:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktol26129 for ; Fri, 15 Jun 2001 20:50: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 QQktol12795 for ; Fri, 15 Jun 2001 20:49:50 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe70.law10.hotmail.com [64.4.14.205]) id QQktol03779 for ; Fri, 15 Jun 2001 20:49:49 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Jun 2001 13:49:49 -0700 X-Originating-IP: [12.34.209.74] From: "Frank Hujber" To: "Sudipta Sengupta" , "'Wayne W. Szeto'" , References: <0CD7D73C734BD411AEE100B0D0220404015450E0@mail1.tellium.com> Subject: Re: constraint-based routing algorithms Date: Fri, 15 Jun 2001 16:47:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: X-OriginalArrivalTime: 15 Jun 2001 20:49:49.0031 (UTC) FILETIME=[B7B88F70:01C0F5DC] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can you give a clue as to any public domain documents for these protocols? Frank Hujber Alphion Corporation fhujber@alphion.com ----- Original Message ----- From: Sudipta Sengupta To: 'Wayne W. Szeto' ; Sent: Friday, June 15, 2001 4:13 PM Subject: RE: constraint-based routing algorithms > OSPF TE extensions have been proposed to disseminate link bandwidth > information for facilitating distributed traffic engineered route > computation. one important metric for evaluating the efficiency of > constraint-based routing algorithms is reduced path blocking. most of the > algorithms mentioned below (mira, etc.) try to minimize path blocking in an > online routing model. vendors look upon the path computation module of their > MPLS software as proprietary and would not want to reveal the precise > algorithms used. the interest of customers (carriers/ISPs) in such > sophisticated algorithms is also not clear. a case needs to be made for the > direct or indirect translation of efficient routing into network deployment > and operational cost savings. to the best of my knowledge, MPLS > implementations continue to use a simple shortest-hop or shortest-cost (with > user defined cost) based algorithms for path computation. > > --sudipta > > __________________________________ > Sudipta Sengupta > Tellium Optical Networking Systems > 2 Crescent Place PO box 901 > Oceanport, NJ 07757-0901. > Email: sudipta@tellium.com > Phone: +1-732-483-2837 > > > -----Original Message----- > From: Wayne W. Szeto [mailto:wwszeto@math.uwaterloo.ca] > Sent: Thursday, June 14, 2001 4:14 PM > To: mpls@UU.NET > Subject: constraint-based routing algorithms > > > > I have been looking at constraint-based routing algorithms for a while and > the ones that I encountered are all based on minimum interference routing > algorithm (mira), including s-mira, l-mira, lbu (link based utilization > qos routing algorithm), and profile-based routing. I would like to know > the trend for routing algorithms in MPLS networks. Are MPLS networks > deployed today or in the near future going to use the simplest routing > algorithm (i.e. minimum-hop)? Is there any MPLS networks using mira? or > is there some other more popular algorithms that I'm missing? Thanks for > any help. > From owner-mpls@UU.NET Fri Jun 15 17:46:49 2001 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 RAA00205 for ; Fri, 15 Jun 2001 17:46:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktop11243; Fri, 15 Jun 2001 21:46:43 GMT Received: by mail-control.mail.uu.net id QQktop20282 for mpls-outgoing; Fri, 15 Jun 2001 21:45:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktop20253 for ; Fri, 15 Jun 2001 21:45:22 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 QQktoo19937 for ; Fri, 15 Jun 2001 21:43:49 GMT Received: from magenta.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQktoo26736 for ; Fri, 15 Jun 2001 21:43:48 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id f5FLh9J93054; Fri, 15 Jun 2001 14:43:09 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id OAA24596; Fri, 15 Jun 2001 14:43:09 -0700 (PDT) Date: Fri, 15 Jun 2001 14:43:09 -0700 (PDT) From: Kireeti Kompella Message-Id: <200106152143.OAA24596@kummer.juniper.net> To: mpls@UU.NET, SSengupta@tellium.com, wwszeto@math.uwaterloo.ca Subject: RE: constraint-based routing algorithms In-Reply-To: <0CD7D73C734BD411AEE100B0D0220404015450E0@mail1.tellium.com> Sender: owner-mpls@UU.NET Precedence: bulk Note that, unlike "regular" SPF, constraint-based routing is used for computing source routes. In regular SPF, if each node were to compute different paths, one could easily have routing loops. In constraint-based routing, each node only needs to ensure that it doesn't compute a looped path. Another point is that the constraint-based routing problem can easily be NP-hard, depending on what constraints are allowed. So, there is much scope for heuristics, etc., which could (would) be considered value-add or even intellectual property. The first point says that there is no great need to standardize the algorithm; the second that there is adequate reason to not standardize it. What should be reasonably uniform is the semantics of some of the more common constraints, so that a SP can have at least a rough idea of how to set the constraints. Daniel Awduche and I had once written a draft on this, but it has expired. It could of course be resurrected, but only if there is adequate interest. Kireeti. From owner-mpls@UU.NET Fri Jun 15 18:14:39 2001 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 SAA00718 for ; Fri, 15 Jun 2001 18:14:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktoq12731; Fri, 15 Jun 2001 22:14:43 GMT Received: by mail-control.mail.uu.net id QQktoq12422 for mpls-outgoing; Fri, 15 Jun 2001 22:14:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktoq12402 for ; Fri, 15 Jun 2001 22:13:59 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 QQktoq15916 for ; Fri, 15 Jun 2001 22:11:08 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQktoq01742 for ; Fri, 15 Jun 2001 22:11:08 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f5FM8iJ19623; Fri, 15 Jun 2001 18:08:44 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 18:12:29 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D022040401982310@mail1.tellium.com> From: Bala Rajagopalan To: "'Kireeti Kompella'" , mpls@UU.NET, Sudipta Sengupta , wwszeto@math.uwaterloo.ca Subject: RE: constraint-based routing algorithms Date: Fri, 15 Jun 2001 18:12:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, June 15, 2001 5:43 PM > To: mpls@UU.NET; SSengupta@tellium.com; wwszeto@math.uwaterloo.ca > Subject: RE: constraint-based routing algorithms > > > > What should be reasonably uniform is the semantics of some of the > more common constraints, so that a SP can have at least a rough > idea of how to set the constraints. > This is an interesting issue. It's usually the case that the nature of the path computation algorithm dictates the kind of metrics that need to be measured/propagated. Given that algorithms are not standard, we have to potentially allow for the superset of metrics to be made standard. Also, given that ultimately it is the service provider (or owner of the network) who wants to realize a certain result from path computation (e.g., optimize something), it is not clear to me how multiple path computation algorithms can exist in the same (multi-vendor) network. It seems like in practice there must be a few commonly agreed upon path computation paradigms (e.g., least cost of some type, with policy constraints) if not algorithms. Different vendors may have their own algorithms to fit the common paradigms, and a multivendor network operator can make sure that different boxes are at least working on the same objective. Regards, Bala From owner-mpls@UU.NET Fri Jun 15 18:20:06 2001 Received: from cmr0.ash.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 SAA00820 for ; Fri, 15 Jun 2001 18:20:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktor02574; Fri, 15 Jun 2001 22:19:42 GMT Received: by mail-control.mail.uu.net id QQktor13008 for mpls-outgoing; Fri, 15 Jun 2001 22:19:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktor12989 for ; Fri, 15 Jun 2001 22:18:51 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 QQktoq21294 for ; Fri, 15 Jun 2001 22:14:07 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQktoq06342 for ; Fri, 15 Jun 2001 22:14:07 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f5FMBiJ19677; Fri, 15 Jun 2001 18:11:44 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 18:15:28 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D0220404015450E2@mail1.tellium.com> From: Sudipta Sengupta To: "'Kireeti Kompella'" , mpls@UU.NET, wwszeto@math.uwaterloo.ca Subject: RE: constraint-based routing algorithms Date: Fri, 15 Jun 2001 18:15:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk kireeti, i came across a reference to the expired draft you mentioned. would be interested in having a look. do you have the last revised version ? we (at tellium) have been looking at path computation algorithms in the context of diverse routing of primary and backup paths in optical networks. algorithms like MIRA (lakshman, et al) have recently been proposed for LSP computation in an online model with the objective of minimizing blocking. given the NP-hardness of most constraint-based routing algorithms, there is always scope for improvement. through standardization efforts of protocol packet formats (e.g., for TE extensions to topology/resource discovery protocols like OSPF), the IETF is INDIRECTLY STANDARDIZING the information model that is available as input for path computation. this information model could be inadequate for intelligent computation of traffic engineered paths as algorithmic complexity evolves (dictated by resource utilization and application needs). for example, in the context of optical networks, there is a need for multi-dimensional cost metric (link cost and fiber miles) for computing delay bounded minimum-cost paths. also, information on the backup bandwidth allocated on a link can be used for efficient computation of shared backup LSPs. it seems that there is an increased need for awareness of constraint-based routing algorithms while designing TE extensions to existing protocols. given the generality of some of the OSPF-TE drafts (like the one on link bundling) in use of terminology and applicability to different types of networks, we have had some confusion in interpreting/mapping the fields in the context of optical networks. this might hinder the development of truly "interoperable" implementations. there is probably a need for clear and concrete interpretation of general drafts for specific underlying transport technologies like optical mesh networks. --sudipta __________________________________ Sudipta Sengupta Tellium Optical Networking Systems 2 Crescent Place PO box 901 Oceanport, NJ 07757-0901. Email: sudipta@tellium.com Phone: +1-732-483-2837 -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, June 15, 2001 5:43 PM To: mpls@UU.NET; SSengupta@tellium.com; wwszeto@math.uwaterloo.ca Subject: RE: constraint-based routing algorithms Note that, unlike "regular" SPF, constraint-based routing is used for computing source routes. In regular SPF, if each node were to compute different paths, one could easily have routing loops. In constraint-based routing, each node only needs to ensure that it doesn't compute a looped path. Another point is that the constraint-based routing problem can easily be NP-hard, depending on what constraints are allowed. So, there is much scope for heuristics, etc., which could (would) be considered value-add or even intellectual property. The first point says that there is no great need to standardize the algorithm; the second that there is adequate reason to not standardize it. What should be reasonably uniform is the semantics of some of the more common constraints, so that a SP can have at least a rough idea of how to set the constraints. Daniel Awduche and I had once written a draft on this, but it has expired. It could of course be resurrected, but only if there is adequate interest. Kireeti. From owner-mpls@UU.NET Fri Jun 15 19:32:41 2001 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 TAA01661 for ; Fri, 15 Jun 2001 19:32:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktow16691; Fri, 15 Jun 2001 23:32:10 GMT Received: by mail-control.mail.uu.net id QQktow09020 for mpls-outgoing; Fri, 15 Jun 2001 23:31:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktow08968 for ; Fri, 15 Jun 2001 23:31:19 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 QQktow25337 for ; Fri, 15 Jun 2001 23:30:05 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQktow13220 for ; Fri, 15 Jun 2001 23:30:02 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f5FNRXJ20795; Fri, 15 Jun 2001 19:27:33 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Jun 2001 19:31:18 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D022040402088933@mail1.tellium.com> From: Hang Liu To: Sudipta Sengupta , "'Kireeti Kompella'" , mpls@UU.NET, wwszeto@math.uwaterloo.ca Subject: RE: constraint-based routing algorithms Date: Fri, 15 Jun 2001 19:31:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, Note that different vendors or network operators may want to use different algorithms, metrics and/or constraints to compute optimal path in their networks. Some algorithms, metrics and/or constraints may be only suitable for certain networks (optical, IP, MPLS, etc.) Moreover, networks are also divided into AS and areas, which can accommodate this kind of diversity. Therefore, instead of standardizing every metric and constraint in the routing protocols such as OSPF-TE, it is more practical to standardize only part of commonly used items. Equipment vendors and network operators can use their private message fields (private opaque LSAs or Sub-TLVs in OSPF-TE) to distribute the metrics and constraints required for their own algorithms. Regards Hang Liu Tellium -----Original Message----- From: Sudipta Sengupta [mailto:SSengupta@tellium.com] Sent: Friday, June 15, 2001 6:15 PM To: 'Kireeti Kompella'; mpls@UU.NET; wwszeto@math.uwaterloo.ca Subject: RE: constraint-based routing algorithms kireeti, i came across a reference to the expired draft you mentioned. would be interested in having a look. do you have the last revised version ? we (at tellium) have been looking at path computation algorithms in the context of diverse routing of primary and backup paths in optical networks. algorithms like MIRA (lakshman, et al) have recently been proposed for LSP computation in an online model with the objective of minimizing blocking. given the NP-hardness of most constraint-based routing algorithms, there is always scope for improvement. through standardization efforts of protocol packet formats (e.g., for TE extensions to topology/resource discovery protocols like OSPF), the IETF is INDIRECTLY STANDARDIZING the information model that is available as input for path computation. this information model could be inadequate for intelligent computation of traffic engineered paths as algorithmic complexity evolves (dictated by resource utilization and application needs). for example, in the context of optical networks, there is a need for multi-dimensional cost metric (link cost and fiber miles) for computing delay bounded minimum-cost paths. also, information on the backup bandwidth allocated on a link can be used for efficient computation of shared backup LSPs. it seems that there is an increased need for awareness of constraint-based routing algorithms while designing TE extensions to existing protocols. given the generality of some of the OSPF-TE drafts (like the one on link bundling) in use of terminology and applicability to different types of networks, we have had some confusion in interpreting/mapping the fields in the context of optical networks. this might hinder the development of truly "interoperable" implementations. there is probably a need for clear and concrete interpretation of general drafts for specific underlying transport technologies like optical mesh networks. --sudipta __________________________________ Sudipta Sengupta Tellium Optical Networking Systems 2 Crescent Place PO box 901 Oceanport, NJ 07757-0901. Email: sudipta@tellium.com Phone: +1-732-483-2837 -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Friday, June 15, 2001 5:43 PM To: mpls@UU.NET; SSengupta@tellium.com; wwszeto@math.uwaterloo.ca Subject: RE: constraint-based routing algorithms Note that, unlike "regular" SPF, constraint-based routing is used for computing source routes. In regular SPF, if each node were to compute different paths, one could easily have routing loops. In constraint-based routing, each node only needs to ensure that it doesn't compute a looped path. Another point is that the constraint-based routing problem can easily be NP-hard, depending on what constraints are allowed. So, there is much scope for heuristics, etc., which could (would) be considered value-add or even intellectual property. The first point says that there is no great need to standardize the algorithm; the second that there is adequate reason to not standardize it. What should be reasonably uniform is the semantics of some of the more common constraints, so that a SP can have at least a rough idea of how to set the constraints. Daniel Awduche and I had once written a draft on this, but it has expired. It could of course be resurrected, but only if there is adequate interest. Kireeti. From owner-mpls@UU.NET Fri Jun 15 19:58:37 2001 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 TAA01861 for ; Fri, 15 Jun 2001 19:58:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktox27677; Fri, 15 Jun 2001 23:58:37 GMT Received: by mail-control.mail.uu.net id QQktox11322 for mpls-outgoing; Fri, 15 Jun 2001 23:58:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktox11317 for ; Fri, 15 Jun 2001 23:58: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 QQktox28244 for ; Fri, 15 Jun 2001 23:57:06 GMT Received: from magenta.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQktox25244 for ; Fri, 15 Jun 2001 23:57:05 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id f5FNv0J97998; Fri, 15 Jun 2001 16:57:04 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id QAA25406; Fri, 15 Jun 2001 16:57:00 -0700 (PDT) Date: Fri, 15 Jun 2001 16:57:00 -0700 (PDT) From: Kireeti Kompella Message-Id: <200106152357.QAA25406@kummer.juniper.net> To: SSengupta@tellium.com Subject: RE: constraint-based routing algorithms Cc: mpls@UU.NET In-Reply-To: <0CD7D73C734BD411AEE100B0D0220404015450E2@mail1.tellium.com> Sender: owner-mpls@UU.NET Precedence: bulk > i came across a reference to the expired draft you mentioned. would be > interested in having a look. do you have the last revised version ? I've gotten a couple of emails about this; if I get some more, I will re-post it. I'll send you a copy off-line. Kireeti. From owner-mpls@UU.NET Fri Jun 15 20:59:48 2001 Received: from cmr0.ash.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 UAA02436 for ; Fri, 15 Jun 2001 20:59:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktpb04799; Sat, 16 Jun 2001 00:59:27 GMT Received: by mail-control.mail.uu.net id QQktpb05562 for mpls-outgoing; Sat, 16 Jun 2001 00:58:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktpb05554 for ; Sat, 16 Jun 2001 00:58: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 QQktpb04981 for ; Sat, 16 Jun 2001 00:57:58 GMT Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQktpb27148 for ; Sat, 16 Jun 2001 00:57:56 GMT Received: from mrchang (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f5G12YK27330 for ; Sat, 16 Jun 2001 10:02:34 +0900 (KST) Message-ID: <001401c0f5ff$10bf1e00$84131796@sktelecom.com> From: "Ray M. Chang" To: Subject: Pls subscribe one more Date: Sat, 16 Jun 2001 09:55:40 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C0F64A.806B43A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C0F64A.806B43A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Q291bGRuJ3Qgc3Vic2NyaWJlIGJ5IG1haWxpbmcgdG8gbXBscy1yZXF1ZXN0QHV1Lm5ldC4NClNv IGNvdWxkIGFueW9uZSBoZWxwIHVzIHN1YnNjcmliZSB0aGUgZm9sbG93aW5nIGFkZHJlc3M/DQoN CnVjaG9vbkBza3RlbGVjb20uY29tDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciBraW5kbmVzcy4N Cg0KUmF5Lg0K ------=_NextPart_000_0011_01C0F64A.806B43A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI0NjIuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkNvdWxkbid0IHN1 YnNjcmliZSBieSBtYWlsaW5nIHRvIDxBIA0KaHJlZj0ibWFpbHRvOm1wbHMtcmVxdWVzdEB1dS5u ZXQiPm1wbHMtcmVxdWVzdEB1dS5uZXQ8L0E+LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPlNvIGNvdWxkIGFueW9uZSBoZWxwIHVzIHN1YnNjcmliZSB0aGUgZm9sbG93aW5nIA0KYWRk cmVzcz88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48QSANCmhyZWY9Im1haWx0bzp1Y2hvb25Ac2t0ZWxlY29tLmNv bSI+dWNob29uQHNrdGVsZWNvbS5jb208L0E+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzIGEgbG90IGZv ciB5b3VyIGtpbmRuZXNzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlJheS48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwv SFRNTD4NCg== ------=_NextPart_000_0011_01C0F64A.806B43A0-- From owner-mpls@UU.NET Sat Jun 16 01:41:47 2001 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 BAA08949 for ; Sat, 16 Jun 2001 01:41:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktpu19085; Sat, 16 Jun 2001 05:41:18 GMT Received: by mail-control.mail.uu.net id QQktpu05525 for mpls-outgoing; Sat, 16 Jun 2001 05:40:45 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktpu05514 for ; Sat, 16 Jun 2001 05:40: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 QQktpu28818 for ; Sat, 16 Jun 2001 05:38:42 GMT From: Ashwinp@in.huawei.com Received: from huaweimail.in.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQktpu01659 for ; Sat, 16 Jun 2001 05:38:41 GMT Received: by tor-cm1.cisco.com with Internet Mail Service (5.5.2653.19) id ; Sat, 16 Jun 2001 11:11:41 +0500 Message-ID: <751B6DD7A243D511AB9F0002557C5687459226@tor-cm1.cisco.com> To: mpls@UU.NET, mpls-ops@mplsrc.com Subject: RE: constraint-based routing algorithms Date: Sat, 16 Jun 2001 11:11:41 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F62B.35CE6800" 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_01C0F62B.35CE6800 Content-Type: text/plain; charset="iso-8859-1" Dear all I have a related question on the CSPF. The OSPF extension floods the Traffic Engineering data (LSA) on an Area. But if i want to compute a Constraint shortest path to the other Area or to the other AS i have to have the TE database of all the area/ all the AS. So can anyone please tell me how it works for the path computation outside an Area/Autonomus System ? Thanks in advance Ashwin ------_=_NextPart_001_01C0F62B.35CE6800 Content-Type: text/html; charset="iso-8859-1" RE: constraint-based routing algorithms

Dear all

      I have a related question on the CSPF.
      The OSPF extension floods the Traffic Engineering
      data (LSA) on an Area. But if i want to compute a Constraint
      shortest path to the other Area or to the other AS i have
      to have the TE database of all the area/ all the AS. So can
      anyone please tell me how it works for the path computation outside
      an Area/Autonomus System ?

Thanks in advance
Ashwin

------_=_NextPart_001_01C0F62B.35CE6800-- From owner-mpls@UU.NET Sat Jun 16 03:13:17 2001 Received: from cmr0.ash.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 DAA21830 for ; Sat, 16 Jun 2001 03:13:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktqa07510; Sat, 16 Jun 2001 07:12:29 GMT Received: by mail-control.mail.uu.net id QQktqa22003 for mpls-outgoing; Sat, 16 Jun 2001 07:11:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktqa21994 for ; Sat, 16 Jun 2001 07:11:40 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 QQktqa08297 for ; Sat, 16 Jun 2001 07:09:34 GMT Received: from mail.cad.zju.edu.cn by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [210.32.131.2]) id QQktqa06605 for ; Sat, 16 Jun 2001 07:09:33 GMT Received: (qmail 11505 invoked from network); 16 Jun 2001 07:10:59 -0000 Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97) by 210.32.131.2 with SMTP; 16 Jun 2001 07:10:59 -0000 Message-ID: <3B2B0643.878E221D@cad.zju.edu.cn> Date: Sat, 16 Jun 2001 15:09:55 +0800 From: Jing Shen Reply-To: jshen@cad.zju.edu.cn Organization: state key lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: SSengupta@tellium.com, mpls@UU.NET Subject: Re: constraint-based routing algorithms References: <200106152357.QAA25406@kummer.juniper.net> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to got a copy of your draft, would you please do me a favor to send one ? Thanks a lot. James > > i came across a reference to the expired draft you mentioned. would be > > interested in having a look. do you have the last revised version ? > > I've gotten a couple of emails about this; if I get some more, I > will re-post it. > > I'll send you a copy off-line. > > Kireeti. From owner-mpls@UU.NET Sat Jun 16 13:02:23 2001 Received: from cmr1.ash.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 NAA25004 for ; Sat, 16 Jun 2001 13:02:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktro22841; Sat, 16 Jun 2001 17:01:31 GMT Received: by mail-control.mail.uu.net id QQktro08244 for mpls-outgoing; Sat, 16 Jun 2001 17:00:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktro06798 for ; Sat, 16 Jun 2001 17:00:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQktrn22069 for ; Sat, 16 Jun 2001 16:56:50 GMT Received: from mailhost.iitb.ac.in by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [203.199.51.142]) id QQktrn19186 for ; Sat, 16 Jun 2001 16:56:44 GMT Received: (qmail 13889 invoked from network); 16 Jun 2001 16:49:32 -0000 Received: from bhairav.ee.iitb.ernet.in (HELO bhairav.ee.iitb.ac.in) (144.16.100.100) by mailhost.iitb.ac.in with SMTP; 16 Jun 2001 16:49:32 -0000 Received: from vani.ee.iitb.ac.in (director.ee.iitb.ac.in [192.168.100.121]) by bhairav.ee.iitb.ac.in (8.8.8/8.8.8) with ESMTP id WAA18488; Sat, 16 Jun 2001 22:27:28 +0530 (IST) Received: from localhost (gabhijit@localhost) by vani.ee.iitb.ac.in (8.9.3/8.9.3) with ESMTP id WAA13021; Sat, 16 Jun 2001 22:28:50 +0530 X-Authentication-Warning: vani.ee.iitb.ac.in: gabhijit owned process doing -bs Date: Sat, 16 Jun 2001 22:28:50 +0530 (IST) From: Abhijit Gadgil To: Eric Gray cc: , Subject: Re: LMp. 17 in rfc3036. In-Reply-To: <3B2A14AC.C30DDD7F@sandburst.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Eric, Few comments are not quite clear to me. Please see below. >It is not definitely wrong for Ru to send a label mapping to Rd for the >same FEC that Rd has just sent a label mapping to Ru - even though >Ru knows that Rd is the next hop for this FEC. However, in doing so, >it is effectively NOT using ordered control since there is no downstream >label to which it can bind the label it is advertising to Rd. As said before, >it is definitely wrong for Ru to bind the label it receives from Rd to the >label it advertises to Rd. >> Accepted, Ru MUST NOT bind it as u pointed out. >> Of course this is not harmful as far as the normal operation goes. It's >> only unnecessary. Am I missing something? > >It can be useful, as you suggested, in the case where Rd is using DU, >and liberal retention, modes. I don't think it's even useful then because, it will be released by Rd, as soon as it processes the mapping for the corresponding label. At Rd., upon receiving this label. LMp.1 - No LMp.3 - yes LMp.4 - No LMp.8 - Send release for (Label L, FEC F). LMp.33 - Ok Note here LMp.13 or LMp.16 is not reached, so the label won't be retained anyways. The reason why Ru originally sent Label to Rd. was that Rd retains it if configured for Liberal retention. But even in that case, Rd is not retaining it at all. So it's not useful also. If Ru simply does not send it to Rd, it saves on sending one Mapping message and processing one Release message. Rd saves on processing one Mapping and sending one release. (this is just for one FEC) I agree this won't hamper the data traffic, but there will be lot of unnecessary Mapping and Release messages dancing. (This is not as a result of some mis-configuration, but rather a protocol behavior) Is this Correct? -abhijit From owner-mpls@UU.NET Sat Jun 16 21:47:36 2001 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 VAA28063 for ; Sat, 16 Jun 2001 21:47:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktsx01973; Sun, 17 Jun 2001 01:47:00 GMT Received: by mail-control.mail.uu.net id QQktsx11407 for mpls-outgoing; Sun, 17 Jun 2001 01:46:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktsx11379 for ; Sun, 17 Jun 2001 01:46: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 QQktsw17306 for ; Sun, 17 Jun 2001 01:44:12 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQktsw26559 for ; Sun, 17 Jun 2001 01:44:11 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id SAA26362; Sat, 16 Jun 2001 18:43:58 -0700 (PDT) Message-Id: <200106170143.SAA26362@red.juniper.net> To: raszuk@cisco.com cc: Ashwinp@in.huawei.com, mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: constraint-based routing algorithms In-Reply-To: Your message of "Sat, 16 Jun 2001 03:04:37 PDT." <3B2B2F35.B11199B4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <87239.992742238.1@juniper.net> Date: Sat, 16 Jun 2001 18:43:58 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Robert, > To give you a very short answer you are correct that scope of flooding > is limited to given area/level. Therefor to establish the inter-area LSP > your headends will not have enough information to compute full end to > end ERO. There are main two ways to solve it: > > Online: By means of loose ERO (you indicate via hops or areas) and relay > on the ABRs to compute it's own part of the ERO. > > Offline: By means of offline server running CSPF which would be > receiving information about TE topology from multiple areas. > > There is of course a number of issues with multiarea TEs so please wait > for the soon to be published ID for more in depth clarification. While waiting for "the soon to be published ID", one may also look at draft-kompella-mpls-multiarea-te-01.txt for some of the possible solutions. Yakov. From owner-mpls@UU.NET Sun Jun 17 06:37:15 2001 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 GAA08869 for ; Sun, 17 Jun 2001 06:37:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktug00984; Sun, 17 Jun 2001 10:36:44 GMT Received: by mail-control.mail.uu.net id QQktug18775 for mpls-outgoing; Sun, 17 Jun 2001 10:36:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktug18712 for ; Sun, 17 Jun 2001 10:35:58 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 QQktug12333 for ; Sun, 17 Jun 2001 10:35:38 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQktug29170 for ; Sun, 17 Jun 2001 10:35:38 GMT Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f5HAY6i22804; Sun, 17 Jun 2001 12:34:06 +0200 (MET DST) Received: from alcatel.be ([138.203.253.195]) by bemail05.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256A6E.003A060C; Sun, 17 Jun 2001 12:33:47 +0200 Message-ID: <3B2C880F.3A3F2FEA@alcatel.be> Date: Sun, 17 Jun 2001 12:35:59 +0200 From: Dimitri Papadimitriou Organization: Alcatel Bell - IPO NSG X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: raszuk@cisco.com CC: Yakov Rekhter , Ashwinp@in.huawei.com, mpls@UU.NET, mpls-ops@mplsrc.com Subject: Re: constraint-based routing algorithms References: <200106170143.SAA26362@red.juniper.net> Content-Type: multipart/mixed; boundary="------------F2D62B53FEC9ECBC6474C706" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------F2D62B53FEC9ECBC6474C706 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert, To complete somewhat the description of available ID given by Yakov, you could also take a look on the following documents: 1) The draft: draft-venkatachalam-ospf-traffic-01.txt This document describes the OSPF "Traffic Engineering Summary LSA" and its support to enable traffic engineering across area boundaries. This document describes the traffic engineering (TE) summary LSA that will be originated by the Area Border Router (ABR) into an area. This summary LSA is a type-10 opaque LSA, that will be flooded within the area. The functionality of the TE summary LSA is similar to that of the summary LSA of standard OSPF, but in addition it carries the traffic engineering metrics to the remote destination (IP network or ASBR). 2) The draft: draft-venkatachalam-interarea-mpls-te-01.txt A Framework for the LSP Setup Across IGP Areas for MPLS Traffic Engineering This draft propose an architecture for the inter-area LSP setup based on criteria (combination of constraints). It derives architectural requirements for the routing protocols, signaling protocols and the MIBs to support such an idea. Demonstration is made that such a mechanism will reduce the crankback during LSP setup. A possible outline of the modifications to the CSPF algorithm and examples are presented. The companion document (see below) elaborates on the extensions required for such architecture. The companion draft is: draft-dharanikota-interarea-mpls-te-ext-01.txt This document proposes the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. The companion document (see above) provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document. Regards, Dimitri. Yakov Rekhter wrote: > > Robert, > > > To give you a very short answer you are correct that scope of flooding > > is limited to given area/level. Therefor to establish the inter-area LSP > > your headends will not have enough information to compute full end to > > end ERO. There are main two ways to solve it: > > > > Online: By means of loose ERO (you indicate via hops or areas) and relay > > on the ABRs to compute it's own part of the ERO. > > > > Offline: By means of offline server running CSPF which would be > > receiving information about TE topology from multiple areas. > > > > There is of course a number of issues with multiarea TEs so please wait > > for the soon to be published ID for more in depth clarification. > > While waiting for "the soon to be published ID", one may also look > at draft-kompella-mpls-multiarea-te-01.txt for some of the > possible solutions. > > Yakov. > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml --------------F2D62B53FEC9ECBC6474C706 Content-Type: text/x-vcard; charset=us-ascii; name="dimitri.papadimitriou.vcf" Content-Description: Card for Dimitri Papadimitriou Content-Disposition: attachment; filename="dimitri.papadimitriou.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Dimitri;Papadimitriou Dimitri tel;home:+32 2 3434361 tel;work:+32 3 2408491 x-mozilla-html:FALSE url:http://www.alcatel.com org:Alcatel Bell;IPO NSG - Antwerpen version:2.1 email;internet:dimitri.papadimitriou@alcatel.be title:Optical Networking R&S - Senior Engineer adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM fn:Papadimitriou Dimitri end:vcard --------------F2D62B53FEC9ECBC6474C706-- From owner-mpls@UU.NET Mon Jun 18 08:56:46 2001 Received: from cmr0.ash.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 IAA05917 for ; Mon, 18 Jun 2001 08:56:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktyh28673; Mon, 18 Jun 2001 12:53:47 GMT Received: by mail-control.mail.uu.net id QQktyh21699 for mpls-outgoing; Mon, 18 Jun 2001 12:53:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktyh21688 for ; Mon, 18 Jun 2001 12:52:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQktyh17592 for ; Mon, 18 Jun 2001 12:51:48 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQktyh25265 for ; Mon, 18 Jun 2001 12:51:47 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 18 Jun 2001 18:29:06 +0530 Received: from srikn (srikn.future.futsoft.com [10.20.6.48]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f5ICpRh30007; Mon, 18 Jun 2001 18:21:28 +0530 Reply-To: From: "Srikanth" To: Subject: Conflict in the Type values of Diff-serv TLV and Generalized Label Request Date: Mon, 18 Jun 2001 18:24:34 +0530 Message-Id: <000401c0f7f5$d36a9680$3006140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, In draft-ietf-mpls-diff-ext-09.txt, section 6.1 gives the type value of Diff-Serv TLV as 0x901. Also In draft-ietf-mpls-generalized-cr-ldp-03.txt, section 2.1 gives the type value of Generalized Label Request as 0x0901. This will be a problem when an implementation is going to provide Diff-serv (using Ldp) and Generalized Cr-Ldp together. Regards, Srikanth Narayanan. From owner-mpls@UU.NET Mon Jun 18 09:38:18 2001 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 JAA07358 for ; Mon, 18 Jun 2001 09:38:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktyk24343; Mon, 18 Jun 2001 13:30:04 GMT Received: by mail-control.mail.uu.net id QQktyj14564 for mpls-outgoing; Mon, 18 Jun 2001 13:29:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktyj14550 for ; Mon, 18 Jun 2001 13:29:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQktyj21690 for ; Mon, 18 Jun 2001 13:29:06 GMT Received: from www1.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: www1.tropicnetworks.com [209.87.233.11]) id QQktyj00066 for ; Mon, 18 Jun 2001 13:29:05 GMT Received: from mail.tropicnetworks.com (gw.tropicnetworks.com [209.87.233.9]) by www1.tropicnetworks.com (8.10.1/8.10.1) with ESMTP id f5IDWjL28299 for ; Mon, 18 Jun 2001 09:32:45 -0400 (EDT) Received: from cr437225a ([10.1.2.190]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with SMTP id AAAFFF for ; Mon, 18 Jun 2001 09:29:14 -0400 From: "Sudhakar Ganti" To: Subject: RE: constraint-based routing algorithms Date: Mon, 18 Jun 2001 09:26:16 -0400 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: <3B2C880F.3A3F2FEA@alcatel.be> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit For multi-area TE, also look at the following drafts: 1)draft-ash-ccamp-multi-area-te-reqmts-00.txt 2)draft-lee-mpls-te-exchange-00.txt 3)draft-lee-mpls-path-request-00.txt -Sudhakar > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Dimitri > Papadimitriou > Sent: Sunday, June 17, 2001 6:36 AM > To: raszuk@cisco.com > Cc: Yakov Rekhter; Ashwinp@in.huawei.com; mpls@UU.NET; > mpls-ops@mplsrc.com > Subject: Re: constraint-based routing algorithms > > > Robert, > > To complete somewhat the description of available ID given by Yakov, > you could also take a look on the following documents: > > 1) The draft: draft-venkatachalam-ospf-traffic-01.txt > > This document describes the OSPF "Traffic Engineering Summary LSA" > and its support to enable traffic engineering across area boundaries. > This document describes the traffic engineering (TE) summary LSA that > will be originated by the Area Border Router (ABR) into an area. This > summary LSA is a type-10 opaque LSA, that will be flooded within the > area. The functionality of the TE summary LSA is similar to that of > the summary LSA of standard OSPF, but in addition it carries the > traffic engineering metrics to the remote destination (IP network or > ASBR). > > 2) The draft: draft-venkatachalam-interarea-mpls-te-01.txt > > A Framework for the LSP Setup Across IGP Areas for MPLS Traffic > Engineering This draft propose an architecture for the inter-area LSP > setup based on criteria (combination of constraints). It derives > architectural requirements for the routing protocols, signaling > protocols and the MIBs to support such an idea. Demonstration is made > that such a mechanism will reduce the crankback during LSP setup. A > possible outline of the modifications to the CSPF algorithm and > examples are presented. The companion document (see below) elaborates > on the extensions required for such architecture. > > The companion draft is: > draft-dharanikota-interarea-mpls-te-ext-01.txt > This document proposes the extensions required to the routing protocols, > signaling protocols, and the MIB to support the idea of inter-area LSPs. > The companion document (see above) provides the architectural > requirements > for such a concept. This document also provides the signaling extensions > to support the crankback as defined in the architecture document. > > Regards, > Dimitri. > > > Yakov Rekhter wrote: > > > > Robert, > > > > > To give you a very short answer you are correct that scope of flooding > > > is limited to given area/level. Therefor to establish the > inter-area LSP > > > your headends will not have enough information to compute full end to > > > end ERO. There are main two ways to solve it: > > > > > > Online: By means of loose ERO (you indicate via hops or > areas) and relay > > > on the ABRs to compute it's own part of the ERO. > > > > > > Offline: By means of offline server running CSPF which would be > > > receiving information about TE topology from multiple areas. > > > > > > There is of course a number of issues with multiarea TEs so > please wait > > > for the soon to be published ID for more in depth clarification. > > > > While waiting for "the soon to be published ID", one may also look > > at draft-kompella-mpls-multiarea-te-01.txt for some of the > > possible solutions. > > > > Yakov. > > > > ------- > > 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 Mon Jun 18 10:07:59 2001 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 KAA08305 for ; Mon, 18 Jun 2001 10:07:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktym01841; Mon, 18 Jun 2001 14:05:39 GMT Received: by mail-control.mail.uu.net id QQktym02685 for mpls-outgoing; Mon, 18 Jun 2001 14:05:05 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktym00868 for ; Mon, 18 Jun 2001 14:04:50 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 QQktym15358 for ; Mon, 18 Jun 2001 14:04:33 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktym04389 for ; Mon, 18 Jun 2001 14:04:33 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 8E2B794006; Mon, 18 Jun 2001 10:04:20 -0400 (EDT) Message-ID: <3B2E0A64.5E5E0028@sandburst.com> Date: Mon, 18 Jun 2001 10:04:20 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Abhijit Gadgil Cc: mpls@UU.NET, Bob Thomas Subject: Re: LMp. 17 in rfc3036. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Abhijit, Please see response below. For the record, though, it turns out that sending a Label Mapping to message source was included in the current specified procedure in an attempt to cover what was felt at the time to be a hole (see the Note referenced previously for details). As you have already pointed out, this hole would mosty likely never occur in properly functioning LSRs (a subsequent route change that introduces a requirement for the label not previously distributed would also result in a new label distribution). However, as may be inferred from your earlier observation (the PV may result in loop-detection and release - if PV is enabled), strict following of the currently specified procedure will do no harm. In other words, it is not necessary to distribute a label to MsgSource as part of the procedure for handling a label distributed from MsgSource - but it will do no harm if an implementation does so. Consequently, it does not seem necessary to take any sort of immediate action WRT this issue and RFC 3036. Does this clear up the remaining muddy areas? -- Eric Gray You wrote: > Eric, > > Few comments are not quite clear to me. Please see below. > > >It is not definitely wrong for Ru to send a label mapping to Rd for the > >same FEC that Rd has just sent a label mapping to Ru - even though > >Ru knows that Rd is the next hop for this FEC. However, in doing so, > >it is effectively NOT using ordered control since there is no downstream > >label to which it can bind the label it is advertising to Rd. As said before, > >it is definitely wrong for Ru to bind the label it receives from Rd to the > >label it advertises to Rd. > >> > > Accepted, Ru MUST NOT bind it as u pointed out. > > >> Of course this is not harmful as far as the normal operation goes. It's > >> only unnecessary. Am I missing something? > > > >It can be useful, as you suggested, in the case where Rd is using DU, > >and liberal retention, modes. > > I don't think it's even useful then because, it will be released by Rd, > as soon as it processes the mapping for the corresponding label. > > At Rd., upon receiving this label. > LMp.1 - No > LMp.3 - yes > LMp.4 - No > LMp.8 - Send release for (Label L, FEC F). > LMp.33 - Ok > > Note here LMp.13 or LMp.16 is not reached, so the label won't be retained > anyways. This was the case when Ru included a Path Vector that includes Rd. As pointed out already, this is strange behavior - since Ru cannot consider the label it receives from Rd and the label is sends to Rd to be part of the same LSP. In the case where Ru sends a label to Rd - coincidental to the label it got from Rd and for the same FEC - but either does not include a Path Vector or includes a Path Vector with only itself included (as would be the case if it were distributing this label independently), then Rd would be able to retain this label. This would be useful because Rd could immediately start using this label in a topology change scenario in which Ru suddenly becomes the next hop for this FEC relative to Rd. Note that I am using the designations Ru and Rd in the context of prior discussion. In the scenario described above, these designations are unfortunately chosen. > > > The reason why Ru originally sent Label to Rd. was that Rd retains it > if configured for Liberal retention. But even in that case, Rd is not > retaining it at all. So it's not useful also. > > If Ru simply does not send it to Rd, it saves on sending one Mapping > message and processing one Release message. Rd saves on processing one > Mapping and sending one release. (this is just for one FEC) > > I agree this won't hamper the data traffic, but there will be lot of > unnecessary Mapping and Release messages dancing. (This is not as a result > of some mis-configuration, but rather a protocol behavior) > > Is this Correct? > > -abhijit From owner-mpls@UU.NET Mon Jun 18 10:42:28 2001 Received: from cmr1.ash.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 KAA09058 for ; Mon, 18 Jun 2001 10:42:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktyo04445; Mon, 18 Jun 2001 14:40:16 GMT Received: by mail-control.mail.uu.net id QQktyo10744 for mpls-outgoing; Mon, 18 Jun 2001 14:39:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktyo10735 for ; Mon, 18 Jun 2001 14:39:39 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 QQktyo23515 for ; Mon, 18 Jun 2001 14:37:08 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktyo28621 for ; Mon, 18 Jun 2001 14:37:08 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 5C3F39400A; Mon, 18 Jun 2001 10:37:07 -0400 (EDT) Message-ID: <3B2E1213.40953170@sandburst.com> Date: Mon, 18 Jun 2001 10:37:07 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: srikn@future.futsoft.com Cc: mpls@UU.NET Subject: Re: Conflict in the Type values of Diff-serv TLV and Generalized Label Request References: <000401c0f7f5$d36a9680$3006140a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Srikanth, Nice catch. Odd that there does not appear to be a single common author for both drafts, in spite of the fact that there are so many. Any of the authors from either draft care to say what the plan of action is? -- Eric Gray You wrote: > Hi all, > > In draft-ietf-mpls-diff-ext-09.txt, section 6.1 gives the type value of > Diff-Serv TLV as 0x901. > > Also In draft-ietf-mpls-generalized-cr-ldp-03.txt, section 2.1 gives the > type value of Generalized Label Request as 0x0901. > > This will be a problem when an implementation is going to provide Diff-serv > (using Ldp) and Generalized Cr-Ldp together. > > Regards, > Srikanth Narayanan. From owner-mpls@UU.NET Mon Jun 18 15:04:14 2001 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 PAA17016 for ; Mon, 18 Jun 2001 15:04:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktzg22395; Mon, 18 Jun 2001 19:01:06 GMT Received: by mail-control.mail.uu.net id QQktzg28628 for mpls-outgoing; Mon, 18 Jun 2001 19:00:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktzg27910 for ; Mon, 18 Jun 2001 19:00:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktzf15657 for ; Mon, 18 Jun 2001 18:56:46 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQktzf09398 for ; Mon, 18 Jun 2001 18:56:44 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5IIumx03527 for ; Mon, 18 Jun 2001 11:56:49 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA00654 for mpls@uu.net; Mon, 18 Jun 2001 14:56:41 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktok25337 for ; Fri, 15 Jun 2001 20:43: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 QQktok14637 for ; Fri, 15 Jun 2001 20:41:59 GMT Received: from carrier1.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gblon1s30.carrier1.com [212.4.193.97]) id QQktok29550 for ; Fri, 15 Jun 2001 20:41:58 GMT Received: by gblon1s30.carrier1.com via suspension id <119044>; Fri, 15 Jun 2001 21:41:50 +0100 Received: by gblon1s30.carrier1.com via suspension id <119234>; Fri, 15 Jun 2001 16:44:38 +0100 Received: by gblon1s30.carrier1.com via suspension id <119056>; Fri, 15 Jun 2001 03:43:42 +0100 Received: by gblon1s30.carrier1.com via suspension id <119073>; Thu, 14 Jun 2001 22:35:34 +0100 Received: from gblon1s07.carrier1.com ([10.1.9.21]) by gblon1s30.carrier1.com with ESMTP id <119187>; Thu, 14 Jun 2001 14:47:49 +0100 Received: by GBLON1S07 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 14:47:49 +0100 Message-ID: <83189BAB0F57D411A1C400508B6AADBD0340872E@GBLON1S07> From: Ruyter Hill To: "'bhupeshb@in.huawei.com'" Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: Tag-switching -vs- MPLS !!! Date: Thu, 14 Jun 2001 14:47:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F4D8.98AEF510" 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_01C0F4D8.98AEF510 Content-Type: text/plain; charset="iso-8859-1" Hi To further clarify this Tag switching was the CISCO proprietary predecessor to MPLS You may find in some versions of IOS, commands which still use the term "tag switch" these are effectively MPLS commands one must be careful however as tag switching used TDP ( Cisco's version of LDP ) so if you have different IOS versions across your network you may find things don't work as the two protocols are very slightly different Perhaps Robert or someone can say if there is backwards compatibility for TDP in the later versions of IOS ? So in summary TDP and MPLS are really the same thing when dealing with CISCO equipment Kind Regards Hill Ruyter IP Solutions Specialist Carrier1, London -----Original Message----- From: bhupeshb@in.huawei.com [mailto:bhupeshb@in.huawei.com] Sent: 13 June 2001 08:19 To: Unlisted-recipients Cc: mpls-ops@mplsrc.com; mpls@uu.net Subject: RE: Tag-switching -vs- MPLS !!! Importance: High tag switching is the general term used to notify a methodology MPLS uses that methodology ...of tag switching. dont confuse the terms technology and methodology ... MPLs is a technology which uses a kind of methodology of tag - switching which might be in use by some other protocols or technologies too.... regards bhupesh -----Original Message----- From: Sivaramakrishna Iyer Krishnan [ mailto:krishnan@research.bell-labs.com ] Sent: Monday, June 11, 2001 11:44 PM To: mpls-ops@mplsrc.com Subject: Tag-switching -vs- MPLS !!! Hi All, I am not sure what is the difference between tag-switching and MPLS ????????.... Also, are all mpls commands backward compatible to tag-switching ???... Thanks, Krishnan. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------_=_NextPart_001_01C0F4D8.98AEF510 Content-Type: text/html; charset="iso-8859-1" RE: Tag-switching -vs- MPLS !!!
Hi
 
To further clarify this
 
Tag switching was the CISCO proprietary predecessor to MPLS
 
You may find in some versions of IOS, commands which still use the term "tag switch" 
these are effectively MPLS commands 
 
one must be careful however as tag switching used TDP  ( Cisco's version of LDP ) 
so if you have different IOS versions across your network you may find things don't work as the two
protocols are very slightly different
 
Perhaps Robert or someone can say if there is backwards compatibility for TDP in the later versions of IOS ?
 
 
So in summary TDP and MPLS are really the same thing when dealing with CISCO equipment
 
 
Kind Regards
 
Hill Ruyter
IP Solutions Specialist
Carrier1, London
 
 
-----Original Message-----
From: bhupeshb@in.huawei.com [mailto:bhupeshb@in.huawei.com]
Sent: 13 June 2001 08:19
To: Unlisted-recipients
Cc: mpls-ops@mplsrc.com; mpls@uu.net
Subject: RE: Tag-switching -vs- MPLS !!!
Importance: High

tag switching is the general term used to notify a methodology

MPLS uses that methodology ...of tag switching.
dont confuse the terms technology and methodology ...

MPLs is a technology which uses a kind of methodology of tag - switching which might be in use by some other protocols or technologies too....

regards
bhupesh


-----Original Message-----
From: Sivaramakrishna Iyer Krishnan
[mailto:krishnan@research.bell-labs.com]
Sent: Monday, June 11, 2001 11:44 PM
To: mpls-ops@mplsrc.com
Subject: Tag-switching -vs- MPLS !!!



Hi All,

I am not sure what is the difference between tag-switching and MPLS
????????....

Also, are all mpls commands backward compatible to tag-switching ???...

Thanks,
Krishnan.

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

------_=_NextPart_001_01C0F4D8.98AEF510-- From owner-mpls@UU.NET Mon Jun 18 16:47:06 2001 Received: from cmr0.ash.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 QAA20660 for ; Mon, 18 Jun 2001 16:47:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktzn13471; Mon, 18 Jun 2001 20:46:31 GMT Received: by mail-control.mail.uu.net id QQktzn18358 for mpls-outgoing; Mon, 18 Jun 2001 20:45:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktzn18347 for ; Mon, 18 Jun 2001 20:45:49 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 QQktzn10592 for ; Mon, 18 Jun 2001 20:45:02 GMT Received: from beta.dmz-us.st.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beta.dmz-us.st.com [167.4.1.35]) id QQktzn11228 for ; Mon, 18 Jun 2001 20:45:01 GMT Received: from zeta.dmz-us.st.com (zeta.dmz-us.st.com [167.4.80.115]) by beta.dmz-us.st.com (STMicroelectronics) with SMTP id A271348E5 for ; Mon, 18 Jun 2001 20:45:01 +0000 (GMT) Received: by zeta.dmz-us.st.com (STMicroelectronics, from userid 0) id DD63648D9; Mon, 18 Jun 2001 20:45:02 +0000 (GMT) Received: from usx011.crn.st.com (localhost [127.0.0.1]) by zeta.dmz-us.st.com (STMicroelectronics) with ESMTP id 9CACD1843 for ; Mon, 18 Jun 2001 20:45:02 +0000 (GMT) Received: from st.com (odc22.ott.st.com [167.4.248.49]) by usx011.crn.st.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id PAA25973; Mon, 18 Jun 2001 15:44:48 -0500 (CDT) Message-ID: <3B2E64E6.12634D9B@st.com> Date: Mon, 18 Jun 2001 16:30:30 -0400 From: Rahul Bhushan Organization: STMicroelectronics Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Tag-switching -vs- MPLS !!! References: <83189BAB0F57D411A1C400508B6AADBD0340872E@GBLON1S07> Content-Type: multipart/mixed; boundary="------------31ED96AC5E88AA6FDEF1C7C9" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------31ED96AC5E88AA6FDEF1C7C9 Content-Type: multipart/alternative; boundary="------------424D9075AEECF72A0229B550" --------------424D9075AEECF72A0229B550 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, You can check out Rekhtor/Davie/Doolan's book : Switching in IP-Networks It gives a good background on Toshiba's CSR, Ipsilon's IP-Switching, IBM's ARIS and Cisco's Tag-Switching architectures. All these architectures have evolved in some parts into MPLS. URL to the book (Price in CDN $): http://chapters.indigo.ca/books/details/default.asp?mscssid=0Q482TPG4VJ08P5RMF66W8RXJS9LB69E&WSID=1606023A308A1E0D41A3A4CDB2DE767BB6DE2418&ISBN=1558605053 > > -----Original Message----- > From: Sivaramakrishna Iyer Krishnan > [ mailto:krishnan@research.bell-labs.com > ] > Sent: Monday, June 11, 2001 11:44 PM > To: mpls-ops@mplsrc.com > Subject: Tag-switching -vs- MPLS !!! > > > > Hi All, > > I am not sure what is the difference between tag-switching and MPLS > ????????.... > > Also, are all mpls commands backward compatible to tag-switching > ???... > > Thanks, > Krishnan. > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > > > > -----Original Message----- > From: Sivaramakrishna Iyer Krishnan > [mailto:krishnan@research.bell-labs.com] > Sent: Monday, June 11, 2001 11:44 PM > To: mpls-ops@mplsrc.com > Subject: Tag-switching -vs- MPLS !!! > > > Hi All, > > I am not sure what is the difference between tag-switching > and MPLS > ????????.... > > Also, are all mpls commands backward compatible to > tag-switching ???... > > Thanks, > Krishnan. > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > --------------424D9075AEECF72A0229B550 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

    You can check out Rekhtor/Davie/Doolan's book :

Switching in IP-Networks

It gives a good background on Toshiba's CSR,
Ipsilon's IP-Switching, IBM's ARIS and Cisco's
Tag-Switching architectures.

All these architectures have evolved in some
parts into MPLS.

URL to the book (Price in CDN $):
http://chapters.indigo.ca/books/details/default.asp?mscssid=0Q482TPG4VJ08P5RMF66W8RXJS9LB69E&WSID=1606023A308A1E0D41A3A4CDB2DE767BB6DE2418&ISBN=1558605053 


-----Original Message-----  
From: Sivaramakrishna Iyer Krishnan  
[ mailto:krishnan@research.bell-labs.com
<mailto:krishnan@research.bell-labs.com> ]  
Sent: Monday, June 11, 2001 11:44 PM  
To: mpls-ops@mplsrc.com  
Subject: Tag-switching -vs- MPLS !!!  



Hi All,  

I am not sure what is the difference between tag-switching and MPLS  
????????....  

Also, are all mpls commands backward compatible to tag-switching ???...  

Thanks,  
Krishnan.  

-------  
The MPLS-OPS Mailing List  
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
<http://www.mplsrc.com/mplsops.shtml>   
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
<http://www.mplsrc.com/mpls-ops_archive.shtml>   
 
-----Original Message-----
From: Sivaramakrishna Iyer Krishnan
[mailto:krishnan@research.bell-labs.com]
Sent: Monday, June 11, 2001 11:44 PM
To: mpls-ops@mplsrc.com
Subject: Tag-switching -vs- MPLS !!!
 

Hi All,

I am not sure what is the difference between tag-switching and MPLS
????????....

Also, are all mpls commands backward compatible to tag-switching ???...

Thanks,
Krishnan.

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

--------------424D9075AEECF72A0229B550-- --------------31ED96AC5E88AA6FDEF1C7C9 Content-Type: text/x-vcard; charset=us-ascii; name="Rahul.Bhushan.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rahul Bhushan Content-Disposition: attachment; filename="Rahul.Bhushan.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Bhushan;Rahul tel;fax:(613)768-9025 tel;work:(613)768-9058 x-mozilla-html:FALSE org:STMicroelectronics Inc.;Ottawa Design Centre adr:;;;Nepean;ON;;Canada version:2.1 email;internet:rahul.bhushan@st.com title:IC Design Engineer x-mozilla-cpt:;11248 fn:Rahul Bhushan end:vcard --------------31ED96AC5E88AA6FDEF1C7C9-- From owner-mpls@UU.NET Mon Jun 18 17:51:27 2001 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 RAA22018 for ; Mon, 18 Jun 2001 17:51:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktzr28945; Mon, 18 Jun 2001 21:50:35 GMT Received: by mail-control.mail.uu.net id QQktzr15509 for mpls-outgoing; Mon, 18 Jun 2001 21:49:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktzr15458 for ; Mon, 18 Jun 2001 21:49:03 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 QQktzr13199 for ; Mon, 18 Jun 2001 21:47:56 GMT Received: from calliope1.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10]) id QQktzr01330 for ; Mon, 18 Jun 2001 21:47:55 GMT Received: from fmsmsx27.FM.INTEL.COM (fmsmsx27.fm.intel.com [132.233.42.27]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with ESMTP id VAA01351 for ; Mon, 18 Jun 2001 21:47:55 GMT Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 14:47:53 -0700 Message-ID: From: "Bakshi, Sanjay" To: mpls@UU.NET Cc: "Sharma, Prem" Subject: MPLS over POS Date: Mon, 18 Jun 2001 14:47:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F840.521A8900" 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_01C0F840.521A8900 Content-Type: text/plain; charset="iso-8859-1" Hi, Where can i find information on MPLS over POS? Is it an extention of IP over POS using PPP encapsulation with MPLS shim between PPP header and IP header? Please let me know. thanks, --sanjay ------_=_NextPart_001_01C0F840.521A8900 Content-Type: text/html; charset="iso-8859-1" RE: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt"
Hi,
Where can i find information on MPLS over POS?
Is it an extention of IP over POS using PPP encapsulation with MPLS shim between PPP header and IP header?
Please let me know.
thanks,
--sanjay
 

 

------_=_NextPart_001_01C0F840.521A8900-- From owner-mpls@UU.NET Mon Jun 18 18:00:59 2001 Received: from cmr0.ash.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 SAA22194 for ; Mon, 18 Jun 2001 18:00:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktzs21977; Mon, 18 Jun 2001 22:00:20 GMT Received: by mail-control.mail.uu.net id QQktzr16563 for mpls-outgoing; Mon, 18 Jun 2001 21:59:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktzr16546 for ; Mon, 18 Jun 2001 21:59:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQktzr28439 for ; Mon, 18 Jun 2001 21:58:45 GMT Received: from mail.krioukov.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cj114416-a.reston1.va.home.com [24.15.191.36]) id QQktzr09495 for ; Mon, 18 Jun 2001 21:58:45 GMT Received: from DIMA1 ([47.184.55.188]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id RAA02419; Mon, 18 Jun 2001 17:58:38 -0400 From: "Dmitri Krioukov" To: "Sudipta Sengupta" , "'Kireeti Kompella'" Cc: Subject: RE: constraint-based routing algorithms Date: Mon, 18 Jun 2001 17:58:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <0CD7D73C734BD411AEE100B0D0220404015450E2@mail1.tellium.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I also think that the draft was really useful and should be resurrected. Its original version is still available at http://www.watersprings.org/links/mlr/id/draft-kompella-te-pathcomp-00.txt I'd suggest to add more references to incremental Dijkstra and fill in the "NPC" reference (Section 5) that currently leads nowhere. -- dima. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Sudipta > Sengupta > Sent: Friday, June 15, 2001 6:15 PM > To: 'Kireeti Kompella'; mpls@UU.NET; wwszeto@math.uwaterloo.ca > Subject: RE: constraint-based routing algorithms > > > kireeti, > > i came across a reference to the expired draft you mentioned. would be > interested in having a look. do you have the last revised version ? > > we (at tellium) have been looking at path computation algorithms in the > context of diverse routing of primary and backup paths in optical > networks. > algorithms like MIRA (lakshman, et al) have recently been proposed for LSP > computation in an online model with the objective of minimizing blocking. > > given the NP-hardness of most constraint-based routing > algorithms, there is > always scope for improvement. through standardization efforts of protocol > packet formats (e.g., for TE extensions to topology/resource discovery > protocols like OSPF), the IETF is INDIRECTLY STANDARDIZING the information > model that is available as input for path computation. this information > model could be inadequate for intelligent computation of traffic > engineered > paths as algorithmic complexity evolves (dictated by resource utilization > and application needs). for example, in the context of optical networks, > there is a need for multi-dimensional cost metric (link cost and fiber > miles) for computing delay bounded minimum-cost paths. also, > information on > the backup bandwidth allocated on a link can be used for efficient > computation of shared backup LSPs. it seems that there is an > increased need > for awareness of constraint-based routing algorithms while designing TE > extensions to existing protocols. > > given the generality of some of the OSPF-TE drafts (like the one on link > bundling) in use of terminology and applicability to different types of > networks, we have had some confusion in interpreting/mapping the fields in > the context of optical networks. this might hinder the > development of truly > "interoperable" implementations. there is probably a need for clear and > concrete interpretation of general drafts for specific underlying > transport > technologies like optical mesh networks. > > --sudipta > > __________________________________ > Sudipta Sengupta > Tellium Optical Networking Systems > 2 Crescent Place PO box 901 > Oceanport, NJ 07757-0901. > Email: sudipta@tellium.com > Phone: +1-732-483-2837 > > > > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, June 15, 2001 5:43 PM > To: mpls@UU.NET; SSengupta@tellium.com; wwszeto@math.uwaterloo.ca > Subject: RE: constraint-based routing algorithms > > > Note that, unlike "regular" SPF, constraint-based routing is used > for computing source routes. In regular SPF, if each node were to > compute different paths, one could easily have routing loops. In > constraint-based routing, each node only needs to ensure that it > doesn't compute a looped path. > > Another point is that the constraint-based routing problem can > easily be NP-hard, depending on what constraints are allowed. So, > there is much scope for heuristics, etc., which could (would) be > considered value-add or even intellectual property. > > The first point says that there is no great need to standardize > the algorithm; the second that there is adequate reason to not > standardize it. > > What should be reasonably uniform is the semantics of some of the > more common constraints, so that a SP can have at least a rough > idea of how to set the constraints. Daniel Awduche and I had > once written a draft on this, but it has expired. It could of > course be resurrected, but only if there is adequate interest. > > Kireeti. From owner-mpls@UU.NET Mon Jun 18 18:05:13 2001 Received: from cmr1.ash.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 SAA22269 for ; Mon, 18 Jun 2001 18:05:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktzs00703; Mon, 18 Jun 2001 22:04:19 GMT Received: by mail-control.mail.uu.net id QQktzs24378 for mpls-outgoing; Mon, 18 Jun 2001 22:03:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktzs23451 for ; Mon, 18 Jun 2001 22:03: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 QQktzs13138 for ; Mon, 18 Jun 2001 22:03:15 GMT Received: from c0mailgw11.prontomail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgw.prontomail.com [216.163.180.10]) id QQktzs27029 for ; Mon, 18 Jun 2001 22:03:15 GMT Received: by c0mailgw11.prontomail.com (NPlex 5.1.050) id 3B2B2FD600056923; Mon, 18 Jun 2001 14:56:37 -0700 Received: from 148.75.48.66 by SmtpServer for ; Mon, 18 Jun 2001 21:56:05 +0000 Reply-To: From: "Dennis Hartmann" To: "Rahul Bhushan" , Subject: RE: Tag-switching -vs- MPLS !!! Date: Mon, 18 Jun 2001 18:03:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C0F820.F46B0470" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3B2E64E6.12634D9B@st.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C0F820.F46B0470 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C0F820.F46E11B0" ------=_NextPart_001_0005_01C0F820.F46E11B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The biggest difference is the fact that Tag-Switching uses TDP, while standardized MPLS uses LDP as a distribution protocol. TDP is a subset of LDP. TDP uses TCP and UDP ports 711, while LDP uses TCP and UDP ports 646. LDP has added functionality that is not available in TDP (MD5 authentication, etc.), and it is an IETF standard (TDP is Cisco proprietary). The MLSTE class has a whole chapter devoted to TDP and LDP, as well as distribution protocol migration. Some Cisco IOS images do not support LDP. Use the IOS Feature Navigator to get information on what features are supported for your particular hardware. I am currently working with 12.2(2T) which is the first 3640 image to support LDP. Anyone know of any caveats for this code (Service Provider Feature Set) with the 3640? Sincerely, Dennis J. Hartmann White Pine Consulting dennisjhartmann@hotmail.com (914) 980-0316 (cellular) (845) 896-4777 (home) AOL IM: dennisjhartmann -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Rahul Bhushan Sent: Monday, June 18, 2001 4:31 PM To: mpls@UU.NET Subject: Re: Tag-switching -vs- MPLS !!! Hi, You can check out Rekhtor/Davie/Doolan's book : Switching in IP-Networks It gives a good background on Toshiba's CSR, Ipsilon's IP-Switching, IBM's ARIS and Cisco's Tag-Switching architectures. All these architectures have evolved in some parts into MPLS. URL to the book (Price in CDN $): http://chapters.indigo.ca/books/details/default.asp?mscssid=0Q482TPG4VJ08P5R MF66W8RXJS9LB69E&WSID=1606023A308A1E0D41A3A4CDB2DE767BB6DE2418&ISBN=15586050 53 -----Original Message----- From: Sivaramakrishna Iyer Krishnan [ mailto:krishnan@research.bell-labs.com ] Sent: Monday, June 11, 2001 11:44 PM To: mpls-ops@mplsrc.com Subject: Tag-switching -vs- MPLS !!! Hi All, I am not sure what is the difference between tag-switching and MPLS ????????.... Also, are all mpls commands backward compatible to tag-switching ???... Thanks, Krishnan. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml -----Original Message----- From: Sivaramakrishna Iyer Krishnan [mailto:krishnan@research.bell-labs.com] Sent: Monday, June 11, 2001 11:44 PM To: mpls-ops@mplsrc.com Subject: Tag-switching -vs- MPLS !!! Hi All, I am not sure what is the difference between tag-switching and MPLS ????????.... Also, are all mpls commands backward compatible to tag-switching ???... Thanks, Krishnan. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------=_NextPart_001_0005_01C0F820.F46E11B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
    The biggest difference is = the fact=20 that Tag-Switching uses TDP, while standardized MPLS uses LDP as a = distribution=20 protocol.  TDP is a subset of LDP.  TDP uses TCP and UDP ports = 711,=20 while LDP uses TCP and UDP ports 646.  LDP has added functionality = that is=20 not available in TDP (MD5 authentication, etc.), and it is an IETF = standard (TDP=20 is Cisco proprietary).  The MLSTE class has a whole chapter devoted = to TDP=20 and LDP, as well as distribution protocol migration.  Some Cisco = IOS images=20 do not support LDP.  Use the IOS Feature Navigator to get = information on=20 what features are supported for your particular hardware.  I am = currently=20 working with 12.2(2T) which is the first 3640 image to support = LDP.  Anyone=20 know of any caveats for this code (Service Provider Feature Set) with = the=20 3640? 
 
Sincerely,
 
Dennis J. = Hartmann
White Pine=20 Consulting
dennisjhartmann@hotmail.com
(914) 980-0316=20 (cellular)
(845) 896-4777 = (home)
AOL IM:=20 dennisjhartmann
-----Original Message-----
From: owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Rahul = Bhushan
Sent:=20 Monday, June 18, 2001 4:31 PM
To: = mpls@UU.NET
Subject: Re:=20 Tag-switching -vs- MPLS !!!

Hi,=20

    You can check out Rekhtor/Davie/Doolan's book :=20

Switching in IP-Networks=20

It gives a good background on Toshiba's CSR,
Ipsilon's = IP-Switching,=20 IBM's ARIS and Cisco's
Tag-Switching architectures.=20

All these architectures have evolved in some
parts into MPLS.=20

URL to the book (Price in CDN $):
http://chapters.indigo.ca/books/details/d= efault.asp?mscssid=3D0Q482TPG4VJ08P5RMF66W8RXJS9LB69E&WSID=3D1606023A= 308A1E0D41A3A4CDB2DE767BB6DE2418&ISBN=3D1558605053=20 

-----Original Message-----  
From: Sivaramakrishna Iyer Krishnan  
[ mailto:krishnan@research.=
bell-labs.com
<mailto:krishnan@research.=
bell-labs.com> ]  
Sent: Monday, June 11, 2001 11:44 PM  
To: mpls-ops@mplsrc.com  
Subject: Tag-switching -vs- MPLS !!!  



Hi All,  

I am not sure what is the difference between tag-switching and =
MPLS  
????????....  

Also, are all mpls commands backward compatible to tag-switching =
???...  

Thanks,  
Krishnan.  

-------  
The MPLS-OPS Mailing List  
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsop=
s.shtml
<http://www.mplsrc.com/mplsop=
s.shtml>   
Archive: http://www.mplsrc.c=
om/mpls-ops_archive.shtml
<http://www.mplsrc.c=
om/mpls-ops_archive.shtml>   

-----Original=20 Message-----
From: Sivaramakrishna Iyer = Krishnan
[mailto:krishnan@research.= bell-labs.com]=20
Sent: Monday, June 11, 2001 11:44 PM =
To: mpls-ops@mplsrc.com
Subject:=20 Tag-switching -vs- MPLS !!!
 =20

Hi All,=20

I am not sure what is the difference between=20 tag-switching and MPLS
????????....=20

Also, are all mpls commands backward compatible = to=20 tag-switching ???...=20

Thanks,
Krishnan.=20

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

------=_NextPart_001_0005_01C0F820.F46E11B0-- ------=_NextPart_000_0004_01C0F820.F46B0470 Content-Type: text/x-vcard; name="Dennis J. Hartmann.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Dennis J. Hartmann.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Hartmann;Dennis;J. FN:Dennis J. Hartmann ORG:White Pine Consulting TITLE:CEO NOTE:CCIE Written/CCNP/Voice Specialization/CCDP/CCNA/CCDA/MCSE TEL;WORK;VOICE:(914) 980-0316 TEL;HOME;VOICE:(845) 896-4777 TEL;CELL;VOICE:(914) 980-0316 TEL;WORK;FAX:(419) 730-1666 ADR;WORK:;;3 White Pine Lane;Fishkill;NY;12524;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:3 White Pine = Lane=3D0D=3D0AFishkill, NY 12524=3D0D=3D0AUnited States of America ADR;HOME:;;;;;;United States of America LABEL;HOME:United States of America URL;WORK:http://resumes.dice.com/sanester EMAIL;PREF;INTERNET:dennisjhartmann@hotmail.com REV:20010607T141417Z END:VCARD ------=_NextPart_000_0004_01C0F820.F46B0470-- From owner-mpls@UU.NET Mon Jun 18 18:14:00 2001 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 SAA22426 for ; Mon, 18 Jun 2001 18:14:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktzs26816; Mon, 18 Jun 2001 22:13:35 GMT Received: by mail-control.mail.uu.net id QQktzs07527 for mpls-outgoing; Mon, 18 Jun 2001 22:12:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktzs07485 for ; Mon, 18 Jun 2001 22:12: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 QQktzs25227 for ; Mon, 18 Jun 2001 22:10:34 GMT Received: from c0mailgw11.prontomail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgw.prontomail.com [216.163.180.10]) id QQktzs22975 for ; Mon, 18 Jun 2001 22:10:33 GMT Received: by c0mailgw11.prontomail.com (NPlex 5.1.050) id 3B2B2FD6000577DD; Mon, 18 Jun 2001 15:06:34 -0700 Received: from 148.75.48.66 by SmtpServer for ; Mon, 18 Jun 2001 22:06:30 +0000 Reply-To: From: "Dennis Hartmann" To: "Bakshi, Sanjay" , Cc: "Sharma, Prem" Subject: RE: MPLS over POS Date: Mon, 18 Jun 2001 18:13:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C0F822.681E0BF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C0F822.681E0BF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C0F822.681E0BF0" ------=_NextPart_001_000C_01C0F822.681E0BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: RE: Valid Race Condition related to draft "draft-ietf-mpls-crlsp -modify-03.txt"MPLS over POS falls into Frame-mode MPLS (just like Ethernet, Frame-Relay, and PPP). Yes. It uses the MPLS Shim header. Check Jim Guichard and Ivan Pepelnjack's book by Cisco Press for some good information on the differences between frame-mode and cell-mode MPLS. Sincerely, Dennis J. Hartmann White Pine Consulting dennisjhartmann@hotmail.com (914) 980-0316 (cellular) (845) 896-4777 (home) AOL IM: dennisjhartmann -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bakshi, Sanjay Sent: Monday, June 18, 2001 5:48 PM To: mpls@UU.NET Cc: Sharma, Prem Subject: MPLS over POS Hi, Where can i find information on MPLS over POS? Is it an extention of IP over POS using PPP encapsulation with MPLS shim between PPP header and IP header? Please let me know. thanks, --sanjay ------=_NextPart_001_000C_01C0F822.681E0BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE: Valid Race Condition related to draft = "draft-ietf-mpls-crlsp -modify-03.txt"
MPLS=20 over POS falls into Frame-mode MPLS (just like Ethernet, Frame-Relay, = and=20 PPP).  Yes.  It uses the MPLS Shim header.  Check Jim = Guichard=20 and Ivan Pepelnjack's book by Cisco Press for some good information on = the=20 differences between frame-mode and cell-mode MPLS.
 
Sincerely,
 
Dennis J. = Hartmann
White Pine=20 Consulting
dennisjhartmann@hotmail.com
(914) 980-0316=20 (cellular)
(845) 896-4777 = (home)
AOL IM:=20 dennisjhartmann
-----Original Message-----
From: owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Bakshi, = Sanjay
Sent:=20 Monday, June 18, 2001 5:48 PM
To: mpls@UU.NET
Cc: = Sharma,=20 Prem
Subject: MPLS over POS

Hi,
Where can i find information on MPLS over=20 POS?
Is=20 it an extention of IP over POS using PPP encapsulation with MPLS shim = between=20 PPP header and IP header?
Please let me know.
thanks,
--sanjay
 

 

------=_NextPart_001_000C_01C0F822.681E0BF0-- ------=_NextPart_000_000B_01C0F822.681E0BF0 Content-Type: text/x-vcard; name="Dennis J. Hartmann.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Dennis J. Hartmann.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Hartmann;Dennis;J. FN:Dennis J. Hartmann ORG:White Pine Consulting TITLE:CEO NOTE:CCIE Written/CCNP/Voice Specialization/CCDP/CCNA/CCDA/MCSE TEL;WORK;VOICE:(914) 980-0316 TEL;HOME;VOICE:(845) 896-4777 TEL;CELL;VOICE:(914) 980-0316 TEL;WORK;FAX:(419) 730-1666 ADR;WORK:;;3 White Pine Lane;Fishkill;NY;12524;United States of America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:3 White Pine = Lane=3D0D=3D0AFishkill, NY 12524=3D0D=3D0AUnited States of America ADR;HOME:;;;;;;United States of America LABEL;HOME:United States of America URL;WORK:http://resumes.dice.com/sanester EMAIL;PREF;INTERNET:dennisjhartmann@hotmail.com REV:20010607T141417Z END:VCARD ------=_NextPart_000_000B_01C0F822.681E0BF0-- From owner-mpls@UU.NET Mon Jun 18 18:27:16 2001 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 SAA22660 for ; Mon, 18 Jun 2001 18:27:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktzt10642; Mon, 18 Jun 2001 22:26:26 GMT Received: by mail-control.mail.uu.net id QQktzt09124 for mpls-outgoing; Mon, 18 Jun 2001 22:25:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktzt09110 for ; Mon, 18 Jun 2001 22:25:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQktzt25918 for ; Mon, 18 Jun 2001 22:23:54 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQktzt07848 for ; Mon, 18 Jun 2001 22:23:53 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f5IMLTe00758; Mon, 18 Jun 2001 18:21:29 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 18:25:11 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D0220404029D8651@mail1.tellium.com> From: Vasanthi Thirumalai To: "Bakshi, Sanjay" , mpls@UU.NET Cc: "Sharma, Prem" Subject: RE: MPLS over POS Date: Mon, 18 Jun 2001 18:25:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Sanjay, Additionally you can refer to RFC 3032 (MPLS Label Stack Encoding) to get specific details on how to encode a packet in order to transmit it over a PPP data link. -Vasanthi -----Original Message----- From: Dennis Hartmann [mailto:sanester@starband.net] Sent: Monday, June 18, 2001 6:14 PM To: Bakshi, Sanjay; mpls@UU.NET Cc: Sharma, Prem Subject: RE: MPLS over POS MPLS over POS falls into Frame-mode MPLS (just like Ethernet, Frame-Relay, and PPP). Yes. It uses the MPLS Shim header. Check Jim Guichard and Ivan Pepelnjack's book by Cisco Press for some good information on the differences between frame-mode and cell-mode MPLS. Sincerely, Dennis J. Hartmann White Pine Consulting dennisjhartmann@hotmail.com (914) 980-0316 (cellular) (845) 896-4777 (home) AOL IM: dennisjhartmann -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bakshi, Sanjay Sent: Monday, June 18, 2001 5:48 PM To: mpls@UU.NET Cc: Sharma, Prem Subject: MPLS over POS Hi, Where can i find information on MPLS over POS? Is it an extention of IP over POS using PPP encapsulation with MPLS shim between PPP header and IP header? Please let me know. thanks, --sanjay From owner-mpls@UU.NET Mon Jun 18 20:19:24 2001 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 UAA24887 for ; Mon, 18 Jun 2001 20:19:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuab03318; Tue, 19 Jun 2001 00:18:33 GMT Received: by mail-control.mail.uu.net id QQkuab29777 for mpls-outgoing; Tue, 19 Jun 2001 00:17:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkuab29772 for ; Tue, 19 Jun 2001 00:17:51 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 QQkuab08531 for ; Tue, 19 Jun 2001 00:15:19 GMT Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQkuab28943 for ; Tue, 19 Jun 2001 00:15:18 GMT Received: from mrchang (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f5J0JuZ23824 for ; Tue, 19 Jun 2001 09:19:56 +0900 (KST) Message-ID: <001c01c0f854$98f1d220$84131796@sktelecom.com> From: "Ray M. Chang" To: Subject: Pls subscribe one more person Date: Tue, 19 Jun 2001 09:12:58 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C0F8A0.089656A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C0F8A0.089656A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sIG1vZGVyYXRvciEhIQ0KDQpXZSBjb3VsZG4ndCBzdWJzY3JpYmUgYnkgbWFpbGluZyB0 byBtcGxzLXJlcXVlc3RAdXUubmV0Lg0KU28gY291bGQgeW91IGhlbHAgdXMgc3Vic2NyaWJlIHRo ZSBmb2xsb3dpbmcgYWRkcmVzcz8NCg0KeXNzaGluQHNrdGVsZWNvbS5jb20NCg0KVGhhbmtzIGEg bG90IGZvciB5b3VyIGtpbmRuZXNzLg0KDQpSYXkuDQo= ------=_NextPart_000_0019_01C0F8A0.089656A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI0NjIuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxvLCBtb2Rl cmF0b3IhISE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5XZSZuYnNwO2NvdWxkbid0IHN1YnNjcmliZSBieSBtYWls aW5nIHRvIDxBIA0KaHJlZj0ibWFpbHRvOm1wbHMtcmVxdWVzdEB1dS5uZXQiPm1wbHMtcmVxdWVz dEB1dS5uZXQ8L0E+LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlNvIGNvdWxkJm5i c3A7eW91IGhlbHAgdXMgc3Vic2NyaWJlIHRoZSBmb2xsb3dpbmcgDQphZGRyZXNzPzwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPjxBIA0KaHJlZj0ibWFpbHRvOnlzc2hpbkBza3RlbGVjb20uY29tIj55c3NoaW5Ac2t0 ZWxlY29tLmNvbTwvQT48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFua3MgYSBsb3QgZm9yIHlvdXIga2luZG5l c3MuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+UmF5LjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0019_01C0F8A0.089656A0-- From owner-mpls@UU.NET Tue Jun 19 03:51:53 2001 Received: from cmr1.ash.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 DAA16002 for ; Tue, 19 Jun 2001 03:51:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkubf03570; Tue, 19 Jun 2001 07:50:53 GMT Received: by mail-control.mail.uu.net id QQkubf02075 for mpls-outgoing; Tue, 19 Jun 2001 07:50:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkubf02044 for ; Tue, 19 Jun 2001 07:50: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 QQkubf03132 for ; Tue, 19 Jun 2001 07:49:58 GMT Received: from mail.marhold.at by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.marhold.at [194.152.126.85]) id QQkubf21865 for ; Tue, 19 Jun 2001 07:49:57 GMT Received: from AMARHOLD ([62.22.50.94]) by mail.marhold.at (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id at; Tue, 19 Jun 2001 10:00:45 +0200 From: "Alexander Marhold" To: "Vikas D" Cc: , Subject: RE: Do Control packes use LSP? Date: Tue, 19 Jun 2001 09:52:25 +0200 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20010619032914.28839.qmail@web14802.mail.yahoo.com> Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ----> see inline answers Do the control packets originated by an LSP ingress, directed toward the LSP egress router use MPLS forwarding? By control packets, I mean any protocol packets originated by layer 3 on the ingress. ---> Yes, details seee below Consider the following scenario:- Router A -----[ IP/MPLS cloud ]----- Router B Assume that the above network is one AS. Routers A, B and all routers in the cloud run OSPF. An LSP is setup between A and B and another one is setup in the reverse direction. Traffic engineering is enabled at A as well as at B. Now, I found no reference in any MPLS draft/RFC which talks about forwarding packets originated at router A, destined for router B. Are these packets forwarded using MPLS or using "normal" IP routing? ---> they are treated like any packet with a given destination address and in that they will use the LSP I assume (because it sounds logical - though I did not see any mention of it in documents), that the signaling packets for the LSP itself (say refresh messages in RSVP) shall not be sent over the LSP. ---> RSVP is sent HOP-by-HOP so the destination address is always the physical next-hop so in a typicall framebased implementation using PHP (penultimate hop popping) they are sent unlabelled I am not sure about sending other protocol packets. Say, A and B also run I-BGP with each other as the peer. Do the BGP (or any other application) packets use LSP? ---> YES, they are treated like any L3 packet and are using by default the same FORWARDING engine like other packets I say "by default", as there maybe could be vendor implementations treating local packets differently, even though I am currently not aware of such implementation with best regards Alexander __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ __/ __/ Dipl.Ing. Alexander Marhold MBA __/ CCIE #3324, CCNP, CCDP, CCSI #20642 __/ Core & IP Services __/ Mobile: ++43-(0)664-16 28 234 __/ PRO IN http://www.proin.com From owner-mpls@UU.NET Tue Jun 19 11:02:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23397 for ; Tue, 19 Jun 2001 11:02:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuci19705; Tue, 19 Jun 2001 15:00:06 GMT Received: by mail-control.mail.uu.net id QQkuch04922 for mpls-outgoing; Tue, 19 Jun 2001 14:59:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkuch04914 for ; Tue, 19 Jun 2001 14:59:26 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 QQkuch21947 for ; Tue, 19 Jun 2001 14:59:12 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkuch12245 for ; Tue, 19 Jun 2001 14:59:10 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5JF04v18335; Tue, 19 Jun 2001 20:30:05 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A70.00529E78 ; Tue, 19 Jun 2001 20:32:25 +0530 X-Lotus-FromDomain: HSS To: "Alexander Marhold" cc: "Vikas D" , mpls-ops@mplsrc.com, mpls@UU.NET Message-ID: <65256A70.00529D1B.00@sandesh.hss.hns.com> Date: Tue, 19 Jun 2001 20:32:20 +0530 Subject: RE: Do Control packes use LSP? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi all! Just to add here I think we use a dedicated VCI/VPI pair between ATM LSRs to run LDP and hence it is kind of out-of-band siganlling. Same is the case with FR (using specific DLCI). So I guess its not strictly correct to say that the control packets follow the same LSP as the data packets(in ATM and FR LSRs). best regards -s "Alexander Marhold" on 06/19/2001 01:22:25 PM To: "Vikas D" cc: mpls-ops@mplsrc.com, mpls@UU.NET (bcc: Sumit Chauhan/HSS) Subject: RE: Do Control packes use LSP? ----> see inline answers Do the control packets originated by an LSP ingress, directed toward the LSP egress router use MPLS forwarding? By control packets, I mean any protocol packets originated by layer 3 on the ingress. ---> Yes, details seee below Consider the following scenario:- Router A -----[ IP/MPLS cloud ]----- Router B Assume that the above network is one AS. Routers A, B and all routers in the cloud run OSPF. An LSP is setup between A and B and another one is setup in the reverse direction. Traffic engineering is enabled at A as well as at B. Now, I found no reference in any MPLS draft/RFC which talks about forwarding packets originated at router A, destined for router B. Are these packets forwarded using MPLS or using "normal" IP routing? ---> they are treated like any packet with a given destination address and in that they will use the LSP I assume (because it sounds logical - though I did not see any mention of it in documents), that the signaling packets for the LSP itself (say refresh messages in RSVP) shall not be sent over the LSP. ---> RSVP is sent HOP-by-HOP so the destination address is always the physical next-hop so in a typicall framebased implementation using PHP (penultimate hop popping) they are sent unlabelled I am not sure about sending other protocol packets. Say, A and B also run I-BGP with each other as the peer. Do the BGP (or any other application) packets use LSP? ---> YES, they are treated like any L3 packet and are using by default the same FORWARDING engine like other packets I say "by default", as there maybe could be vendor implementations treating local packets differently, even though I am currently not aware of such implementation with best regards Alexander __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ __/ __/ Dipl.Ing. Alexander Marhold MBA __/ CCIE #3324, CCNP, CCDP, CCSI #20642 __/ Core & IP Services __/ Mobile: ++43-(0)664-16 28 234 __/ PRO IN http://www.proin.com ------- 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 Tue Jun 19 15:13:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01065 for ; Tue, 19 Jun 2001 15:13:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkucy03746; Tue, 19 Jun 2001 19:12:52 GMT Received: by mail-control.mail.uu.net id QQkucy08813 for mpls-outgoing; Tue, 19 Jun 2001 19:12:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkucy08801 for ; Tue, 19 Jun 2001 19:12:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkucy26485 for ; Tue, 19 Jun 2001 19:08:59 GMT Received: from gateway.ipinfusion.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gt.ipinfusion.com [209.11.132.18] (may be forged)) id QQkucy11854 for ; Tue, 19 Jun 2001 19:08:59 GMT Received: from ipinfusion.com (IDENT:root@[10.10.0.38]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id f5JJfSZ08241 for ; Tue, 19 Jun 2001 12:41:28 -0700 Message-ID: <3B2FA4C1.CABD0147@ipinfusion.com> Date: Tue, 19 Jun 2001 12:15:13 -0700 From: Manoj Dutta X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Label Mapping Message !! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In section A.1.2 , subsection LMp.6 (RFC 3036), it is mentioned that in case of loop detection, the matching label mapping should be removed. I have the following doubts :- 1) Should a label release message be sent for this label ? 2) Should a withdraw be sent to all the peers which have been sent a label corresponding to the label being deleted ? A related question is what happens to incoming packets with valid labels but no outgoing labels ? thanks in advance manoj From owner-mpls@UU.NET Tue Jun 19 16:16:38 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03378 for ; Tue, 19 Jun 2001 16:16:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkudd21642; Tue, 19 Jun 2001 20:17:12 GMT Received: by mail-control.mail.uu.net id QQkudd04654 for mpls-outgoing; Tue, 19 Jun 2001 20:15:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkudd04639 for ; Tue, 19 Jun 2001 20:15: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 QQkudc04762 for ; Tue, 19 Jun 2001 20:12:53 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkudc17392 for ; Tue, 19 Jun 2001 20:12:53 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5JKCvx15231 for ; Tue, 19 Jun 2001 13:12:57 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA01821 for mpls@uu.net; Tue, 19 Jun 2001 16:12:51 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkuan17926 for ; Tue, 19 Jun 2001 03:29: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 QQkuan13414 for ; Tue, 19 Jun 2001 03:29:15 GMT Received: from web14802.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14802.mail.yahoo.com [216.136.224.218]) id QQkuan00878 for ; Tue, 19 Jun 2001 03:29:15 GMT Message-ID: <20010619032914.28839.qmail@web14802.mail.yahoo.com> Received: from [216.174.224.251] by web14802.mail.yahoo.com; Mon, 18 Jun 2001 20:29:14 PDT Date: Mon, 18 Jun 2001 20:29:14 -0700 (PDT) From: Vikas D Subject: Do Control packes use LSP? To: mpls-ops@mplsrc.com, mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi All, Do the control packets originated by an LSP ingress, directed toward the LSP egress router use MPLS forwarding? By control packets, I mean any protocol packets originated by layer 3 on the ingress. Consider the following scenario:- Router A -----[ IP/MPLS cloud ]----- Router B Assume that the above network is one AS. Routers A, B and all routers in the cloud run OSPF. An LSP is setup between A and B and another one is setup in the reverse direction. Traffic engineering is enabled at A as well as at B. Now, I found no reference in any MPLS draft/RFC which talks about forwarding packets originated at router A, destined for router B. Are these packets forwarded using MPLS or using "normal" IP routing? I assume (because it sounds logical - though I did not see any mention of it in documents), that the signaling packets for the LSP itself (say refresh messages in RSVP) shall not be sent over the LSP. I am not sure about sending other protocol packets. Say, A and B also run I-BGP with each other as the peer. Do the BGP (or any other application) packets use LSP? Thanks - Vikas __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Tue Jun 19 16:18:46 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03498 for ; Tue, 19 Jun 2001 16:18:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkudd25244; Tue, 19 Jun 2001 20:19:19 GMT Received: by mail-control.mail.uu.net id QQkudd04875 for mpls-outgoing; Tue, 19 Jun 2001 20:18:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkudd04800 for ; Tue, 19 Jun 2001 20:17:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkudc25533 for ; Tue, 19 Jun 2001 20:14:22 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkudc21392 for ; Tue, 19 Jun 2001 20:14:21 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5JKEPh12970 for ; Tue, 19 Jun 2001 13:14:25 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA01829 for mpls@uu.net; Tue, 19 Jun 2001 16:14:19 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkucw16615 for ; Tue, 19 Jun 2001 18:42:02 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 QQkucw01845 for ; Tue, 19 Jun 2001 18:40:42 GMT Received: from web14807.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14807.mail.yahoo.com [216.136.224.223]) id QQkucw04928 for ; Tue, 19 Jun 2001 18:40:41 GMT Message-ID: <20010619184041.22164.qmail@web14807.mail.yahoo.com> Received: from [216.174.224.251] by web14807.mail.yahoo.com; Tue, 19 Jun 2001 11:40:41 PDT Date: Tue, 19 Jun 2001 11:40:41 -0700 (PDT) From: Vikas D Subject: RE: Do Control packes use LSP? To: Shahram Davari , "'Alexander Marhold'" Cc: mpls-ops@mplsrc.com, mpls@UU.NET In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D07@BBY1EXM01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I agree that there is no reason in theory not to be able to send control packets over LSP. But do MPLS capable routers use LSP for control packets? Or is there a way in them to send all data but no control packets over LSP? And most importantly, do the service providers use LSPs for control data (if at all they have a choice)? - VD __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Tue Jun 19 17:28:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05467 for ; Tue, 19 Jun 2001 17:28:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkudh25640; Tue, 19 Jun 2001 21:29:34 GMT Received: by mail-control.mail.uu.net id QQkudh02228 for mpls-outgoing; Tue, 19 Jun 2001 21:28:58 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkudh02216 for ; Tue, 19 Jun 2001 21:28:44 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 QQkudh19416 for ; Tue, 19 Jun 2001 21:28:13 GMT Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auemail1.lucent.com [192.11.223.161]) id QQkudh14755 for ; Tue, 19 Jun 2001 21:28:13 GMT Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JLSC816526 for ; Tue, 19 Jun 2001 17:28:12 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JLSBA16497 for ; Tue, 19 Jun 2001 17:28:11 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 23:28:10 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0CB60633@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: mpls-wg Subject: WG last Call on GMPLS documents Date: Tue, 19 Jun 2001 23:28:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk When flooded with the many postings/comments, I sometimes hate it when people are giving so much comments. But at the other hand, it also shows that we do get feedback from the community. The WG Last Call was a joint call between MPLS and CCAMP WGs. This was done because the 4 documents were in transit from MPLS to CCAMP WG. As a result we saw a lot of (too much!) cross posting. > - from now on we want discussion on CCAMP mailing list. Pls do not > copy MPLS and IPO mailing lists... if you want to participate, pls > join CCAMP mailing list. > - BUT... before you send more comments... pls hold off for a bit. > There are some 1000 or so postings to the WG Last Call. > I have asked the CCAMP WG chairs to try and make a summary of > the issues. Once they have done that, they will post them and try to > find out how many people agree/disagree with each issue. > I.e. they will try to find out if there is WG consensus on what the > issues are. > - I believe there were some suggested "fixes" to address some issues > as well. The WG chairs will also try to summarize these and again > then try to find out how much WG support there is for these "fixes". > - Then we will take it from there. > Thanks, Bert From owner-mpls@UU.NET Tue Jun 19 19:38:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07860 for ; Tue, 19 Jun 2001 19:38:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkudq13702; Tue, 19 Jun 2001 23:39:23 GMT Received: by mail-control.mail.uu.net id QQkudq22241 for mpls-outgoing; Tue, 19 Jun 2001 23:38:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkudq22236 for ; Tue, 19 Jun 2001 23:38: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 QQkudq19811 for ; Tue, 19 Jun 2001 23:38:28 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f257.law11.hotmail.com [64.4.16.132]) id QQkudq28901 for ; Tue, 19 Jun 2001 23:38:27 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 19 Jun 2001 16:38:26 -0700 Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 19 Jun 2001 23:38:26 GMT X-Originating-IP: [65.112.106.16] From: "Irfan Lateef" To: Shahram_Davari@pmc-sierra.com, alexander@marhold.at, vikdw@yahoo.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: Do Control packes use LSP? Date: Tue, 19 Jun 2001 19:38:26 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Jun 2001 23:38:26.0821 (UTC) FILETIME=[F00BCB50:01C0F918] Sender: owner-mpls@UU.NET Precedence: bulk To further add, the ingress node FEC can be mapped to three level of granularity,a subnet mask, or IP adress or IP address and port number. And if an IP and address and port number is chosen to be mapped in the FEC then the traffic to that destination will go on the LSP and every thing else will be IP hop-by-hop. Hope this helps! Irfan Lateef >From: Shahram Davari >To: "'Alexander Marhold'" , Vikas D >CC: mpls-ops@mplsrc.com, mpls@UU.NET >Subject: RE: Do Control packes use LSP? >Date: Tue, 19 Jun 2001 06:05:54 -0700 > >Hi, > >In MPLS you could select to send any traffic that you wish >over an LSP. This is accomplished by packet classification to FECs, and >possibly local policy, and therefore is configurable at the ingress LSR. > >-Shahram > > > -----Original Message----- > > From: Alexander Marhold [mailto:alexander@marhold.at] > > Sent: Tuesday, June 19, 2001 3:52 AM > > To: Vikas D > > Cc: mpls-ops@mplsrc.com; mpls@UU.NET > > Subject: RE: Do Control packes use LSP? > > > > > > ----> see inline answers > > > > Do the control packets originated by an LSP ingress, > > directed toward the LSP egress router use MPLS > > forwarding? By control packets, I mean any protocol > > packets originated by layer 3 on the ingress. > > > > ---> Yes, details seee below > > > > Consider the following scenario:- > > > > Router A -----[ IP/MPLS cloud ]----- Router B > > > > Assume that the above network is one AS. Routers A, > > B and all routers in the cloud run OSPF. An LSP is > > setup between A and B and another one is setup in the > > reverse direction. Traffic engineering is enabled at > > A as well as at B. > > > > Now, I found no reference in any MPLS draft/RFC which > > talks about forwarding packets originated at router A, > > destined for router B. Are these packets forwarded > > using MPLS or using "normal" IP routing? > > > > ---> they are treated like any packet with a given > > destination address and > > in that they will use the LSP > > > > I assume (because it sounds logical - though I did not > > see any mention of it in documents), that the > > signaling packets for the LSP itself (say refresh > > messages in RSVP) shall not be sent over the LSP. > > > > ---> RSVP is sent HOP-by-HOP so the destination address is always the > > physical next-hop > > so in a typicall framebased implementation using PHP (penultimate hop > > popping) they are sent unlabelled > > > > I am not sure about sending other protocol packets. > > Say, A and B also run I-BGP with each other as the > > peer. Do the BGP (or any other application) packets > > use LSP? > > > > ---> YES, they are treated like any L3 packet and are using > > by default the > > same FORWARDING engine like other packets > > > > I say "by default", as there maybe could be vendor > > implementations treating > > local packets differently, even though I am currently not > > aware of such > > implementation > > > > with best regards > > > > Alexander > > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ > > __/ > > __/ Dipl.Ing. Alexander Marhold MBA > > __/ CCIE #3324, CCNP, CCDP, CCSI #20642 > > __/ Core & IP Services > > __/ Mobile: ++43-(0)664-16 28 234 > > __/ PRO IN http://www.proin.com > > > > > > > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Jun 19 20:37:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09073 for ; Tue, 19 Jun 2001 20:37:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkudu21475; Wed, 20 Jun 2001 00:38:10 GMT Received: by mail-control.mail.uu.net id QQkudu16769 for mpls-outgoing; Wed, 20 Jun 2001 00:37:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkudu16764 for ; Wed, 20 Jun 2001 00:37: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 QQkudu26557 for ; Wed, 20 Jun 2001 00:36:52 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f66.law11.hotmail.com [64.4.17.66]) id QQkudu14518 for ; Wed, 20 Jun 2001 00:36:51 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 19 Jun 2001 17:36:51 -0700 Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 20 Jun 2001 00:36:50 GMT X-Originating-IP: [65.112.106.16] From: "Irfan Lateef" To: afarrel@movaz.com, bhaskara@turinnetworks.com Cc: mpls@UU.NET Subject: Re: GMPLS LSR MIB Date: Tue, 19 Jun 2001 20:36:50 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Jun 2001 00:36:51.0022 (UTC) FILETIME=[18B66EE0:01C0F921] Sender: owner-mpls@UU.NET Precedence: bulk Adrian, Will this MIB also cover cross-connects for optical(OXCs) and other technology-specific layers. Regards, Irfan Lateef >From: "Adrian Farrel" >To: "Bhaskara Peela" >CC: >Subject: Re: GMPLS LSR MIB >Date: Fri, 15 Jun 2001 13:50:11 -0400 > >Yes, in deed. > >The authors of the GMPLS TE MIB are discussing this at the moment and I >hope >that we'll have something out soon(ish). > >Adrian >-- >Adrian Farrel >Movaz Networks Inc. >afarrel@movaz.com >----- Original Message ----- >From: "Bhaskara Peela" >To: >Sent: Friday, June 15, 2001 1:40 PM >Subject: GMPLS LSR MIB > > > > Hi, > > > > Is any there any work going on for the GMPLS support of LSR mib. > > i.e., is there any MIB that enables the provisioning of static GMPLS >LSPs. > > > > thanks > > > > regards > > bhaskara > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Jun 19 22:36:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12584 for ; Tue, 19 Jun 2001 22:36:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuec07705; Wed, 20 Jun 2001 02:37:19 GMT Received: by mail-control.mail.uu.net id QQkuec05594 for mpls-outgoing; Wed, 20 Jun 2001 02:36:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkuec05579 for ; Wed, 20 Jun 2001 02:36: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 QQkuec00532 for ; Wed, 20 Jun 2001 02:36:04 GMT Received: from cms1.etri.re.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cms1.etri.re.kr [129.254.16.11]) id QQkuec10698 for ; Wed, 20 Jun 2001 02:36:01 GMT Received: from etri.re.kr (vines-b.etri.re.kr [129.254.191.73]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSGMTS91; Wed, 20 Jun 2001 11:33:57 +0900 Message-ID: <3B300F38.BD314ECD@etri.re.kr> Date: Wed, 20 Jun 2001 11:49:28 +0900 From: Changhoon Kim Organization: Electronics and Telecommunications Research Institute X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Vikas D CC: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Do Control packes use LSP? References: <20010619032914.28839.qmail@web14802.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vikas, I have some inline comments below. Vikas D wrote: > Now, I found no reference in any MPLS draft/RFC which > talks about forwarding packets originated at router A, > destined for router B. Are these packets forwarded > using MPLS or using "normal" IP routing? Ideally, we should be able to define traffic trunks on the basis of FECs (at any granularities), traffic profiles, and other TE requirements. But practically, ISPs might prefer to let traditional IGP SPF define proper sets of traffic trunks for given LSPs, by advertising (FA) LSPs as unidirectional p2p links and making use of them. Anyway even in that case, IGP peering over (FA) LSPs should be avoided, and of course as far as I know, is not supported by any implementation. Anyway, I also want to know others' opinion about having a standard that deals with "rules to map data & control packets to proper LSPs." Is this still skeptical as a topic for standard? Then, are there anybody who got a decent "best-practices and their rationale" on this? > I assume (because it sounds logical - though I did not > see any mention of it in documents), that the > signaling packets for the LSP itself (say refresh > messages in RSVP) shall not be sent over the LSP. Right, as others replied. > I am not sure about sending other protocol packets. > Say, A and B also run I-BGP with each other as the > peer. Do the BGP (or any other application) packets > use LSP? It depends upon the IP addresses; the egress address of the LSP and the IBGP peer address. If they are identical, IBGP route updates should use the LSP. But if not, they won't even though the egress and the IBGP peer are the same. Thus, in that case, utilizaing loopback to indicate its IBGP peer and its egress is preferred. Cheers, Chang -- Changhoon Kim Dept. of Internet Technologies Electronics and Telecommunications Research Institute (ETRI) Taejon, KOREA Tel) +82-42-860-5801 Fax) +82-42-860-5440 *** Man usually avoids attributing cleverness to somebody else, unless it is an enemy. -- Albert Einstein From owner-mpls@UU.NET Tue Jun 19 23:48:24 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13842 for ; Tue, 19 Jun 2001 23:48:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkueh17757; Wed, 20 Jun 2001 03:48:59 GMT Received: by mail-control.mail.uu.net id QQkueh03445 for mpls-outgoing; Wed, 20 Jun 2001 03:48:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkueh03359 for ; Wed, 20 Jun 2001 03:47:44 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 QQkueh09879 for ; Wed, 20 Jun 2001 03:45:19 GMT Received: from multitech.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkueh21512 for ; Wed, 20 Jun 2001 03:45:17 GMT Received: from multitech.co.in ([211.99.83.137]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f5K3gQ023538 for ; Wed, 20 Jun 2001 09:12:27 +0530 Message-ID: <3B301AA4.AD82A292@multitech.co.in> Date: Wed, 20 Jun 2001 11:38:12 +0800 From: abhay X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "mpls Mailing list (E-mail)" Subject: Multi-Point to Point and Point to Multi-Point Realizations Content-Type: multipart/alternative; boundary="------------8B4B89A3C21A05CB7678E376" Sender: owner-mpls@UU.NET Precedence: bulk --------------8B4B89A3C21A05CB7678E376 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello All, Appreciating the point to point LSP realizations using mpls t.e mib,thereby relying on the mptp and ptmp characteristics of the LSR MIB. It seems,mpls traffic engineering can be made compact with a smooth interaction between both T.E MIB and LSR MIB not to mention the signaling protocol How smooth can this interaction be,is it too dependent for mptp and ptmp to be found in LSR MIB alone.. Any constructive suggestions ? Regards, Abhay --------------8B4B89A3C21A05CB7678E376 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Hello All,
         Appreciating the point to point LSP realizations using mpls t.e mib,thereby
         relying on the mptp and ptmp characteristics of the LSR MIB.
         It seems,mpls traffic engineering can be made compact with a smooth
         interaction between both T.E MIB and LSR MIB not to mention the signaling protocol
         How smooth can this interaction be,is it too dependent for mptp and ptmp to be found
         in LSR MIB alone..
         Any constructive suggestions ?
         Regards,
         Abhay
 
         
 
 
--------------8B4B89A3C21A05CB7678E376-- From owner-mpls@UU.NET Wed Jun 20 00:02:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13967 for ; Wed, 20 Jun 2001 00:02:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuei15062; Wed, 20 Jun 2001 04:03:23 GMT Received: by mail-control.mail.uu.net id QQkuei17974 for mpls-outgoing; Wed, 20 Jun 2001 04:02:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkuei17272 for ; Wed, 20 Jun 2001 04:02:38 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 QQkuei26546 for ; Wed, 20 Jun 2001 04:00:54 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkuei29282 for ; Wed, 20 Jun 2001 04:00:52 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5K40EL23375; Wed, 20 Jun 2001 09:30:19 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A71.001633CA ; Wed, 20 Jun 2001 09:32:30 +0530 X-Lotus-FromDomain: HSS To: abhay cc: "mpls Mailing list (E-mail)" Message-ID: <65256A71.0016168C.00@sandesh.hss.hns.com> Date: Wed, 20 Jun 2001 09:31:11 +0530 Subject: Re: Multi-Point to Point and Point to Multi-Point Realizations Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=ByBkkoyr6Sk4UupnH6dtWgeiYcIe6MJtOwBaV0yquauctca2tjcYBTgf" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=ByBkkoyr6Sk4UupnH6dtWgeiYcIe6MJtOwBaV0yquauctca2tjcYBTgf Content-type: text/plain; charset=us-ascii Content-Disposition: inline hi abhay! I guess mptp is not a problem if you have label merging LSRs in your network and you can easily form a LSP tree. But I guess ptmp and mptmp is still a domain few have treaded as far as I know. Though I think there is a draft on it in the WG area. ciao sumit abhay on 06/20/2001 09:08:12 AM To: "mpls Mailing list (E-mail)" cc: (bcc: Sumit Chauhan/HSS) Subject: Multi-Point to Point and Point to Multi-Point Realizations Hello All, Appreciating the point to point LSP realizations using mpls t.e mib,thereby relying on the mptp and ptmp characteristics of the LSR MIB. It seems,mpls traffic engineering can be made compact with a smooth interaction between both T.E MIB and LSR MIB not to mention the signaling protocol How smooth can this interaction be,is it too dependent for mptp and ptmp to be found in LSR MIB alone.. Any constructive suggestions ? Regards, Abhay --0__=ByBkkoyr6Sk4UupnH6dtWgeiYcIe6MJtOwBaV0yquauctca2tjcYBTgf Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KDQo8cHJlPkhlbGxvIEFsbCw8L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXBwcmVjaWF0aW5nIHRoZSBw b2ludCB0byBwb2ludCBMU1AgcmVhbGl6YXRpb25zIHVzaW5nIG1wbHMgdC5lIG1pYix0aGVyZWJ5 PC9wcmU+DQoNCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlbHlpbmcgb24gdGhlIG1wdHAgYW5kIHB0bXAgY2hhcmFjdGVyaXN0aWNzIG9mIHRo ZSBMU1IgTUlCLjwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJdCBzZWVtcyxtcGxzIHRyYWZmaWMgZW5naW5lZXJpbmcgY2FuIGJl IG1hZGUgY29tcGFjdCB3aXRoIGEgc21vb3RoPC9wcmU+DQoNCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVyYWN0aW9uIGJldHdlZW4gYm90 aCBULkUgTUlCIGFuZCBMU1IgTUlCIG5vdCB0byBtZW50aW9uIHRoZSBzaWduYWxpbmcgcHJvdG9j b2w8L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSG93IHNtb290aCBjYW4gdGhpcyBpbnRlcmFjdGlvbiBiZSxpcyBpdCB0b28gZGVw ZW5kZW50IGZvciBtcHRwIGFuZCBwdG1wIHRvIGJlIGZvdW5kPC9wcmU+DQoNCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIExTUiBNSUIgYWxv bmUuLjwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBbnkgY29uc3RydWN0aXZlIHN1Z2dlc3Rpb25zID88L3ByZT4NCg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8 L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQWJoYXk8L3ByZT4NCg0KPHByZT4mbmJzcDs8L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3ByZT4NCg0KPHBy ZT4mbmJzcDs8L3ByZT4NCg0KPHByZT4mbmJzcDs8L3ByZT4NCjwvaHRtbD4NCg0K --0__=ByBkkoyr6Sk4UupnH6dtWgeiYcIe6MJtOwBaV0yquauctca2tjcYBTgf-- From owner-mpls@UU.NET Wed Jun 20 01:45:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16883 for ; Wed, 20 Jun 2001 01:45:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkudp12337; Tue, 19 Jun 2001 23:26:56 GMT Received: by mail-control.mail.uu.net id QQkudp21330 for mpls-outgoing; Tue, 19 Jun 2001 23:26:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkudp21288 for ; Tue, 19 Jun 2001 23: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 QQkudp27993 for ; Tue, 19 Jun 2001 23:25:39 GMT Received: from mail.timetra.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.timetra.com [63.104.212.2]) id QQkudp11483 for ; Tue, 19 Jun 2001 23:25:39 GMT Received: from SAURABAHPC ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Jun 2001 16:20:58 -0700 Reply-To: From: "Saurabh Shrivastava" To: "Mpls \(E-mail\)" Subject: mplsInSegmentTable Date: Tue, 19 Jun 2001 16:25:27 -0700 Message-ID: <006401c0f917$204746c0$c7bcfea9@SAURABAHPC> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 19 Jun 2001 23:20:58.0140 (UTC) FILETIME=[7EFBC5C0:01C0F916] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi all!, the draft - draft-ietf-mpls-lsr-mib-07.txt has this - 7.3. mplsInSegmentTable This table contains a description of the incoming MPLS segments to an LSR and their associated parameters. The administrative and operational status objects for this table are used to control packet transmission on this segment. If either the administrative and operational status objects for this table are set to 'down', this implies that packets will not be forwarded. Likewise, if the values are set to 'up' this implies that packets are forwarded. These values are particularly useful in cases where multi-point connections utilize a single cross- connect and the administrator wishes to disable some, but not all of the streams. In these cases, the administrator may set the administrative status object to 'down' on some of the in-segments. point to note, if you look at mplsInSegmentEntry, there is no operational/admin status fields. so how will the administrator bring a segment "down" or "up" ? - the way it is implied in the above paragraph. ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Saurabh Shrivastava saurabh@timetra.com TiMetra Networks, Inc. 408.245.8796 (residence) http://www.timetra.com/ 650.237.5154 (office) ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ From owner-mpls@UU.NET Wed Jun 20 09:38:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06944 for ; Wed, 20 Jun 2001 09:38:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkufu06686; Wed, 20 Jun 2001 13:38:59 GMT Received: by mail-control.mail.uu.net id QQkufu10690 for mpls-outgoing; Wed, 20 Jun 2001 13:38:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkufu10677 for ; Wed, 20 Jun 2001 13:38:21 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 QQkufu26444 for ; Wed, 20 Jun 2001 13:33:54 GMT Received: from dnsmx2pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQkufu08953 for ; Wed, 20 Jun 2001 13:33:54 GMT Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id JAA24775; Wed, 20 Jun 2001 09:28:15 -0400 (EDT) Subject: Re: Multi-Point to Point and Point to Multi-Point Realizations To: suchauhan@hss.hns.com Cc: mpls@UU.NET From: "Robert Streijl" Date: Wed, 20 Jun 2001 09:28:26 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 06/20/2001 09:28:27 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=85256A710049F6BE8f9e8a93df938690918c85256A710049F6BE" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=85256A710049F6BE8f9e8a93df938690918c85256A710049F6BE Content-type: text/plain; charset=us-ascii Hi, Would you happen to know which draft that is? thanks Robert suchauhan@hss.hns.com on 06/20/2001 12:01:11 AM To: abhay cc: "mpls Mailing list (E-mail)" (bcc: Robert Streijl/Telcordia) Subject: Re: Multi-Point to Point and Point to Multi-Point Realizations hi abhay! I guess mptp is not a problem if you have label merging LSRs in your network and you can easily form a LSP tree. But I guess ptmp and mptmp is still a domain few have treaded as far as I know. Though I think there is a draft on it in the WG area. ciao sumit abhay on 06/20/2001 09:08:12 AM To: "mpls Mailing list (E-mail)" cc: (bcc: Sumit Chauhan/HSS) Subject: Multi-Point to Point and Point to Multi-Point Realizations Hello All, Appreciating the point to point LSP realizations using mpls t.e mib,thereby relying on the mptp and ptmp characteristics of the LSR MIB. It seems,mpls traffic engineering can be made compact with a smooth interaction between both T.E MIB and LSR MIB not to mention the signaling protocol How smooth can this interaction be,is it too dependent for mptp and ptmp to be found in LSR MIB alone.. Any constructive suggestions ? Regards, Abhay --0__=85256A710049F6BE8f9e8a93df938690918c85256A710049F6BE Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KDQo8cHJlPkhlbGxvIEFsbCw8L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXBwcmVjaWF0aW5nIHRoZSBw b2ludCB0byBwb2ludCBMU1AgcmVhbGl6YXRpb25zIHVzaW5nIG1wbHMgdC5lIG1pYix0aGVyZWJ5 PC9wcmU+DQoNCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlbHlpbmcgb24gdGhlIG1wdHAgYW5kIHB0bXAgY2hhcmFjdGVyaXN0aWNzIG9mIHRo ZSBMU1IgTUlCLjwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJdCBzZWVtcyxtcGxzIHRyYWZmaWMgZW5naW5lZXJpbmcgY2FuIGJl IG1hZGUgY29tcGFjdCB3aXRoIGEgc21vb3RoPC9wcmU+DQoNCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVyYWN0aW9uIGJldHdlZW4gYm90 aCBULkUgTUlCIGFuZCBMU1IgTUlCIG5vdCB0byBtZW50aW9uIHRoZSBzaWduYWxpbmcgcHJvdG9j b2w8L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSG93IHNtb290aCBjYW4gdGhpcyBpbnRlcmFjdGlvbiBiZSxpcyBpdCB0b28gZGVw ZW5kZW50IGZvciBtcHRwIGFuZCBwdG1wIHRvIGJlIGZvdW5kPC9wcmU+DQoNCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIExTUiBNSUIgYWxv bmUuLjwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBbnkgY29uc3RydWN0aXZlIHN1Z2dlc3Rpb25zID88L3ByZT4NCg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8 L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQWJoYXk8L3ByZT4NCg0KPHByZT4mbmJzcDs8L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3ByZT4NCg0KPHBy ZT4mbmJzcDs8L3ByZT4NCg0KPHByZT4mbmJzcDs8L3ByZT4NCjwvaHRtbD4NCg0K --0__=85256A710049F6BE8f9e8a93df938690918c85256A710049F6BE-- From owner-mpls@UU.NET Wed Jun 20 11:05:45 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10143 for ; Wed, 20 Jun 2001 11:05:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuga22688; Wed, 20 Jun 2001 15:06:17 GMT Received: by mail-control.mail.uu.net id QQkuga27915 for mpls-outgoing; Wed, 20 Jun 2001 15:05:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkuga26587 for ; Wed, 20 Jun 2001 15:05:24 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 QQkuga16048 for ; Wed, 20 Jun 2001 15:01:51 GMT Received: from ext1.ics.forth.gr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2]) id QQkuga13566 for ; Wed, 20 Jun 2001 15:01:50 GMT Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51]) by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id SAA16087; Wed, 20 Jun 2001 18:01:41 +0300 (EET DST) Received: from titan.ics.forth.gr (titan.ics.forth.gr [139.91.190.42]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id SAA21863; Wed, 20 Jun 2001 18:01:45 +0300 (EET DST) Posted-Date: Wed, 20 Jun 2001 18:01:45 +0300 (EET DST) Received: from localhost (tziou@localhost) by titan.ics.forth.gr (8.9.1b+Sun/ICS-FORTH/V8.1-NULL) with ESMTP id SAA15846; Wed, 20 Jun 2001 18:01:33 +0300 (EET DST) Organization: X-Authentication-Warning: titan.ics.forth.gr: tziou owned process doing -bs Date: Wed, 20 Jun 2001 18:01:33 +0300 (EET DST) From: Chrysostomos Tziouvaras To: mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: DWDM Muxing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, do you know what's the state of the art in the number of channels in DWDM muxers? Thanks Chrysostomos Tziouvaras ICS-FORTH Researcher From owner-mpls@UU.NET Wed Jun 20 14:21:40 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16986 for ; Wed, 20 Jun 2001 14:21:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkugn09923; Wed, 20 Jun 2001 18:22:15 GMT Received: by mail-control.mail.uu.net id QQkugn22395 for mpls-outgoing; Wed, 20 Jun 2001 18:21:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkugn22373 for ; Wed, 20 Jun 2001 18:21:13 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 QQkugn06209 for ; Wed, 20 Jun 2001 18:19:09 GMT Received: from web11406.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11406.mail.yahoo.com [216.136.131.236]) id QQkugn05655 for ; Wed, 20 Jun 2001 18:19:09 GMT Message-ID: <20010620181909.32515.qmail@web11406.mail.yahoo.com> Received: from [63.116.202.66] by web11406.mail.yahoo.com; Wed, 20 Jun 2001 11:19:09 PDT Date: Wed, 20 Jun 2001 11:19:09 -0700 (PDT) From: Vishal Mishra Subject: Re: DWDM Muxing To: Chrysostomos Tziouvaras Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk 160 channels / fibre. Vishal. --- Chrysostomos Tziouvaras wrote: > Hi, > do you know what's the state of the art in the number of channels in > DWDM > muxers? > > Thanks > Chrysostomos Tziouvaras > ICS-FORTH Researcher > > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jun 20 16:30:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21527 for ; Wed, 20 Jun 2001 16:30:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkugw23348; Wed, 20 Jun 2001 20:30:40 GMT Received: by mail-control.mail.uu.net id QQkugw17601 for mpls-outgoing; Wed, 20 Jun 2001 20:30:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkugv17519 for ; Wed, 20 Jun 2001 20:29: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 QQkugv05914 for ; Wed, 20 Jun 2001 20:28:43 GMT Received: from optic3.ipoptical.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.ipoptical.com [64.242.9.180]) id QQkugv13207 for ; Wed, 20 Jun 2001 20:28:41 GMT Received: by optic3.ipoptical.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 16:28:40 -0400 Message-ID: From: Alex Mondrus To: "'Chrysostomos Tziouvaras'" , mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing Date: Wed, 20 Jun 2001 16:28:35 -0400 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 320 at 25 space http://www.ipoptical.com -----Original Message----- From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] Sent: Wednesday, June 20, 2001 11:02 AM To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: DWDM Muxing Hi, do you know what's the state of the art in the number of channels in DWDM muxers? Thanks Chrysostomos Tziouvaras ICS-FORTH Researcher From owner-mpls@UU.NET Wed Jun 20 22:32:56 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00636 for ; Wed, 20 Jun 2001 22:32:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuhu07926; Thu, 21 Jun 2001 02:33:32 GMT Received: by mail-control.mail.uu.net id QQkuhu25641 for mpls-outgoing; Thu, 21 Jun 2001 02:33:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkuhu25626 for ; Thu, 21 Jun 2001 02:32:47 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 QQkuhu29047 for ; Thu, 21 Jun 2001 02:30:01 GMT Received: from noya.bupt.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkuht24466 for ; Thu, 21 Jun 2001 02:29:59 GMT Received: from mars ([202.112.109.101]) by noya.bupt.edu.cn (8.11.4/8.10.1) with SMTP id f5L2UFv16532 for ; Thu, 21 Jun 2001 10:30:15 +0800 (CST) Message-Id: <200106210230.f5L2UFv16532@noya.bupt.edu.cn> Date: Thu, 21 Jun 2001 10:33:0 +0800 From: Wang Yu To: "mpls@UU.NET" Subject: how to decide the message ID of a LDP message? X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA00636 everybody£¬ Hi! how to decide the message ID of a LDP message? thanks a lot. Wang Yu wangyu7707@263.net From owner-mpls@UU.NET Wed Jun 20 23:34:03 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03148 for ; Wed, 20 Jun 2001 23:34:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuhy04090; Thu, 21 Jun 2001 03:34:39 GMT Received: by mail-control.mail.uu.net id QQkuhy21646 for mpls-outgoing; Thu, 21 Jun 2001 03:34:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkuhy21635 for ; Thu, 21 Jun 2001 03:34:01 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 QQkuhx09245 for ; Thu, 21 Jun 2001 03:28:49 GMT Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkuhx22288 for ; Thu, 21 Jun 2001 03:28:48 GMT Received: from m2hub.mail.wipro.com (m2hub.wipro.com [164.164.27.50]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with ESMTP id f5L97SW25963 for ; Thu, 21 Jun 2001 09:07:28 GMT Received: from m2vwall2.wipro.com ([164.164.27.52]) by m2hub.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GF9G2900.IBY for ; Thu, 21 Jun 2001 08:52:57 +0530 Received: from soflt.alc.wipinfo.soft.net ([192.168.220.205]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GF9GGQ00.RFW; Thu, 21 Jun 2001 09:01:38 +0530 Date: Thu, 21 Jun 2001 09:02:25 +0530 (IST) From: "chetan kumar s" X-Sender: chetansk@soflt.alc.wipinfo.soft.net Reply-To: chetan.kumar@wipro.com To: Wang Yu cc: "mpls@UU.NET" Subject: Re: how to decide the message ID of a LDP message? In-Reply-To: <200106210230.f5L2UFv16532@noya.bupt.edu.cn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id XAA03148 > everybody£¬ > Hi! > how to decide the message ID of a LDP message? Hi, It is just a 32bit number, could be generated from a 32 bit counter which may be incremented as each message is sent to the peer.. Thanks Chetan S > thanks a lot. > > > > Wang Yu > wangyu7707@263.net > From owner-mpls@UU.NET Thu Jun 21 01:18:52 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05357 for ; Thu, 21 Jun 2001 01:18:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuif04845; Thu, 21 Jun 2001 05:19:26 GMT Received: by mail-control.mail.uu.net id QQkuif12257 for mpls-outgoing; Thu, 21 Jun 2001 05:18:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkuif12230 for ; Thu, 21 Jun 2001 05:18:36 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 QQkuif19936 for ; Thu, 21 Jun 2001 05:18:24 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkuif02400 for ; Thu, 21 Jun 2001 05:18:21 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 21 Jun 2001 10:53:26 +0530 Received: from sailendram (sailendram.future.futsoft.com [10.8.7.27]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f5L5Fhh06018 for ; Thu, 21 Jun 2001 10:45:44 +0530 Reply-To: From: "sailendra mahanty" To: Subject: Use of RD in BGP/MPLS VPN Date: Thu, 21 Jun 2001 10:31:14 +0530 Message-Id: <000401c0fa0f$334cd2a0$1b07080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, draft-rosen-rfc2547bis-03.txt clearly distinguish between RD and RT. The aim of the RD is to resolve the ambiguity of IP4 address for IP address overlapping situation. IMHO when there is a BGP session between two PEs, the route advertise information in UPDATE msg is not used by other BGP speaker ( P routers specifically ). If i am missing something in saying this please let me know. If i am right in saying the last statemnet, the address overlapping can be resolved at the peer PE by using RT. Putting the question in other way, what way the RD value associated with a route is used in the remote PE ? Can anybody please help me to get clear picture of RD. Regards, -sailendra From owner-mpls@UU.NET Thu Jun 21 02:22:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17241 for ; Thu, 21 Jun 2001 02:22:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuij06029; Thu, 21 Jun 2001 06:22:39 GMT Received: by mail-control.mail.uu.net id QQkuij08721 for mpls-outgoing; Thu, 21 Jun 2001 06:22:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkuij08715 for ; Thu, 21 Jun 2001 06:21:59 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 QQkuij19562 for ; Thu, 21 Jun 2001 06:17:49 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkuij20767 for ; Thu, 21 Jun 2001 06:17:36 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5L6Hb700694; Thu, 21 Jun 2001 11:47:39 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A72.0022C631 ; Thu, 21 Jun 2001 11:49:49 +0530 X-Lotus-FromDomain: HSS To: "Robert Streijl" cc: mpls@UU.NET Message-ID: <65256A72.0022C433.00@sandesh.hss.hns.com> Date: Thu, 21 Jun 2001 11:49:43 +0530 Subject: Re: Multi-Point to Point and Point to Multi-Point Realizations Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=BctzkC1QCct5Eznrlf6uHOFnxHAb06jrREbilyVbMWlv9SDqm7FwCfKP" Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk --0__=BctzkC1QCct5Eznrlf6uHOFnxHAb06jrREbilyVbMWlv9SDqm7FwCfKP Content-type: text/plain; charset=us-ascii Content-Disposition: inline http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-05.txt "Robert Streijl" on 06/20/2001 06:58:26 PM To: Sumit Chauhan/HSS@HSS cc: mpls@UU.NET Subject: Re: Multi-Point to Point and Point to Multi-Point Realizations Hi, Would you happen to know which draft that is? thanks Robert suchauhan@hss.hns.com on 06/20/2001 12:01:11 AM To: abhay cc: "mpls Mailing list (E-mail)" (bcc: Robert Streijl/Telcordia) Subject: Re: Multi-Point to Point and Point to Multi-Point Realizations hi abhay! I guess mptp is not a problem if you have label merging LSRs in your network and you can easily form a LSP tree. But I guess ptmp and mptmp is still a domain few have treaded as far as I know. Though I think there is a draft on it in the WG area. ciao sumit abhay on 06/20/2001 09:08:12 AM To: "mpls Mailing list (E-mail)" cc: (bcc: Sumit Chauhan/HSS) Subject: Multi-Point to Point and Point to Multi-Point Realizations Hello All, Appreciating the point to point LSP realizations using mpls t.e mib,thereby relying on the mptp and ptmp characteristics of the LSR MIB. It seems,mpls traffic engineering can be made compact with a smooth interaction between both T.E MIB and LSR MIB not to mention the signaling protocol How smooth can this interaction be,is it too dependent for mptp and ptmp to be found in LSR MIB alone.. Any constructive suggestions ? Regards, Abhay --0__=BctzkC1QCct5Eznrlf6uHOFnxHAb06jrREbilyVbMWlv9SDqm7FwCfKP Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KDQo8cHJlPkhlbGxvIEFsbCw8L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXBwcmVjaWF0aW5nIHRoZSBw b2ludCB0byBwb2ludCBMU1AgcmVhbGl6YXRpb25zIHVzaW5nIG1wbHMgdC5lIG1pYix0aGVyZWJ5 PC9wcmU+DQoNCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlbHlpbmcgb24gdGhlIG1wdHAgYW5kIHB0bXAgY2hhcmFjdGVyaXN0aWNzIG9mIHRo ZSBMU1IgTUlCLjwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJdCBzZWVtcyxtcGxzIHRyYWZmaWMgZW5naW5lZXJpbmcgY2FuIGJl IG1hZGUgY29tcGFjdCB3aXRoIGEgc21vb3RoPC9wcmU+DQoNCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVyYWN0aW9uIGJldHdlZW4gYm90 aCBULkUgTUlCIGFuZCBMU1IgTUlCIG5vdCB0byBtZW50aW9uIHRoZSBzaWduYWxpbmcgcHJvdG9j b2w8L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSG93IHNtb290aCBjYW4gdGhpcyBpbnRlcmFjdGlvbiBiZSxpcyBpdCB0b28gZGVw ZW5kZW50IGZvciBtcHRwIGFuZCBwdG1wIHRvIGJlIGZvdW5kPC9wcmU+DQoNCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIExTUiBNSUIgYWxv bmUuLjwvcHJlPg0KDQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBbnkgY29uc3RydWN0aXZlIHN1Z2dlc3Rpb25zID88L3ByZT4NCg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8 L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQWJoYXk8L3ByZT4NCg0KPHByZT4mbmJzcDs8L3ByZT4NCg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3ByZT4NCg0KPHBy ZT4mbmJzcDs8L3ByZT4NCg0KPHByZT4mbmJzcDs8L3ByZT4NCjwvaHRtbD4NCg0K --0__=BctzkC1QCct5Eznrlf6uHOFnxHAb06jrREbilyVbMWlv9SDqm7FwCfKP-- From owner-mpls@UU.NET Thu Jun 21 03:47:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21227 for ; Thu, 21 Jun 2001 03:47:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuip15854; Thu, 21 Jun 2001 07:48:26 GMT Received: by mail-control.mail.uu.net id QQkuip07429 for mpls-outgoing; Thu, 21 Jun 2001 07:47:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkuip07400 for ; Thu, 21 Jun 2001 07:47:22 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 QQkuip16226 for ; Thu, 21 Jun 2001 07:45:44 GMT From: Juerg.Fankhauser@swisscom.com Received: from sbe3777.swissptt.ch by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: outmail5.swisscom.com [138.190.3.48]) id QQkuip12032 for ; Thu, 21 Jun 2001 07:45:44 GMT Received: from sbe2173.swissptt.ch (138.190.70.55) by sbe3778.swissptt.ch (MX V5.2 AnHp) with SMTP for ; Thu, 21 Jun 2001 09:25:42 +0200 Received: from 138.190.70.105 by sbe2173.swissptt.ch (InterScan E-Mail VirusWall NT); Thu, 21 Jun 2001 09:09:56 +0200 (W. Europe Daylight Time) Received: by gd2zdk.swissptt.ch with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 09:13:52 +0200 Message-ID: To: mpls@UU.NET Subject: RE: Use of RD in BGP/MPLS VPN Date: Thu, 21 Jun 2001 09:13:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Sailendra, I think that's because an advertized route can be associated with any number and combination of RTs (depending on your VPN routing scheme), while it carries exactly one RD as part of the address. That means: Even if it would be possible in theory to resolve the routing with RT alone, thanks to the RD it can be handled by regular (multiprotocol) BGP processes and tables. btw - P routers are not even BGP speakers in MPLS/VPN. Regards, ----------------------------- Juerg FANKHAUSER swisscom AG, Bern juerg.fankhauser@swisscom.com ----------------------------- -----Original Message----- From: sailendra mahanty [mailto:sailendram@future.futsoft.com] Sent: Donnerstag, 21. Juni 2001 07:01 To: mpls@UU.NET Subject: Use of RD in BGP/MPLS VPN Hi All, draft-rosen-rfc2547bis-03.txt clearly distinguish between RD and RT. The aim of the RD is to resolve the ambiguity of IP4 address for IP address overlapping situation. IMHO when there is a BGP session between two PEs, the route advertise information in UPDATE msg is not used by other BGP speaker ( P routers specifically ). If i am missing something in saying this please let me know. If i am right in saying the last statemnet, the address overlapping can be resolved at the peer PE by using RT. Putting the question in other way, what way the RD value associated with a route is used in the remote PE ? Can anybody please help me to get clear picture of RD. Regards, -sailendra From owner-mpls@UU.NET Thu Jun 21 05:05:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22038 for ; Thu, 21 Jun 2001 05:05:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuiu14887; Thu, 21 Jun 2001 09:05:59 GMT Received: by mail-control.mail.uu.net id QQkuiu15750 for mpls-outgoing; Thu, 21 Jun 2001 09:05:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkuiu15736 for ; Thu, 21 Jun 2001 09:05: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 QQkuiu10129 for ; Thu, 21 Jun 2001 09:04:37 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkuiu17497 for ; Thu, 21 Jun 2001 09:04:36 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 21 Jun 2001 14:42:17 +0530 Received: from sailendram (sailendram.future.futsoft.com [10.8.7.27]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f5L942h29384; Thu, 21 Jun 2001 14:34:02 +0530 Reply-To: From: "sailendra mahanty" To: Cc: Subject: RE: Use of RD in BGP/MPLS VPN Date: Thu, 21 Jun 2001 14:19:24 +0530 Message-Id: <000a01c0fa2f$13162840$1b07080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Juerg, At the remote PE, when BGP receives the route update, it won't mantain two routes to same IP address (Overlapped IP addresses) if RD is not used. Here i agree that RD is needed for BGP regular processing like selecting routes from RIB-In to Loc-RIB. But by some means (say by using RT value) if one can populate appropriate VRF with routes to overlapped addresses, RD may not be reuired. Please let me know if i am missing something ? Regards, -sailendra -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Juerg.Fankhauser@swisscom.com Sent: Thursday, June 21, 2001 12:44 PM To: mpls@uu.net Subject: RE: Use of RD in BGP/MPLS VPN Hi Sailendra, I think that's because an advertized route can be associated with any number and combination of RTs (depending on your VPN routing scheme), while it carries exactly one RD as part of the address. That means: Even if it would be possible in theory to resolve the routing with RT alone, thanks to the RD it can be handled by regular (multiprotocol) BGP processes and tables. btw - P routers are not even BGP speakers in MPLS/VPN. Regards, ----------------------------- Juerg FANKHAUSER swisscom AG, Bern juerg.fankhauser@swisscom.com ----------------------------- -----Original Message----- From: sailendra mahanty [mailto:sailendram@future.futsoft.com] Sent: Donnerstag, 21. Juni 2001 07:01 To: mpls@UU.NET Subject: Use of RD in BGP/MPLS VPN Hi All, draft-rosen-rfc2547bis-03.txt clearly distinguish between RD and RT. The aim of the RD is to resolve the ambiguity of IP4 address for IP address overlapping situation. IMHO when there is a BGP session between two PEs, the route advertise information in UPDATE msg is not used by other BGP speaker ( P routers specifically ). If i am missing something in saying this please let me know. If i am right in saying the last statemnet, the address overlapping can be resolved at the peer PE by using RT. Putting the question in other way, what way the RD value associated with a route is used in the remote PE ? Can anybody please help me to get clear picture of RD. Regards, -sailendra From owner-mpls@UU.NET Thu Jun 21 05:31:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22346 for ; Thu, 21 Jun 2001 05:31:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuiw26676; Thu, 21 Jun 2001 09:32:00 GMT Received: by mail-control.mail.uu.net id QQkuiw27699 for mpls-outgoing; Thu, 21 Jun 2001 09:31:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkuiw27556 for ; Thu, 21 Jun 2001 09:30: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 QQkuiv08051 for ; Thu, 21 Jun 2001 09:29:26 GMT Received: from manali.in.allegronetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.94.179]) id QQkuiv03970 for ; Thu, 21 Jun 2001 09:29:20 GMT Received: by manali.in.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 14:59:12 +0530 Message-ID: <2310F01DA869D411A86900508BD635411E7B12@manali.in.allegronetworks.com> From: Abhishek Choudhary To: "'mpls@uu.net'" Subject: test mail: plz ignore.. Date: Thu, 21 Jun 2001 14:59:11 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA34.A148F390" 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_01C0FA34.A148F390 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01C0FA34.A148F390 Content-Type: text/html; charset="iso-8859-1" test mail: plz ignore.. ------_=_NextPart_001_01C0FA34.A148F390-- From owner-mpls@UU.NET Thu Jun 21 06:58:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22967 for ; Thu, 21 Jun 2001 06:58:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujb08067; Thu, 21 Jun 2001 10:59:18 GMT Received: by mail-control.mail.uu.net id QQkujb26640 for mpls-outgoing; Thu, 21 Jun 2001 10:58:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkujb26618 for ; Thu, 21 Jun 2001 10:58: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 QQkujb11817 for ; Thu, 21 Jun 2001 10:57:25 GMT Received: from web4105.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web4105.mail.yahoo.com [216.115.104.125]) id QQkujb13066 for ; Thu, 21 Jun 2001 10:57:25 GMT Message-ID: <20010621105724.1041.qmail@web4105.mail.yahoo.com> Received: from [64.110.57.227] by web4105.mail.yahoo.com; Thu, 21 Jun 2001 03:57:24 PDT Date: Thu, 21 Jun 2001 03:57:24 -0700 (PDT) From: tito bayuadji Subject: Question about ATM-MPLS To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk hi all i wanna ask question about encoding in ATM MPLS why we must use 3 encoding in ATM MPLS ( SVC, SVP, SVP multipoint) ? and if we must use 3 kind of encoding in what condition we must use each encoding thanks __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Thu Jun 21 09:09:54 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27119 for ; Thu, 21 Jun 2001 09:09:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujk07936; Thu, 21 Jun 2001 13:10:29 GMT Received: by mail-control.mail.uu.net id QQkujk07221 for mpls-outgoing; Thu, 21 Jun 2001 13:09:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkujk06519 for ; Thu, 21 Jun 2001 13:09:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkujk29461 for ; Thu, 21 Jun 2001 13:08:44 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkujk05782 for ; Thu, 21 Jun 2001 13:08:43 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5LD8nx07932 for ; Thu, 21 Jun 2001 06:08:49 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02804 for mpls@uu.net; Thu, 21 Jun 2001 09:08:41 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkugf28899 for ; Wed, 20 Jun 2001 16:26:45 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 QQkugf19624 for ; Wed, 20 Jun 2001 16:26:11 GMT Received: from mail1.hyperchip.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail1.hyperchip.com [207.164.218.3]) id QQkugf29109 for ; Wed, 20 Jun 2001 16:26:11 GMT Received: from hermes.hyperchip.com ([10.0.0.12]) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 15Cknz-0001XX-00 for mpls@UU.NET; Wed, 20 Jun 2001 12:26:11 -0400 Received: by HERMES with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 12:26:00 -0400 Message-ID: From: Jason Rosengren To: "'mpls@uu.net'" Subject: question regarding RSVP-TE Date: Wed, 20 Jun 2001 12:25:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi I have a question regarding the PATH message and subsequent RESV message in RSVP-TE. On sending a number of PATH messages each having the same tunnel_id and various LSP-IDs. Should the egress return only one RESV with a number of filter_specs for all lsp_id or should there be a number of RESVs returned each with their own filter_spec corresponding to one lsp_id? Both scenarios seem to be valid. I hope to get this clarified. Thanks Jason From owner-mpls@UU.NET Thu Jun 21 09:11:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27164 for ; Thu, 21 Jun 2001 09:11:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujk09674; Thu, 21 Jun 2001 13:11:38 GMT Received: by mail-control.mail.uu.net id QQkujk07312 for mpls-outgoing; Thu, 21 Jun 2001 13:09:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkujk06996 for ; Thu, 21 Jun 2001 13:09:34 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 QQkujk24226 for ; Thu, 21 Jun 2001 13:08:34 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkujk05593 for ; Thu, 21 Jun 2001 13:08:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5LD8dx07834 for ; Thu, 21 Jun 2001 06:08:39 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02800 for mpls@uu.net; Thu, 21 Jun 2001 09:08:31 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkuge24791 for ; Wed, 20 Jun 2001 16:09:23 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 QQkuge20010 for ; Wed, 20 Jun 2001 16:08:39 GMT Received: from denexg01.icgcomm.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.92.105.60]) id QQkuge05886 for ; Wed, 20 Jun 2001 16:08:39 GMT Received: by denexg01.icgcomm.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 10:08:38 -0600 Message-ID: <6F751F46B77ED411AF2D00805FFE90C03B3EB7@denexg08.icgcomm.com> From: "Hart, Jim" To: "'Chrysostomos Tziouvaras'" , mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing Date: Wed, 20 Jun 2001 10:08:38 -0600 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 it depends, but 32 is pretty common -- Jim Hart Director, Data Engineering ICG communications jim_hart@icgcomm.com 303-414-5856 cell- 720-320-0618 -----Original Message----- From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] Sent: Wednesday, June 20, 2001 9:02 AM To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: DWDM Muxing Hi, do you know what's the state of the art in the number of channels in DWDM muxers? Thanks Chrysostomos Tziouvaras ICS-FORTH Researcher ------- 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 Thu Jun 21 09:12:14 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27257 for ; Thu, 21 Jun 2001 09:12:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujk11272; Thu, 21 Jun 2001 13:12:50 GMT Received: by mail-control.mail.uu.net id QQkujk07397 for mpls-outgoing; Thu, 21 Jun 2001 13:09:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkujk07009 for ; Thu, 21 Jun 2001 13:09:34 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 QQkujk25042 for ; Thu, 21 Jun 2001 13:09:01 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkujk06140 for ; Thu, 21 Jun 2001 13:09:00 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5LD96x08101 for ; Thu, 21 Jun 2001 06:09:06 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02812 for mpls@uu.net; Thu, 21 Jun 2001 09:08:59 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkugi23015 for ; Wed, 20 Jun 2001 17:11: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 QQkugi02736 for ; Wed, 20 Jun 2001 17:11:54 GMT Received: from mailsrv03.pneast by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [66.7.6.123]) id QQkugi16044 for ; Wed, 20 Jun 2001 17:11:54 GMT Received: by mailsrv03 with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 13:06:07 -0400 Message-ID: <048D54B6FD5FD51180AD00D0B7C9EB590A421E@mailsrv03> From: Ala Al-Fuqaha To: "'Chrysostomos Tziouvaras'" , mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing Date: Wed, 20 Jun 2001 13:06:01 -0400 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 Hi, I think that 8, 32, 40, 64, and 90 are typical DWDM mux levels (32 is the most common now). Do you know about the expected DWDM mux levels in the near future? Thanks /Ala -----Original Message----- From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] Sent: Wednesday, June 20, 2001 11:02 AM To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: DWDM Muxing Hi, do you know what's the state of the art in the number of channels in DWDM muxers? Thanks Chrysostomos Tziouvaras ICS-FORTH Researcher ------- 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 Thu Jun 21 09:13:34 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27323 for ; Thu, 21 Jun 2001 09:13:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujk13064; Thu, 21 Jun 2001 13:14:09 GMT Received: by mail-control.mail.uu.net id QQkujk07517 for mpls-outgoing; Thu, 21 Jun 2001 13:10:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkujk06602 for ; Thu, 21 Jun 2001 13:09: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 QQkujk13259 for ; Thu, 21 Jun 2001 13:08:52 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkujk14707 for ; Thu, 21 Jun 2001 13:08:52 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5LD8th28769 for ; Thu, 21 Jun 2001 06:08:55 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02808 for mpls@uu.net; Thu, 21 Jun 2001 09:08:50 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkugg29715 for ; Wed, 20 Jun 2001 16:31:33 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 QQkugf21864 for ; Wed, 20 Jun 2001 16:28:42 GMT Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: grex.cyberspace.org [216.93.104.34]) id QQkugf22780 for ; Wed, 20 Jun 2001 16:28:41 GMT Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id MAA27789; Wed, 20 Jun 2001 12:27:42 -0400 Date: Wed, 20 Jun 2001 12:27:42 -0400 (EDT) From: Hemant P K To: "Hart, Jim" cc: "'Chrysostomos Tziouvaras'" , mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing In-Reply-To: <6F751F46B77ED411AF2D00805FFE90C03B3EB7@denexg08.icgcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Jim, what is the WDM channel spacing for that ? regards, - Hemant On Wed, 20 Jun 2001, Hart, Jim wrote: > it depends, but 32 is pretty common > > -- > Jim Hart > Director, Data Engineering > ICG communications > jim_hart@icgcomm.com > 303-414-5856 > cell- 720-320-0618 > > > -----Original Message----- > From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] > Sent: Wednesday, June 20, 2001 9:02 AM > To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com > Subject: DWDM Muxing > > > Hi, > do you know what's the state of the art in the number of channels in DWDM > muxers? > > Thanks > Chrysostomos Tziouvaras > ICS-FORTH Researcher > > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > ------- > 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 Thu Jun 21 09:17:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27393 for ; Thu, 21 Jun 2001 09:17:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujl03671; Thu, 21 Jun 2001 13:17:45 GMT Received: by mail-control.mail.uu.net id QQkujk07667 for mpls-outgoing; Thu, 21 Jun 2001 13:10:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkujk07384 for ; Thu, 21 Jun 2001 13:09: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 QQkujk01477 for ; Thu, 21 Jun 2001 13:09:27 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkujk15257 for ; Thu, 21 Jun 2001 13:09:26 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5LD9Uh29030 for ; Thu, 21 Jun 2001 06:09:30 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02822 for mpls@uu.net; Thu, 21 Jun 2001 09:09:24 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkugp26488 for ; Wed, 20 Jun 2001 18:57: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 QQkugp06840 for ; Wed, 20 Jun 2001 18:56:13 GMT Received: from cello.cs.iitm.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cello.cs.iitm.ernet.in [202.141.24.3]) id QQkugp07098 for ; Wed, 20 Jun 2001 18:56:07 GMT Received: from rts.iitm.ernet.in (IDENT:root@rts.iitm.ernet.in [144.16.241.62]) by cello.cs.iitm.ernet.in (8.11.0/8.11.0) with ESMTP id f5KIsBW32636; Thu, 21 Jun 2001 00:24:11 +0530 Received: from localhost (saradhi@localhost) by rts.iitm.ernet.in (8.9.3/8.8.7) with ESMTP id AAA02393; Thu, 21 Jun 2001 00:08:45 +0530 Date: Thu, 21 Jun 2001 00:08:45 +0530 (IST) From: "Chava. Vijaya Saradhi" To: Chrysostomos Tziouvaras cc: mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: Re: DWDM Muxing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Chrysostomos, Now practically 60 tp 80 wavelengths are available in Mux.. But, Bell-labs proved 1024 wavelengths theoritically.. regards, On Wed, 20 Jun 2001, Chrysostomos Tziouvaras wrote: > Hi, > do you know what's the state of the art in the number of channels in DWDM > muxers? > > Thanks > Chrysostomos Tziouvaras > ICS-FORTH Researcher > > > ------- > 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 Thu Jun 21 09:19:37 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27516 for ; Thu, 21 Jun 2001 09:19:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujl05741; Thu, 21 Jun 2001 13:20:13 GMT Received: by mail-control.mail.uu.net id QQkujl09784 for mpls-outgoing; Thu, 21 Jun 2001 13:16:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkujk08839 for ; Thu, 21 Jun 2001 13:12: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 QQkujk15997 for ; Thu, 21 Jun 2001 13:11:47 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkujk09891 for ; Thu, 21 Jun 2001 13:11:46 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5LDBjh00226 for ; Thu, 21 Jun 2001 06:11:45 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA02847 for mpls@uu.net; Thu, 21 Jun 2001 09:11:44 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkujj18035 for ; Thu, 21 Jun 2001 12:59:12 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 QQkujj13248 for ; Thu, 21 Jun 2001 12:57:52 GMT Received: from tisch.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tisch.mail.mindspring.net [207.69.200.157]) id QQkujj20486 for ; Thu, 21 Jun 2001 12:57:52 GMT Received: from tecra8100 (user-vcauhud.dsl.mindspring.com [216.175.71.205]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id IAA05322; Thu, 21 Jun 2001 08:57:36 -0400 (EDT) From: "Walt Carter" To: "Simon Dredge" , "Hart, Jim" , "'Chrysostomos Tziouvaras'" , , , Subject: RE: DWDM Muxing Date: Thu, 21 Jun 2001 08:55:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4611AD058694D4118FD5009027B0A6620212AA51@ICARIAN> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In today's DWDM systems, wavelength spacing occurs at 0.8 nm or 100-Ghz steps. Future systems will space wavelengths at 0.4 nm or 50 Ghz, to further increase the capacity of existing fibers. The ITU has set specifications that list the channel code and wavelength for each optical signal multiplexed into a fiber. Present ITU specs recommend 81 channels, starting at a center frequency of 196.10 THz (1528.77 nm) and decreasing in 80 steps of 50 GHz (~0.39 nm) each. The ITU uses as its starting point a 193.10-THz reference frequency that corresponds to a spectral line for krypton gas. The ITU specified frequency rather than wavelength because wavelength depends on a transmission medium, and thus it can vary. Frequency is a physical unit that will not vary as a signal goes from one medium into another, say from glass into air. Regards, Walter S. Carter kSi group, inc (770) 460-2062 Office (678) 362-4504 Mobile 2 WAY: -----Original Message----- From: Simon Dredge [mailto:sdredge@zaffire.com] Sent: Wednesday, June 20, 2001 12:50 PM To: Hart, Jim; 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing I believe 40-Channel Muxes (full c-band) are in the works and will be available soon -----Original Message----- From: Hart, Jim [mailto:Jim_Hart@icgcomm.com] Sent: Wednesday, June 20, 2001 9:09 AM To: 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing it depends, but 32 is pretty common -- Jim Hart Director, Data Engineering ICG communications jim_hart@icgcomm.com 303-414-5856 cell- 720-320-0618 -----Original Message----- From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] Sent: Wednesday, June 20, 2001 9:02 AM To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: DWDM Muxing Hi, do you know what's the state of the art in the number of channels in DWDM muxers? Thanks Chrysostomos Tziouvaras ICS-FORTH Researcher ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- 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 Thu Jun 21 09:42:21 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28537 for ; Thu, 21 Jun 2001 09:42:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujm19873; Thu, 21 Jun 2001 13:42:57 GMT Received: by mail-control.mail.uu.net id QQkujm12747 for mpls-outgoing; Thu, 21 Jun 2001 13:42:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkujm12720 for ; Thu, 21 Jun 2001 13:42: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 QQkujm03779 for ; Thu, 21 Jun 2001 13:41:50 GMT Received: from c2.ciena.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQkujm15620 for ; Thu, 21 Jun 2001 13:41:49 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id JAA05981; Thu, 21 Jun 2001 09:41:47 -0400 (EDT) Received: from wntasdexg01.asd.ciena.com(10.25.2.11) by c2.ciena.com via smap (V2.0) id xma005939; Thu, 21 Jun 01 09:41:35 -0400 Received: by wntasdexg01.asd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 09:40:44 -0400 Message-ID: <4D29EF232640D311A78C0008C75D8B92E9F28C@wntasdexg01.asd.ciena.com> From: "Kotha, Saikrishna" To: "'Chrysostomos Tziouvaras'" , mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing Date: Thu, 21 Jun 2001 09:40:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Check the following link: 320 channels at 12.5 Ghz spacing http://www.ciena.com/news/archive/2001/06/06.05.2001b.html > -----Original Message----- > From: Chrysostomos Tziouvaras [SMTP:tziou@ics.forth.gr] > Sent: Wednesday, June 20, 2001 11:02 AM > To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com > Subject: DWDM Muxing > > Hi, > do you know what's the state of the art in the number of channels in DWDM > muxers? > > Thanks > Chrysostomos Tziouvaras > ICS-FORTH Researcher > From owner-mpls@UU.NET Thu Jun 21 11:00:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01449 for ; Thu, 21 Jun 2001 11:00:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujs29812; Thu, 21 Jun 2001 15:01:33 GMT Received: by mail-control.mail.uu.net id QQkujs15193 for mpls-outgoing; Thu, 21 Jun 2001 15:00:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkujs14800 for ; Thu, 21 Jun 2001 15:00: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 QQkujr26665 for ; Thu, 21 Jun 2001 14:58:36 GMT Received: from sigcentralexc1.infoglobal.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [217.112.97.132]) id QQkujr06341 for ; Thu, 21 Jun 2001 14:58:35 GMT Received: by SIGCENTRALEXC1 with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 16:58:31 +0200 Message-ID: From: Alexander Zlatkin To: "'Walt Carter'" , Simon Dredge , "Hart, Jim" , "'Chrysostomos Tziouvaras'" , mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing Date: Thu, 21 Jun 2001 16:58:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Sorry to interfere, but Walt's statement about the wavelengths and frequencies is not correct. In the physical medium the relation between these two is: frequency (Hz) = group velocity (m/s) / lambda (m) It is the wave packet group velocity that changes when it crosses the media boundary; the frequency and wavelength do not. Hz or nanometer? It is a matter or choice. An electrician would prefer Hz, while a physicist would normally use nm, 1/cm or eV. Alex ============================================= -----Mensaje original----- De: Walt Carter [SMTP:waltcarter@mindspring.com] Enviado el: jueves 21 de junio de 2001 14:56 Para: Simon Dredge; Hart, Jim; 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Asunto: RE: DWDM Muxing In today's DWDM systems, wavelength spacing occurs at 0.8 nm or 100-Ghz steps. Future systems will space wavelengths at 0.4 nm or 50 Ghz, to further increase the capacity of existing fibers. The ITU has set specifications that list the channel code and wavelength for each optical signal multiplexed into a fiber. Present ITU specs recommend 81 channels, starting at a center frequency of 196.10 THz (1528.77 nm) and decreasing in 80 steps of 50 GHz (~0.39 nm) each. The ITU uses as its starting point a 193.10-THz reference frequency that corresponds to a spectral line for krypton gas. The ITU specified frequency rather than wavelength because wavelength depends on a transmission medium, and thus it can vary. Frequency is a physical unit that will not vary as a signal goes from one medium into another, say from glass into air. Regards, Walter S. Carter kSi group, inc (770) 460-2062 Office (678) 362-4504 Mobile 2 WAY: -----Original Message----- From: Simon Dredge [mailto:sdredge@zaffire.com] Sent: Wednesday, June 20, 2001 12:50 PM To: Hart, Jim; 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing I believe 40-Channel Muxes (full c-band) are in the works and will be available soon -----Original Message----- From: Hart, Jim [mailto:Jim_Hart@icgcomm.com] Sent: Wednesday, June 20, 2001 9:09 AM To: 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing it depends, but 32 is pretty common -- Jim Hart Director, Data Engineering ICG communications jim_hart@icgcomm.com 303-414-5856 cell- 720-320-0618 -----Original Message----- From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] Sent: Wednesday, June 20, 2001 9:02 AM To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: DWDM Muxing Hi, do you know what's the state of the art in the number of channels in DWDM muxers? Thanks Chrysostomos Tziouvaras ICS-FORTH Researcher ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- 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 Thu Jun 21 11:03:56 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01541 for ; Thu, 21 Jun 2001 11:03:56 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujs01682; Thu, 21 Jun 2001 15:04:33 GMT Received: by mail-control.mail.uu.net id QQkujs17728 for mpls-outgoing; Thu, 21 Jun 2001 15:03:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkujs17519 for ; Thu, 21 Jun 2001 15:03:44 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 QQkujs27183 for ; Thu, 21 Jun 2001 15:02:14 GMT Received: from dnsmx1rrc.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQkujs27956 for ; Thu, 21 Jun 2001 15:02:14 GMT Received: from notes800.cc.telcordia.com (notes800a.cc.telcordia.com [128.96.79.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA24116 for ; Thu, 21 Jun 2001 10:58:50 -0400 (EDT) Subject: label stack depth To: mpls@UU.NET From: "Robert Streijl" Date: Thu, 21 Jun 2001 10:59:00 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes800/Telcordia(Release 5.0.6a |January 17, 2001) at 06/21/2001 10:59:01 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Is there any maximum defined for the depth of a label stack? What is common, two, three labels, more? I known that the bottom will indicate the last label. Theoratically it seems that there can be an undefinite amount. Practically it will probably introduce some management complications. I don't recall having seen any limitations in the drafts and RFCs. I guess that before transmitted onto the layer 2 transport technology (e.g. ATM, Ethernet, etc.) it can be fragmented to a size supported by that transport technology so that should not matter. Any insights are welcomed. Thanks. Robert From owner-mpls@UU.NET Thu Jun 21 12:16:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04619 for ; Thu, 21 Jun 2001 12:16:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujx25862; Thu, 21 Jun 2001 16:17:12 GMT Received: by mail-control.mail.uu.net id QQkujx00284 for mpls-outgoing; Thu, 21 Jun 2001 16:16:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkujx00151 for ; Thu, 21 Jun 2001 16:16:11 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 QQkujw29592 for ; Thu, 21 Jun 2001 16:13:46 GMT Received: from ulysses.routingloop.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: c1297948-a.snvl1.sfba.home.com [65.3.196.186]) id QQkujw16591 for ; Thu, 21 Jun 2001 16:13:46 GMT Received: (from alan@localhost) by ulysses.routingloop.com (8.10.0/8.10.0) id f5LGDWW68167; Thu, 21 Jun 2001 09:13:32 -0700 (PDT) Date: Thu, 21 Jun 2001 09:13:32 -0700 From: Alan Hannan To: "'Chrysostomos Tziouvaras'" , mpls@UU.NET, mpls-ops@mplsrc.com, ip-optical@lists.bell-labs.com Subject: Re: DWDM Muxing Message-ID: <20010621091332.A68077@routingloop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from AZlatkin@infoglobal.es on Thu, Jun 21, 2001 at 04:58:31PM +0200 Sender: owner-mpls@UU.NET Precedence: bulk It seems to me that there are four ways of looking at this: a/ What is Theoretically Possible - Certainly 12.5 ghz is theoretically possible, and probably more/tighter, this implies that more than 500 lambdas can be sent b/ What is Possible/Done in the Labs - seems to be at the 12.5 ghz spacing, or around 300 lambdas c/ What Capacity is Deployed in the Field - best seems to be about 192 or 160 lambdas at 2.5gbps or 10gbps d/ What capacity is USED in the field - seems to be about 10-25 lambdas at 2.5Gbps or 10gbps Very useful thread, methinks. -alan Thus spake Alexander Zlatkin (AZlatkin@infoglobal.es) on or about Thu, Jun 21, 2001 at 04:58:31PM +0200: > Sorry to interfere, but Walt's statement about the wavelengths > and frequencies is not correct. > > In the physical medium the relation between these two is: > > frequency (Hz) = group velocity (m/s) / lambda (m) > > It is the wave packet group velocity that changes when it > crosses the media boundary; the frequency and wavelength > do not. > Hz or nanometer? It is a matter or choice. An electrician > would prefer Hz, while a physicist would normally use > nm, 1/cm or eV. > > Alex > ============================================= > > -----Mensaje original----- > De: Walt Carter [SMTP:waltcarter@mindspring.com] > Enviado el: jueves 21 de junio de 2001 14:56 > Para: Simon Dredge; Hart, Jim; 'Chrysostomos Tziouvaras'; mpls@UU.NET; > mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com > Asunto: RE: DWDM Muxing > > In today's DWDM systems, wavelength spacing occurs at 0.8 nm or 100-Ghz > steps. Future systems will space wavelengths at 0.4 nm or 50 Ghz, to further > increase the capacity of existing fibers. The ITU has set specifications > that list the channel code and wavelength for each optical signal > multiplexed into a fiber. Present ITU specs recommend 81 channels, starting > at a center frequency of 196.10 THz (1528.77 nm) and decreasing in 80 steps > of 50 GHz (~0.39 nm) each. The ITU uses as its starting point a 193.10-THz > reference frequency that corresponds to a spectral line for krypton gas. The > ITU specified frequency rather than wavelength because wavelength depends on > a transmission medium, and thus it can vary. Frequency is a physical unit > that will not vary as a signal goes from one medium into another, say from > glass into air. > > Regards, > Walter S. Carter > kSi group, inc > (770) 460-2062 Office > (678) 362-4504 Mobile > 2 WAY: > > > > -----Original Message----- > From: Simon Dredge [mailto:sdredge@zaffire.com] > Sent: Wednesday, June 20, 2001 12:50 PM > To: Hart, Jim; 'Chrysostomos Tziouvaras'; mpls@UU.NET; > mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com > Subject: RE: DWDM Muxing > > > I believe 40-Channel Muxes (full c-band) are in the works and will be > available soon > > -----Original Message----- > From: Hart, Jim [mailto:Jim_Hart@icgcomm.com] > Sent: Wednesday, June 20, 2001 9:09 AM > To: 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com; > ip-optical@lists.bell-labs.com > Subject: RE: DWDM Muxing > > > it depends, but 32 is pretty common > > -- > Jim Hart > Director, Data Engineering > ICG communications > jim_hart@icgcomm.com > 303-414-5856 > cell- 720-320-0618 > > > -----Original Message----- > From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] > Sent: Wednesday, June 20, 2001 9:02 AM > To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com > Subject: DWDM Muxing > > > Hi, > do you know what's the state of the art in the number of channels in DWDM > muxers? > > Thanks > Chrysostomos Tziouvaras > ICS-FORTH Researcher > > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > ------- > 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 Thu Jun 21 12:42:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05994 for ; Thu, 21 Jun 2001 12:42:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujy27433; Thu, 21 Jun 2001 16:42:43 GMT Received: by mail-control.mail.uu.net id QQkujy02593 for mpls-outgoing; Thu, 21 Jun 2001 16:42:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkujy02585 for ; Thu, 21 Jun 2001 16:42: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 QQkujy13800 for ; Thu, 21 Jun 2001 16:39:40 GMT Received: from calliope1.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10]) id QQkujy23446 for ; Thu, 21 Jun 2001 16:39:40 GMT Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id QAA21356; Thu, 21 Jun 2001 16:38:07 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 21 Jun 2001 16:38:07 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 09:38:04 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8900655DDBB@orsmsx35.jf.intel.com> From: "Hegde, Shriharsha" To: "'Ritu Chadha'" , franr@pfn.com, Olivier.Dugeon@rd.francetelecom.com, mpls@UU.NET, te-wg@ops.ietf.org, sganguly@carrier9.com Cc: policy@raleigh.ibm.com, rap@ops.ietf.org Subject: RE: MPLS and COPS Date: Thu, 21 Jun 2001 09:37:56 -0700 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 Just like Diffserv MIB and Diffserv PIB are in Diffserv working group, I support the notion of having a TE PIB in parallel to TE MIB in TE WG. I believe PIB approach is the right direction to take for policy/administrative control over MPLS/TE. harsha PS: I have not followed the TE WG discussion which took place months ago about the ADs deciding that policy should not be in TEWG charter. -----Original Message----- From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com] Sent: Tuesday, June 12, 2001 12:50 PM To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET; te-wg@ops.ietf.org; sganguly@carrier9.com Cc: chadha@mailee.research.telcordia.com; policy@raleigh.ibm.com Subject: RE: MPLS and COPS Well, I can't comment on that except to say that I'm completely in agreement with you. You should direct your concerns to the ADs. Randy? Ritu >From: "Sukanta Ganguly" >To: "Ritu Chadha" , , , , >Subject: RE: MPLS and COPS >Date: Tue, 12 Jun 2001 11:50:35 -0700 >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >Importance: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 >X-Loop-Detect: 1 > >Ritu, > I see what you are saying and I did read some of them emails but it is >needed. I mean I don't get it (:-)). Why not have a way for TE to take in >some higher layer knowledge to perform smart engineering. There is a lot of >knowledge that can be conveyed to the lower layers from the applications >sitting on top. > > >Sukanta Ganguly >Senior Architect >Carrier9 Networks >Phone (408)-746-0400 x 119 >FAx (408)-730-9441 > >-----Original Message----- >From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com] >Sent: Tuesday, June 12, 2001 11:16 AM >To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET; >te-wg@ops.ietf.org; sganguly@carrier9.com >Cc: chadha@mailee.research.telcordia.com >Subject: RE: MPLS and COPS > > >Been there, tried that :-). > >This was discussed at some length a few months ago on the tewg mailing list. >The ADs did not see policy as an area that fitted within the TE WG charter >at that time. > >Ritu > >>From: "Sukanta Ganguly" >>To: "Fran Reichmeyer" , "'Olivier Dugeon '" >, , >>Subject: RE: MPLS and COPS >>Date: Tue, 12 Jun 2001 10:51:26 -0700 >>MIME-Version: 1.0 >>Content-Transfer-Encoding: 7bit >>X-Priority: 3 (Normal) >>X-MSMail-Priority: Normal >>Importance: Normal >>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 >>X-Loop-Detect: 1 >> >>Maybe the TE group should be the place for this. Clearly policies should be >>an important traffic engineering operation. >> >>SG >> >>-----Original Message----- >>From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On >>Behalf Of Fran Reichmeyer >>Sent: Tuesday, June 12, 2001 6:54 AM >>To: 'Olivier Dugeon '; 'mpls@UU.NET '; 'te-wg@ops.ietf.org ' >>Subject: RE: MPLS and COPS >> >> >>After several attempts at introducing this to the wg, it >>was decided that policy is out of scope for the MPLS wg at this >>time. >>-Fran >> >> >>-----Original Message----- >>From: Olivier Dugeon >>To: mpls@UU.NET; te-wg@ops.ietf.org >>Sent: 6/12/01 4:28 AM >>Subject: MPLS and COPS >> >>Hi all, >> >>In a context of QoS control in a multi-domain and multi-technology >>network, we would use COPS as the control protocol rather than SNMP. >>COPS need a "Policy rules Information Base" to work. A such PIB is >>available for DiffServ for example. I would to know if somebody work on >>a PIB for MPLS. >> >>- Is there some case study inside the WG or it is out the scope/out of >>date ? >>- Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ? >> >>Thank's a lot >> >>Olivier Dugeon >>-- >> FTR&D/DAC/CPN >> Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.com >> 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 >> F-22307 LANNION | Fax: +(33) 2 96 05 18 52 >> > ============================================================================ = Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1A-216R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================ = From owner-mpls@UU.NET Thu Jun 21 12:51:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06401 for ; Thu, 21 Jun 2001 12:51:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkujz06425; Thu, 21 Jun 2001 16:52:32 GMT Received: by mail-control.mail.uu.net id QQkujz03684 for mpls-outgoing; Thu, 21 Jun 2001 16:51:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkujz03646 for ; Thu, 21 Jun 2001 16:51:37 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 QQkujz25361 for ; Thu, 21 Jun 2001 16:47:37 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkujz03879 for ; Thu, 21 Jun 2001 16:47:36 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5LGlfx27106 for ; Thu, 21 Jun 2001 09:47:41 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA04087 for mpls@uu.net; Thu, 21 Jun 2001 12:47:34 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkujy02624 for ; Thu, 21 Jun 2001 16:42:35 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 QQkujy16162 for ; Thu, 21 Jun 2001 16:39:05 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkujy00072 for ; Thu, 21 Jun 2001 16:39:04 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA27267; Thu, 21 Jun 2001 12:39:02 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA15765; Thu, 21 Jun 2001 12:39:02 -0400 (EDT) Message-Id: <200106211639.MAA15765@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Cc: vijay@cosinecom.com Subject: LDP-FT - second last call Date: Thu, 21 Jun 2001 12:39:02 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Fault Tolerance for LDP and CR-LDP went through a workgroup last call. It has been updated to address the issued raised. This notice commences a one week last call on the new draft, draft-ietf-mpls-ldp-ft-02.txt The last call is restricted to the issues raised in the prior last call. The last call ends June 28, 12pm GMT. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jun 21 13:00:04 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06990 for ; Thu, 21 Jun 2001 13:00:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuka14127; Thu, 21 Jun 2001 17:00:38 GMT Received: by mail-control.mail.uu.net id QQkuka04216 for mpls-outgoing; Thu, 21 Jun 2001 17:00:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkujz04125 for ; Thu, 21 Jun 2001 16:59:43 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 QQkujz09160 for ; Thu, 21 Jun 2001 16:54:11 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 QQkujz07816 for ; Thu, 21 Jun 2001 16:54:11 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5LGsAh03659 for ; Thu, 21 Jun 2001 09:54:10 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA04193 for mpls@uu.net; Thu, 21 Jun 2001 12:54:09 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkujz03592 for ; Thu, 21 Jun 2001 16:50:17 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 QQkujz00556 for ; Thu, 21 Jun 2001 16:49:39 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkujz03262 for ; Thu, 21 Jun 2001 16:49:39 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA20764 for ; Thu, 21 Jun 2001 12:49:35 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA25472 for ; Thu, 21 Jun 2001 11:30:55 -0400 (EDT) Message-Id: <200106211530.LAA25472@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: LDP-FT - second last call Date: Thu, 21 Jun 2001 11:30:55 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Resending, never saw it come back from the list. ,,,George ------- Forwarded Message To: mpls@uu.net Cc: vijay@cosinecom.com Subject: LDP-FT - second last call Date: Wed, 20 Jun 2001 15:22:32 -0400 From: George Swallow Fault Tolerance for LDP and CR-LDP went through a workgroup last call. It has been updated to address the issued raised. This notice commences a one week last call on the new draft, draft-ietf-mpls-ldp-ft-02.txt The last call is restricted to the issues raised in the prior last call. The last call ends June 27, 12pm GMT. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 ------- End of Forwarded Message From owner-mpls@UU.NET Thu Jun 21 13:05:14 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07288 for ; Thu, 21 Jun 2001 13:05:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuka20653; Thu, 21 Jun 2001 17:05:48 GMT Received: by mail-control.mail.uu.net id QQkuka17745 for mpls-outgoing; Thu, 21 Jun 2001 17:05:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkuka16326 for ; Thu, 21 Jun 2001 17:05: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 QQkuka13718 for ; Thu, 21 Jun 2001 17:04:32 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkuka19227 for ; Thu, 21 Jun 2001 17:04:32 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id C9A9A4E8B; Thu, 21 Jun 2001 13:04:27 -0400 (EDT) Message-ID: <3B32291B.280D73DE@sandburst.com> Date: Thu, 21 Jun 2001 13:04:27 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Robert Streijl Cc: mpls@UU.NET Subject: Re: label stack depth References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert, Please see below. You wrote: > Hi, > > Is there any maximum defined for the depth of a label stack? In effect, a maximum label stack depth is defined by what any specific application considers to be a minimum usable payload and the maximum transmission unit size for the portion of the network that carries packets for this application and is currently under examination. > > What is common, two, three labels, more? Past performance is no guarantee of future results. Most common at this point is probably still zero. Once this is no longer true, the number may be very much higher than 2 or 3. > > > I known that the bottom will indicate the last label. (Theoretically) it > seems that there can be an (indefinite) amount. > Practically it will probably introduce some management complications. > I don't recall having seen any limitations in the drafts and RFCs. What's practical depends in part on the real diameter of the network using MPLS. To get any real utility out of label switching, at least one LSR on any given LSP needs to perform a simple label switch operation based on the top level label. On this basis, you would have to have at least 3 LSRs in a row (discounting PHP or egress pop at a second LSR) before it makes sense to have a stack depth of even 1 label. Beyond this, however, it depends a lot on complexity of the routing (or traffic engineering) topology and the extent to which implementations seeks to take advantage of work previously done in aggregating and deaggregating traffic. For example, you could build a case for a scenario in which a label stack depth of 2 labels is justified for traffic spanning only 4 LSRs, 3 labels for 5 LSRs, and so on. Management complications are limited to the scope of the label stack depth that is managed. If a provider offers a service for transparently transporting opaque (or - to some extent - quasi opaque) data between two points, they need only to manage the labels (if any) that they use to support this service (not any that they may transport using this service). > > > I guess that before transmitted onto the layer 2 transport technology > (e.g. ATM, Ethernet, etc.) it can be fragmented to a size supported by that > transport technology so that should not matter. > > Any insights are welcomed. > > Thanks. > Robert Hope this helps. -- Eric Gray From owner-mpls@UU.NET Thu Jun 21 13:24:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08540 for ; Thu, 21 Jun 2001 13:24:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkukb18828; Thu, 21 Jun 2001 17:22:28 GMT Received: by mail-control.mail.uu.net id QQkukb25564 for mpls-outgoing; Thu, 21 Jun 2001 17:21:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkukb25522 for ; Thu, 21 Jun 2001 17:21:36 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 QQkukb24662 for ; Thu, 21 Jun 2001 17:16:02 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 QQkukb20944 for ; Thu, 21 Jun 2001 17:16:01 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5LHG3h22541 for ; Thu, 21 Jun 2001 10:16:04 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA04466 for mpls@uu.net; Thu, 21 Jun 2001 13:15:58 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkuka24159 for ; Thu, 21 Jun 2001 17:09:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkuka07737 for ; Thu, 21 Jun 2001 17:07:30 GMT Received: from dtctxexchims01.ins.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.164.93.95]) id QQkuka22667 for ; Thu, 21 Jun 2001 17:07:29 GMT Received: from CHIMA ([135.17.52.57]) by dtctxexchims01.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAZTVFAV; Thu, 21 Jun 2001 12:07:27 -0500 Reply-To: From: "Chima Chima" To: "'Roberto Simongini'" , "'Simon Dredge'" Cc: "'Walt Carter'" , "'Hart, Jim'" , "'Chrysostomos Tziouvaras'" , "'mpls'" , "'mpls-ops'" , "'ip-optical'" Subject: RE: DWDM Muxing Date: Thu, 21 Jun 2001 13:19:43 -0400 Message-ID: <006601c0fa76$5d2eb180$39341187@ho.lucent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C0FA54.D61D1180" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Disposition-Notification-To: "Chima Chima" In-Reply-To: <6B9B5F4E1E78D211A3D00000F81A24A502F7A818@zmild002.europe.nortel.com> Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C0FA54.D61D1180 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkukb18828 Content-Transfer-Encoding: quoted-printable RE: DWDM MuxingSimon, Lucent 1.6 T long haul system is capable of 80 channels C-Ban= d and 80 Channel L-Band. This product has already been deployed by Time Warner. Chima E. Chima LWS/ESS/ONG New York City -----Original Message----- From: Roberto Simongini [mailto:simongin@nortelnetworks.com] Sent: Thursday, June 21, 2001 10:25 AM To: Simon Dredge Cc: Walt Carter; Hart, Jim; 'Chrysostomos Tziouvaras'; mpls; mpls-ops; ip-optical Subject: RE: DWDM Muxing Simon, 40 Channels (C-Band) plus 40 (L-Band) are already commercialy availabl= e on OPTEra L(ong) H(aul) DWDM products Family from NORTEL Networks. I may send you (as well as to other colleagues) s= ome Doc if might be of your interest. Regards. Roberto. Roberto Simongini NORTEL NETWORKS S.p.A. Wireless Solutions Engineering Director Unified Networks Solutions Via di Grotta Perfetta, 643 00144 - ROMA Tel: +39-06 5152 XT9234 (ESN 794 9234) Mobile: +39-(0) 348 2611 829 e_mail: simongin@nortelnetworks.com -----Original Message----- From: Walt Carter [mailto:waltcarter@mindspring.com] Sent: gioved=EC 21 giugno 2001 14.56 To: Simon Dredge; Hart, Jim; 'Chrysostomos Tziouvaras'; mpls; mpls-ops; ip-optical Subject: RE: DWDM Muxing In today's DWDM systems, wavelength spacing occurs at 0.8 nm or 100-Ghz steps. Future systems will space wavelengths at 0.4 nm or 50 Ghz, to further increase the capacity of existing fibers. The ITU has set specification= s that list the channel code and wavelength for each optical signal multiplexed into a fiber. Present ITU specs recommend 81 channels, starting at a center frequency of 196.10 THz (1528.77 nm) and decreasing in 80 steps of 50 GHz (~0.39 nm) each. The ITU uses as its starting point a 193.10-= THz reference frequency that corresponds to a spectral line for krypton gas. The ITU specified frequency rather than wavelength because wavelength depen= ds on a transmission medium, and thus it can vary. Frequency is a physical un= it that will not vary as a signal goes from one medium into another, say f= rom glass into air. Regards, Walter S. Carter kSi group, inc (770) 460-2062 Office (678) 362-4504 Mobile 2 WAY: -----Original Message----- From: Simon Dredge [mailto:sdredge@zaffire.com] Sent: Wednesday, June 20, 2001 12:50 PM To: Hart, Jim; 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing I believe 40-Channel Muxes (full c-band) are in the works and will be available soon -----Original Message----- From: Hart, Jim [mailto:Jim_Hart@icgcomm.com] Sent: Wednesday, June 20, 2001 9:09 AM To: 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: RE: DWDM Muxing it depends, but 32 is pretty common -- Jim Hart Director, Data Engineering ICG communications jim_hart@icgcomm.com 303-414-5856 cell- 720-320-0618 -----Original Message----- From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] Sent: Wednesday, June 20, 2001 9:02 AM To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com Subject: DWDM Muxing Hi, do you know what's the state of the art in the number of channels in DW= DM muxers? Thanks Chrysostomos Tziouvaras ICS-FORTH Researcher ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------=_NextPart_000_0067_01C0FA54.D61D1180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DWDM Muxing
Simon,
       &nbs= p;  =20 Lucent 1.6 T  long haul system is capable of 80 channels C-Band and = 80=20 Channel L-Band.
This=20 product has already been deployed by Time Warner.
 
Chima=20 E. Chima
 
LWS/ESS/ONG
New=20 York City
-----Original Message-----
From: Roberto Simongini=20 [mailto:simongin@nortelnetworks.com]
Sent: Thursday, June = 21, 2001=20 10:25 AM
To: Simon Dredge
Cc: Walt Carter; Hart, = Jim;=20 'Chrysostomos Tziouvaras'; mpls; mpls-ops; = ip-optical
Subject: RE:=20 DWDM Muxing

Simon,

40 Channels  (C-Band) plus 40 (L-Band) are = already=20 commercialy available on OPTEra L(ong) H(aul) DWDM products = Family=20
from NORTEL Networks. I may send you (as well as to = other=20 colleagues) some Doc if might be of your interest. Regards. =
Roberto.

Roberto Simongini
NORTEL = NETWORKS=20 S.p.A.
Wireless Solutions Engineering = Director=20
Unified Networks Solutions

Via di Grotta Perfetta, 643
00144 -=20 ROMA

Tel:    +39-06 5152 XT9234 (ESN 794=20 9234)      
Mobile:=20 +39-(0) 348 2611 829 =
       =20 e_mail: simongin@nortelnetworks.com

-----Original Message-----
From: Walt=20 Carter [mailto:waltcarter@mindspring.co= m]=20
Sent: gioved=EC 21 giugno 2001 14.56 =
To: Simon Dredge; Hart, Jim; 'Chrysostomos Tziouvaras'; mpls; = mpls-ops;
ip-optical
Subject:=20 RE: DWDM Muxing


In today's DWDM systems, wavelength spacing occurs = at 0.8 nm=20 or 100-Ghz
steps. Future systems will space=20 wavelengths at 0.4 nm or 50 Ghz, to further
increase=20 the capacity of existing fibers. The ITU has set specifications =
that list the channel code and wavelength for each = optical=20 signal
multiplexed into a fiber. Present ITU = specs=20 recommend 81 channels, starting
at a center = frequency=20 of 196.10 THz (1528.77 nm) and decreasing in 80 steps
of 50 GHz (~0.39 nm) each. The ITU uses as its starting point = a=20 193.10-THz
reference frequency that = corresponds to a=20 spectral line for krypton gas. The
ITU = specified=20 frequency rather than wavelength because wavelength depends on=20
a transmission medium, and thus it can vary. = Frequency is a=20 physical unit
that will not vary as a signal = goes from=20 one medium into another, say from
glass into = air.

Regards,
Walter S. = Carter=20
kSi group, inc
(770) = 460-2062=20 Office
(678) 362-4504 Mobile =
2=20 WAY: <wcarter@ksigroup.net>
<http://www.ksigroup.net/>


-----Original Message-----
From: Simon=20 Dredge [mailto:sdredge@zaffire.com]=20
Sent: Wednesday, June 20, 2001 12:50 PM =
To: Hart, Jim; 'Chrysostomos Tziouvaras'; mpls@UU.NET; =
mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com =
Subject: RE: DWDM Muxing


I believe 40-Channel Muxes (full c-band) are in the = works and=20 will be
available soon

-----Original Message-----
From: Hart,=20 Jim [mailto:Jim_Hart@icgcomm.com]=20
Sent: Wednesday, June 20, 2001 9:09 AM =
To: 'Chrysostomos Tziouvaras'; mpls@UU.NET; = mpls-ops@mplsrc.com;=20
ip-optical@lists.bell-labs.com
Subject: RE: DWDM Muxing


it depends, but 32 is pretty common

--
Jim Hart =
Director, Data Engineering
ICG=20 communications
jim_hart@icgcomm.com =
303-414-5856
cell- = 720-320-0618


-----Original Message-----
From:=20 Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] =
Sent: Wednesday, June 20, 2001 9:02 AM =
To: mpls@UU.NET; mpls-ops@mplsrc.com;=20 ip-optical@lists.bell-labs.com
Subject: DWDM = Muxing


Hi,
do you know what's the = state of=20 the art in the number of channels in DWDM
muxers?

Thanks
Chrysostomos = Tziouvaras=20
ICS-FORTH Researcher


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

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

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

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

------=_NextPart_000_0067_01C0FA54.D61D1180-- From owner-mpls@UU.NET Thu Jun 21 13:54:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10321 for ; Thu, 21 Jun 2001 13:54:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkukd27595; Thu, 21 Jun 2001 17:51:47 GMT Received: by mail-control.mail.uu.net id QQkukd28350 for mpls-outgoing; Thu, 21 Jun 2001 17:51:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkukd28283 for ; Thu, 21 Jun 2001 17:51: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 QQkukd28342 for ; Thu, 21 Jun 2001 17:46:40 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkukd20685 for ; Thu, 21 Jun 2001 17:46:39 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA10184 for mpls@uu.net; Thu, 21 Jun 2001 13:46:37 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkukd27700 for ; Thu, 21 Jun 2001 17:46: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 QQkukc18483 for ; Thu, 21 Jun 2001 17:43:28 GMT Received: from icarian.ZAFFIRE.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: int.zaffire.com [63.121.21.2]) id QQkukc00960 for ; Thu, 21 Jun 2001 17:43:28 GMT Received: by ICARIAN with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 10:43:26 -0700 Message-ID: <4611AD058694D4118FD5009027B0A6620212AA77@ICARIAN> From: Simon Dredge To: Chima_Chima@ins.com, "'Roberto Simongini'" , "'Simon Dredge'" Cc: "'Walt Carter'" , "'Hart, Jim'" , "'Chrysostomos Tziouvaras'" , "'mpls'" , "'mpls-ops'" , "'ip-optical'" Subject: RE: DWDM Muxing Date: Thu, 21 Jun 2001 10:43:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA79.AC5089C0" 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_01C0FA79.AC5089C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry - I thought that Chrysostomos was asking about component-level = DWDM, not system-level (i.e. by muxes, I presumed AWG's). Interested, = though, Re. the 1.6T - Is that using 2 x 80ch. AWG's w/ 10Gbps Channels @ 0.4 nm or = 4 x 40ch AWG's w/10Gbps channels @ 0.8nm interleaved at 50Ghz intervals? I suppose it could even be 4 x 40ch 'banded' AWG's coupled with a = thin-film filter...... anyway, I'm not in the LH optics biz , nor am I an = engineer, so maybe I should keep my mouth shut in the future ;-) =20 =20 =20 =20 -----Original Message----- From: Chima Chima [mailto:Chima_Chima@ins.com] Sent: Thursday, June 21, 2001 10:20 AM To: 'Roberto Simongini'; 'Simon Dredge' Cc: 'Walt Carter'; 'Hart, Jim'; 'Chrysostomos Tziouvaras'; 'mpls'; 'mpls-ops'; 'ip-optical' Subject: RE: DWDM Muxing Simon, Lucent 1.6 T long haul system is capable of 80 channels = C-Band and 80 Channel L-Band. This product has already been deployed by Time Warner. =20 Chima E. Chima =20 LWS/ESS/ONG New York City -----Original Message----- From: Roberto Simongini [mailto:simongin@nortelnetworks.com] Sent: Thursday, June 21, 2001 10:25 AM To: Simon Dredge Cc: Walt Carter; Hart, Jim; 'Chrysostomos Tziouvaras'; mpls; mpls-ops; ip-optical Subject: RE: DWDM Muxing Simon,=20 40 Channels (C-Band) plus 40 (L-Band) are already commercialy = available on OPTEra L(ong) H(aul) DWDM products Family=20 from NORTEL Networks. I may send you (as well as to other colleagues) = some Doc if might be of your interest. Regards.=20 Roberto.=20 Roberto Simongini=20 NORTEL NETWORKS S.p.A.=20 Wireless Solutions Engineering Director=20 Unified Networks Solutions=20 Via di Grotta Perfetta, 643=20 00144 - ROMA=20 Tel: +39-06 5152 XT9234 (ESN 794 9234) =20 Mobile: +39-(0) 348 2611 829=20 e_mail: simongin@nortelnetworks.com=20 -----Original Message-----=20 From: Walt Carter [ mailto:waltcarter@mindspring.com ]=20 Sent: gioved=EC 21 giugno 2001 14.56=20 To: Simon Dredge; Hart, Jim; 'Chrysostomos Tziouvaras'; mpls; mpls-ops; = ip-optical=20 Subject: RE: DWDM Muxing=20 In today's DWDM systems, wavelength spacing occurs at 0.8 nm or 100-Ghz = steps. Future systems will space wavelengths at 0.4 nm or 50 Ghz, to = further increase the capacity of existing fibers. The ITU has set = specifications=20 that list the channel code and wavelength for each optical signal=20 multiplexed into a fiber. Present ITU specs recommend 81 channels, = starting=20 at a center frequency of 196.10 THz (1528.77 nm) and decreasing in 80 = steps=20 of 50 GHz (~0.39 nm) each. The ITU uses as its starting point a = 193.10-THz=20 reference frequency that corresponds to a spectral line for krypton = gas. The ITU specified frequency rather than wavelength because wavelength = depends on a transmission medium, and thus it can vary. Frequency is a physical = unit=20 that will not vary as a signal goes from one medium into another, say = from=20 glass into air.=20 Regards,=20 Walter S. Carter=20 kSi group, inc=20 (770) 460-2062 Office=20 (678) 362-4504 Mobile=20 2 WAY: =20 < http://www.ksigroup.net/ >=20 -----Original Message-----=20 From: Simon Dredge [ mailto:sdredge@zaffire.com = ]=20 Sent: Wednesday, June 20, 2001 12:50 PM=20 To: Hart, Jim; 'Chrysostomos Tziouvaras'; mpls@UU.NET;=20 mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com=20 Subject: RE: DWDM Muxing=20 I believe 40-Channel Muxes (full c-band) are in the works and will be=20 available soon=20 -----Original Message-----=20 From: Hart, Jim [ mailto:Jim_Hart@icgcomm.com = ]=20 Sent: Wednesday, June 20, 2001 9:09 AM=20 To: 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com;=20 ip-optical@lists.bell-labs.com=20 Subject: RE: DWDM Muxing=20 it depends, but 32 is pretty common=20 --=20 Jim Hart=20 Director, Data Engineering=20 ICG communications=20 jim_hart@icgcomm.com=20 303-414-5856=20 cell- 720-320-0618=20 -----Original Message-----=20 From: Chrysostomos Tziouvaras [ mailto:tziou@ics.forth.gr ]=20 Sent: Wednesday, June 20, 2001 9:02 AM=20 To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com=20 Subject: DWDM Muxing=20 Hi,=20 do you know what's the state of the art in the number of channels in = DWDM=20 muxers?=20 Thanks=20 Chrysostomos Tziouvaras=20 ICS-FORTH Researcher=20 -------=20 The MPLS-OPS Mailing List=20 Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml =20 Archive: http://www.mplsrc.com/mpls-ops_archive.shtml =20 -------=20 The MPLS-OPS Mailing List=20 Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml =20 Archive: http://www.mplsrc.com/mpls-ops_archive.shtml =20 -------=20 The MPLS-OPS Mailing List=20 Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml =20 Archive: http://www.mplsrc.com/mpls-ops_archive.shtml =20 -------=20 The MPLS-OPS Mailing List=20 Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml =20 Archive: http://www.mplsrc.com/mpls-ops_archive.shtml =20 ------_=_NextPart_001_01C0FA79.AC5089C0 Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkukd27595 Content-Transfer-Encoding: quoted-printable RE: DWDM Muxing
Sorry -= I thought=20 that Chrysostomos was ask= ing about=20 component-level DWDM, not system-level (i.e. by muxes, I presumed AWG's).= =20  Interested, though, Re. the 1.6T - Is that using= 2 x=20 80ch. AWG's w/ 10Gbps Channels @ 0.4 nm or 4 x 40ch AWG's w/10Gbps=20 channels @ 0.8nm interleaved at 50Ghz intervals? I suppose it could = even be=20 4 x 40ch 'banded' AWG's coupled with a thin-film filter...... anyway, I'm= not in=20 the LH optics biz , nor am I an engineer, so maybe I should keep my mouth= shut=20 in the future ;-)
 
 =
 =
 =
-----Original Message-----
From: Chima Chima=20 [mailto:Chima_Chima@ins.com]
Sent: Thursday, June 21, 2001 10= :20=20 AM
To: 'Roberto Simongini'; 'Simon Dredge'
Cc: 'Wal= t=20 Carter'; 'Hart, Jim'; 'Chrysostomos Tziouvaras'; 'mpls'; 'mpls-ops';=20 'ip-optical'
Subject: RE: DWDM Muxing

Simon,
       &n= bsp;  =20 Lucent 1.6 T  long haul system is capable of 80 channels C-Band an= d 80=20 Channel L-Band.
This=20 product has already been deployed by Time Warner.
 
Chima E. Chima
 
LWS/ESS/ONG
New=20 York City
-----Original Message-----
From: Roberto Simongini= =20 [mailto:simongin@nortelnetworks.com]
Sent: Thursday, June 2= 1, 2001=20 10:25 AM
To: Simon Dredge
Cc: Walt Carter; Hart, = Jim;=20 'Chrysostomos Tziouvaras'; mpls; mpls-ops; ip-optical
Subject:<= /B> RE:=20 DWDM Muxing

Simon,

40 Channels  (C-Band) plus 40 (L-Band) are alr= eady=20 commercialy available on OPTEra L(ong) H(aul) DWDM products Family=20
from NORTEL Networks. I may send you (as well as t= o other=20 colleagues) some Doc if might be of your interest. Regards. Roberto.

Roberto Simongini
NORTEL = NETWORKS=20 S.p.A.
Wireless Solutions Engineering=20 Director
Unified Networks Solutions =

Via di Grotta Perfetta, 643
00144 -=20 ROMA

Tel:    +39-06 5152 XT9234 (ESN 794=20 9234)      
M= obile:=20 +39-(0) 348 2611 829
      &= nbsp;=20 e_mail: simongin@nortelnetworks.com

-----Original Message-----
From:=20 Walt Carter [mailto:waltcarter@mindsprin= g.com]=20
Sent: gioved=EC 21 giugno 2001 14.56
To: Simon Dredge; Hart, Jim; 'Chrysostomos Tziouvaras'; mpls= ;=20 mpls-ops;
ip-optical
Subject: RE: DWDM Muxing


In today's DWDM systems, wavelength spacing occurs = at 0.8 nm=20 or 100-Ghz
steps. Future systems will space= =20 wavelengths at 0.4 nm or 50 Ghz, to further
increase=20 the capacity of existing fibers. The ITU has set specifications=20
that list the channel code and wavelength for each= optical=20 signal
multiplexed into a fiber. Present IT= U specs=20 recommend 81 channels, starting
at a center= =20 frequency of 196.10 THz (1528.77 nm) and decreasing in 80 steps=20
of 50 GHz (~0.39 nm) each. The ITU uses as its sta= rting=20 point a 193.10-THz
reference frequency that= =20 corresponds to a spectral line for krypton gas. The
ITU specified frequency rather than wavelength because wavel= ength=20 depends on
a transmission medium, and thus = it can=20 vary. Frequency is a physical unit
that wil= l not=20 vary as a signal goes from one medium into another, say from=20
glass into air.

Regards,
Walter S. Carter= =20
kSi group, inc
(770) 460= -2062=20 Office
(678) 362-4504 Mobile
2 WAY: <wcarter@ksigroup.net>
<http://www.ksigroup.net/>=20


-----Original Message-----
From:=20 Simon Dredge [mailto:sdredge@zaffire.com]=20
Sent: Wednesday, June 20, 2001 12:50 PM To: Hart, Jim; 'Chrysostomos Tziouvaras'; mpls@UU.NET;=20
mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.co= m=20
Subject: RE: DWDM Muxing


I believe 40-Channel Muxes (full c-band) are in the= works=20 and will be
available soon

-----Original Message-----
From:=20 Hart, Jim [mailto:Jim_Hart@icgcomm.com]= =20
Sent: Wednesday, June 20, 2001 9:09 AM
= To: 'Chrysostomos Tziouvaras'; mpls@UU.NET;=20 mpls-ops@mplsrc.com;
ip-optical@lists.bell-labs.com
Sub= ject: RE:=20 DWDM Muxing


it depends, but 32 is pretty common

--
Jim Hart
Director, Data Engineering
ICG=20 communications
jim_hart@icgcomm.com =
303-414-5856
cell- 720-320-0618=20


-----Original Message-----
From:=20 Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr]=20
Sent: Wednesday, June 20, 2001 9:02 AM
= To: mpls@UU.NET; mpls-ops@mplsrc.com;=20 ip-optical@lists.bell-labs.com
Subject: DWD= M=20 Muxing


Hi,
do you know what's th= e state of=20 the art in the number of channels in DWDM
muxers?

Thanks
Chrysostomos=20 Tziouvaras
ICS-FORTH Researcher

=

-------
The MPLS-OPS Mail= ing=20 List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mp= lsops.shtml=20
Archive: http://www.mpls= rc.com/mpls-ops_archive.shtml=20

-------
The MPLS-OPS Mail= ing=20 List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mp= lsops.shtml=20
Archive: http://www.mpls= rc.com/mpls-ops_archive.shtml=20

-------
The MPLS-OPS Mail= ing=20 List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mp= lsops.shtml=20
Archive: http://www.mpls= rc.com/mpls-ops_archive.shtml=20

-------
The MPLS-OPS Mail= ing=20 List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mp= lsops.shtml=20
Archive: http://www.mpls= rc.com/mpls-ops_archive.shtml=20

------_=_NextPart_001_01C0FA79.AC5089C0-- From owner-mpls@UU.NET Thu Jun 21 13:56:14 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10430 for ; Thu, 21 Jun 2001 13:56:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkukd15038; Thu, 21 Jun 2001 17:53:22 GMT Received: by mail-control.mail.uu.net id QQkukd28536 for mpls-outgoing; Thu, 21 Jun 2001 17:52:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkukd28494 for ; Thu, 21 Jun 2001 17:52: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 QQkukd13773 for ; Thu, 21 Jun 2001 17:51:51 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQkukd07976 for ; Thu, 21 Jun 2001 17:51:51 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LHpoR10915 for ; Thu, 21 Jun 2001 13:51:51 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5LHpoQ10875 for ; Thu, 21 Jun 2001 13:51:50 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 19:51:49 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0CB60EDB@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Chrysostomos Tziouvaras'" , mpls-wg , "Hart, Jim" Subject: RE: DWDM Muxing Date: Thu, 21 Jun 2001 19:51:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Why does all this Optical related stuff have to be copied to the MPLS WG??? Bert > ---------- > From: Hart, Jim[SMTP:Jim_Hart@icgcomm.com] > Sent: Wednesday, June 20, 2001 6:08 PM > To: 'Chrysostomos Tziouvaras'; mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com > Subject: RE: DWDM Muxing > > it depends, but 32 is pretty common > > -- > Jim Hart > Director, Data Engineering > ICG communications > jim_hart@icgcomm.com > 303-414-5856 > cell- 720-320-0618 > > > -----Original Message----- > From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] > Sent: Wednesday, June 20, 2001 9:02 AM > To: mpls@UU.NET; mpls-ops@mplsrc.com; ip-optical@lists.bell-labs.com > Subject: DWDM Muxing > > > Hi, > do you know what's the state of the art in the number of channels in DWDM > muxers? > > Thanks > Chrysostomos Tziouvaras > ICS-FORTH Researcher > > > ------- > 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 Thu Jun 21 14:29:23 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12823 for ; Thu, 21 Jun 2001 14:29:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkukf05704; Thu, 21 Jun 2001 18:26:50 GMT Received: by mail-control.mail.uu.net id QQkukf21198 for mpls-outgoing; Thu, 21 Jun 2001 18:25:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkukf21177 for ; Thu, 21 Jun 2001 18:25:49 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 QQkukf22833 for ; Thu, 21 Jun 2001 18:21:46 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkukf09321 for ; Thu, 21 Jun 2001 18:21:45 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5LILpx10920 for ; Thu, 21 Jun 2001 11:21:51 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA05001 for mpls@uu.net; Thu, 21 Jun 2001 14:21:44 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkukf20665 for ; Thu, 21 Jun 2001 18:19: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 QQkuke17450 for ; Thu, 21 Jun 2001 18:14:16 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkuke28910 for ; Thu, 21 Jun 2001 18:14:16 GMT Received: from kishan (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11]) by acc.com (8.11.1/8.11.1) with SMTP id f5LIBNl28601 for ; Thu, 21 Jun 2001 11:11:23 -0700 (PDT) Reply-To: From: "Hari Kishan" To: Subject: FEC 0 ?? Date: Thu, 21 Jun 2001 11:09:48 -0700 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Is FEC 0 (Zero) a valid FEC ?? For me it seems like a valid FEC. If an LSR sends a label request for FEC 0, it can result in the establishment of a LSP which ends at the default traffic exit point of the MPLS domain. Any Comments?? What could be a value for Invalid FEC ?? --------------------------------- Hari Kishan Desineni, Ericsson Inc, Data Backbone & Optical Division, Santabarbara, California - 93117 Office:(805) 562 6419 Home:(805) 968 1894 From owner-mpls@UU.NET Thu Jun 21 14:43:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13713 for ; Thu, 21 Jun 2001 14:43:18 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkukg14192; Thu, 21 Jun 2001 18:41:20 GMT Received: by mail-control.mail.uu.net id QQkukg22813 for mpls-outgoing; Thu, 21 Jun 2001 18:40:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkukg22780 for ; Thu, 21 Jun 2001 18:40:24 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 QQkukg28437 for ; Thu, 21 Jun 2001 18:39:56 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkukg28241 for ; Thu, 21 Jun 2001 18:39:55 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5LIdsh03049 for ; Thu, 21 Jun 2001 11:39:54 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA05105 for mpls@uu.net; Thu, 21 Jun 2001 14:39:53 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkukg22619 for ; Thu, 21 Jun 2001 18:38:16 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 QQkukg21414 for ; Thu, 21 Jun 2001 18:37:27 GMT Received: from hawk.mail.pas.earthlink.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hawk.mail.pas.earthlink.net [207.217.120.22]) id QQkukg28835 for ; Thu, 21 Jun 2001 18:37:26 GMT Received: from ANDREWHOME (user-vcauoft.dsl.mindspring.com [216.175.97.253]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id LAA08149; Thu, 21 Jun 2001 11:37:22 -0700 (PDT) Reply-To: From: "Andrew Smith" To: , , Cc: , , "Hegde, Shriharsha" , Subject: RE: MPLS and COPS Date: Thu, 21 Jun 2001 11:53:04 -0700 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.2911.0) In-reply-to: <4148FEAAD879D311AC5700A0C969E8900655DDBB@orsmsx35.jf.intel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit If: (a) none of the existing WGs want the work item (b) there are willing and able people to do the work (c) it doesn't overlap with other work (d) it is a legitimate, missing piece of what seems to be a popular (proposed) standard then find a friendly AD (doesn't seem to matter which Area), hold a BoF, if anyone shows up for the BoF ask to form a WG and go from there. Don't let the unwillingness of existing WGs (or their chairs or their ADs) stop a piece of work that people, both vendors and consumers, want to see standardised. Fran and Harsha, you know the process - just get the work done. My 2c. Andrew P.S. There's no such thing as "policy" - it's just network management. It would be irresponsible for the IESG to hold back this legitimate piece of standards' work. -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of Hegde, Shriharsha Sent: Thursday, June 21, 2001 9:38 AM To: 'Ritu Chadha'; franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET; te-wg@ops.ietf.org; sganguly@carrier9.com Cc: policy@raleigh.ibm.com; rap@ops.ietf.org Subject: RE: MPLS and COPS Just like Diffserv MIB and Diffserv PIB are in Diffserv working group, I support the notion of having a TE PIB in parallel to TE MIB in TE WG. I believe PIB approach is the right direction to take for policy/administrative control over MPLS/TE. harsha PS: I have not followed the TE WG discussion which took place months ago about the ADs deciding that policy should not be in TEWG charter. -----Original Message----- From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com] Sent: Tuesday, June 12, 2001 12:50 PM To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET; te-wg@ops.ietf.org; sganguly@carrier9.com Cc: chadha@mailee.research.telcordia.com; policy@raleigh.ibm.com Subject: RE: MPLS and COPS Well, I can't comment on that except to say that I'm completely in agreement with you. You should direct your concerns to the ADs. Randy? Ritu >From: "Sukanta Ganguly" >To: "Ritu Chadha" , , , , >Subject: RE: MPLS and COPS >Date: Tue, 12 Jun 2001 11:50:35 -0700 >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >Importance: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 >X-Loop-Detect: 1 > >Ritu, > I see what you are saying and I did read some of them emails but it is >needed. I mean I don't get it (:-)). Why not have a way for TE to take in >some higher layer knowledge to perform smart engineering. There is a lot of >knowledge that can be conveyed to the lower layers from the applications >sitting on top. > > >Sukanta Ganguly >Senior Architect >Carrier9 Networks >Phone (408)-746-0400 x 119 >FAx (408)-730-9441 > >-----Original Message----- >From: Ritu Chadha [mailto:chadha@mailee.research.telcordia.com] >Sent: Tuesday, June 12, 2001 11:16 AM >To: franr@pfn.com; Olivier.Dugeon@rd.francetelecom.com; mpls@UU.NET; >te-wg@ops.ietf.org; sganguly@carrier9.com >Cc: chadha@mailee.research.telcordia.com >Subject: RE: MPLS and COPS > > >Been there, tried that :-). > >This was discussed at some length a few months ago on the tewg mailing list. >The ADs did not see policy as an area that fitted within the TE WG charter >at that time. > >Ritu > >>From: "Sukanta Ganguly" >>To: "Fran Reichmeyer" , "'Olivier Dugeon '" >, , >>Subject: RE: MPLS and COPS >>Date: Tue, 12 Jun 2001 10:51:26 -0700 >>MIME-Version: 1.0 >>Content-Transfer-Encoding: 7bit >>X-Priority: 3 (Normal) >>X-MSMail-Priority: Normal >>Importance: Normal >>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 >>X-Loop-Detect: 1 >> >>Maybe the TE group should be the place for this. Clearly policies should be >>an important traffic engineering operation. >> >>SG >> >>-----Original Message----- >>From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On >>Behalf Of Fran Reichmeyer >>Sent: Tuesday, June 12, 2001 6:54 AM >>To: 'Olivier Dugeon '; 'mpls@UU.NET '; 'te-wg@ops.ietf.org ' >>Subject: RE: MPLS and COPS >> >> >>After several attempts at introducing this to the wg, it >>was decided that policy is out of scope for the MPLS wg at this >>time. >>-Fran >> >> >>-----Original Message----- >>From: Olivier Dugeon >>To: mpls@UU.NET; te-wg@ops.ietf.org >>Sent: 6/12/01 4:28 AM >>Subject: MPLS and COPS >> >>Hi all, >> >>In a context of QoS control in a multi-domain and multi-technology >>network, we would use COPS as the control protocol rather than SNMP. >>COPS need a "Policy rules Information Base" to work. A such PIB is >>available for DiffServ for example. I would to know if somebody work on >>a PIB for MPLS. >> >>- Is there some case study inside the WG or it is out the scope/out of >>date ? >>- Is there a new version of the draft "draft-franr-mpls-cops-00.txt" ? >> >>Thank's a lot >> >>Olivier Dugeon >>-- >> FTR&D/DAC/CPN >> Technopole Anticipa | mailto:Olivier.Dugeon@francetelecom.com >> 2, Avenue Pierre Marzin | Phone: +(33) 2 96 05 28 80 >> F-22307 LANNION | Fax: +(33) 2 96 05 18 52 >> > ============================================================================ = Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1A-216R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================ = From owner-mpls@UU.NET Thu Jun 21 15:00:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14210 for ; Thu, 21 Jun 2001 14:59:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkukh24504; Thu, 21 Jun 2001 18:58:58 GMT Received: by mail-control.mail.uu.net id QQkukh24990 for mpls-outgoing; Thu, 21 Jun 2001 18:58:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkukh24967 for ; Thu, 21 Jun 2001 18:58:00 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 QQkukh24945 for ; Thu, 21 Jun 2001 18:57:05 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkukh26685 for ; Thu, 21 Jun 2001 18:57:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA16471 for mpls@uu.net; Thu, 21 Jun 2001 14:57:03 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkukh24861 for ; Thu, 21 Jun 2001 18:56:39 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 QQkukh10729 for ; Thu, 21 Jun 2001 18:49:35 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkukh16657 for ; Thu, 21 Jun 2001 18:49:35 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA16993; Thu, 21 Jun 2001 14:49:34 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA13093; Thu, 21 Jun 2001 14:36:30 -0400 (EDT) Message-Id: <200106211836.OAA13093@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Jason Rosengren cc: "'mpls@uu.net'" , swallow@cisco.com Subject: Re: question regarding RSVP-TE In-reply-to: Your message of "Wed, 20 Jun 2001 12:25:54 EDT." Date: Thu, 21 Jun 2001 14:36:30 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Date: Thu, 21 Jun 2001 10:20:14 -0400 From: George Swallow > Hi > > I have a question regarding the PATH message and subsequent RESV message in > RSVP-TE. > On sending a number of PATH messages each having the same tunnel_id and > various LSP-IDs. Should the egress return only one RESV with a number of > filter_specs for all lsp_id or should there be a number of RESVs returned > each with their own filter_spec corresponding to one lsp_id? > > Both scenarios seem to be valid. Both scenarios are valid. Note also that this actually has nothing to do with RSVP-TE per se, it is equally true for RSVP. > I hope to get this clarified. > > Thanks > Jason ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jun 21 20:06:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20813 for ; Thu, 21 Jun 2001 20:06:22 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkulc10897; Fri, 22 Jun 2001 00:05:28 GMT Received: by mail-control.mail.uu.net id QQkulc11796 for mpls-outgoing; Fri, 22 Jun 2001 00:03:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkulc11669 for ; Fri, 22 Jun 2001 00:03:33 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 QQkulc05031 for ; Fri, 22 Jun 2001 00:03:12 GMT Received: from cpimssmtpoa01.msn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc12877 for ; Fri, 22 Jun 2001 00:03:12 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:11 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:08 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.222] by hotmail.com (3.2) with ESMTP id MHotMailBCEF10F10057400421C3CF2EC1DE09492; Tue Jun 12 00:34:15 2001 Message-ID: <461201c0faae$b7cf3f00$0e03ca0a@cp98suwbm02> Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by cpimssmtpc03.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 00:34:17 -0700 Content-Transfer-Encoding: 7bit Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbi13684; Tue, 12 Jun 2001 07:33:57 GMT X-Mailer: Microsoft CDO for Windows 2000 Received: by mail-control.mail.uu.net id QQktbi13768 for mpls-outgoing; Tue, 12 Jun 2001 07:33:28 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktbi13754 for ; Tue, 12 Jun 2001 07:33: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 QQktbi05270 for ; Tue, 12 Jun 2001 07:31:50 GMT From: Received: from hindon.hss.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQktbi19127 for ; Tue, 12 Jun 2001 07:31:48 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5C6qrE25843; Tue, 12 Jun 2001 12:22:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A69.00244A9C ; Tue, 12 Jun 2001 12:06:23 +0530 X-Lotus-FromDomain: HSS To: Cc: "'Manoj Dutta'" , Date: Thu, 21 Jun 2001 17:03:08 -0700 Subject: RE: Label Mapping !! MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-OriginalArrivalTime: 12 Jun 2001 07:34:17.0943 (UTC) FILETIME=[16894670:01C0F312] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi! IMHO this is not correct as the LSR from which the label mapping has beeen learnt can never be the upstream LSR for the same mapping - liberal or conservative mode notwithstanding. regards sumit "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on 06/12/2001 12:02:39 PM To: "'Manoj Dutta'" , mpls@UU.NET cc: (bcc: Sumit Chauhan/HSS) Subject: RE: Label Mapping !! Hi, > I had some doubts in RFC 3036. In section A.1.2, LMp.17 and A.1.6 > FEC.1, an LSR seems to send mappings for a given FEC to the next hop > for the same FEC. If so, why ? As I understand it, this is due to the existance of liberal mode : in case of LDP reconstuction, the former Next Hop (downstrem located) may become a LSR upstream located. Rigth? Thierry From owner-mpls@UU.NET Thu Jun 21 20:07:57 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20844 for ; Thu, 21 Jun 2001 20:07:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkulc12724; Fri, 22 Jun 2001 00:06:34 GMT Received: by mail-control.mail.uu.net id QQkulc11982 for mpls-outgoing; Fri, 22 Jun 2001 00:03:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkulc11676 for ; Fri, 22 Jun 2001 00:03:33 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 QQkulc05024 for ; Fri, 22 Jun 2001 00:03:12 GMT Received: from cpimssmtpoa01.msn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc12861 for ; Fri, 22 Jun 2001 00:03:12 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:11 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:08 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.220] by hotmail.com (3.2) with ESMTP id MHotMailBCEF0A8F00A54004204BCF2EC1DC132A0; Tue Jun 12 00:06:55 2001 Message-ID: <460f01c0faae$b7b77140$0e03ca0a@cp98suwbm02> Content-Transfer-Encoding: 7bit Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by cpimssmtpc01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 00:09:10 -0700 Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbg00165; Tue, 12 Jun 2001 07:08:46 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: by mail-control.mail.uu.net id QQktbg03806 for mpls-outgoing; Tue, 12 Jun 2001 07:08:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktbg03323 for ; Tue, 12 Jun 2001 07:08:05 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 QQktbg28602 for ; Tue, 12 Jun 2001 07:06:48 GMT Received: from p-mail2.cnet.fr by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: p-mail2.rd.francetelecom.fr [193.49.124.32]) id QQktbg28169 for ; Tue, 12 Jun 2001 07:06:48 GMT Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 09:06:23 +0200 From: "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" To: Cc: Subject: RE: Label Mapping !! Date: Thu, 21 Jun 2001 17:03:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 12 Jun 2001 07:09:10.0263 (UTC) FILETIME=[93E39070:01C0F30E] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit HI, > hi! > IMHO this is not correct as the LSR from which the label > mapping has beeen > learnt can never be the upstream LSR for the same mapping - liberal or > conservative mode notwithstanding. Even if the IGP completely change the route for the FEC? e.g. If the network is ------- / \ A----B----C----D | | \----E First, the Path from A to E may be A B C D E. In this case, ------- / \ A-->-B-->-C-->-D | \|/ \----E hence, C is upstream with respect to D : C uses the label distributed by D. If the path from A to E changed to A B D C E. In this case, --->--- / \ A-->-B----C--<-D \|/ | \----E here, D is upstream with respect to C : D uses the label distributed by C. Finally, in liberal mode, if C has distributed a label to D (in the first case, where D was the Next Hop for C), it can use it directly. This is a quite strange case but it seems to be ok. Thierry From owner-mpls@UU.NET Thu Jun 21 20:08:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20860 for ; Thu, 21 Jun 2001 20:08:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkulc14675; Fri, 22 Jun 2001 00:07:51 GMT Received: by mail-control.mail.uu.net id QQkulc12094 for mpls-outgoing; Fri, 22 Jun 2001 00:03:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkulc11707 for ; Fri, 22 Jun 2001 00:03: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 QQkulc19884 for ; Fri, 22 Jun 2001 00:03:17 GMT Received: from cpimssmtpoa01.msn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc12951 for ; Fri, 22 Jun 2001 00:03:16 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:15 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:12 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.222] by hotmail.com (3.2) with ESMTP id MHotMailBCEF74CA00C24004204CCF2EC1DE10AF16; Tue Jun 12 07:40:17 2001 Message-ID: <466601c0faae$ba319900$0e03ca0a@cp98suwbm02> Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by cpimssmtpc03.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 07:43:36 -0700 Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktck03709; Tue, 12 Jun 2001 14:43:12 GMT Received: by mail-control.mail.uu.net id QQktck14683 for mpls-outgoing; Tue, 12 Jun 2001 14:42:43 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktck14675 for ; Tue, 12 Jun 2001 14:42:37 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 QQktck12573 for ; Tue, 12 Jun 2001 14:40:49 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktck01041 for ; Tue, 12 Jun 2001 14:40:49 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id B71519400B; Tue, 12 Jun 2001 10:40:48 -0400 (EDT) Date: Thu, 21 Jun 2001 17:03:12 -0700 From: "Eric Gray" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Cc: "Sumit" , Subject: Re: Label Mapping !! References: <98388C05D464D111B61800805F150416029AB381@p-ibis.rd.francetelecom.fr> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2001 14:43:36.0954 (UTC) FILETIME=[101A6DA0:01C0F34E] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thierry/Sumit/Manoj, Consider the following simple analysis: o assume that a router has N interfaces for routing in a given routing domain o assume (for simplicity) it is not multipathing on any of these interfaces o then - for any specific FEC - o it has exactly one output interface to a nexthop for that FEC o it has N-1 interfaces over which it might receive a packet destined for that nexthop and FEC o and, if there is a route change that changes the nexthop, then one of the N-1 previously upstream peers MUST be the new nexthop. Therefore, it does not take a strange case to produce a scenario in which a router that was forwarding packets to another becomes the next hop for those same packets. -- Eric Gray So far, it has been writ: > HI, > > hi! > > IMHO this is not correct as the LSR from which the label > > mapping has beeen > > learnt can never be the upstream LSR for the same mapping - liberal or > > conservative mode notwithstanding. > > Even if the IGP completely change the route for the FEC? > > e.g. > > If the network is ------- > / \ > A----B----C----D > | | > \----E > > > First, the Path from A to E may be A B C D E. In this case, > ------- > / \ > A-->-B-->-C-->-D > | \|/ > \----E > hence, C is upstream with respect to D : C uses the label distributed by D. > > If the path from A to E changed to A B D C E. In this case, > --->--- > / \ > A-->-B----C--<-D > \|/ | > \----E > here, D is upstream with respect to C : D uses the label distributed by C. > > Finally, in liberal mode, if C has distributed a label to D (in the first > case, where D was the Next Hop for C), it can use it directly. > > This is a quite strange case but it seems to be ok. > > Thierry > From owner-mpls@UU.NET Thu Jun 21 20:09:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20876 for ; Thu, 21 Jun 2001 20:09:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkulc16524; Fri, 22 Jun 2001 00:08:59 GMT Received: by mail-control.mail.uu.net id QQkulc12155 for mpls-outgoing; Fri, 22 Jun 2001 00:04:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkulc11713 for ; Fri, 22 Jun 2001 00:03: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 QQkulc19883 for ; Fri, 22 Jun 2001 00:03:17 GMT Received: from cpimssmtpoa01.msn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc12947 for ; Fri, 22 Jun 2001 00:03:16 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:15 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:12 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.224] by hotmail.com (3.2) with ESMTP id MHotMailBCEF715C0073400421C4CF2EC1E010FA3; Tue Jun 12 07:25:37 2001 Message-ID: <466301c0faae$ba175a40$0e03ca0a@cp98suwbm02> Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by cpimssmtpc05.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 07:25:37 -0700 Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcj17109; Tue, 12 Jun 2001 14:25:15 GMT Received: by mail-control.mail.uu.net id QQktcj13121 for mpls-outgoing; Tue, 12 Jun 2001 14:24:45 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktcj13116 for ; Tue, 12 Jun 2001 14:24:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktcj09159 for ; Tue, 12 Jun 2001 14:22:56 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktcj11246 for ; Tue, 12 Jun 2001 14:22:56 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 1863C9400B; Tue, 12 Jun 2001 10:22:51 -0400 (EDT) Date: Thu, 21 Jun 2001 17:03:11 -0700 From: "Eric Gray" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Cc: Subject: Re: Section A.1.2 RFC 3036 concerns! References: <65256A69.002AA10F.00@sandesh.hss.hns.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2001 14:25:37.0576 (UTC) FILETIME=[8CBE6A80:01C0F34B] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit suchauhan@hss.hns.com wrote: > Hi! > I have a few concerns regarding the algo defined in this section > > 1. LMp.10 - In this case should we not consider this as a dual purpose message > for the release of the previous label and installing the new label generated by > the same downstream LSR. I strongly think it gives a better logic to the > situation here as we have confirmed already that this is from our current > next-hop for that FEC. No. See "http://cell.onecall.net/mhonarc/mpls/current/msg00004.html", second paragraph in particular. > > > 2. LMp.14 - How do we actually define a Ingress LSR? In my opinion any LSR > should be able to act as Ingress atleast till the point the network IGP comes > into stable state as till that point packets to the same destination may be > coming from different Ingress routers. I would probably use something like - For > the LMp.14 case we should have a FTN entry created and then time it out using > say LRU algorithm to keep the size of FTN in check. Am I correct? Out of scope for specification. This falls under the heading of 'figure it out or find another line of work'. :-) (Your opinion on who must be an Ingress is not technically correct. Apply the same reasoning to who must be an egress, and you may find some satisfaction) See any of about a thousand postings on Label Edge Router functionality, over the last 2 years. > > > 3. LMp.17 - Why do we need to send this also to the Peer LSR fro which the > mapping has been learnt? Someone has raised the question earlier as well but I > am still not convinced about the right approach here. See note 7 - as it already says. > > > 4. LMp.21 - In the message sent should not "PrevAdvLabel" be just "Label". We > are only sending the current mapping and not the previous one here. No. We are re-advertising the same label - in case there is a change in hop count or path vector. > > > 5. Lmp.28 - Should this not be done before LMp.20 so that we may not have to > resend to the same peer twice (once because we are in DU mode and again when we > realise we also have an outstanding request for a label from the same peer). I > know this will not cause a problem as the peer will reject the second mapping > but seems an awful waste of processing and network bandwidth (same as in point 1 > above). No. Assume we are operating in DU advertisement, ordered control, mode. If we have an outstanding request from an LSR peer that is upstream with respect to a particular FEC, then it MUST be because the upstream LSR is looking for at least two labels. The label advertisement mode is negotiated between peers and both must use the mode negotiated. Therefore, for an LSR that is operating in DU mode to send a label request, it must expect at least two label mappings. The current procedure arrives at the correct behavior. > > > regards > sumit From owner-mpls@UU.NET Thu Jun 21 20:11:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20921 for ; Thu, 21 Jun 2001 20:11:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkulc18632; Fri, 22 Jun 2001 00:10:17 GMT Received: by mail-control.mail.uu.net id QQkulc12224 for mpls-outgoing; Fri, 22 Jun 2001 00:04:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkulc11718 for ; Fri, 22 Jun 2001 00:03:35 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 QQkulc19740 for ; Fri, 22 Jun 2001 00:03:10 GMT Received: from cpimssmtpoa01.msn.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc13687 for ; Fri, 22 Jun 2001 00:03:09 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:09 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:05 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.220] by hotmail.com (3.2) with ESMTP id MHotMailBCEED6AA00504004204FCF2EC1DC052E14; Mon Jun 11 20:25:46 2001 Message-ID: <45e501c0faae$b6674a90$0e03ca0a@cp98suwbm02> Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by cpimssmtpc01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Mon, 11 Jun 2001 20:23:55 -0700 Content-Transfer-Encoding: 7bit Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktar07584; Tue, 12 Jun 2001 03:23:32 GMT X-Mailer: Microsoft CDO for Windows 2000 Received: by mail-control.mail.uu.net id QQktar27463 for mpls-outgoing; Tue, 12 Jun 2001 03:23:02 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktar27452 for ; Tue, 12 Jun 2001 03:22: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 QQktar17920 for ; Tue, 12 Jun 2001 03:22:47 GMT Received: from localhost.localdomain by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQktar13053 for ; Tue, 12 Jun 2001 03:22:44 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f5C3Piq01550; Tue, 12 Jun 2001 08:55:45 +0530 Date: Thu, 21 Jun 2001 17:03:05 -0700 From: "Nagendra Singh Tomar" Reply-To: To: Cc: , , Subject: Re: Error in RFC 3036?? In-Reply-To: <200106111122.HAA06906@rhthomas-sun2.cisco.com> Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-OriginalArrivalTime: 12 Jun 2001 03:23:55.0185 (UTC) FILETIME=[1C465210:01C0F2EF] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bob! I am sorry if I did'nt put it correctly, but by saying that the Loop Detected Notification might in turn Loop, I meant that since a loop was detected on the label request received, there is a very high possibility that the return path (from the receiver of the label request to the sender of the Label request) for the notification message might as well loop so its better to silently discard it. Is'nt it because of this Bob ? regards tomar On Mon, 11 Jun 2001, Bob Thomas wrote: > Tomar, > > > If the node detects a loop in the label request message, the its wise not > > to send the loop detected notification, because that might in turn loop > > Note that the Loop Detected Notification is not propagated by the > receiver, and therefore will not loop. > > Bob > > > > and make the network conditions worse. In the LRq.2 case the loop is not > > detected in the label request message so we are sure that the return path > > for the notification message has no loop, so it is safe to send a > > notification in that case. > > > > --tomar > > > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > > > > > yup sorry! LRq.4 it is. typo ;o) > > > > > > > > > > > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on > > > 06/11/2001 03:27:43 PM > > > > > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > cc: > > > > > > Subject: RE: Error in RFC 3036?? > > > > > > > > > > > > > > > > IMHO, should it not be > > > > If Loop Detected , got to LRq.5 > > > > > > LRq.4 and not LRq.5 I think.... > > > > > > > > > > > > > -- > > > > > > ------------------------------------------------------------------------------ > > Nagendra Singh Tomar > > > > Residence: > > 369 KHB Colony > > 5th Block Koramangala > > Bangalore 95 > > INDIA > > Phone : 5524839 > > email : nagendras@netbrahma.com > > > > > > "Sometimes quantity becomes quality" > > --Gary Kasparov, > > When he played against Deep Blue. He said this after looking at a > > computer which found a forced mate in 249 in an endgame, after calculating > > all the possible moves with only 5 pieces left on the board. > > ------------------------------------------------------------------------------ > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Thu Jun 21 20:12:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20988 for ; Thu, 21 Jun 2001 20:12:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkulc20557; Fri, 22 Jun 2001 00:11:39 GMT Received: by mail-control.mail.uu.net id QQkulc12492 for mpls-outgoing; Fri, 22 Jun 2001 00:04:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkulc11754 for ; Fri, 22 Jun 2001 00:03:36 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 QQkulc19969 for ; Fri, 22 Jun 2001 00:03:22 GMT Received: from cpimssmtpoa01.msn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc13086 for ; Fri, 22 Jun 2001 00:03:22 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:21 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:17 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.224] by hotmail.com (3.2) with ESMTP id MHotMailBCEFAAB000A24004204BCF2EC1E0095918; Tue Jun 12 11:30:35 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by cpimssmtpc05.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 11:32:37 -0700 Message-ID: <46cc01c0faae$bd7419d0$0e03ca0a@cp98suwbm02> Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktda10837; Tue, 12 Jun 2001 18:31:56 GMT Received: by mail-control.mail.uu.net id QQktda05126 for mpls-outgoing; Tue, 12 Jun 2001 18:31:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktda05097 for ; Tue, 12 Jun 2001 18:31:08 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 QQktcz13830 for ; Tue, 12 Jun 2001 18:28:21 GMT Received: from abel.senecanetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQktcz27817 for ; Tue, 12 Jun 2001 18:28:21 GMT Received: (from root@localhost) by abel.senecanetworks.com (8.9.3/8.99.99) id JAA18356; Tue, 12 Jun 2001 09:33:11 -0500 Received: from vsharmapc ([10.0.1.238]) by abel.senecanetworks.com (8.9.3/8.9.3) with SMTP id JAA18300; Tue, 12 Jun 2001 09:33:11 -0500 From: "Vipul Sharma" To: Cc: Subject: RE: LSR-MIB Question Date: Thu, 21 Jun 2001 17:03:17 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C0F34C.004B68E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20010611224151.79246.qmail@web14508.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Scanner: echelon X-OriginalArrivalTime: 12 Jun 2001 18:32:37.0968 (UTC) FILETIME=[0E62C500:01C0F36E] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C0F34C.004B68E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Shahram, I had run into similar question a while ago...Attached is the info. which will help you for 1. My feeling is that since there is no error conditions maybe they need to be collected in mplsInSegmentDiscards. But that is just what I beleive maybe the gurus have a differing opinion. For 2, I believe that we are reqd. to keep 2 sets of stats one for the swapped label and one for the pushed label Thanx, Vip vsharma@ieee.org Attached message ================================================================= > In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see stats for errored > packets. >For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors which is "The >number of errored packets received on this segment." > My question is what type of errors make these packets errored packets >because most errored packets are dropped at the physical interface iteself >by the chips (my understanding). So does this stats put a req. to run the >phy. interface device in promiscous mode? Basically any case where a labeled packet is received and cannot be forwarded by the MPLS software. There are many cases: out of bandwidth in the switching fabric, illegal labels in the packet, etc... --Tom >Vip > -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of S. Davari Sent: Monday, June 11, 2001 6:42 PM To: mpls@UU.NET Subject: LSR-MIB Question Hi All, A few questions regarding LSR-MIB: 1) If TTL expires in an MPLS packet is the packet counted in mplsInSegmentErrors" or not? 2) If we receive a labeled packet and swap the label and then push a new label do we keep 2 sets of statistics on the outgoing segment, one for the swapped label and one for the pushed label or only one? BTW, I also noticed that in LSR-MIB a swap consists of a pop on incoming segment followed by a push on outgoing segment, this is odd !! The odder thing is that the incoming segment has a parameter called InSegmentNpop in which "N" identifies the number of pops to be performed on the insegment. How does one know in advance how many pops to perform? If you know that, then it means that all those labels that you pop are not used at all. Thanks, -Shahram _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca ------=_NextPart_000_0022_01C0F34C.004B68E0 Content-Type: message/rfc822 Content-Disposition: attachment From: "Vipul Sharma" Sender: To: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: LSR MIB question Date: Fri, 4 May 2001 11:36:58 -0400 Message-ID: <015c01c0d4b0$0ee16900$ee01000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-scanner: echelon Importance: Normal In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C18@BBY1EXM01> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit It is my understanding that both stats are to be collected to satisfy the LSR MIB. Each LSR is reqd. to collect stats for in-segments and out-segments on a per LSP basis. In case of a tunnel, it should collect stats on per LSP (which may be agg. in a tunnel) as well as the tunnel (which is a new LSP)from a LSR point of view. Atleast, this is my understanding.... Vip -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram Davari Sent: Friday, May 04, 2001 11:03 AM To: 'mpls@uu.net' Subject: LSR MIB question Hi All, If an LSR is the origin point of an MPLS tunnel, and it receives an MPLS packet, it first swaps the top label and pushes a new label on top of that. Which performance statistics are required to be collected by LSR-MIB: The swapped label or the pushed label or both? Yours, Shahram Davari ------=_NextPart_000_0022_01C0F34C.004B68E0-- From owner-mpls@UU.NET Thu Jun 21 20:13:28 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21062 for ; Thu, 21 Jun 2001 20:13:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkulc22313; Fri, 22 Jun 2001 00:12:43 GMT Received: by mail-control.mail.uu.net id QQkulc12628 for mpls-outgoing; Fri, 22 Jun 2001 00:04:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkulc11681 for ; Fri, 22 Jun 2001 00:03:34 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 QQkulc04987 for ; Fri, 22 Jun 2001 00:03:11 GMT Received: from cpimssmtpoa01.msn.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc08208 for ; Fri, 22 Jun 2001 00:03:10 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:10 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:06 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.225] by hotmail.com (3.2) with ESMTP id MHotMailBCEEF864008740042047CF2EC1E10C1D13; Mon Jun 11 22:49:31 2001 Message-ID: <45f701c0faae$b6f8b520$0e03ca0a@cp98suwbm02> Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by cpimssmtpc06.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Mon, 11 Jun 2001 22:50:45 -0700 Content-Transfer-Encoding: 7bit Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktbb08986; Tue, 12 Jun 2001 05:50:25 GMT X-Mailer: Microsoft CDO for Windows 2000 Received: by mail-control.mail.uu.net id QQktbb22833 for mpls-outgoing; Tue, 12 Jun 2001 05:49:40 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktbb22814 for ; Tue, 12 Jun 2001 05:49:29 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 QQktbb06764 for ; Tue, 12 Jun 2001 05:49:04 GMT Received: from localhost.localdomain by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.54]) id QQktbb27144 for ; Tue, 12 Jun 2001 05:49:01 GMT Received: from cheetah (IDENT:tomar@cheetah [127.0.0.1] (may be forged)) by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f5C5pwq02306; Tue, 12 Jun 2001 11:22:00 +0530 Date: Thu, 21 Jun 2001 17:03:06 -0700 From: "Nagendra Singh Tomar" Reply-To: To: Cc: , "Bob Thomas" , Subject: Re: Error in RFC 3036?? In-Reply-To: <65256A69.001B1EC2.00@sandesh.hss.hns.com> Organization: NetBrahma Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-OriginalArrivalTime: 12 Jun 2001 05:50:45.0586 (UTC) FILETIME=[9FAED320:01C0F303] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yeah, actually I missed that point! --tomar On Tue, 12 Jun 2001 suchauhan@hss.hns.com wrote: > > > hi nagendra! > In case we are using Loop Detection in a MPLS domain (or for that matter > over an LSP) and then in the case considered above the Loop Detection when > detected at a LSR shall be the first to detect it and hence it is before the > loop has actually occurred further down the LSP. We have still not reached the > receiver as this is an Intermediate LSP. Hence there should not be a loop if we > send back a notification to the source. > > regards > sumit > > > > > Nagendra Singh Tomar on 06/12/2001 08:55:44 AM > > Please respond to nagendras@netbrahma.com > > To: Bob Thomas > cc: nagendras@netbrahma.com, Sumit Chauhan/HSS@HSS, mpls@UU.NET > > Subject: Re: Error in RFC 3036?? > > > > > Bob! > I am sorry if I did'nt put it correctly, but by saying that the > Loop Detected Notification might in turn Loop, I meant that since a loop > was detected on the label request received, there is a very high > possibility that the return path (from the receiver of the label request > to the sender of the Label request) for the notification message might as > well loop so its better to silently discard it. > > Is'nt it because of this Bob ? > > regards > tomar > > > On Mon, 11 Jun 2001, Bob Thomas wrote: > > > Tomar, > > > > > If the node detects a loop in the label request message, the its wise not > > > to send the loop detected notification, because that might in turn loop > > > > Note that the Loop Detected Notification is not propagated by the > > receiver, and therefore will not loop. > > > > Bob > > > > > > > and make the network conditions worse. In the LRq.2 case the loop is not > > > detected in the label request message so we are sure that the return path > > > for the notification message has no loop, so it is safe to send a > > > notification in that case. > > > > > > --tomar > > > > > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > > > > > > > > > yup sorry! LRq.4 it is. typo ;o) > > > > > > > > > > > > > > > > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" > on > > > > 06/11/2001 03:27:43 PM > > > > > > > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > > cc: > > > > > > > > Subject: RE: Error in RFC 3036?? > > > > > > > > > > > > > > > > > > > > > IMHO, should it not be > > > > > If Loop Detected , got to LRq.5 > > > > > > > > LRq.4 and not LRq.5 I think.... > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > ------------------------------------------------------------------------------ > > > Nagendra Singh Tomar > > > > > > Residence: > > > 369 KHB Colony > > > 5th Block Koramangala > > > Bangalore 95 > > > INDIA > > > Phone : 5524839 > > > email : nagendras@netbrahma.com > > > > > > > > > "Sometimes quantity becomes quality" > > > --Gary Kasparov, > > > When he played against Deep Blue. He said this after looking at a > > > computer which found a forced mate in 249 in an endgame, after calculating > > > all the possible moves with only 5 pieces left on the board. > > > > ------------------------------------------------------------------------------ > > > > > > > -- > > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ > > > > > > -- ------------------------------------------------------------------------------ Nagendra Singh Tomar Residence: 369 KHB Colony 5th Block Koramangala Bangalore 95 INDIA Phone : 5524839 email : nagendras@netbrahma.com "Sometimes quantity becomes quality" --Gary Kasparov, When he played against Deep Blue. He said this after looking at a computer which found a forced mate in 249 in an endgame, after calculating all the possible moves with only 5 pieces left on the board. ------------------------------------------------------------------------------ From owner-mpls@UU.NET Thu Jun 21 20:17:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21245 for ; Thu, 21 Jun 2001 20:17:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld05637; Fri, 22 Jun 2001 00:17:05 GMT Received: by mail-control.mail.uu.net id QQkulc12811 for mpls-outgoing; Fri, 22 Jun 2001 00:04:31 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkulc12183 for ; Fri, 22 Jun 2001 00:04:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkulc05453 for ; Fri, 22 Jun 2001 00:03:29 GMT Received: from cpimssmtpoa01.msn.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc08556 for ; Fri, 22 Jun 2001 00:03:29 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:28 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:25 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.220] by hotmail.com (3.2) with ESMTP id MHotMailBCF0B2290097400421BBCF2EC1DC127619; Wed Jun 13 06:14:26 2001 Message-ID: <475f01c0faae$c1ec8290$0e03ca0a@cp98suwbm02> Content-Transfer-Encoding: 7bit Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by cpimssmtpc01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Wed, 13 Jun 2001 06:14:19 -0700 Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktfw03713; Wed, 13 Jun 2001 13:13:56 GMT Received: by mail-control.mail.uu.net id QQktfw21979 for mpls-outgoing; Wed, 13 Jun 2001 13:13:25 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktfw21970 for ; Wed, 13 Jun 2001 13:13: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 QQktfw27641 for ; Wed, 13 Jun 2001 13:09:29 GMT From: Received: from marvin.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQktfw23105 for ; Wed, 13 Jun 2001 13:09:28 GMT Received: from cclmsent02.lon.bt.com by marvin (local) with ESMTP; Wed, 13 Jun 2001 14:08:57 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 13 Jun 2001 14:08:48 +0100 To: Cc: , , , , , , , Subject: RE: GMPLS issues (was - GMPLS Last Calls) Date: Thu, 21 Jun 2001 17:03:25 -0700 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Jun 2001 13:14:19.0928 (UTC) FILETIME=[C17AE180:01C0F40A] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Where is the issue ? Why do we need NSAP addresses in GMPLS ? > > Kind regards, > > Eric > Eric, I understand your points on the 'management network'......that is, the addressing of it's user-plane is a separate network to the user-plane offered for cutsomer connections. So let me concentrate on the 'external' user-plane here in an attempt to answer your question. Seems we have some choices in GMPLS at the moment: Addressing - v4 or v6 Signalling - RSVP or CR-LDP Routing - OSPF or IS-IS (but exterior is BGP only) All these facets are, in principle, independent choices. And, in particular, since 'server layer trails = client layer links' then addressing cannot be from the same space at a server and client layer. The addressing might have exactly the same format, but it comes from a different space, ie address X at layer M is not = address X at layer M. Given that the layers have to be decoupled in the general case (for commercial as well as technical reasons - see the BT 'Freeland' requirements draft to 12/00 mtg) then there seems to be no reason why an operator could not use NSAPs for the access points of SDH or OTNs if he so wished. And, given this choice, that operator might also prefer to use PNNI as the signalling/routing solution too. So, the issue seems not one of 'necesssity' but simply choice......though there may be certain technical benefits of choosing 1 solution over another. I don't believe there is anything technically wrong with saying this and giving operators/vendors a choice here is there?.....if there is please point out the problems. regards, Neil From owner-mpls@UU.NET Thu Jun 21 20:19:29 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21296 for ; Thu, 21 Jun 2001 20:19:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld07853; Fri, 22 Jun 2001 00:18:44 GMT Received: by mail-control.mail.uu.net id QQkulc12943 for mpls-outgoing; Fri, 22 Jun 2001 00:04:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkulc12074 for ; Fri, 22 Jun 2001 00:03:52 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 QQkulc23588 for ; Fri, 22 Jun 2001 00:03:19 GMT Received: from cpimssmtpoa01.msn.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc08373 for ; Fri, 22 Jun 2001 00:03:18 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:18 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:14 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.223] by hotmail.com (3.2) with ESMTP id MHotMailBCEF94F900BE400421BBCF2EC1DF0E7F17; Tue Jun 12 09:58:05 2001 Message-ID: <469e01c0faae$bbdc62d0$0e03ca0a@cp98suwbm02> Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by cpimssmtpc04.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 09:57:43 -0700 Content-Transfer-Encoding: 7bit Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktct20695; Tue, 12 Jun 2001 16:57:23 GMT X-Mailer: Microsoft CDO for Windows 2000 Received: by mail-control.mail.uu.net id QQktct14226 for mpls-outgoing; Tue, 12 Jun 2001 16:56:54 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktct14209 for ; Tue, 12 Jun 2001 16:56:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQktct16791 for ; Tue, 12 Jun 2001 16:55:11 GMT From: Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQktct02236 for ; Tue, 12 Jun 2001 16:55:10 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f5CGsKq13600; Tue, 12 Jun 2001 18:54:20 +0200 (MET DST) Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256A69.005CDB36 ; Tue, 12 Jun 2001 18:54:14 +0200 X-Lotus-FromDomain: ALCATEL To: Cc: Date: Thu, 21 Jun 2001 17:03:14 -0700 Subject: Re: How is penultimate label popping requested/discouraged by signalling? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-OriginalArrivalTime: 12 Jun 2001 16:57:43.0547 (UTC) FILETIME=[CC3F14B0:01C0F360] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Considering RSVP the following applies [PHP = Penultimate Hop Popping]: 1/ Logic in last (ultimate) hop. The last (ultimate) hop requests the penultimate hop to apply PHP by specifying the 'implicit null label' in the RESV message. 2/ Logic in penultimate hop. * RSVP has no mechanism that allows the penultimate hop to specify **up front** (in the PATH message) that it does not support PHP. * If the last (ultimate) hop requests the penultimate hop to do PHP, while the penultimate hop does not support this feature, the following procedure applies: The penultimate hop returns a RESV ERR message to the last hop with an error code of "routing problem" and an error value of "unacceptable label value". This behavior is described in section 4.1.1.2 of (also included for reference below). Francis. --------------------------------- 4.1.1.2. Upstream A node uses the label carried in the LABEL object as the outgoing label associated with the sender. The router allocates a new label and binds it to the incoming interface of this session/sender. This is the same interface that the router uses to forward Resv messages to the previous hops. Several circumstance can lead to an unacceptable label. 1. the node is a merge incapable ATM switch but the downstream node has assigned the same label to two senders. ***2. The implicit null label was assigned, but the node is not *** capable of doing a penultimate pop for the associated L3PID 3. The assigned label is outside the requested label range In any of these events the node send a ResvErr message with an error code of "routing problem" and an error value of "unacceptable label value". From owner-mpls@UU.NET Thu Jun 21 20:20:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21348 for ; Thu, 21 Jun 2001 20:20:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld09651; Fri, 22 Jun 2001 00:19:59 GMT Received: by mail-control.mail.uu.net id QQkulc13065 for mpls-outgoing; Fri, 22 Jun 2001 00:04:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkulc12077 for ; Fri, 22 Jun 2001 00:03:52 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 QQkulc23574 for ; Fri, 22 Jun 2001 00:03:18 GMT Received: from cpimssmtpoa01.msn.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc13808 for ; Fri, 22 Jun 2001 00:03:18 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:17 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:14 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.223] by hotmail.com (3.2) with ESMTP id MHotMailBCEF8E45002C40042163CF2EC1DF11802; Tue Jun 12 09:28:55 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by cpimssmtpc04.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 09:28:54 -0700 Message-ID: <469201c0faae$bb6780f0$0e03ca0a@cp98suwbm02> Content-Transfer-Encoding: 7bit Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcr12325; Tue, 12 Jun 2001 16:28:26 GMT Received: by mail-control.mail.uu.net id QQktcr06833 for mpls-outgoing; Tue, 12 Jun 2001 16:27:57 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktcr06818 for ; Tue, 12 Jun 2001 16:27: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 QQktcr06831 for ; Tue, 12 Jun 2001 16:27:20 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 QQktcr08023 for ; Tue, 12 Jun 2001 16:27:19 GMT Received: (qmail 13441 invoked by uid 104); 12 Jun 2001 16:27:18 -0000 Received: from Sajith_Kizhikkepurayil@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.398627 secs); 12/06/2001 09:27:18 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 12 Jun 2001 16:27:17 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5CGRHG20598; Tue, 12 Jun 2001 09:27:17 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 09:30:42 -0700 From: "Sajith Kizhikkepurayil" To: Cc: Subject: RE: swap & push operation Date: Thu, 21 Jun 2001 17:03:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 12 Jun 2001 16:28:54.0516 (UTC) FILETIME=[C5A9E340:01C0F35C] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi robert thanks for the clarification, the slide had it clearly explained so if i want to establish an explicit path between 2 LSRs do I need to use swap&push always, or is it only in special case like this ? thanks sajith >One example can be the CSC (Carrier of Carriers) case. When the packet >from ISP CE router is received to the carrier network it is a labeled >packet. The label is ahead of time distributed from Carrier's PE to the >CE. > >At the PE based on the incomming label value the label is being swapped >+ new IGP label is being pushed on top of stack to get packets to the >other side PE of the carrier (the one which faces the other ISP). > >For more graphical picture of this take a look at page from the below >ppt url (sorry for this but I hate draw ascii pictures :). >ftp://ftp-eng.cisco.com/rraszuk/interas_csc/RR_CSC_InterAS.ppt > >R. > >> Sajith Kizhikkepurayil wrote: >> >> hi >> >> from rfc 3031: >> ---- >> c) replace the label at the top of the label stack with a >> specified new label, and then push one or more specified new >> labels onto the label stack. >> ---- >> >> could somebody give me an application scenario ? >> >> i understand that this is useful in ingress of an LSP >> i would like to know how exactly it works with respect >to deciding >> the next hop, and how is the label that swaped&pushed being >> is decided >> >> if this is already being discussed, please give me the >pointers. >> >> thanks >> sajith > From owner-mpls@UU.NET Thu Jun 21 20:21:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21380 for ; Thu, 21 Jun 2001 20:21:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld11573; Fri, 22 Jun 2001 00:21:07 GMT Received: by mail-control.mail.uu.net id QQkulc13197 for mpls-outgoing; Fri, 22 Jun 2001 00:04:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkulc12051 for ; Fri, 22 Jun 2001 00:03:49 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 QQkulc20032 for ; Fri, 22 Jun 2001 00:03:27 GMT Received: from cpimssmtpoa01.msn.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc08515 for ; Fri, 22 Jun 2001 00:03:26 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:26 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:22 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.222] by hotmail.com (3.2) with ESMTP id MHotMailBCF0577F008F400421C0CF2EC1DE12541; Tue Jun 12 23:47:28 2001 Message-ID: <473201c0faae$c09ea5d0$0e03ca0a@cp98suwbm02> Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by cpimssmtpc03.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 23:47:25 -0700 Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktex11458; Wed, 13 Jun 2001 06:46:41 GMT Received: by mail-control.mail.uu.net id QQktex18837 for mpls-outgoing; Wed, 13 Jun 2001 06:46:12 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktex18800 for ; Wed, 13 Jun 2001 06:46:06 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 QQktex25129 for ; Wed, 13 Jun 2001 06:45:48 GMT From: Received: from huaweimail.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQktex27751 for ; Wed, 13 Jun 2001 06:45:46 GMT Received: by tor-cm1.cisco.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 12:18:43 +0500 To: Cc: , Subject: RE: Tag-switching -vs- MPLS !!! Date: Thu, 21 Jun 2001 17:03:22 -0700 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F3D9.13B05570" X-OriginalArrivalTime: 13 Jun 2001 06:47:25.0212 (UTC) FILETIME=[B46E55C0:01C0F3D4] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C0F3D9.13B05570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit tag switching is the general term used to notify a methodology MPLS uses that methodology ...of tag switching. dont confuse the terms technology and methodology ... MPLs is a technology which uses a kind of methodology of tag - switching which might be in use by some other protocols or technologies too.... regards bhupesh -----Original Message----- From: Sivaramakrishna Iyer Krishnan [mailto:krishnan@research.bell-labs.com] Sent: Monday, June 11, 2001 11:44 PM To: mpls-ops@mplsrc.com Subject: Tag-switching -vs- MPLS !!! Hi All, I am not sure what is the difference between tag-switching and MPLS ????????.... Also, are all mpls commands backward compatible to tag-switching ???... Thanks, Krishnan. ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------_=_NextPart_001_01C0F3D9.13B05570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Tag-switching -vs- MPLS !!!

tag switching is the general term used to notify a = methodology

MPLS uses that methodology ...of tag = switching.
dont confuse the terms technology and methodology = ..

MPLs is a technology which uses a kind of methodology = of tag - switching which might be in use by some other protocols or = technologies too....

regards
bhupesh


-----Original Message-----
From: Sivaramakrishna Iyer Krishnan
[mailto:krishnan@research= bell-labs.com]
Sent: Monday, June 11, 2001 11:44 PM
To: mpls-ops@mplsrc.com
Subject: Tag-switching -vs- MPLS !!!



Hi All,

I am not sure what is the difference between = tag-switching and MPLS
????????....

Also, are all mpls commands backward compatible to = tag-switching ???...

Thanks,
Krishnan.

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

------_=_NextPart_001_01C0F3D9.13B05570-- From owner-mpls@UU.NET Thu Jun 21 20:22:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21409 for ; Thu, 21 Jun 2001 20:22:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld24168; Fri, 22 Jun 2001 00:21:46 GMT Received: by mail-control.mail.uu.net id QQkulc22333 for mpls-outgoing; Fri, 22 Jun 2001 00:13:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkulc13758 for ; Fri, 22 Jun 2001 00:05:11 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 QQkulc21790 for ; Fri, 22 Jun 2001 00:03:28 GMT Received: from cpimssmtpoa01.msn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc13210 for ; Fri, 22 Jun 2001 00:03:28 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:28 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:24 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.220] by hotmail.com (3.2) with ESMTP id MHotMailBCF084F3003B40042049CF2EC1DC116E2; Wed Jun 13 03:01:24 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by cpimssmtpc01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Wed, 13 Jun 2001 03:00:35 -0700 Message-ID: <475301c0faae$c1838790$0e03ca0a@cp98suwbm02> Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktfk29533; Wed, 13 Jun 2001 10:00:12 GMT Received: by mail-control.mail.uu.net id QQktfj10770 for mpls-outgoing; Wed, 13 Jun 2001 09:59:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQktfj10750 for ; Wed, 13 Jun 2001 09:59:33 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 QQktfj23624 for ; Wed, 13 Jun 2001 09:59:26 GMT Received: from smtp.huawei.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.135.132]) id QQktfj27316 for ; Wed, 13 Jun 2001 09:58:53 GMT Received: from z97716 ([10.110.10.147]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GEV4AA01.R21; Wed, 13 Jun 2001 17:42:10 +0800 From: "Heqing Zhu" To: Cc: References: Subject: Re: LSR-MIB Question Date: Thu, 21 Jun 2001 17:03:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 13 Jun 2001 10:00:35.0522 (UTC) FILETIME=[B0CB4A20:01C0F3EF] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA21409 When using the label stack, if there are several layers, and egress router is the same router. So I think you need pop these labels. If I am wrong, please correct me. > Hello, > Regarding the LSR MIB, the use of InSegmentNpop is not clear to me and I > raised this issue earlier, but have not got a reply. If for a particular > label 'N' pop operations are always done then what is the significance of > the N-1 labels beneath it. Which scenario is this useful and how is the 'N' > value set,especially when it is greater than 1. > > Regards, > Vijay > From owner-mpls@UU.NET Thu Jun 21 20:22:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21424 for ; Thu, 21 Jun 2001 20:22:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld13445; Fri, 22 Jun 2001 00:22:13 GMT Received: by mail-control.mail.uu.net id QQkulc13340 for mpls-outgoing; Fri, 22 Jun 2001 00:04:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkulc12187 for ; Fri, 22 Jun 2001 00:04:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkulc05392 for ; Fri, 22 Jun 2001 00:03:26 GMT Received: from cpimssmtpoa01.msn.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc08502 for ; Fri, 22 Jun 2001 00:03:26 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:26 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:22 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.223] by hotmail.com (3.2) with ESMTP id MHotMailBCF03EF4004D4004204FCF2EC1DF066710; Tue Jun 12 22:02:48 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by cpimssmtpc04.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 22:01:05 -0700 Message-ID: <472901c0faae$c06a2850$0e03ca0a@cp98suwbm02> Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkteq10376; Wed, 13 Jun 2001 05:00:36 GMT Received: by mail-control.mail.uu.net id QQkteq28701 for mpls-outgoing; Wed, 13 Jun 2001 05:00:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkteq28393 for ; Wed, 13 Jun 2001 05:00:01 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 QQktep26316 for ; Wed, 13 Jun 2001 04:59:43 GMT Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.6]) id QQktep20838 for ; Wed, 13 Jun 2001 04:59:42 GMT Received: from grofw (router.hclt.co.in [202.54.64.1]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ52SD6Y; Wed, 13 Jun 2001 10:42:50 +0530 Received: from VIJAYC ([192.168.232.219]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L8Z2D7P5; Wed, 13 Jun 2001 10:27:37 +0530 From: "Vijayanand C" To: Cc: Subject: RE: LSR-MIB Question Date: Thu, 21 Jun 2001 17:03:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <002101c0f36d$875d08e0$ee01000a@vsharmapc> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-OriginalArrivalTime: 13 Jun 2001 05:01:05.0795 (UTC) FILETIME=[DA008D30:01C0F3C5] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Regarding the LSR MIB, the use of InSegmentNpop is not clear to me and I raised this issue earlier, but have not got a reply. If for a particular label 'N' pop operations are always done then what is the significance of the N-1 labels beneath it. Which scenario is this useful and how is the 'N' value set,especially when it is greater than 1. Regards, Vijay -----Original Message----- From: Vipul Sharma [mailto:vsharma@senecanetworks.com] Sent: Tuesday, June 12, 2001 11:59 PM To: davari@ieee.org Cc: mpls@UU.NET Subject: RE: LSR-MIB Question Shahram, I had run into similar question a while ago...Attached is the info. which will help you for 1. My feeling is that since there is no error conditions maybe they need to be collected in mplsInSegmentDiscards. But that is just what I beleive maybe the gurus have a differing opinion. For 2, I believe that we are reqd. to keep 2 sets of stats one for the swapped label and one for the pushed label Thanx, Vip vsharma@ieee.org Attached message ================================================================= > In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see stats for errored > packets. >For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors which is "The >number of errored packets received on this segment." > My question is what type of errors make these packets errored packets >because most errored packets are dropped at the physical interface iteself >by the chips (my understanding). So does this stats put a req. to run the >phy. interface device in promiscous mode? Basically any case where a labeled packet is received and cannot be forwarded by the MPLS software. There are many cases: out of bandwidth in the switching fabric, illegal labels in the packet, etc... --Tom >Vip > -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of S. Davari Sent: Monday, June 11, 2001 6:42 PM To: mpls@UU.NET Subject: LSR-MIB Question Hi All, A few questions regarding LSR-MIB: 1) If TTL expires in an MPLS packet is the packet counted in mplsInSegmentErrors" or not? 2) If we receive a labeled packet and swap the label and then push a new label do we keep 2 sets of statistics on the outgoing segment, one for the swapped label and one for the pushed label or only one? BTW, I also noticed that in LSR-MIB a swap consists of a pop on incoming segment followed by a push on outgoing segment, this is odd !! The odder thing is that the incoming segment has a parameter called InSegmentNpop in which "N" identifies the number of pops to be performed on the insegment. How does one know in advance how many pops to perform? If you know that, then it means that all those labels that you pop are not used at all. Thanks, -Shahram _______________________________________________________ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca From owner-mpls@UU.NET Thu Jun 21 20:23:59 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21491 for ; Thu, 21 Jun 2001 20:23:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld15520; Fri, 22 Jun 2001 00:23:21 GMT Received: by mail-control.mail.uu.net id QQkulc13591 for mpls-outgoing; Fri, 22 Jun 2001 00:05:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkulc11773 for ; Fri, 22 Jun 2001 00:03: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 QQkulc05335 for ; Fri, 22 Jun 2001 00:03:24 GMT Received: from cpimssmtpoa01.msn.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc13891 for ; Fri, 22 Jun 2001 00:03:23 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:23 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:19 -0700 Content-Class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline; Creation-Date=Tue, 12 Jun 2001 15:27:31 -0500 Received: from [207.46.193.223] by hotmail.com (3.2) with ESMTP id MHotMailBCEFCA3B00A6400421BBCF2EC1DF09525; Tue Jun 12 13:44:47 2001 Message-ID: <46f301c0faae$bebd1490$0e03ca0a@cp98suwbm02> Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by cpimssmtpc04.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 13:44:38 -0700 Content-Transfer-Encoding: 7bit Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktdi12130; Tue, 12 Jun 2001 20:44:14 GMT X-Mailer: Microsoft CDO for Windows 2000 Received: by mail-control.mail.uu.net id QQktdi29201 for mpls-outgoing; Tue, 12 Jun 2001 20:43:45 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktdi29170 for ; Tue, 12 Jun 2001 20:43: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 QQktdi12545 for ; Tue, 12 Jun 2001 20:37:52 GMT From: Received: from damgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQktdi23529 for ; Tue, 12 Jun 2001 20:37:51 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f5CKdpF10420; Tue, 12 Jun 2001 15:39:52 -0500 (CDT) Received: from kcopmp04.corp.sprint.com (kcopmp04m.corp.sprint.com [10.74.2.74]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f5CKRas10494; Tue, 12 Jun 2001 15:27:37 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp04.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id PAA21357; Tue, 12 Jun 2001 15:27:36 -0500 (CDT) X-OpenMail-Hops: 1 Date: Thu, 21 Jun 2001 17:03:19 -0700 Subject: RE: GMPLS issues (was - GMPLS Last Calls) MIME-Version: 1.0 To: Cc: , , , , , X-OriginalArrivalTime: 12 Jun 2001 20:44:38.0875 (UTC) FILETIME=[7F9D42B0:01C0F380] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bala, Thanks for your reply. Sorry it took so long to reply back. Please see in-line. Thanks, Ananth bala>> > 1) Type of legacy equipment needing NSAP addresses bala>> > (also, is bala>> > this optical network element or client equipment?) bala>> > 2) Rough estimate of number of UNI ports needing NSAP address bala>> > (2002, 2005, and 2010) bala>> > 3) Description of application in which this legacy equipment bala>> > will use UNI bala>> > signaling bala>I don't recall seeing any response. furthermore, the NSAP bala>requirement was not unanimously endorsed by all carriers (at bala>the OIF). From our OIF representatives, although it was not unanimously endorsed, there was a significant demand for NSAP support. Well, NSAP is the main non-IP type of addressing that is required. The general requirement is to be able to support non-IP addresses (probably have an address translation from non-IP addresses to routable addresses). bala>It would also be nice if you can give some insight on bala>the timeline in which you need various features, and whether bala>the current GMPLS developments are inadequate within bala>that timeline. (We can always have a progression of features). NSAP support will be needed always (e.g. support for legacy DCC that uses NSAP). So the timeframe requirement is now. Ananth>2) GMPLS is being defined based on assumptions about proprietary Ananth>transmission planes without those assumptions being specified. How can Ananth>we be sure that the control plane support is correct? How can we be Ananth>sure that it can be combined with other features? Assumptions Ananth>regarding the transmission plane that can affect the control plane must Ananth>be clearly documented. This creates the additional related problem that Ananth>there is not a clear inter-working defined for interaction between Ananth>standard/proprietary control planes/transmission planes. bala>BR: I get the feeling you're referring to the concatenation/transperency bala>issues discussed recently. While the debate has been hot, there's bala>no show stopper here. Several suggestions are being considered for bala>clarifying standard/non-standard features supported. The concatenation/transparency issues are a concern. In addition, management features such as manual protection switching, protection switching configuration, billing support (e.g. usage collection) etc need to be supported too. Ananth>3) Assuring separation of the control plane from the data plane Ananth>continues to arise.. When the control plane fails it should not affect Ananth> existing connections. Also if connections in progress are affected Ananth>then they should not leave partially setup connections - they should Ananth>fail gracefully informing the initiator. The GMPLS architecture Ananth>document mentions this separation, but it's not clear how the GMPLS Ananth>signaling specifications reflect the implications of this decoupling. bala>BR: This issue has been discussed for the OIF UNI signaling (GMPLS bala>based, as you know), and solutions in the RSVP/LDP space have been bala>proposed (some drafts may be written). bala>This is also not a show stopper by any means. Don't understand how the OIF UNI addresses this. Our concerns are more with respect to the NNI (internal separation of control and data). If this is not addressed, it is definitely a showstopper. According to our OIF representatives, the OIF is looking at the IETF to specify these protocols. To be specific, existing connections shouldn't be impacted when the control plane fails. Ananth>4) Support for NSAP addresses and in general support such that control Ananth>plane addressing is independent of clients and vice versa. Also Ananth>scalable naming/addressing scheme such as proposed in OIF. bala>BR: NSAP, see my initial comments. The OIF is not dealing with bala>names/resolution, etc. This has been decided to be out of the bala>scope of UNI signaling, and considered as a separate function. Address translation of some form (for e.g. NSAP address translation) should be supported. See comment at the beginning of the email. Ananth>5) Since the control plane may be supported via multiple protocols, Ananth>clear statement of what is - and isn't - covered in the GMPLS Signaling Ananth>Description, RSVP Extensions, LDP Extensions drafts is needed. bala>BR: Don't understand this, but doesn't look like a major issue from bala>your phrasing. Recommend the development of applicability statements to cover this (otherwise, it is difficult to understand how the different pieces join together to form a coherent picture). Ananth>6) Terminology is an issue (e.g., waveband switching, link) bala>BR: Any inconsistencies can be taken care of easily. Like your comment. Hope it is as easy as it sounds :-) Mapping of terminology between standards bodies and also between different drafts in the IETF can be painful. Agreed however, that this is not a show-stopper. Ananth>7) Transaction support for connection set-up and release is needed for Ananth>connection oriented networks (e.g. crankback capability). bala>BR: Internet drafts have already been written on crankback. I suggest bala>that you please consider writing some drafts if there is something bala>missing. Aware of the "iwata-draft". Are there others? Ananth>8) Reliable message transfer bala>BR: Very much a part of signaling. the OIF work has considered this bala>aspect also. 'soft-state' signaling protocols may not be acceptable for the optical control plane. Live channels must not be dropped as a result of signaling message delivery failures (e.g. timer refresh failures) Ananth>9) Security concerns have not been fully addressed, particularly at the Ananth> architectural level. The use of separate control network may Ananth>necessitate the need for 24 hour staff to protect against 'Denial of Ananth>Service' attacks as currently happens for IP router networks. In Ananth>general, admission control issues need to be addressed. bala>BR: Please elaborate on these, specifically, what's new in the bala>context of GMPLS. e.g. in the case of ATM UNI, if a user or users attempt too many call setups simultaneously the switch control processor can become overloaded. So, some form of call pacing/overload handling is needed. Is there something similar in the GMPLS context for optical devices? Ananth>10) The definition of transparency may be overly simplified. See Ananth>comments by Ben Mack-Crane: Ananth>I think the debate on transparency indicates that the issue is not as Ananth>clear Ananth>as we might think. The OIF document you cite defines forms of Ananth>transparency Ananth>that are very straightforward (flags 1,2) not the more complex forms in Ananth>the current GMPLS drafts (flags 3..10). Also, these are easily Ananth>provided in Ananth>O-E-O or O-O-O networks operating at the lambda level, but there is no Ananth>standard for providing these over TDM multiplexed SONET/SDH links. bala>BR: This is an ongoing topic of discussion. Doesn't break down bala>the rest of the proposal. Agreed. Ananth>If two vendors implement the same signaling but different TDM Ananth>multiplexing, that Ananth>doesn't achieve interoperability. Is there any way in the drafts to Ananth>determine the scope Ananth>of application of the various signaling elements (that is, whether they Ananth>apply to UNI or NNI, whether they apply to specific network Ananth>layers/technologies)? Ananth>11) One summary of additional items with issues includes: Ananth>- SDH/SONET transparency. Ananth>- SDH/SONET arbitrary concatenation, flexible concatenation. Ananth>- AUG-X, TUG, STS Groups signal types and LSP capabilities. Ananth>- All kinds of end-to-end protection/restoration for any layer, except Ananth>the IP layer. bala>BR: Restoration is not actually covered in the current set of drafts. bala>An earlier thread discussed this, and my suggestion is that this bala>feature be dealt with separately. Potential show-stopper for deployment if restoration is not covered. Would agree that it could be addressed separately, though. Ananth>- The label set object (only used for lambda issues). Ananth>- LSP encoding type, bandwidth encoding and GPID have to be simplified Ananth>accordingly. Ananth>- MPLS extensions to control G.709 (since multiplexing, etc is not yet Ananth>defined). bala>BR: A draft is forthcoming on this. Have been made aware of this. Thanks. Ananth>12) Support for paths across SONET/SDH gateways bala>BR: Please clarify the issues/write drafts. Quoting from Siegfried Giebl's email regarding "If I understand this document correctly, then you are completely separating SONET and SDH signal types from each other, thus making it difficult to deal with paths across SONET/SDH gateways. As an alternative, I suggest you work only with entities of level STS-1 (STM-0) and higher. On the other hand why don't you go the full way and also add 64 kb/s channels ?" Ananth> 13) Compatibility is required/desired with legacy SDH/SONET equipment Ananth>[and also legacy DWDM] bala>BR: Same as above. NSAP issue identified above. Elements within a link may not communicate using the signaling, i.e., legacy SDH/SONET equipment that does not participate in signaling (participate only in connectivity) Thanks, Ananth From owner-mpls@UU.NET Thu Jun 21 20:25:56 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21566 for ; Thu, 21 Jun 2001 20:25:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld17170; Fri, 22 Jun 2001 00:24:24 GMT Received: by mail-control.mail.uu.net id QQkulc13715 for mpls-outgoing; Fri, 22 Jun 2001 00:05:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkulc11830 for ; Fri, 22 Jun 2001 00:03: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 QQkulc19851 for ; Fri, 22 Jun 2001 00:03:15 GMT Received: from cpimssmtpoa01.msn.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc08297 for ; Fri, 22 Jun 2001 00:03:15 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:14 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:11 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.225] by hotmail.com (3.2) with ESMTP id MHotMailBCEF6EEA006F40042163CF2EC1E108262; Tue Jun 12 07:15:07 2001 Message-ID: <464e01c0faae$b99b7380$0e03ca0a@cp98suwbm02> Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by cpimssmtpc06.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 07:14:14 -0700 Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktci04851; Tue, 12 Jun 2001 14:13:52 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: by mail-control.mail.uu.net id QQktci12110 for mpls-outgoing; Tue, 12 Jun 2001 14:13:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktci12102 for ; Tue, 12 Jun 2001 14:13:21 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 QQktci19481 for ; Tue, 12 Jun 2001 14:11:55 GMT From: Received: from huaweimail.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.164]) id QQktci28808 for ; Tue, 12 Jun 2001 14:11:53 GMT Received: by tor-cm1.cisco.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 19:44:53 +0500 To: Cc: , Subject: RE: What we do if the LSP is preempted Date: Thu, 21 Jun 2001 17:03:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F34E.3D562BB0" X-OriginalArrivalTime: 12 Jun 2001 14:14:14.0468 (UTC) FILETIME=[F5946840:01C0F349] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C0F34E.3D562BB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello lei D____________________F / \ A---------------B---------------------C \_____E______/ Suppose i have a LSP ABEC of priority 3 And a LSP ADF with priority 4 Now i want to setup ABC with priority 2. As the resources are not available on link AB i will preempt LSP ABEC But there is a LSP ADF with priority 4 less than that of ABEC so if i preempt ABEC then won't it be fair to establish the LSP through ADFC and preempt ADF if enough resources are not available ? Thanks Ashwin -----Original Message----- From: Lei Yao [mailto:lei.yao@wcom.com] Sent: Tuesday, June 12, 2001 6:38 PM To: Ashwinp@in.huawei.com Subject: RE: What we do if the LSP is preempted A LSP is preempted because of the lack of network resource. In other words, there is network congestion. Therefore, you should not try to re-build the preempted LSP. -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Ashwinp@in.huawei.com Sent: Tuesday, June 12, 2001 10:12 AM To: mpls-ops@mplsrc.com; mpls@UU.NET Subject: What we do if the LSP is preempted Dear all Can you please tell me what if the LSP is preempted ? Do we try to reestablish the LSP with some other path or we will just preempt it ? If we just preempt the LSP then it will be unfare with that LSP. And when should we try to reestablish that LSP ? Do anybody has any ionformation regarding this ? Thanks in advance Ashwin ------_=_NextPart_001_01C0F34E.3D562BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What we do if the LSP is preempted
 
Hello=20 lei
 
 =20 D____________________F
 /      &n= bsp;           &n= bsp;           &n= bsp;       =20 \
A---------------B---------------------C
       &nb= sp;          =20 \_____E______/
 
Suppose i have a LSP ABEC of priority=20 3
And a=20 LSP ADF with priority 4
 
Now i=20 want to setup ABC with priority 2.
As the=20 resources are not available on link AB i will preempt LSP=20 ABEC
But=20 there is a LSP ADF with priority 4 less than that of ABEC so if i=20 preempt
ABEC=20 then won't it be fair to establish the LSP through ADFC and preempt ADF =
if=20 enough resources are not available ?
Thanks
Ashwin
 
-----Original Message-----
From: Lei Yao=20 [mailto:lei.yao@wcom.com]
Sent: Tuesday, June 12, 2001 6:38 = PM
To: Ashwinp@in.huawei.com
Subject: RE: What we = do if=20 the LSP is preempted

A LSP=20 is preempted because of the lack of network resource. In other words, = there is=20 network congestion. Therefore, you should not try to re-build the = preempted=20 LSP.

 

=

-----Original=20 Message-----
From: = owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of=20 Ashwinp@in.huawei.com
Sent: Tuesday, June 12, 2001 = 10:12=20 AM
To: = mpls-ops@mplsrc.com;=20 mpls@UU.NET
Subject: What we=20 do if the LSP is preempted

 

 

Dear=20 all=20

 Can = you please=20 tell me what if the LSP is preempted ? Do we try to reestablish the = LSP=20
 with some=20 other path or we will just preempt it ?
 If = we just=20 preempt the LSP then it will be unfare with that LSP. And when should = we try=20 to
 reestablish=20 that LSP ?=20

Do = anybody has any=20 ionformation regarding this ?

Thanks in = advance=20
Ashwin

------_=_NextPart_001_01C0F34E.3D562BB0-- From owner-mpls@UU.NET Thu Jun 21 20:28:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21599 for ; Thu, 21 Jun 2001 20:28:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld29148; Fri, 22 Jun 2001 00:26:44 GMT Received: by mail-control.mail.uu.net id QQkulc22344 for mpls-outgoing; Fri, 22 Jun 2001 00:13:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkulc13301 for ; Fri, 22 Jun 2001 00:04:54 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 QQkulc21612 for ; Fri, 22 Jun 2001 00:03:20 GMT Received: from cpimssmtpoa01.msn.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc13825 for ; Fri, 22 Jun 2001 00:03:19 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:19 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:15 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.221] by hotmail.com (3.2) with ESMTP id MHotMailBCEF9C15006A400420F0CF2EC1DD0C423; Tue Jun 12 10:27:55 2001 Message-ID: <46af01c0faae$bc4a18c0$0e03ca0a@cp98suwbm02> Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by cpimssmtpc02.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 10:27:40 -0700 Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcv25379; Tue, 12 Jun 2001 17:27:14 GMT Received: by mail-control.mail.uu.net id QQktcv07715 for mpls-outgoing; Tue, 12 Jun 2001 17:26:44 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQktcv07674 for ; Tue, 12 Jun 2001 17:26:33 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 QQktcv14332 for ; Tue, 12 Jun 2001 17:25:17 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktcv10999 for ; Tue, 12 Jun 2001 17:25:17 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 6D99494009; Tue, 12 Jun 2001 13:25:12 -0400 (EDT) Date: Thu, 21 Jun 2001 17:03:15 -0700 From: "Eric Gray" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Cc: Subject: Re: How is penultimate label popping requested/discouraged by signalling ? References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2001 17:27:45.0846 (UTC) FILETIME=[FE801560:01C0F364] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Heinrich, It is requested using implicit NULL labels. It is discouraged by releasing the implicit NULL label (after requesting another for the same FEC). While it isn't the intention that an LSR can volunteer to do PHP, as long as the nexthop is able to forward IP packets and uses the platform wide label space, it is hard to prevent. I agree it would not be a good idea, in general, and a signaling approach is available. -- Eric Gray You wrote: > Hello,How is penultimate label popping requested resp. discouraged by explicit > signalling?IMHO: it would be very bad if the penultimate LSR would do the > label popping implicitly, i.e. by checking whetherhis next hop router is also > the egress of the LSP and without permission !Heinrich Hummel,Siemens AG From owner-mpls@UU.NET Thu Jun 21 20:28:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21633 for ; Thu, 21 Jun 2001 20:28:42 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld00705; Fri, 22 Jun 2001 00:27:59 GMT Received: by mail-control.mail.uu.net id QQkulc22409 for mpls-outgoing; Fri, 22 Jun 2001 00:13:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkulc13302 for ; Fri, 22 Jun 2001 00:04:54 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 QQkulc21566 for ; Fri, 22 Jun 2001 00:03:17 GMT Received: from cpimssmtpoa01.msn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc12962 for ; Fri, 22 Jun 2001 00:03:16 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:16 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:12 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.220] by hotmail.com (3.2) with ESMTP id MHotMailBCEF79610062400420F0CF2EC1DC09680; Tue Jun 12 07:59:45 2001 Message-ID: <466c01c0faae$ba686070$0e03ca0a@cp98suwbm02> Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by cpimssmtpc01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 07:58:44 -0700 Content-Transfer-Encoding: 7bit Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcl23042; Tue, 12 Jun 2001 14:58:16 GMT X-Mailer: Microsoft CDO for Windows 2000 Received: by mail-control.mail.uu.net id QQktcl16455 for mpls-outgoing; Tue, 12 Jun 2001 14:57:45 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQktcl16446 for ; Tue, 12 Jun 2001 14:57:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQktcl05766 for ; Tue, 12 Jun 2001 14:54:00 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQktcl16036 for ; Tue, 12 Jun 2001 14:53:59 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id f5CKVqZ11748 for ; Tue, 12 Jun 2001 20:31:53 GMT Received: from soflt.alc.wipinfo.soft.net ([192.168.220.205]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GET6T100.MQR; Tue, 12 Jun 2001 14:11:25 +0530 Date: Thu, 21 Jun 2001 17:03:12 -0700 From: "chetan kumar s" Reply-To: To: Cc: "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" , "'Manoj Dutta'" , Subject: RE: Label Mapping !! In-Reply-To: <65256A69.002443F5.00@sandesh.hss.hns.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-OriginalArrivalTime: 12 Jun 2001 14:58:44.0755 (UTC) FILETIME=[2D31DE30:01C0F350] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > hi! > IMHO this is not correct as the LSR from which the label mapping Hi, If look at the Notes:7 given in A.1.2, things are quite clear. The reason for including the message source is to handle the unsolicited ordered control mode. If the label is not sent to the next hop(upstream) for the FEC, the next hop may not have the label to use. Later if the next hop becomes the downstream for the FEC in question and since we are in unsoliciated ordered, the new next hop would have no way to request for the label. Of course the received may wish to release the same based on his retention mode, under which condition the next hop would be in request-on-request so that it can request for label. Thanks Chetan S > has beeen learnt can never be the upstream LSR for the same mapping - > liberal or conservative mode notwithstanding. > > regards > sumit > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" on > 06/12/2001 12:02:39 PM > > To: "'Manoj Dutta'" , mpls@UU.NET > cc: (bcc: Sumit Chauhan/HSS) > > Subject: RE: Label Mapping !! > > > > > Hi, > > I had some doubts in RFC 3036. In section A.1.2, LMp.17 and A.1.6 > > FEC.1, an LSR seems to send mappings for a given FEC to the next hop > > for the same FEC. If so, why ? > > As I understand it, this is due to the existance of liberal mode : in case > of LDP reconstuction, the former Next Hop (downstrem located) may become a > LSR upstream located. > > Rigth? > > Thierry > > > > From owner-mpls@UU.NET Thu Jun 21 20:29:51 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21684 for ; Thu, 21 Jun 2001 20:29:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuld18881; Fri, 22 Jun 2001 00:28:42 GMT Received: by mail-control.mail.uu.net id QQkuld22886 for mpls-outgoing; Fri, 22 Jun 2001 00:16:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkulc13374 for ; Fri, 22 Jun 2001 00: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 QQkulc21573 for ; Fri, 22 Jun 2001 00:03:17 GMT Received: from cpimssmtpoa01.msn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.46.193.226]) id QQkulc12976 for ; Fri, 22 Jun 2001 00:03:17 GMT Received: from cp98suwbm02 ([10.202.3.14]) by cpimssmtpoa01.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Thu, 21 Jun 2001 17:03:16 -0700 Received: from mail pickup service by cp98suwbm02 with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:03:12 -0700 Content-Class: urn:content-classes:message Received: from [207.46.193.223] by hotmail.com (3.2) with ESMTP id MHotMailBCEF79EB001A40042162CF2EC1DF11240; Tue Jun 12 08:02:03 2001 Message-ID: <466f01c0faae$ba829f30$0e03ca0a@cp98suwbm02> Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by cpimssmtpc04.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Tue, 12 Jun 2001 08:01:04 -0700 Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQktcm23893; Tue, 12 Jun 2001 15:00:34 GMT Received: by mail-control.mail.uu.net id QQktcm16632 for mpls-outgoing; Tue, 12 Jun 2001 15:00:00 GMT X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQktcl16602 for ; Tue, 12 Jun 2001 14:59:45 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 QQktcl20738 for ; Tue, 12 Jun 2001 14:54:57 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQktcl19298 for ; Tue, 12 Jun 2001 14:54:57 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 006B39400B; Tue, 12 Jun 2001 10:54:56 -0400 (EDT) Date: Thu, 21 Jun 2001 17:03:12 -0700 From: "Eric Gray" X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Cc: , "Bob Thomas" , Subject: Re: Error in RFC 3036?? References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2001 15:01:04.0266 (UTC) FILETIME=[80598EA0:01C0F350] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Nagendra/Sumit/Vijay, LDP did not include discussion of timeouts as this is out of scope for the specification. The Label Request Abort message does allow an implementation to use a timeout. Since LDP relies on routing, it is assumed that a routing loop is a transient condition. By not forwarding a Label Request in which a loop has been detected, looping of the LSP control messages is not continued. It is not necessary to remove a loop created by Label Request messages since such a loop cannot produce a loop in the data path. This is not true for Label Mappings - therefore, in the Label Mapping case, it is a good idea to release the mappings and clean up state. In the Label Request case, when the loop is resolved, recognize new nexthop will ensure that wrong state is cleared up and the rest of the Label Request process reaches completion. -- Eric Gray You wrote: > Yeah, actually I missed that point! > --tomar > > On Tue, 12 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > hi nagendra! > > In case we are using Loop Detection in a MPLS domain (or for that matter > > over an LSP) and then in the case considered above the Loop Detection when > > detected at a LSR shall be the first to detect it and hence it is before the > > loop has actually occurred further down the LSP. We have still not reached the > > receiver as this is an Intermediate LSP. Hence there should not be a loop if we > > send back a notification to the source. > > > > regards > > sumit > > > > > > > > > > Nagendra Singh Tomar on 06/12/2001 08:55:44 AM > > > > Please respond to nagendras@netbrahma.com > > > > To: Bob Thomas > > cc: nagendras@netbrahma.com, Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > > Subject: Re: Error in RFC 3036?? > > > > > > > > > > Bob! > > I am sorry if I did'nt put it correctly, but by saying that the > > Loop Detected Notification might in turn Loop, I meant that since a loop > > was detected on the label request received, there is a very high > > possibility that the return path (from the receiver of the label request > > to the sender of the Label request) for the notification message might as > > well loop so its better to silently discard it. > > > > Is'nt it because of this Bob ? > > > > regards > > tomar > > > > > > On Mon, 11 Jun 2001, Bob Thomas wrote: > > > > > Tomar, > > > > > > > If the node detects a loop in the label request message, the its wise not > > > > to send the loop detected notification, because that might in turn loop > > > > > > Note that the Loop Detected Notification is not propagated by the > > > receiver, and therefore will not loop. > > > > > > Bob > > > > > > > > > > and make the network conditions worse. In the LRq.2 case the loop is not > > > > detected in the label request message so we are sure that the return path > > > > for the notification message has no loop, so it is safe to send a > > > > notification in that case. > > > > > > > > --tomar > > > > > > > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote: > > > > > > > > > > > > > > > > > > > yup sorry! LRq.4 it is. typo ;o) > > > > > > > > > > > > > > > > > > > > > > > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS" > > on > > > > > 06/11/2001 03:27:43 PM > > > > > > > > > > To: Sumit Chauhan/HSS@HSS, mpls@UU.NET > > > > > cc: > > > > > > > > > > Subject: RE: Error in RFC 3036?? > > > > > > > > > > > > > > > > > > > > > > > > > > IMHO, should it not be > > > > > > If Loop Detected , got to LRq.5 > > > > > > > > > > LRq.4 and not LRq.5 I think.... > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Nagendra Singh Tomar > > > > > > > > Residence: > > > > 369 KHB Colony > > > > 5th Block Koramangala > > > > Bangalore 95 > > > > INDIA > > > > Phone : 5524839 > > > > email : nagendras@netbrahma.com > > > > > > > > > > > > "Sometimes quantity becomes quality" > > > > --Gary Kasparov, > > > > When he played against Deep Blue. He said this after looking at a > > > > computer which found a forced mate in 249 in an endgame, after calculating > > > > all the possible moves with only 5 pieces left on the board. > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > -- > > > > > > ------------------------------------------------------------------------------ > > Nagendra Singh Tomar > > > > Residence: > > 369 KHB Colony > > 5th Block Koramangala > > Bangalore 95 > > INDIA > > Phone : 5524839 > > email : nagendras@netbrahma.com > > > > > > "Sometimes quantity becomes quality" > > --Gary Kasparov, > > When he played against Deep Blue. He said this after looking at a > > computer which found a forced mate in 249 in an endgame, after calculating > > all the possible moves with only 5 pieces left on the board. > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > -- > > ------------------------------------------------------------------------------ > Nagendra Singh Tomar > > Residence: > 369 KHB Colony > 5th Block Koramangala > Bangalore 95 > INDIA > Phone : 5524839 > email : nagendras@netbrahma.com > > "Sometimes quantity becomes quality" > --Gary Kasparov, > When he played against Deep Blue. He said this after looking at a > computer which found a forced mate in 249 in an endgame, after calculating > all the possible moves with only 5 pieces left on the board. > ------------------------------------------------------------------------------ From owner-mpls@UU.NET Thu Jun 21 21:03:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22756 for ; Thu, 21 Jun 2001 21:03:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkulg25043; Fri, 22 Jun 2001 01:01:35 GMT Received: by mail-control.mail.uu.net id QQkulg02942 for mpls-outgoing; Fri, 22 Jun 2001 01:01:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkulg01633 for ; Fri, 22 Jun 2001 01:00: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 QQkulf17480 for ; Fri, 22 Jun 2001 00:59:20 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f83.law11.hotmail.com [64.4.17.83]) id QQkulf00010 for ; Fri, 22 Jun 2001 00:59:19 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Jun 2001 17:59:19 -0700 Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP; Fri, 22 Jun 2001 00:59:19 GMT X-Originating-IP: [65.112.106.16] From: "Irfan Lateef" To: sgamble@tropicnetworks.com, rdonkin@orchestream.com, mblanes@larc.usp.br, jkton2000@yahoo.com Cc: Nicola.DiGiusto@TILAB.COM, mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: R:VPN solution center Date: Thu, 21 Jun 2001 20:59:19 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Jun 2001 00:59:19.0370 (UTC) FILETIME=[913782A0:01C0FAB6] Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQkulg25043 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA22756 Following this thread I have realized there are quite a few VPN provision tool vendors on this list. As a designer of GMPLS based systems, I have the following question. In order to be able to provision GMPLS paths in a GMPLS enabled network which has IP-over-MPLS-over-OTN-over-WDM, what information or data needs to be passed from a NE to a EMS/NMS/VPNTool. To add another complexity, what if a single box is doing the things namely, takes in IP-over-Ethernet as input and sends out g.709 over WDM. Appreciate your responses. Thanks, Irfan Lateef >From: "Stephen Gamble" >To: "Donkin, Richard" , "'Marcelo Blanes'" >, "Jonathan Okhrizty" >CC: "Di Giusto Nicola" , >Subject: RE: R:VPN solution center >Date: Thu, 21 Jun 2001 15:40:51 -0400 > >There is also Nortel's 'Preside' which works on Cisco, Contivity and I >think >Shasta? I know they are working on Juniper support currently. > >It has some unique QoS features in their Cisco cartrige like CAR, WRED and >CBWFQ. ACL support and route-maps are neat for BGP route selection in >multi-homed VPN enviroments. > > >CW (Cable and Wireless) use Preside (aka PPS) for their large Cisco VPN >deployment (rfc2547) on their live network. Have been for months. > > > >Stephen Gamble >Verification Engineer >Tropic Networks Inc. > >-----Original Message----- >From: Donkin, Richard [mailto:rdonkin@orchestream.com] >Sent: Thursday, June 21, 2001 2:38 PM >To: 'Marcelo Blanes'; Jonathan Okhrizty >Cc: Di Giusto Nicola; mpls-ops@mplsrc.com >Subject: RE: R:VPN solution center > > >Some sort of provisioning tool is a good idea for any large MPLS VPN >deployment, to avoid the cost of provisioning errors and provide quicker >roll-out of revenue earning services. As networks evolve and service >providers consolidate, it's important that such a tool is scalable and can >handle multiple vendors' equipment. > >VPN SC is one such tool for Cisco VPN deployments - there are others, >including Orchestream, which also provisions Cisco routers but is >multi-vendor, supporting Juniper, Riverstone and so on, and has some very >nice features (see http://www.orchestream.com for more details). > >Of course, I am somewhat biased but I thought I would add another viewpoint >:) > >Richard Donkin >T: +44 (0)20 7348 1507 >Orchestream >Avon House, Kensington Village, Avonmore Road, London W14 8TS >T: +44 (0)20 7348 1500 F: +44 (0)20 7348 1501 >www.orchestream.com > > > > -----Original Message----- > > From: Marcelo Blanes [mailto:mblanes@larc.usp.br] > > Sent: 20 June 2001 21:00 > > To: Jonathan Okhrizty > > Cc: Di Giusto Nicola; mpls-ops@mplsrc.com > > Subject: Re: R:VPN solution center > > > > > > > > Jonathan/Di Giusto, > > > > Thanks for the anwers! > > > > What I would like to know is if VPN-SC from Cisco is > > essential for deploy > > VPN/MPLS solution? Another question is if it possible to use > > VPN-SC after > > the network is already deployed? > > > > Thanks, > > Marcelo. > > > > On Wed, 20 Jun 2001, Jonathan Okhrizty wrote: > > > > > Hi, > > > > > > If you're using VPN-SC, make sure you upgrade to 2.0. > > > It has a very nice feature where it includes XML so it > > > can add new command for the future or > > > user-configurable command to be added to router > > > config. > > > > > > Also VPNSC 2.0 has its own independent TGS and can be > > > provisioned using SSH. > > > > > > > > > Carlos > > > > > > --- Di Giusto Nicola > > > wrote: > > > > Hi Marcelo, > > > > at the moment I 'm testing VPN SC in Telecom Italia > > > > Lab laboratory. > > > > > > > > Nicola > > > > > > > > > ---------- > > > > > Da: Marcelo Blanes[SMTP:mblanes@larc.usp.br] > > > > > Inviato: mercoledì 20 giugno 2001 2.13 > > > > > A: mpls-ops@mplsrc.com > > > > > Oggetto: VPN solution center > > > > > > > > > > Hi, > > > > > > > > > > Does anyone uses the VPN solution center from > > > > Cisco to managed the VPNs? > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Marcelo. > > > > > > > > > > ------- > > > > > The MPLS-OPS Mailing List > > > > > Subscribe/Unsubscribe: > > > > http://www.mplsrc.com/mplsops.shtml > > > > > Archive: > > > > http://www.mplsrc.com/mpls-ops_archive.shtml > > > > > > > > > > > > > ------- > > > > The MPLS-OPS Mailing List > > > > Subscribe/Unsubscribe: > > > > http://www.mplsrc.com/mplsops.shtml > > > > Archive: > > > http://www.mplsrc.com/mpls-ops_archive.shtml > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Get personalized email addresses from Yahoo! Mail > > > http://personal.mail.yahoo.com/ > > > > > > > ------- > > The MPLS-OPS Mailing List > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > > > >-- >This communication contains confidential information intended solely for >the >use of the individual/s and/or entity or entities to whom it was intended >to >be addressed. If you are not the intended recipient, be aware that any >disclosure, copying, distribution, or use of the contents of this >transmission is prohibited. If you have received this communication in >error, please contact the sender immediately, delete this communication >from >your system, and do not disclose its contents to any third party, or use >its >contents. Any opinions expressed are solely those of the author and do not >necessarily represent those of Orchestream Ltd or its group of companies >unless otherwise specifically stated. > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Fri Jun 22 01:40:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00619 for ; Fri, 22 Jun 2001 01:40:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuly00166; Fri, 22 Jun 2001 05:39:25 GMT Received: by mail-control.mail.uu.net id QQkuly28902 for mpls-outgoing; Fri, 22 Jun 2001 05:38:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkuly28891 for ; Fri, 22 Jun 2001 05:38:33 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 QQkuly11406 for ; Fri, 22 Jun 2001 05:37:49 GMT Received: from gateway.ipinfusion.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gt.ipinfusion.com [209.11.132.18] (may be forged)) id QQkuly11339 for ; Fri, 22 Jun 2001 05:37:48 GMT Received: from ipinfusion.com (IDENT:root@[10.10.0.38]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id f5M69iZ03047 for ; Thu, 21 Jun 2001 23:09:44 -0700 Message-ID: <3B32DB17.21C9D6A0@ipinfusion.com> Date: Thu, 21 Jun 2001 22:43:51 -0700 From: Manoj Dutta X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Label Mapping Processing !! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a few doubts in step LMp.29 Section A.1.1 (RFC 3036). i thnk the check for Downstream Unsolicited Independent/Ordered Control is redndant. In case of DU independent control, a mapping is sent to peers as soon as a new fec is recognized and DU ordered control is handled by LMp.19-LMp.21. For pending label requests,,step 1-5 given for DoD should be sufficient for all posible cases. Let me know if this is correct. Also, why is stored hop count value set to UnknownHopCount (0), in this step ? thanks in advance manoj From owner-mpls@UU.NET Fri Jun 22 02:05:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08817 for ; Fri, 22 Jun 2001 02:05:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkuma04635; Fri, 22 Jun 2001 06:04:51 GMT Received: by mail-control.mail.uu.net id QQkuma15696 for mpls-outgoing; Fri, 22 Jun 2001 06:04:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkuma15102 for ; Fri, 22 Jun 2001 06:04:14 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 QQkuma19109 for ; Fri, 22 Jun 2001 06:03:14 GMT Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQkuma02796 for ; Fri, 22 Jun 2001 06:03:11 GMT Received: from multitech.co.in ([211.99.86.84]) by multitech.co.in (8.11.0/8.11.0) with ESMTP id f5M609022662; Fri, 22 Jun 2001 11:30:10 +0530 Message-ID: <3B32DDE3.8261740E@multitech.co.in> Date: Fri, 22 Jun 2001 13:55:47 +0800 From: abhay X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Ashwinp@in.huawei.com CC: naderv@msn.com, mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: What we do if the LSP is preempted References: <464e01c0faae$b99b7380$0e03ca0a@cp98suwbm02> Content-Type: multipart/alternative; boundary="------------C35B00BA6EAD0163611BD41D" Sender: owner-mpls@UU.NET Precedence: bulk --------------C35B00BA6EAD0163611BD41D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ashwin, You can re-route and re-establish the pre-empted LSP,but the newly re-routed LSP may pre-empt others,which may cause a cascade effect. The network topology has to stabilize generally,there needs to be a latency period,before you retry. Regards, Abhay Ashwinp@in.huawei.com wrote: > Hello lei D____________________F > / > \A---------------B---------------------C > \_____E______/Suppose i have a LSP ABEC of priority 3And a LSP ADF > with priority 4Now i want to setup ABC with priority 2.As the > resources are not available on link AB i will preempt LSP ABECBut > there is a LSP ADF with priority 4 less than that of ABEC so if i > preemptABEC then won't it be fair to establish the LSP through ADFC > and preempt ADF if enough resources are not available ? > Thanks > Ashwin > > -----Original Message----- > From: Lei Yao [mailto:lei.yao@wcom.com] > Sent: Tuesday, June 12, 2001 6:38 PM > To: Ashwinp@in.huawei.com > Subject: RE: What we do if the LSP is preempted > > A LSP is preempted because of the lack of network resource. > In other words, there is network congestion. Therefore, you > should not try to re-build the preempted LSP. > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Ashwinp@in.huawei.com > Sent: Tuesday, June 12, 2001 10:12 AM > To: mpls-ops@mplsrc.com; mpls@UU.NET > Subject: What we do if the LSP is preempted > > Dear all > > Can you please tell me what if the LSP is preempted ? Do we > try to reestablish the LSP > with some other path or we will just preempt it ? > If we just preempt the LSP then it will be unfare with that > LSP. And when should we try to > reestablish that LSP ? > > Do anybody has any ionformation regarding this ? > > Thanks in advance > Ashwin > --------------C35B00BA6EAD0163611BD41D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Ashwin,
       You can re-route and re-establish the pre-empted LSP,but the newly re-routed LSP may
       pre-empt others,which may cause a cascade effect.
       The network topology has to stabilize generally,there needs to be a latency period,before
       you retry.
       Regards,
       Abhay



 




Ashwinp@in.huawei.com wrote:


 Hello
lei  
D____________________F
/                                      
\A---------------B---------------------C                  
\_____E______/Suppose
i have a LSP ABEC of priority 3And
a LSP ADF with priority 4Now
i want to setup ABC with priority 2.As
the resources are not available on link AB i will preempt LSP ABECBut
there is a LSP ADF with priority 4 less than that of ABEC so if i preemptABEC
then won't it be fair to establish the LSP through ADFC and preempt ADF if
enough resources are not available ?

Thanks

Ashwin



-----Original
Message-----

From: Lei Yao [mailto:lei.yao@wcom.com]

Sent: Tuesday, June 12, 2001
6:38 PM

To: Ashwinp@in.huawei.com

Subject: RE: What we do if
the LSP is preempted

 





A
LSP is preempted because of the lack of network resource. In other words,
there is network congestion. Therefore, you should not try to re-build
the preempted LSP.







-----Original
Message-----

From:
owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On
Behalf Of Ashwinp@in.huawei.com

Sent:
Tuesday, June 12, 2001 10:12 AM

To:
mpls-ops@mplsrc.com; mpls@UU.NET

Subject:
What we do if the LSP is preempted








Dear
all



Can you please tell me what if the LSP is preempted ? Do we try to reestablish
the LSP 


with some other path or we will just preempt it ? 


If we just preempt the LSP then it will be unfare with that LSP. And when
should we try to 


reestablish that LSP ?


Do
anybody has any ionformation regarding this ?


Thanks
in advance

Ashwin









--------------C35B00BA6EAD0163611BD41D--



From owner-mpls@UU.NET  Fri Jun 22 02:12:09 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09860
	for ; Fri, 22 Jun 2001 02:12:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuma07851;
	Fri, 22 Jun 2001 06:11:12 GMT
Received: by mail-control.mail.uu.net 
	id QQkuma21355
	for mpls-outgoing; Fri, 22 Jun 2001 06:10:40 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkuma21342
	for ; Fri, 22 Jun 2001 06:10: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 QQkuma28118
	for ; Fri, 22 Jun 2001 06:09:53 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkuma07243
	for ; Fri, 22 Jun 2001 06:09:53 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA13231 for mpls@uu.net; Thu, 21 Jun 2001 23:32:27 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkuld25078
	for ; Fri, 22 Jun 2001 00:26:08 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 QQkuld12248
	for ; Fri, 22 Jun 2001 00:25:18 GMT
Received: from zcars0m9.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQkuld18875
	for ; Fri, 22 Jun 2001 00:25:17 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5M0P4003946
	for ; Thu, 21 Jun 2001 20:25:04 -0400 (EDT)
Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 21 Jun 2001 20:25:07 -0400
Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id NMHSS6R1; Thu, 21 Jun 2001 20:25:07 -0400
Received: from americasm06.nt.com (cheevers.engeast.baynetworks.com [192.32.224.102]) 
          by zbl6c002.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id JPBDMTRC; Thu, 21 Jun 2001 20:25:07 -0400
Message-ID: <3B329064.F776D22E@americasm06.nt.com>
Date: Thu, 21 Jun 2001 20:25:08 -0400
From: "Seshu Ganugapati" 
Organization: Nortel Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.5.1 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls 
Subject: unsubscribe
References: <472901c0faae$c06a2850$0e03ca0a@cp98suwbm02>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: 
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit





From owner-mpls@UU.NET  Fri Jun 22 07:48:22 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17174
	for ; Fri, 22 Jun 2001 07:48:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkumx02995;
	Fri, 22 Jun 2001 11:47:10 GMT
Received: by mail-control.mail.uu.net 
	id QQkumx25926
	for mpls-outgoing; Fri, 22 Jun 2001 11:46:28 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkumx25876
	for ; Fri, 22 Jun 2001 11:46:18 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 QQkumw04037
	for ; Fri, 22 Jun 2001 11:43:50 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkumw13345
	for ; Fri, 22 Jun 2001 11:43:49 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA19385 for mpls@uu.net; Fri, 22 Jun 2001 07:43:49 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkums00731
	for ; Fri, 22 Jun 2001 10:37:17 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 QQkums08271
	for ; Fri, 22 Jun 2001 10:37:00 GMT
Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: amsterdam.cisco.com [144.254.74.238])
	id QQkums09275
	for ; Fri, 22 Jun 2001 10:37:00 GMT
Received: from WDEC-W2K.cisco.com (amsterdam3-dhcp102.cisco.com [144.254.51.151])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA07402;
	Fri, 22 Jun 2001 12:36:52 +0200 (MET DST)
Message-Id: <4.3.2.7.2.20010622113925.03854910@amsterdam.cisco.com>
X-Sender: wdec@amsterdam.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 22 Jun 2001 12:36:44 +0200
To: , 
From: Wojciech Dec 
Subject: RE: Use of RD in BGP/MPLS VPN
Cc: 
In-Reply-To: <000a01c0fa2f$13162840$1b07080a@future.futsoft.com>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

I'd say there is a better way to look at this:
You need a RT to figure out into which VRF to import the route to, and I'd 
say that it's a property of a VPN rather than of a particular PE - thinking 
of it in other terms (ie a property of a PE) would lead to increasingly 
complex RT import-export configurations which would not scale, since a new 
PE would imply a config change on all existing PEs
IP addresses need to be made VPN wise unique - The RD makes the ip address 
unique (thereby forming a vpnv4 address).
I guess that so far the above is no news.
Now on top of the above config scaling issues and to explain further 
consider the case of a Route Reflector in the picture and a multi-PE homed 
site (prefix);
the RT for this prefix is the same (belongs to the same VPN), and if there 
were to be no unique RD (or no RD at all) then an RRs would only reflect 
the best prefix (ie only one of the PEs would be the 'target' to reach that 
VPN prefix).

Regards,
Woj.

At 14:19 21/06/2001 +0530, sailendra mahanty wrote:
>Hello Juerg,
>
>At the remote PE, when BGP receives the route update, it won't mantain two
>routes to same IP address (Overlapped IP addresses) if RD is not used. Here
>i agree that RD is needed for BGP regular processing like selecting routes
>from RIB-In to Loc-RIB.
>
>But by some means (say by using RT value) if one can populate appropriate
>VRF with routes to overlapped addresses, RD may not be reuired.
>
>Please let me know if i am missing something ?
>
>Regards,
>-sailendra
>
>-----Original Message-----
>From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of
>Juerg.Fankhauser@swisscom.com
>Sent: Thursday, June 21, 2001 12:44 PM
>To: mpls@uu.net
>Subject: RE: Use of RD in BGP/MPLS VPN
>
>
>Hi Sailendra,
>
>I think that's because an advertized route can be associated with any number
>and combination of RTs (depending on your VPN routing scheme), while it
>carries exactly one RD as part of the address.
>
>That means: Even if it would be possible in theory to resolve the routing
>with RT alone, thanks to the RD it can be handled by regular (multiprotocol)
>BGP processes and tables.
>
>btw - P routers are not even BGP speakers in MPLS/VPN.
>
>Regards,
>-----------------------------
>Juerg FANKHAUSER
>swisscom AG, Bern
>juerg.fankhauser@swisscom.com
>-----------------------------
>
>
>
>-----Original Message-----
>From: sailendra mahanty [mailto:sailendram@future.futsoft.com]
>Sent: Donnerstag, 21. Juni 2001 07:01
>To: mpls@UU.NET
>Subject: Use of RD in BGP/MPLS VPN
>
>
>Hi All,
>
>draft-rosen-rfc2547bis-03.txt clearly distinguish between RD and RT. The aim
>of the RD is to resolve the ambiguity of IP4 address for IP address
>overlapping situation.
>
>IMHO when there is a BGP session between two PEs, the route advertise
>information in UPDATE msg is not used by other BGP speaker ( P routers
>specifically ).
>If i am missing something in saying this please let me know.
>
>If i am right in saying the last statemnet, the address overlapping can be
>resolved at the peer PE by using RT.
>
>Putting the question in other way, what way the RD value associated with a
>route is used in the remote PE ?
>
>Can anybody please help me to get clear picture of RD.
>
>Regards,
>-sailendra

_________________________________________________________
Wojciech Dec   CCIE# 5563      Phone:  +31 (0)20 342 3034
Network Consulting Engineer    E-Mail: wdec@cisco.com
Cisco Systems
PO Box 22514,
1100 DA Amsterdam
The Netherlands



From owner-mpls@UU.NET  Fri Jun 22 10:16:10 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22452
	for ; Fri, 22 Jun 2001 10:16:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkung27899;
	Fri, 22 Jun 2001 14:13:47 GMT
Received: by mail-control.mail.uu.net 
	id QQkung06970
	for mpls-outgoing; Fri, 22 Jun 2001 14:12:59 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkung06917
	for ; Fri, 22 Jun 2001 14:12: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 QQkung01450
	for ; Fri, 22 Jun 2001 14:12:13 GMT
Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQkung26875
	for ; Fri, 22 Jun 2001 14:12:12 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5MECHx10453
	for ; Fri, 22 Jun 2001 07:12:17 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA01968 for mpls@uu.net; Fri, 22 Jun 2001 10:12:10 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkund12457
	for ; Fri, 22 Jun 2001 13:16:21 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 QQkunc08646
	for ; Fri, 22 Jun 2001 13:14:30 GMT
Received: from piorun.ds.pg.gda.pl by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: piorun.ds.pg.gda.pl [213.192.76.1])
	id QQkunc23866
	for ; Fri, 22 Jun 2001 13:14:23 GMT
Received: from localhost (maks@localhost)
	by piorun.ds.pg.gda.pl (8.11.4/8.11.4) with ESMTP id f5MDJ9v28581
	for ; Fri, 22 Jun 2001 15:19:16 +0200
Date: Fri, 22 Jun 2001 15:19:08 +0200 (CEST)
From: Maksymilian Milkowski 
To: 
Subject: intserv vs diffserv
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
I would like to ask about differences in IP QoS models implemented in
MPLS: do they only differ in granularity? When it is recommended to use
the former and when the latter? Does the type of hardware (ATM-LSRs, IP
routers) have any influence on this choice?
And one question regarding diffserv only: does the setting up of
packet's DSCP value in domain boundary mean that this packet will be
treated in the same way in all nodes of the domain?

Thanks in advance,

Maks Milkowski




From owner-mpls@UU.NET  Fri Jun 22 10:17:31 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22514
	for ; Fri, 22 Jun 2001 10:17:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkung29015;
	Fri, 22 Jun 2001 14:14:55 GMT
Received: by mail-control.mail.uu.net 
	id QQkung06988
	for mpls-outgoing; Fri, 22 Jun 2001 14:13:09 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkung06937
	for ; Fri, 22 Jun 2001 14:12:49 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 QQkung05086
	for ; Fri, 22 Jun 2001 14:11:20 GMT
Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQkung26465
	for ; Fri, 22 Jun 2001 14:11:17 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5MEBMx10033
	for ; Fri, 22 Jun 2001 07:11:22 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA01955 for mpls@uu.net; Fri, 22 Jun 2001 10:11:16 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkukr09343
	for ; Thu, 21 Jun 2001 21:28:14 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 QQkukr28154
	for ; Thu, 21 Jun 2001 21:28:01 GMT
Received: from eikenes.alvestrand.no by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 217-13-28-204.dd.nextgentel.com [217.13.28.204])
	id QQkukr08164
	for ; Thu, 21 Jun 2001 21:28:00 GMT
Received: from HALVESTR-W2K.cisco.com (eikenes.alvestrand.no [217.13.28.203])
	by eikenes.alvestrand.no (Postfix) with ESMTP
	id 348B461CC4; Thu, 21 Jun 2001 23:27:08 +0200 (CEST)
Date: Thu, 21 Jun 2001 23:27:03 +0200
From: Harald Tveit Alvestrand 
To: ah_smith@pacbell.net, te-wg@ops.ietf.org, mpls@UU.NET,
        subip-area@subip.ietf.org
Cc: rap@ops.ietf.org, franr@pfn.com,
        "Hegde, Shriharsha" , iesg@ietf.org
Subject: RE: MPLS and COPS
Message-ID: <60077867.993166023@HALVESTR-W2K.cisco.com>
In-Reply-To: 
References:  
X-Mailer: Mulberry/2.1.0a6 (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

Note:

If there is a piece of standards work that is needed, well defined
and not part of any WG's charter, there is a shorter process:

- Write it up as an internet-draft.
- Talk about it in whatever fashion you like.
- Get a friendly AD to sponsor it.
- Do the 4-week IETF-wide Last Call.
- You're done.

Don't let the fact that it's an item too small to spin up a WG for block 
you from doing what's right.


--On 21. juni 2001 11:53 -0700 Andrew Smith  wrote:

> If:
> (a) none of the existing WGs want the work item
> (b) there are willing and able people to do the work
> (c) it doesn't overlap with other work
> (d) it is a legitimate, missing piece of what seems to be a popular
> (proposed) standard
>
> then find a friendly AD (doesn't seem to matter which Area), hold a BoF,
> if anyone shows up for the BoF ask to form a WG and go from there. Don't
> let the unwillingness of existing WGs (or their chairs or their ADs) stop
> a piece of work that people, both vendors and consumers, want to see
> standardised. Fran and Harsha, you know the process - just get the work
> done.






From owner-mpls@UU.NET  Fri Jun 22 10:39:12 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23345
	for ; Fri, 22 Jun 2001 10:39:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuni29300;
	Fri, 22 Jun 2001 14:37:35 GMT
Received: by mail-control.mail.uu.net 
	id QQkuni09756
	for mpls-outgoing; Fri, 22 Jun 2001 14:37:03 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkuni09744
	for ; Fri, 22 Jun 2001 14:36: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 QQkuni07849
	for ; Fri, 22 Jun 2001 14:35:35 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkuni28379
	for ; Fri, 22 Jun 2001 14:35:34 GMT
Message-ID: <3B3357B5.87973940@sandburst.com>
Date: Fri, 22 Jun 2001 10:35:33 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Manoj Dutta 
Cc: mpls@UU.NET
Subject: Re: Label Mapping Processing !!
References: <3B32DB17.21C9D6A0@ipinfusion.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Manoj,

    So, if you look at the test in LMp.28, you see that LMp.29 is skipped if
there are no outstanding label requests.

    The behavior you're pointing out is correct as is.

    If the LSR is using either independent or ordered control, downstream
unsolicited label distribution, the only way that it would have outstanding
label requests is if the upstream LSR needs more than one label and has
not yet received additional ones it asked for.  The idea is that - in DU mode
- the upstream LSR will get one label for free; if it asks for a label, it must
be because it wants at least two.  Therefore, sending labels for outstanding
requests is definitely not redundant.

--
Eric Gray

You wrote:

> Hi,
>
> I have a few doubts in step LMp.29 Section A.1.1 (RFC 3036). i thnk the
> check for Downstream Unsolicited
> Independent/Ordered Control is redndant. In case of DU independent
> control,  a mapping is sent to peers as
> soon as a new fec is recognized and DU ordered control is handled by
> LMp.19-LMp.21.   For pending
> label requests,,step 1-5 given for DoD should be sufficient for all
> posible cases.  Let me know if this is correct.
> Also,  why is stored hop count value set to UnknownHopCount (0), in this
> step ?
>
> thanks in advance
> manoj



From owner-mpls@UU.NET  Fri Jun 22 11:31:00 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26211
	for ; Fri, 22 Jun 2001 11:30:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkunl13802;
	Fri, 22 Jun 2001 15:28:44 GMT
Received: by mail-control.mail.uu.net 
	id QQkunl04757
	for mpls-outgoing; Fri, 22 Jun 2001 15:28:10 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkunl04745
	for ; Fri, 22 Jun 2001 15:28:03 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 QQkunl03639
	for ; Fri, 22 Jun 2001 15:24:03 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 QQkunl10555
	for ; Fri, 22 Jun 2001 15:24:02 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5MFO1h23970
	for ; Fri, 22 Jun 2001 08:24:01 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA02289 for mpls@uu.net; Fri, 22 Jun 2001 11:24:00 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkunj11309
	for ; Fri, 22 Jun 2001 14:51: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 QQkunj02176
	for ; Fri, 22 Jun 2001 14:48:14 GMT
Received: from c0mailgw04.prontomail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mailgw.prontomail.com [216.163.180.10])
	id QQkunj06396
	for ; Fri, 22 Jun 2001 14:48:14 GMT
Received: by c0mailgw04.prontomail.com (NPlex 5.5.015.3) id 3B32AE35000215B0; Fri, 22 Jun 2001 07:42:25 -0700
Received: from 148.75.48.66 by SmtpServer for ; Fri, 22 Jun 2001 14:42:21 +0000
Reply-To: 
From: "Dennis Hartmann" 
To: , 
Cc: , , 
Subject: RE: Tag-switching -vs- MPLS !!!
Date: Fri, 22 Jun 2001 10:49:31 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <473201c0faae$c09ea5d0$0e03ca0a@cp98suwbm02>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

    As far as Cisco CLI goes, I found this out playing in the lab the other
day.

Cisco's tag-switching distribution protocol "TDP" uses a 255.255.255.255
broadcast and MPLS LDP uses the all routers multicast address of 224.0.0.2
(per debug ip packet details).

Sincerely,

Dennis J. Hartmann
White Pine Consulting
dennisjhartmann@hotmail.com
(914) 980-0316 (cellular)
(845) 896-4777 (home)
AOL IM: dennisjhartmann
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
bhupeshb@in.huawei.com
Sent: Thursday, June 21, 2001 8:03 PM
To: naderv@msn.com
Cc: mpls-ops@mplsrc.com; mpls@UU.NET
Subject: RE: Tag-switching -vs- MPLS !!!
Importance: High


tag switching is the general term used to notify a methodology
MPLS uses that methodology ...of tag switching.
dont confuse the terms technology and methodology ..
MPLs is a technology which uses a kind of methodology of tag - switching
which might be in use by some other protocols or technologies too....
regards
bhupesh


-----Original Message-----
From: Sivaramakrishna Iyer Krishnan
[mailto:krishnan@researchbell-labs.com]
Sent: Monday, June 11, 2001 11:44 PM
To: mpls-ops@mplsrc.com
Subject: Tag-switching -vs- MPLS !!!



Hi All,
I am not sure what is the difference between tag-switching and MPLS
????????....
Also, are all mpls commands backward compatible to tag-switching ???...
Thanks,
Krishnan.
-------
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 Jun 22 11:34:01 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26405
	for ; Fri, 22 Jun 2001 11:34:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkunm16408;
	Fri, 22 Jun 2001 15:31:55 GMT
Received: by mail-control.mail.uu.net 
	id QQkunm05133
	for mpls-outgoing; Fri, 22 Jun 2001 15:31:20 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkunm05012
	for ; Fri, 22 Jun 2001 15:31: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 QQkunl23968
	for ; Fri, 22 Jun 2001 15:29:05 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 QQkunl14201
	for ; Fri, 22 Jun 2001 15:29:05 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5MFT8h27305
	for ; Fri, 22 Jun 2001 08:29:08 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA02367 for mpls@uu.net; Fri, 22 Jun 2001 11:29:03 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkunl04720
	for ; Fri, 22 Jun 2001 15:27: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 QQkunl18849
	for ; Fri, 22 Jun 2001 15:25:24 GMT
Received: from web5304.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5304.mail.yahoo.com [216.115.106.113])
	id QQkunl00104
	for ; Fri, 22 Jun 2001 15:25:23 GMT
Message-ID: <20010622152523.9878.qmail@web5304.mail.yahoo.com>
Received: from [128.100.244.36] by web5304.mail.yahoo.com; Fri, 22 Jun 2001 08:25:23 PDT
Date: Fri, 22 Jun 2001 08:25:23 -0700 (PDT)
From: Norm Rumac 
Subject: Typcial Blocking Probabilites in WDM networks?
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Does anyone know what would be an acceptable range for
blocking probabilites withing a carrier supporting
dynamic lightpath establishment (via GMPLS etc.)?

Would it be ludicrous to assume a long-haul optical
carrier refusing more than say 15 percent of the
requests for connection establishment?


Thanks,

--Norm

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/



From owner-mpls@UU.NET  Fri Jun 22 11:58:06 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28076
	for ; Fri, 22 Jun 2001 11:58:06 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkunn28241;
	Fri, 22 Jun 2001 15:55:55 GMT
Received: by mail-control.mail.uu.net 
	id QQkunn07845
	for mpls-outgoing; Fri, 22 Jun 2001 15:55:16 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkunn07817
	for ; Fri, 22 Jun 2001 15: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 QQkunn28204
	for ; Fri, 22 Jun 2001 15:52:02 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkunn16380
	for ; Fri, 22 Jun 2001 15:52:01 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA04226 for mpls@uu.net; Fri, 22 Jun 2001 11:52:01 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkunn07487
	for ; Fri, 22 Jun 2001 15:51: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 QQkunm20965
	for ; Fri, 22 Jun 2001 15:44:23 GMT
Received: from mailsrv.coronanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [38.186.47.7])
	id QQkunm10079
	for ; Fri, 22 Jun 2001 15:44:22 GMT
Received: from hamrick (63.137.88.2 [63.137.88.2]) by mailsrv.coronanetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id M29AH461; Fri, 22 Jun 2001 08:46:19 -0700
From: "Vincent Hamrick" 
To: "'Vipul Sharma'" , 
Cc: 
Subject: RE: LSR-MIB Question
Date: Fri, 22 Jun 2001 11:39:27 -0400
Message-ID: <00e601c0fb31$8624c5a0$0808650a@coronanetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <46cc01c0faae$bd7419d0$0e03ca0a@cp98suwbm02>
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

What if you replace the top label and then push another label?  Against
which label would you store the outSegment counts?  Or would you store them
against both labels?

Thanks,
-V


-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vipul
Sharma
Sent: Thursday, June 21, 2001 8:03 PM
To: naderv@msn.com
Cc: mpls@UU.NET
Subject: RE: LSR-MIB Question


Shahram,
	I had run into similar question a while ago...Attached is the info. which
will help you for 1.
My feeling is that since there is no error conditions maybe they need to be
collected in mplsInSegmentDiscards. But that is just what I beleive maybe
the gurus have a differing opinion.
For 2, I believe that we are reqd. to keep 2 sets of stats one for the
swapped label and one for the pushed label
	Thanx,
Vip
vsharma@ieee.org

Attached message
=================================================================


>         In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see stats for errored
> packets.
>For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors which is "The
>number of errored packets received on this segment."
>         My question is what type of errors make these packets errored
packets
>because most errored packets are dropped at the physical interface iteself
>by the chips (my understanding). So does this stats put a req. to run the
>phy. interface device in promiscous mode?

         Basically any case where a labeled packet is received and
cannot be forwarded by the MPLS software. There are many cases:
out of bandwidth in the switching fabric, illegal labels in the
packet, etc...


         --Tom




>Vip
>

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of S. Davari
Sent: Monday, June 11, 2001 6:42 PM
To: mpls@UU.NET
Subject: LSR-MIB Question


Hi All,

A few questions regarding LSR-MIB:

1) If TTL expires in an MPLS packet is the packet
counted in
mplsInSegmentErrors" or not?

2) If we receive a labeled packet and swap the label
and then push a new label
do we keep 2 sets of statistics on the outgoing
segment, one for the swapped
label and one for the pushed label or only one?

BTW, I also noticed that in LSR-MIB a swap consists of
a pop on incoming segment followed
by a push on outgoing segment, this is odd !! The
odder thing is that the incoming segment has
a parameter called InSegmentNpop in which "N"
identifies the number of pops to be performed on the
insegment. How does one know in advance how many pops
to perform? If you know that, then it means
that all those labels that you pop are not used at
all.

Thanks,
-Shahram

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca




From owner-mpls@UU.NET  Fri Jun 22 12:33:19 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29521
	for ; Fri, 22 Jun 2001 12:33:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkunq13619;
	Fri, 22 Jun 2001 16:31:01 GMT
Received: by mail-control.mail.uu.net 
	id QQkunq01203
	for mpls-outgoing; Fri, 22 Jun 2001 16:30:22 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkunq01195
	for ; Fri, 22 Jun 2001 16:30:15 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkunp22938
	for ; Fri, 22 Jun 2001 16:28:49 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkunp17178
	for ; Fri, 22 Jun 2001 16:28:49 GMT
Message-ID: <3B33723F.98E21CFB@sandburst.com>
Date: Fri, 22 Jun 2001 12:28:47 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Vincent Hamrick 
Cc: "'Vipul Sharma'" , naderv@msn.com, mpls@UU.NET
Subject: Re: LSR-MIB Question
References: <00e601c0fb31$8624c5a0$0808650a@coronanetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Vincent,

    Think about it this way: a (set of) label(s) on an inSegment map
reliably to a specific label stack manipulation (pop, swap, push,
shake, rattle and/or roll) for any given LSP.

--
Eric Gray

You wrote:

> What if you replace the top label and then push another label?  Against
> which label would you store the outSegment counts?  Or would you store them
> against both labels?
>
> Thanks,
> -V
>
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vipul
> Sharma
> Sent: Thursday, June 21, 2001 8:03 PM
> To: naderv@msn.com
> Cc: mpls@UU.NET
> Subject: RE: LSR-MIB Question
>
> Shahram,
>         I had run into similar question a while ago...Attached is the info. which
> will help you for 1.
> My feeling is that since there is no error conditions maybe they need to be
> collected in mplsInSegmentDiscards. But that is just what I beleive maybe
> the gurus have a differing opinion.
> For 2, I believe that we are reqd. to keep 2 sets of stats one for the
> swapped label and one for the pushed label
>         Thanx,
> Vip
> vsharma@ieee.org
>
> Attached message
> =================================================================
>
> >         In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see stats for errored
> > packets.
> >For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors which is "The
> >number of errored packets received on this segment."
> >         My question is what type of errors make these packets errored
> packets
> >because most errored packets are dropped at the physical interface iteself
> >by the chips (my understanding). So does this stats put a req. to run the
> >phy. interface device in promiscous mode?
>
>          Basically any case where a labeled packet is received and
> cannot be forwarded by the MPLS software. There are many cases:
> out of bandwidth in the switching fabric, illegal labels in the
> packet, etc...
>
>          --Tom
>
> >Vip
> >
>
> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of S. Davari
> Sent: Monday, June 11, 2001 6:42 PM
> To: mpls@UU.NET
> Subject: LSR-MIB Question
>
> Hi All,
>
> A few questions regarding LSR-MIB:
>
> 1) If TTL expires in an MPLS packet is the packet
> counted in
> mplsInSegmentErrors" or not?
>
> 2) If we receive a labeled packet and swap the label
> and then push a new label
> do we keep 2 sets of statistics on the outgoing
> segment, one for the swapped
> label and one for the pushed label or only one?
>
> BTW, I also noticed that in LSR-MIB a swap consists of
> a pop on incoming segment followed
> by a push on outgoing segment, this is odd !! The
> odder thing is that the incoming segment has
> a parameter called InSegmentNpop in which "N"
> identifies the number of pops to be performed on the
> insegment. How does one know in advance how many pops
> to perform? If you know that, then it means
> that all those labels that you pop are not used at
> all.
>
> Thanks,
> -Shahram
>
> _______________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.ca address at http://mail.yahoo.ca



From owner-mpls@UU.NET  Fri Jun 22 12:55:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00148
	for ; Fri, 22 Jun 2001 12:55:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkunr16076;
	Fri, 22 Jun 2001 16:51:56 GMT
Received: by mail-control.mail.uu.net 
	id QQkunr03008
	for mpls-outgoing; Fri, 22 Jun 2001 16:51:23 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkunr02940
	for ; Fri, 22 Jun 2001 16:51: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 QQkunr19162
	for ; Fri, 22 Jun 2001 16:50:57 GMT
Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQkunr28718
	for ; Fri, 22 Jun 2001 16:50:56 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5MGp3x21213
	for ; Fri, 22 Jun 2001 09:51:03 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA02580 for mpls@uu.net; Fri, 22 Jun 2001 12:50:54 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkunl04720
	for ; Fri, 22 Jun 2001 15:27: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 QQkunl18849
	for ; Fri, 22 Jun 2001 15:25:24 GMT
Received: from web5304.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5304.mail.yahoo.com [216.115.106.113])
	id QQkunl00104
	for ; Fri, 22 Jun 2001 15:25:23 GMT
Message-ID: <20010622152523.9878.qmail@web5304.mail.yahoo.com>
Received: from [128.100.244.36] by web5304.mail.yahoo.com; Fri, 22 Jun 2001 08:25:23 PDT
Date: Fri, 22 Jun 2001 08:25:23 -0700 (PDT)
From: Norm Rumac 
Subject: Typcial Blocking Probabilites in WDM networks?
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

Does anyone know what would be an acceptable range for
blocking probabilites withing a carrier supporting
dynamic lightpath establishment (via GMPLS etc.)?

Would it be ludicrous to assume a long-haul optical
carrier refusing more than say 15 percent of the
requests for connection establishment?


Thanks,

--Norm

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/



From owner-mpls@UU.NET  Fri Jun 22 12:56:18 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00171
	for ; Fri, 22 Jun 2001 12:56:17 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkunr29652;
	Fri, 22 Jun 2001 16:53:23 GMT
Received: by mail-control.mail.uu.net 
	id QQkunr03113
	for mpls-outgoing; Fri, 22 Jun 2001 16:52:49 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkunr03088
	for ; Fri, 22 Jun 2001 16:52:16 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 QQkunr26049
	for ; Fri, 22 Jun 2001 16:51:11 GMT
Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQkunr18131
	for ; Fri, 22 Jun 2001 16:51:10 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5MGpDh00329
	for ; Fri, 22 Jun 2001 09:51:13 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA02584 for mpls@uu.net; Fri, 22 Jun 2001 12:51:08 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkunr02848
	for ; Fri, 22 Jun 2001 16:49:22 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 QQkunr23107
	for ; Fri, 22 Jun 2001 16:47:16 GMT
Received: from web5303.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web5303.mail.yahoo.com [216.115.106.112])
	id QQkunr25013
	for ; Fri, 22 Jun 2001 16:47:16 GMT
Message-ID: <20010622164715.6782.qmail@web5303.mail.yahoo.com>
Received: from [128.100.122.196] by web5303.mail.yahoo.com; Fri, 22 Jun 2001 09:47:15 PDT
Date: Fri, 22 Jun 2001 09:47:15 -0700 (PDT)
From: Norm Rumac 
Subject: re: Typcial Blocking Probabilites in WDM networks?
To: Tom Scott 
Cc: mpls@UU.NET
In-Reply-To: <3B336A34.D5A03AA7@dacor.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

Tom,
I am thinking wavelengths here.  If you are
interested, I am also thinking of a model consistent
with the framework given in section 6 of the following
document (although my question is more general in
nature):



http://www.ietf.org/internet-drafts/draft-many-ip-optical-framework-03.txt



--Norm

--- Tom Scott  wrote:
> Norm,
> 
> I don't have an answer but I'm interested in the
> issue. Could you refer
> me to a whitepaper, I-D, or RFC that describes
> dynamic lightpath
> management/control (creation, maintenance,
> deletion)? 
> 
> (I assume that you mean wavelengths/lambdas or some
> other unit of
> dynamically assignable fiber resources. The only
> units or regimes I'm
> familiar with are from GMPLS: packets, time slots,
> wavelengths, fibers.)
> 
> -- TT
> 
> 
> -------- Original Message --------
> Subject: Typcial Blocking Probabilites in WDM
> networks?
> Date: Fri, 22 Jun 2001 08:25:23 -0700 (PDT)
> From: Norm Rumac 
> To: mpls@UU.NET
> 
> Hi,
> 
> Does anyone know what would be an acceptable range
> for
> blocking probabilites withing a carrier supporting
> dynamic lightpath establishment (via GMPLS etc.)?
> 
> Would it be ludicrous to assume a long-haul optical
> carrier refusing more than say 15 percent of the
> requests for connection establishment?
> 
> 
> Thanks,
> 
> --Norm
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/



From owner-mpls@UU.NET  Fri Jun 22 13:09:18 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00586
	for ; Fri, 22 Jun 2001 13:09:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuns10658;
	Fri, 22 Jun 2001 17:08:51 GMT
Received: by mail-control.mail.uu.net 
	id QQkuns23551
	for mpls-outgoing; Fri, 22 Jun 2001 17:08:11 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkuns23539
	for ; Fri, 22 Jun 2001 17:08: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 QQkuns11782
	for ; Fri, 22 Jun 2001 17:01:27 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkuns00958
	for ; Fri, 22 Jun 2001 17:01:27 GMT
Message-ID: <3B3379E0.3D9DDC13@sandburst.com>
Date: Fri, 22 Jun 2001 13:01:20 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Manoj Dutta 
Cc: mpls@UU.NET
Subject: Re: Label Mapping Message !!
References: <3B2FA4C1.CABD0147@ipinfusion.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Manoj,

    I apologize for not following through on this when you raised it the
first time.  I talked to Bob Thomas about this off-line after your earlier
posting (Re: Loop Detection) and it appears that the statement "Goto LMp.33"
that appears on the line after "LMp.7   Remove Label from ..." was included
in error.  Note that this statement also appears at the end of LMp.8.

    Bob and I both feel that this statement is an error, where it appears in
LMP.7, and I had meant to respond to your posting on the mailing list in a
bit more timely fashion.  Guess I got busy, lazy or just plain forgetfull -
I'm too lazy (with all this work going on) to remember which.  I appreciate
your persistence in bringing it up again.

    In general, as your mail pointed out both times, it is just bad to stop
using a label without releasing it.

--
Eric Gray

Most recently, you wrote:

> Hi,
>
> In section A.1.2 , subsection LMp.6 (RFC 3036), it is mentioned that in
> case of loop detection, the
> matching label mapping should be removed. I have the following doubts :-
>
> 1) Should a label release message be sent for this label ?
> 2) Should a withdraw be sent to all the peers which have been sent a
> label corresponding to the label being
> deleted ? A related question is what happens to incoming packets with
> valid labels but no outgoing labels ?
>
> thanks in advance
> manoj

And earlier, you wrote:

> Subject: Loop Detection !!
>    Date: Tue, 29 May 2001 19:38:24 -0700
>    From: Manoj Dutta
>      To: mpls@UU.NET
>
>
>
>
> Hi,
>
> I have a few doubts regarding loop detection in RFC 3036 :-
>
> a)  If an LSR A receives a mapping fron a downstream LSR B and a loop is
> detected on checking the attributes, then  the label is released by
> LASR A only if there is no matching mapping received previously.  Why is
> the mapping not  released in case there is a matching mapping already
> present in the LSR A.
>
> b)  The algorithm for handling loop detection messages received in
> response to label mapping message is not very clear.  According to the
> RFC it should be handled in the same manner as No Route notification
> message (A.1.10) but A.1.10 describes the case when a No Route is
> received in response to request message only.
>
> Thanks in advance
> manoj
>





From owner-mpls@UU.NET  Fri Jun 22 13:51:29 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02096
	for ; Fri, 22 Jun 2001 13:51:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkunv08890;
	Fri, 22 Jun 2001 17:50:14 GMT
Received: by mail-control.mail.uu.net 
	id QQkunv27661
	for mpls-outgoing; Fri, 22 Jun 2001 17:49:32 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkunv27654
	for ; Fri, 22 Jun 2001 17:49:23 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkunv09021
	for ; Fri, 22 Jun 2001 17:48:15 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkunv05912
	for ; Fri, 22 Jun 2001 17:48:14 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA11680 for mpls@uu.net; Fri, 22 Jun 2001 13:48:14 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkunv27385
	for ; Fri, 22 Jun 2001 17:47:44 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 QQkunv11385
	for ; Fri, 22 Jun 2001 17:46:49 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 QQkunv11402
	for ; Fri, 22 Jun 2001 17:46:49 GMT
Received: (qmail 13611 invoked by uid 104); 22 Jun 2001 17:46:48 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.437133 secs); 22/06/2001 10:46:47
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by father.pmc-sierra.bc.ca with SMTP; 22 Jun 2001 17:46:47 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5MHkke03542;
	Fri, 22 Jun 2001 10:46:46 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id ; Fri, 22 Jun 2001 10:50:49 -0700
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D19@BBY1EXM01>
From: Shahram Davari 
To: "'Eric Gray'" ,
        Vincent Hamrick
	 
Cc: "'Vipul Sharma'" , naderv@msn.com, mpls@UU.NET
Subject: RE: LSR-MIB Question
Date: Fri, 22 Jun 2001 10:50:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Eric,

Does this mean that a transmitted MPLS packet will update only one outsegment? (no multicast)

-Shahram

> -----Original Message-----
> From: Eric Gray [mailto:eric.gray@sandburst.com]
> Sent: Friday, June 22, 2001 12:29 PM
> To: Vincent Hamrick
> Cc: 'Vipul Sharma'; naderv@msn.com; mpls@UU.NET
> Subject: Re: LSR-MIB Question
> 
> 
> Vincent,
> 
>     Think about it this way: a (set of) label(s) on an inSegment map
> reliably to a specific label stack manipulation (pop, swap, push,
> shake, rattle and/or roll) for any given LSP.
> 
> --
> Eric Gray
> 
> You wrote:
> 
> > What if you replace the top label and then push another 
> label?  Against
> > which label would you store the outSegment counts?  Or 
> would you store them
> > against both labels?
> >
> > Thanks,
> > -V
> >
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vipul
> > Sharma
> > Sent: Thursday, June 21, 2001 8:03 PM
> > To: naderv@msn.com
> > Cc: mpls@UU.NET
> > Subject: RE: LSR-MIB Question
> >
> > Shahram,
> >         I had run into similar question a while 
> ago...Attached is the info. which
> > will help you for 1.
> > My feeling is that since there is no error conditions maybe 
> they need to be
> > collected in mplsInSegmentDiscards. But that is just what I 
> beleive maybe
> > the gurus have a differing opinion.
> > For 2, I believe that we are reqd. to keep 2 sets of stats 
> one for the
> > swapped label and one for the pushed label
> >         Thanx,
> > Vip
> > vsharma@ieee.org
> >
> > Attached message
> > =================================================================
> >
> > >         In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see 
> stats for errored
> > > packets.
> > >For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors 
> which is "The
> > >number of errored packets received on this segment."
> > >         My question is what type of errors make these 
> packets errored
> > packets
> > >because most errored packets are dropped at the physical 
> interface iteself
> > >by the chips (my understanding). So does this stats put a 
> req. to run the
> > >phy. interface device in promiscous mode?
> >
> >          Basically any case where a labeled packet is received and
> > cannot be forwarded by the MPLS software. There are many cases:
> > out of bandwidth in the switching fabric, illegal labels in the
> > packet, etc...
> >
> >          --Tom
> >
> > >Vip
> > >
> >
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf 
> Of S. Davari
> > Sent: Monday, June 11, 2001 6:42 PM
> > To: mpls@UU.NET
> > Subject: LSR-MIB Question
> >
> > Hi All,
> >
> > A few questions regarding LSR-MIB:
> >
> > 1) If TTL expires in an MPLS packet is the packet
> > counted in
> > mplsInSegmentErrors" or not?
> >
> > 2) If we receive a labeled packet and swap the label
> > and then push a new label
> > do we keep 2 sets of statistics on the outgoing
> > segment, one for the swapped
> > label and one for the pushed label or only one?
> >
> > BTW, I also noticed that in LSR-MIB a swap consists of
> > a pop on incoming segment followed
> > by a push on outgoing segment, this is odd !! The
> > odder thing is that the incoming segment has
> > a parameter called InSegmentNpop in which "N"
> > identifies the number of pops to be performed on the
> > insegment. How does one know in advance how many pops
> > to perform? If you know that, then it means
> > that all those labels that you pop are not used at
> > all.
> >
> > Thanks,
> > -Shahram
> >
> > _______________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.ca address at http://mail.yahoo.ca
> 



From owner-mpls@UU.NET  Fri Jun 22 14:29:51 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03487
	for ; Fri, 22 Jun 2001 14:29:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkunx24175;
	Fri, 22 Jun 2001 18:29:24 GMT
Received: by mail-control.mail.uu.net 
	id QQkunx21051
	for mpls-outgoing; Fri, 22 Jun 2001 18:28:53 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkunx21021
	for ; Fri, 22 Jun 2001 18:28: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 QQkunx18535
	for ; Fri, 22 Jun 2001 18:27:40 GMT
Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkunx22424
	for ; Fri, 22 Jun 2001 18:27:39 GMT
Message-ID: <3B338E1A.C4AD95B8@sandburst.com>
Date: Fri, 22 Jun 2001 14:27:38 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Shahram Davari 
Cc: mpls@UU.NET
Subject: Re: LSR-MIB Question
References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D19@BBY1EXM01>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Shahram,

    In terms of the MIB, no that is not what this means.

--
Eric Gray

You wrote:

> Eric,
>
> Does this mean that a transmitted MPLS packet will update only one outsegment? (no multicast)
>
> -Shahram
>
> > -----Original Message-----
> > From: Eric Gray [mailto:eric.gray@sandburst.com]
> > Sent: Friday, June 22, 2001 12:29 PM
> > To: Vincent Hamrick
> > Cc: 'Vipul Sharma'; naderv@msn.com; mpls@UU.NET
> > Subject: Re: LSR-MIB Question
> >
> >
> > Vincent,
> >
> >     Think about it this way: a (set of) label(s) on an inSegment map
> > reliably to a specific label stack manipulation (pop, swap, push,
> > shake, rattle and/or roll) for any given LSP.
> >
> > --
> > Eric Gray
> >
> > You wrote:
> >
> > > What if you replace the top label and then push another
> > label?  Against
> > > which label would you store the outSegment counts?  Or
> > would you store them
> > > against both labels?
> > >
> > > Thanks,
> > > -V
> > >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vipul
> > > Sharma
> > > Sent: Thursday, June 21, 2001 8:03 PM
> > > To: naderv@msn.com
> > > Cc: mpls@UU.NET
> > > Subject: RE: LSR-MIB Question
> > >
> > > Shahram,
> > >         I had run into similar question a while
> > ago...Attached is the info. which
> > > will help you for 1.
> > > My feeling is that since there is no error conditions maybe
> > they need to be
> > > collected in mplsInSegmentDiscards. But that is just what I
> > beleive maybe
> > > the gurus have a differing opinion.
> > > For 2, I believe that we are reqd. to keep 2 sets of stats
> > one for the
> > > swapped label and one for the pushed label
> > >         Thanx,
> > > Vip
> > > vsharma@ieee.org
> > >
> > > Attached message
> > > =================================================================
> > >
> > > >         In the MPLS MIBs (MPLS TE , MPLS LSR MIBs)I see
> > stats for errored
> > > > packets.
> > > >For e.g. in the MPLS LSR MIB there is mplsInSegmentErrors
> > which is "The
> > > >number of errored packets received on this segment."
> > > >         My question is what type of errors make these
> > packets errored
> > > packets
> > > >because most errored packets are dropped at the physical
> > interface iteself
> > > >by the chips (my understanding). So does this stats put a
> > req. to run the
> > > >phy. interface device in promiscous mode?
> > >
> > >          Basically any case where a labeled packet is received and
> > > cannot be forwarded by the MPLS software. There are many cases:
> > > out of bandwidth in the switching fabric, illegal labels in the
> > > packet, etc...
> > >
> > >          --Tom
> > >
> > > >Vip
> > > >
> > >
> > > -----Original Message-----
> > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf
> > Of S. Davari
> > > Sent: Monday, June 11, 2001 6:42 PM
> > > To: mpls@UU.NET
> > > Subject: LSR-MIB Question
> > >
> > > Hi All,
> > >
> > > A few questions regarding LSR-MIB:
> > >
> > > 1) If TTL expires in an MPLS packet is the packet
> > > counted in
> > > mplsInSegmentErrors" or not?
> > >
> > > 2) If we receive a labeled packet and swap the label
> > > and then push a new label
> > > do we keep 2 sets of statistics on the outgoing
> > > segment, one for the swapped
> > > label and one for the pushed label or only one?
> > >
> > > BTW, I also noticed that in LSR-MIB a swap consists of
> > > a pop on incoming segment followed
> > > by a push on outgoing segment, this is odd !! The
> > > odder thing is that the incoming segment has
> > > a parameter called InSegmentNpop in which "N"
> > > identifies the number of pops to be performed on the
> > > insegment. How does one know in advance how many pops
> > > to perform? If you know that, then it means
> > > that all those labels that you pop are not used at
> > > all.
> > >
> > > Thanks,
> > > -Shahram
> > >
> > > _______________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.ca address at http://mail.yahoo.ca
> >



From owner-mpls@UU.NET  Fri Jun 22 14:39:19 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03967
	for ; Fri, 22 Jun 2001 14:39:18 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuny05443;
	Fri, 22 Jun 2001 18:38:52 GMT
Received: by mail-control.mail.uu.net 
	id QQkuny21916
	for mpls-outgoing; Fri, 22 Jun 2001 18:38:21 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkuny21905
	for ; Fri, 22 Jun 2001 18:38: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 QQkuny00920
	for ; Fri, 22 Jun 2001 18:36:18 GMT
Received: from zsc3s002.nortelnetworks.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: h86s136a81n47.user.nortelnetworks.com [47.81.136.86])
	id QQkuny01600
	for ; Fri, 22 Jun 2001 18:36:18 GMT
Received: from zsc4s001.baynetworks.com by zsc3s002.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id LAA19769; Fri, 22 Jun 2001 11:06:39 -0700
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Fri, 22 Jun 2001 11:28:50 -0700
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 22 Jun 2001 11:35:56 -0700
Message-ID: <8B888AAAAB0FD31189590008C7918443074E29ED@zbl6c002.corpeast.baynetworks.com>
From: "Stephen Suryaputra" 
To: Norm Rumac , Tom Scott 
Cc: mpls@UU.NET
Subject: RE: Typcial Blocking Probabilites in WDM networks?
Date: Fri, 22 Jun 2001 11:35:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0FB4A.2BE39260"
X-Orig: 
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FB4A.2BE39260
Content-Type: text/plain;
	charset="iso-8859-1"

I would think that the blocking probability depends on
the call pattern of the connection. I'm not so sure if
we can assume that the call patern is similar to voice.
If it is then Erlang blocking formula might be relevant.

Furthermore, the acceptable blocking probability is really
depends on the user, I think.

Cheers,

> -----Original Message-----
> From: Norm Rumac [mailto:norm_rumac@yahoo.com]
> Sent: Friday, June 22, 2001 12:47 PM
> To: Tom Scott
> Cc: mpls@UU.NET
> Subject: re: Typcial Blocking Probabilites in WDM networks?
> 
> 
> Tom,
> I am thinking wavelengths here.  If you are
> interested, I am also thinking of a model consistent
> with the framework given in section 6 of the following
> document (although my question is more general in
> nature):
> 

> 
> http://www.ietf.org/internet-drafts/draft-many-ip-optical-fram
> ework-03.txt
> 

> 
> --Norm
> 
> --- Tom Scott  wrote:
> > Norm,
> > 
> > I don't have an answer but I'm interested in the
> > issue. Could you refer
> > me to a whitepaper, I-D, or RFC that describes
> > dynamic lightpath
> > management/control (creation, maintenance,
> > deletion)? 
> > 
> > (I assume that you mean wavelengths/lambdas or some
> > other unit of
> > dynamically assignable fiber resources. The only
> > units or regimes I'm
> > familiar with are from GMPLS: packets, time slots,
> > wavelengths, fibers.)
> > 
> > -- TT
> > 
> > 
> > -------- Original Message --------
> > Subject: Typcial Blocking Probabilites in WDM
> > networks?
> > Date: Fri, 22 Jun 2001 08:25:23 -0700 (PDT)
> > From: Norm Rumac 
> > To: mpls@UU.NET
> > 
> > Hi,
> > 
> > Does anyone know what would be an acceptable range
> > for
> > blocking probabilites withing a carrier supporting
> > dynamic lightpath establishment (via GMPLS etc.)?
> > 
> > Would it be ludicrous to assume a long-haul optical
> > carrier refusing more than say 15 percent of the
> > requests for connection establishment?
> > 
> > 
> > Thanks,
> > 
> > --Norm
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Get personalized email addresses from Yahoo! Mail
> > http://personal.mail.yahoo.com/
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
> 
> 

------_=_NextPart_001_01C0FB4A.2BE39260
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Typcial Blocking Probabilites in WDM networks?




I would think that the blocking probability depends =
on

the call pattern of the connection. I'm not so sure =
if

we can assume that the call patern is similar to =
voice.

If it is then Erlang blocking formula might be =
relevant.




Furthermore, the acceptable blocking probability is =
really

depends on the user, I think.




Cheers,




> -----Original Message-----

> From: Norm Rumac [mailto:norm_rumac@yahoo.com]

> Sent: Friday, June 22, 2001 12:47 PM

> To: Tom Scott

> Cc: mpls@UU.NET

> Subject: re: Typcial Blocking Probabilites in =
WDM networks?

> 

> 

> Tom,

> I am thinking wavelengths here.  If you =
are

> interested, I am also thinking of a model =
consistent

> with the framework given in section 6 of the =
following

> document (although my question is more general =
in

> nature):

> <br>

> <a href>

> http://www.ietf.org/internet-drafts/draft-many-ip-opti=
cal-fram

> ework-03.txt</a>

> <br>

> 

> --Norm

> 

> --- Tom Scott <telecomtom@dacor.net> =
wrote:

> > Norm,

> > 

> > I don't have an answer but I'm interested =
in the

> > issue. Could you refer

> > me to a whitepaper, I-D, or RFC that =
describes

> > dynamic lightpath

> > management/control (creation, =
maintenance,

> > deletion)? 

> > 

> > (I assume that you mean =
wavelengths/lambdas or some

> > other unit of

> > dynamically assignable fiber resources. =
The only

> > units or regimes I'm

> > familiar with are from GMPLS: packets, =
time slots,

> > wavelengths, fibers.)

> > 

> > -- TT

> > 

> > 

> > -------- Original Message --------

> > Subject: Typcial Blocking Probabilites in =
WDM

> > networks?

> > Date: Fri, 22 Jun 2001 08:25:23 -0700 =
(PDT)

> > From: Norm Rumac =
<norm_rumac@yahoo.com>

> > To: mpls@UU.NET

> > 

> > Hi,

> > 

> > Does anyone know what would be an =
acceptable range

> > for

> > blocking probabilites withing a carrier =
supporting

> > dynamic lightpath establishment (via GMPLS =
etc.)?

> > 

> > Would it be ludicrous to assume a =
long-haul optical

> > carrier refusing more than say 15 percent =
of the

> > requests for connection =
establishment?

> > 

> > 

> > Thanks,

> > 

> > --Norm

> > 

> > =
__________________________________________________

> > Do You Yahoo!?

> > Get personalized email addresses from =
Yahoo! Mail

> > http://personal.mail.yahoo.com/

> 

> 

> 

> =
__________________________________________________

> Do You Yahoo!?

> Get personalized email addresses from Yahoo! =
Mail

> http://personal.mail.yahoo.com/

> 

> 





------_=_NextPart_001_01C0FB4A.2BE39260--


From owner-mpls@UU.NET  Fri Jun 22 15:41:23 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06870
	for ; Fri, 22 Jun 2001 15:41:23 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuoc12178;
	Fri, 22 Jun 2001 19:41:18 GMT
Received: by mail-control.mail.uu.net 
	id QQkuoc18375
	for mpls-outgoing; Fri, 22 Jun 2001 19:40:44 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkuoc18367
	for ; Fri, 22 Jun 2001 19:40:36 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 QQkuoc19607
	for ; Fri, 22 Jun 2001 19:39:29 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkuoc24815
	for ; Fri, 22 Jun 2001 19:39:29 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA18200 for mpls@uu.net; Fri, 22 Jun 2001 15:39:29 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkuoc18296
	for ; Fri, 22 Jun 2001 19:38: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 QQkuoc17852
	for ; Fri, 22 Jun 2001 19:37:24 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f260.law10.hotmail.com [64.4.14.135])
	id QQkuoc23721
	for ; Fri, 22 Jun 2001 19:37:24 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 22 Jun 2001 12:37:22 -0700
Received: from 38.204.3.195 by lw10fd.law10.hotmail.msn.com with HTTP;	Fri, 22 Jun 2001 19:37:22 GMT
X-Originating-IP: [38.204.3.195]
From: "manoj juneja" 
To: ccamp@ops.ietf.org, mpls@UU.NET
Subject: Control Channel Doubt
Date: Fri, 22 Jun 2001 12:37:22 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 22 Jun 2001 19:37:22.0566 (UTC) FILETIME=[C1EAE260:01C0FB52]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi All,
          Consider the following scenario :

   If I have 2 nodes A and B connected by 3 links (viz. OC-3, OC-192 and 
OC-48). Furthermore, I have a out-of-fiber control channel running on 
ethernet between these two nodes. Here, I am considering the case of one 
control channel for all the three data plane interfaces. When an incoming 
path message is received, how to identify for which incoming data plane 
interface this is for ? or Do I have to configure three control channels 
correspondng to each of the data plane interfaces ?

Please clarify my doubt.

Regards,
manoj.



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mpls@UU.NET  Fri Jun 22 15:52:28 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07451
	for ; Fri, 22 Jun 2001 15:52:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuod04437;
	Fri, 22 Jun 2001 19:52:08 GMT
Received: by mail-control.mail.uu.net 
	id QQkuod19786
	for mpls-outgoing; Fri, 22 Jun 2001 19:51:17 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkuod19763
	for ; Fri, 22 Jun 2001 19:51:03 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 QQkuod14326
	for ; Fri, 22 Jun 2001 19:49:30 GMT
Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQkuod14140
	for ; Fri, 22 Jun 2001 19:49:29 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5MJnZx24227
	for ; Fri, 22 Jun 2001 12:49:36 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA03115 for mpls@uu.net; Fri, 22 Jun 2001 15:49:27 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkunz23605
	for ; Fri, 22 Jun 2001 18:56:56 GMT
Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkunz11965
	for ; Fri, 22 Jun 2001 18:56:09 GMT
Received: from web11602.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web11602.mail.yahoo.com [216.136.172.54])
	id QQkunz19859
	for ; Fri, 22 Jun 2001 18:56:08 GMT
Message-ID: <20010622185608.22751.qmail@web11602.mail.yahoo.com>
Received: from [38.192.40.194] by web11602.mail.yahoo.com; Fri, 22 Jun 2001 11:56:08 PDT
Date: Fri, 22 Jun 2001 11:56:08 -0700 (PDT)
From: NoZizzing OrDripping 
Subject: What to do with an illegal label stack?
To: mpls@UU.NET
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

An MPLS packet arrives with a label stack with no
bottom of stack bit set (e.g. 88 47 22 22 20 60 00 00
00 00 00 00...).

Is any behavior mandated here?  Is it OK to forward
this packet, or must it be discarded?

-Zizz

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/



From owner-mpls@UU.NET  Fri Jun 22 16:10:20 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08122
	for ; Fri, 22 Jun 2001 16:10:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuoe09869;
	Fri, 22 Jun 2001 20:10:11 GMT
Received: by mail-control.mail.uu.net 
	id QQkuoe02372
	for mpls-outgoing; Fri, 22 Jun 2001 20:09:35 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkuoe02262
	for ; Fri, 22 Jun 2001 20:09:18 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 QQkuoe07079
	for ; Fri, 22 Jun 2001 20:00:28 GMT
Received: from mail.timetra.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.timetra.com [63.104.212.2])
	id QQkuoe10544
	for ; Fri, 22 Jun 2001 20:00:27 GMT
Received: from SAURABAHPC ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 22 Jun 2001 12:55:19 -0700
Reply-To: 
From: "Saurabh Shrivastava" 
To: "'manoj juneja'" ,
        "Mpls \(E-mail\)" 
Subject: RE: Control Channel Doubt
Date: Fri, 22 Jun 2001 13:00:03 -0700
Message-ID: <00c201c0fb55$ed943940$c7bcfea9@SAURABAHPC>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-OriginalArrivalTime: 22 Jun 2001 19:55:19.0399 (UTC) FILETIME=[43C28F70:01C0FB55]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

manoj,
there is something called a LIH (logical interface
handle) in the HOP Object in the PATH message - this
shd be copied into the RESV, so that the receiver
can know on which interface it shd make reservations
even if it receives RESV on some other interface.
-saurabh

~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Saurabh Shrivastava          saurabh@timetra.com        

TiMetra Networks, Inc.       408.245.8796 (residence)
http://www.timetra.com/      650.237.5154 (office)
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~


# -----Original Message-----
# From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of manoj
# juneja
# Sent: Friday, June 22, 2001 12:37 PM
# To: ccamp@ops.ietf.org; mpls@UU.NET
# Subject: Control Channel Doubt
# 
# 
# Hi All,
#           Consider the following scenario :
# 
#    If I have 2 nodes A and B connected by 3 links (viz. OC-3, 
# OC-192 and 
# OC-48). Furthermore, I have a out-of-fiber control channel running on 
# ethernet between these two nodes. Here, I am considering the 
# case of one 
# control channel for all the three data plane interfaces. When 
# an incoming 
# path message is received, how to identify for which incoming 
# data plane 
# interface this is for ? or Do I have to configure three 
# control channels 
# correspondng to each of the data plane interfaces ?
# 
# Please clarify my doubt.
# 
# Regards,
# manoj.
# 
# 
# 
# _________________________________________________________________
# Get your FREE download of MSN Explorer at http://explorer.msn.com
# 


From owner-mpls@UU.NET  Fri Jun 22 16:39:29 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09330
	for ; Fri, 22 Jun 2001 16:39:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuog21566;
	Fri, 22 Jun 2001 20:39:20 GMT
Received: by mail-control.mail.uu.net 
	id QQkuog15126
	for mpls-outgoing; Fri, 22 Jun 2001 20:38:47 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkuog15105
	for ; Fri, 22 Jun 2001 20:38:37 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkuog27207
	for ; Fri, 22 Jun 2001 20:35:59 GMT
Received: from auemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: auemail1.lucent.com [192.11.223.161])
	id QQkuog21367
	for ; Fri, 22 Jun 2001 20:35:59 GMT
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5MKZwf00493
	for ; Fri, 22 Jun 2001 16:35:58 -0400 (EDT)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5MKZvQ00481
	for ; Fri, 22 Jun 2001 16:35:58 -0400 (EDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 22 Jun 2001 22:35:56 +0200
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0CB6127D@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" 
To: mpls-wg , manoj juneja 
Subject: RE: Control Channel Doubt
Date: Fri, 22 Jun 2001 22:35:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Please DO NOT cross post to multiple mailing lists with largely
overlapping audiences. Choose one list and discuss it there.

Thanks, Bert


> ----------
> From: 	manoj juneja[SMTP:manojkumarjuneja@hotmail.com]
> Sent: 	Friday, June 22, 2001 9:37 PM
> To: 	ccamp@ops.ietf.org; mpls@UU.NET
> Subject: 	Control Channel Doubt
> 
> Hi All,
>           Consider the following scenario :
> 
>    If I have 2 nodes A and B connected by 3 links (viz. OC-3, OC-192 and 
> OC-48). Furthermore, I have a out-of-fiber control channel running on 
> ethernet between these two nodes. Here, I am considering the case of one 
> control channel for all the three data plane interfaces. When an incoming 
> path message is received, how to identify for which incoming data plane 
> interface this is for ? or Do I have to configure three control channels 
> correspondng to each of the data plane interfaces ?
> 
> Please clarify my doubt.
> 
> Regards,
> manoj.
> 
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> 


From owner-mpls@UU.NET  Fri Jun 22 17:09:02 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10386
	for ; Fri, 22 Jun 2001 17:09:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuoi21085;
	Fri, 22 Jun 2001 21:01:39 GMT
Received: by mail-control.mail.uu.net 
	id QQkuoi19847
	for mpls-outgoing; Fri, 22 Jun 2001 21:01:03 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkuoi19686
	for ; Fri, 22 Jun 2001 21:00:51 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 QQkuoh04690
	for ; Fri, 22 Jun 2001 20:57:35 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkuoh18211
	for ; Fri, 22 Jun 2001 20:57:34 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA22850 for mpls@uu.net; Fri, 22 Jun 2001 16:57:34 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkuoh16721
	for ; Fri, 22 Jun 2001 20:53:07 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 QQkuoh10545
	for ; Fri, 22 Jun 2001 20:51:32 GMT
Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQkuoh06859
	for ; Fri, 22 Jun 2001 20:51:31 GMT
Received: from mira1.cisco.com (mira1.cisco.com [171.71.208.193])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5MKpcx00073
	for ; Fri, 22 Jun 2001 13:51:38 -0700 (PDT)
Received: from cisco.com (skatukam-u5.cisco.com [171.71.213.88])
	by mira1.cisco.com (Mirapoint)
	with ESMTP id AAP00137;
	Fri, 22 Jun 2001 13:51:30 -0700 (PDT)
Message-ID: <3B33AFD2.78A1084C@cisco.com>
Date: Fri, 22 Jun 2001 13:51:30 -0700
From: Suresh Katukam 
Organization: Cisco Systems
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mpls-wg 
Subject: Re: Control Channel Doubt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit


Saurabh,

Consider two nodes: A ---- B (There are 3 links as
Manoj pointed out).

1. How does A indicate to B on which link the node
B should make reservation on?

Your message to Manoj only indicates that B should copy
the LIH value from PATH to RESV message. This does not
provide information to B which link to choose from.
It works fine for IF/IB case but not for OF/OB.

For this, LMP has been proposed to discover each other's
port ids. For OIF point of view, LIH value in the HOP
object of the PATH message should indicate A's local
port ID on which A wants to allocate resources on.
Since B knows using LMP or manual configuration,
A's internal port id, it can figure out what link
that it needs to make reservations on.

There are other proposals (new HOP object) that can
be used by node A to indicate to B about the link that
it wants to make reservations on.

Hope this clarifies,
-- Suresh Katukam


Saurabh Shrivastava wrote:
> 
> manoj,
> there is something called a LIH (logical interface
> handle) in the HOP Object in the PATH message - this
> shd be copied into the RESV, so that the receiver
> can know on which interface it shd make reservations
> even if it receives RESV on some other interface.
> -saurabh
> 
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> Saurabh Shrivastava          saurabh@timetra.com
> 
> TiMetra Networks, Inc.       408.245.8796 (residence)
> http://www.timetra.com/      650.237.5154 (office)
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> 
> # -----Original Message-----
> # From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of manoj
> # juneja
> # Sent: Friday, June 22, 2001 12:37 PM
> # To: ccamp@ops.ietf.org; mpls@UU.NET
> # Subject: Control Channel Doubt
> #
> #
> # Hi All,
> #           Consider the following scenario :
> #
> #    If I have 2 nodes A and B connected by 3 links (viz. OC-3,
> # OC-192 and
> # OC-48). Furthermore, I have a out-of-fiber control channel running on
> # ethernet between these two nodes. Here, I am considering the
> # case of one
> # control channel for all the three data plane interfaces. When
> # an incoming
> # path message is received, how to identify for which incoming
> # data plane
> # interface this is for ? or Do I have to configure three
> # control channels
> # correspondng to each of the data plane interfaces ?
> #
> # Please clarify my doubt.
> #
> # Regards,
> # manoj.
> #
> #
> #
> # _________________________________________________________________
> # Get your FREE download of MSN Explorer at http://explorer.msn.com
> #



From owner-mpls@UU.NET  Fri Jun 22 18:18:33 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13422
	for ; Fri, 22 Jun 2001 18:18:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuon25195;
	Fri, 22 Jun 2001 22:18:27 GMT
Received: by mail-control.mail.uu.net 
	id QQkuon03565
	for mpls-outgoing; Fri, 22 Jun 2001 22:17:55 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkuon03513
	for ; Fri, 22 Jun 2001 22:17:37 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 QQkuon27275
	for ; Fri, 22 Jun 2001 22:16:55 GMT
Received: from calliope1.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10])
	id QQkuon23577
	for ; Fri, 22 Jun 2001 22:16:55 GMT
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id WAA00291;
	Fri, 22 Jun 2001 22:16:48 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 22 Jun 2001 22:16:48 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 22 Jun 2001 15:16:46 -0700
Message-ID: 
From: "Karmakar, Soumen" 
To: "'Suresh Katukam'" , mpls-wg 
Subject: RE: Control Channel Doubt
Date: Fri, 22 Jun 2001 15:16:44 -0700
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

IMHO , each of the supported link will have an interface id. For out of
fiber IPCC the nodes may exchange LMP messages : BeginVerify, BeginVerifyAck
and then  Test messages over the infiber link (each link) . The
TestStatusSuccess message informs node A of its own and remote interface id.
Hence node A will have the mapping of the local and remote interface ID (of
node B). This information has to be manually configured for non automated
neighbour discovery.
Now when the PATH message is initiated , the RSVP Hop object will include
the LIH (the interface id or the port ID , which can be IP address for
numberd link or 32 bit identifier for unnumbered link) and on which the
connection is established 
As pointed out earlier , the node receiving the LIH in PATH message will
record the LIH and return it in the RESV message.
The second question , one IPCC can be associated with multiple component
links , hence configuring three control channels is not necessary. Of course
more than one can be done , in that case the RSVP Hop object will contain
the correct IP address of the control channel and the LIH.

Rgds,
Soumen


-----Original Message-----
From: Suresh Katukam [mailto:skatukam@cisco.com]
Sent: Friday, June 22, 2001 1:52 PM
To: mpls-wg
Subject: Re: Control Channel Doubt



Saurabh,

Consider two nodes: A ---- B (There are 3 links as
Manoj pointed out).

1. How does A indicate to B on which link the node
B should make reservation on?

Your message to Manoj only indicates that B should copy
the LIH value from PATH to RESV message. This does not
provide information to B which link to choose from.
It works fine for IF/IB case but not for OF/OB.

For this, LMP has been proposed to discover each other's
port ids. For OIF point of view, LIH value in the HOP
object of the PATH message should indicate A's local
port ID on which A wants to allocate resources on.
Since B knows using LMP or manual configuration,
A's internal port id, it can figure out what link
that it needs to make reservations on.

There are other proposals (new HOP object) that can
be used by node A to indicate to B about the link that
it wants to make reservations on.

Hope this clarifies,
-- Suresh Katukam


Saurabh Shrivastava wrote:
> 
> manoj,
> there is something called a LIH (logical interface
> handle) in the HOP Object in the PATH message - this
> shd be copied into the RESV, so that the receiver
> can know on which interface it shd make reservations
> even if it receives RESV on some other interface.
> -saurabh
> 
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> Saurabh Shrivastava          saurabh@timetra.com
> 
> TiMetra Networks, Inc.       408.245.8796 (residence)
> http://www.timetra.com/      650.237.5154 (office)
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> 
> # -----Original Message-----
> # From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of manoj
> # juneja
> # Sent: Friday, June 22, 2001 12:37 PM
> # To: ccamp@ops.ietf.org; mpls@UU.NET
> # Subject: Control Channel Doubt
> #
> #
> # Hi All,
> #           Consider the following scenario :
> #
> #    If I have 2 nodes A and B connected by 3 links (viz. OC-3,
> # OC-192 and
> # OC-48). Furthermore, I have a out-of-fiber control channel running on
> # ethernet between these two nodes. Here, I am considering the
> # case of one
> # control channel for all the three data plane interfaces. When
> # an incoming
> # path message is received, how to identify for which incoming
> # data plane
> # interface this is for ? or Do I have to configure three
> # control channels
> # correspondng to each of the data plane interfaces ?
> #
> # Please clarify my doubt.
> #
> # Regards,
> # manoj.
> #
> #
> #
> # _________________________________________________________________
> # Get your FREE download of MSN Explorer at http://explorer.msn.com
> #




From owner-mpls@UU.NET  Sat Jun 23 02:42:28 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05999
	for ; Sat, 23 Jun 2001 02:42:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkupu07612;
	Sat, 23 Jun 2001 06:41:50 GMT
Received: by mail-control.mail.uu.net 
	id QQkupu23473
	for mpls-outgoing; Sat, 23 Jun 2001 06:41:17 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkupu23402
	for ; Sat, 23 Jun 2001 06:40: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 QQkupu00997
	for ; Sat, 23 Jun 2001 06:40:26 GMT
Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQkupu27513
	for ; Sat, 23 Jun 2001 06:40:25 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id  for ;
 Sat, 23 Jun 2001 12:17:57 +0530
Received: from abdulmk (abdulmk.future.futsoft.com [10.8.7.11])
	by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f5N6a4Q04673
	for ; Sat, 23 Jun 2001 12:07:19 +0530
Message-Id: <004d01c0fbae$889c4d80$0b07080a@future.futsoft.com>
Reply-To: "Abdul Malick" 
From: "Abdul Malick" 
To: 
Subject: Doubts regarding VR based VPNs
Date: Sat, 23 Jun 2001 12:03:04 +0530
Organization: Future Software Ltd.,
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_004A_01C0FBDC.75837420"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_004A_01C0FBDC.75837420
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello All,

After reading draft-ouldbrahim-vpn-vr-03.txt and other materials on VR =
based NBVPN  i get the following doubts:

1. Is it right to say that if we want to use piggy-backing for VPN =
information discovery, the backbone VR configuration is a must (because =
PEs have to be contacted by Public address which need not be visible to =
the VRs).

2. Is it right to say that tunnels (MPLS, IPSEC,etc) could be used only =
in the backbone VR based configuration because otherwise the VRs have to =
be aware of the addresses and routes for the PEs (public)?

3. Will the VRs send labelled packets to the backbone VR? If so will =
there be any signaling (may be some registration) between the VRs and =
backbone VR?

4. Is it right to say that one VR can participate in only one VPN? (i =
did not find details on multiple VPN support per VR)


Can somebody clear my doubts?
Please pardon me if these questions have already been discussed.

Thanks in advance

Malick

------=_NextPart_000_004A_01C0FBDC.75837420
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hello All,


 


After reading =
draft-ouldbrahim-vpn-vr-03.txt and=20
other materials on VR based NBVPN  i get the following =
doubts:


 


1. Is it right to say that if we want =
to use=20
piggy-backing for VPN information discovery, the backbone VR =
configuration is a=20
must (because PEs have to be contacted by Public address which need =
not be=20
visible to the VRs).


 


2. Is it right to say that tunnels =
(MPLS,=20
IPSEC,etc) could be used only in the backbone VR based configuration =
because=20
otherwise the VRs have to be aware of the addresses and =
routes for the=20
PEs (public)?


 


3. Will the VRs send labelled packets =
to the=20
backbone VR? If so will there be any signaling (may be some =
registration)=20
between the VRs and backbone VR?


 


4. =
Is it right=20
to say that one VR can participate in only one VPN? (i did not find=20
details on multiple VPN support per VR)


 


 


Can somebody clear my =
doubts?


Please pardon me if these questions =
have already=20
been discussed.


 


Thanks in advance


 


Malick


------=_NextPart_000_004A_01C0FBDC.75837420--



From owner-mpls@UU.NET  Sat Jun 23 13:32:31 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13820
	for ; Sat, 23 Jun 2001 13:32:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkurm22781;
	Sat, 23 Jun 2001 17:31:33 GMT
Received: by mail-control.mail.uu.net 
	id QQkurm17472
	for mpls-outgoing; Sat, 23 Jun 2001 17:30:59 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkurm17457
	for ; Sat, 23 Jun 2001 17:30:41 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 QQkurm17244
	for ; Sat, 23 Jun 2001 17:30:07 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkurm11652
	for ; Sat, 23 Jun 2001 17:30:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA21376 for mpls@uu.net; Sat, 23 Jun 2001 13:30:05 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkurl17386
	for ; Sat, 23 Jun 2001 17:29: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 QQkurl18213
	for ; Sat, 23 Jun 2001 17:26:05 GMT
Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10])
	id QQkurl08264
	for ; Sat, 23 Jun 2001 17:26:04 GMT
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5NHQAN16053;
	Sat, 23 Jun 2001 10:26:10 -0700 (PDT)
Received: from cisco.com (ams-vpdn-client-369.cisco.com [144.254.47.117])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with ESMTP id AFY00442 (AUTH rraszuk);
	Sat, 23 Jun 2001 10:26:00 -0700 (PDT)
Message-ID: <3B34D0B8.7D8B88F5@cisco.com>
Date: Sat, 23 Jun 2001 10:24:08 -0700
From: Robert Raszuk 
Reply-To: raszuk@cisco.com
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Maksymilian Milkowski 
CC: mpls@UU.NET
Subject: Re: intserv vs diffserv
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Maks,

> I would like to ask about differences in IP QoS models implemented in
> MPLS: do they only differ in granularity? When it is recommended to use
> the former and when the latter? Does the type of hardware (ATM-LSRs, IP
> routers) have any influence on this choice?

I am not aware that anybody is using intserv in the SP/ISP type of
network. It simply does not scale.

> And one question regarding diffserv only: does the setting up of
> packet's DSCP value in domain boundary mean that this packet will be
> treated in the same way in all nodes of the domain?

It depends of the configuration of each node and does not have anything
to do specifically with MPLS. MPLS header is just a vehicle to carry the
EXP bits. In DS-TE the middle nodes diffserv scheduling configuration
can be automated via RSVP so you can assume that for such a flows the
answer would be yes.

R.

> Maksymilian Milkowski wrote:
> 
> Hi,
> I would like to ask about differences in IP QoS models implemented in
> MPLS: do they only differ in granularity? When it is recommended to use
> the former and when the latter? Does the type of hardware (ATM-LSRs, IP
> routers) have any influence on this choice?
> And one question regarding diffserv only: does the setting up of
> packet's DSCP value in domain boundary mean that this packet will be
> treated in the same way in all nodes of the domain?
> 
> Thanks in advance,
> 
> Maks Milkowski



From owner-mpls@UU.NET  Sat Jun 23 14:51:51 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15289
	for ; Sat, 23 Jun 2001 14:51:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkurr07975;
	Sat, 23 Jun 2001 18:51:19 GMT
Received: by mail-control.mail.uu.net 
	id QQkurr11494
	for mpls-outgoing; Sat, 23 Jun 2001 18:50:48 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkurr11483
	for ; Sat, 23 Jun 2001 18:50:28 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 QQkurr15259
	for ; Sat, 23 Jun 2001 18:46:33 GMT
Received: from t-mta3.odn.ne.jp by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mfep3.odn.ne.jp [143.90.131.181])
	id QQkurr01916
	for ; Sat, 23 Jun 2001 18:46:28 GMT
Received: from YONEDA ([204.248.134.190]) by t-mta3.odn.ne.jp with SMTP
          id <20010623184611200.SZMX.23490.t-mta3.odn.ne.jp@mta3.odn.ne.jp>;
          Sun, 24 Jun 2001 03:46:11 +0900
From: "Susumu Yoneda" 
To: "Stephen Suryaputra" ,
        "Norm Rumac" ,
        "Tom Scott" 
Cc: 
Subject: RE: Typcial Blocking Probabilites in WDM networks?
Date: Sun, 24 Jun 2001 03:51:22 +0900
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0000_01C0FC60.EF681690"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <8B888AAAAB0FD31189590008C7918443074E29ED@zbl6c002.corpeast.baynetworks.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C0FC60.EF681690
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Typcial Blocking Probabilites in WDM networks?Hi,

At an initial stage of Lambda service by using OOO switch, only "busy" case
can be applied. Then, "call waiting" type of message would be considered in
the signalling.
  -----Original Message-----
  From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Stephen
Suryaputra
  Sent: Saturday, June 23, 2001 3:36 AM
  To: Norm Rumac; Tom Scott
  Cc: mpls@UU.NET
  Subject: RE: Typcial Blocking Probabilites in WDM networks?


  I would think that the blocking probability depends on
  the call pattern of the connection. I'm not so sure if
  we can assume that the call patern is similar to voice.
  If it is then Erlang blocking formula might be relevant.

  Furthermore, the acceptable blocking probability is really
  depends on the user, I think.

  Cheers,

  > -----Original Message-----
  > From: Norm Rumac [mailto:norm_rumac@yahoo.com]
  > Sent: Friday, June 22, 2001 12:47 PM
  > To: Tom Scott
  > Cc: mpls@UU.NET
  > Subject: re: Typcial Blocking Probabilites in WDM networks?
  >
  >
  > Tom,
  > I am thinking wavelengths here.  If you are
  > interested, I am also thinking of a model consistent
  > with the framework given in section 6 of the following
  > document (although my question is more general in
  > nature):
  > 

  > 
  > http://www.ietf.org/internet-drafts/draft-many-ip-optical-fram
  > ework-03.txt
  > 

  >
  > --Norm
  >
  > --- Tom Scott  wrote:
  > > Norm,
  > >
  > > I don't have an answer but I'm interested in the
  > > issue. Could you refer
  > > me to a whitepaper, I-D, or RFC that describes
  > > dynamic lightpath
  > > management/control (creation, maintenance,
  > > deletion)?
  > >
  > > (I assume that you mean wavelengths/lambdas or some
  > > other unit of
  > > dynamically assignable fiber resources. The only
  > > units or regimes I'm
  > > familiar with are from GMPLS: packets, time slots,
  > > wavelengths, fibers.)
  > >
  > > -- TT
  > >
  > >
  > > -------- Original Message --------
  > > Subject: Typcial Blocking Probabilites in WDM
  > > networks?
  > > Date: Fri, 22 Jun 2001 08:25:23 -0700 (PDT)
  > > From: Norm Rumac 
  > > To: mpls@UU.NET
  > >
  > > Hi,
  > >
  > > Does anyone know what would be an acceptable range
  > > for
  > > blocking probabilites withing a carrier supporting
  > > dynamic lightpath establishment (via GMPLS etc.)?
  > >
  > > Would it be ludicrous to assume a long-haul optical
  > > carrier refusing more than say 15 percent of the
  > > requests for connection establishment?
  > >
  > >
  > > Thanks,
  > >
  > > --Norm
  > >
  > > __________________________________________________
  > > Do You Yahoo!?
  > > Get personalized email addresses from Yahoo! Mail
  > > http://personal.mail.yahoo.com/
  >
  >
  >
  > __________________________________________________
  > Do You Yahoo!?
  > Get personalized email addresses from Yahoo! Mail
  > http://personal.mail.yahoo.com/
  >
  >


------=_NextPart_000_0000_01C0FC60.EF681690
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: Typcial Blocking Probabilites in WDM =
networks?




Hi,


 


At an initial stage of Lambda service by using =
OOO switch, only=20
"busy" case can be applied. Then, "call waiting" type of message would =
be=20
considered in the signalling.



  
-----Original Message-----
From: owner-mpls@UU.NET=20
  [mailto:owner-mpls@UU.NET]On Behalf Of Stephen=20
  Suryaputra
Sent: Saturday, June 23, 2001 3:36 =
AM
To: Norm=20
  Rumac; Tom Scott
Cc: mpls@UU.NET
Subject: RE: =
Typcial=20
  Blocking Probabilites in WDM networks?


  
I would think that the blocking probability depends =
on=20
  
the call pattern of the connection. I'm not so sure =
if=20
  
we can assume that the call patern is similar to=20
  voice. 
If it is then Erlang blocking formula =
might be=20
  relevant. 

  
Furthermore, the acceptable blocking probability is=20
  really 
depends on the user, I think. =


  
Cheers, 

  
> -----Original Message----- 
>=20
  From: Norm Rumac [mailto:norm_rumac@yahoo.com]=20
  
> Sent: Friday, June 22, 2001 12:47 PM =

> To: Tom Scott 
> Cc: =
mpls@UU.NET=20
  
> Subject: re: Typcial Blocking Probabilites in =
WDM=20
  networks? 
> 
>=20
  
> Tom, 
> I =
am thinking=20
  wavelengths here.  If you are 
> =
interested, I=20
  am also thinking of a model consistent 
> =
with the=20
  framework given in section 6 of the following 
>=20
  document (although my question is more general in 
>=20
  nature): 
> <br> 
>=20
  <a href> 
> h=
ttp://www.ietf.org/internet-drafts/draft-many-ip-optical-fram =

  
> ework-03.txt</a> 
>=20
  <br> 
> 
>=20
  --Norm 
> 
> =
--- Tom Scott=20
  <telecomtom@dacor.net> wrote: 
> =
>=20
  Norm, 
> > 
> > I=20
  don't have an answer but I'm interested in the 
>=20
  > issue. Could you refer 
> > me to =
a=20
  whitepaper, I-D, or RFC that describes 
> =
>=20
  dynamic lightpath 
> > =
management/control=20
  (creation, maintenance, 
> > deletion)? =

  
> > 
> =
> (I assume=20
  that you mean wavelengths/lambdas or some 
> >=20
  other unit of 
> > dynamically =
assignable fiber=20
  resources. The only 
> > units or =
regimes=20
  I'm 
> > familiar with are from GMPLS: =
packets,=20
  time slots, 
> > wavelengths, =
fibers.)=20
  
> > 
> > -- =
TT=20
  
> > 
> > =

> > -------- Original Message -------- 
> > Subject: Typcial Blocking Probabilites in =
WDM=20
  
> > networks? 
> =
> Date:=20
  Fri, 22 Jun 2001 08:25:23 -0700 (PDT) 
> =
> From:=20
  Norm Rumac <norm_rumac@yahoo.com> 
> =
> To:=20
  mpls@UU.NET 
> > 
>=20
  > Hi, 
> > 
> >=20
  Does anyone know what would be an acceptable range 
> > for 
> > blocking =
probabilites=20
  withing a carrier supporting 
> > =
dynamic=20
  lightpath establishment (via GMPLS etc.)? 
> >=20
  
> > Would it be ludicrous to assume a =
long-haul=20
  optical 
> > carrier refusing more than =
say 15=20
  percent of the 
> > requests for =
connection=20
  establishment? 
> > 
>=20
  > 
> > Thanks, 
>=20
  > 
> > --Norm 
>=20
  > 
> >=20
  __________________________________________________ 
> > Do You Yahoo!? 
> > =
Get=20
  personalized email addresses from Yahoo! Mail 
>=20
  > http://personal.mail.yahoo.com/<=
/A>=20
  
> 
> =

> 
>=20
  __________________________________________________ 
> Do You Yahoo!? 
> Get =
personalized email=20
  addresses from Yahoo! Mail 
> http://personal.mail.yahoo.com/<=
/A>=20
  
> 
>=20



------=_NextPart_000_0000_01C0FC60.EF681690--




From owner-mpls@UU.NET  Sat Jun 23 21:40:34 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21296
	for ; Sat, 23 Jun 2001 21:40:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuss05635;
	Sun, 24 Jun 2001 01:39:18 GMT
Received: by mail-control.mail.uu.net 
	id QQkuss22913
	for mpls-outgoing; Sun, 24 Jun 2001 01:38:46 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkuss22902
	for ; Sun, 24 Jun 2001 01:38:31 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 QQkuss13445
	for ; Sun, 24 Jun 2001 01:36:10 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkuss24377
	for ; Sun, 24 Jun 2001 01:36:10 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA02364 for mpls@uu.net; Sat, 23 Jun 2001 21:36:09 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkuss22648
	for ; Sun, 24 Jun 2001 01:35:42 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 QQkuss11584
	for ; Sun, 24 Jun 2001 01:33:56 GMT
Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQkuss24015
	for ; Sun, 24 Jun 2001 01:33:55 GMT
Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5O1Xwh29582;
	Sat, 23 Jun 2001 18:33:58 -0700 (PDT)
Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id VAA03131; Sat, 23 Jun 2001 21:33:52 -0400 (EDT)
Message-Id: <200106240133.VAA03131@rhthomas-sun2.cisco.com>
X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs
To: nagendras@netbrahma.com
cc: naderv@msn.com, suchauhan@hss.hns.com, mpls@UU.NET
Subject: Re: Error in RFC 3036?? 
In-reply-to: Your message of "Thu, 21 Jun 2001 17:03:05 PDT."
             <45e501c0faae$b6674a90$0e03ca0a@cp98suwbm02> 
Date: Sat, 23 Jun 2001 21:33:51 -0400
From: Bob Thomas 
Sender: owner-mpls@UU.NET
Precedence: bulk

Tomar,

> Bob!
>      I am sorry if I did'nt put it correctly, but by saying that the
> Loop Detected Notification might in turn Loop, I meant that since a loop
> was detected on the label request received, there is a very  high
> possibility that the return path (from the receiver of the label request

I think the probability is quite low since unless the LDP session is a
targeted session the sender and receiver of the Label Request message
are directly connected.

Bob


> to the sender of the Label request) for the notification message might as
> well loop so its better to silently discard it.
> 
> Is'nt it because of this Bob ?
> 
> regards
> tomar
> 
> 
> On Mon, 11 Jun 2001, Bob Thomas wrote:
> 
> > Tomar,
> >
> > > If the node detects a loop in the label request message, the  its wise not
> > > to send the loop detected notification, because that might in turn loop
> >
> > Note that the Loop Detected Notification is not propagated by the
> > receiver, and therefore will not loop.
> >
> > Bob
> >
> >
> > > and make the network conditions worse. In the LRq.2 case the loop is not
> > > detected in the label request message so we are sure that the return path
> > > for the notification message has no loop, so it is safe to send a
> > > notification in that case.
> > >
> > > --tomar
> > >
> > > On Mon, 11 Jun 2001 suchauhan@hss.hns.com wrote:
> > >
> > > >
> > > >
> > > > yup sorry! LRq.4 it is. typo ;o)
> > > >
> > > >
> > > >
> > > >
> > > > "zze-PELLE Thierry StagiaireFTRD/DAC/ISS"  on
> > > > 06/11/2001 03:27:43 PM
> > > >
> > > > To:   Sumit Chauhan/HSS@HSS, mpls@UU.NET
> > > > cc:
> > > >
> > > > Subject:  RE: Error in RFC 3036??
> > > >
> > > >
> > > >
> > > >
> > > > > IMHO, should it not be
> > > > >      If Loop Detected , got to LRq.5
> > > >
> > > > LRq.4 and not LRq.5 I think....
> > > >
> > > >
> > > >
> > >
> > > --
> > >
> > >
> > > ------------------------------------------------------------------------------
> > >  Nagendra Singh Tomar
> > >
> > >  Residence:
> > >  369 KHB Colony
> > >  5th Block Koramangala
> > >  Bangalore 95
> > >  INDIA
> > >  Phone : 5524839
> > >  email : nagendras@netbrahma.com
> > >
> > >
> > > "Sometimes quantity becomes quality"
> > >                             --Gary Kasparov,
> > >  When he played against Deep Blue. He said this after looking at a
> > >  computer which found a forced mate in 249 in an endgame, after calculating
> > >  all the possible moves with only 5 pieces left on the board.
> > > ------------------------------------------------------------------------------
> > >
> >
> 
> --
> 
> 
> ------------------------------------------------------------------------------
>  Nagendra Singh Tomar
> 
>  Residence:
>  369 KHB Colony
>  5th Block Koramangala
>  Bangalore 95
>  INDIA
>  Phone : 5524839
>  email : nagendras@netbrahma.com
> 
> 
> "Sometimes quantity becomes quality"
>                             --Gary Kasparov,
>  When he played against Deep Blue. He said this after looking at a
>  computer which found a forced mate in 249 in an endgame, after calculating
>  all the possible moves with only 5 pieces left on the board.
> ------------------------------------------------------------------------------
> 



From owner-mpls@UU.NET  Sun Jun 24 05:34:14 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08908
	for ; Sun, 24 Jun 2001 05:34:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuty21135;
	Sun, 24 Jun 2001 09:33:05 GMT
Received: by mail-control.mail.uu.net 
	id QQkuty06922
	for mpls-outgoing; Sun, 24 Jun 2001 09:32:33 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkuty06913
	for ; Sun, 24 Jun 2001 09:32: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 QQkuty20639
	for ; Sun, 24 Jun 2001 09:32:05 GMT
From: neil.2.harrison@bt.com
Received: from gollum.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41])
	id QQkuty29845
	for ; Sun, 24 Jun 2001 09:32:04 GMT
Received: from cclmsent02.lon.bt.com by gollum (local) with ESMTP;
          Sun, 24 Jun 2001 10:27:55 +0100
Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) 
          id ; Sun, 24 Jun 2001 10:27:46 +0100
Message-ID: 
To: raszuk@cisco.com, maks@ds.pg.gda.pl
Cc: mpls@UU.NET
Subject: RE: intserv vs diffserv
Date: Sun, 24 Jun 2001 10:27:40 +0100
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Robert Raszuk wrote 23 June 2001 18:24


> > And one question regarding diffserv only: does the setting up of
> > packet's DSCP value in domain boundary mean that this packet will be
> > treated in the same way in all nodes of the domain?
> 
> It depends of the configuration of each node and does not 
> have anything
> to do specifically with MPLS. MPLS header is just a vehicle 
> to carry the
> EXP bits. In DS-TE the middle nodes diffserv scheduling configuration
> can be automated via RSVP so you can assume that for such a flows the
> answer would be yes.
> 
> R.
NH=> This is true for the up-state QoS scheduling behaviour.  However,
upstate QoS sheduling and the *importance* of a given application's traffic
are not related.  That is, whether a voice connection is mission critical
(ie must survive) or not (ie can be dropped under failure) cannot be
inferred from the DS EF codepoint alone.  One can also imagine corresponding
cases for the AF classes.

This has some important implications for private VPNs vs generic public
services.  In the former case if DS classes are merged across VPN
populations (eg by using vanilla LDP as the server layer of LSPs to say
client BGP4 distributed LSPs in the RFC2547 model) it is not clear to me how
one can offer solid, and differentiable, survivability SLAs to a given VPN
topology.

One approach may be based on a concept of 'effective BW per LSP' that
defines the VPN topology that is required, and the survivability is a
function of the LSPs effective BW and not on a per pkt DS class basis.  Here
DS scheduling in now only relative to the VPN LSP traffic and not the
general population traffic, and the key metric that the operator is
concerned with is overall MPLS layer VPN LSP topology survival (relative to
other private VPNs and the general public service traffic....again in its
own, but this time 'operator owned', internal VPN). 

An alternative view could be to take each of the DS classes and associate it
with some survivability index.  For illustrative purposes only, let's say
there are N DS classes and M survivability indices.  One might now need to
create NxM LSPs across the network (assuming each N QoS class could be
associated with any of the M survivability indices) and allocate the traffic
at ingress accordingly.  

neil


From owner-mpls@UU.NET  Mon Jun 25 07:03:37 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10196
	for ; Mon, 25 Jun 2001 07:03:36 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuxw03137;
	Mon, 25 Jun 2001 11:03:19 GMT
Received: by mail-control.mail.uu.net 
	id QQkuxw17058
	for mpls-outgoing; Mon, 25 Jun 2001 11:02:46 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkuxw17017
	for ; Mon, 25 Jun 2001 11:02: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 QQkuxw29779
	for ; Mon, 25 Jun 2001 11:02:15 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkuxw09745
	for ; Mon, 25 Jun 2001 11:02:15 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA12711 for mpls@uu.net; Mon, 25 Jun 2001 07:02:15 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkuxw12294
	for ; Mon, 25 Jun 2001 11:01:41 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 QQkuxw05916
	for ; Mon, 25 Jun 2001 11:01:01 GMT
Received: from anti_vir1.rad.co.il by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: radmail.rad.co.il [207.232.32.10])
	id QQkuxw02554
	for ; Mon, 25 Jun 2001 11:01:00 GMT
Received: from anti_vir1.rad.co.il (localhost [127.0.0.1])
	by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5PC1OM05016
	for ; Mon, 25 Jun 2001 14:01:24 +0200 (IST)
Received: from radmail.rad.co.il (radmail [192.114.24.30])
	by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5PC1Mr05008;
	Mon, 25 Jun 2001 14:01:22 +0200 (IST)
Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il
          (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35)
          with ESMTP id il; Mon, 25 Jun 2001 14:02:15 +0300
Received: by TLV1 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 25 Jun 2001 13:59:41 +0200
Message-ID: 
From: Sasha Vainshtein 
To: "'murali tallapudi'" 
Cc: "'mpls@uu.net'" 
Subject: RE: doubt on diff-serv
Date: Mon, 25 Jun 2001 13:59:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0FD6E.4E5DBD90"
Sender: owner-mpls@UU.NET
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C0FD6E.4E5DBD90
Content-Type: text/plain;
	charset="iso-8859-1"

Murali,
This is a good and valid question. IMHO the answer is like following:
1. Router B operates in accordance with preconfigured EXP-->PHB mappings 
2. Preconfigured mappings in any DiffServ-aware LSR MUST include 
    mapping of  000 (EXP) --> Default Forwarding PHB. May be this should
    be explicitly added to the draft
3. Router A (which is not Diff-Serv-aware) MUST set EXP bits to 000.
This would result in consistent LSP behavior.
------------------------------------------
With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com  
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
 


> -----Original Message-----
> From: murali tallapudi [mailto:tallapudi@mail.com]
> Sent: Monday, June 25, 2001 7:10 AM
> To: Sasha@AXERRA.com
> Subject: doubt on diff-serv
> 
> 
>  hi,
> 
>    i got one doubt on diff-serv. can u see the attachment  
> and clear my doubt?..
> 
> 
>  regards
> 
>  murali
> -- 
> 
> _______________________________________________
> FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
> 
> FREE PC-to-Phone calls with Net2Phone
> http://www.net2phone.com/cgi-bin/link.cgi?121
> 
> 
> 
> 
> 
> -- 
> 
> _______________________________________________
> FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
> 
> FREE PC-to-Phone calls with Net2Phone
> http://www.net2phone.com/cgi-bin/link.cgi?121
> 
> 
> 
> 
> 
> 


------_=_NextPart_000_01C0FD6E.4E5DBD90
Content-Type: application/msword;
	name="diff_Q.doc"
Content-Disposition: attachment;
	filename="diff_Q.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJAAAAAAAAAAA
EAAAJgAAAAEAAAD+////AAAAACMAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAWyAJBAAA8BK/AAAAAAAAEAAAAAAABAAA2AYAAA4AYmpiauIA4gAAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAIhIAAIBqAQCAagEAcAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZwAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKgAAAAAAAAAqAAAAKgA
AAAAAAAAqAAAAAAAAACIAQAAAAAAAIgBAAAAAAAAiAEAABQAAAAAAAAAAAAAAJwBAAAAAAAAuAQA
AAAAAAC4BAAAAAAAALgEAAAAAAAAuAQAAAwAAADEBAAAFAAAAJwBAAAAAAAAug0AALYAAADkBAAA
AAAAAOQEAAAAAAAA5AQAAAAAAADkBAAAAAAAAOQEAAAAAAAAXwsAAAAAAABfCwAAAAAAAF8LAAAA
AAAAOQ0AAAIAAAA7DQAAAAAAADsNAAAAAAAAOw0AAAAAAAA7DQAAAAAAADsNAAAAAAAAOw0AACQA
AABwDgAAIAIAAJAQAABmAAAAXw0AABUAAAAAAAAAAAAAAAAAAAAAAAAAiAEAAAAAAABfCwAAAAAA
AAAAAAAAAAAAAAAAAAAAAADVCQAAigEAAF8LAAAAAAAAXwsAAAAAAABfCwAAAAAAAF8NAAAAAAAA
IQwAAAAAAACoAAAAAAAAAKgAAAAAAAAA5AQAAAAAAAAAAAAAAAAAAOQEAADxBAAAdA0AABYAAAAh
DAAAAAAAACEMAAAAAAAAIQwAAAAAAABfCwAAKAAAAKgAAACgAAAA5AQAAAAAAACIAQAAAAAAAOQE
AAAAAAAAOQ0AAAAAAAAAAAAAAAAAACEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAXwsAAAAAAAA5DQAAAAAAACEMAAAYAQAAIQwAAAAAAAAAAAAA
AAAAADkNAAAAAAAASAEAAEAAAACIAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOQ0AAAAAAADkBAAAAAAAANgEAAAMAAAAYIqi7QP7
wAGcAQAAHAMAALgEAAAAAAAAhwsAAJoAAAA5DQAAAAAAAAAAAAAAAAAAOQ0AAAAAAACKDQAAMAAA
ALoNAAAAAAAAOQ0AAAAAAAD2EAAAAAAAACEMAAAAAAAA9hAAAAAAAAA5DQAAAAAAACEMAAAAAAAA
nAEAAAAAAACcAQAAAAAAAKgAAAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAAgDZAAAACAgI
CAgICAgIDQ0ICA0NCAgNDQ0NDQ0NDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgTk9ERSAgIEEgOiAgIERpZmYtU2VydiAgIGRpc2FibGVkDSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgTk9ERSAgQiAgOiAgIERpZmYtU2VydiAgZW5hYmxlZCAo
IEUtTFNQICkNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOT0RFICAg
QyA6ICAgRGlmZi1TZXJ2ICAgZGlzYWJsZWQNDQ0NDU5vdyBteSBxdWVzdGlvbiBpcyA6ICANDSAg
ICAgICAgICBIb3cgbm9kZSBCIHdpbGwgdW5kZXJzdGFuZCB0aGUgTGFiZWwgUmVxdWVzdCBtZXNz
YWdlIC4NIFdoZXRoZXIgaXQgd2lsbCB1bmRlcnN0YW5kIHRoZSByZXF1ZXN0IGZvciAgZGVmYXVs
dCAgZm9yd2FyZGluZyAgY2FzZSANb3IgICBQcmUtY29uZmlndXJlZCAgRVhQLS0+IFBIQiBtYXBw
aW5nIGNhc2U/Li4uLg0gYWNjb3JkaW5nIHRvIHRoZSBkcmFmdHMgaXQgaXMgdGhlIGxhdHRlciBv
bmUuIFdvbpJ0IHRoaXMgbGVhZCB0byBtaXN1bmRlcnN0YW5kaW5nDSBiZXR3ZWVuIHRoZSBMU1KS
cy4gIElzbpJ0IHRoaXMgYSBCYWNrd2FyZCBJbmNvbXBhdGliaWxpdHkgcHJvYmxlbT8NQQ0NQg0N
Qw0NIExhYmVsIHJlcXVlc3QgbWVzc2FnZSB3aXRob3V0ICBkaWZmLXNlcnYgVExWDQ1MYWJlbCBS
ZXF1ZXN0IG1lc3NhZ2Ugd2l0aG91dCAgRGlmZi1TZXJ2IFRMVg0NDQ0AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAkE
AAALBAAADQQAAA8EAAARBAAA2AYAAPMA8wDzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGANqAAAAAENKFABVCAFtSAAEbkgABHUIAQYABAAACgQA
AAsEAAAOBAAADwQAABIEAAATBAAAFAQAABUEAAAWBAAAFwQAABgEAAAZBAAAZAQAALcEAAACBQAA
AwUAAAQFAAAFBQAABgUAAB0FAAAeBQAAXwUAAKcFAADZBQAALAYAAHAGAAByBgAAcwYAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAANxgUAAfQaAAABAAAAHAAEAABwBgAA
1wYAAP7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQECcwYAAHUGAAB2
BgAAeAYAAHkGAACnBgAAqAYAANUGAADWBgAA1wYAANgGAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAADcYFAAH0GgAAAQAAAAogADGQaAEfsNAv
ILDgPSGwCAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQADwAKAAEAaQAP
AAMAAAAAAAAAAAA4AABA8f8CADgADAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgA
bUgJBHNICQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0
ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAAAAAAAADAAAABgAAAAkA
AAA4AAAAZgAAANgCAAABAAAAAAAAAAAA/////wIEAAAAAAAAAQAAAAAAAAAAAP////8EBAAAAAAA
AAEAAAAAAAAAAAD/////BQQAAAAAAAABAAAAAAAAAAAA/////xMEAAAAAAAAAQAAAAAAAAAAAP//
//8XBAAAAAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAYAAAAJAAAAOAAAAGYAAABp
AAAAAAAAAAAIAQAAAAAIAgAAAAAIAwAAAAAIBAAAAAAI//8AAAAAAAAAANgCAAAIAAASAAAAAP//
//8AAAAACgAAAAsAAAAOAAAADwAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAZAAA
ALcAAAACAQAAAwEAAAQBAAAFAQAABgEAAB0BAAAeAQAAXwEAAKcBAADZAQAALAIAAHACAAByAgAA
cwIAAHUCAAB2AgAAeAIAAHkCAACnAgAAqAIAANUCAADZAgAAmAAAAAAwAAAAAAAAAIAAAACAmAAA
AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw
AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA
AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA
AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA
AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA
mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA
AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw
AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA
AAAAAIAAAACAmgAAAAAAAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAAAAAAAAAA
AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAAAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA
AACAmgAAAAAAAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAAAAAAAAAAAIAAAACA
AAQAANgGAAAFAAAAAAQAAHMGAADYBgAABgAAAAgAAAAABAAA1wYAAAcAAAAPAADwOAAAAAAABvAY
AAAAAggAAAIAAAAUAAAAAQAAAAEAAAAZAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCo
BAAAEAAI8AgAAAAOAAAAGAQAAA8AA/BGBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA
AAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAIEAAAACgAAEwAL8AYAAACAAAAAAQAA
ABDwBAAAAAgAAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAAQAPAATwTgAAABIACvAIAAAABAQAAAAK
AAAzAAvwEgAAAIAAAAACAIEB/2YAAL8BEAAQAAAAEPAEAAAABgAAAAAAEfAEAAAAGQAAAAAADfAE
AAAAAAACAA8ABPBCAAAAEgAK8AgAAAAFBAAAAAoAABMAC/AGAAAAgAAAAAMAAAAQ8AQAAAAHAAAA
AAAR8AQAAAAoAAAAAAAN8AQAAAAAAAMADwAE8EgAAABCAQrwCAAAAAoEAAAACgAAQwAL8BgAAABE
AQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAMAAAAAABHwBAAAAA4AAAAPAATwSAAAAEIB
CvAIAAAADAQAAAAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAEAAAABQAA
AAAAEfAEAAAABQAAAA8ABPBIAAAAQgEK8AgAAAANBAAAAAoAAEMAC/AYAAAARAEEAAAAfwEAAAEA
vwEAABAA/wEQABAAAAAQ8AQAAAAEAAAAAAAR8AQAAAAFAAAADwAE8EgAAABCAQrwCAAAAA4EAAAA
CgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAIAAAAAABHwBAAAAAQA
AAAPAATwQgAAAKIMCvAIAAAAEwQAAAAKAAATAAvwBgAAAIAAAAAEAAAAEPAEAAAAAAAAAAAAEfAE
AAAABwAAAAAADfAEAAAAAAAEAA8ABPBOAAAAQgEK8AgAAAAUBAAAAAoAAFMAC/AeAAAARAEEAAAA
fwEAAAEAvwEAABAA0QEBAAAA/wEQABAAAAAQ8AQAAAAMAAAAAAAR8AQAAAACAAAADwAE8E4AAABC
AQrwCAAAABUEAAAACgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAAEADRAQEAAAD/ARAAEAAAABDw
BAAAAAoAAAAAABHwBAAAAAIAAAAPAATwTgAAAEIBCvAIAAAAFgQAAAAKAABTAAvwHgAAAEQBBAAA
AH8BAAABAL8BAAAQANEBAQAAAP8BEAAQAAAAEPAEAAAACwAAAAAAEfAEAAAAAgAAAA8ABPBCAAAA
ogwK8AgAAAAXBAAAAAoAABMAC/AGAAAAgAAAAAUAAAAQ8AQAAAABAAAAAAAR8AQAAAAqAAAAAAAN
8AQAAAAAAAUADwAE8E4AAABCAQrwCAAAABgEAAAACgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAA
EADRAQEAAAD/ARAAEAAAABDwBAAAAAkAAAAAABHwBAAAAAEAAAAPAATwQgAAABIACvAIAAAAAQQA
AAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAAAA
AAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAsAAAAMAAAADwAAABAAAADYAgAAEwQA
AIQDAAAAAAAAEA4AANACAAB0AAAAAAAXBAAASBIAAAAAAADUHAAA0AIAAHQAAAAAAA4EAAA8HgAA
oAUAANwjAACgBQAAdAAAAAAACgQAADD9//+gBQAAHAIAAKAFAAB0AAAAAAANBAAAlBEAAKAFAAC4
GgAAoAUAAHQAAAAAAAwEAACgBQAAoAUAABAOAACgBQAAdAAAAAAABAQAABAOAACEAwAAlBEAALwH
AAB0AAAAAAAFBAAAuBoAAIQDAAA8HgAAvAcAAHQAAAAAAAIEAAAcAgAAhAMAAKAFAAC8BwAAdAAA
AAAAGAQAABgVAACoAAAAzBUAAMQCAAB0AAAAAAAVBAAAcAgAAKgAAAAkCQAAxAIAAHQAAAAAABYE
AAD8EgAAnAAAAFAZAACcAAAAdAAAAAAAFAQAAFQGAACcAAAAqAwAAJwAAAB0AAAAAAAAAAAAOQIA
AD4CAABwAgAAngIAAKICAADZAgAABwAcAAcABwAcAAcAAAAAAEkAAABMAAAAjQAAAJQAAADnAAAA
6gAAABYBAAAaAQAAVQEAAF4BAACHAQAAkwEAAKcBAACpAQAA2gEAAOMBAAAtAgAANAIAAEECAABw
AgAAkAIAAJ0CAAC+AgAAywIAANkCAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHAAQABwAzAAcAMwAHAP//BAAAAA8ARgB1AHQAdQByAGUAIABTAG8AZgB0AHcAYQByAGUATQBD
ADoAXABXAEkATgBEAE8AVwBTAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0A
aQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBh
AHYAZQAgAG8AZgAgAEQAbwBjAHUAbQBlAG4AdAAxAC4AYQBzAGQADwBGAHUAdAB1AHIAZQAgAFMA
bwBmAHQAdwBhAHIAZQAaAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAZABpAGYAZgBf
AFEALgBkAG8AYwD/QAOAAQBvAgAAbwIAAKQZuwG4AbgBbwIAAAAAAABvAgAAAAAAAAIQAAAAAAAA
ANgCAACAAAAIAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAA
AAD//wAAAgD//wAAAAD//wAAAgD//wAAAAADAAAARxaQAQAAAgIGAwUEBQIDBIc6AAAAAAAAAAAA
AAAAAAD/AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEH
BgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgIC
BIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAEEAcgBpAGEAbAAAACIABABxCIgYAPDQAgAAaAEAAAAA
3rNWpuuzVqYAAAAAAQANAAAAWgAAAAICAAABAAEAAAAEAAMQBAAAAAAAAAAAAAAAAQABAAAAAQAA
AAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBMjAAAAAAAAAA
AAAAAAAAAHcCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD//xIAAAAAAAAAAAAAAAAAAAAPAEYAdQB0AHUAcgBlACAAUwBvAGYAdAB3AGEA
cgBlAA8ARgB1AHQAdQByAGUAIABTAG8AZgB0AHcAYQByAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAA
AAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAHQBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAACk
AAAABAAAALAAAAAFAAAAyAAAAAYAAADUAAAABwAAAOAAAAAIAAAA8AAAAAkAAAAIAQAAEgAAABQB
AAAKAAAAMAEAAAwAAAA8AQAADQAAAEgBAAAOAAAAVAEAAA8AAABcAQAAEAAAAGQBAAATAAAAbAEA
AAIAAADkBAAAHgAAAAEAAAAAAHMAHgAAAAEAAAAAAHMAHgAAABAAAABGdXR1cmUgU29mdHdhcmUA
HgAAAAEAAAAAdXR1HgAAAAEAAAAAdXR1HgAAAAcAAABOb3JtYWwAUx4AAAAQAAAARnV0dXJlIFNv
ZnR3YXJlAB4AAAACAAAAMQB0dR4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4wAABAAAAAAI7q0AEA
AABAAAAAANBWGQL7wAFAAAAAAF5B6gP7wAEDAAAAAQAAAAMAAABaAAAAAwAAAAICAAADAAAAAAAA
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
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA
AtXN1ZwuGxCTlwgAKyz5rjAAAAD0AAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAiAAAAAYAAACQ
AAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAAAAATAAAAuAAAABYAAADAAAAADQAAAMgA
AAAMAAAA1QAAAAIAAADkBAAAHgAAABAAAABGdXR1cmUgU29mdHdhcmUAAwAAAAQAAAADAAAAAQAA
AAMAAAB3AgAAAwAAADIRCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA
AQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
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
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAA
/v///wsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAA/v///xQAAAAVAAAAFgAAABcAAAAY
AAAAGQAAABoAAAD+////HAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAAP7////9////JQAAAP7/
///+/////v//////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAA
AEYAAAAAAAAAAAAAAABAU7PtA/vAAScAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAPYQAAAAAAAAVwBvAHIAZABE
AG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA
AgEFAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIhIA
AAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAABMAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA
bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAGwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMA
dABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAB
AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAQFOz7QP7wAFAU7PtA/vAAQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29m
dCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==

------_=_NextPart_000_01C0FD6E.4E5DBD90--



From owner-mpls@UU.NET  Mon Jun 25 07:41:08 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11284
	for ; Mon, 25 Jun 2001 07:41:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuxy16003;
	Mon, 25 Jun 2001 11:39:19 GMT
Received: by mail-control.mail.uu.net 
	id QQkuxy28858
	for mpls-outgoing; Mon, 25 Jun 2001 11:38:47 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkuxy28853
	for ; Mon, 25 Jun 2001 11:38:41 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 QQkuxy04104
	for ; Mon, 25 Jun 2001 11:32:50 GMT
Received: from grex.cyberspace.org by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQkuxy13440
	for ; Mon, 25 Jun 2001 11:32:50 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id HAA28060; Mon, 25 Jun 2001 07:33:10 -0400
Date: Mon, 25 Jun 2001 07:33:09 -0400 (EDT)
From: "Hemant P. Kelkar" 
To: mpls@UU.NET
cc: ip-optical@lists.bell-labs.com
Subject: QoS in WRONs
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi everybody,
In wavelength routed optical networks (WRONs) (which can be exploited by
MPLS-CP components for MPLambdaS solutions), which are the QoS parameters
of interest ?
Apart from Lambda provisioning per link/per connection, which are the QoS
provisioning mechanisms in MPLambdaS networks ?
sorry, if it has been covered earlier.
--
regards,
Hemant



From owner-mpls@UU.NET  Mon Jun 25 07:48:56 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11482
	for ; Mon, 25 Jun 2001 07:48:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuxz28037;
	Mon, 25 Jun 2001 11:48:16 GMT
Received: by mail-control.mail.uu.net 
	id QQkuxz29965
	for mpls-outgoing; Mon, 25 Jun 2001 11:47:33 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkuxz29959
	for ; Mon, 25 Jun 2001 11:47:29 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 QQkuxz00403
	for ; Mon, 25 Jun 2001 11:47:11 GMT
Received: from grex.cyberspace.org by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: grex.cyberspace.org [216.93.104.34])
	id QQkuxz24372
	for ; Mon, 25 Jun 2001 11:47:11 GMT
Received: from localhost (hemant@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id HAA29374; Mon, 25 Jun 2001 07:47:29 -0400
Date: Mon, 25 Jun 2001 07:47:28 -0400 (EDT)
From: "Hemant P. Kelkar" 
To: nozizzingordripping@yahoo.com
cc: mpls@UU.NET
Subject: Re:What to do with an illegal label stack?
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi Zizz,
If the MPLS forwarding plane receives a label stack which is illegal, it
will silently (ideally it should) process the upper layer of the label
stack, WITHOUT checking for the validity/presence of the "S" bit. The
reason for this behaviour is that if the forwarding plane checks everytime
about the sanity of the label stack, the desired feature of MPLS (i.e.
fast switching using labels) will not be achieved in practice.
Therefore, the better idea is to keep the responsibility of
assigning/determining the correct label stack, with the LDP (or any other
label distribution protocol). The control plane of every LSR, 
participating
in the label distribution process should keep this check.
Further, avoiding such errors is a must, since a case may arise, when the
MPLS forwarding plane will process the "header of IP packet" assuming it
to be the next layer of the label stack(when the S bit is not set in the
bottom of the stack.)
Hope that was useful to you,
regards,
--
Hemant


------------------------------------------------------
An MPLS packet arrives with a label stack with no
bottom of stack bit set (e.g. 88 47 22 22 20 60 00 00
00 00 00 00...).

Is any behavior mandated here?  Is it OK to forward
this packet, or must it be discarded?

-Zizz
 



From owner-mpls@UU.NET  Mon Jun 25 08:28:48 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12924
	for ; Mon, 25 Jun 2001 08:28:47 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuyb17019;
	Mon, 25 Jun 2001 12:27:28 GMT
Received: by mail-control.mail.uu.net 
	id QQkuyb22755
	for mpls-outgoing; Mon, 25 Jun 2001 12:26:56 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkuyb22740
	for ; Mon, 25 Jun 2001 12:26: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 QQkuyb20312
	for ; Mon, 25 Jun 2001 12:26:03 GMT
From: francis.arts@alcatel.be
Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc119.alcatel.be [195.207.101.119])
	id QQkuyb08403
	for ; Mon, 25 Jun 2001 12:26:01 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f5PCPrt26983;
	Mon, 25 Jun 2001 14:25:57 +0200 (MET DST)
Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256A76.004446C0 ; Mon, 25 Jun 2001 14:25:45 +0200
X-Lotus-FromDomain: ALCATEL
To: "'murali tallapudi'" 
cc: "'mpls@uu.net'" 
Message-ID: 
Date: Mon, 25 Jun 2001 14:25:41 +0200
Subject: RE: doubt on diff-serv
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=BKRXgN1QBM6tZzRB1mDWsBtkwdDnyvkxKx7mS9dR18AlkbtS6twOqPOw"
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk

--0__=BKRXgN1QBM6tZzRB1mDWsBtkwdDnyvkxKx7mS9dR18AlkbtS6twOqPOw
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




Murali,

Section 5.3 of   indicates the expected behavior in the situation described in your mail:

"If a DIFFSERV object is not present in the Path message, the LSR
   SHOULD interpret this as a request for an E-LSP using the
   Preconfigured EXP<-->PHB Mapping. However, for backward
   compatibility purposes with other non-Diff-Serv Quality of Service
   options allowed by [RSVP_MPLS_TE] such as Integrated Services
   Controlled Load or Guaranteed Services, the LSR MAY support a
   configurable "override option". When this "override option" is
   configured, the LSR interprets a path message without a Diff-Serv
   object as a request for an LSP with such non-Diff-Serv Quality of
   Service."



     Francis.








Sasha Vainshtein  on 25/06/2001 13:59:36
                                                              
                                                              
                                                              
 To:      "'murali tallapudi'"            
                                                              
 cc:      "'mpls@uu.net'" (bcc: Francis          
          ARTS/BE/ALCATEL)                                    
                                                              
                                                              
                                                              
 Subject: RE: doubt on diff-serv                              
                                                              





Murali,
This is a good and valid question. IMHO the answer is like following:
1. Router B operates in accordance with preconfigured EXP-->PHB mappings
2. Preconfigured mappings in any DiffServ-aware LSR MUST include
    mapping of  000 (EXP) --> Default Forwarding PHB. May be this should
    be explicitly added to the draft
3. Router A (which is not Diff-Serv-aware) MUST set EXP bits to 000.
This would result in consistent LSP behavior.
------------------------------------------
With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)



> -----Original Message-----
> From: murali tallapudi [mailto:tallapudi@mail.com]
> Sent: Monday, June 25, 2001 7:10 AM
> To: Sasha@AXERRA.com
> Subject: doubt on diff-serv
>
>
>  hi,
>
>    i got one doubt on diff-serv. can u see the attachment
> and clear my doubt?..
>
>
>  regards
>
>  murali
> --
>
> _______________________________________________
> FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
>
> FREE PC-to-Phone calls with Net2Phone
> http://www.net2phone.com/cgi-bin/link.cgi?121
>
>
>
>
>
> --
>
> _______________________________________________
> FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
>
> FREE PC-to-Phone calls with Net2Phone
> http://www.net2phone.com/cgi-bin/link.cgi?121
>
>
>
>
>
>



--0__=BKRXgN1QBM6tZzRB1mDWsBtkwdDnyvkxKx7mS9dR18AlkbtS6twOqPOw
Content-type: application/msword; 
	name="diff_Q.doc"
Content-Disposition: attachment; filename="diff_Q.doc"
Content-Description: Mac Word 3.0
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJAAAAAAAAAAA
EAAAJgAAAAEAAAD+////AAAAACMAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAWyAJBAAA8BK/AAAAAAAAEAAAAAAABAAA2AYAAA4AYmpiauIA4gAAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAIhIAAIBqAQCAagEAcAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZwAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAKgAAAAAAAAAqAAAAKgA
AAAAAAAAqAAAAAAAAACIAQAAAAAAAIgBAAAAAAAAiAEAABQAAAAAAAAAAAAAAJwBAAAAAAAAuAQA
AAAAAAC4BAAAAAAAALgEAAAAAAAAuAQAAAwAAADEBAAAFAAAAJwBAAAAAAAAug0AALYAAADkBAAA
AAAAAOQEAAAAAAAA5AQAAAAAAADkBAAAAAAAAOQEAAAAAAAAXwsAAAAAAABfCwAAAAAAAF8LAAAA
AAAAOQ0AAAIAAAA7DQAAAAAAADsNAAAAAAAAOw0AAAAAAAA7DQAAAAAAADsNAAAAAAAAOw0AACQA
AABwDgAAIAIAAJAQAABmAAAAXw0AABUAAAAAAAAAAAAAAAAAAAAAAAAAiAEAAAAAAABfCwAAAAAA
AAAAAAAAAAAAAAAAAAAAAADVCQAAigEAAF8LAAAAAAAAXwsAAAAAAABfCwAAAAAAAF8NAAAAAAAA
IQwAAAAAAACoAAAAAAAAAKgAAAAAAAAA5AQAAAAAAAAAAAAAAAAAAOQEAADxBAAAdA0AABYAAAAh
DAAAAAAAACEMAAAAAAAAIQwAAAAAAABfCwAAKAAAAKgAAACgAAAA5AQAAAAAAACIAQAAAAAAAOQE
AAAAAAAAOQ0AAAAAAAAAAAAAAAAAACEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAXwsAAAAAAAA5DQAAAAAAACEMAAAYAQAAIQwAAAAAAAAAAAAA
AAAAADkNAAAAAAAASAEAAEAAAACIAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOQ0AAAAAAADkBAAAAAAAANgEAAAMAAAAYIqi7QP7
wAGcAQAAHAMAALgEAAAAAAAAhwsAAJoAAAA5DQAAAAAAAAAAAAAAAAAAOQ0AAAAAAACKDQAAMAAA
ALoNAAAAAAAAOQ0AAAAAAAD2EAAAAAAAACEMAAAAAAAA9hAAAAAAAAA5DQAAAAAAACEMAAAAAAAA
nAEAAAAAAACcAQAAAAAAAKgAAAAAAAAAqAAAAAAAAACoAAAAAAAAAKgAAAAAAAAAAgDZAAAACAgI
CAgICAgIDQ0ICA0NCAgNDQ0NDQ0NDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgTk9ERSAgIEEgOiAgIERpZmYtU2VydiAgIGRpc2FibGVkDSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgTk9ERSAgQiAgOiAgIERpZmYtU2VydiAgZW5hYmxlZCAo
IEUtTFNQICkNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOT0RFICAg
QyA6ICAgRGlmZi1TZXJ2ICAgZGlzYWJsZWQNDQ0NDU5vdyBteSBxdWVzdGlvbiBpcyA6ICANDSAg
ICAgICAgICBIb3cgbm9kZSBCIHdpbGwgdW5kZXJzdGFuZCB0aGUgTGFiZWwgUmVxdWVzdCBtZXNz
YWdlIC4NIFdoZXRoZXIgaXQgd2lsbCB1bmRlcnN0YW5kIHRoZSByZXF1ZXN0IGZvciAgZGVmYXVs
dCAgZm9yd2FyZGluZyAgY2FzZSANb3IgICBQcmUtY29uZmlndXJlZCAgRVhQLS0+IFBIQiBtYXBw
aW5nIGNhc2U/Li4uLg0gYWNjb3JkaW5nIHRvIHRoZSBkcmFmdHMgaXQgaXMgdGhlIGxhdHRlciBv
bmUuIFdvbpJ0IHRoaXMgbGVhZCB0byBtaXN1bmRlcnN0YW5kaW5nDSBiZXR3ZWVuIHRoZSBMU1KS
cy4gIElzbpJ0IHRoaXMgYSBCYWNrd2FyZCBJbmNvbXBhdGliaWxpdHkgcHJvYmxlbT8NQQ0NQg0N
Qw0NIExhYmVsIHJlcXVlc3QgbWVzc2FnZSB3aXRob3V0ICBkaWZmLXNlcnYgVExWDQ1MYWJlbCBS
ZXF1ZXN0IG1lc3NhZ2Ugd2l0aG91dCAgRGlmZi1TZXJ2IFRMVg0NDQ0AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAkE
AAALBAAADQQAAA8EAAARBAAA2AYAAPMA8wDzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGANqAAAAAENKFABVCAFtSAAEbkgABHUIAQYABAAACgQA
AAsEAAAOBAAADwQAABIEAAATBAAAFAQAABUEAAAWBAAAFwQAABgEAAAZBAAAZAQAALcEAAACBQAA
AwUAAAQFAAAFBQAABgUAAB0FAAAeBQAAXwUAAKcFAADZBQAALAYAAHAGAAByBgAAcwYAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAANxgUAAfQaAAABAAAAHAAEAABwBgAA
1wYAAP7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQECcwYAAHUGAAB2
BgAAeAYAAHkGAACnBgAAqAYAANUGAADWBgAA1wYAANgGAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAADcYFAAH0GgAAAQAAAAogADGQaAEfsNAv
ILDgPSGwCAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQADwAKAAEAaQAP
AAMAAAAAAAAAAAA4AABA8f8CADgADAAGAE4AbwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgA
bUgJBHNICQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0
ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAAAAAAAADAAAABgAAAAkA
AAA4AAAAZgAAANgCAAABAAAAAAAAAAAA/////wIEAAAAAAAAAQAAAAAAAAAAAP////8EBAAAAAAA
AAEAAAAAAAAAAAD/////BQQAAAAAAAABAAAAAAAAAAAA/////xMEAAAAAAAAAQAAAAAAAAAAAP//
//8XBAAAAAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAYAAAAJAAAAOAAAAGYAAABp
AAAAAAAAAAAIAQAAAAAIAgAAAAAIAwAAAAAIBAAAAAAI//8AAAAAAAAAANgCAAAIAAASAAAAAP//
//8AAAAACgAAAAsAAAAOAAAADwAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAZAAA
ALcAAAACAQAAAwEAAAQBAAAFAQAABgEAAB0BAAAeAQAAXwEAAKcBAADZAQAALAIAAHACAAByAgAA
cwIAAHUCAAB2AgAAeAIAAHkCAACnAgAAqAIAANUCAADZAgAAmAAAAAAwAAAAAAAAAIAAAACAmAAA
AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw
AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA
AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA
AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA
AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA
mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA
AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw
AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA
AAAAAIAAAACAmgAAAAAAAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAAAAAAAAAA
AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAAAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA
AACAmgAAAAAAAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAAAAAAAAAAAIAAAACA
AAQAANgGAAAFAAAAAAQAAHMGAADYBgAABgAAAAgAAAAABAAA1wYAAAcAAAAPAADwOAAAAAAABvAY
AAAAAggAAAIAAAAUAAAAAQAAAAEAAAAZAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCo
BAAAEAAI8AgAAAAOAAAAGAQAAA8AA/BGBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA
AAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAIEAAAACgAAEwAL8AYAAACAAAAAAQAA
ABDwBAAAAAgAAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAAQAPAATwTgAAABIACvAIAAAABAQAAAAK
AAAzAAvwEgAAAIAAAAACAIEB/2YAAL8BEAAQAAAAEPAEAAAABgAAAAAAEfAEAAAAGQAAAAAADfAE
AAAAAAACAA8ABPBCAAAAEgAK8AgAAAAFBAAAAAoAABMAC/AGAAAAgAAAAAMAAAAQ8AQAAAAHAAAA
AAAR8AQAAAAoAAAAAAAN8AQAAAAAAAMADwAE8EgAAABCAQrwCAAAAAoEAAAACgAAQwAL8BgAAABE
AQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAMAAAAAABHwBAAAAA4AAAAPAATwSAAAAEIB
CvAIAAAADAQAAAAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAEAAAABQAA
AAAAEfAEAAAABQAAAA8ABPBIAAAAQgEK8AgAAAANBAAAAAoAAEMAC/AYAAAARAEEAAAAfwEAAAEA
vwEAABAA/wEQABAAAAAQ8AQAAAAEAAAAAAAR8AQAAAAFAAAADwAE8EgAAABCAQrwCAAAAA4EAAAA
CgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAIAAAAAABHwBAAAAAQA
AAAPAATwQgAAAKIMCvAIAAAAEwQAAAAKAAATAAvwBgAAAIAAAAAEAAAAEPAEAAAAAAAAAAAAEfAE
AAAABwAAAAAADfAEAAAAAAAEAA8ABPBOAAAAQgEK8AgAAAAUBAAAAAoAAFMAC/AeAAAARAEEAAAA
fwEAAAEAvwEAABAA0QEBAAAA/wEQABAAAAAQ8AQAAAAMAAAAAAAR8AQAAAACAAAADwAE8E4AAABC
AQrwCAAAABUEAAAACgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAAEADRAQEAAAD/ARAAEAAAABDw
BAAAAAoAAAAAABHwBAAAAAIAAAAPAATwTgAAAEIBCvAIAAAAFgQAAAAKAABTAAvwHgAAAEQBBAAA
AH8BAAABAL8BAAAQANEBAQAAAP8BEAAQAAAAEPAEAAAACwAAAAAAEfAEAAAAAgAAAA8ABPBCAAAA
ogwK8AgAAAAXBAAAAAoAABMAC/AGAAAAgAAAAAUAAAAQ8AQAAAABAAAAAAAR8AQAAAAqAAAAAAAN
8AQAAAAAAAUADwAE8E4AAABCAQrwCAAAABgEAAAACgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAA
EADRAQEAAAD/ARAAEAAAABDwBAAAAAkAAAAAABHwBAAAAAEAAAAPAATwQgAAABIACvAIAAAAAQQA
AAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAAAA
AAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAsAAAAMAAAADwAAABAAAADYAgAAEwQA
AIQDAAAAAAAAEA4AANACAAB0AAAAAAAXBAAASBIAAAAAAADUHAAA0AIAAHQAAAAAAA4EAAA8HgAA
oAUAANwjAACgBQAAdAAAAAAACgQAADD9//+gBQAAHAIAAKAFAAB0AAAAAAANBAAAlBEAAKAFAAC4
GgAAoAUAAHQAAAAAAAwEAACgBQAAoAUAABAOAACgBQAAdAAAAAAABAQAABAOAACEAwAAlBEAALwH
AAB0AAAAAAAFBAAAuBoAAIQDAAA8HgAAvAcAAHQAAAAAAAIEAAAcAgAAhAMAAKAFAAC8BwAAdAAA
AAAAGAQAABgVAACoAAAAzBUAAMQCAAB0AAAAAAAVBAAAcAgAAKgAAAAkCQAAxAIAAHQAAAAAABYE
AAD8EgAAnAAAAFAZAACcAAAAdAAAAAAAFAQAAFQGAACcAAAAqAwAAJwAAAB0AAAAAAAAAAAAOQIA
AD4CAABwAgAAngIAAKICAADZAgAABwAcAAcABwAcAAcAAAAAAEkAAABMAAAAjQAAAJQAAADnAAAA
6gAAABYBAAAaAQAAVQEAAF4BAACHAQAAkwEAAKcBAACpAQAA2gEAAOMBAAAtAgAANAIAAEECAABw
AgAAkAIAAJ0CAAC+AgAAywIAANkCAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHAAQABwAzAAcAMwAHAP//BAAAAA8ARgB1AHQAdQByAGUAIABTAG8AZgB0AHcAYQByAGUATQBD
ADoAXABXAEkATgBEAE8AVwBTAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0A
aQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBh
AHYAZQAgAG8AZgAgAEQAbwBjAHUAbQBlAG4AdAAxAC4AYQBzAGQADwBGAHUAdAB1AHIAZQAgAFMA
bwBmAHQAdwBhAHIAZQAaAEMAOgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAZABpAGYAZgBf
AFEALgBkAG8AYwD/QAOAAQBvAgAAbwIAAKQZuwG4AbgBbwIAAAAAAABvAgAAAAAAAAIQAAAAAAAA
ANgCAACAAAAIAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAA
AAD//wAAAgD//wAAAAD//wAAAgD//wAAAAADAAAARxaQAQAAAgIGAwUEBQIDBIc6AAAAAAAAAAAA
AAAAAAD/AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEH
BgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgIC
BIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAEEAcgBpAGEAbAAAACIABABxCIgYAPDQAgAAaAEAAAAA
3rNWpuuzVqYAAAAAAQANAAAAWgAAAAICAAABAAEAAAAEAAMQBAAAAAAAAAAAAAAAAQABAAAAAQAA
AAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBMjAAAAAAAAAA
AAAAAAAAAHcCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD//xIAAAAAAAAAAAAAAAAAAAAPAEYAdQB0AHUAcgBlACAAUwBvAGYAdAB3AGEA
cgBlAA8ARgB1AHQAdQByAGUAIABTAG8AZgB0AHcAYQByAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAA
AAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAHQBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAACk
AAAABAAAALAAAAAFAAAAyAAAAAYAAADUAAAABwAAAOAAAAAIAAAA8AAAAAkAAAAIAQAAEgAAABQB
AAAKAAAAMAEAAAwAAAA8AQAADQAAAEgBAAAOAAAAVAEAAA8AAABcAQAAEAAAAGQBAAATAAAAbAEA
AAIAAADkBAAAHgAAAAEAAAAAAHMAHgAAAAEAAAAAAHMAHgAAABAAAABGdXR1cmUgU29mdHdhcmUA
HgAAAAEAAAAAdXR1HgAAAAEAAAAAdXR1HgAAAAcAAABOb3JtYWwAUx4AAAAQAAAARnV0dXJlIFNv
ZnR3YXJlAB4AAAACAAAAMQB0dR4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4wAABAAAAAAI7q0AEA
AABAAAAAANBWGQL7wAFAAAAAAF5B6gP7wAEDAAAAAQAAAAMAAABaAAAAAwAAAAICAAADAAAAAAAA
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
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA
AtXN1ZwuGxCTlwgAKyz5rjAAAAD0AAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAiAAAAAYAAACQ
AAAAEQAAAJgAAAAXAAAAoAAAAAsAAACoAAAAEAAAALAAAAATAAAAuAAAABYAAADAAAAADQAAAMgA
AAAMAAAA1QAAAAIAAADkBAAAHgAAABAAAABGdXR1cmUgU29mdHdhcmUAAwAAAAQAAAADAAAAAQAA
AAMAAAB3AgAAAwAAADIRCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA
AQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
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
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAA
/v///wsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAA/v///xQAAAAVAAAAFgAAABcAAAAY
AAAAGQAAABoAAAD+////HAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAAP7////9////JQAAAP7/
///+/////v//////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAA
AEYAAAAAAAAAAAAAAABAU7PtA/vAAScAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAPYQAAAAAAAAVwBvAHIAZABE
AG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA
AgEFAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIhIA
AAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAABMAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA
bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAGwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMA
dABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAB
AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAQFOz7QP7wAFAU7PtA/vAAQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29m
dCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==

--0__=BKRXgN1QBM6tZzRB1mDWsBtkwdDnyvkxKx7mS9dR18AlkbtS6twOqPOw--



From owner-mpls@UU.NET  Mon Jun 25 12:54:45 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21130
	for ; Mon, 25 Jun 2001 12:54:44 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuyt07553;
	Mon, 25 Jun 2001 16:51:32 GMT
Received: by mail-control.mail.uu.net 
	id QQkuyt05019
	for mpls-outgoing; Mon, 25 Jun 2001 16:50:55 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkuyt05011
	for ; Mon, 25 Jun 2001 16:50:40 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 QQkuyt21764
	for ; Mon, 25 Jun 2001 16:49: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 QQkuyt03332
	for ; Mon, 25 Jun 2001 16:49:24 GMT
Received: (qmail 25788 invoked by uid 104); 25 Jun 2001 16:49:24 -0000
Received: from Sajith_Kizhikkepurayil@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.412324 secs); 25/06/2001 09:49:23
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by mother.pmc-sierra.bc.ca with SMTP; 25 Jun 2001 16:49:23 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5PGnJe01265;
	Mon, 25 Jun 2001 09:49:19 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id ; Mon, 25 Jun 2001 09:53:33 -0700
Message-ID: <219DA90B32B7D411B90E00306E0071FC1529FF@sje4exm01.pmc-sierra.bc.ca>
From: Sajith Kizhikkepurayil 
To: "'Hemant P. Kelkar'" ,
        nozizzingordripping@yahoo.com
Cc: mpls@UU.NET
Subject: RE: What to do with an illegal label stack?
Date: Mon, 25 Jun 2001 09:53:31 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

>An MPLS packet arrives with a label stack with no
>bottom of stack bit set (e.g. 88 47 22 22 20 60 00 00
>00 00 00 00...).
>
>Is any behavior mandated here?  Is it OK to forward
>this packet, or must it be discarded?

i believe there is no way a forwarding plane can detect
this, unless there is an upper limit on number of labels
in the stack defined by the standarad, which, i believe
is not the case

so the packet will be forwarded, unless there any other
errors

thanks
sajith



From owner-mpls@UU.NET  Mon Jun 25 13:32:02 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21975
	for ; Mon, 25 Jun 2001 13:32:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuyw11105;
	Mon, 25 Jun 2001 17:30:17 GMT
Received: by mail-control.mail.uu.net 
	id QQkuyv27688
	for mpls-outgoing; Mon, 25 Jun 2001 17:29:45 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkuyv27676
	for ; Mon, 25 Jun 2001 17:29:36 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkuyv03153
	for ; Mon, 25 Jun 2001 17:28:44 GMT
Received: from saraswathi.hclt.co.in by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [202.54.64.6])
	id QQkuyv25619
	for ; Mon, 25 Jun 2001 17:28:42 GMT
Received: from gayatri.hclt.com (GAYATRI [192.168.232.199]) by saraswathi.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id NA8KVHS0; Mon, 25 Jun 2001 23:12:40 +0530
Received: from MALLIKPC ([192.168.232.162]) by gayatri.hclt.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id N158VKA4; Mon, 25 Jun 2001 22:56:24 +0530
From: "gopinathg" 
To: , 
Subject: Doubt in cr-ldp Release meaage
Date: Mon, 25 Jun 2001 23:05:51 +0530
Message-ID: <000001c0fd9d$48396e30$a2e8a8c0@hclt.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All

     What to do in cr-ldp If a release mesage contains a wild card FEC and
LSP-ID ? ie release message with no Label TLV.
Do we need to get the label using the LSP-ID and apply the same procedure as
for the wild card FEC & Label ?

Please Correct If I am wrong ....



Thanks In Advance

Gopinath.G.S
HCL Technologies
CHENNAI  600 006

http://www.hcltechnologies.com
Ph work: +91-44-8291735/36/37 ext-629
Ph Res  : +91-44-8292491



From owner-mpls@UU.NET  Mon Jun 25 15:18:45 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24602
	for ; Mon, 25 Jun 2001 15:18:45 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuzd20567;
	Mon, 25 Jun 2001 19:16:24 GMT
Received: by mail-control.mail.uu.net 
	id QQkuzd18144
	for mpls-outgoing; Mon, 25 Jun 2001 19:15:47 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkuzd18121
	for ; Mon, 25 Jun 2001 19:15:32 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkuzc01879
	for ; Mon, 25 Jun 2001 19:14:24 GMT
Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkuzc19807
	for ; Mon, 25 Jun 2001 19:14:24 GMT
Message-ID: <3B378D87.C65157B5@sandburst.com>
Date: Mon, 25 Jun 2001 15:14:15 -0400
From: Eric Gray 
MIME-Version: 1.0
To: gopinathg 
Cc: mpls@UU.NET
Subject: Re: Doubt in cr-ldp Release meaage
References: <000001c0fd9d$48396e30$a2e8a8c0@hclt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Gopinath,

    CR-LDP relies on Label Release processing as defined in RFC 3036.
Section 3.5.11.1 (of RFC 3036) says on this subject:

   "The FEC TLV may contain the Wildcard FEC Element; if so, it may
   contain no other FEC Elements.  In this case, if the Label Release
   message contains an optional Label TLV, then the label is to be
   released for all FECs to which it is bound.  If there is not an
   optional Label TLV in the Label Release message, then the sending LSR
   is releasing all label mappings previously learned from the receiving
   LSR."

Inclusion of the LSPID TLV was intended to be a potential optimization
that might be used by some LSRs to more quickly recover the state block
for the LSP.  This 'optimization' is not likely to be useful at any LSR
other than the one that assigned the LSPID (the LSP ingress).  It is
explicitly not intended to replace the Label and FEC in the standard LDP
Label Release message since an LSR that did not keep the LSPID as part
of its LSP state would be unable to recover information about the LSP to
be released.  The LSPID is only useful at LSRs with local repair capability
(i.e. - those 'terminating' a loose hop or those adjacent to an abstract
node).  Therefore, inclusion of an LSPID TLV with a wildcard FEC and no
Label TLV is likely to be an error; it can only be reliably handled using
basic LDP procedures.  In other words, considering only the FEC and Label
and releasing ALL labels distributed by the downstream LSR peer.

--
Eric Gray

You wrote:

> Hi All
>
>      What to do in cr-ldp If a release mesage contains a wild card FEC and
> LSP-ID ? ie release message with no Label TLV.
> Do we need to get the label using the LSP-ID and apply the same procedure as
> for the wild card FEC & Label ?
>
> Please Correct If I am wrong ....
>
> Thanks In Advance
>
> Gopinath.G.S
> HCL Technologies
> CHENNAI  600 006
>
> http://www.hcltechnologies.com
> Ph work: +91-44-8291735/36/37 ext-629
> Ph Res  : +91-44-8292491



From owner-mpls@UU.NET  Mon Jun 25 15:53:25 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25599
	for ; Mon, 25 Jun 2001 15:53:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuzf02420;
	Mon, 25 Jun 2001 19:50:37 GMT
Received: by mail-control.mail.uu.net 
	id QQkuzf22069
	for mpls-outgoing; Mon, 25 Jun 2001 19:49:42 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkuzf22052
	for ; Mon, 25 Jun 2001 19:49:27 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 QQkuze21511
	for ; Mon, 25 Jun 2001 19:44:50 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkuze05791
	for ; Mon, 25 Jun 2001 19:44:49 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA12467 for mpls@uu.net; Mon, 25 Jun 2001 15:44:49 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkuze21141
	for ; Mon, 25 Jun 2001 19:44:11 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 QQkuze19539
	for ; Mon, 25 Jun 2001 19:43:51 GMT
Received: from zrc2s03g.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [47.103.122.66])
	id QQkuze05583
	for ; Mon, 25 Jun 2001 19:43:51 GMT
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA25188
	for ; Mon, 25 Jun 2001 14:45:22 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 25 Jun 2001 14:42:56 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 25 Jun 2001 14:42:55 -0500
Message-ID: 
From: "Krishna Rao" 
To: "'mpls@uu.net'" 
Date: Mon, 25 Jun 2001 14:42:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0FDAF.043C2AD0"
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_01C0FDAF.043C2AD0
Content-Type: text/plain;
	charset="iso-8859-1"

auth 9c003f6b subscribe mpls kbrao@nortelnetworks.com


------_=_NextPart_001_01C0FDAF.043C2AD0
Content-Type: text/html;
	charset="iso-8859-1"











auth 9c003f6b subscribe mpls kbrao@nortelnetworks.com





------_=_NextPart_001_01C0FDAF.043C2AD0--



From owner-mpls@UU.NET  Mon Jun 25 19:11:48 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29348
	for ; Mon, 25 Jun 2001 19:11:48 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkuzs25054;
	Mon, 25 Jun 2001 23:11:02 GMT
Received: by mail-control.mail.uu.net 
	id QQkuzs04084
	for mpls-outgoing; Mon, 25 Jun 2001 23:10:30 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkuzs04064
	for ; Mon, 25 Jun 2001 23:10: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 QQkuzs24721
	for ; Mon, 25 Jun 2001 23:07:55 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkuzs21895
	for ; Mon, 25 Jun 2001 23:07:55 GMT
Message-ID: <3B37C442.D9ABC413@sandburst.com>
Date: Mon, 25 Jun 2001 19:07:46 -0400
From: Eric Gray 
MIME-Version: 1.0
To: Sajith Kizhikkepurayil 
Cc: mpls@UU.NET
Subject: Re: What to do with an illegal label stack?
References: <219DA90B32B7D411B90E00306E0071FC1529FF@sje4exm01.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sajith,

    Just to add to what you've said, each LSR is only supposed to
act on labels it has distributed and generally only those at the top
of the label stack.  An LSR will look at one or more lower labels
(in the label stack) if higher labels (starting at the top) are labels
distributed by the local LSR with a semantic meaning of "pop and
look again".

    The scenario in which the BOS bit is not correctly set will cause
some LSR somewhere to encounter something it thinks is a label
(but is not) and chances are that label will not be one it distributed.
In this case, it should recognize this as an error and discard the
offending packet.  The really thorny problem is when the LSR has
issued labels likely to occur in the first 32 bit word of an IP header.
For this reason, it could be a good idea to avoid using the label
0x45000 (for IPv4) or any label beginning with 0x6 (for IPv6)
whenever it is likely that packets may be received with the BOS bit
not correctly set - which (by the way) really should be NEVER.

    Otherwise, the only 'illegal' label stack is one that begins with
a label not distributed by the LSR that receives it.  In this case,
the only reasonable action is to drop the packet.

--
Eric Gray

You wrote:

> >An MPLS packet arrives with a label stack with no
> >bottom of stack bit set (e.g. 88 47 22 22 20 60 00 00
> >00 00 00 00...).
> >
> >Is any behavior mandated here?  Is it OK to forward
> >this packet, or must it be discarded?
>
> i believe there is no way a forwarding plane can detect
> this, unless there is an upper limit on number of labels
> in the stack defined by the standarad, which, i believe
> is not the case
>
> so the packet will be forwarded, unless there any other
> errors
>
> thanks
> sajith



From owner-mpls@UU.NET  Tue Jun 26 05:03:31 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25562
	for ; Tue, 26 Jun 2001 05:03:30 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvbg00625;
	Tue, 26 Jun 2001 09:02:30 GMT
Received: by mail-control.mail.uu.net 
	id QQkvbg06633
	for mpls-outgoing; Tue, 26 Jun 2001 09:01:56 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvbg06364
	for ; Tue, 26 Jun 2001 09:01: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 QQkvbg22722
	for ; Tue, 26 Jun 2001 09:00:20 GMT
Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [203.197.140.35])
	id QQkvbg26879
	for ; Tue, 26 Jun 2001 09:00:19 GMT
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id  for ;
 Tue, 26 Jun 2001 14:37:11 +0530
Received: from abdulmk (abdulmk.future.futsoft.com [10.8.7.11])
	by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f5Q8xJY01224
	for ; Tue, 26 Jun 2001 14:29:20 +0530
Message-Id: <004501c0fe1d$e75b4940$0b07080a@future.futsoft.com>
Reply-To: "Abdul Malick" 
From: "Abdul Malick" 
To: 
References: <004d01c0fbae$889c4d80$0b07080a@future.futsoft.com>
Subject: Re: Doubts regarding VR based VPNs
Date: Tue, 26 Jun 2001 14:26:33 +0530
Organization: Future Software Ltd.,
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0042_01C0FE4B.FFEE8D40"
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0042_01C0FE4B.FFEE8D40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello All

I haven't got any reply for my mail till now.
Can somebody help me out?

Regards
Malick
  ----- Original Message -----=20
  From: Abdul Malick=20
  To: mpls@uu.net=20
  Sent: Saturday, June 23, 2001 12:03 PM
  Subject: Doubts regarding VR based VPNs


  Hello All,

  After reading draft-ouldbrahim-vpn-vr-03.txt and other materials on VR =
based NBVPN i get the following doubts:

  1. Is it right to say that if we want to use piggy-backing for VPN =
information discovery, the backbone VR configuration is a must (because =
PEs have to be contacted by Public address which need not be visible to =
the VRs).

  2. Is it right to say that tunnels (MPLS, IPSEC,etc) could be used =
only in the backbone VR based configuration because otherwise the VRs =
have to be aware of the addresses and routes for the PEs (public)?

  3. Will the VRs send labelled packets to the backbone VR? If so will =
there be any signaling (may be some registration) between the VRs and =
backbone VR?

  4. Is it right to say that one VR can participate in only one VPN? (i =
did not find details on multiple VPN support per VR)


  Can somebody clear my doubts?
  Please pardon me if these questions have already been discussed.

  Thanks in advance

  Malick

------=_NextPart_000_0042_01C0FE4B.FFEE8D40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hello All


 


I haven't got any reply for my mail =
till=20
now.


Can somebody help me out?


 


Regards


Malick


  
----- Original Message ----- 

  From:=20
  Abdul Malick 
  
  
Sent: Saturday, June 23, 2001 =
12:03=20
  PM

  
Subject: Doubts regarding VR =
based=20
  VPNs

  


  
Hello All,

  
 

  
After reading =
draft-ouldbrahim-vpn-vr-03.txt and=20
  other materials on VR based NBVPN i get the following=20
doubts:

  
 

  
1. Is it right to say that if we want =
to use=20
  piggy-backing for VPN information discovery, the backbone VR =
configuration is=20
  a must (because PEs have to be contacted by Public address which =
need not=20
  be visible to the VRs).

  
 

  
2. Is it right to say that tunnels =
(MPLS,=20
  IPSEC,etc) could be used only in the backbone VR based configuration =
because=20
  otherwise the VRs have to be aware of the addresses and =
routes for=20
  the PEs (public)?

  
 

  
3. Will the VRs send labelled packets =
to the=20
  backbone VR? If so will there be any signaling (may be some =
registration)=20
  between the VRs and backbone VR?

  
 

  
4. =
Is=20
  it right to say that one VR can participate in only one VPN? (i =
did not=20
  find details on multiple VPN support per VR)

  
 

  
 

  
Can somebody clear my =
doubts?

  
Please pardon me if these questions =
have already=20
  been discussed.

  
 

  
Thanks in advance

  
 

  
Malick


------=_NextPart_000_0042_01C0FE4B.FFEE8D40--



From owner-mpls@UU.NET  Tue Jun 26 09:25:35 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03263
	for ; Tue, 26 Jun 2001 09:25:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvbx11016;
	Tue, 26 Jun 2001 13:22:58 GMT
Received: by mail-control.mail.uu.net 
	id QQkvbx03404
	for mpls-outgoing; Tue, 26 Jun 2001 13:22:27 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvbx03376
	for ; Tue, 26 Jun 2001 13:22:08 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 QQkvbx05116
	for ; Tue, 26 Jun 2001 13:21:08 GMT
Received: from zcars0m9.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	id QQkvbx18292
	for ; Tue, 26 Jun 2001 13:21:08 GMT
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5QDKs015818
	for ; Tue, 26 Jun 2001 09:20:54 -0400 (EDT)
Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 26 Jun 2001 09:20:38 -0400
Received: from zcard04k.ca.nortel.com ([47.129.242.84]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id N4CTABJC; Tue, 26 Jun 2001 09:20:41 -0400
Received: from newcomputer (acart16n.ca.nortel.com [47.129.9.84]) 
          by zcard04k.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id KZYPZCMM; Tue, 26 Jun 2001 09:20:39 -0400
From: "Hamid Ould-Brahim" 
To: Abdul Malick 
Cc: mpls 
Subject: RE: Doubts regarding VR based VPNs
Date: Tue, 26 Jun 2001 09:19:07 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_001F_01C0FE21.0CE3B780"
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.00.2314.1300
In-Reply-To: <004501c0fe1d$e75b4940$0b07080a@future.futsoft.com>
Importance: Normal
X-Orig: 
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C0FE21.0CE3B780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Malick,

See my comments inline.

    After reading draft-ouldbrahim-vpn-vr-03.txt and other materials on VR
based NBVPN i get the following doubts:

    1. Is it right to say that if we want to use piggy-backing for VPN
information discovery, the backbone VR configuration is a must (because PEs
have to be contacted by Public address which need not be visible to the
VRs).

    Not necessarily, if the PE is playing the role of the backbone VR that
    should be enough. The idea is the tunnel information has to be build
    using addresses within the service provider addressing space.

    2. Is it right to say that tunnels (MPLS, IPSEC,etc) could be used only
in the backbone VR based configuration because otherwise the VRs have to be
aware of the addresses and routes for the PEs (public)?

    Same thing here. VR can know (if needed) the addresses outside the VPN
space (because they are after all routers). With respect to MPLS,
    MPLS can be used as a tunneling within the backbone or even
    at the VR level. Assuming some form of label distribution occurs
    per VPN basis (per VR).

    3. Will the VRs send labelled packets to the backbone VR? If so will
there be any signaling (may be some registration) between the VRs and
backbone VR?

    Yes. They can as I said. On the registration aspects, you can
    always make the VR and backbone VR known to each other. These
    are actually implementation choices.

    4. Is it right to say that one VR can participate in only one VPN? (i
did not find details on multiple VPN support per VR)

    We assumed in the draft that only one VR per VPN is needed. Multiple
    VPN support per VR can be achieved in the case of extranets. No need
    for a third VR which contains both routes of the other two VRs.
    Remember VR is per VPN basis (not per site). Two VRs on different
    VPNs can inject themselves routes to each other and use normal
firewalling mechanisms.

    Can somebody clear my doubts?
    Please pardon me if these questions have already been discussed.

    Thanks in advance

    Malick

    Hope this help.

    Hamid

------=_NextPart_000_001F_01C0FE21.0CE3B780
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Malick,


 


See my comments inline.


  
    
 

    
After reading =
draft-ouldbrahim-vpn-vr-03.txt=20
    and other materials on VR based NBVPN i get the following=20
    doubts:

    
 

    
1. Is it right to say that if we =
want to use=20
    piggy-backing for VPN information discovery, the backbone VR =
configuration=20
    is a must (because PEs have to be contacted by Public address =
which=20
    need not be visible to the VRs).

    
 

    
Not necessarily, if the PE is playing the =
role of=20
    the backbone VR that

    
should be enough. The idea is the tunnel=20
    information has to be build

    
using addresses within the service =
provider=20
    addressing space.

    
 

    
2. Is it right to say that =
tunnels (MPLS,=20
    IPSEC,etc) could be used only in the backbone VR based configuration =
because=20
    otherwise the VRs have to be aware of the addresses and =
routes for=20
    the PEs (public)? 

    
 

    
Same thing =
here. VR=20
    can know (if needed) the addresses outside the VPN=20
    space=20
    (because they are after all routers). With respect to=20
    MPLS,

    
MPLS can be used as a tunneling within =
the backbone=20
    or even

    
at the VR level. Assuming some form of =
label=20
    distribution occurs

    
per VPN basis (per =
VR).

    
 

    
3. Will the VRs send labelled =
packets to=20
    the backbone VR? If so will there be any signaling (may be some=20
    registration) between the VRs and backbone VR? 

    
 

    
Yes. They can =
as I=20
    said. On the registration aspects,=20
    you can=20
    

    
always make the VR and backbone VR known =
to each=20
    other. These

    
are actually implementation=20
    choices.

    
 

    
4. Is=20
    it right to say that one VR can participate in only one VPN? (i =
did not=20
    find details on multiple VPN support per VR)

    
 

    
We assumed in the draft that only one VR =
per VPN is=20
    needed. Multiple

    
VPN support per VR can be achieved in the =
case of=20
    extranets. No need

    
for a third VR which contains both routes =
of the=20
    other two VRs.

    
Remember VR is per VPN basis (not per=20
    site). Two VRs on different

    
VPNs can inject themselves routes to each =

    other and use normal firewalling=20
    mechanisms.

    
 

    
Can somebody clear my =
doubts?

    
Please pardon me if these questions =
have=20
    already been discussed.

    
 

    
Thanks in advance

    
 

    
Malick 

    
 

    
Hope this=20
    help.

    
 

    
Hamid 


------=_NextPart_000_001F_01C0FE21.0CE3B780--



From owner-mpls@UU.NET  Tue Jun 26 21:04:58 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02663
	for ; Tue, 26 Jun 2001 21:04:57 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvds19974;
	Wed, 27 Jun 2001 01:04:37 GMT
Received: by mail-control.mail.uu.net 
	id QQkvds03798
	for mpls-outgoing; Wed, 27 Jun 2001 01:04:05 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvds03344
	for ; Wed, 27 Jun 2001 01:03: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 QQkvds15557
	for ; Wed, 27 Jun 2001 01:02:11 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f237.law11.hotmail.com [64.4.17.237])
	id QQkvds08782
	for ; Wed, 27 Jun 2001 01:02:11 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 26 Jun 2001 18:02:05 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Wed, 27 Jun 2001 01:02:05 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" 
To: mpls@UU.NET
Subject: MIBs for GMPLS
Date: Tue, 26 Jun 2001 21:02:05 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 27 Jun 2001 01:02:05.0335 (UTC) FILETIME=[C8348270:01C0FEA4]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,
In order to use the MIB defined by the draft 
draft-nadeau-mpls-gmpls-te-mib-00.txt a MIB similar
to RFC 1850 OSPF-v2 MIB with extensions derived from
ideas given in the following drafts
draft-kompella-ospf-gmpls-extensions-01.txt
AND/OR
draft-kompella-isis-gmpls-extensions-02.txt
AND/OR
draft-katz-yeung-ospf-traffic-05.txt
AND/OR
draft-srisuresh-ospf-te-00.txt
AND/OR others ....
may be required to exchange topology data with the management
interface. This data can then be used by the administrator to
setup TE-tunnels.

I have the following two questions,

1. Whether such a MIB is being written/developed?

2.  If yes, which draft(s) is being used as a base and
    when is it likely to be available.

2a. If no,which draft is the most likely candidate to be used
    for drafting a MIB like, say, gmpls-ospf-te-mib.txt

Appreciate your guidance.

If this is not the forum, I would like to find an interest
group to discuss this subject.

Thanks
Irfan Lateef
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mpls@UU.NET  Tue Jun 26 22:53:11 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09659
	for ; Tue, 26 Jun 2001 22:53:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvdz05660;
	Wed, 27 Jun 2001 02:53:05 GMT
Received: by mail-control.mail.uu.net 
	id QQkvdz17603
	for mpls-outgoing; Wed, 27 Jun 2001 02:52:34 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvdz17592
	for ; Wed, 27 Jun 2001 02:52:31 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 QQkvdz18948
	for ; Wed, 27 Jun 2001 02:52:08 GMT
Received: from MAIL-CLUSTER.calynet.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.104.246.2])
	id QQkvdz05423
	for ; Wed, 27 Jun 2001 02:52:08 GMT
Received: by mail-cluster.calynet.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 19:48:50 -0700
Message-ID: <636C2D109E6CD3119C3600062905FE8F8C7F21@mail-cluster.calynet.com>
From: Bernard Zelmans 
To: mpls@UU.NET
Subject: L2 MPLS based VPN
Date: Tue, 26 Jun 2001 19:48:46 -0700
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

Hi all,

looking at both Martini and Kompella draft on L2 based VPN, the LSP with the
inner+outer label is started from the same node (PE). Is there a particular
reason for that? why don't we allow an access device to initiate the inner
label LSP and have an aggregation device start the tunnel?
Thanks in advance,

b



From owner-mpls@UU.NET  Wed Jun 27 00:16:19 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13093
	for ; Wed, 27 Jun 2001 00:16:19 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvef25399;
	Wed, 27 Jun 2001 04:16:19 GMT
Received: by mail-control.mail.uu.net 
	id QQkvef05774
	for mpls-outgoing; Wed, 27 Jun 2001 04:15:37 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvef05748
	for ; Wed, 27 Jun 2001 04:15:28 GMT
Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkvee08078
	for ; Wed, 27 Jun 2001 04:14:46 GMT
Received: from web11708.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: web11708.mail.yahoo.com [216.136.172.74])
	id QQkvee24937
	for ; Wed, 27 Jun 2001 04:14:46 GMT
Message-ID: <20010627041446.36982.qmail@web11708.mail.yahoo.com>
Received: from [24.12.61.77] by web11708.mail.yahoo.com; Tue, 26 Jun 2001 21:14:46 PDT
Date: Tue, 26 Jun 2001 21:14:46 -0700 (PDT)
From: vola ray 
Subject: Re: L2 MPLS based VPN
To: Bernard Zelmans , mpls@UU.NET
In-Reply-To: <636C2D109E6CD3119C3600062905FE8F8C7F21@mail-cluster.calynet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-mpls@UU.NET
Precedence: bulk

bernard,
This seems EASIER to Implement and Manage for Any Aggregation Issues,
such as Open up a Fat VoIP Tunnel from a  PE Router and pass all VoIP
calls from the CE Routers over it. 
vola

--- Bernard Zelmans  wrote:
> Hi all,
> 
> looking at both Martini and Kompella draft on L2 based VPN, the LSP with the
> inner+outer label is started from the same node (PE). Is there a particular
> reason for that? why don't we allow an access device to initiate the inner
> label LSP and have an aggregation device start the tunnel?
> Thanks in advance,
> 
> b
> 


=====
__________________________________________________________
karmany evadhikaraste ma phaleshu kadachan 
[U are Entitled to Your Duty (Karma) Only, 
 Never to its Result]
                  -- 5000+ years old Gita 2:46

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/


From owner-mpls@UU.NET  Wed Jun 27 03:45:12 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05645
	for ; Wed, 27 Jun 2001 03:45:11 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkves14989;
	Wed, 27 Jun 2001 07:43:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkves28080
	for mpls-outgoing; Wed, 27 Jun 2001 07:43:12 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkves28072
	for ; Wed, 27 Jun 2001 07:43:08 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 QQkves10073
	for ; Wed, 27 Jun 2001 07:36:16 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkves20006
	for ; Wed, 27 Jun 2001 07:36:15 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA10449 for mpls@uu.net; Wed, 27 Jun 2001 03:36:15 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkves26699
	for ; Wed, 27 Jun 2001 07:35: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 QQkves13292
	for ; Wed, 27 Jun 2001 07:35:09 GMT
Received: from anti_vir1.rad.co.il by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: radmail.rad.co.il [207.232.32.10])
	id QQkves08075
	for ; Wed, 27 Jun 2001 07:35:07 GMT
Received: from anti_vir1.rad.co.il (localhost [127.0.0.1])
	by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5R8ZXF10719
	for ; Wed, 27 Jun 2001 10:35:33 +0200 (IST)
Received: from radmail.rad.co.il (radmail [192.114.24.30])
	by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5R8ZWr10708;
	Wed, 27 Jun 2001 10:35:32 +0200 (IST)
Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il
          (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35)
          with ESMTP id il; Wed, 27 Jun 2001 10:36:28 +0300
Received: by TLV1 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 10:33:51 +0200
Message-ID: 
From: Sasha Vainshtein 
To: "'Bernard Zelmans'" , mpls@UU.NET
Cc: Alik Shimelmits , Gonen Zilber ,
        Israel Sasson 
Subject: RE: L2 MPLS based VPN
Date: Wed, 27 Jun 2001 10:33:50 +0200
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

Bernard,
Inner labels in both Martiti-Transport and Kompella L2 VPN drafts 
are distributed directly between peer edge devices, and have meaning
only between these devices. Both Martini and Kompella drafts allow using
targeted LDP sessions for this purpose, and Kompella also allows using
MP-BGP for this purpose.
For the aggregation device to allocate the outer label, it has to be able
to infer somehow the FEC of the incoming packet.
I see the following options for the packet transmitted by the access device
to the aggregation one:
1. It is a label packet with the outer label in the stack being the inner
label
of the virtual connection. This label cannot be valid in the aggregation
device
(as it did not participate in its distribution) so it either drops the
packet or, even
worse, misuses it.
2. It is an IP packet (say, with MPLS-in-IP protocol type and 
the inner label following the IP header). In this case the access device:
* Has to operate as an IP router
* Has to know IP address of its remote peer device
* The aggregation device may push the "outer" label on top of IP header
or just to forward the unlabeled
*The remote access device must recognize the incoming IP packet as 
one carying MPLS-in-IP, strip its IP header and then process the incoming
label.
I.e., the 2nd option will work, but it imposes restrictions on access
devices. E.g.,
you cannot connect Ethernet switches (which are not IP routers) in this way.
PE devices in both Martini and Kompella are assumed to be LERs (as defined
in RFC 3031)
with additional capabilities allowing support of encapsulation of L2
packets; this approach
does not impose any restrictions on the access (presumably, CPE) devices.
With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com  
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
 


> -----Original Message-----
> From: Bernard Zelmans [mailto:bzelmans@calynet.com]
> Sent: Wednesday, June 27, 2001 4:49 AM
> To: mpls@UU.NET
> Subject: L2 MPLS based VPN
> 
> 
> Hi all,
> 
> looking at both Martini and Kompella draft on L2 based VPN, 
> the LSP with the
> inner+outer label is started from the same node (PE). Is 
> there a particular
> reason for that? why don't we allow an access device to 
> initiate the inner
> label LSP and have an aggregation device start the tunnel?
> Thanks in advance,
> 
> b
> 



From owner-mpls@UU.NET  Wed Jun 27 09:21:02 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23560
	for ; Wed, 27 Jun 2001 09:21:01 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvfp24639;
	Wed, 27 Jun 2001 13:18:32 GMT
Received: by mail-control.mail.uu.net 
	id QQkvfp01774
	for mpls-outgoing; Wed, 27 Jun 2001 13:17:59 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvfp01766
	for ; Wed, 27 Jun 2001 13:17:45 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkvfo05517
	for ; Wed, 27 Jun 2001 13:14:05 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkvfo22471
	for ; Wed, 27 Jun 2001 13:14:04 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA20287 for mpls@uu.net; Wed, 27 Jun 2001 09:14:04 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvfo00869
	for ; Wed, 27 Jun 2001 13:13:21 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 QQkvfo03181
	for ; Wed, 27 Jun 2001 13:12:22 GMT
Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQkvfo09255
	for ; Wed, 27 Jun 2001 13:12:21 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09763; Wed, 27 Jun 2001 09:12:21 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABU00253;
	Wed, 27 Jun 2001 09:12:19 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010627091405.030a2518@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 27 Jun 2001 09:15:44 -0400
To: "Irfan Lateef" , mpls@UU.NET
From: "Thomas D. Nadeau" 
Subject: Re: MIBs for GMPLS
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk


         Hi,

>In order to use the MIB defined by the draft 
>draft-nadeau-mpls-gmpls-te-mib-00.txt a MIB similar
>to RFC 1850 OSPF-v2 MIB with extensions derived from
>ideas given in the following drafts
>draft-kompella-ospf-gmpls-extensions-01.txt
>AND/OR
>draft-kompella-isis-gmpls-extensions-02.txt
>AND/OR
>draft-katz-yeung-ospf-traffic-05.txt
>AND/OR
>draft-srisuresh-ospf-te-00.txt
>AND/OR others ....
>may be required to exchange topology data with the management
>interface. This data can then be used by the administrator to
>setup TE-tunnels.

         I don't think that this is necessary for GMPLS-TE
tunnels to be set up. The aforementioned drafts are
necessary insofar as to facilitate the exchange
of that information. That is, that functionality
must be supported by the devices in the GMPLS
network.

>I have the following two questions,
>
>1. Whether such a MIB is being written/developed?

         Yes, GMPLS-TE-MIB.

         --Tom




>2.  If yes, which draft(s) is being used as a base and
>    when is it likely to be available.
>
>2a. If no,which draft is the most likely candidate to be used
>    for drafting a MIB like, say, gmpls-ospf-te-mib.txt
>
>Appreciate your guidance.
>
>If this is not the forum, I would like to find an interest
>group to discuss this subject.
>
>Thanks
>Irfan Lateef
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mpls@UU.NET  Wed Jun 27 09:26:12 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27061
	for ; Wed, 27 Jun 2001 09:26:12 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvfp00958;
	Wed, 27 Jun 2001 13:22:45 GMT
Received: by mail-control.mail.uu.net 
	id QQkvfp02977
	for mpls-outgoing; Wed, 27 Jun 2001 13:22:11 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvfp02942
	for ; Wed, 27 Jun 2001 13:22:01 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 QQkvfp18992
	for ; Wed, 27 Jun 2001 13:20:55 GMT
Received: from charon.s3group.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ns.s3group.com [193.120.90.3])
	id QQkvfp26370
	for ; Wed, 27 Jun 2001 13:20:54 GMT
Received: from headyin.s3group.com ([193.120.89.200])
	by charon.s3group.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00509;
	Wed, 27 Jun 2001 14:20:50 +0100 (BST)
Received: from s3group.com ([193.120.89.113])
 by headyin.s3group.com (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8)
 with ESMTP id <0GFL00INHBQZ86@headyin.s3group.com>; Wed,
 27 Jun 2001 14:20:59 +0100 (BST)
Date: Wed, 27 Jun 2001 14:26:12 +0100
From: Paul Mannion 
Subject: Q RE N-POPS Value in LSR MIB
To: "mpls@UU.NET" , mpls-ops@mplsrc.com
Message-id: <3B39DEF4.8987620B@s3group.com>
Organization: Comms Infrastructure
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_2UJRRc7LhRYlQVHpwv/nyQ)"
X-Accept-Language: en,en-GB
Sender: owner-mpls@UU.NET
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_2UJRRc7LhRYlQVHpwv/nyQ)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
    Sorry if this has been answered already.

    I'm a little confused as to how the N-POP value in the LSR
    MIB is used in practice.

    i.e. if the N-POPS is > 1, say 2, which of the following is the
    correct behaviour assuming an incoming label stack size of 3.

    1] Pop 2 labels and lookup and forward according to the remaining
         label.

    2] Perform a lookup using each label before it is "popped", if this
        is the case i'm not sure what use the N-POP value is as the
action
        is specified by the lookup result in each case.

        thanks in advance
Paul



--Boundary_(ID_2UJRRc7LhRYlQVHpwv/nyQ)
Content-type: text/x-vcard; name=Paul.Mannion.vcf; charset=us-ascii
Content-description: Card for Paul Mannion
Content-disposition: attachment; filename=Paul.Mannion.vcf
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Mannion;Paul
tel;work:353-1-2078766
x-mozilla-html:FALSE
org:Silicon and Software Systems;Communications Infrastructure
version:2.1
email;internet:Paul.Mannion@s3group.com
title:Software Engineer
adr;quoted-printable:;;Sandyford Ind Estate,=0D=0ALeopardstown;Dublin;;;Ireland
fn:Paul Mannion
end:vcard

--Boundary_(ID_2UJRRc7LhRYlQVHpwv/nyQ)--


From owner-mpls@UU.NET  Wed Jun 27 09:57:25 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16955
	for ; Wed, 27 Jun 2001 09:57:24 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvfr23075;
	Wed, 27 Jun 2001 13:55:14 GMT
Received: by mail-control.mail.uu.net 
	id QQkvfr08967
	for mpls-outgoing; Wed, 27 Jun 2001 13:54:41 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvfr08953
	for ; Wed, 27 Jun 2001 13:54:25 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 QQkvfr00353
	for ; Wed, 27 Jun 2001 13:53:12 GMT
Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkvfr12548
	for ; Wed, 27 Jun 2001 13:53:12 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA23378 for mpls@uu.net; Wed, 27 Jun 2001 09:53:12 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvfr08454
	for ; Wed, 27 Jun 2001 13:48:58 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 QQkvfr23821
	for ; Wed, 27 Jun 2001 13:47:48 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 QQkvfr08020
	for ; Wed, 27 Jun 2001 13:47:48 GMT
Received: (qmail 1845 invoked by uid 104); 27 Jun 2001 13:47:47 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.420549 secs); 27/06/2001 06:47:47
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by father.pmc-sierra.bc.ca with SMTP; 27 Jun 2001 13:47:47 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5RDlke17394;
	Wed, 27 Jun 2001 06:47:46 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 06:52:07 -0700
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D2D@BBY1EXM01>
From: Shahram Davari 
To: "'Paul Mannion'" , mpls@UU.NET,
        mpls-ops@mplsrc.com
Subject: RE: Q RE N-POPS Value in LSR MIB
Date: Wed, 27 Jun 2001 06:52:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi,

This question has been asked a number of times. If you read the LSR-MIB carefully it seems that a swap is modeled as a pop followed by a push. Therefore if you want to terminate an LSP and you know for sure that all the traffics inside that LSP are MPLS traffic, then setting N-POPs =2 and mplsOutSegmentPushTopLabel= true(1), will pop the top label and swap the lower ones.

However, it seems that there is no use for N-POPs >2, because as you said, an LSR needs to look at the lower labels to decide whether to terminate them or not.

Yours,
-Shahram 

> -----Original Message-----
> From: Paul Mannion [mailto:Paul.Mannion@s3group.com]
> Sent: Wednesday, June 27, 2001 9:26 AM
> To: mpls@UU.NET; mpls-ops@mplsrc.com
> Subject: Q RE N-POPS Value in LSR MIB
> 
> 
> Hi,
>     Sorry if this has been answered already.
> 
>     I'm a little confused as to how the N-POP value in the LSR
>     MIB is used in practice.
> 
>     i.e. if the N-POPS is > 1, say 2, which of the following is the
>     correct behaviour assuming an incoming label stack size of 3.
> 
>     1] Pop 2 labels and lookup and forward according to the remaining
>          label.
> 
>     2] Perform a lookup using each label before it is 
> "popped", if this
>         is the case i'm not sure what use the N-POP value is as the
> action
>         is specified by the lookup result in each case.
> 
>         thanks in advance
> Paul
> 
> 
> 



From owner-mpls@UU.NET  Wed Jun 27 12:26:44 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09864
	for ; Wed, 27 Jun 2001 12:26:43 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvgb06952;
	Wed, 27 Jun 2001 16:24:14 GMT
Received: by mail-control.mail.uu.net 
	id QQkvgb22998
	for mpls-outgoing; Wed, 27 Jun 2001 16:23:43 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvgb22990
	for ; Wed, 27 Jun 2001 16:23:33 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkvgb17718
	for ; Wed, 27 Jun 2001 16:19: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 QQkvgb29656
	for ; Wed, 27 Jun 2001 16:19:31 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 MAA26848
	for ; Wed, 27 Jun 2001 12:19:29 -0400 (EDT)
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 MAA07855
	for ; Wed, 27 Jun 2001 12:19:30 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 27 Jun 2001 12:19:30 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF042F7EBA@whq-msgusr-02.pit.comms.marconi.com>
From: "Choudhury, Sanjaya" 
To: mpls@UU.NET
Subject: Per-Connection policing vs Aggregate policing -In the L-LSP/E-LSP
	 context
Date: Wed, 27 Jun 2001 12:19:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

		
	Hi! I have few questions related to policing L-LSPs 
	and E-LSPs. Your help will be appreciated.

	Q1. For L-LSP one has multiple options for policing the 
	incoming traffic.
		a) per-connection policing based on the signaled
		traffic parameters.
		b) aggregate policing control by the PSC it is 
		carrying (based on the parameters configured
		for the PSC)
		c) both

	Although the choice depends on the hardware capability,
	is there a typical standard ? typical user requirement ?
	are any of these choices violate any existing drafts/standards?

	Q2. The case for E-LSP is more confusing. 
	      
	       Class-Type Model: As mentioned in the diff-te related
	       drafts, only one set of traffic parameters is signaled
	       during the connection setup. In such a case, 
		a) per-connection policing based on the signaled
		parameter 
		b) aggregate policing based on the configured per
		PSC parameters -different flows might get policed
		differently based on the EXP.
		c) both -?
		
	       Traffic Parameters for each PSC: This is based on the 
	       E-LSP draft that was posted few months back (I am
	       not sure of the current status of the draft).
		a) per-connection policing -not possible ?
		b) aggregate policing 
			-either based on the configured per-PSC
			parameters
			-or based on the signaled per-PSC 
			traffic parameters
		c)both -?
	Although the choice depends on the hardware capability,
	is there a typical standard ? typical user requirement ?
	are any of these choices violate any existing drafts/standards?
	

	Thanks,
	sanjay

	

		
			
	
	
	


From owner-mpls@UU.NET  Wed Jun 27 13:14:22 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24935
	for ; Wed, 27 Jun 2001 13:14:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvge26857;
	Wed, 27 Jun 2001 17:10:28 GMT
Received: by mail-control.mail.uu.net 
	id QQkvge16535
	for mpls-outgoing; Wed, 27 Jun 2001 17:09:51 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvge16504
	for ; Wed, 27 Jun 2001 17:09:42 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 QQkvge13523
	for ; Wed, 27 Jun 2001 17:09:34 GMT
From: francis.arts@alcatel.be
Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc119.alcatel.be [195.207.101.119])
	id QQkvge26122
	for ; Wed, 27 Jun 2001 17:09:34 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f5RH9WC00408
	for ; Wed, 27 Jun 2001 19:09:33 +0200 (MET DST)
Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256A78.005E4090 ; Wed, 27 Jun 2001 19:09:29 +0200
X-Lotus-FromDomain: ALCATEL
To: mpls@UU.NET
Message-ID: 
Date: Wed, 27 Jun 2001 19:09:26 +0200
Subject: MPLSCP
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk




Hello,

Looking into section 4.2 of RFC 3032, I find that the MPLS CP protocol has value '0x8281'.

However, the list on the IANA homepage indicates the following:
* 8281            Tag Switching - Unicast                         [Davie]
* 8283            Tag Switching - Multicast                       [Davie]

I have 2 questions:

1/ Does the use 'tag switching - unicast' on the IANA homepage indeed correspond
to the use for MPLSCP as intended in RFC 3032?

2/ Is the value '8283' as specified on the IANA homepage, not meant to be used for
MPLS at all (since only 1 NCP -MPLS CP- is used for both unicast and multicast MPLS traffic)?




Regards,

     Francis.




From owner-mpls@UU.NET  Wed Jun 27 13:39:01 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07031
	for ; Wed, 27 Jun 2001 13:39:00 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvgg13197;
	Wed, 27 Jun 2001 17:32:47 GMT
Received: by mail-control.mail.uu.net 
	id QQkvgg19023
	for mpls-outgoing; Wed, 27 Jun 2001 17:32:16 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvgg18986
	for ; Wed, 27 Jun 2001 17:31: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 QQkvgf28754
	for ; Wed, 27 Jun 2001 17:29:08 GMT
Received: from mail.tropicnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gw.tropicnetworks.com [209.87.233.9])
	id QQkvgf10401
	for ; Wed, 27 Jun 2001 17:29:08 GMT
Received: from tropicnetworks.com ([10.1.2.208]) by mail.tropicnetworks.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA1408;
          Wed, 27 Jun 2001 13:29:18 -0400
Message-ID: <3B3A14FE.1FA277BF@tropicnetworks.com>
Date: Wed, 27 Jun 2001 13:16:46 -0400
From: Nabil Seddigh 
Organization: Tropic Networks
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Choudhury, Sanjaya" 
CC: mpls@UU.NET
Subject: Re: Per-Connection policing vs Aggregate policing -In the 
 L-LSP/E-LSPcontext
References: <4FBEA8857476D311A03300204840E1CF042F7EBA@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Two thoughts on per-connection vs per-aggregate policing:

1. I would assume that the reason anyone would use E-LSP would
   be to take advantage of the Diffserv architecture - this 
   implies no per-connection policing or scheduling 
   treatment at the LSRs. Otherwise, you might as well use L-LSP.

2. Though each LSR may treat E-LSPs as Diffserv aggregates, 
   it is still possible to perform per-connection admission 
   control on each aggregate within an E-LSP. 

>         Hi! I have few questions related to policing L-LSPs
>         and E-LSPs. Your help will be appreciated.
> 

---
Best, 
Nabil Seddigh
nseddigh@tropicnetworks.com


From owner-mpls@UU.NET  Wed Jun 27 15:13:08 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03901
	for ; Wed, 27 Jun 2001 15:13:07 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvgm10941;
	Wed, 27 Jun 2001 19:11:22 GMT
Received: by mail-control.mail.uu.net 
	id QQkvgm12872
	for mpls-outgoing; Wed, 27 Jun 2001 19:10:44 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvgm12783
	for ; Wed, 27 Jun 2001 19:10:34 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 QQkvgm20085
	for ; Wed, 27 Jun 2001 19:08:45 GMT
Received: from cerberus.oware.net by cmr1.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: 40327021.ptr.dia.nextlink.net [64.50.112.33])
	id QQkvgm08252
	for ; Wed, 27 Jun 2001 19:08:45 GMT
Received: (qmail 10171 invoked from network); 27 Jun 2001 18:14:48 -0000
Received: from 40327002.ptr.dia.nextlink.net (HELO eureka) (64.50.112.2)
  by 40327021.ptr.dia.nextlink.net with SMTP; 27 Jun 2001 18:14:48 -0000
From: "Bala Subrahmanyam Venkata" 
To: 
Subject: VPN of Origin attribute
Date: Wed, 27 Jun 2001 12:17:36 -0700
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.00.2314.1300
Importance: Normal
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

All-

Is there a reason why RFC 2547bis draft does not refer to the "VPN of
Origin" attribute at all ? (I am not clear as to how this attribute is
different from "Site of Origin" attribute as defined in RFC 2547).


TIA

/bala




From owner-mpls@UU.NET  Wed Jun 27 16:32:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10314
	for ; Wed, 27 Jun 2001 16:32:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvgs16715;
	Wed, 27 Jun 2001 20:30:25 GMT
Received: by mail-control.mail.uu.net 
	id QQkvgr11924
	for mpls-outgoing; Wed, 27 Jun 2001 20:29:53 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvgr11885
	for ; Wed, 27 Jun 2001 20:29: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 QQkvgr18598
	for ; Wed, 27 Jun 2001 20:29:18 GMT
Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkvgr17976
	for ; Wed, 27 Jun 2001 20:29:17 GMT
Message-ID: <3B3A4219.5DB47D21@sandburst.com>
Date: Wed, 27 Jun 2001 16:29:13 -0400
From: Eric Gray 
MIME-Version: 1.0
To: francis.arts@alcatel.be
Cc: mpls@UU.NET
Subject: Re: MPLSCP
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Francis,

    I had asked a very much related question (twice - see below) in E-Mail
dating back to the middle of May.  I am somewhat disturbed that I have not
yet received any sort of reply.

    Perhaps you will be luckier.

--
Eric Gray

You wrote:

> Hello,
>
> Looking into section 4.2 of RFC 3032, I find that the MPLS CP protocol has value '0x8281'.
>
> However, the list on the IANA homepage indicates the following:
> * 8281            Tag Switching - Unicast                         [Davie]
> * 8283            Tag Switching - Multicast                       [Davie]
>
> I have 2 questions:
>
> 1/ Does the use 'tag switching - unicast' on the IANA homepage indeed correspond
> to the use for MPLSCP as intended in RFC 3032?
>
> 2/ Is the value '8283' as specified on the IANA homepage, not meant to be used for
> MPLS at all (since only 1 NCP -MPLS CP- is used for both unicast and multicast MPLS traffic)?
>
> Regards,
>
>      Francis.

Message 1
=========

>    Subject: Re: PPP protocol type for MPLS packets ...
>       Date: Tue, 15 May 2001 13:01:29 -0400
>       From: Eric Gray
>         To: Elwin Eliazer, Eric Rosen, George Swallow,
>            Scott Bradner
>         CC: mpls@UU.NET, naveenietf@yahoo.com
>
>
>> Elwin,
>>
>>     Quoting from Standard 51 (PPP), section 6.5 towards the bottom of
>> page 48:
>>
>> "The Protocol field is never compressed when sending any LCP packet.
>>  This rule guarantees unambiguous recognition of LCP packets."
>>
>> ====================================================================
>> Eric/George/Scott,
>>
>> On a related issue, I notice that - while RFC 3032 lists the MPLSCP
>> protocol number as 0x8281 - PPP-numbers, located at:
>>
>>     ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers
>>
>> Shows this number assigned as follows -
>>
>> "8281   Tag Switching - Unicast              [Davie]"
>>
>> I can't recall any discussion about re-assigning this protocol number
>> and I wonder - is possible at this point to make this happen (between
>> B. Davie, Cisco and IANA)?
>>
>> --
>> Eric Gray
>>
>> You wrote:
>>
>> > Hi,
>> >
>> > Will it be a good practice to disable protocol
>> > field compression (during LCP) as the PPP protocol
>> > field value for MPLS unicast and multicast are
>> > 0x0281 and 0x0283, as defined in RFC 3032,
>> > section 4.3, that has the most significant
>> > byte as non-zero?
>> >
>> > regards,
>> > Elwin.
>> >
>> > =====
>> > -------
>> > Elwin Stelzer Eliazer
>> > Corona Networks
>> > San Jose, CA
>> > 408-519-3832
>> > -------
>> >
>> > __________________________________________________
>> > Do You Yahoo!?
>> > Yahoo! Auctions - buy the things you want at great prices
>> > http://auctions.yahoo.com/
>>

Message 2
=========

>>
>>
> Subject: Earlier mail
>    Date: Wed, 23 May 2001 15:54:15 -0400
>    From: Eric Gray
>     To: George Swallow, Eric Rosen, Scott Bradner
>
>
>
>
> Eric/George/Scott,
>
>     Earlier I sent you guys a question, to which I have not
> yet received a reply of any sort.  On looking into it, I saw
> that I had embedded it in a reply to someone else - and
> you probably missed it.
>
>     My question was:
>
> I notice that - while RFC 3032 lists the MPLSCP
> protocol number as 0x8281 - PPP-numbers, located at:
>
>     ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers
>
> Shows this number assigned as follows -
>
> "8281   Tag Switching - Unicast              [Davie]"
>
> I can't recall any discussion about re-assigning this protocol number
> and I wonder - is possible at this point to make this happen (between
> B. Davie, Cisco and IANA)?
>
> --
> Eric Gray
>
>



From owner-mpls@UU.NET  Wed Jun 27 17:34:51 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22671
	for ; Wed, 27 Jun 2001 17:34:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvgw11565;
	Wed, 27 Jun 2001 21:30:41 GMT
Received: by mail-control.mail.uu.net 
	id QQkvgw08225
	for mpls-outgoing; Wed, 27 Jun 2001 21:30:06 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvgv08172
	for ; Wed, 27 Jun 2001 21:29:59 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkvgv08323
	for ; Wed, 27 Jun 2001 21:29:08 GMT
Received: from mail-out.globalone.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-out.globalone.net [199.184.38.11])
	id QQkvgv15364
	for ; Wed, 27 Jun 2001 21:29:08 GMT
Received: from avres1.globalone.net ([192.168.75.20])
	by mail-out.globalone.net (8.8.7/8.8.5) with ESMTP id RAA14819
	for ; Wed, 27 Jun 2001 17:29:07 -0400
Received: from master.res.globalone.net (unverified) by avres1.globalone.net
 (Content Technologies SMTPRS 4.1.5) with ESMTP id  for ;
 Wed, 27 Jun 2001 17:27:49 -0400
Received: from mail4.res.globalone.net (mail4.res.globalone.net [160.81.232.18] (may be forged))
	by master.res.globalone.net (8.8.7/8.8.5) with ESMTP id RAA14494
	for ; Wed, 27 Jun 2001 17:29:05 -0400
Received: from Globalone.net ([160.81.226.189]) by mail4.res.globalone.net
          (Netscape Messaging Server 3.62)  with ESMTP id 595;
          Wed, 27 Jun 2001 17:29:04 -0400
Message-ID: <3B3A5029.195FDED2@Globalone.net>
Date: Wed, 27 Jun 2001 17:29:13 -0400
From: "Franklin Lian" 
Reply-To: Franklin.Lian@globalone.net
Organization: Global One
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en,zh-CN,zh,zh-TW
MIME-Version: 1.0
To: Bala Subrahmanyam Venkata 
CC: mpls@UU.NET
Subject: Re: VPN of Origin attribute
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello, Bala

In RFC 2547, there are three BGP extended attributes speficied:

- Site of Origin
- VPN of Origin
- Target VPN

In practice, "Site of Origin" identifies from which site the route is
originated and the "Target VPN" is the Route-Target attribute.  In
section 4.2.3 of RFC2547, the VPN of origin is an optional attribute
that is used to identify a particular set of sites which may or may
not constitute a VPN.  I found that Cisco's implementation of VPN of
Origin is the Route-Distinguisher attribute of the route, however, I 
don't think RD is exact the "VPN of Origin" specified in RFC2547.

Personally I don't think the "VPN of Origin" is so necessary and it
does not hurt to take if off.

Hoep it will help
Franklin

Bala Subrahmanyam Venkata wrote:
> 
> All-
> 
> Is there a reason why RFC 2547bis draft does not refer to the "VPN of
> Origin" attribute at all ? (I am not clear as to how this attribute is
> different from "Site of Origin" attribute as defined in RFC 2547).
> 
> TIA
> 
> /bala


From owner-mpls@UU.NET  Wed Jun 27 17:35:13 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22971
	for ; Wed, 27 Jun 2001 17:35:13 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvgw17119;
	Wed, 27 Jun 2001 21:32:29 GMT
Received: by mail-control.mail.uu.net 
	id QQkvgw08530
	for mpls-outgoing; Wed, 27 Jun 2001 21:31:57 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvgw08512
	for ; Wed, 27 Jun 2001 21:31:46 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkvgw12329
	for ; Wed, 27 Jun 2001 21:31:18 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 QQkvgw16497
	for ; Wed, 27 Jun 2001 21:31:18 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 RAA29795;
	Wed, 27 Jun 2001 17:31:14 -0400 (EDT)
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 RAA21152;
	Wed, 27 Jun 2001 17:31:16 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 27 Jun 2001 17:31:16 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF01B0BC81@whq-msgusr-02.pit.comms.marconi.com>
From: "Punj, Arun" 
To: "'Bala Subrahmanyam Venkata'" , mpls@UU.NET
Subject: RE: VPN of Origin attribute
Date: Wed, 27 Jun 2001 17:31:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

Bala,

IMO the VPN Of origin is a superflous attribute in RFC2547. If you 
look at the example given in the RFC2547, section 4.2.4 page 13, 
for use of VPN of origin attribute, you will notice it can be simply
replaced by a VPN target attribute. 

The site of origin attribute has a different purpose altogather. It
is meant to prevent feeding of an address back into a site from which
it was learnt ( refer page 24 section 7 RFC2547bis ).

I hope it helps


Arun Punj
Office of CTO, Marconi Communications,
Ph  : 724-742-7583 - Web: www.marconi.com
1000 Fore Drive, Warrandale, PA - 15086



> -----Original Message-----
> From: Bala Subrahmanyam Venkata [mailto:bsubrahm@doradosoftware.com]
> Sent: Wednesday, June 27, 2001 3:18 PM
> To: mpls@UU.NET
> Subject: VPN of Origin attribute
> 
> 
> All-
> 
> Is there a reason why RFC 2547bis draft does not refer to the "VPN of
> Origin" attribute at all ? (I am not clear as to how this attribute is
> different from "Site of Origin" attribute as defined in RFC 2547).
> 
> 
> TIA
> 
> /bala
> 
> 


From owner-mpls@UU.NET  Wed Jun 27 19:56:06 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26707
	for ; Wed, 27 Jun 2001 19:56:05 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvhf24526;
	Wed, 27 Jun 2001 23:55:15 GMT
Received: by mail-control.mail.uu.net 
	id QQkvhf02396
	for mpls-outgoing; Wed, 27 Jun 2001 23:54:44 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvhf02382
	for ; Wed, 27 Jun 2001 23:54: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 QQkvhf24575
	for ; Wed, 27 Jun 2001 23:53:40 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f130.law11.hotmail.com [64.4.17.130])
	id QQkvhf03108
	for ; Wed, 27 Jun 2001 23:53:40 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 27 Jun 2001 16:53:39 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Wed, 27 Jun 2001 23:53:39 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" 
To: tnadeau@cisco.com, mpls@UU.NET
Subject: Re: MIBs for GMPLS
Date: Wed, 27 Jun 2001 19:53:39 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 27 Jun 2001 23:53:39.0391 (UTC) FILETIME=[6348ECF0:01C0FF64]
Sender: owner-mpls@UU.NET
Precedence: bulk

Tom,

I may be missing something here but let try to make it
more explicit using a hypothetical example.

Let us extend the example given in the draft
draft-nadeau-mpls-gmpls-te-mib-00.txt section.8 from two hops
to N hops and from loosely routed to explicitly routed and assume
that this has to be done automatically from a management application.

Further assume the application needs to find a list of ERHOPs
satisfying a condition like "find unprotected lambdas with OC-48
worth of bandwidth and setup an LSP  from A to B".


My understanding is, the information gathered by the extensions
specified in draft-kompella-ospf-gmpls-extensions-01.txt section.5
namely LinkProtectionType,LinkDescriptor (in fact most of the
sub-TLVs of TE-link TLV) may be necessary to do this.

I do not see this data incorporated in any MIB.

Now in the absence of such data, how can the management application
compute the explicit hops satisfying the criteria mentioned above.

If I am totally in the wrong direction would appreciate any pointers
in the right direction.

Thanks for your attention and appreciate your response.

Irfan Lateef




>From: "Thomas D. Nadeau" 
>To: "Irfan Lateef" , mpls@UU.NET
>Subject: Re: MIBs for GMPLS
>Date: Wed, 27 Jun 2001 09:15:44 -0400
>
>
>         Hi,
>
>>In order to use the MIB defined by the draft
>>draft-nadeau-mpls-gmpls-te-mib-00.txt a MIB similar
>>to RFC 1850 OSPF-v2 MIB with extensions derived from
>>ideas given in the following drafts
>>draft-kompella-ospf-gmpls-extensions-01.txt
>>AND/OR
>>draft-kompella-isis-gmpls-extensions-02.txt
>>AND/OR
>>draft-katz-yeung-ospf-traffic-05.txt
>>AND/OR
>>draft-srisuresh-ospf-te-00.txt
>>AND/OR others ....
>>may be required to exchange topology data with the management
>>interface. This data can then be used by the administrator to
>>setup TE-tunnels.
>
>         I don't think that this is necessary for GMPLS-TE
>tunnels to be set up. The aforementioned drafts are
>necessary insofar as to facilitate the exchange
>of that information. That is, that functionality
>must be supported by the devices in the GMPLS
>network.
>
>>I have the following two questions,
>>
>>1. Whether such a MIB is being written/developed?
>
>         Yes, GMPLS-TE-MIB.
>
>         --Tom
>
>
>
>
>>2.  If yes, which draft(s) is being used as a base and
>>    when is it likely to be available.
>>
>>2a. If no,which draft is the most likely candidate to be used
>>    for drafting a MIB like, say, gmpls-ospf-te-mib.txt
>>
>>Appreciate your guidance.
>>
>>If this is not the forum, I would like to find an interest
>>group to discuss this subject.
>>
>>Thanks
>>Irfan Lateef
>>_________________________________________________________________
>>Get your FREE download of MSN Explorer at http://explorer.msn.com
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mpls@UU.NET  Wed Jun 27 21:13:34 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20552
	for ; Wed, 27 Jun 2001 21:13:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvhk19810;
	Thu, 28 Jun 2001 01:13:18 GMT
Received: by mail-control.mail.uu.net 
	id QQkvhk19793
	for mpls-outgoing; Thu, 28 Jun 2001 01:12:37 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvhk19774
	for ; Thu, 28 Jun 2001 01:12:30 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 QQkvhk10897
	for ; Thu, 28 Jun 2001 01:12:24 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkvhk29198
	for ; Thu, 28 Jun 2001 01:12:24 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id VAA10476 for mpls@uu.net; Wed, 27 Jun 2001 21:12:24 -0400 (EDT)
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvhk19637
	for ; Thu, 28 Jun 2001 01:11:37 GMT
Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkvhk13998
	for ; Thu, 28 Jun 2001 01:09:07 GMT
Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: funnel.cisco.com [161.44.131.24])
	id QQkvhk14861
	for ; Thu, 28 Jun 2001 01:09:07 GMT
Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA01174; Wed, 27 Jun 2001 21:09:06 -0400 (EDT)
Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.83.99.123])
	by bucket.cisco.com (Mirapoint)
	with ESMTP id ABW00265;
	Wed, 27 Jun 2001 21:08:58 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010627205431.031a7548@bucket.cisco.com>
X-Sender: tnadeau@bucket.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 27 Jun 2001 21:12:21 -0400
To: "Irfan Lateef" , mpls@UU.NET
From: "Thomas D. Nadeau" 
Subject: Re: MIBs for GMPLS
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-mpls@UU.NET
Precedence: bulk

At 07:53 PM 6/27/2001 -0400, Irfan Lateef wrote:
>Tom,
>
>I may be missing something here but let try to make it
>more explicit using a hypothetical example.
>
>Let us extend the example given in the draft
>draft-nadeau-mpls-gmpls-te-mib-00.txt section.8 from two hops
>to N hops and from loosely routed to explicitly routed and assume
>that this has to be done automatically from a management application.
>
>Further assume the application needs to find a list of ERHOPs
>satisfying a condition like "find unprotected lambdas with OC-48
>worth of bandwidth and setup an LSP  from A to B".

         Then you go to LSR A and specify the tunnel bandwidth to
be that of an OC-48 link and specify B as the destination.

>My understanding is, the information gathered by the extensions
>specified in draft-kompella-ospf-gmpls-extensions-01.txt section.5
>namely LinkProtectionType,LinkDescriptor (in fact most of the
>sub-TLVs of TE-link TLV) may be necessary to do this.

         If you feel that the GMPLS-TE-MIB is missing some
constrains, please let us know. At present, we feel that
the MIB is nearly adequate for specifying GMPLS te tunnels,
but we could be wrong and for this reason always welcome
input from others.

         It is my understanding that the tunnel will be signaled
as any other MPLS tunnel, just using additional or replacement
GMPLS-specifics. Therefore, the number of hops in the tunnel
or the constraints those links fit into are not necessary for
this to work. That is, the head-end should be able to signal
the tunnel based on the information specified in the tunnel record.
If you want to calculate explicit paths and want to check out what
bandwidth/afinity/etc... is available, there are several
ways of determining this. Depending on what configuration you
are using, the MPLS link bundling or MPLS-DS-TE MIBs might
help you, as they provide specific TE link information. These
might be more appropriate places to find that information
anyway.  Please take a look at these and see if they
meet (or not) your requirements. Second, there are proprietary
MIBs that various vendors have that show this information
as well.

>I do not see this data incorporated in any MIB.
>Now in the absence of such data, how can the management application
>compute the explicit hops satisfying the criteria mentioned above.

         The management application should not be required to
compute the explicit hops. There are several reasons why this
is very difficult, but basically they are the same as any
off-line TE application would experience, just worse because
the information needs to be up-to-date all the time. If it
somehow does, it needs all of the information provided by the
CSPF in every LSR, perhaps across multiple (G)MPLS domains.
What is typical in such cases is the use of loose routes.
These are specified at the head-end LSR, which then does the
path computation between the points specified. This is much
easier to do there because it already has this up-to-date
information. In cases where specific paths are to
be taken, then entire path (or most of it) is specified, and the
LSR optionally fills-in the gaps. Some off-line tool may be
used to assist the operator in this choice, but it is not
mandatory, and as mentioned, is a difficult process to
get right especially in a multi-vendor network.

         --Tom





From owner-mpls@UU.NET  Thu Jun 28 02:24:40 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04686
	for ; Thu, 28 Jun 2001 02:24:40 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvif17257;
	Thu, 28 Jun 2001 06:24:28 GMT
Received: by mail-control.mail.uu.net 
	id QQkvif29779
	for mpls-outgoing; Thu, 28 Jun 2001 06:23:56 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvif29764
	for ; Thu, 28 Jun 2001 06:23:45 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkvif14274
	for ; Thu, 28 Jun 2001 06:22:05 GMT
Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkvif26008
	for ; Thu, 28 Jun 2001 06:22:05 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA22906 for mpls@uu.net; Thu, 28 Jun 2001 02:22:04 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvif29286
	for ; Thu, 28 Jun 2001 06:17:44 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 QQkvif01094
	for ; Thu, 28 Jun 2001 06:16:57 GMT
Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: ihemail1.lucent.com [192.11.222.161])
	id QQkvif22355
	for ; Thu, 28 Jun 2001 06:16:57 GMT
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5S6Gvj24838
	for ; Thu, 28 Jun 2001 02:16:57 -0400 (EDT)
Received: from ii0015exch001u.wins.lucent.com (h135-254-248-252.lucent.com [135.254.248.252])
	by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5S6Gtl24828
	for ; Thu, 28 Jun 2001 02:16:56 -0400 (EDT)
Received: by II0015EXCH001U with Internet Mail Service (5.5.2650.21)
	id ; Thu, 28 Jun 2001 11:46:54 +0530
Message-ID: 
From: "Mahna, Pranjal (Pranjal)" 
To: "'mpls@uu.net'" 
Date: Thu, 28 Jun 2001 11:46:47 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

subscribe



From owner-mpls@UU.NET  Thu Jun 28 04:01:57 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09118
	for ; Thu, 28 Jun 2001 04:01:56 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvim09404;
	Thu, 28 Jun 2001 08:01:19 GMT
Received: by mail-control.mail.uu.net 
	id QQkvim02008
	for mpls-outgoing; Thu, 28 Jun 2001 08:00:47 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvim01583
	for ; Thu, 28 Jun 2001 08:00: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 QQkvil28844
	for ; Thu, 28 Jun 2001 07:59:12 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkvil04858
	for ; Thu, 28 Jun 2001 07:59:11 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA27124 for mpls@uu.net; Thu, 28 Jun 2001 03:59:11 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvil28831
	for ; Thu, 28 Jun 2001 07:58:34 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkvil19426
	for ; Thu, 28 Jun 2001 07:58:01 GMT
Received: from anti_vir1.rad.co.il by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: radmail.rad.co.il [207.232.32.10])
	id QQkvil07002
	for ; Thu, 28 Jun 2001 07:58:00 GMT
Received: from anti_vir1.rad.co.il (localhost [127.0.0.1])
	by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5S8wRo23110
	for ; Thu, 28 Jun 2001 10:58:27 +0200 (IST)
Received: from radmail.rad.co.il (radmail [192.114.24.30])
	by anti_vir1.rad.co.il (8.11.4/8.11.4) with ESMTP id f5S8wNr23092;
	Thu, 28 Jun 2001 10:58:24 +0200 (IST)
Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il
          (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35)
          with ESMTP id il; Thu, 28 Jun 2001 10:59:20 +0300
Received: by TLV1 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 10:56:42 +0200
Message-ID: 
From: Sasha Vainshtein 
To: "'luca@level3.net'" 
Cc: "'pwe3@ietf.org'" , "'mpls@uu.net'" ,
        Alik Shimelmits , Gonen Zilber ,
        Israel Sasson 
Subject: A doubt regarding draft-martini-l2circuit-trans-mpls-06.txt
Date: Thu, 28 Jun 2001 10:56:42 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Sender: owner-mpls@UU.NET
Precedence: bulk

Luka,
After comaring  
with the -05 version I have found the following addition which
troubles me.
In the 1st para of Section 5 you state that

Note that if the tunnel label is not available, the 
VC label MUST NOT be advertized.

This statement suggests several questions which all refer
to the reference model shown below:

----------          ----------          ----------          ----------
|        |          |        |          |        |          |        |
|  PE-1  |<-------->|  P-1   |{...PSN..}|  P-2   |<-------->|  PE-2  |
----------          ----------          ----------          ----------
   ^   ^               ^                      ^               ^     ^
   |   |               |                      |               |     |
   |   -- LDP Session --                      -- LDP Session --     |
   |      for tunnel                             for tunnel         |
   |   label distribution                     label distribution    |
   |                                                                | 
   ------ LDP Session for VC Label distribution ---------------------

Let us assume that:
1. Vanilla LDP in DU mode is used in the core PSN for distribution of 
labels creating hop-by-hop routed LSPs between PE devices. FT LDP
is NOT deployed
2. PE-1 and PE-2 each advertise some (may be Implicit NULL) labels
for IPv4 Host Address FECs (each - for its own Router ID address).
PE-1 does it via its LDP session with P-1, and PE-2 - via its
LDP session with P-2. DU mode of LDP guarantees that PE-1 eventually
learns IPv4 Host Address FEC for PE-2 and its label binding via its
LDP session with P-1, and vice versa for PE-2.
3. PE-1 and PE-2 establish (using LDP extended discovery mechanism)
an LDP session between them which is used for distribution of
VC labels
4. Now let us consider the following situation: for some reason
the LDP session between PE-1 and P-1 has been CLOSED but IP connectivity
between PE-1 and PE-2 remains intact. The simplest example is a situation
when protocol processing and forwarding functions in P-1 are distributed
(say, to different boards) and the protocol processor board has been
reset. As a consequence, PE-1 loses (for some time) the tunnel label
for PE-2. Nevertheless, the LDP session between PE-1 and PE-2 remains
unaffected buy such a disruption. The following questions now arise:
a) What happens to VC labels which have been advertized by PE-1 to PE-2
before the LDP session between PE-1 and PE-1 has been closed? 
b) If a new VC FEC is created in PE-1 while there is no tunnel label
in it for the PE-2 IPv4 Host Address FEC, it is not advertised to PE-2.
Do you suggest that it is advertised once the LDP session between PE-1
and P-1 has been restored and the tunnel label for PE-2 re-learned?

I think that this example described above demonstrates 
that the new limitation introduced in the -06 release requires
a certain dependence between LDP sessions maintained by PE-1 
(and PE-2).AFAIK LDP definitions in, RFC 3036 allow for only 
one type of interaction between different LDP sessions,
namely the ordered label distribution control mode. 
IMHO, this type of interaction is irrelevant for distribution 
of VC labels because LSRs which distribute them serve as egress LERs
for the associated FEC and hence may distribute them at any time regardless
of the label distribution control mode.

Another example is provided by the situation when there is no
MPLS connectivity in the core PSN. Of course, in this case 
there are no LDP sessions between PE-1 and P-1, PE-2 and P-2;
nevertheless, the LDP session between PE-1 and PE-2 may exist.
Section 5.1.1 of   
suggests using MPLS-in-IP to create CEM over the IP PSN; 
by implication, this mechanism is equally applicable
to all types of VCs. The limitation in the -06 draft makes it, however,
impossible to use LDP for distribution of VC labels in such a scenario
because there are no tunnel labels at all.
(BTW, the idea of using MPLS-in-IP has recently been adopted for 
L3 VPNs as shown in )

I would highly appreciated any information regarding your
reasons behind the new limitation.


With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)



From owner-mpls@UU.NET  Thu Jun 28 09:56:55 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18399
	for ; Thu, 28 Jun 2001 09:56:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjj07373;
	Thu, 28 Jun 2001 13:54:54 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjj02514
	for mpls-outgoing; Thu, 28 Jun 2001 13:54:18 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvjj02503
	for ; Thu, 28 Jun 2001 13:54:11 GMT
Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38])
	id QQkvjj01063
	for ; Thu, 28 Jun 2001 13:53:46 GMT
Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQkvjj00448
	for ; Thu, 28 Jun 2001 13:53:45 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5SDrnh10046
	for ; Thu, 28 Jun 2001 06:53:49 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA14680 for mpls@uu.net; Thu, 28 Jun 2001 09:53:44 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvhb05806
	for ; Wed, 27 Jun 2001 22:46:14 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 QQkvhb24799
	for ; Wed, 27 Jun 2001 22:46:11 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f267.law10.hotmail.com [64.4.14.142])
	id QQkvhb01277
	for ; Wed, 27 Jun 2001 22:46:11 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 27 Jun 2001 15:46:10 -0700
Received: from 12.125.43.134 by lw10fd.law10.hotmail.msn.com with HTTP;	Wed, 27 Jun 2001 22:46:10 GMT
X-Originating-IP: [12.125.43.134]
From: "Igor Achkinazi" 
To: mpls@UU.NET
Subject: Cisco LDP config
Date: Wed, 27 Jun 2001 22:46:10 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 27 Jun 2001 22:46:10.0905 (UTC) FILETIME=[F632FC90:01C0FF5A]
Sender: owner-mpls@UU.NET
Precedence: bulk

Hi all,

Could somebody help me to configure DoD for LDP on Cisco router? I try to 
configure DoD on FastEthernet interface, by default it uses DU.

Thanks in advance,
Igor


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



From owner-mpls@UU.NET  Thu Jun 28 10:20:36 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05117
	for ; Thu, 28 Jun 2001 10:20:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjl08237;
	Thu, 28 Jun 2001 14:18:20 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjl25166
	for mpls-outgoing; Thu, 28 Jun 2001 14:17:47 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvjl25081
	for ; Thu, 28 Jun 2001 14:17:32 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 QQkvjk29933
	for ; Thu, 28 Jun 2001 14:11:28 GMT
Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11])
	id QQkvjk23111
	for ; Thu, 28 Jun 2001 14:11:28 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5SEBYx02117;
	Thu, 28 Jun 2001 07:11:34 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA14812; Thu, 28 Jun 2001 10:11:25 -0400 (EDT)
Message-Id: <200106281411.KAA14812@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: francis.arts@alcatel.be
cc: mpls@UU.NET
Subject: Re: MPLSCP 
In-reply-to: Your message of Wed, 27 Jun 2001 19:09:26 +0200.
              
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 28 Jun 2001 10:11:25 -0400
From: Eric Rosen 
Sender: owner-mpls@UU.NET
Precedence: bulk


You should implement as specified in RFC 3032. 

I will write to IANA and ask them to (a) remove the 8283 value (which is not
used),  and (b) to  change the  references from  "tag switching  [davie]" to
"mpls [rfc3032]". 



From owner-mpls@UU.NET  Thu Jun 28 10:24:29 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07684
	for ; Thu, 28 Jun 2001 10:24:28 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjl10348;
	Thu, 28 Jun 2001 14:22:50 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjl25765
	for mpls-outgoing; Thu, 28 Jun 2001 14:22:18 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvjl25745
	for ; Thu, 28 Jun 2001 14:22: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 QQkvjl08260
	for ; Thu, 28 Jun 2001 14:21:46 GMT
Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQkvjl09652
	for ; Thu, 28 Jun 2001 14:21:46 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5SELjh26819;
	Thu, 28 Jun 2001 07:21:45 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA14867; Thu, 28 Jun 2001 10:21:44 -0400 (EDT)
Message-Id: <200106281421.KAA14867@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: "Punj, Arun" 
cc: "'Bala Subrahmanyam Venkata'" , mpls@UU.NET
Subject: Re: VPN of Origin attribute 
In-reply-to: Your message of Wed, 27 Jun 2001 17:31:15 -0400.
             <4FBEA8857476D311A03300204840E1CF01B0BC81@whq-msgusr-02.pit.comms.marconi.com> 
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 28 Jun 2001 10:21:43 -0400
From: Eric Rosen 
Sender: owner-mpls@UU.NET
Precedence: bulk

This thread really belongs on the ppvpn list (ppvpn@zephion.net)

> IMO the VPN Of origin is a superflous attribute in RFC2547. If you 
> look at the example given in the RFC2547, section 4.2.4 page 13, 
> for use of VPN of origin attribute, you will notice it can be simply
> replaced by a VPN target attribute. 

You are correct, this attribute  was originally added because it was thought
that its use might simplify  the expression of certain policies, not because
it is strictly necessary. 

However, see  draft-rosen-vpns-ospf-bgp-mpls-02.txt for  a real use  of that
attribute. 


From owner-mpls@UU.NET  Thu Jun 28 11:21:11 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17757
	for ; Thu, 28 Jun 2001 11:21:09 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjp25492;
	Thu, 28 Jun 2001 15:19:42 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjp19628
	for mpls-outgoing; Thu, 28 Jun 2001 15:19:05 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvjp19597
	for ; Thu, 28 Jun 2001 15:18:47 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 QQkvjo09119
	for ; Thu, 28 Jun 2001 15:14:05 GMT
Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQkvjo27477
	for ; Thu, 28 Jun 2001 15:14:05 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5SFE8h29804
	for ; Thu, 28 Jun 2001 08:14:08 -0700 (PDT)
Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA15018 for mpls@uu.net; Thu, 28 Jun 2001 11:14:02 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvjn28389
	for ; Thu, 28 Jun 2001 14:58:48 GMT
Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40])
	id QQkvjn13453
	for ; Thu, 28 Jun 2001 14:56:41 GMT
Received: from celox-stl-ems2.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: celox-stl-imap1.celoxnetworks.com [12.104.200.29])
	id QQkvjn04058
	for ; Thu, 28 Jun 2001 14:56:41 GMT
Received: by celox-stl-ems2.celoxnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 09:56:38 -0500
Message-ID: <6F2719D5300C624BBC5F69424EC0C2060FECBA@celox-stl-ems2.celoxnetworks.com>
From: "Pour, Mort" 
To: "'mpls@uu.net'" 
Subject: 1+1 protection switching
Date: Thu, 28 Jun 2001 09:56:35 -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


I have a question regarding the 1+1 protection switching in MPLS. 
Draft 
states that the path merge LSR can select the backup path when the primary
path fails.
What about the issues of duplicate (or missing) packets on the backup path
due
to variations in delay between the two path. Or if the two path are
synchronized, how is that achieved?

Thanks
Mort Pour



From owner-mpls@UU.NET  Thu Jun 28 11:34:22 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27454
	for ; Thu, 28 Jun 2001 11:34:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjq29499;
	Thu, 28 Jun 2001 15:31:54 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjq20630
	for mpls-outgoing; Thu, 28 Jun 2001 15:31:19 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvjq20619
	for ; Thu, 28 Jun 2001 15:31:16 GMT
Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39])
	id QQkvjq07760
	for ; Thu, 28 Jun 2001 15:30:45 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkvjq29105
	for ; Thu, 28 Jun 2001 15:30:45 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA20411 for mpls@uu.net; Thu, 28 Jun 2001 11:30:45 -0400 (EDT)
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvjq20523
	for ; Thu, 28 Jun 2001 15:30:00 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 QQkvjp03595
	for ; Thu, 28 Jun 2001 15:28:35 GMT
Received: from cvis29.marconicomms.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: cvis29.marconicomms.com [195.99.244.61])
	id QQkvjp01882
	for ; Thu, 28 Jun 2001 15:28:34 GMT
Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id  for ;
 Thu, 28 Jun 2001 16:28:19 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-32) id QAA14592; Thu, 28 Jun 2001 16:28:19 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256A79.005495AB ; Thu, 28 Jun 2001 16:23:53 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Torsten Mueller" 
To: mpls@UU.NET
Message-ID: <80256A79.005494A0.00@marconicomms.com>
Date: Thu, 28 Jun 2001 17:28:04 +0200
Subject: status of draft-martini-l2circuit-trans-mpls-06.txt ?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk




Hallo,

can somebody in this group pleas clarify, what is the status of
draft-martini-l2circuit-trans-mpls-06.txt,
"Transport of Layer 2 Frames Over MPLS".
Is it an draft of the MPLS WG? I can not find it on the MPLS WG charter
web page.

Thanks,
Torsten Mueller




From owner-mpls@UU.NET  Thu Jun 28 11:42:20 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03328
	for ; Thu, 28 Jun 2001 11:42:20 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjq06099;
	Thu, 28 Jun 2001 15:40:44 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjq21353
	for mpls-outgoing; Thu, 28 Jun 2001 15:40:12 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvjq21331
	for ; Thu, 28 Jun 2001 15:39:57 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 QQkvjq17393
	for ; Thu, 28 Jun 2001 15:38:53 GMT
Received: from celox-stl-ems2.celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: celox-stl-imap1.celoxnetworks.com [12.104.200.29])
	id QQkvjq12499
	for ; Thu, 28 Jun 2001 15:38:52 GMT
Received: by celox-stl-ems2.celoxnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 10:38:49 -0500
Message-ID: <6F2719D5300C624BBC5F69424EC0C2060FECBB@celox-stl-ems2.celoxnetworks.com>
From: "Pour, Mort" 
To: "'mpls@uu.net'" 
Subject: RE: 1+1 protection switching
Date: Thu, 28 Jun 2001 10:38:46 -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

Thanks,
But this may also cause the connection to be dropped by TCP?

Regards,
Mort


-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Thursday, June 28, 2001 10:36 AM
To: 'Pour, Mort'; 'mpls@uu.net'
Subject: RE: 1+1 protection switching


Hi,

I think it is understood/accepted that a number of packets may be dropped or
deliver out of order for a short period of time. The receiver should
re-order the packets and/or request retransmission.  

Yours,
-Shahram

> -----Original Message-----
> From: Pour, Mort [mailto:mpour@celoxnetworks.com]
> Sent: Thursday, June 28, 2001 10:57 AM
> To: 'mpls@uu.net'
> Subject: 1+1 protection switching
> 
> 
> 
> I have a question regarding the 1+1 protection switching in MPLS. 
> Draft 
> states that the path merge LSR can select the backup path 
> when the primary
> path fails.
> What about the issues of duplicate (or missing) packets on 
> the backup path
> due
> to variations in delay between the two path. Or if the two path are
> synchronized, how is that achieved?
> 
> Thanks
> Mort Pour
> 


From owner-mpls@UU.NET  Thu Jun 28 11:45:38 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05710
	for ; Thu, 28 Jun 2001 11:45:37 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjq07061;
	Thu, 28 Jun 2001 15:43:14 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjq21532
	for mpls-outgoing; Thu, 28 Jun 2001 15:42:38 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvjq21503
	for ; Thu, 28 Jun 2001 15:42: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 QQkvjq01504
	for ; Thu, 28 Jun 2001 15:38:20 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkvjq01764
	for ; Thu, 28 Jun 2001 15:38:19 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA21261 for mpls@uu.net; Thu, 28 Jun 2001 11:38:19 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvjq20818
	for ; Thu, 28 Jun 2001 15:33:59 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 QQkvjq27762
	for ; Thu, 28 Jun 2001 15:31:29 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 QQkvjq02989
	for ; Thu, 28 Jun 2001 15:31:29 GMT
Received: (qmail 8995 invoked by uid 104); 28 Jun 2001 15:31:28 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.394077 secs); 28/06/2001 08:31:27
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by mother.pmc-sierra.bc.ca with SMTP; 28 Jun 2001 15:31:27 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5SFVRe05554;
	Thu, 28 Jun 2001 08:31:27 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 08:35:51 -0700
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D36@BBY1EXM01>
From: Shahram Davari 
To: "'Pour, Mort'" , "'mpls@uu.net'"
	 
Subject: RE: 1+1 protection switching
Date: Thu, 28 Jun 2001 08:35:49 -0700
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

Hi,

I think it is understood/accepted that a number of packets may be dropped or deliver out of order for a short period of time. The receiver should re-order the packets and/or request retransmission.  

Yours,
-Shahram

> -----Original Message-----
> From: Pour, Mort [mailto:mpour@celoxnetworks.com]
> Sent: Thursday, June 28, 2001 10:57 AM
> To: 'mpls@uu.net'
> Subject: 1+1 protection switching
> 
> 
> 
> I have a question regarding the 1+1 protection switching in MPLS. 
> Draft 
> states that the path merge LSR can select the backup path 
> when the primary
> path fails.
> What about the issues of duplicate (or missing) packets on 
> the backup path
> due
> to variations in delay between the two path. Or if the two path are
> synchronized, how is that achieved?
> 
> Thanks
> Mort Pour
> 



From owner-mpls@UU.NET  Thu Jun 28 11:50:56 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09684
	for ; Thu, 28 Jun 2001 11:50:55 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjr04899;
	Thu, 28 Jun 2001 15:48:13 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjr22232
	for mpls-outgoing; Thu, 28 Jun 2001 15:47:31 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvjr22211
	for ; Thu, 28 Jun 2001 15:47:27 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 QQkvjr11247
	for ; Thu, 28 Jun 2001 15:46:16 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkvjr04086
	for ; Thu, 28 Jun 2001 15:46:15 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA22200 for mpls@uu.net; Thu, 28 Jun 2001 11:46:15 -0400 (EDT)
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvjr22016
	for ; Thu, 28 Jun 2001 15:45:41 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 QQkvjq09697
	for ; Thu, 28 Jun 2001 15:44:40 GMT
Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP 
	(peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13])
	id QQkvjq17817
	for ; Thu, 28 Jun 2001 15:44:40 GMT
Received: (qmail 20712 invoked by uid 104); 28 Jun 2001 15:44:39 -0000
Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.717847 secs); 28/06/2001 08:44:38
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by father.pmc-sierra.bc.ca with SMTP; 28 Jun 2001 15:44:37 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5SFibe08874;
	Thu, 28 Jun 2001 08:44:37 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 08:49:00 -0700
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D38@BBY1EXM01>
From: Shahram Davari 
To: "'Pour, Mort'" , "'mpls@uu.net'"
	 
Subject: RE: 1+1 protection switching
Date: Thu, 28 Jun 2001 08:48:58 -0700
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

Could you please explain more, why do you think that TCP connection may be dropped.

> -----Original Message-----
> From: Pour, Mort [mailto:mpour@celoxnetworks.com]
> Sent: Thursday, June 28, 2001 11:39 AM
> To: 'mpls@uu.net'
> Subject: RE: 1+1 protection switching
> 
> 
> Thanks,
> But this may also cause the connection to be dropped by TCP?
> 
> Regards,
> Mort
> 
> 
> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Thursday, June 28, 2001 10:36 AM
> To: 'Pour, Mort'; 'mpls@uu.net'
> Subject: RE: 1+1 protection switching
> 
> 
> Hi,
> 
> I think it is understood/accepted that a number of packets 
> may be dropped or
> deliver out of order for a short period of time. The receiver should
> re-order the packets and/or request retransmission.  
> 
> Yours,
> -Shahram
> 
> > -----Original Message-----
> > From: Pour, Mort [mailto:mpour@celoxnetworks.com]
> > Sent: Thursday, June 28, 2001 10:57 AM
> > To: 'mpls@uu.net'
> > Subject: 1+1 protection switching
> > 
> > 
> > 
> > I have a question regarding the 1+1 protection switching in MPLS. 
> > Draft 
> > states that the path merge LSR can select the backup path 
> > when the primary
> > path fails.
> > What about the issues of duplicate (or missing) packets on 
> > the backup path
> > due
> > to variations in delay between the two path. Or if the two path are
> > synchronized, how is that achieved?
> > 
> > Thanks
> > Mort Pour
> > 
> 



From owner-mpls@UU.NET  Thu Jun 28 11:54:22 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12200
	for ; Thu, 28 Jun 2001 11:54:21 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjr09780;
	Thu, 28 Jun 2001 15:49:44 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjr22269
	for mpls-outgoing; Thu, 28 Jun 2001 15:47:50 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvjr22246
	for ; Thu, 28 Jun 2001 15:47: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 QQkvjr08048
	for ; Thu, 28 Jun 2001 15:45:15 GMT
Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mill.cisco.com [161.44.131.47])
	id QQkvjr03663
	for ; Thu, 28 Jun 2001 15:45:15 GMT
Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA22002 for mpls@uu.net; Thu, 28 Jun 2001 11:45:14 -0400 (EDT)
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvjq21684
	for ; Thu, 28 Jun 2001 15:44:35 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 QQkvjq01054
	for ; Thu, 28 Jun 2001 15:37:43 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 QQkvjq11304
	for ; Thu, 28 Jun 2001 15:37:42 GMT
Received: (qmail 11366 invoked by uid 104); 28 Jun 2001 15:37:42 -0000
Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.393358 secs); 28/06/2001 08:37:41
Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1)
  by mother.pmc-sierra.bc.ca with SMTP; 28 Jun 2001 15:37:41 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f5SFbee07472;
	Thu, 28 Jun 2001 08:37:40 -0700 (PDT)
Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 08:42:05 -0700
Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D37@BBY1EXM01>
From: Shahram Davari 
To: "'Torsten Mueller'" , mpls@UU.NET
Subject: RE: status of draft-martini-l2circuit-trans-mpls-06.txt ?
Date: Thu, 28 Jun 2001 08:41:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-mpls@UU.NET
Precedence: bulk

When a draft does not have a name that starts with "draft-ietf-..." it is not a WG document.

-Shahram

> -----Original Message-----
> From: Torsten Mueller [mailto:Torsten.Mueller@marconi.com]
> Sent: Thursday, June 28, 2001 11:28 AM
> To: mpls@UU.NET
> Subject: status of draft-martini-l2circuit-trans-mpls-06.txt ?
> 
> 
> 
> 
> 
> Hallo,
> 
> can somebody in this group pleas clarify, what is the status of
> draft-martini-l2circuit-trans-mpls-06.txt,
> "Transport of Layer 2 Frames Over MPLS".
> Is it an draft of the MPLS WG? I can not find it on the MPLS 
> WG charter
> web page.
> 
> Thanks,
> Torsten Mueller
> 
> 



From owner-mpls@UU.NET  Thu Jun 28 12:37:28 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12791
	for ; Thu, 28 Jun 2001 12:37:27 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvju25020;
	Thu, 28 Jun 2001 16:36:26 GMT
Received: by mail-control.mail.uu.net 
	id QQkvju17763
	for mpls-outgoing; Thu, 28 Jun 2001 16:35:53 GMT
Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15])
	id QQkvju17689
	for ; Thu, 28 Jun 2001 16:35: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 QQkvju20802
	for ; Thu, 28 Jun 2001 16:35:22 GMT
Received: from MAIL-CLUSTER.calynet.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [63.104.246.2])
	id QQkvju24607
	for ; Thu, 28 Jun 2001 16:35:22 GMT
Received: by mail-cluster.calynet.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 09:32:00 -0700
Message-ID: <636C2D109E6CD3119C3600062905FE8F921E2E@mail-cluster.calynet.com>
From: Bernard Zelmans 
To: "'Sasha Vainshtein'" , mpls@UU.NET
Cc: Alik Shimelmits , Gonen Zilber ,
        Israel Sasson 
Subject: RE: L2 MPLS based VPN
Date: Thu, 28 Jun 2001 09:31:59 -0700
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

let me describe what I'm thinking of and let me know if it's stupid.
basically the idea is to distribute the initiation of the LSP for the VC (as
per Martini definition), closer to the customer. so I could have a simple L2
device that would be MPLS enable so that it learns from the PE (through LDP)
the FEC information. Then you would map all ethernet traffic coming on one
port or one VLAN id onto that LSP. On the PE you would receive this labelled
packet and would tunnel it to the peer egress point. so basically you don't
change the protocol (Martini or Kompella) but you extend to another hop the
initialisation of the LSP (corresponding to the VC or inner label once in
the tunnel from the PE)and advertise the FEC through LDP from the PE to this
MPLS enable device.
the point is that I could implement PE function on my box but which one to
go to (Martini or Kompella)? it looks to me that Kompella has more
advantages. but it also looks like that there will be 2 different
implementations out there.
Thanks in advance for your input,

b

-----Original Message-----
From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]
Sent: Wednesday, June 27, 2001 10:34 AM
To: Bernard Zelmans; mpls@UU.NET
Cc: Alik Shimelmits; Gonen Zilber; Israel Sasson
Subject: RE: L2 MPLS based VPN


Bernard,
Inner labels in both Martiti-Transport and Kompella L2 VPN drafts 
are distributed directly between peer edge devices, and have meaning
only between these devices. Both Martini and Kompella drafts allow using
targeted LDP sessions for this purpose, and Kompella also allows using
MP-BGP for this purpose.
For the aggregation device to allocate the outer label, it has to be able
to infer somehow the FEC of the incoming packet.
I see the following options for the packet transmitted by the access device
to the aggregation one:
1. It is a label packet with the outer label in the stack being the inner
label
of the virtual connection. This label cannot be valid in the aggregation
device
(as it did not participate in its distribution) so it either drops the
packet or, even
worse, misuses it.
2. It is an IP packet (say, with MPLS-in-IP protocol type and 
the inner label following the IP header). In this case the access device:
* Has to operate as an IP router
* Has to know IP address of its remote peer device
* The aggregation device may push the "outer" label on top of IP header
or just to forward the unlabeled
*The remote access device must recognize the incoming IP packet as 
one carying MPLS-in-IP, strip its IP header and then process the incoming
label.
I.e., the 2nd option will work, but it imposes restrictions on access
devices. E.g.,
you cannot connect Ethernet switches (which are not IP routers) in this way.
PE devices in both Martini and Kompella are assumed to be LERs (as defined
in RFC 3031)
with additional capabilities allowing support of encapsulation of L2
packets; this approach
does not impose any restrictions on the access (presumably, CPE) devices.
With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com  
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
 


> -----Original Message-----
> From: Bernard Zelmans [mailto:bzelmans@calynet.com]
> Sent: Wednesday, June 27, 2001 4:49 AM
> To: mpls@UU.NET
> Subject: L2 MPLS based VPN
> 
> 
> Hi all,
> 
> looking at both Martini and Kompella draft on L2 based VPN, 
> the LSP with the
> inner+outer label is started from the same node (PE). Is 
> there a particular
> reason for that? why don't we allow an access device to 
> initiate the inner
> label LSP and have an aggregation device start the tunnel?
> Thanks in advance,
> 
> b
> 


From owner-mpls@UU.NET  Thu Jun 28 12:59:50 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28050
	for ; Thu, 28 Jun 2001 12:59:50 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjv02209;
	Thu, 28 Jun 2001 16:57:52 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjv20897
	for mpls-outgoing; Thu, 28 Jun 2001 16:57:20 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvjv20878
	for ; Thu, 28 Jun 2001 16:57: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 QQkvjv06919
	for ; Thu, 28 Jun 2001 16:52:26 GMT
From: francis.arts@alcatel.be
Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: alc119.alcatel.be [195.207.101.119])
	id QQkvjv00658
	for ; Thu, 28 Jun 2001 16:52:25 GMT
Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f5SGq3v17208;
	Thu, 28 Jun 2001 18:52:03 +0200 (MET DST)
Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256A79.005CA68D ; Thu, 28 Jun 2001 18:51:59 +0200
X-Lotus-FromDomain: ALCATEL
To: erosen@cisco.com
cc: mpls@UU.NET
Message-ID: 
Date: Thu, 28 Jun 2001 18:51:55 +0200
Subject: Re: MPLSCP
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpls@UU.NET
Precedence: bulk




Hello Eric,

It should be noted that this correction should also be reflected in an updated version of sections 4.2 and 5 of RFC 3032. Both sections are referring to an 'MPLS unicast' and 'MPLS multicast' code point for the PPP protocol value and ethertype (see extract
from RFC 3032 below).

Regards,

     Francis.


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

** Extract from RFC 3032**
*******************************

4.3. Sending Labeled Packets

  ...

   Exactly one labeled packet is encapsulated in the PPP Information
   field, where the PPP Protocol field indicates either type hex 0281
   (MPLS Unicast) or type hex 0283 (MPLS Multicast).  The maximum length
   of a labeled packet transmitted over a PPP link is the same as the
   maximum length of the Information field of a PPP encapsulated packet.

   ...

   Note that two codepoints are defined for labeled packets; one for
   multicast and one for unicast.
   ...

5. Transporting Labeled Packets over LAN Media

   ...

   The ethertype value 8847 hex is used to indicate that a frame is
   carrying an MPLS unicast packet.

   The ethertype value 8848 hex is used to indicate that a frame is
   carrying an MPLS multicast packet.
   ...

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





Eric Rosen  on 28/06/2001 16:11:25

Please respond to erosen@cisco.com
                                                              
                                                              
                                                              
 To:      Francis ARTS/BE/ALCATEL@ALCATEL                     
                                                              
 cc:      mpls@UU.NET                                         
                                                              
                                                              
                                                              
 Subject: Re: MPLSCP                                          
                                                              






You should implement as specified in RFC 3032.

I will write to IANA and ask them to (a) remove the 8283 value (which is not
used),  and (b) to  change the  references from  "tag switching  [davie]" to
"mpls [rfc3032]".






From owner-mpls@UU.NET  Thu Jun 28 13:27:30 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16092
	for ; Thu, 28 Jun 2001 13:27:29 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjx10713;
	Thu, 28 Jun 2001 17:26:18 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjx13494
	for mpls-outgoing; Thu, 28 Jun 2001 17:25:46 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvjx13474
	for ; Thu, 28 Jun 2001 17:25: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 QQkvjx28708
	for ; Thu, 28 Jun 2001 17:17:20 GMT
Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11])
	id QQkvjx15750
	for ; Thu, 28 Jun 2001 17:17:20 GMT
Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5SHHJh07889;
	Thu, 28 Jun 2001 10:17:19 -0700 (PDT)
Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA15495; Thu, 28 Jun 2001 13:17:18 -0400 (EDT)
Message-Id: <200106281717.NAA15495@erosen-sun.cisco.com>
X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs
To: francis.arts@alcatel.be
cc: mpls@UU.NET
Subject: Re: MPLSCP 
In-reply-to: Your message of Thu, 28 Jun 2001 18:51:55 +0200.
              
Reply-To: erosen@cisco.com
User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1
 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1)
 MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune")
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 28 Jun 2001 13:17:18 -0400
From: Eric Rosen 
Sender: owner-mpls@UU.NET
Precedence: bulk


No, RFC  3032 is correct  as written.  The  data packets need  codepoints to
distinguish  multicast from  unicast.   However, only  a  single PPP  MPLSCP
codepoint is used, not one for unicast and one for multicast. 


From owner-mpls@UU.NET  Thu Jun 28 13:36:40 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23038
	for ; Thu, 28 Jun 2001 13:36:35 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvjy14818;
	Thu, 28 Jun 2001 17:34:45 GMT
Received: by mail-control.mail.uu.net 
	id QQkvjy14377
	for mpls-outgoing; Thu, 28 Jun 2001 17:34:12 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvjy14367
	for ; Thu, 28 Jun 2001 17:34: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 QQkvjy16441
	for ; Thu, 28 Jun 2001 17:33:40 GMT
Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: [216.57.132.42])
	id QQkvjy27846
	for ; Thu, 28 Jun 2001 17:33:39 GMT
Message-ID: <3B3B6A6F.A9BF03A8@sandburst.com>
Date: Thu, 28 Jun 2001 13:33:35 -0400
From: Eric Gray 
MIME-Version: 1.0
To: francis.arts@alcatel.be
Cc: erosen@cisco.com, mpls@UU.NET
Subject: Re: MPLSCP
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

Francis,

    I don't see why these changes would be required.  If you look at assigned
numbers for PPP - available at

    ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers

you will find that 0x0281 and 0x0283 have been assigned as specified in RFC
3032.  If you look at assigned numbers for Ethernet, available at

    http://www.iana.org/assignments/ethernet-numbers

you will similarly find that 0x8847 and 0x8848 have been assigned as specified
in RFC 3032.

    The number )- 0x8281 - is required for MPLSCP, which is independent of
Unicast/Multicast considerations.

--
Eric Gray

You wrote:

> Hello Eric,
>
> It should be noted that this correction should also be reflected in an updated version of sections 4.2 and 5 of RFC 3032. Both sections are referring to an 'MPLS unicast' and 'MPLS multicast' code point for the PPP protocol value and ethertype (see extract
> from RFC 3032 below).
>
> Regards,
>
>      Francis.
>
> --------------------
>
> ** Extract from RFC 3032**
> *******************************
>
> 4.3. Sending Labeled Packets
>
>   ...
>
>    Exactly one labeled packet is encapsulated in the PPP Information
>    field, where the PPP Protocol field indicates either type hex 0281
>    (MPLS Unicast) or type hex 0283 (MPLS Multicast).  The maximum length
>    of a labeled packet transmitted over a PPP link is the same as the
>    maximum length of the Information field of a PPP encapsulated packet.
>
>    ...
>
>    Note that two codepoints are defined for labeled packets; one for
>    multicast and one for unicast.
>    ...
>
> 5. Transporting Labeled Packets over LAN Media
>
>    ...
>
>    The ethertype value 8847 hex is used to indicate that a frame is
>    carrying an MPLS unicast packet.
>
>    The ethertype value 8848 hex is used to indicate that a frame is
>    carrying an MPLS multicast packet.
>    ...
>
> ---------------------
>
> Eric Rosen  on 28/06/2001 16:11:25
>
> Please respond to erosen@cisco.com
>
>
>
>  To:      Francis ARTS/BE/ALCATEL@ALCATEL
>
>  cc:      mpls@UU.NET
>
>
>
>  Subject: Re: MPLSCP
>
>
> You should implement as specified in RFC 3032.
>
> I will write to IANA and ask them to (a) remove the 8283 value (which is not
> used),  and (b) to  change the  references from  "tag switching  [davie]" to
> "mpls [rfc3032]".



From owner-mpls@UU.NET  Thu Jun 28 14:16:31 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21934
	for ; Thu, 28 Jun 2001 14:16:31 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvka05253;
	Thu, 28 Jun 2001 18:14:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkvka08533
	for mpls-outgoing; Thu, 28 Jun 2001 18:14:04 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvka08493
	for ; Thu, 28 Jun 2001 18:13:50 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 QQkvka14975
	for ; Thu, 28 Jun 2001 18:11:13 GMT
From: bhaskara@turinnetworks.com
Received: from milan.turinnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 63-197-247-126.turinntwks.com [63.197.247.126] (may be forged))
	id QQkvka23311
	for ; Thu, 28 Jun 2001 18:11:12 GMT
Received: by MILAN with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 11:10:59 -0700
Message-ID: <36EF020032CFD411B7B400508B55E590A21B38@MILAN>
To: ccamp@ops.ietf.org, mpls@UU.NET
Subject: looking for LMP
Date: Thu, 28 Jun 2001 11:10:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FFFD.A9462850"
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_01C0FFFD.A9462850
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Does any one know about the LMP public domain availability?
Or any interop testing tool for testing the functionality of LMP?

thank you

with regards
bhaskara

------_=_NextPart_001_01C0FFFD.A9462850
Content-Type: text/html;
	charset="iso-8859-1"






looking for LMP




Hi,




Does any one know about the LMP public domain availability?

Or any interop testing tool for testing the functionality of LMP?




thank you




with regards

bhaskara





------_=_NextPart_001_01C0FFFD.A9462850--


From owner-mpls@UU.NET  Thu Jun 28 14:18:43 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23496
	for ; Thu, 28 Jun 2001 14:18:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvkb06489;
	Thu, 28 Jun 2001 18:16:20 GMT
Received: by mail-control.mail.uu.net 
	id QQkvka08568
	for mpls-outgoing; Thu, 28 Jun 2001 18:14:16 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvka08498
	for ; Thu, 28 Jun 2001 18:13: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 QQkvka16190
	for ; Thu, 28 Jun 2001 18:12:45 GMT
Received: from celox-stl-ems2.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: celox-stl-imap1.celoxnetworks.com [12.104.200.29])
	id QQkvka24302
	for ; Thu, 28 Jun 2001 18:12:45 GMT
Received: by celox-stl-ems2.celoxnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 13:12:42 -0500
Message-ID: <6F2719D5300C624BBC5F69424EC0C2060FECBD@celox-stl-ems2.celoxnetworks.com>
From: "Pour, Mort" 
To: "'mpls@uu.net'" 
Subject: RE: 1+1 protection switching
Date: Thu, 28 Jun 2001 13:12:37 -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

On second thought I agree. I don't think there will any problem except for
some
retransmissions or some duplicate packets being dropped.


-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Thursday, June 28, 2001 10:49 AM
To: 'Pour, Mort'; 'mpls@uu.net'
Subject: RE: 1+1 protection switching


Could you please explain more, why do you think that TCP connection may be
dropped.

> -----Original Message-----
> From: Pour, Mort [mailto:mpour@celoxnetworks.com]
> Sent: Thursday, June 28, 2001 11:39 AM
> To: 'mpls@uu.net'
> Subject: RE: 1+1 protection switching
> 
> 
> Thanks,
> But this may also cause the connection to be dropped by TCP?
> 
> Regards,
> Mort
> 
> 
> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Thursday, June 28, 2001 10:36 AM
> To: 'Pour, Mort'; 'mpls@uu.net'
> Subject: RE: 1+1 protection switching
> 
> 
> Hi,
> 
> I think it is understood/accepted that a number of packets 
> may be dropped or
> deliver out of order for a short period of time. The receiver should
> re-order the packets and/or request retransmission.  
> 
> Yours,
> -Shahram
> 
> > -----Original Message-----
> > From: Pour, Mort [mailto:mpour@celoxnetworks.com]
> > Sent: Thursday, June 28, 2001 10:57 AM
> > To: 'mpls@uu.net'
> > Subject: 1+1 protection switching
> > 
> > 
> > 
> > I have a question regarding the 1+1 protection switching in MPLS. 
> > Draft 
> > states that the path merge LSR can select the backup path 
> > when the primary
> > path fails.
> > What about the issues of duplicate (or missing) packets on 
> > the backup path
> > due
> > to variations in delay between the two path. Or if the two path are
> > synchronized, how is that achieved?
> > 
> > Thanks
> > Mort Pour
> > 
> 


From owner-mpls@UU.NET  Thu Jun 28 14:24:59 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27837
	for ; Thu, 28 Jun 2001 14:24:59 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvkb22991;
	Thu, 28 Jun 2001 18:22:23 GMT
Received: by mail-control.mail.uu.net 
	id QQkvkb09666
	for mpls-outgoing; Thu, 28 Jun 2001 18:20:06 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvkb09654
	for ; Thu, 28 Jun 2001 18:20:01 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 QQkvkb26108
	for ; Thu, 28 Jun 2001 18:18:35 GMT
Received: from mail.timetra.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail.timetra.com [63.104.212.2])
	id QQkvkb27354
	for ; Thu, 28 Jun 2001 18:18:34 GMT
Received: from SAURABAHPC ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 28 Jun 2001 11:12:24 -0700
Reply-To: 
From: "Saurabh Shrivastava" 
To: "'Pour, Mort'" , "'mpls@uu.net'" 
Subject: RE: 1+1 protection switching
Date: Thu, 28 Jun 2001 11:18:26 -0700
Message-ID: <008c01c0fffe$ba1617c0$c7bcfea9@SAURABAHPC>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <6F2719D5300C624BBC5F69424EC0C2060FECBD@celox-stl-ems2.celoxnetworks.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-OriginalArrivalTime: 28 Jun 2001 18:12:24.0933 (UTC) FILETIME=[E1F85150:01C0FFFD]
Sender: owner-mpls@UU.NET
Precedence: bulk
Content-Transfer-Encoding: 7bit

but isnt there a requirement that in an LSP, there
should be no packet reordering.


~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Saurabh Shrivastava          saurabh@timetra.com        

TiMetra, Inc.                408.245.8796 (residence)
http://www.timetra.com/      650.237.5154 (office)
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~


*  -----Original Message-----
*  From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Pour,
*  Mort
*  Sent: Thursday, June 28, 2001 11:13 AM
*  To: 'mpls@uu.net'
*  Subject: RE: 1+1 protection switching
*  
*  
*  On second thought I agree. I don't think there will any 
*  problem except for
*  some
*  retransmissions or some duplicate packets being dropped.
*  
*  
*  -----Original Message-----
*  From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
*  Sent: Thursday, June 28, 2001 10:49 AM
*  To: 'Pour, Mort'; 'mpls@uu.net'
*  Subject: RE: 1+1 protection switching
*  
*  
*  Could you please explain more, why do you think that TCP 
*  connection may be
*  dropped.
*  
*  > -----Original Message-----
*  > From: Pour, Mort [mailto:mpour@celoxnetworks.com]
*  > Sent: Thursday, June 28, 2001 11:39 AM
*  > To: 'mpls@uu.net'
*  > Subject: RE: 1+1 protection switching
*  > 
*  > 
*  > Thanks,
*  > But this may also cause the connection to be dropped by TCP?
*  > 
*  > Regards,
*  > Mort
*  > 
*  > 
*  > -----Original Message-----
*  > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
*  > Sent: Thursday, June 28, 2001 10:36 AM
*  > To: 'Pour, Mort'; 'mpls@uu.net'
*  > Subject: RE: 1+1 protection switching
*  > 
*  > 
*  > Hi,
*  > 
*  > I think it is understood/accepted that a number of packets 
*  > may be dropped or
*  > deliver out of order for a short period of time. The 
*  receiver should
*  > re-order the packets and/or request retransmission.  
*  > 
*  > Yours,
*  > -Shahram
*  > 
*  > > -----Original Message-----
*  > > From: Pour, Mort [mailto:mpour@celoxnetworks.com]
*  > > Sent: Thursday, June 28, 2001 10:57 AM
*  > > To: 'mpls@uu.net'
*  > > Subject: 1+1 protection switching
*  > > 
*  > > 
*  > > 
*  > > I have a question regarding the 1+1 protection switching 
*  in MPLS. 
*  > > Draft 
*  > > states that the path merge LSR can select the backup path 
*  > > when the primary
*  > > path fails.
*  > > What about the issues of duplicate (or missing) packets on 
*  > > the backup path
*  > > due
*  > > to variations in delay between the two path. Or if the 
*  two path are
*  > > synchronized, how is that achieved?
*  > > 
*  > > Thanks
*  > > Mort Pour
*  > > 
*  > 


From owner-mpls@UU.NET  Thu Jun 28 14:31:35 2001
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02540
	for ; Thu, 28 Jun 2001 14:31:34 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvkb28862;
	Thu, 28 Jun 2001 18:28:35 GMT
Received: by mail-control.mail.uu.net 
	id QQkvkb10526
	for mpls-outgoing; Thu, 28 Jun 2001 18:28:02 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvkb10508
	for ; Thu, 28 Jun 2001 18:27: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 QQkvkb29528
	for ; Thu, 28 Jun 2001 18:22:35 GMT
Received: from celox-stl-ems2.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: celox-stl-imap1.celoxnetworks.com [12.104.200.29])
	id QQkvkb29062
	for ; Thu, 28 Jun 2001 18:22:35 GMT
Received: by celox-stl-ems2.celoxnetworks.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 13:22:32 -0500
Message-ID: <6F2719D5300C624BBC5F69424EC0C2060FECBF@celox-stl-ems2.celoxnetworks.com>
From: "Pour, Mort" 
To: "'mpls@uu.net'" 
Subject: RE: 1+1 protection switching
Date: Thu, 28 Jun 2001 13:22:27 -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

As far as I know there are no explicit requirements on reordering.

-----Original Message-----
From: Saurabh Shrivastava [mailto:saurabh@timetra.com]
Sent: Thursday, June 28, 2001 1:18 PM
To: 'Pour, Mort'; 'mpls@uu.net'
Subject: RE: 1+1 protection switching


but isnt there a requirement that in an LSP, there
should be no packet reordering.


~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Saurabh Shrivastava          saurabh@timetra.com        

TiMetra, Inc.                408.245.8796 (residence)
http://www.timetra.com/      650.237.5154 (office)
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~


*  -----Original Message-----
*  From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Pour,
*  Mort
*  Sent: Thursday, June 28, 2001 11:13 AM
*  To: 'mpls@uu.net'
*  Subject: RE: 1+1 protection switching
*  
*  
*  On second thought I agree. I don't think there will any 
*  problem except for
*  some
*  retransmissions or some duplicate packets being dropped.
*  
*  
*  -----Original Message-----
*  From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
*  Sent: Thursday, June 28, 2001 10:49 AM
*  To: 'Pour, Mort'; 'mpls@uu.net'
*  Subject: RE: 1+1 protection switching
*  
*  
*  Could you please explain more, why do you think that TCP 
*  connection may be
*  dropped.
*  
*  > -----Original Message-----
*  > From: Pour, Mort [mailto:mpour@celoxnetworks.com]
*  > Sent: Thursday, June 28, 2001 11:39 AM
*  > To: 'mpls@uu.net'
*  > Subject: RE: 1+1 protection switching
*  > 
*  > 
*  > Thanks,
*  > But this may also cause the connection to be dropped by TCP?
*  > 
*  > Regards,
*  > Mort
*  > 
*  > 
*  > -----Original Message-----
*  > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
*  > Sent: Thursday, June 28, 2001 10:36 AM
*  > To: 'Pour, Mort'; 'mpls@uu.net'
*  > Subject: RE: 1+1 protection switching
*  > 
*  > 
*  > Hi,
*  > 
*  > I think it is understood/accepted that a number of packets 
*  > may be dropped or
*  > deliver out of order for a short period of time. The 
*  receiver should
*  > re-order the packets and/or request retransmission.  
*  > 
*  > Yours,
*  > -Shahram
*  > 
*  > > -----Original Message-----
*  > > From: Pour, Mort [mailto:mpour@celoxnetworks.com]
*  > > Sent: Thursday, June 28, 2001 10:57 AM
*  > > To: 'mpls@uu.net'
*  > > Subject: 1+1 protection switching
*  > > 
*  > > 
*  > > 
*  > > I have a question regarding the 1+1 protection switching 
*  in MPLS. 
*  > > Draft 
*  > > states that the path merge LSR can select the backup path 
*  > > when the primary
*  > > path fails.
*  > > What about the issues of duplicate (or missing) packets on 
*  > > the backup path
*  > > due
*  > > to variations in delay between the two path. Or if the 
*  two path are
*  > > synchronized, how is that achieved?
*  > > 
*  > > Thanks
*  > > Mort Pour
*  > > 
*  > 


From owner-mpls@UU.NET  Thu Jun 28 19:21:53 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11507
	for ; Thu, 28 Jun 2001 19:21:52 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvkv12922;
	Thu, 28 Jun 2001 23:18:41 GMT
Received: by mail-control.mail.uu.net 
	id QQkvkv18433
	for mpls-outgoing; Thu, 28 Jun 2001 23:17:53 GMT
Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11])
	id QQkvkv18420
	for ; Thu, 28 Jun 2001 23:17:47 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 QQkvku27190
	for ; Thu, 28 Jun 2001 23:12:52 GMT
From: neil.2.harrison@bt.com
Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41])
	id QQkvku08884
	for ; Thu, 28 Jun 2001 23:12:51 GMT
Received: from cryndent01.mww.bt.com by gollum (local) with ESMTP;
          Fri, 29 Jun 2001 00:12:47 +0100
Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) 
          id ; Fri, 29 Jun 2001 00:12:43 +0100
Message-ID: 
To: mpls@UU.NET
Subject: RE: 1+1 protection switching
Date: Fri, 29 Jun 2001 00:12:37 +0100
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-mpls@UU.NET
Precedence: bulk

If you change a path then you change its delay.  In all cases except 1+1 (eg
1:1 or 1:N) you will get a hit on the restored path.....that's just a fact.
In 1+1 you have the ability, should you choose, to delay/phase align the
working and protection.  Clearly the working and protection path must be
buffered such that the 'faster' path has the same delay as the 'slower'
path......otherwise hitless changeover will not be posssible.

But you also have to ask yourself if a hit such a big deal?  This depends on
the applications tolerance to the hit it gets.........and this can vary and
is not simply a function of the transport delay, but what
framing/realignment process (if any) the application is using.

neil

> -----Original Message-----
> From: Pour, Mort [mailto:mpour@celoxnetworks.com]
> Sent: 28 June 2001 19:22
> To: 'mpls@uu.net'
> Subject: RE: 1+1 protection switching
> 
> 
> As far as I know there are no explicit requirements on reordering.
> 
> -----Original Message-----
> From: Saurabh Shrivastava [mailto:saurabh@timetra.com]
> Sent: Thursday, June 28, 2001 1:18 PM
> To: 'Pour, Mort'; 'mpls@uu.net'
> Subject: RE: 1+1 protection switching
> 
> 
> but isnt there a requirement that in an LSP, there
> should be no packet reordering.
> 
> 
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> Saurabh Shrivastava          saurabh@timetra.com        
> 
> TiMetra, Inc.                408.245.8796 (residence)
> http://www.timetra.com/      650.237.5154 (office)
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> 
> 
> *  -----Original Message-----
> *  From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On 
> Behalf Of Pour,
> *  Mort
> *  Sent: Thursday, June 28, 2001 11:13 AM
> *  To: 'mpls@uu.net'
> *  Subject: RE: 1+1 protection switching
> *  
> *  
> *  On second thought I agree. I don't think there will any 
> *  problem except for
> *  some
> *  retransmissions or some duplicate packets being dropped.
> *  
> *  
> *  -----Original Message-----
> *  From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> *  Sent: Thursday, June 28, 2001 10:49 AM
> *  To: 'Pour, Mort'; 'mpls@uu.net'
> *  Subject: RE: 1+1 protection switching
> *  
> *  
> *  Could you please explain more, why do you think that TCP 
> *  connection may be
> *  dropped.
> *  
> *  > -----Original Message-----
> *  > From: Pour, Mort [mailto:mpour@celoxnetworks.com]
> *  > Sent: Thursday, June 28, 2001 11:39 AM
> *  > To: 'mpls@uu.net'
> *  > Subject: RE: 1+1 protection switching
> *  > 
> *  > 
> *  > Thanks,
> *  > But this may also cause the connection to be dropped by TCP?
> *  > 
> *  > Regards,
> *  > Mort
> *  > 
> *  > 
> *  > -----Original Message-----
> *  > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> *  > Sent: Thursday, June 28, 2001 10:36 AM
> *  > To: 'Pour, Mort'; 'mpls@uu.net'
> *  > Subject: RE: 1+1 protection switching
> *  > 
> *  > 
> *  > Hi,
> *  > 
> *  > I think it is understood/accepted that a number of packets 
> *  > may be dropped or
> *  > deliver out of order for a short period of time. The 
> *  receiver should
> *  > re-order the packets and/or request retransmission.  
> *  > 
> *  > Yours,
> *  > -Shahram
> *  > 
> *  > > -----Original Message-----
> *  > > From: Pour, Mort [mailto:mpour@celoxnetworks.com]
> *  > > Sent: Thursday, June 28, 2001 10:57 AM
> *  > > To: 'mpls@uu.net'
> *  > > Subject: 1+1 protection switching
> *  > > 
> *  > > 
> *  > > 
> *  > > I have a question regarding the 1+1 protection switching 
> *  in MPLS. 
> *  > > Draft 
> *  > > states that the path merge LSR can select the backup path 
> *  > > when the primary
> *  > > path fails.
> *  > > What about the issues of duplicate (or missing) packets on 
> *  > > the backup path
> *  > > due
> *  > > to variations in delay between the two path. Or if the 
> *  two path are
> *  > > synchronized, how is that achieved?
> *  > > 
> *  > > Thanks
> *  > > Mort Pour
> *  > > 
> *  > 
> 


From owner-mpls@UU.NET  Fri Jun 29 18:16:17 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26323
	for ; Fri, 29 Jun 2001 18:16:16 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvoi12954;
	Fri, 29 Jun 2001 22:14:42 GMT
Received: by mail-control.mail.uu.net 
	id QQkvoi29265
	for mpls-outgoing; Fri, 29 Jun 2001 22:14:07 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvoi29239
	for ; Fri, 29 Jun 2001 22:13: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 QQkvoi20176
	for ; Fri, 29 Jun 2001 22:12:45 GMT
From: bhaskara@turinnetworks.com
Received: from milan.turinnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 63-197-247-126.turinntwks.com [63.197.247.126] (may be forged))
	id QQkvoi01374
	for ; Fri, 29 Jun 2001 22:12:44 GMT
Received: by MILAN with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 15:12:41 -0700
Message-ID: <36EF020032CFD411B7B400508B55E590A21B3B@MILAN>
To: ccamp@ops.ietf.org, mpls@UU.NET
Subject:  lmp mib
Date: Fri, 29 Jun 2001 15:12:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C100E8.9CACAF60"
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_01C100E8.9CACAF60
Content-Type: text/plain;
	charset="iso-8859-1"




> Hi,
> 
> In lmpTeLinkTable of  "draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType
> SYNTAX is given as uint32 in table entry index and when it is
> defined it is given as INTEGER type.  which one is correct?
> 
> thanks
> regards
> bhaskara

------_=_NextPart_001_01C100E8.9CACAF60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






 lmp mib










Hi,




In lmpTeLinkTable of  =
"draft-dubuc-lmp-mib-02.txt" , lmpTeLinkEncodingType SYNTAX =
is given as uint32 in table entry index and when it is



defined it is given as INTEGER =
type.  which one is correct?




thanks

regards

bhaskara





------_=_NextPart_001_01C100E8.9CACAF60--


From owner-mpls@UU.NET  Fri Jun 29 19:52:43 2001
Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27626
	for ; Fri, 29 Jun 2001 19:52:42 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvop21448;
	Fri, 29 Jun 2001 23:52:46 GMT
Received: by mail-control.mail.uu.net 
	id QQkvop28867
	for mpls-outgoing; Fri, 29 Jun 2001 23:52:14 GMT
Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46])
	id QQkvop28831
	for ; Fri, 29 Jun 2001 23:51:57 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 QQkvop14828
	for ; Fri, 29 Jun 2001 23:48:44 GMT
Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: f114.law11.hotmail.com [64.4.17.114])
	id QQkvop18090
	for ; Fri, 29 Jun 2001 23:48:43 GMT
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 29 Jun 2001 16:48:33 -0700
Received: from 65.112.106.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Fri, 29 Jun 2001 23:48:33 GMT
X-Originating-IP: [65.112.106.16]
From: "Irfan Lateef" 
To: tnadeau@cisco.com, mpls@UU.NET
Subject: Re: MIBs for GMPLS
Date: Fri, 29 Jun 2001 19:48:33 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 29 Jun 2001 23:48:33.0273 (UTC) FILETIME=[01A68690:01C100F6]
Sender: owner-mpls@UU.NET
Precedence: bulk

Tom,

Thanks for your response. A few comments embedded below.

>If you want to calculate explicit paths and want to check out what
>bandwidth/afinity/etc... is available,

Yes, something similar. In fact what I want to provide to the
management interface user is manual-override capability, like
the aircraft pilot has over auto-pilot. The reason being inspite
of all the sophisticated algorithm, if the route is graphically
mapped on a screen, a human can sometimes make better judgements.

This capability is slightly different than choosing a set of hops
and letting the rest to be filled in by the signalling protocol. Here
the application chooses all the hops and the user changes only the
ones he/she desires for further optimization.

Now this can be done in two ways. One is as you suggested initially
where the NMS gives the source and destination and let the protocol
choose the hops. Here in order to check the hops before setting the
path, I would like to propose a variation, where the NMS instead of
a setup request, should send a "prepare-to-setup" request with src,
dest and the traffic contraints, and the ack message
should return the list of hops. Then the user can send a
"execute-setup" request. If this approach can work,
it would address all the issues typical with offline TE application
as pointed out by you and yet deliver the capability we need.

The second is what I am currently pursuing, namely get all the
formation necessary on the NMS and compute the explicit hops and
perform manual changes and then send a set up request thru the NMS.


>Depending on what configuration you are using, the MPLS link bundling or 
>MPLS-DS-TE MIBs might help you, as they provide specific TE link 
>information.

You are right on the mark. I went through these MIBs and its
looks like they will almost solve my problem. During the course
implementation if I end up squeezing in a few more variables I
will keep the listed posted for consideration in next updates.

>         The management application should not be required to
>compute the explicit hops. There are several reasons why this

I agree in most parts, but would like to make one point.
In the GMPLS paradigm we may need to de-emphasize, the urgency to
update the data and the possibility of its obsolence in shorter time
durations, because the underlying network characteristics are not changing 
as frequently and dynamically as it is in IP layer network.

Here we are talking about lambdas and SONET which may be
considered relatively stable. This is also the reason for manual
override because the paths being setup are of relatively higher bandwidth 
and for longer periods of time having a bigger impact in term of cost for 
the
service provider.

Regards,
Irfan Lateef


>From: "Thomas D. Nadeau" 
>To: "Irfan Lateef" , mpls@UU.NET
>Subject: Re: MIBs for GMPLS
>Date: Wed, 27 Jun 2001 21:12:21 -0400
>
>At 07:53 PM 6/27/2001 -0400, Irfan Lateef wrote:
>>Tom,
>>
>>I may be missing something here but let try to make it
>>more explicit using a hypothetical example.
>>
>>Let us extend the example given in the draft
>>draft-nadeau-mpls-gmpls-te-mib-00.txt section.8 from two hops
>>to N hops and from loosely routed to explicitly routed and assume
>>that this has to be done automatically from a management application.
>>
>>Further assume the application needs to find a list of ERHOPs
>>satisfying a condition like "find unprotected lambdas with OC-48
>>worth of bandwidth and setup an LSP  from A to B".
>
>         Then you go to LSR A and specify the tunnel bandwidth to
>be that of an OC-48 link and specify B as the destination.
>
>>My understanding is, the information gathered by the extensions
>>specified in draft-kompella-ospf-gmpls-extensions-01.txt section.5
>>namely LinkProtectionType,LinkDescriptor (in fact most of the
>>sub-TLVs of TE-link TLV) may be necessary to do this.
>
>         If you feel that the GMPLS-TE-MIB is missing some
>constrains, please let us know. At present, we feel that
>the MIB is nearly adequate for specifying GMPLS te tunnels,
>but we could be wrong and for this reason always welcome
>input from others.
>
>         It is my understanding that the tunnel will be signaled
>as any other MPLS tunnel, just using additional or replacement
>GMPLS-specifics. Therefore, the number of hops in the tunnel
>or the constraints those links fit into are not necessary for
>this to work. That is, the head-end should be able to signal
>the tunnel based on the information specified in the tunnel record.
>If you want to calculate explicit paths and want to check out what
>bandwidth/afinity/etc... is available, there are several
>ways of determining this. Depending on what configuration you
>are using, the MPLS link bundling or MPLS-DS-TE MIBs might
>help you, as they provide specific TE link information. These
>might be more appropriate places to find that information
>anyway.  Please take a look at these and see if they
>meet (or not) your requirements. Second, there are proprietary
>MIBs that various vendors have that show this information
>as well.
>
>>I do not see this data incorporated in any MIB.
>>Now in the absence of such data, how can the management application
>>compute the explicit hops satisfying the criteria mentioned above.
>
>         The management application should not be required to
>compute the explicit hops. There are several reasons why this
>is very difficult, but basically they are the same as any
>off-line TE application would experience, just worse because
>the information needs to be up-to-date all the time. If it
>somehow does, it needs all of the information provided by the
>CSPF in every LSR, perhaps across multiple (G)MPLS domains.
>What is typical in such cases is the use of loose routes.
>These are specified at the head-end LSR, which then does the
>path computation between the points specified. This is much
>easier to do there because it already has this up-to-date
>information. In cases where specific paths are to
>be taken, then entire path (or most of it) is specified, and the
>LSR optionally fills-in the gaps. Some off-line tool may be
>used to assist the operator in this choice, but it is not
>mandatory, and as mentioned, is a difficult process to
>get right especially in a multi-vendor network.
>
>         --Tom
>
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



From owner-mpls@UU.NET  Sat Jun 30 07:39:34 2001
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21501
	for ; Sat, 30 Jun 2001 07:39:33 -0400 (EDT)
Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: mail-control.mail.uu.net [153.39.51.35])
	id QQkvqk19992;
	Sat, 30 Jun 2001 11:38:57 GMT
Received: by mail-control.mail.uu.net 
	id QQkvqk28186
	for mpls-outgoing; Sat, 30 Jun 2001 11:38:25 GMT
Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP 
	(peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47])
	id QQkvqk28171
	for ; Sat, 30 Jun 2001 11:38: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 QQkvqk03710
	for ; Sat, 30 Jun 2001 11:37:52 GMT
Received: from [192.168.100.19] by cmr0.ash.ops.us.uu.net with ESMTP 
	(peer crosschecked as: smtp.kpnqwest.com [193.242.92.8])
	id QQkvqk16744
	for ; Sat, 30 Jun 2001 11:37:51 GMT
Received: from ntexghub01.kpnqwest.com (unverified) by 
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Sat, 30 Jun 2001 13:37:50 +0200
Received: by ntexghub01 with Internet Mail Service (5.5.2653.19)
	id ; Sat, 30 Jun 2001 13:37:50 +0200
Message-ID: 
From: "Metz, Eduard" 
To: Bernard Zelmans ,
        "'Sasha Vainshtein'"
	 , mpls@UU.NET
Cc: Alik Shimelmits , Gonen Zilber ,
        Israel Sasson 
Subject: RE: L2 MPLS based VPN
Date: Sat, 30 Jun 2001 13:37:49 +0200
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


I think both L2VPN drafts support a mode in which the L2VPN carries MPLS as
the L2 protocol across the network. So in that way what you suggest is
supported already. 

When doing so, the PE becomes transparent to the MPLS payload however. This
means specific functionality in relation to the termination the L2 circuit
now moves towards the CE, and cannot be expected to be fullfilled on the PE
anymore.

cheers,
	Eduard


> -----Original Message-----
> From: Bernard Zelmans [mailto:bzelmans@calynet.com]
> Sent: 28 June 2001 18:32
> To: 'Sasha Vainshtein'; mpls@UU.NET
> Cc: Alik Shimelmits; Gonen Zilber; Israel Sasson
> Subject: RE: L2 MPLS based VPN
> 
> 
> let me describe what I'm thinking of and let me know if it's stupid.
> basically the idea is to distribute the initiation of the LSP 
> for the VC (as
> per Martini definition), closer to the customer. so I could 
> have a simple L2
> device that would be MPLS enable so that it learns from the 
> PE (through LDP)
> the FEC information. Then you would map all ethernet traffic 
> coming on one
> port or one VLAN id onto that LSP. On the PE you would 
> receive this labelled
> packet and would tunnel it to the peer egress point. so 
> basically you don't
> change the protocol (Martini or Kompella) but you extend to 
> another hop the
> initialisation of the LSP (corresponding to the VC or inner 
> label once in
> the tunnel from the PE)and advertise the FEC through LDP from 
> the PE to this
> MPLS enable device.
> the point is that I could implement PE function on my box but 
> which one to
> go to (Martini or Kompella)? it looks to me that Kompella has more
> advantages. but it also looks like that there will be 2 different
> implementations out there.
> Thanks in advance for your input,
> 
> b
> 
> -----Original Message-----
> From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]
> Sent: Wednesday, June 27, 2001 10:34 AM
> To: Bernard Zelmans; mpls@UU.NET
> Cc: Alik Shimelmits; Gonen Zilber; Israel Sasson
> Subject: RE: L2 MPLS based VPN
> 
> 
> Bernard,
> Inner labels in both Martiti-Transport and Kompella L2 VPN drafts 
> are distributed directly between peer edge devices, and have meaning
> only between these devices. Both Martini and Kompella drafts 
> allow using
> targeted LDP sessions for this purpose, and Kompella also allows using
> MP-BGP for this purpose.
> For the aggregation device to allocate the outer label, it 
> has to be able
> to infer somehow the FEC of the incoming packet.
> I see the following options for the packet transmitted by the 
> access device
> to the aggregation one:
> 1. It is a label packet with the outer label in the stack 
> being the inner
> label
> of the virtual connection. This label cannot be valid in the 
> aggregation
> device
> (as it did not participate in its distribution) so it either drops the
> packet or, even
> worse, misuses it.
> 2. It is an IP packet (say, with MPLS-in-IP protocol type and 
> the inner label following the IP header). In this case the 
> access device:
> * Has to operate as an IP router
> * Has to know IP address of its remote peer device
> * The aggregation device may push the "outer" label on top of 
> IP header
> or just to forward the unlabeled
> *The remote access device must recognize the incoming IP packet as 
> one carying MPLS-in-IP, strip its IP header and then process 
> the incoming
> label.
> I.e., the 2nd option will work, but it imposes restrictions on access
> devices. E.g.,
> you cannot connect Ethernet switches (which are not IP 
> routers) in this way.
> PE devices in both Martini and Kompella are assumed to be 
> LERs (as defined
> in RFC 3031)
> with additional capabilities allowing support of encapsulation of L2
> packets; this approach
> does not impose any restrictions on the access (presumably, 
> CPE) devices.
> With best regards,
>                                    Sasha Vainshtein
> email:     sasha@axerra.com  
> tel:       +972-3-7659993 (office)
>            +972-8-9254948 (res.)
>            +972-58-674833 (cell.)
>  
> 
> 
> > -----Original Message-----
> > From: Bernard Zelmans [mailto:bzelmans@calynet.com]
> > Sent: Wednesday, June 27, 2001 4:49 AM
> > To: mpls@UU.NET
> > Subject: L2 MPLS based VPN
> > 
> > 
> > Hi all,
> > 
> > looking at both Martini and Kompella draft on L2 based VPN, 
> > the LSP with the
> > inner+outer label is started from the same node (PE). Is 
> > there a particular
> > reason for that? why don't we allow an access device to 
> > initiate the inner
> > label LSP and have an aggregation device start the tunnel?
> > Thanks in advance,
> > 
> > b
> > 
>